Как обеспечить принудительное применение MFA во всей организации Google Workspace

Многофакторная аутентификация — это защитная мера с наивысшей отдачей, которую может внедрить практически любая организация, а в Google Workspace она называется двухэтапной аутентификацией (2-Step Verification, 2SV). Загвоздка в слове *принудительное*. Сделать MFA доступной — легко и по большей части бесполезно: учетные записи, наиболее вероятно подверженные атаке, реже всего подключают ее добровольно. Реальная защита достигается через принудительное применение — требование включить 2SV для всей организации, с правильными факторами и таким внедрением, которое никого не заблокирует. Эта статья — как раз такой план внедрения.

Почему «доступно» — это не «обязательно»

Если 2SV опциональна, ее внедрение идет по пути наименьшего сопротивления: технически подкованные и заботящиеся о безопасности сотрудники подключают ее, а занятые руководители и учетные записи, близкие к сервисным, — нет. Злоумышленники это знают. Атаки через фишинг учетных данных и повторное использование паролей нацелены именно на те аккаунты, которые пропустили подключение. Опциональная мера защищает как раз тех, кому она нужна меньше всего.

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

Выбирайте факторы осознанно

Не все вторые факторы равноценны. От самых надежных к самым слабым:

• Passkeys и аппаратные ключи безопасности (FIDO2). Устойчивы к фишингу: они криптографически привязаны к легитимному сайту, поэтому фишинговая страница не может их ретранслировать. Золотой стандарт, настоятельно рекомендуемый для администраторов и других ценных учетных записей.
• Google prompt / приложение-аутентификатор (TOTP). Существенное улучшение по сравнению с паролями, но целеустремленный набор инструментов для фишинга в реальном времени способен ретранслировать одноразовый код. Хороший вариант для остальных пользователей.
• SMS-коды. Лучше, чем ничего, но уязвимы к SIM-свопингу и перехвату. Приемлемы в качестве резервного варианта, но не как основной фактор.

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

Поэтапное внедрение без блокировок

Опасение, которое тормозит принудительное внедрение MFA, — риск заблокировать людей. Разбейте внедрение на этапы, чтобы устранить этот риск:

1. Сначала сообщите. Расскажите организации, что меняется, почему и к какому сроку. Предоставьте инструкции по подключению. Внезапное принудительное включение порождает обращения в службу поддержки и недовольство.
2. Откройте окно для подключения. Включите 2SV как доступную опцию и установите крайний срок. Отслеживайте прогресс подключения, чтобы видеть, кто еще не подключился.
3. Подтолкните отстающих. По мере приближения крайнего срока напоминайте тем, кто еще не подключился. Именно на этом этапе подключается большая часть «длинного хвоста».
4. Включите принудительное применение с льготным периодом для новых пользователей. Включите принудительное применение, но настройте льготный период для вновь созданных учетных записей, чтобы адаптация не блокировалась при первом входе.
5. Раздайте резервные варианты. Убедитесь, что у пользователей есть резервные коды или зарегистрирован второй фактор, чтобы потерянный телефон был мелким неудобством, а не блокировкой.
6. Обрабатывайте исключения точечно. Некоторые сервисные или общие учетные записи действительно могут испытывать трудности с интерактивной 2SV. Переведите их на более подходящую модель аутентификации (ключи сервисных учетных записей, выделенная обработка), а не встраивайте широкие исключения в политику для пользователей.

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

Типичные ошибки

• Освобождение руководителей «для удобства». Самые ценные учетные записи — худший кандидат на исключение. Наоборот, к ним стоит применять *самые* строгие факторы.
• Разрешение только SMS. Формально требование выполнено, но дверь для SIM-свопинга остается открытой. Настаивайте на факторах на основе приложений или аппаратных ключей.
• Забытые сервисные и общие учетные записи. У них часто есть значительный доступ, а интерактивная аутентификация обходится стороной. Управляйте ими осознанно — см. обнаружение рискованных ИИ-агентов и сервисных учетных записей.
• Отношение к этому как к разовому действию. Новые учетные записи, новые исключения и дрейф политики означают, что принудительное применение требует периодической проверки, а не однократного переключателя.

Проверяйте применение — не предполагайте

Включить политику и убедиться, что она *действительно применяется к каждой учетной записи*, — это две разные вещи. Учетные записи, созданные до введения политики, находящиеся в освобожденном организационном подразделении или попавшие в льготный период, могут незаметно оказаться вне зоны действия правила. Часть здоровой практики безопасности Google Workspace — и мера, которую аудиторы SOC 2 конкретно проверяют в рамках CC6.1, — это проверка того, что принудительное применение MFA действует во всей организации, а не только того, что переключатель включен.

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

Работа со сложными случаями

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

• Руководители и VIP-пользователи. Они — главные цели фишинга и чаще всего просят исключение. Применяйте к ним самые строгие факторы, а не освобождайте от требований. Скомпрометированная учетная запись руководителя — один из худших возможных исходов; удобство того не стоит.
• Общие почтовые ящики и ролевые учетные записи. Интерактивная 2SV подходит для отдельного человека, но не для почтового ящика, которым пользуются пятеро. Перестройте их как делегированный доступ к индивидуально защищенным учетным записям, чтобы защита следовала за реальными людьми.
• Сервисные и автоматизированные учетные записи. Им вообще не следует выполнять интерактивные входы. Аутентифицируйте их с помощью отдельно управляемых учетных данных сервисных аккаунтов и управляйте ими как теми нечеловеческими идентичностями, которыми они являются.
• Полевой персонал и сотрудники «на передовой». Людям без смартфона или с ограниченной связью нужен работающий фактор — аппаратные ключи или резервные коды, — спланированный заранее до дня внедрения, а не импровизированный на ходу службой поддержки.

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

После внедрения: поддерживайте принудительное применение

Внедрение — это не финишная черта. Новые учетные записи, новые организационные подразделения и разовые исключения — все это создает пути, по которым покрытие может ослабнуть. Встройте регулярную проверку в свою рутину: убедитесь, что 2SV по-прежнему принудительно применяется во всех организационных подразделениях, что ни одно исключение незаметно не стало постоянным и что строгие факторы по-прежнему требуются там, где вы их требовали. Даже самая надежная мера защиты в мире ослабевает, если никто не проверяет, что она все еще действует, — а утверждение «мы обеспечиваем принудительное применение MFA» должно быть тем, что вы можете доказать, а не тем, на что вы надеетесь.

8200.dev проверяет конфигурацию администратора вашего Google Workspace — включая принудительное применение двухэтапной аутентификации, настройки общего доступа и аутентификацию электронной почты — и отмечает отклонения со ссылками прямо на нужную настройку. Узнайте как это работает.

Хотите убедиться, что MFA действительно применяется везде? Начните бесплатный аудит безопасности и получите оценку состояния идентификации и конфигурации вашего Google Workspace.