Аргументы в пользу корпоративного менеджера паролей - просто
После очередного года крупных утечек учётных данных аргумент в пользу корпоративного менеджера паролей - уже не технический. Это аргумент управления операционным риском.
2016-й стал ещё одним рекордным годом по краже учётных данных. Взлом LinkedIn 2012 года оказался связан со 117 миллионами аккаунтов - это выяснилось только в этом году. Yahoo в сентябре сообщил об утечке 500 миллионов аккаунтов в 2014 году. Dropbox подтвердил взлом 2012 года с 68 миллионами пострадавших пользователей. Паттерн ясен: учётные данные, украденные годами ранее, всё ещё используются, продаются и применяются повторно.
В этом контексте я продолжаю вести один и тот же разговор с клиентами о корпоративном управлении паролями. Разговор должен быть простым, но часто таковым не является - потому что «менеджер паролей» звучит как базовая IT-гигиена, а не управление рисками. Я хочу переформулировать это.
Как выглядит реальный риск
Риск - не в том, что сотрудник использует слабый пароль для критической системы. Это плохо, но локально.
Более высокий риск - повторное использование учётных данных в разных системах. Сотрудник использует один и тот же пароль для рабочей почты, SaaS-инструмента и личного аккаунта на сервисе, взломанном два года назад. Учётные данные из той старой утечки всплывают, тестируются на рабочей почте - и срабатывают. Ничего в вашей инфраструктуре не сломалось. Вектор атаки был полностью внешним.
Это именно тот паттерн взломов, который доминировал в 2016 году. Он называется «подстановка учётных данных» (credential stuffing) и не требует никакой технической сложности в исполнении.
Что на самом деле решает корпоративный менеджер паролей
Грамотно внедрённый менеджер паролей для команды решает три вещи.
Первое - делает уникальные пароли практичными. Без менеджера просить сотрудников поддерживать 40 уникальных сложных паролей - значит просить их делать что-то действительно трудное. С менеджером это изменение привычки средней сложности, а не испытание памяти.
Второе - создаёт процесс ротации и отзыва. Когда сотрудник уходит, общие учётные данные сервисов, хранящиеся в менеджере, можно аккуратно сменить. Без этого оффбординг неполный: вы убираете доступ там, где знаете что искать, но не обязательно везде.
Третье - даёт команде безопасности видимость. В большинстве корпоративных менеджеров паролей есть журналы аудита. Можно видеть, какие учётные данные используются, были ли они расшарены и когда менялись в последний раз. Без этого вы работаете вслепую.
Возражения, которые я слышу
«У нас маленькая команда, это корпоративный продукт». У большинства вендоров менеджеров паролей есть планы для малого бизнеса. Стоимость на место достаточно низкая, чтобы экономия от предотвращения одного инцидента с учётными данными легко её оправдывала.
«У нас для всего есть SSO». Почти наверняка - не для всего. Всегда есть длинный хвост SaaS-инструментов, сторонних порталов и консолей доступа к вендорам за пределами зонтика SSO. Менеджер паролей покрывает именно этот хвост.
«Сотрудники не будут им пользоваться». Это настоящее возражение. Внедрение требует политики, а не просьбы. Если политика говорит, что общие учётные данные сервисов должны храниться в менеджере - внедрение следует само.
Отправная точка
Проведите аудит общих учётных данных, которые ваша команда сейчас использует: рассылает по почте, хранит в таблицах, держит в заметках. Составьте список каждого сервиса. Этот список и есть масштаб проблемы. Затем выберите инструмент и перенесите в него этот список. Техническая работа невелика. Работа с политикой и привычками - вот где большая часть усилий.