Управление на тайните за машинни идентичности за одити през 2026 г.

Предупреждението в 02:13, което никой не можеше да свърже със собственик

В 02:13 във вторник сутрин каналът на центъра за операции по сигурността (SOC) светва. Стартиран е експорт от продукционна база данни чрез вътрешен акаунт за автоматизация. Пътят за достъп е легитимен. Токенът е валиден. Изходният IP адрес принадлежи на облачен runner, използван от инженерния екип. Няма видим зловреден софтуер. Няма доклад за фишинг.

CISO задава първия очевиден въпрос: „Кой е собственикът на тази идентичност?“

Мълчание.

Ръководителят на DevOps си спомня, че токенът е създаден по време на миграция на клиент преди две години. Екипът на платформата казва, че може да се използва от интеграция за фактуриране. Администраторът на базата данни казва, че има достъп само за четене, защото премахването му веднъж е прекъснало нощна задача. Правният отдел пита дали са били засегнати лични данни. Функцията по съответствие пита дали това е инцидент, подлежащ на докладване по NIS2, DORA или GDPR. Одиторът изисква доказателства, че служебните акаунти, API ключовете, сертификатите и CI/CD тайните са инвентаризирани, преглеждани, ротирани, наблюдавани и отнемани.

Към 09:00 проектът на одитната констатация вече се оформя. В забравен микросървис е открит твърдо заложен, неротиран API ключ. Той предоставя широк достъп до продукционна база данни с клиентски транзакции. Разработчикът, който го е създал, е напуснал преди две години. Системата няма именуван собственик, няма документирана цел, няма запис за ротация и няма правило за мониторинг.

Това е проблемът с машинните идентичности през 2026 г.

Повечето организации са подобрили контрола на достъпа за хора. Те имат MFA, работни потоци за постъпващи, преместващи се и напускащи служители, прегледи на привилегирован достъп и журнали от доставчика на идентичност. Но машинните идентичности са се размножили по-бързо от управлението. Служебни акаунти, идентичности на работни натоварвания, API ключове, OAuth токени, SSH ключове, сертификати, Kubernetes тайни, SaaS интеграционни токени, акаунти за роботизирана автоматизация на процеси и CI/CD удостоверителни данни за разгръщане вече извършват критични бизнес действия, без да са „потребители“ в човешкия смисъл.

За доставчици на SaaS, финтех компании, доставчици на управлявани услуги, оператори на облачни услуги и МСП с висока зависимост от данни неуправляваните машинни идентичности вече не са въпрос само на техническа хигиена. Те са риск за устойчивостта и съответствието на ниво управителен орган. NIS2 третира контрола на достъпа, управлението на активите, сигурността на веригата на доставки, обработването на инциденти и киберхигиената като основни мерки за управление на риска в киберсигурността. DORA поставя ИКТ риска, оперативната устойчивост, докладването на инциденти и риска от трети страни в областта на ИКТ под отчетността на управителния орган на финансовите субекти. GDPR изисква администраторите и обработващите лични данни да защитават личните данни и да демонстрират отчетност.

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

Защо машинните идентичности се превърнаха в новия проблем на привилегирования достъп

Машинна идентичност, или NHI, е всяка цифрова идентичност, използвана от софтуер, инфраструктура или автоматизирани процеси, а не от човек. На практика това включва служебни акаунти, използвани от приложения, API ключове, използвани от SaaS интеграции, OAuth и refresh токени, използвани от приложения на трети страни, SSH ключове, използвани от автоматизация, TLS сертификати и частни ключове, CI/CD тайни, идентичности на облачни работни натоварвания, низове за връзка с бази данни, вградени удостоверителни данни, RPA bot акаунти и удостоверителни данни за интеграции, управлявани от доставчици.

Тези идентичности често имат три характеристики, които притесняват одиторите.

Първо, те са дългоживеещи. Човешки потребител може да ротира удостоверителни данни, да сменя роли и да напусне чрез формален процес на освобождаване. API токен, създаден по време на прозорец за внедряване, може да остане активен години наред, защото никой не иска да рискува прекъсване на продукционната среда.

