Людмила Лисичева | IBM Brand Development Manager SW | CLICO Bulgaria

Националният институт за стандарти и технологии на САЩ (NIST) дефинира Zero Trust като подход към киберсигурността, при който достъпът до ресурси вече не се дава по подразбиране само защото потребителят е „вътре“ в мрежата или използва служебно устройство. Вместо това доверието се изгражда всеки път на база на ясни политики, конкретен контекст и реална необходимост. С други думи — даваме достъп само до това, което е нужно за конкретната задача, в конкретната ситуация, а всеки опит за достъп извън тези рамки се третира като потенциално нерегламентиран.

Организациите все по-често работят в хибридни и мултиоблачни архитектури, където данните, работните натоварвания и контролите са разпределени между различни среди. Интеграциите между решения и инструменти ускоряват процесите, но създават и нови пътища за достъп, които не винаги са видими през класическия мрежов периметър. В този контекст нечовешките идентичности (non-human identities/NHI) — агенти, работни натоварвания (workloads), системни акаунти (service accounts), API токени и автоматизирани процесни потоци (pipelines) — са все повече и по-критични от човешките потребители.

Този модел става още по-важен с навлизането на agentic AI в продукционна среда. AI агентът може да търси, анализира и комбинира данни, да извиква API-та, да създава тикети, да изпраща съобщения или да променя конфигурации. С други думи: той извършва действия самостоятелно. 

Рисковият профил се променя

Нерегламентиран достъп вече може да възникне не само чрез компрометиран потребител, а и чрез прекалено широки права на инструмент, API или service акаунт. При Agentic AI допълнителен риск представлява ситуацията, при която агентът използва легитимен достъп до данни, но в неправилен контекст, ако липсват достатъчно подробни политики. Освен поверителността, може да бъде засегната и достоверността на информацията, когато данни от различни източници се смесват, извличат или интерпретират без ясен контрол на произхода, правата и контекста.

Въвеждането на Zero Trust политика в такава среда започва с преосмисляне на това кои са реалните субекти на достъп. На практика екипите по сигурност трябва да проверят дали политиката обхваща само човешките потребители, или и AI агенти, работни натоварвания, service акаунти, API токени, автоматизирани процесни потоци и cloud-native компоненти. В хибридна или мултиоблачна архитектура това означава контролите да не бъдат фрагментирани по отделни платформи, облаци или екипи, а да се прилагат последователно в цялата среда.

Следващият важен въпрос е къде реално се налага контролът. Ако достъпът се управлява основно през мрежови периметър, статични правила и идентификационни данни, Zero Trust остава частичен. По-устойчивият модел изисква политиките да се прилагат на ниво идентичност, мрежа и приложение според конкретния контекст на заявката, като постоянният привилегирован достъп постепенно се заменя с достъп по заявка (on-demand) и кратковременни, динамични идентификационни данни (short-lived, dynamic secrets).

Зрелостта на подобен модел се вижда не само в наличието на политики, но и в тяхната проследимост и изпълнимост. Всяко решение за достъп трябва да може да се свърже с конкретна идентичност, заявена цел, контекст, политика и реално използван ресурс. Също толкова важно е екипите да могат автоматизирано да ротират, отнемат и преиздават достъпи в мащаб, така че критичните права да не зависят от ръчни процеси, а границите между екипи, услуги, среди и данни да бъдат ясно дефинирани, наложени и проверими.

Как да прилагаме на практика?

• Управление на идентичностите, управление на NHI (Identity and Non-Human Identity Governance)

Първата стъпка е ясна идентификация на всички субекти: хора, приложения, работни натоварвания, service акаунти, автоматизирани процесни потоци и AI агенти. Всеки NHI обект трябва да има определен собственик, цел, среда, жизнен цикъл, допустими права и периодичен преглед. Необходимо е централизирано управление чрез IAM/IGA, регистър на NHI, модел за притежание и механизъм за регулярна проверка на достъпите.

• Динамични и краткотрайни идентификационни данни (Dynamic Secrets / Short-lived Credentials)

  От ключова важност е елиминирането на hard-coded secrets, статични пароли, дълготрайни API ключове и споделени идентификационни данни на service акаунти. В Zero Trust модел, особено при agentic AI workflows, достъпът трябва да се издава on-demand, за конкретен контекст, задача и идентичност. Кратковременните идентификационни данни (credentials) намаляват риска от изтичане, повторна употреба, странично придвижване (lateral movement) и нерегламентиран скрит достъп (shadow access). Необходимо е въвеждане на централизирано управление на тайни, динамично издаване на идентификационни данни, ротация, ограничен живот (TTL), отнемане (revocation) и одит.

• Политики като код (Policy as Code)

