С чего начать, когда бюджет ограничен

Бюджеты на информационную безопасность редко охватывают полную программу NIS2 за раз. Управление учётными данными — это точка, с которой может начать небольшая команда. Оно делает доступ видимым, отзываемым и проверяемым без новой инфраструктуры. По статье 21 NIS2 требует мер управления рисками, соответствующих риску, который организация действительно несёт. Выбор конкретных продуктов и политик остаётся за этой оценкой.

В отчёте Verizon 2026 Data Breach Investigations Report учётные данные оказались в числе скомпрометированных данных в 28% взломов. Это делает управление учётными данными естественной первоочередной целью для любой программы, основанной на оценке рисков.

Здесь рассмотрены семь контролей доступа, ранжированные по затратам труда, и показано, какие доказательства каждый из них производит для руководства безопасностью, аудиторов или органов государственного надзора.

Кому нужно соответствие NIS2

NIS2 применяется к организациям среднего и крупного размера в 18 критических секторах, определённых Европейской комиссией. Применимость для конкретной организации зависит от сектора, размера и национального внедрения директивы. Такое определение должно производиться юридическим отделом и с опорой на официальное руководство.

Видимость учётных данных и контроль над ними приносят практическую пользу независимо от того, завершена ли эта оценка или ещё в процессе. Семь контролей ниже применимы в обоих случаях.

Что требует NIS2 для безопасности учётных данных

Статья 21 связывает безопасность учётных данных с пятью мерами: базовая гигиена кибербезопасности и обучение, политики контроля доступа, безопасность при работе с кадрами, управление активами, и процедуры проверки эффективности контролей. Эти пять мер дают организациям свободу выбора инструментов и политик, масштабированных под их риски.

Программа безопасности учётных данных отвечает на четыре вопроса:

  • кто имеет доступ;
  • почему он его имеет;
  • как удаляется доступ;
  • как организация доказывает работоспособность контроля.

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

Инвентаризация, назначенный владелец и цикл проверки охватывают эту начальную работу. Более широкая архитектура идентификации может последовать позже. Это означает политики, которые большинство команд уже знают: сложность учётных данных, соответствующая риску системы, ротация после взлома или смены роли, удаление стандартных паролей поставщика перед развёртыванием.

Большинство команд пропускают доказательство работоспособности контролей: политика без логов, без даты проверки и без записей об исключениях не удовлетворит аудитора. Построение тропы доказательств по мере внедрения каждого контроля, а не её восстановление перед аудитом, делает объём работы пропорциональным размеру команды.

Требует ли NIS2 многофакторную аутентификацию

Статья 21(2)(j) называет многофакторную аутентификацию (MFA) или решения непрерывной аутентификации мерой, применяемой «в надлежащих случаях», оставляя каждой организации судить, где риск оправдывает контроль. Эта формулировка масштабирует MFA к конкретным системам, а не применяет её ко всем учётным записям. Внешние приложения, удалённый сетевой доступ и привилегированное администрирование несут наибольший риск компрометации учётных данных и получают MFA в первую очередь. Статья 21 также поручает организациям взвешивать стоимость внедрения при оценке соразмерности, что даёт небольшим командам обоснованное основание для последовательного развёртывания вместо единовременного развёртывания везде.

В анализе Verizon 2026 года 7513 проблем с утечкой облачной MFA половина была устранена в течение одного месяца; проблемы со слабыми паролями и неправильной конфигурацией разрешений потребовали почти восьми месяцев для достижения этого же показателя.

Семь шагов, ранжированные по приоритету

Начните с создания видимости привилегированного и общего доступа, с его отзывом и проверяемостью. Последовательность ниже ранжирует семь контролей доступа по затратам труда и показывает первое действие и доказательства для каждого. Это предлагает приоритизированную отправную точку; полная оценка рисков и юридический анализ остаются основой для любого определения соответствия.

Общие и сервисные учётные данные

Общие учётные данные — это задача управления перед тем, как быть технической. Пароль, брошенный в чат или таблицу, не имеет чёткого владельца, пути избирательного отзыва и записи о том, кто и когда его использовал.

Представьте окончание контракта подрядчика: удаление его отдельной учётной записи ничего не делает с общим паролем администратора, который он знал. Пароль остаётся действительным вне организации до тех пор, пока кто-то его не изменит. Депровизионирование должно сопровождаться ротацией каждого секрета, к которому человек мог получить доступ.

Токены конвейера CI/CD, оставленные в файле .env или переменной конвейера, доступны для чтения любому, кто может редактировать эту конфигурацию, и часто пережить сотрудника, который его создал. Изоляция его в отдельной записи хранилища, принадлежащей команде платформы, а не отдельному лицу, и его плановая ротация закрывает разрыв.

Как начать с инвентаризации

Следующий шаг конкретен: на этой неделе создайте инвентаризацию привилегированных учётных записей в первом шаге, потому что каждый последующий контроль зависит от знания того, что вы защищаете.

Если команде нужно переместить общие учётные данные из таблиц и чатов, оцените требования к хранилищу учётных данных, управление доступом через каталог и журналы аудита в соответствии с требованиями статьи 21 для доказательства.