Второ, те са мощни. Токен за разгръщане може да променя инфраструктура. Принципал на облачна услуга може да създава хранилища. Акаунт в база данни може да експортира клиентски записи. Ключ за подписване може да компрометира целостта на софтуерната верига на доставки.

Трето, те трудно се свързват с конкретна отговорност. Човешките идентичности са обвързани със записи в ЧР. Машинните идентичности често са обвързани със скриптове, пайплайни, доставчици, забравени проекти или недокументирани интеграции.

Zenith Blueprint: 30-стъпкова пътна карта на одитора на Clarysec Zenith Blueprint посочва това директно във фазата „Контроли в действие“, стъпка 22:

И не забравяйте машинните идентичности. Именно тук одитите често разкриват тиха експозиция. Проследяват ли се API токените? Обвързани ли са интеграционните акаунти с хора, или висят без собственик? Кога за последно беше ротиран низът за достъп до база данни, вграден в скрипт отпреди десетилетия?

Управлението на идентичности не е бляскаво, но е структурно. Без него вашата СУСИ е просто набор от заключени врати, без начин да сте сигурни кой държи ключовете.

Последното изречение е същността. Една компания може да има добре оформена политика за контрол на достъпа и въпреки това да не премине одит, ако машинните идентичности не се управляват. СУСИ, която не може да обясни кой е собственик на дадена тайна, защо тя съществува и кога е била последно прегледана, все още не функционира като контролирана система.

ISO/IEC 27001:2022 превръща управлението на тайни в доказателства

ISO/IEC 27001:2022 е ефективен, защото не третира управлението на тайни като изолирана инженерна задача. Той изисква рисково базирана СУСИ с определен обхват, изисквания на заинтересованите страни, отчетност на ръководството, оценка на риска, третиране на риска, избор на контроли, Декларация за приложимост и непрекъснато подобрение.

При машинните идентичности организацията не следва да започва с покупка на инструмент. Тя трябва да започне с обхвата и задълженията.

Съгласно клаузи 4.1 до 4.4 на ISO/IEC 27001:2022 организацията определя вътрешните и външните фактори, заинтересованите страни, правните, регулаторните и договорните изисквания, интерфейсите и зависимостите. В контекста на NHI обхватът на СУСИ трябва да идентифицира облачни среди, SaaS платформи, CI/CD системи, продукционни приложения, клиентски интеграции, обработващи лични данни, доставчици на управлявани услуги и криптографски услуги, в които съществуват машинни удостоверителни данни.

Клаузи 5.1 до 5.3 възлагат на ръководството отчетност за политиките, ресурсите, ролите и докладването на резултатността. Това е важно, защото коригирането на пропуски при NHI често създава оперативно напрежение. Ротацията на удостоверителни данни за продукционна база данни, замяната на наследен споделен служебен акаунт или налагането на инжектиране на тайни от трезор може да прекъсне крехки работни потоци. Без изпълнителен спонсор екипите отлагат почистването.

Клаузи 6.1.1 до 6.1.3 и 6.2 осигуряват контролния механизъм. Организацията определя критерии за риска, идентифицира рискове за поверителността, целостта и наличността, назначава собственици на риска, оценява вероятност и въздействие, избира варианти за третиране, подбира контроли, изготвя Декларацията за приложимост и проследява измерими цели.

В практически план планът за третиране на риска при машинни идентичности трябва да отговори на следното:

• Кои системи и бизнес услуги зависят от NHI?
• Кои тайни могат да осъществяват достъп до лични данни, регулирани финансови услуги, продукционна инфраструктура или критични клиентски услуги?
• Кои идентичности са привилегировани, неактивни, споделени, управлявани от доставчик или неуправлявани?
• Кои контроли намаляват риска, като съхранение в трезор, ротация, минимални привилегии, срок на валидност, управление на жизнения цикъл на сертификати, CI/CD сканиране, мониторинг и аварийно отнемане?
• Кои остатъчни рискове изискват бизнес одобрение?

