Чи справді нам потрібен OWASP NHI Top 10?

pic

Open Web Application Security Project (OWASP) нещодавно представив свою нову ініціативу — Non-Human Identity (NHI) Top 10. Протягом останніх років різні списки Top 10 від OWASP, включаючи широко застосовувані рейтинги безпеки API та веб-додатків, стали невід’ємними інструментами для розробників та фахівців з кібербезпеки.

Тепер увага переміщується на нову галузь кібербезпеки: Безпека нефізичних ідентичностей (Non-Human Identity security). Це включає управління ризиками, пов'язаними з API-ключами, обліковими записами сервісів, додатками OAuth, SSH-ключами, ролями IAM, секретами та іншими машиними ідентичностями. Хоча OWASP вже пропонує надійні рамки для ризиків безпеки, нагальне питання: Чи дійсно нам потрібен NHI Top 10?

Відповідь однозначна — так. І ось чому.

Чому NHI Top 10 є необхідним

Хоча деякі існуючі проекти OWASP торкаються вразливостей, таких як неправильне управління секретами, вони не повністю охоплюють унікальні ризики, що виникають через NHI. NHI відіграють важливу роль у зв'язуванні систем, сервісів, даних та агентів AI через середовища розробки та експлуатації. Проте вони створюють вразливості, які традиційні рамки безпеки не охоплюють повністю, такі як:

  • Занадто великі привілеї
  • Атаки фішингу через OAuth
  • Експлуатація ролей IAM для латерального переміщення

Зі збільшенням кількості кібер атак на NHI, створення спеціального посібника для цих ризиків стало необхідним для розробників та команд з безпеки.

Як OWASP Top 10 ранжує ризики

OWASP використовує стандартну систему для пріоритетизації ризиків, засновану на:

  1. Експлуатованість: Наскільки легко хакерам використати вразливість?
  2. Вплив: Який рівень шкоди може завдати цей ризик для систем та операцій?
  3. Поширеність: Наскільки поширена ця проблема в різних середовищах?
  4. Виявлення: Наскільки важко виявити слабкість за допомогою наявних інструментів?

Ці критерії лежать в основі NHI Top 10 та його критичних ризиків, які детально описані нижче.

Розбір ризиків OWASP NHI Top 10

1. Неправильне завершення доступу (NHI1:2025)

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

2. Витік секретів (NHI2:2025)

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

3. Вразливі сторонні NHI (NHI3:2025)

Розробницькі пайплайни часто інтегруються з сторонніми інструментами, такими як CircleCI або GitHub, через NHI. Порушення безпеки з цими постачальниками змушують терміново змінювати облікові дані, підкреслюючи важливість моніторингу зовнішніх NHI.

4. Небезпечні методи аутентифікації (NHI4:2025)

Застарілі механізми, такі як імпліцитні потоки OAuth або паролі додатків, не підтримують MFA і залишають системи вразливими до сучасних атак.

5. Надмірні привілеї NHI (NHI5:2025)

Багато NHI працюють з надмірними правами через неуважні практики надання доступу. Нещодавній звіт CSA показав, що 37% інцидентів, пов'язаних з NHI, виникли через надмірні привілеї.

6. Небезпечні конфігурації хмарного деплойменту (NHI6:2025)

Невірно налаштовані CI/CD пайплайни та занадто ліберальні налаштування OIDC створюють лазівки для зловмисників, щоб скористатися критичними ресурсами.

7. Довготривалі секрети (NHI7:2025)

Секрети, що залишаються активними протягом багатьох років, збільшують ризик їхнього використання. Наприклад, Microsoft AI випадково розкрив токен, який був дійсним протягом більше двох років, що дозволяло отримати доступ до 38 ТБ внутрішніх даних.

8. Ізоляція середовища (NHI8:2025)

Погані практики ізоляції можуть дозволити тестовим NHI потрапити в середовище виробництва. Атака Midnight Blizzard на Microsoft продемонструвала цей ризик, коли тестовий додаток OAuth зберігав високі привілеї в середовищі виробництва.

9. Повторне використання NHI (NHI9:2025)

Повторне використання NHI в різних додатках порушує принцип найменших привілеїв та посилює шкоду в разі порушення безпеки.

10. Використання NHI людиною (NHI10:2025)

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

Стандартизація безпеки NHI за допомогою OWASP

OWASP NHI Top 10 заповнює критичну прогалину, надаючи стандартизовану рамку для вирішення цих вразливостей. Інструменти, як-от Astrix Security, вже інтегрували цю рамку у свої інформаційні панелі з дотримання стандартів, що дозволяє організаціям:

  • Візуалізувати прогалини в безпеці, пов'язані з NHI
  • Пріоритетно визначати заходи з виправлення
  • Відстежувати прогрес з часом

Застосовуючи NHI Top 10, організації можуть забезпечити міцне управління NHI, зменшити площу для атак і створити більш безпечні пайплайни для розробки.

Висновок

Нефізичні ідентичності знаходяться в основі сучасних цифрових екосистем, але вони залишаються одними з найменше зрозумілих та найбільш незахищених елементів кібербезпеки. OWASP NHI Top 10 дає фахівцям з безпеки практичні інсайти для захисту цих критичних активів.

З розвитком ландшафту загроз прийняття таких рамок, як NHI Top 10, вже не є просто рекомендацією — це необхідність.

Оптимізуйте свої стратегії кібербезпеки за допомогою OWASP NHI Top 10 вже сьогодні!

оригінальний пост: https://easy4hub.blogspot.com/

Перекладено з: Do We Really Need the OWASP NHI Top 10?

Leave a Reply

Your email address will not be published. Required fields are marked *