С развитието на мултиклауд, хибридни среди, Kubernetes, CI/CD и agentic AI workflows, подходът “Политики като код” се утвърждава като ключов за хомогенно, автоматизирано и одитируемо прилагане на политики. Вместо правилата да бъдат разпръснати като ръчни настройки в различни системи, те се описват като код — с версии, преглед, тестове и контрол преди внедряване. Това позволява политиките да се прилагат последователно в различни точки — облачни ресурси, Kubernetes workloads, CI/CD процесни потоци, API gateways и AI agent runtimes. Например:  AI агент може да извика даден инструмент само ако потребителят, от чието име действа, има необходимата роля; агентът е одобрен за този случай; данните не са класифицирани като ограничени; действието не е експорт към външен канал.

• Класифициране и защита на данните (Data Classification and Data Protection)

Не е достатъчно да знаем кой има достъп до дадена система и къде живеят данните.  Необходима е по-детайлна класификация по тип, вид и риск, както и според това какви операции се извършват —  дали те трябва да бъдат показани в пълен вид, маскирани, токенизирани, редактирани или блокирани. Тук на помощ идват инструменти за откриване на данни, класификация, мониторинг на дейността, маскиране/редакция, токенизация, DLP, одит, доклади за съответствие и дори проследяване на произхода на данните. Освен ограничаване на нерегламентирания достъп, тези решения подпомагат проследимостта и контрола върху интегритета чрез откриване на подозрителна активност, нерегламентирани промени и потенциална злоупотреба.

• Криптиране и управление на ключовете (Encryption and Key Management)

Данните трябва да бъдат защитени както в покой, така и при пренос, а при по-чувствителни сценарии — и на ниво приложение или отделни полена. Важно е криптографските ключове да не се управляват ръчно и да не се съхраняват в приложенията. Необходимо е централизирано управление на ключове, криптиране като услуга, HSM/KMS интеграция, подписване, токенизация и ротация на ключовете.

• API gateway и контрол на действията

API Gateway е важна точка на прилагане. Той може да валидира контекста на идентичността, обхвата на токена, разрешените методи, ограниченията на броя на заявките, контекста на източника и достъпа до конкретни API крайни точки.

Например: ако AI агент има право да чете данни за клиенти чрез /customers/read, това не означава, че трябва да има право да извиква /customers/export, /customers/update или /customers/delete.

• Време на изпълнение, работно натоварване и прилагане на действия (Runtime, Workload and Action Enforcement)

Важно е приложенията, workload-ите и AI агентите да не наследяват  автоматично всички права на потребителя, разработчика или средата, в която работят. Достъпът трябва да се ограничава според конкретния случай, среда, инструмент и действие. За високорискови действия като изтриване на данни, външно изпращане, промяна в продукционната среда или промяна на правата трябва да се прилагат контроли с човешка намеса (Human-in-the-loop контроли) — процеси на одобрение, повишено ниво на разрешение, одобрение, базирано на риска и проследимост на действията.

• Проследимост, одит и откриване на идентичности (Observability, Audit, Detection)

Zero Trust изисква проследимост. Трябва да може да се отговори не само на въпроса „кой достъпи системата“, а „кой потребител, чрез кой агент, с кои идентификационни данни, към кой API, с какво действие и какъв резултат“. На по-високото ниво работят централизирани логове, SIEM/XDR корелация, проследимост на действията, идентификатори за проследяване (trace IDs), правила за откриване на инциденти и процедури за реакция при инциденти.

• Управление на жизнения цикъл и непрекъснат преглед (Lifecycle Management and Continuous Review)

Zero Trust не е еднократна конфигурация. Достъпът, политиките, агентите, идентификационните данни и потокът на данните трябва да се преглеждат постоянно. Всеки достъп трябва да има ясно дефиниран жизнен цикъл — от създаване и използване до автоматично отнемане при отпадане на необходимостта.

Къде попада отговорността?

Едно от най-големите предизвикателства при внедряването на Zero Trust и agentic AI не е само технологично, но и организационно: политиките и инструментите често попадат между различни екипи. В много организации идентичностите се управляват споделено — от IT Operations или Service Desk за потребителски акаунти и групи, от Cloud/Platform или DevOps екипи за идентичности на работни натоварвания и системни акаунти, от собственици на приложения - за права в конкретни системи, а от екипите по сигурност — за контролната рамка, привилегирован достъп и прегледи на достъпа. Рискът е появата на „сиви зони“: агент без ясен собственик, идентификационни данни без жизнен цикъл, политика без точка на прилагане или логове без контекст. Успехът зависи от централизиран модел на управление с ясни собственици, дефинирани отговорности, периодични прегледи и рамка за проследимост, която свързва потребител, агент, идентификационни данни, инструмент, действие и резултат.