След това ISO/IEC 27002:2022 предоставя каталога с контроли от Annex A. Най-релевантните контроли включват 5.9 Инвентар на информацията и други свързани активи, 5.15 Контрол на достъпа, 5.16 Управление на идентичности, 5.17 Информация за удостоверяване, 5.18 Права за достъп, 5.19 Информационна сигурност във взаимоотношенията с доставчици, 5.20 Адресиране на информационната сигурност в споразуменията с доставчици, 5.21 Управление на информационната сигурност във веригата на доставки на ИКТ, 5.23 Информационна сигурност при използване на облачни услуги, 5.24 Планиране и подготовка за управление на инциденти, 5.28 Събиране на доказателства, 8.2 Права за привилегирован достъп, 8.3 Ограничаване на достъпа до информация, 8.5 Сигурна автентикация, 8.15 Регистриране, 8.16 Дейности по мониторинг, 8.24 Използване на криптография, 8.25 Сигурен жизнен цикъл на разработката, 8.26 Изисквания за сигурност на приложенията, 8.28 Сигурно програмиране и 8.31 Разделяне на среди за разработка, тест и продукция.

Zenith Controls: Ръководство за кръстосано съответствие на Clarysec Zenith Controls съпоставя тези връзки по ISO/IEC 27002:2022 по начин, който одиторите и собствениците на контроли могат да използват. За контрол 5.16, Управление на идентичности, Zenith Controls обяснява връзката между идентичността и удостоверителните данни:

Управлението на идентичности дава отговора „кой“, докато информацията за удостоверяване гарантира „как“ — проверката, че лицето, което заявява дадена идентичност, е легитимно. 5.16 управлява жизнения цикъл на идентичността, докато 5.17 гарантира, че пароли, токени, сертификати и други удостоверителни данни са сигурно обвързани с тези идентичности и се управляват правилно в подкрепа на силна автентикация.

Тази връзка е съществена за NHI. Токен без собственик на идентичността не е одитируем. Служебен акаунт без преглед на достъпа не отговаря на принципа на минимални привилегии. Сертификат без статус на жизнения цикъл не е контролирана криптография. Удостоверителни данни за интеграция с доставчик без договорни условия не са ефективно управление на риска от трети страни.

Контролният модел на Clarysec: идентичност, тайна, привилегия, доказателства

Clarysec внедрява управлението на машинни идентичности и тайни чрез повторяем контролен модел. Ние не третираме „тайните“ само като въпрос на DevOps или „служебните акаунти“ само като въпрос на IAM. Свързваме идентичност, тайна, привилегия и доказателства.

Слоят на политиката е мястото, където това става приложимо.

За МСП Политика за управление на потребителски акаунти и привилегии за МСП на Clarysec Политика за управление на потребителски акаунти и привилегии за МСП постановява:

Служебните акаунти, използвани от системи или приложения, трябва да бъдат документирани, ограничени до конкретни системи и никога да не се използват за интерактивно вписване.

Това предотвратява класическия антимодел, при който служебен акаунт се превръща в споделен администраторски вход. То също така дава на одитора ясен тест: покажете инвентара на служебните акаунти, покажете системното ограничение и покажете, че интерактивното вписване е деактивирано или технически предотвратено.

Политика за управление на активите за МСП на Clarysec Политика за управление на активите за МСП разширява дефиницията за активи, за да включи:

Цифрови удостоверителни данни и услуги: домейн имена, цифрови сертификати, API ключове, имейл акаунти, облачни вписвания

Това е важно, защото много организации инвентаризират само сървъри, лаптопи и приложения. През 2026 г. един API ключ може да бъде по-чувствителен от лаптоп. Частният ключ на сертификат може да бъде продукционен актив за автентикация. Облачно вписване, използвано от автоматизация, може да създаде експозиция на регулирани данни. Третирането на удостоверителните данни като активи е основата на готовото за одит управление на тайни.

За корпоративни среди Политика за управление на потребителски акаунти и привилегии на Clarysec Политика за управление на потребителски акаунти и привилегии повишава прага за доказателства:

Организацията трябва да поддържа подробен инвентар на всички активни и неактивни удостоверителни данни, привилегировани акаунти и служебни акаунти на системно ниво. Този инвентар трябва да се актуализира непрекъснато и да се преглежда на тримесечна база.

Именно при тримесечния преглед излизат на повърхността много пропуски. Неактивни удостоверителни данни, осиротели служебни принципали, стари интеграционни потребители, неуправлявани акаунти на доставчици и аварийни токени стават видими само когато някой сравни регистъра с реалните записи в IAM, трезора, CI/CD и облачните среди.

