Как да осигуря AI сигурност?

Как да осигуря AI сигурност?

За да осигуриш AI сигурност, третирай AI системата като продукт в production, а не като „модел“. Това значи: threat modeling, защита на данните, защита на версиите/артефактите, контрол на достъпа до inference, и специални мерки за LLM рискове (prompt injection, изтичане през tools, злоупотреба с контекст). AI сигурността не е единична защита, а слоеве: данни, модел, приложение и операции. Следващите стъпки дават практичен план.

Въведение

Класическата киберсигурност не е достатъчна за AI. Освен обичайните рискове (credential leaks, RCE, supply chain), AI добавя:

• data poisoning и „лоши“ training данни
• model inversion/extraction (извличане на знание/параметри)
• prompt injection и jailbreaking при LLM
• злоупотреба с инструменти (tools) и агентни системи
• drift: качеството пада и никой не забелязва

Затова най-добрият подход е: сигурност по дизайн + тестове + мониторинг.

Ако AI има достъп до вътрешни системи, всяка prompt injection атака може да стане бизнес инцидент.

Стъпка 1: Направи threat model (какво пазиш и от кого)

Започни с инвентар:

• Какви данни влиза/излиза (PII, търговски тайни)?
• Къде се пазят артефактите (model weights, prompts, ключове)?
• Какви интеграции има (CRM, файлове, платежни системи)?

Определи актьори и сценарии:

• външен атакуващ (ботове, scraping)
• вътрешен потребител (неволна грешка)
• доставчик/подизпълнител

Резултатът трябва да е списък от рискове с приоритет: вероятност × въздействие.

Стъпка 2: Заключи data pipeline-а (training и inference данни)

AI е толкова сигурен, колкото и данните му.

Мерки:

• Контрол на достъпа до raw данни (least privilege).
• Валидация на входа (schema, размери, лимити).
• Сканиране за PII/секрети преди логване.
• За RAG: sanitize на документи и източници; не индексирай „каквото дойде“.

За poisoning защита:

• подписани/версионирани datasets
• отделна карантина за нови данни
• автоматични проверки за аномалии в разпределенията

Стъпка 3: Защити supply chain-а (модели, зависимости, контейнери)

Съвременните AI системи са зависими от много пакети и модели.

Практики:

• pin-вай версии (poetry.lock/requirements.txt).
• сканирай контейнери за CVE.
• използвай private registry за образи.
• проверявай произход на модели (официален repo, hash).

Supply chain компромис в AI често изглежда като „странно поведение“, не като класически пробив.

Стъпка 4: Сигурен inference endpoint (auth, rate limits, изолация)

Минимални мерки за endpoint:

• TLS навсякъде
• authentication (API key/JWT/OAuth)
• authorization (кой може какви модели/функции)
• rate limiting и квоти
• входна валидация (size limits, типове)

Изолация:

• отдели inference от други услуги
• минимални права към storage/secret-и
• network egress политики (особено при tools)

Стъпка 5: LLM специфики: prompt injection и безопасни tools

OWASP публикува топ рискове за LLM приложения, като prompt injection е сред най-важните. Ако LLM има tools (например „изпрати имейл“, „чети CRM“, „плати“), ти трябва строг контрол.

Практичен модел:

• Allowlist на инструменти: LLM може да извиква само предварително дефинирани функции.
• Валидация на параметрите: типове, диапазони, позволени домейни.
• Sandbox за изпълнение: инструменти не трябва да имат директен достъп до production без допълнителни проверки.
• Output constraints: не изпълнявай „свободен текст“ като команда.

За prompt injection:

• разделяй „инструкции“ и „данни“ (например с ясни блокове)
• не се доверявай на съдържание от външни документи/URL като инструкции
• при RAG: маркирай източника като „не-доверен“ и филтрирай

Стъпка 6: Наблюдение и откриване на злоупотреба

Това, което не измерваш, не можеш да защитиш.

Следи:

• аномалии в трафика (spikes, scraping)
• повтарящи се провали/грешки
• подозрителни промптове (индикатори за jailbreak/injection)
• разходи (LLM често се DoS-ва през токени)
• качество (drift)

Полезно: отделен „security audit log“ с минимална чувствителност (метаданни, хешове), за да не логваш PII.

Стъпка 7: Тестове, red teaming и план за инциденти

Сигурността идва от упражнения.

• Направи тестове за OWASP LLM Top 10 рискове.
• Пусни „злоупотребни“ тестови промптове (jailbreak, injection).
• Тествай tools безопасността (валидирай, че не приемат опасни параметри).
• Направи план за инцидент: кой реагира, как се изключват интеграции, как се прави rollback.

Съвети за по-добри резултати

• Започни с минимални права и добавяй достъп постепенно.
• Използвай отделни ключове/проекти за dev/staging/prod.
• Въвеждай „human approval“ за опасни действия (плащания, изтриване, изпращане).
• Дръж лимити за токени, файлове и трафик.
• Преглеждай периодично prompts, tools и политики.

Чести грешки, които да избягваш

• LLM има директен достъп до вътрешни системи без allowlist/валидиране.
• Логваш целия промпт/контекст с лични данни.
• Няма rate limit и някой изяжда бюджета за час.
• Няма начин за бързо изключване на tools.
• Няма тестове за prompt injection.

