Директивата NIS2 налага преки задължения на организациите в областта на управлението на риска в веригата на доставки, докладването на инциденти и отговорността на ниво управителен съвет. Октомври носи нова вълна от законно обвързващи крайни срокове в целия ЕС, тъй като държавите членки преминават от транспониране към прилагане. В Австрия националният закон за прилагане влиза в сила след приемането му; в Полша задължителната саморегистрация приключва на фиксирана дата, определена от националния орган.

По-широкото несъответствие с NIS2 излага съществените субекти на глоби до 10 милиона евро или 2% от глобалния оборот, важните субекти — до 7 милиона евро или 1,4%, а управителните органи — на лична отговорност, включително временни забрани за заемане на ръководни роли.

Повечето организации знаят, че трябва да се съобразят. По-рудният въпрос е откъде да започнат, без да претоварят екипа преди първия одит.

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

Управлението на достъпа и хигиената на идентификационните данни отговарят и на трите критерия. Те няма да покрият всяко изискване на NIS2, но ще ви отведат по-далеч и по-бързо от почти всяка друга отделна инвестиция.

Защо идентификационните данни все още са критичната точка за блокиране

Докладът на Verizon за разследване на пробиви на данни за 2026 г. (Verizon Data Breach Investigations Report) установи, че експлоатацията на уязвимости е изпреварила откраднатите идентификационни данни като най-честия единичен вектор за първоначален достъп, представлявайки 31% от пробивите. Но премахването на приоритета от контрола на идентификационните данни на това основание би било грешно решение.

Собствените данни на DBIR показват различна картина, когато фокусът се измести отвъд рамката на първоначалния достъп. Злоупотребата с идентификационни данни, измерена по цялата верига на атаката, се появява в 39% от всички пробиви. Verizon изрично я определя като „легитимна цел за ограничаване на атаките“. Идентификационните данни не просто отварят предната врата; те са това, което атакуващите използват, за да се придвижват из сградата, след като влязат вътре.

Сравнете сроковете за изпълнение на две изисквания от член 21 на NIS2:

  • Управление на риска във веригата на доставки (Чл. 21(2)(d)) — 6–12 месеца
  • Прилагане на контрол на достъпа (Чл. 21(2)(i)) — 2–4 седмици

Прилагането на детайлна политика за пароли в Active Directory, мигрирането на споделени идентификационни данни в управляван трезор и активирането на устойчива на фишинг MFA за акаунти с повишени привилегии е проект за 2–4 седмици за компетентен екип. Възвръщаемостта на инвестициите от усилията за съответствие не може да се сравни.

Три пропуска в управлението на достъпа, които водят до неуспех при предварителни одити

Повечето дискусии относно управлението на достъпа по NIS2 се фокусират върху потребителите хора. Одиторите все по-често не правят това. Сервизните акаунти, API ключовете, низовете за връзка с бази данни и токените за внедряване са нечовешки самоличности и те обикновено остават неуправлявани по начини, които биха били неприемливи за който и да е човешки акаунт.

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

Член 21(2)(i) изисква политиките за контрол на достъпа да покриват всички акаунти с достъп до мрежови и информационни системи. „Всички акаунти“ включва сервизните акаунти. Ако не можете да ги опишете, не можете да ги контролирате и не можете да докажете контрол пред одит.

Решението започва с инвентаризация: извлечете всеки сервизен акаунт от AD, всеки API ключ от вашия хранилищен съд за тайни (или от конфигурационните файлове, където в момента са твърдо кодирани) и ги вкарайте в управлявана система с графици за ротация и документирани собственици.

Неактивният акаунт съществува, има валидни идентификационни данни и принадлежи на някой, който вече не се нуждае от достъп: бивш служител, изпълнител, чийто ангажимент е приключил, или доставчик, чийто проект е приключил преди шест месеца. Тези акаунти са пряка точка на неуспех при одит съгласно член 21(2)(i), който изисква политиките за контрол на достъпа да включват управление на жизнен цикъл.

Пропускът при прекратяване на достъпа почти никога не е злонамерен. Той е процедурен. Човешки ресурси затварят тикета, ИТ отделът деактивира акаунта в Active Directory и никой не проверява дали това лице е имало и директен достъп до база данни, VPN сертификат, AWS IAM потребител или SSH ключове на три производствени сървъра. Всеки от тях е отделен идентификатор, който трябва да бъде отнет. В повечето организации нито една отделна система не проследява всички тях.

Прегледите на достъпа трябва да бъдат документирани и износими. Одиторите изискват доклади с ясна история на прегледите, а не имейл преписки.

Член 21(2)(j) изисква MFA „когато е подходящо“. Насоките на ENISA и по-широката регулаторна посока ясно показват, че „подходящо“ покрива целия привилегирован достъп и целия отдалечен достъп до критични системи. SMS OTP вече не е достатъчен за тези контексти.