Тайните са информация за удостоверяване, а не удобство за разработчици

Най-опасната фраза в управлението на тайни е „временен ключ“.

Временните ключове стават постоянни. Тестовите удостоверителни данни достигат продукционната среда. Изходният код разкрива токени. Журналите от компилации излагат пароли. Екипите за поддръжка споделят сертификати чрез билети. Разработчиците копират файлове с променливи на средата в чат. Външен изпълнител създава принципал на облачна услуга и напуска.

Zenith Blueprint, във фазата „Контроли в действие“, стъпка 22, описва информацията за удостоверяване в широк смисъл:

Този контрол не се отнася само до паролите, макар че паролите със сигурност са част от картината. Той се отнася до всички удостоверителни данни, използвани за заявяване на идентичност: пароли, PIN кодове, криптографски ключове, биометрични шаблони, смарт карти, токени, сертификати, OAuth токени, SSH ключове, API тайни. Това са ключовете към кралството и контрол 5.17 гарантира, че тези ключове се третират със сериозността, която заслужават.

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

Политиките на Clarysec превръщат това в оперативни правила.

Политика за криптографски контроли за МСП Политика за криптографски контроли за МСП постановява:

Ключовете не трябва да се съхраняват в открит текст или да бъдат вграждани в изходен код, документи или имейли

Политика за сигурна разработка за МСП Политика за сигурна разработка за МСП постановява:

Без твърдо кодирани удостоверителни данни или тайни в изходния код

За корпоративни екипи Политика за сигурна разработка Политика за сигурна разработка постановява:

Тайните не трябва да бъдат твърдо кодирани или съхранявани в открит текст в хранилища.

А Политика за изискванията за сигурност на приложенията Политика за изискванията за сигурност на приложенията е още по-директна:

Съхраняването на пароли или криптографски ключове в открит текст е строго забранено.

Тези клаузи на политиките създават ясна одитна следа. Екипите по сигурността могат да тестват хранилища, CI/CD променливи, контейнерни образи, конфигурационни хранилища, системи за проследяване на задачи, платформи за документация и журнали спрямо изрични изисквания. Те също така подкрепят сигурността на обработването по GDPR Article 32, защото експозицията на тайни може директно да доведе до неоторизиран достъп до лични данни.

Корпоративното управление на криптографията също изисква собственост. Политика за криптографски контроли на Clarysec Политика за криптографски контроли изисква:

Трябва да се поддържа централизиран Регистър за управление на ключове, в който се записват всички криптографски ключове, статусът на жизнения им цикъл, определените попечители и контекстите на използване.

За машинните идентичности този регистър трябва да свързва ключове на сертификати, ключове за подписване, API ключове и ключове, управлявани в облак, с по-широкия регистър на NHI. Одиторът трябва да може да проследи продукционен сертификат от бизнес услугата до собственика, попечителя, срока на валидност, доказателствата за ротация и процедурата за реагиране при инциденти.

NIS2, DORA и GDPR: един модел на доказателства, много регулатори

Управлението на машинните идентичности е проблем на кръстосаното съответствие, защото един и същ отказ може да задейства множество задължения.

Изтекъл API токен при доставчик на SaaS може да причини прекъсване на услуга по NIS2, експозиция на лични данни по GDPR и договорно докладване на инцидент към финансови клиенти съгласно очакванията на DORA за веригата на доставки. Компрометирана CI/CD тайна при доставчик на ИКТ услуги може да засегне устойчивостта на клиентите, целостта на софтуера и непрекъсваемостта на дейността. Забравен акаунт за интеграция с доставчик може да създе достъп до регулирани системи без подходяща надлежна проверка или договорни контроли.

NIS2 Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки. Минималните области включват анализ на риска, политики за сигурност на информационните системи, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурно придобиване, разработка и поддръжка, обработване на уязвимости, оценка на ефективността, киберхигиена, криптография, сигурност на ЧР, контрол на достъпа и управление на активите, както и, когато е подходящо, MFA или непрекъсната автентикация. Машинните идентичности попадат в почти всички тези области. NIS2 Article 23 също създава поетапно докладване на значителни инциденти, включително ранно предупреждение в срок от 24 часа, уведомяване за инцидент в срок от 72 часа и окончателен доклад не по-късно от един месец след уведомлението за инцидент.

