Отвечая на вопросы пользователей сервиса 152DOC, мы готовим максимально развернутые и обоснованные ответы. Некоторыми из них просто не можем не поделиться со всей нашей аудиторией.
Недавно с клиентом мы обсуждали такие вопросы по ведению Журнала учета первичных паролей (далее – Журнал), входящего в комплект ОРД сервиса:
- Обязателен ли такой Журнал, какими НПА предусмотрено его ведение?
- По Инструкции парольной защиты сервиса 152DOC пользователь ИСПДн должен изменить первичный пароль. С учетом этого возникает вопрос: какая практическая польза такого Журнала? Для чего могут когда-нибудь потребоваться первичные пароли, которые в дальнейшем были уже изменены?
- Вести бумажный Журнал неудобно, а реализовать его в электронном виде в той форме, которая есть, проблематично. Можно ли фиксировать это не Журналом, а, например, в докладной/служебной записке? В ней можно указать, что сотруднику предоставлен доступ в конкретную систему и выдан первичный пароль. При этом сам пароль в докладной/служебной записке не записывать.
В статье вы найдете ответы на эти вопросы.
Обязательность Журнала учета первичных паролей
Прямого требования вести именно журнал регистрации первичных паролей как отдельный обязательный документ в федеральном законодательстве нет. Однако ведение такого журнала вытекает из совокупности требований:
- Постановление Правительства РФ № 1119 от 01.11.2012. Оно устанавливает необходимость определения угроз безопасности информации и выбора мер по их нейтрализации.
- Приказ ФСТЭК России № 21 от 18.02.2013. В составе базового набора мер защиты для всех уровней защищенности предусмотрена мера УПД.4 («Управление средствами аутентификации»). Она требует управления выдачей, использованием, хранением и отзывом паролей. Журнал сервиса 152DOC — это классический инструмент реализации этой меры на практике.
Таким образом, журнал не обязателен прямым текстом закона. Однако он является наиболее простым и проверяемым способом доказать регулятору, что вы действительно управляете паролями. Иными словами, вы можете подтвердить, что не раздаете их бесконтрольно.
Практическая польза журнала и почему недостаточно служебной записки без записи самого пароля. Инструкция пользователя изменить пароль после первого входа решает задачу личной гигиены сотрудника, но не закрывает потребности администрирования и расследования инцидентов. Служебная записка вида «пароль выдан, сам пароль не записывал» имеет нулевую доказательную ценность.
Практическая польза ведения полноценного журнала или его электронного аналога:
| Ситуация | Зачем нужен зафиксированный первичный пароль |
| Расследование инцидента | Если сотрудник совершил правонарушение в системе до того, как сменил пароль, следствие должно точно знать: кто еще мог зайти под этой учетной записью? Если первичный пароль знал только админ и пользователь (что зафиксировано в журнале с подписью последнего), круг подозреваемых сужается. Если же пароль знали все системные администраторы отдела, ответственность размывается. |
| Разблокировка заблокированной учетной записи | Пользователь трижды неверно ввел новый пароль, и штатная разблокировка через SMS/e-mail недоступна (например, номер телефона не привязан или корпоративная почта еще не настроена). Администратор сбрасывает пароль к первоначальному значению. Чтобы выдать его пользователю безопасным способом, администратор берет данные из журнала. |
| Контроль дисциплины | Журнал подтверждает факт передачи ответственности. Подпись пользователя напротив выданного пароля означает, что с этого момента любые действия в системе совершены им лично. Это исключает аргумент «я ничего не настраивал, мне просто дали доступ». (забери символ 152DOC) |
| Аудит доступа привилегированных пользователей | Проверка регулятора может касаться действий самих системных администраторов. Журнал показывает, кому, когда и какой уровень доступа был предоставлен. |
| Восстановление цепочки событий | При компрометации системы анализ логов покажет входы под первичной учетной записью. Журнал поможет сопоставить этот технический след с конкретным человеком и временем его ознакомления с доступами. |
Почему нельзя обойтись одной лишь служебной запиской без пароля:
- Отсутствие доказательств контроля: Записка фиксирует намерение предоставить доступ, но не доказывает, что пароль был уникальным, сложным и известным ограниченному кругу лиц.
- Невозможность аудита: При расследовании инцидента невозможно восстановить состояние системы на момент выдачи доступа.
- Нарушение принципа прослеживаемости: Регуляторы требуют подтверждения каждого этапа жизненного цикла учетной записи. Выдача пароля — ключевой этап.
Таким образом, каждый документ сервиса 152DOC продуман и введение его в состав ЛНА обоснован, позволяет закрыть те или иные требования закона, снизить риски нарушения и помогает правильно выстроить процессы обработки ПДн, их защиты и учета действий с ними.
Альтернативные процессы организации
Чтобы избежать хранение критических данных в бумажном виде, вместо классического прошитого журнала, возможно использование одного из вариантов:
- Электронный журнал заявок в Service Desk / Jira: Заявка на создание учетки -> автоматическая генерация сложного пароля -> запись ID заявки, даты, ФИО выдавшего и получившего, хэш-суммы пароля (если политика позволяет) или факта отправки во временный приватный канал. Бумажный листочек с паролем исключается полностью.
- Специализированное ПО (PAM-системы): Система сама генерирует пароль, выдает его пользователю на время сессии, скрывает от администратора и принудительно меняет сразу после использования.
- Автоматизированная рассылка: Пароль генерируется системой, зашифровывается и отправляется сотруднику на личную почту или в закрытый чат одновременно с уведомлением службы безопасности. В этом случае в журнале фиксируется не сам пароль, а идентификатор транзакции рассылки.
Мы всегда готовы отвечать на вопросы пользователей, учитывать их потребности и развивать сервис 152DOC под запросы наших клиентов, предлагать альтернативные пути решения проблемы