Чому безпека API є швидко зростаючою загрозою для підприємств, що керуються даними

Ознайомтеся із сесіями за запитом на саміті Low-Code/No-Code Summit, щоб дізнатися, як успішно впроваджувати інновації та досягати ефективності шляхом підвищення кваліфікації та масштабування громадянських розробників. Дивитися зараз.


Оскільки підприємства, що керуються даними, значною мірою покладаються на архітектуру програмного забезпечення, інтерфейси прикладного програмування (API) займають важливе місце. API революціонізували спосіб використання веб-додатків, оскільки вони допомагають конвеєрам зв’язку між кількома службами. Розробники можуть інтегрувати будь-яку сучасну технологію зі своєю архітектурою за допомогою API, що дуже корисно для додавання функцій, необхідних клієнту.

За своєю природою API вразливі до розголошення логіки додатків і конфіденційних даних, таких як особиста інформація (PII), що робить їх легкою мішенню для зловмисників. Часто доступні через загальнодоступні мережі (доступні з будь-якого місця), API, як правило, добре задокументовані та можуть бути швидко перепроектовані зловмисниками. Вони також чутливі до інцидентів відмови в обслуговуванні (DDoS).

Найбільш значні витоки даних відбуваються через несправні, вразливі або зламані API, які можуть відкрити медичні, фінансові та особисті дані широкій громадськості. Крім того, різні атаки можуть статися, якщо API не захищено належним чином, що робить безпеку API життєво важливим аспектом для бізнесу, що керується даними, сьогодні.

Чому безпека API важлива

За останні кілька років розробка API суттєво зросла завдяки цифровій трансформації та її центральній ролі в розробці мобільних додатків та Інтернету речей. Таке зростання та різноманітність можливих атак роблять безпеку API надзвичайно важливою.

Подія

Саміт інтелектуальної безпеки

8 грудня дізнайтеся про важливу роль штучного інтелекту та машинного навчання в кібербезпеці та конкретних галузевих прикладах. Зареєструйтеся, щоб отримати безкоштовний пропуск сьогодні.

Зареєструватися зараз

Оскільки мікросервіси та безсерверні архітектури набули більшого поширення, атаки включають обхід програми на стороні клієнта, щоб порушити роботу програми для інших користувачів або зламати конфіденційну інформацію. Крім того, зламані, розкриті або зламані API також можуть призвести до порушень серверної системи.

У звіті про безпеку та керування API [subscription required]Gartner прогнозує, що до 2023 року зловживання API перейде з рідкісних до найчастіших векторів атак, що призведе до витоку даних корпоративних веб-додатків, а до 2025 року понад 50% крадіжок даних відбуватиметься через незахищені API.

«У Gartner ми регулярно спілкуємося з організаціями, які зазнали порушень своїх API», — сказав VentureBeat Марк О’Ніл, віце-президент-аналітик Gartner. «Інтерфейси API особливо вразливі, тому що багато команд безпеки мають менший досвід у захисті API. Це особливо стосується нових типів API, таких як GraphQL».

Враховуючи важливу роль, яку вони відіграють у цифровій трансформації та доступ до конфіденційних даних і систем, які вони надають, API тепер вимагають спеціального підходу до безпеки та відповідності.

Безпека API проти безпеки програми

Безпека API зосереджена на захисті цього прикладного рівня та вирішенні того, що може статися, якщо зловмисний хакер безпосередньо взаємодіє з API. Безпека API також передбачає впровадження стратегій і процедур для пом’якшення вразливостей і загроз безпеці.

Коли конфіденційні дані передаються через API, захищений API може гарантувати секретність повідомлення, роблячи його доступним для програм, користувачів і серверів із відповідними дозволами. Він також забезпечує цілісність вмісту, перевіряючи, чи інформація не була змінена після доставки.

«Будь-яка організація, яка сподівається на цифрову трансформацію, повинна використовувати API для децентралізації додатків і одночасного надання інтегрованих послуг. Таким чином, безпека API має бути однією з ключових сфер», — сказав Муралідхаран Паланісамі, головний спеціаліст із рішень AppViewX.

Говорячи про те, чим безпека API відрізняється від загальної безпеки додатків, Паланісамі сказав, що безпека додатків схожа на захист головних дверей, які потребують надійних засобів контролю, щоб запобігти зловмисникам. У той же час безпека API — це захист вікон і заднього двору.