DORA се прилага от 17 януари 2025 г. и обхваща управлението на ИКТ риска, докладването на съществени инциденти, свързани с ИКТ, тестването на оперативната устойчивост, споделянето на информация и риска от трети страни в областта на ИКТ. Articles 5 и 6 изискват управление, отчетност на управителния орган и документирана рамка за управление на ИКТ риска. Article 8 изисква идентифициране на бизнес функции, поддържани от ИКТ, информационни активи и зависимости. Articles 17 до 19 изискват управление на инциденти, класификация и докладване. Articles 28 до 30 изискват управление на риска от трети страни в областта на ИКТ, договорни регистри, надлежна проверка, стандарти за сигурност, права на одит, подкрепа при инциденти, контроли за подизпълнители и стратегии за изход.

GDPR се прилага навсякъде, където се обработват лични данни в неговия териториален обхват. Article 5 изисква цялостност, поверителност и отчетност. Article 32 изисква подходящи технически и организационни мерки за сигурност на обработването. Ако служебен акаунт или API ключ може да достъпва лични данни, неуправляваните тайни се превръщат в отказ на контрол за поверителност, а не само в ИТ проблем.

Едни и същи доказателства могат да подкрепят сертификация по ISO/IEC 27001:2022, надзор по NIS2, проверки по DORA и отчетност по GDPR, когато са структурирани правилно.

NIST CSF 2.0 може да се използва като комуникационен слой за същите доказателства. Неговата функция GOVERN обхваща очакванията на заинтересованите страни, правните и договорните задължения, апетита за риск, отчетността на ръководството, политиката и надзора. Оперативните му резултати обхващат инвентари на активи, услуги, предоставяни от доставчици, управление на идентичности и удостоверителни данни, минимални привилегии, сигурност на данните, регистриране, мониторинг, реагиране при инциденти и възстановяване.

COBIT 2019 и екипите за уверение в стил ISACA обикновено разглеждат управлението и процесната способност. Те ще попитат дали е възложена отговорност, дали контролите са вградени в оперативните процеси, дали изключенията са одобрени, дали показателите се докладват на ръководството и дали доказателствата демонстрират повторяемост, а не еднократно почистване.

Практически спринт за изграждане на регистър на машинните идентичности

Практическият ангажимент на Clarysec често започва с фокусиран спринт, а не с шестмесечна програма за инструменти. Целта е да се създаде защитим регистър на NHI, ранжиране на риска и план за коригиращи действия, които могат да захранят плана за третиране на риска и Декларацията за приложимост по ISO/IEC 27001:2022.

Започнете с една бизнес услуга, например платформа за фактуриране на клиенти, търговско приложение, пациентски портал или система за управление на SaaS tenant-и. Включете продукционна среда, staging, CI/CD, облачна инфраструктура, инструменти за мониторинг, бази данни, SaaS интеграции и услуги, управлявани от доставчици.

Свържете това със Zenith Blueprint, фазата „Управление на риска“, стъпка 14, където Clarysec съгласува политиките за третиране с регулаторни кръстосани препратки. В тази стъпка контролите за сигурна разработка и пайплайни включват забрана за твърдо заложени тайни, преглед от равнопоставени, автоматизиран статичен анализ, сканиране на зависимости, разделяне на разработка, тестване и продукция, MFA за достъп до пайплайни, целостта на артефакти от компилация и CI/CD регистриране.

Съберете идентичности и тайни от доставчика на идентичност, облачния IAM, трезора за тайни, Kubernetes, CI/CD променливи, настройки на хранилища, потребители на бази данни, SaaS административни конзоли, инструменти за управление на сертификати и документация на доставчици.