NIST SP 800-63B (раздел 5.2.10) изрично класифицира базирания на SMS OTP като ограничен автентикатор, цитирайки рисковете от SIM swapping и SS7 прихващане. Устойчивата на фишинг MFA, FIDO2/WebAuthn, хардуерните ключове за сигурност или автентикацията, базирана на сертификати, е стандартът, който издържа при проверка.

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

И трите пропуска споделят обща нишка: липсата на единна система, която проследява идентификационните данни, прилага политики за достъп и произвежда износими доказателства. Passwork адресира това директно:

  • Пароли на сервизни акаунти, API ключове и сертификати, съхранявани в самостоятелно хостван трезор с записи за собственост за всяка тайна и графици за ротация;
  • RBAC и AD/LDAP интеграция за управление на жизнения цикъл;
  • Поддръжка на WebAuthn и хардуерни ключове за сигурност за устойчива на фишинг MFA при достъп до трезора.
  • Одитният лог записва всяко действие с времеви отпечатъци, така че тримесечният преглед на достъпа се превръща в експорт на доклад, а не в ръчно упражнение.

Проблемът с доказателствата

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

Член 32 от NIS2 дава право на компетентните органи да изискват документация за внедрените мерки за сигурност. Документацията е текстът на политиката, техническият контрол, който я прилага, и лог, показващ, че контролът е бил активен и е генерирал събития.

За управление на идентификационните данни и достъпа одиторите очакват:

  • Политика за контрол на достъпа — писмена, с версии, одобрена от ръководството
  • Доказателства за техническо прилагане — настройки на задълбочени политики за пароли в AD, доклади за записване в MFA
  • Записи от прегледа на достъпа — кой е прегледал, кога, какво е било отнето
  • Инвентаризация на привилегированите профили с документация за собственост
  • Дневници за ротация на идентификационни данни за сервизни профили и API ключове
  • Записи от прекратяване на достъпа при напускане с времеви печати за завършване

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

Пет стъпки към съответствие при идентификационните данни

Опишете какво съществува: споделени профили, сервизни профили, API ключове и всички идентификационни данни, съхранявани извън управлявана система: електронни таблици, имейл, .env файлове. Тази инвентаризация е вашата отправна точка и вашият първи артефакт с доказателства.

Стъпка 2. Внедрете централизиран трезор за идентификационни данни.

Изберете решение, което поддържа AES-256 криптиране, RBAC и интеграция с AD/LDAP. Конфигурирайте структурата на трезора, така че да отразява вашата организационна йерархия. Самостоятелно хостваното внедряване ви осигурява суверенитет върху данните и удовлетворява вътрешните политики за сигурност, които забраняват съхраняването на идентификационни данни в облачни услуги на трети страни. Passwork е един пример за платформа, проектирана специално за този модел на внедряване — самостоятелно хоствана, с AES-256 криптиране, с RBAC и AD/LDAP интеграция готови за ползване.

Стъпка 3. Приложете MFA и достъп с най-малко привилегии.

Активирайте MFA за целия достъп до трезора от първия ден. Назначете права на ниво роля. Прилагайте принципа на най-малките привилегии: всеки потребител и сервизен профил получава достъп само до това, което изисква неговата функция. Документирайте матрицата на ролите, това е вашето доказателство за контрол на достъпа според Член 21(2)(i).

Стъпка 4. Мигрирайте неуправляваните тайни в трезора.

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

Стъпка 5. Конфигурирайте регистрирането на одиторски дневници и насрочете редовни прегледи.

Активирайте пълното регистриране на одиторски дневници и експортирайте доклад за съответствие веднага след внедряването. Насрочвайте тримесечни прегледи на достъпа: неактивни профили, роли с прекомерни привилегии, идентификационни данни, до които не е имало достъп от 90+ дни. Всеки цикъл на преглед произвежда датиран артефакт с доказателства, демонстриращ непрекъснато съответствие, точно каквото изисква прилагането на Член 32.

Откъде да започнете

Организациите, които ще се борят с одитите по NIS2, не са тези с несъвършена сигурност. Това са тези без доказателства. Докладът на IBM Cost of a Data Breach Report за 2026 г. определя глобалните средни разходи при пробив в сигурността на 4.99 милиона долара, а организациите, които овладяват пробивите по-бързо, са последователно тези с видимост за това къде се намират техните идентификационни данни.

По-трудните работни направления по NIS2 — риск във веригата на доставки, реагиране на инциденти, управление на ниво борд — трябва да се изпълняват паралелно. Но управлението на идентификационните данни е мястото, където получавате първата си доказана победа.

1. Поставете сервизните профили под управление. 2. Закрийте изостаналите неактивни профили. 3. Приложете устойчива на фишинг MFA върху привилегирования и отдалечения достъп. 4. Изградете инфраструктурата за регистриране в дневници, която превръща тези контроли в експортируеми доказателства.

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

Passwork е самостоятелно хостван мениджър на пароли и тайни, изграден за корпоративни среди — с включени AES-256 криптиране, RBAC, AD/LDAP интеграция и експортируеми одиторски дневници.