«Слабке місце в таких областях вплине на додаток. Безпека API, по суті, є частиною повної безпеки програми, без якої неможливо захистити програму в цілому», — сказав він.

Джерело зображення: Звіт про стан безпеки API від Безпека солі.

Ерез Ялон, віце-президент із досліджень безпеки в Checkmarx, каже, що безпека API не відрізняється від традиційного appsec, але додає більше областей, на які організації повинні звернути увагу.

«Архітектура, орієнтована на API, має більше кінцевих точок, якими потенційний зловмисник може спробувати зловживати; ми називаємо це «розростанням поверхні атаки», — сказав він. «Крім того, спосіб передачі та обміну даними через API дозволяє легко ненавмисно надати конфіденційні дані стороннім очим».

Ялон сказав, що API можна зробити більш безпечними, якщо безпеку розглядати з першого кроку та першого рядка коду, а не додавати як додатковий рівень пізніше в грі.

«Кожна кінцева точка API повинна бути задокументована, а організації повинні мати чіткі вказівки щодо припинення використання старих і невикористаних API. Переконайтеся, що оновлений SBOM [software bill of materials] існує, робить це простіше”, – сказав Ялон.

Критичні уразливості API та атаки

API швидко зарекомендували себе як переважний метод створення сучасних програм, особливо для мобільних пристроїв та Інтернету речей (IoT). Однак, перед обличчям постійної зміни методів розробки додатків і тиску на інновації, деяким компаніям все ще потрібно повністю усвідомити потенційні ризики, пов’язані з наданням їх API загальнодоступним. Перед публічним розгортанням компанії повинні бути обережними щодо таких типових помилок безпеки:

  • Помилки автентифікації: Багато API відхиляють запити статусу автентифікації від справжнього користувача. Зловмисник може копіювати запити API, використовуючи такі недоліки різними способами, включаючи викрадення сеансу та агрегацію облікових записів.
  • Відсутність шифрування: У багатьох API відсутні надійні рівні шифрування між клієнтом API і сервером. Через такі недоліки зловмисники можуть перехопити незашифровані або погано захищені транзакції API, викрасти конфіденційні дані або змінити дані транзакцій.
  • Недолік безпеки кінцевої точки: Оскільки більшість пристроїв IoT і мікросервісних інструментів розроблені для зв’язку із сервером через канал API, хакери намагаються отримати контроль над ними через кінцеві точки IoT. Це може призвести до зміни порядку API, що призведе до порушення даних.

Поточні проблеми безпеки API

За словами Яніка Бедарда, керівника відділу тестування на проникнення, IBM Security X-Force Red, однією з поточних проблем безпеки API є їх перевірка на безпеку, оскільки призначені логічні потоки можуть бути складними для розуміння та тестування, якщо вони не чітко визначені.

«У веб-додатку ці логічні процеси інтуїтивно зрозумілі завдяки використанню веб-інтерфейсу користувача, але в API може бути складніше деталізувати ці робочі процеси», — сказав Бедард VentureBeat. «Це може призвести до тестування безпеки на відсутні вразливості, які, у свою чергу, можуть бути використані зловмисниками».

Бедард сказав, що оскільки конвеєрна передача API стає дедалі складнішою, часто виникають питання про те, яка служба відповідає за який аспект безпеки та в який момент дані вважаються «чистими».

«Сервіси зазвичай вважають дані, що надходять з інших API, чистими, лише для того, щоб вони виявилися необробленими належним чином», — сказав він.

Бернард каже, що прикладом цього було початкове відкриття вразливості Log4J, коли більшість компаній зосереджувалися насамперед на тому, що вони мали безпосередньо в Інтернеті.

«Шкідливі дані врешті-решт надходитимуть до серверних API, іноді за багатьма іншими службами. Ці API, у свою чергу, були б вразливими та могли б надати зловмиснику початкову точку опори в організації», – сказав він.

Джерело зображення: Звіт про стан безпеки API від Salt Security.

«Головне завдання — виявити, оскільки багато команд безпеки просто не впевнені, скільки вони мають API», — сказав Сенді Каріеллі, головний аналітик Forrester.

Каріеллі сказав, що багато команд неусвідомлено розгортають шахрайські API або можуть існувати непідтримувані API, які все ще є загальнодоступними, що може призвести до кількох загроз безпеці.

«Специфікації API можуть бути застарілими, і ви не можете захистити те, про що не знаєте, що маєте», — сказала вона. «Почніть із розуміння того, які елементи керування вже є у вашому середовищі для захисту API, а потім визначте та усуньте прогалини. Важливо, переконайтеся, що виникли API та інвентаризація».