Оценявайте риска на идентичности, които имат достъп до продукционна среда, привилегировани права, достъп до лични данни, зависимост от критична или важна функция, контрол от доставчик, дългоживеещи токени, липса на собственик, липса на ротация, липса на мониторинг или твърдо кодирано съхранение. Използвайте критериите за риск по ISO/IEC 27001:2022, за да оцените вероятността и въздействието. Използвайте анализа на критични или важни функции по DORA, когато е приложимо. Използвайте съображения за въздействие по GDPR, когато личните данни са достъпни. Използвайте въздействието върху услугата по NIS2, когато е вероятно прекъсване или вреда за клиентите.

За всяка NHI с висок риск приложете действия за третиране. Преместете тайните от изходен код, документи и CI/CD променливи в открит текст в трезор или управлявано хранилище за тайни. Заменете споделените служебни акаунти с уникални идентичности на работни натоварвания. Деактивирайте интерактивното вписване за служебни акаунти. Приложете минимални привилегии и удостоверителни данни, специфични за средата. Конфигурирайте ротация, срок на валидност и аварийно отнемане. Обвържете тайните със собственици и попечители. Добавете журналиране за автентикация, използване на токени и чувствителни действия. Добавете предупреждения за аномална география, необичайно време, необичаен обем или достъп до нови ресурси. Актуализирайте договорите с доставчици за обработване на удостоверителни данни, подкрепа при инциденти и права на одит. Документирайте изключенията с одобрение от собственика на риска и дата на изтичане.

Политика за тестови данни и тестови среди Политика за тестови данни и тестови среди подкрепя разделянето на средите:

Интеграцията с CI/CD пайплайни трябва да налага разделяне на средите и удостоверителните данни за автентикация.

Тази клауза често е решаваща. Ако разработката, тестът и продукцията споделят тайни, среда с нисък риск може да се превърне в път към нарушение на продукционната среда.

Спринтът трябва да завърши с пакет доказателства, а не само със списък от констатации. Включете експорт на регистъра на NHI, записи от оценка на риска, план за третиране, съпоставяне с Декларацията за приложимост, препратки към политики, екранни снимки от трезора, журнали за ротация, одобрения от прегледи на достъпа, резултати от CI/CD сканиране за тайни, дефиниции на правила за мониторинг, матрица на отговорностите за удостоверителни данни на доставчици, наръчник за реагиране при инциденти и изключения със собственици и дати на изтичане.

Регистриране и откриване: доказване, че използването на машинни идентичности е видимо

Машинна идентичност, която е добре инвентаризирана, но невидима в журналите, остава опасна. Откриването е част от историята на контрола.

Политика за регистриране и мониторинг за МСП на Clarysec Политика за регистриране и мониторинг за МСП включва доказателства за автентикация:

Журнали за автентикация: успешни и неуспешни опити за вписване, продължителност на сесията, използване на MFA

За NHI адаптирайте това изискване към машинната автентикация. Може да нямате използване на MFA за идентичност на работно натоварване, но трябва да имате събития за автентикация, използване на токени, използване на сертификати, метаданни за API повиквания, изходно работно натоварване, целева услуга, срок на живот на токена, събития при отказ и привилегировани действия.

В Zenith Controls контрол 8.2 по ISO/IEC 27002:2022, Права за привилегирован достъп, е свързан с регистриране и мониторинг, защото привилегированите акаунти изискват подробни записи и надзор. Zenith Controls също свързва 8.2 с управление на идентичности, права за достъп, ограничаване на достъпа до информация и сигурна автентикация. За одиторите това означава, че привилегированите машинни идентичности трябва да се преглеждат и наблюдават със същата сериозност като човешките администратори, понякога дори по-строго.

Добри въпроси за мониторинг включват:

• Автентикирал ли се е служебен акаунт от неочаквано работно натоварване или IP диапазон?
• Достъпил ли е API ключ нова крайна точка или набор от данни?
• Използван ли е сертификат след замяната му?
• Разгърнал ли е CI/CD токен извън одобрен пайплайн?
• Опитал ли е акаунт само за четене операции за запис?
• Станали ли са активни неактивни удостоверителни данни?
• Достъпила ли е интеграция с доставчик данни извън договорените часове или обеми?

Когато възникне предупреждението в 02:13, трябва да отговорите коя идентичност е използвана, коя тайна я е автентикирала, кои права за достъп са упражнени, кои данни или системи са засегнати, дали дейността е очаквана, кой собственик може да я валидира и дали са достигнати праговете за докладване на инцидент.