Източници и полезни линкове (проверени 2023–2026)

• OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST AI Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework
• MITRE ATLAS (Adversarial Threat Landscape for AI Systems): https://atlas.mitre.org/

Контроли по слоеве (практична матрица)

Данни

• Класификация и маркиране (PII, секрети, вътрешни).
• Минимизация и редакт преди логване и преди изпращане към LLM.
• Валидация на входа: размери, типове, allowlist формати.
• Отделни хранилища и ключове за dev/staging/prod.

Модел и артефакти

• Версиониране на модели/промптове и проследимост (кой промени какво).
• Контрол на достъпа до weights и checkpoint-и.
• Проверка на целостта (hash) при сваляне на модели.
• Тестове за регресии при смяна на версия.

Приложение

• AuthN/AuthZ за endpoint-и и админ панели.
• Rate limiting и квоти на потребител/ключ.
• Ограничения на контекст и изход (tokens, размери).
• „Safe defaults“: ако нещо липсва, приложението отказва действие.

Операции

• Наблюдение на разход и злоупотреба (LLM DoS често е през токени).
• Аларми при аномалии и план за бързо изключване на интеграции.
• Ротация на ключове и периодични ревюта на права.

Сигурността на LLM приложенията се печели в интерфейса към данни и инструменти, не в „по-строг промпт“.

Мини-плейбук по OWASP рискове (LLM приложения)

Това не е изчерпателно, но е добра практична рамка за QA/пен тест:

• Prompt injection: отделяй инструкции от данни; не изпълнявай инструкции от външни документи; при tools ползвай allowlist.
• Data leakage: не логвай пълни промптове с PII; маскирай чувствителни полета; ограничи контекста.
• Insecure output handling: не изпълнявай свободен текст като SQL/код/команда; винаги валидирай и ескейпвай.
• Excessive agency: LLM не трябва да има „админ права“; опасните действия минават през потвърждение.
• Supply chain: pin-вай версии и проверявай произхода на модели/пакети.
• Overreliance: за важни решения винаги има човешка проверка или независима валидация.

Сигурност при RAG (когато LLM чете документи)

RAG добавя нови входни канали: файлове, уеб страници, бази знания. Това увеличава риска от injection през съдържание. Практики:

• Индексирай само проверени източници (или отдели „непроверени“ в карантина).
• Използвай метаданни и allowlist на домейни/папки.
• В отговора изисквай цитати към конкретни chunk-ове; ако няма цитат, не приемай твърдението за факт.
• Нормализирай документи при ingestion (премахни скрити инструкции, странни Unicode символи, макроси).

Практичен чеклист преди production

• Има ли threat model и собственик на риска?
• Има ли DLP/редакт преди логване?
• Има ли rate limiting и лимит на токени/контекст?
• Има ли allowlist на tools и валидиране на параметрите?
• Има ли отделни ключове за dev/staging/prod и ротация?
• Има ли мониторинг на разход и аларми при скок?
• Има ли runbook за инцидент и „kill switch“ за интеграции?

Атаки към модели: extraction, inversion и „изтичане“ на знание

Освен prompt injection има и атаки, насочени към самия модел и неговото поведение:

• Model extraction: атакуващият прави много заявки и се опитва да възпроизведе модела (или да извлече знанието му) чрез наблюдение на изходите.
• Model inversion / membership inference: опити да се „отгатне“ дали конкретни данни са били част от обучението или да се възстановят чувствителни характеристики.
• Jailbreaking: систематични техники да се заобиколят политиките и да се генерира забранено съдържание.

Контроли, които реално помагат:

• строги квоти и rate limits (намаляваш възможността за масово сондиране)
• наблюдение за автоматизирани модели на заявки (scraping)
• разделяне на модели/възможности по роли (потребителят не вижда „всичко“)
• минимизиране на детайлността на изхода, когато не е нужна (не връщай вътрешни логове, стекове, контекст)

Когато изходът става „API за атака“, правилният отговор е лимитиране и наблюдение, не само филтри.

Защита на системни инструкции и конфигурация

Системният промпт, инструментите и правилата са част от attack surface-а. Практики:

• дръж системните инструкции като код (version control + ревю)
• не ги „изплювай“ в отговора; филтрирай опити за prompt leaking
• отдели конфигурацията (ключове, домейни, allowlist) от текста, който LLM вижда
• при нужда от debugging, ползвай отделен debug режим за админи

Guardrails и оценка на риска (преди да дадеш достъп на потребители)

Не разчитай само на „правилен промпт“. Добави проверими guardrails:

• политика за съдържание (какво е забранено)
• класификация на вход/изход (напр. PII, токсичност, секрети)
• тестове с фиксирани сценарии (regression suite)
• отделни правила за различни групи потребители (ролева политика)

Практичен подход: събери 50–200 реални/синтетични примера, включително злоупотребни промптове, и мери колко често системата отказва опасни заявки и колко често „изпуска“ чувствителни данни.

Бележка: При AI системи „сигурност“ включва и бизнес злоупотреби: спам, измами, социално инженерство и злоупотреба с достъп. Дръж ясни правила кой може да прави какво, логвай критичните действия и отделяй време за регулярни прегледи на инциденти и near-miss случаи. Това е скучно, но реално намалява риска.

Добави редовни tabletop упражнения поне веднъж на тримесечие.