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

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

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

Проблема возникает, когда пароль можно предсказать. Имена, даты рождения, названия компании, последовательности вроде 123456, qwerty или password удобны для запоминания, но по той же причине оказываются очевидными вариантами для проверки. Добавление одного символа не всегда принципиально меняет ситуацию: условный Password1! выглядит сложнее, но остаётся построенным по легко узнаваемому шаблону.

Для пользователя полезнее ориентироваться на достаточную длину и непредсказуемость пароля. Конкретные требования при этом устанавливает сама организация: если корпоративная система задаёт минимальную длину или другие правила, сотрудник должен следовать именно им.

Один пароль не должен открывать несколько дверей

Менее очевидная проблема — повторное использование одного пароля. Представим, что сотрудник использовал одинаковую комбинацию для корпоративной системы и стороннего интернет-сервиса. Если сторонний сервис будет скомпрометирован и учётные данные попадут к злоумышленникам, полученную пару логин–пароль могут попробовать использовать и в других системах.

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

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

Пароль нельзя передавать другому человеку

Уникальный и достаточно стойкий пароль теряет смысл, если его сообщить постороннему. Причём запрос необязательно будет выглядеть подозрительно: «Продиктуй пароль, я быстро проверю настройки», «Пришли доступ, пока ты в отпуске», «Мне нужно зайти под тобой и посмотреть ошибку».

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

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

Почему одного пароля может быть недостаточно

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

Именно поэтому во многих системах одного пароля недостаточно. После его ввода появляется второй шаг: например, подтверждение входа в приложении, ввод одноразового кода или использование аппаратного устройства. Здесь появляется понятие многофакторной аутентификации.

MFA тоже требует решения человека

Дополнительный фактор значительно меняет ситуацию, если пароль оказался известен постороннему. Но MFA не делает учётную запись автоматически защищённой при любых действиях пользователя. Человек по-прежнему участвует в процедуре аутентификации.

Представим, что Егор получает одно за другим несколько уведомлений с просьбой подтвердить вход. Сам он сейчас никуда не входит. Через некоторое время поступает звонок якобы из технической поддержки: «Мы устраняем ошибку, подтвердите последний запрос».

Нажатие кнопки в приложении в этом случае — уже не просто закрытие уведомления. Пользователь может фактически разрешить попытку аутентификации, которую инициировал другой человек.

Одноразовые коды — тоже средство доступа

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

Но именно в эту минуту код и представляет ценность. Если он предназначен для подтверждения входа или другой операции, его передача постороннему фактически помогает пройти соответствующий этап проверки.

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

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

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

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