Погледът на одитора: един и същ процес, различни въпроси

Най-силната одитна позиция не е „ние спазваме всичко“. Тя е „ние управляваме един контролиран процес, който произвежда доказателства за множество задължения“. Различните одитори ще проверяват този процес по различен начин.

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

Всяка констатация се съпоставя естествено с контролите, политиките и шаблоните за коригиращи действия на Clarysec. По-важното е, че всяка може да бъде превърната в измерими доказателства в рамките на СУСИ.

Как Clarysec ви помага да постигнете готовност за одит

Подходът на Clarysec е практичен, защото започва с доказателствата, които одиторите ще поискат, и работи обратно към контроли, политики и оперативни практики.

В Zenith Blueprint, във фазата „Контроли в действие“, стъпка 19, Clarysec дава директни насоки за автентикация между машини:

При автентикация между машини, например чрез служебни акаунти или API повиквания, ключовете, сертификатите и токените трябва да бъдат защитени със същата строгост. Избягвайте вграждането на удостоверителни данни в код. Използвайте системи за управление на тайни или трезори, за да ги съхранявате и ротирате сигурно.

Типичният работен поток на Clarysec за машинни идентичности включва откриване на NHI в облачни среди, SaaS, CI/CD, хранилища, трезори и бази данни, оценка на пропуските в политиките спрямо комплектите политики за МСП или корпоративни политики на Clarysec, оценка на риска и съпоставяне на третирането по ISO/IEC 27001:2022, актуализации на Декларацията за приложимост, съпоставяне на доказателства за NIS2, DORA, GDPR и NIST CSF, дизайн на регистър на NHI, съгласуване с Регистъра за управление на ключове, сканиране за тайни, процеси за преглед на достъпа, матрици на отговорностите за удостоверителни данни на доставчици, наръчници за реагиране при инциденти и одитни пакети с екранни снимки, експорти, журнали, одобрения и записи за изключения.

За МСП подходът е пропорционален. Доставчик на SaaS със 70 души не се нуждае от същия набор инструменти като глобална банка, но се нуждае от собственост, политика, третиране на риска и доказателства. За регулирани финансови субекти и доставчици на ИКТ същият модел се мащабира към картиране на критични функции по DORA, управление на риска от трети страни и тестване на устойчивостта.

Ако следващият ви одит е през 2026 г., не чакайте одиторът да открие машинните идентичности вместо вас. Започнете с една критична услуга и задайте пет въпроса:

1. Знаем ли всеки служебен акаунт, API ключ, токен, сертификат и CI/CD тайна, използвани от тази услуга?
2. Има ли всяка NHI именуван собственик, попечител, цел и рискова оценка?
3. Съхраняват ли се тайните в трезор, ротират ли се и защитени ли са от изходен код, документи, имейли и съхранение в открит текст?
4. Преглеждат ли се привилегированите машинни идентичности, наблюдават ли се и ограничени ли са от интерактивна употреба?
5. Можем ли да създадем доказателства за ISO/IEC 27001:2022, NIS2, DORA и GDPR от един контролиран процес?

Използвайте Zenith Blueprint: 30-стъпкова пътна карта на одитора Zenith Blueprint, за да структурирате внедряването на вашата СУСИ. Използвайте Zenith Controls: Ръководство за кръстосано съответствие Zenith Controls, за да свържете идентичност, автентикация, привилегии, регистриране, криптография, сигурна разработка и контроли за доставчици по ISO/IEC 27002:2022 с регулаторни доказателства. Използвайте библиотеката от политики за МСП и корпоративни среди на Clarysec, включително Политика за управление на потребителски акаунти и привилегии за МСП Политика за управление на потребителски акаунти и привилегии за МСП, Политика за криптографски контроли Политика за криптографски контроли, Политика за сигурна разработка Политика за сигурна разработка и Политика за изискванията за сигурност на приложенията Политика за изискванията за сигурност на приложенията, за да превърнете добрите намерения в приложими изисквания.

Предупреждението в 02:13 ще се случи някъде. Въпросът е дали вашата организация може да отговори с доказателства кой е държал ключа, какво е отворил той, защо е съществувал и колко бързо можете да го обезопасите.