Почему сложные пароли не спасают компанию: практическое руководство по парольной безопасности

Сцена 1: Компания вводит парольную политику: минимум 8 символов, обязательная цифра, заглавная буква, спецсимвол. Пароль нужно менять раз в 30 дней.

Сцена 2: У сотрудников появляются пароли формата Company2026!, меняющийся через месяц на Company2026@, а еще через месяц на Company2026#.

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

Сцена 4 содержит существенные финансовые потери для бизнеса и нервные потерию для руководителей и ИТ/ИБ команды.

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

Ниже — порядок, в котором, с моей точки зрения, имеет смысл разбирать эту задачу в компании.

С чего начать: посчитать не пароли, а учётные записи

Первый вопрос, который стоит задать ИТ и ИБ: какие учётные записи вообще существуют в нашей инфраструктуре?

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

Поэтому я бы начал с обычной инвентаризации.

Для каждой учётной записи должно быть понятно:

• кто её использует;

• зачем она нужна;

• к каким системам имеет доступ;

• какие права у неё есть;

• кто отвечает за неё;

• когда в последний раз она использовалась.

Особенно полезно сразу разделить аккаунты на обычные пользовательские, привилегированные, сервисные и внешние.

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

Самая неприятная категория — привилегированные аккаунты

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

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

Количество таких аккаунтов тоже должно быть ограничено. Если права Domain Admin есть у двадцати человек просто «на всякий случай», то фактически компания имеет двадцать потенциальных точек компрометации.

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

Для наиболее критичных систем имеет смысл идти дальше и ограничивать административный доступ по времени, рабочему месту или другим условиям.

Отдельный важный вопрос для проработки: “Можно ли обнаружить подозрительное использование привилегированной учётной записи?”.

Что делать с парольной политикой

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

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

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

А что со сменой пароля каждые 30 дней?

Автоматическая ротация через фиксированный короткий срок не всегда даёт тот эффект, которого от неё ждут.

Пользователь, которому приходится менять пароль каждый месяц, обычно не начинает каждый раз придумывать новый случайный секрет. Он модифицирует старый rabotaNeVolk1 или samayaKrasivaya!, добавляя или меняя один символ.

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

Отдельная задача — не допускать использование известных паролей

Есть большая разница между «пароль соответствует нашей политике» и «пароль действительно не скомпрометирован».

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

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

Где сотрудники хранят все эти пароли?

Теперь представим сотрудника, у которого есть доступ к двадцати корпоративным системам и настоятельное ИБ-предписание «Используй уникальные сложные пароли и никогда их не повторяй».

Если у такого сотрудника нет правильного с точки зрения ИБ ответа на этот вопрос нет (он может звучать, например, “В менеджере паролей ОдинКлюч”), парольная политика начинает работать против самой себя. В результате пароли появляются в браузерах, заметках, Excel-файлах, текстовых документах, мессенджерах и письмах. Именно поэтому ксистема хранения паролей — не просто удобный инструмент для сотрудников, а часть системы управления доступами.

Но здесь есть важный нюанс: администратор менеджера паролей не должен автоматически видеть все пароли.

При выборе решения я бы обязательно задавал поставщику этот вопрос: Что произойдёт, если учётная запись администратора менеджера паролей будет скомпрометирована?

Если ответ, в конечном счете, звучит как «администратор сможет получить доступ ко всем хранилищам», мы получаем очень привлекательную цель для злоумышленника.

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

При выборе решения я бы отдельно проверял:

• кто технически может получить доступ к секретам;

• как устроено шифрование (лучше, чтобы оно было на стороне клиента);

• где и как хранятся ключи;

• может ли администратор расшифровать чужое хранилище;

• как организован аудит действий;

• можно ли разделить административные полномочия;

• что произойдёт при компрометации административной учётной записи;

• как восстанавливается доступ при потере учётной записи пользователя.

Это один из тех случаев, когда архитектура продукта важнее красивого списка функций.

Сервисные аккаунты: про них вспоминают последними

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

Через несколько лет никто уже не знает:

• кому он принадлежит;

• зачем он нужен;

• где используется;

• кто знает его пароль;

• что произойдёт, если его отключить.

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

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

Особенно опасно хранить сервисные секреты непосредственно в исходном коде, скриптах и репозиториях.

MFA: начинать нужно не с самых удобных систем, а с самых опасных

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

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

И здесь тоже есть нюанс: MFA сама по себе не является магическим щитом. Нужно защищать и сам процесс восстановления доступа, резервные методы аутентификации и аккаунты, которые могут отключить MFA. Ну и отдельная песня про второй фактор, легко отображающийся на том же устройстве, где вводится первый (обычно —  пароль).

Общие аккаунты — плохая идея не только с точки зрения безопасности

Представим, что пять системных администраторов используют одну учётную запись. В какой-то момент в журнале появляется: “14:32 — изменена конфигурация сервера”. Кто это сделал?

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

Жизненный цикл учётной записи важнее самой политики

Можно иметь прекрасную парольную политику и при этом оставить бывшему сотруднику доступ к VPN. Это довольно бессмысленная защита. Поэтому парольная безопасность должна быть связана с процессами HR и ИТ.

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

Особенно важно не забывать о подрядчиках. Их аккаунты должны иметь срок действия и понятного владельца. Чем больше операций выполняется вручную, тем выше вероятность ошибки. Поэтому отзыв доступа по возможности стоит автоматизировать (если я тут еще раз упомяну про менеджер паролей ОдинКлюч, это не будет выглядеть слишком навязчиво?).

Что измерять директору по ИБ

Если эти показатели постепенно улучшаются, работа идёт в правильном направлении.

Что делать в ближайшие 30 дней

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

Сегодня

Настроить мониторинг важных параметров безопасности учетных данных, в том числе:

• доля критичных систем с MFA;

• количество привилегированных аккаунтов;

• количество неиспользуемых аккаунтов;

• доля сотрудников, работающих через корпоративный менеджер паролей;

• количество секретов, найденных в открытом виде;

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

• количество обнаруженных скомпрометированных корпоративных учётных данных.

Первая неделя

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

Вторая неделя

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

Третья неделя

Пересмотреть парольную политику. Выбрать подход к централизованному хранению секретов. Определить требования к корпоративному менеджеру паролей (в этой статье есть несколько стоящих рекомендаций) и запустить процесс выбора. Отдельно проверить модель защиты от доступа администратора к пользовательским секретам.

Четвёртая неделя

Перевести критичные учётные записи на новые правила. Запустить ротацию наиболее важных административных и сервисных секретов. Определиться с решениями по управлению паролями и секретами.

В итоге

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

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

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

И только в этой системе требования к длине пароля становятся одной из деталей, а не всей парольной безопасностью компании.