Найкращі методи підвищення безпеки API

Надійність безпеки API повністю залежить від того, як архітектура даних забезпечує дотримання правил автентифікації та авторизації. Завдяки технологічним досягненням, таким як хмарні служби, шлюзи API та інтеграційні платформи тепер дозволяють постачальникам API захищати свої API унікальними способами. Стек технологій, на основі якого ви збираєтеся створювати свої API, впливає на те, як ви їх захищаєте.

Для ефективного захисту системи від зловмисників API можна використовувати кілька підходів:

  • Шлюз API: Шлюз API є основою структури безпеки API, оскільки він спрощує розробку, підтримку, моніторинг і захист API. Шлюз API може захищати від різних загроз і забезпечувати моніторинг API, журналювання та обмеження швидкості. Він також може автоматизувати перевірку маркерів безпеки та обмеження трафіку на основі IP-адрес та інших даних.
  • Брандмауери веб-додатків: Брандмауер веб-програми або WAF діє як проміжний рівень між загальнодоступним трафіком і шлюзом або програмою API. WAF можуть запропонувати додатковий захист від загроз, таких як боти, забезпечуючи виявлення зловмисних ботів, здатність ідентифікувати сигнатури атак і додаткову IP-розвідку. WAF можуть бути корисними для блокування поганого трафіку ще до того, як він досягне вашого шлюзу.
  • Програми безпеки: Автономні продукти безпеки, які підтримують такі функції, як захист у реальному часі, статичне сканування коду та вразливостей, вбудована перевірка та розмитість безпеки, також можуть бути впроваджені в архітектуру безпеки.
  • Безпека в коді: Код безпеки – це форма захисту, реалізована внутрішньо в API або програмах. Однак ресурси, необхідні для забезпечення правильного впровадження всіх заходів безпеки у вашому коді API, може бути важко застосувати узгоджено для всіх ваших портфелів API.

Майбутнє безпеки API

Рой Ліберманн, керівник відділу успіху клієнтів у Surf Security, вважає, що нульова довіра може бути ще однією альтернативою захисту від внутрішніх і зовнішніх загроз.

«Коли мова заходить про API, нульова довіра актуальна як для клієнтів, так і для серверів», — сказав він. «Додаток, керований API, може мати величезну кількість мікросервісів, що ускладнює керівникам служби безпеки відстеження їх розвитку та впливу на безпеку. Прийняття принципів нульової довіри гарантує, що кожен мікросервіс спілкується з найменшими привілеями, запобігаючи використанню відкритих портів і забезпечуючи автентифікацію та авторизацію в кожному API».

Ліберманн рекомендує CISO поширювати нульову довіру до API, щоб зменшити ризик використання хакерами зв’язку API для викрадення даних.

Подібним чином Паланісамі каже, що в міру того, як безпека з нульовою довірою та архітектури з нульовою довірою набирають обертів, безпека API буде однією з головних областей уваги, особливо з SaaS та іншими хмарними службами, які використовуються сьогодні.

«Ключ у тому, щоб дивитися на це з підходом до всього підприємства. Безпеку API не можна вирішити, зосередившись лише на кількох програмах», — сказав він.

«Найімовірніше, у наступні п’ять років ми побачимо іншу зміну парадигми програмного забезпечення, яке поєднує функції безпеки REST і SOAP. Я вважаю, що буде парадигма розробки програмного забезпечення, де функції кожного методу використовуються для створення комбінованого кращого методу», — сказав Набіл Ханнан, керуючий директор NetSPI, для VentureBeat. «Це поєднання позбавить розробників безпеки та дозволить краще запровадити «безпечні за проектом»».

Ханнан сказав, що концепція ідентифікації та автентифікації змінюється, і нам потрібно відійти від імен користувачів і паролів і двофакторної автентифікації, яка покладається на те, що люди не роблять помилок.

«Робочий процес автентифікації зміниться на те, що такі компанії, як Apple, роблять із керуванням ідентифікацією за допомогою таких інновацій, як брелок iOS16. Найближчим часом це буде розроблено через API», — сказав він.

Місія VentureBeat має стати цифровою міською площею для тих, хто приймає технічні рішення, щоб отримати знання про трансформаційні корпоративні технології та транзакції. Відкрийте для себе наші брифінги.

Leave a Comment