Основи безпеки
Основи безпеки в епоху AI-розробки: ландшафт загроз, OWASP Top 10 для LLM та принципи безпечної розробки
📎ОФІЦІЙНА ДОКУМЕНТАЦІЯ
Основи безпеки в AI-розробці
Безпека в епоху AI-driven development вимагає нового підходу: крім традиційних загроз, з'являються специфічні ризики, пов'язані з використанням великих мовних моделей (LLM) у процесі розробки.
Ландшафт загроз
AI-розробка створює нові вектори атак, які доповнюють класичні загрози:
OWASP Top 10 для LLM Applications
OWASP визначив 10 найкритичніших ризиків для додатків на основі LLM:
1. Prompt Injection (LLM01)
Зловмисник маніпулює промптом для зміни поведінки LLM. Буває прямий (через user input) та непрямий (через дані, які LLM обробляє).
Захист: валідація вхідних даних, розділення системних та користувацьких промптів, обмеження привілеїв LLM.
2. Insecure Output Handling (LLM02)
Вихідні дані LLM використовуються без належної валідації, що може призвести до XSS, SQL injection та інших атак.
Захист: обробка виходу LLM як ненадійного вводу, санітизація перед використанням.
3. Training Data Poisoning (LLM03)
Маніпуляція тренувальними даними для впровадження backdoors або bias у модель.
Захист: верифікація тренувальних даних, моніторинг поведінки моделі, регулярний аудит.
4. Model Denial of Service (LLM04)
Атаки, що перевантажують LLM ресурсомісткими запитами.
Захист: rate limiting, обмеження розміру вхідних даних, моніторинг використання ресурсів.
5. Supply Chain Vulnerabilities (LLM05)
Вразливості в сторонніх компонентах: моделях, плагінах, бібліотеках.
Захист: верифікація джерел, SCA-сканування, SBOM, pinning версій.
6. Sensitive Information Disclosure (LLM06)
LLM розкриває конфіденційну інформацію через відповіді.
Захист: фільтрація виходу, data masking, обмеження доступу до даних.
7. Insecure Plugin Design (LLM07)
Плагіни LLM мають надмірні дозволи або не валідують вхідні дані.
Захист: принцип найменших привілеїв, валідація на рівні плагінів, аудит дозволів.
8. Excessive Agency (LLM08)
LLM отримує занадто широкі повноваження для виконання дій.
Захист: обмеження дій, human-in-the-loop для критичних операцій, журналювання.
9. Overreliance (LLM09)
Надмірна довіра до результатів LLM без верифікації.
Захист: обов'язковий code review, тестування, навчання розробників.
10. Model Theft (LLM10)
Несанкціонований доступ або копіювання моделей.
Захист: контроль доступу, шифрування, watermarking, моніторинг.
Принципи безпечної AI-розробки
Безпека повинна бути інтегрована в кожний етап розробки, а не додана після.
Defense in Depth
Використовуйте декілька рівнів захисту:
- Мережевий рівень -- firewall, segmentation, VPN
- Рівень ідентифікації -- MFA, RBAC, Conditional Access
- Рівень додатку -- валідація вводу, санітизація виводу
- Рівень даних -- шифрування, DLP, класифікація
- Рівень моніторингу -- SIEM, anomaly detection, audit logs
Least Privilege
- AI-агенти повинні мати мінімально необхідні дозволи
- Розділення ролей між development, staging та production
- JIT (Just-In-Time) доступ для привілейованих операцій
Secure by Default
- Конфігурації повинні бути безпечними за замовчуванням
- Небезпечні опції повинні бути явно увімкнені
- Регулярний аудит конфігурацій
Фреймворки та стандарти
| Фреймворк | Фокус |
|---|---|
| OWASP Top 10 for LLM | Ризики LLM-додатків |
| NIST AI RMF | Управління ризиками AI |
| ISO 27001 | Система управління інформаційною безпекою |
| Microsoft SDL | Безпечний життєвий цикл розробки |
| MITRE ATLAS | Тактики та техніки атак на AI |
Див. також
Інтеграція безпеки в життєвий цикл розробки
Як ефективно перевіряти код, згенерований AI
Комплексний підхід до кібербезпеки в AI-ері