Журнал учёта выдачи первичных паролей ИСПДн
Форма, в которой фиксируется передача первичного пароля работнику: кому, когда, кем выдан, каким способом передан и — главное — когда пользователь его сменил.
Зачем нужен документ
Персональная учётная запись имеет смысл ровно до тех пор, пока пароль от неё знает один человек. Но начинается любая запись иначе: администратор задаёт первичный пароль и передаёт его работнику. В этот момент секрет знают двое, и все построения о персональной ответственности временно не работают.
Журнал существует, чтобы у этого промежутка была видимая граница. Ключевая графа в нём — не «выдан», а «сменён пользователем»: именно она отмечает момент, с которого действия в системе можно вменить владельцу записи, а не любому из двоих.
Отсюда практический вывод, который часто удивляет: журнал, где есть дата выдачи и нет даты смены, не решает задачу вообще. Он фиксирует начало проблемы и молчит о её окончании — а окончание и есть то, ради чего документ заводили.
Чем грозит отсутствие
Прямого штрафа за отсутствие журнала нет. Опаснее другое: утечка первичного пароля не оставляет следов и потому не обнаруживается. А необнаруженный инцидент превращается в несостоявшееся уведомление регулятора — и вот за это санкция предусмотрена отдельно.
Как ещё называют этот документ
Что должно быть в документе
Журнал компактный: семь-восемь граф. Критерий полноты — по строке видно, закрылся ли промежуток совместного знания пароля и когда именно.
Требования законодательства
Как связан с другими документами
Журнал замыкает контур учётных записей: три документа пачки описывают правила, этот фиксирует единственный момент, где правила можно нарушить незаметно.
Когда обновлять документ
Сама форма меняется редко — обычно тогда, когда меняется способ выдачи пароля или состав систем.
Что спросит проверяющий
Журнал смотрят не целиком, а выборочно: берут несколько строк и проверяют, чем они заканчиваются.
Разбор эксперта
Журнал выдачи паролей выглядит самой мелкой позицией комплекта, и именно поэтому его заводят формально: три графы, дата, подпись. Между тем он закрывает вполне конкретную дыру. Всё построение с персональными учётными записями держится на утверждении «пароль знает один человек». В момент выдачи это утверждение ложно, и журнал — единственное место, где видно, когда оно снова стало истинным. Если графы о смене нет, то и ответа нет: администратор знает рабочие пароли половины организации, а в журнале это выглядит как порядок.
Второе, что мы советуем продумать заранее, — способ передачи. Здесь работает простая мысль: канал, который сохраняет сообщение, сохраняет и пароль. Письмо остаётся в почтовом ящике, сообщение — в истории чата, и через год оба доступны любому, кто получит доступ к переписке. Причём такая утечка не порождает ни одного подозрительного события: вход выполняется под настоящей записью с правильным паролем. Мы рекомендуем либо личную передачу, либо одноразовые ссылки, которые перестают работать после первого открытия.
И третье — про одинаковые первичные пароли. Соблазн понятный: администратору проще держать в голове одну комбинацию для всех новичков. Результат — секрет, который знает вся организация, причём знает пожизненно, потому что новые люди приходят постоянно. Если делать журнал ради галочки не хочется, начните с этого пункта: уникальный первичный пароль каждому и обязательная смена при первом входе. Дальше журнал уже работает сам.
Заводите графу «пароль сменён пользователем» и относитесь к пустым клеткам как к открытым задачам, а не как к архиву. Уникальный первичный пароль каждому работнику. Передача — лично или одноразовой ссылкой, но не письмом и не сообщением в чате. Если система умеет требовать смену пароля при первом входе, включите эту настройку: тогда графа закрывается автоматически, и человеческий фактор из процедуры уходит совсем.
Александр КеллерманнГенеральный директор, ведущий аудитор ISO/IEC 27001, Комитет по информационной и правовой безопасностиПодробнее об экспертеЧастые вопросы
Прямого требования в законе нет — есть требование управлять средствами аутентификации. Журнал остаётся простейшим способом подтвердить, что управление реально существует, а не описано на бумаге.
Можно, если фиксируются автор записи и дата, а сам файл защищён от редактирования задним числом. Хранить его в общей папке нельзя: журнал показывает, кто и когда получал доступ.
Это лучший вариант. Графа смены заполняется по данным системы, а журнал сохраняет остальные сведения: кому, когда и каким способом передан пароль.
Одноразовой ссылкой, которая перестаёт работать после открытия, либо по отдельному от логина каналу. Письмо и мессенджер хранят сообщение неограниченно долго — этого достаточно, чтобы считать пароль скомпрометированным.
Категорически нет. Журнал фиксирует факт выдачи, а не значение пароля: документ со списком действующих паролей — это уже не мера защиты, а её противоположность.
Той же строкой, но с другим основанием: не первичная выдача, а восстановление доступа. Отдельный журнал заводить не нужно.
Срок оператор устанавливает сам, разумный ориентир — не менее трёх лет: этого хватает, чтобы разобрать инцидент и подтвердить порядок выдачи при проверке.
Проверить, работают ли ещё эти учётные записи, и принудительно сменить пароли. Незакрытая строка означает, что администратор до сих пор знает рабочий пароль пользователя.