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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Много организации вече са внедрили такива решения.