Запитання: як організації можуть переконатися, що їхні API стійкі до компрометації в умовах збільшення кількості атак на основі API?
Рорі Бланделл, засновник і генеральний директор Gravitee: Компанії будь-якого розміру та в усіх галузях регулярно покладаються на внутрішні API, щоб об’єднати свої бізнес-програми, і на зовнішні API, щоб обмінюватися даними чи послугами з постачальниками, клієнтами чи партнерами. Оскільки один API може мати доступ до кількох програм або служб, компрометація API є простим способом скомпрометувати широкий набір бізнес-активів з мінімальними зусиллями.
API стали популярним вектором атак, і частота атак API вражаюче зросла 681%, за останніми даними дослідження від Salt Labs. Першим кроком у захисті ваших API є дотримання найкращих практик, таких як OWASP рекомендує захистити від поширених ризиків безпеки API.
Однак базових практик безпеки API недостатньо для забезпечення безпеки ІТ-ресурсів. Компанії повинні вжити наступних додаткових заходів для захисту своїх API.
1. Використовуйте автентифікацію на основі ризиків
Компанії повинні прийняти політику автентифікації на основі оцінки ризику, яка дозволяє посилити захист безпеки у випадках підвищеного ризику. Наприклад, клієнт API з довгим досвідом надсилання законних запитів, які слідують передбачуваному шаблону, може не потребувати проходження такого самого рівня автентифікації для кожного запиту, як новий клієнт, який ніколи раніше не підключався. Але якщо шаблон доступу давнього клієнта API змінюється — наприклад, якщо клієнт раптово починає надсилати запити з іншої IP-адреси — вимога більш суворої автентифікації буде розумним способом переконатися, що запити не надходять від скомпрометованого клієнта.
2. Додайте біометричну автентифікацію
Хоча маркери залишаються важливими як основний засіб аутентифікації клієнтів і запитів, вони можна вкрасти. З цієї причини поєднання автентифікації на основі маркерів із біометричною автентифікацією є розумним способом підвищення безпеки API. Замість того, щоб припускати, що будь-хто, хто володіє маркером API, є дійсним користувачем, розробники повинні розробляти програми так, щоб користувачі також мали автентифікуватися за допомогою відбитків пальців, сканування обличчя або подібного методу, принаймні в контекстах підвищеного ризику.
3. Застосуйте зовнішню автентифікацію
Чим складнішими стають ваші схеми автентифікації API, тим важче забезпечити дотримання вимог безпеки в самій програмі. З цієї причини розробники повинні прагнути відокремити правила безпеки API від логіки додатків і натомість використовувати зовнішні інструменти, такі як шлюзи API, для забезпечення виконання вимог безпеки. Цей підхід робить політики безпеки API більш масштабованими та гнучкими, оскільки їх можна легко впроваджувати та оновлювати в межах API-шлюзів, а не через вихідний код програми. І що найважливіше, це дозволяє застосовувати різні правила до різних користувачів або запитів на основі різних профілів ризику.
4. Збалансуйте безпеку API із зручністю використання
Важливо не дозволити безпеці стати ворогом зручності використання. Якщо ви зробите заходи автентифікації API занадто нав’язливими або обтяжливими, ваші користувачі можуть відмовитися від ваших API, що є протилежністю того, що ви хочете. Уникайте цього, переконавшись, що правила безпеки API є суворими, коли для цього є підстави, але не висуваючи непотрібних вимог.
Атаки, націлені на API, не сповільнюються. Розробляючи та захищаючи API, розробники повинні вийти за рамки рекомендацій OWASP, щоб ускладнити використання API.
