Риск концентрации при использовании SSO

Когда вы нажимаете "Sign in with Google" (или Apple, Microsoft, GitHub) в стороннем SaaS, вы не создаёте аккаунт в этом SaaS. Вы говорите ему: "IdP за меня поручится". Пока IdP ручается, у вас есть аккаунт в каждом зависимом SaaS, который принимает этот IdP. В тот день, когда IdP перестаёт ручаться - по любой причине, с объяснением или без него, - все зависимые сервисы перестают работать в одно мгновение.

Это обратная сторона аргументов в пользу безопасности. Стандартное обоснование SSO ("один надёжный аккаунт вместо множества слабых") верно в отношении поверхности атак на пароли, но игнорирует поверхность доступности. Неявное допущение состоит в том, что IdP - это нейтральная коммунальная служба. Но это не так: это частная компания, которая может расторгнуть отношения в одностороннем порядке без всякого SLA, договора и суда.

Распределённый риск против концентрированного

Тред the_smart_ape (don't sign in with google) формулирует это так: SSO меняет распределённый риск на концентрированный. С точки зрения математического ожидания потерь они примерно эквивалентны - та же вероятность полной компрометации, схожая вероятность потери отдельного сервиса. Однако распределение исходов кардинально отличается:

• Распределённый (отдельные аккаунты, менеджер паролей, уникальные алиасы для каждого сайта): сбои независимы. Потеря одного аккаунта означает лишь повторную регистрацию на одном ресурсе. Худший день на 99-м процентиле - это просто досадно.
• Концентрированный (SSO для всего стека): сбои идеально скоррелированы по определению архитектуры. Потеря IdP означает мгновенную потерю всех зависимых сервисов. Худший день на 99-м процентиле - это закрытие бизнеса.

Пример из первоисточника: фаундер трёхлетнего SaaS лишается Gmail из-за внезапной блокировки без объяснения причин и одновременно теряет доступ к Notion (спецификации, контракты), Figma (макеты), Linear (задачи), Vercel (развёртывание, через цепочку восстановления GitHub -> Gmail) и Stripe (панель управления доходами). Человек до сих пор не знает, в чём именно провинился. Google так ничего и не объяснил.

Почему апелляции не помогают

Апелляции при блокировке аккаунтов читают классификаторы, а не живые люди. Показательный пример - известная история с Эндрю Спинксом (Andrew Spinks) и Terraria (январь 2021 года): известный разработчик потерял аккаунт по неизвестным причинам, стандартная апелляция не дала ничего, а доступ восстановили только после того, как он публично отменил порт игры для Stadia и новость разошлась по медиа. Негласное правило: успешная апелляция в массовых сервисах упирается в наличие медийного рычага давления.

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

Правильное правило вместо красивого лозунга

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

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

Если потеря доступа к сервису на 30 дней нанесёт ущерб вашей работе или финансам, не используйте SSO. Создайте настоящий аккаунт с собственным паролем, полноценной 2FA и почтовым алиасом, который не завязан на основной IdP.

Сопутствующие рекомендации из треда помогают применить это правило на практике:

• Разорвите цепочку восстановления. Почта для восстановления паролей от менеджеров паролей, облачных аккаунтов и регистраторов доменов не должна указывать на IdP, потеря которого сделает их недоступными.
• Используйте отдельные почтовые алиасы для каждого сервиса (Proton, Fastmail, SimpleLogin, Hide My Email от Apple). Если один из них утечёт или отношения с каким-то сервисом испортятся, зона поражения ограничится одним алиасом, а не основным адресом.
• Проведите премортем. Потратьте десять минут и представьте, что ваш аккаунт IdP исчез прямо сегодня вечером. Всё, что вы при этом потеряете и не сможете легко восстановить, вообще не следовало привязывать к SSO.

Соседние векторы атак

Риск концентрации при SSO - это сценарий отказа доступности. Тот же механизм (токены, выдаваемые IdP) имеет независимые сценарии отказа в плане безопасности, не зависящие от враждебности самого IdP: см. oauth-token-theft о повторном использовании refresh-токенов через multilogin и consent phishing, а также google-oauth-domain-takeover об отчёте Truffle Security, где покупка домена закрывшегося стартапа за $12 открыла доступ к Slack, Notion и Zoom старой компании.

Общий вывод: SSO концентрирует контроль в руках IdP, и любой сбой на стороне IdP - блокировка аккаунта, утечка, архитектурный просчёт - веером расходится по всему зависимому стеку.

См. также

• smart-ape-dont-sign-in-with-google - исходный тред.
• google-oauth-domain-takeover - уязвимость с покупкой доменов от Truffle Security.
• oauth-token-theft - повторное использование refresh-токенов и consent phishing.
• bitwarden - контекст по теме менеджеров паролей как альтернативы.
• long-lived-keys - refresh-токены как долгоживущие учётные данные.