Пароля Snowflake уже недостаточно: как закрыть входы людей и сервисов
Чтобы включить обязательную MFA в Snowflake и не остановить интеграции, сначала разделите человеческие и служебные учётные записи. Людям с локальным паролем нужен второй фактор; при едином входе сильную проверку обычно применяет поставщик удостоверений. Сервисы следует перевести на способ, не требующий пароля и действий человека.
Не назначайте одну политику всему аккаунту сразу. Сначала проведите инвентаризацию, затем испытайте вход небольшой группой пользователей, отдельно переключите каждую интеграцию и проверьте веб-интерфейс, командную строку и используемые драйверы. До массового включения подготовьте независимый аварийный доступ.
Разделите пользователей до изменения политики
Получите список пользователей командой SHOW USERS и сопоставьте его с историей входов, конфигурациями приложений и владельцами интеграций. Для каждой записи зафиксируйте назначение, владельца, роли, текущий способ аутентификации и используемые клиенты. Имя, похожее на имя сотрудника, не доказывает, что учётная запись не обслуживает старый сценарий или планировщик.
Разнесите записи как минимум по четырём группам: люди с локальным паролем, люди с SSO, сервисы с паролем и сервисы с беспарольным входом. Отдельно отметьте привилегированных пользователей, аварийные записи и учётные записи без известного владельца. Неизвестные записи не удаляйте и не переключайте автоматически: сначала найдите их потребителей по журналам подключений.
Назначение должно быть отражено и в типе пользователя: TYPE=PERSON для человека и TYPE=SERVICE для приложения. План отказа Snowflake от однофакторных паролей предусматривает второй фактор для людей, входящих с паролем, и запрет паролей для служебных пользователей; переходный тип LEGACY_SERVICE постепенно выводится из эксплуатации. Исключения существуют для отдельных видов аккаунтов, поэтому фактический этап внедрения следует проверять в уведомлениях конкретного аккаунта.
Внедрите MFA для парольных входов
Создайте политику аутентификации с MFA_ENROLLMENT=REQUIRED и сначала назначьте её пилотным пользователям. Если нужно ограничить допустимые вторые факторы, задайте их через MFA_POLICY: Snowflake поддерживает ключи доступа, приложения с одноразовыми кодами и Duo. Snowsight должен оставаться среди разрешённых типов клиентов, поскольку именно там пользователь регистрирует второй фактор.
Не переключайте одновременно всех администраторов. Один администратор применяет политику к тестовой записи, другой входит в новой сессии и проверяет, что может отменить изменение. После этого расширяйте охват партиями, фиксируя состав каждой партии, время переключения и ответственного за откат.
Документация Snowflake по MFA указывает, что этот способ предназначен прежде всего для людей с парольной аутентификацией; Snowflake CLI, SnowSQL, JDBC, Node.js и ODBC поддерживают такой вход, но конкретные функции и кэширование токенов зависят от версии клиента. Поэтому успешная регистрация фактора в браузере ещё не подтверждает работоспособность старого драйвера.
Оставьте MFA для SSO у поставщика удостоверений
При едином входе Snowflake по умолчанию полагается на поставщика удостоверений, который применяет MFA или другой метод сильной проверки. Дополнительную MFA внутри Snowflake можно потребовать отдельной политикой, но это уже двойная проверка. Вводить её следует только по осознанному требованию безопасности, а не как автоматическое продолжение настройки SSO.
Для Microsoft Entra сначала добавьте тестового пользователя в корпоративное приложение Snowflake, сопоставьте корпоративный идентификатор с LOGIN_NAME и проверьте вход по инициативе Snowflake и по инициативе поставщика удостоверений. Инструкция Microsoft по интеграции со Snowflake рекомендует отключать локальные учётные данные только после проверки и развёртывания SSO, чтобы входы проходили через политики условного доступа и MFA в Entra.
Удаляйте локальные пароли партиями, а не одновременно с созданием интеграции. Для каждой партии проверьте обычного пользователя, администратора и пользователя с несколькими ролями. Если применяется автоматическое предоставление доступа, убедитесь, что оно не создаёт дубликаты из-за различий между корпоративным идентификатором и LOGIN_NAME.
Переведите сервисы на беспарольный вход
MFA не подходит процессу без человека: запрос подтверждения остановит задачу до ручного вмешательства. Создавайте такие записи с TYPE=SERVICE, назначайте только необходимые роли и не используйте личную учётную запись разработчика как техническую.
Для облачной нагрузки сначала оцените федерацию удостоверений рабочей нагрузки: приложение использует собственное удостоверение в AWS, Microsoft Azure, Google Cloud или совместимом поставщике OpenID Connect вместо постоянного секрета. Если архитектура уже построена вокруг внешнего поставщика авторизации, возможен внешний OAuth. Для совместимого клиента подходит и ключевая пара, но закрытый ключ остаётся долговременным секретом: его нужно защищённо хранить и менять.
Переключайте каждую интеграцию отдельно. Добавьте новый метод, выполните контрольное подключение и запрос с минимальной ролью, затем переведите расписание и наблюдайте полный рабочий цикл. Старый пароль удаляйте после подтверждения штатного запуска, повторного подключения и обработки ошибки, а не сразу после первого успешного запроса.
Проверьте клиенты и аварийное восстановление
Составьте матрицу реально используемых клиентов: Snowsight, Snowflake CLI, SnowSQL, JDBC, ODBC, Python и средства аналитики. Для каждого проверьте первоначальный вход, выбор роли, обновление или истечение сеанса, повторное подключение и запуск в среде без браузера. Старые версии драйверов обновите до назначения обязательной политики.
Если используется кэш MFA, проверьте его отдельно. Он хранится на стороне клиента, имеет ограниченный срок действия и становится недействительным при смене способа аутентификации, учётных данных или аккаунта. Кэш уменьшает число запросов второго фактора, но не превращает интерактивный пользовательский вход в подходящий механизм для сервиса.
До массового переключения создайте выделенного аварийного администратора, не зависящего от штатного SSO. Snowflake предусматривает хранение его пароля и одноразовых кодов в защищённом хранилище; использованный код становится недействительным, поэтому запас и альтернативный фактор нужно контролировать. Такая запись не должна применяться в повседневной работе.
Если пользователь потерял второй фактор, администратор может запустить регистрацию нового метода командой ALTER USER … ENROLL MFA либо временно разрешить парольный вход через MINS_TO_BYPASS_MFA. Обход задавайте на минимальное время и фиксируйте как аварийное действие. Массовое включение завершайте только после проверки MFA и SSO для людей, беспарольного входа сервисов, всех рабочих клиентов и независимого пути восстановления.
Читайте также:
Подпишитесь на рассылку
Получайте свежие новости Web3, AI и криптовалют прямо на вашу почту.