Утечка ключей AWS в OneLogin стала проверкой ответственности поставщика идентификации

Кратко

• Утечка ключей AWS в OneLogin в 2017 году стала проверкой ответственности поставщика идентификации: тогдашние заявления OneLogin сообщали о несанкционированном доступе в регионе данных США, позднее описывали злоумышленника, использовавшего ключи AWS для доступа к AWS API, и советовали клиентам провести широкие меры восстановления — по ключам, сертификатам, токенам, секретам и паролям.
• У кого фактически был контроль над хранением ключей AWS, шифрованием клиентских данных, изоляцией поставщика идентификации, отзывом токенов, рекомендациями клиентам по восстановлению, сроками раскрытия информации и доказательствами того, что компрометация SSO не оставила устойчивой угрозы для учётных записей?
• Суть ответственности в том, что поставщик идентификации концентрирует клиентские риски доступа, поэтому компрометация облачного ключа становится проверкой управления: сегментации, шифрования и доказательств восстановления клиентов.
• Корпоративным клиентам, сотрудникам, администраторам, нижестоящим SaaS-провайдерам, командам безопасности, аудиторам и регуляторам нужны были доказательства, что цепочку доверия к идентификации можно сбросить и проверить, а не просто объявить восстановленной.
• В этой статье своевременные публикации, цитировавшие уведомление OneLogin о безопасности и рекомендации клиентам, рассматриваются как доказательства по инциденту 2017 года; материалы OneLogin и One Identity — как доказательства контекста продукта и регионального размещения данных; материалы AWS и стандартов — как контрольная терминология; сторонний анализ — только как поддержка уроков по реагированию и облачным ключам.

Почему этот случай относится к досье о рисках и ответственности

OneLogin относится к досье о рисках и ответственности, потому что это был не обычный сервис, хранящий один узкий набор данных. Это был поставщик идентификации. Предприятия использовали его, чтобы опосредовать доступ ко множеству других приложений, выпускать утверждения SAML, поддерживать потоки OAuth и OpenID Connect, автоматизировать предоставление и отзыв доступа и централизовать политику аутентификации. Когда у поставщика идентификации происходит инцидент с инфраструктурными ключами, вопрос о вреде шире, чем «была ли затронута одна база данных».

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

Публичная картина начинается с раскрытия OneLogin от 31 мая 2017 года, о котором сообщили Krebs on Security (источник: krebsonsecurity.com) и SecurityWeek (источник: securityweek.com). В этих публикациях цитировались слова OneLogin о том, что компания обнаружила несанкционированный доступ к данным OneLogin в регионе данных США, заблокировала доступ, уведомила правоохранительные органы и работала с независимой компанией по безопасности.

В более позднем обновлении OneLogin, процитированном в тех же публичных материалах, говорилось, что злоумышленник получил ключи AWS, использовал их для доступа к AWS API через промежуточного поставщика в США, создавал инстансы для разведки и получил доступ к таблицам баз данных, содержащим информацию о пользователях, приложениях и типах ключей. В материалах также говорилось, что OneLogin не могла исключить возможность получения злоумышленником способности расшифровывать данные.

Такое сочетание сделало этот случай проверкой на ответственность. Ключи AWS — это не просто пароли. В среде «инфраструктура как сервис» они могут создавать инстансы, читать метаданные, перемещаться между сервисами и добираться до баз данных в зависимости от прав. Модель разделения ответственности AWS (источник: aws.amazon.com) проводит чёткую границу: AWS обеспечивает безопасность базовой облачной инфраструктуры, а клиент, использующий AWS, отвечает за идентификацию, доступ, конфигурацию данных и контроль приложений. В этом случае клиентом AWS была OneLogin, а корпоративные клиенты OneLogin были зависимой стороной.

Цепочка ответственности пересекала три уровня: облачный провайдер, поставщик идентификации и клиентский тенант.

Вопрос практический: у кого фактически был контроль над хранением ключей AWS, шифрованием клиентских данных, изоляцией поставщика идентификации, отзывом токенов, рекомендациями клиентам по восстановлению, сроками раскрытия информации и доказательствами того, что компрометация SSO не оставила устойчивой угрозы для учётных записей? Ответ не может сводиться к «ротируйте ключи». Ротация необходима, но это лишь часть восстановления идентификации. Клиентам нужно было знать, какие объекты доверия затронуты, какие могли быть затронуты, какие нужно заменить немедленно, за какими можно наблюдать и какие доказательства подтвердят завершение.

Нынешнее позиционирование продукта OneLogin (источник: onelogin.com) подчёркивает централизованное управление идентификацией для сотрудников, клиентов и партнёров, тысячи интеграций с приложениями, адаптивную аутентификацию и автоматизированное управление жизненным циклом. Это позиционирование объясняет, что стояло на кону в событии 2017 года. Провайдер, централизующий доступ, снижает фрагментацию, пока всё работает. Когда скомпрометирована его собственная плоскость управления, он может также сконцентрировать неопределённость. Ответственное досье восстановления должно показать, что централизация не становится безграничным радиусом поражения.

Инциденты у поставщика идентификации — это не обычные утечки данных

Многие анализы утечек считают записи. Инциденты у поставщика идентификации требуют иного измерения. Поставщик идентификации хранит или обслуживает пользовательские идентичности, назначения приложений, параметры федерации, подписывающие сертификаты, учётные данные API, интеграции MFA, коннекторы приложений, контроль сеансов и административные политики. Одни из этих объектов — данные. Другие — полномочия. Третьи — карты того, где полномочия принимаются.

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

Документация разработчика OneLogin показывает почему. Обзор API (источник: developers.onelogin.com) сообщает, что API защищён OAuth 2.0 и использует субдомен клиента OneLogin в качестве домена API. Страница учётных данных API (источник: developers.onelogin.com) объясняет, что вызовы API требуют токена доступа OAuth Bearer, полученного с помощью пары учётных данных. Страница генерации токенов (источник: developers.onelogin.com) описывает создание токенов доступа и обновления для ресурсных API. Эти документы — текущая документация продукта, а не криминалистические доказательства инцидента 2017 года.

Они иллюстрируют общую истину о поставщиках идентификации: токены, клиенты, секреты, домены и роли — это операционные полномочия, а не пассивные метаданные.

То же касается федерации. Обзор SAML (источник: developers.onelogin.com) описывает OneLogin как инструмент для включения SSO через SAML. Обзор OpenID Connect (источник: developers.onelogin.com) описывает OpenID Connect как уровень идентификации поверх OAuth 2.0. Страница API выхода (источник: developers.onelogin.com) описывает завершение сеанса OneLogin и отзыв токенов, выпущенных в рамках этого сеанса SSO. Опять же, это документы о продукте, а не факты инцидента, но они объясняют, почему бремя восстановления клиентов после события у поставщика идентификации может быть большим.

Федеративное доверие принимается сервис-провайдерами, потому что сертификаты, токены, конечные точки и метаданные говорят, что поставщик идентификации авторитетен.

Своевременный анализ реагирования клиентов Райана Макгиэна (источник: magoo.medium.com) отражал это практическое бремя. Статья прямо отсылала читателей к статье поддержки OneLogin как к источнику истины, а затем обсуждала действия клиентов: ротацию сертификатов SAML, секретов интеграции 2FA, содержимого Secure Notes, паролей, не связанных с SAML, учётных данных API и связанных объектов доверия. Эта статья — не посмертный разбор OneLogin, но она ценна тем, что показывает, что практики считали необходимым для радиуса поражения: скоординированный сброс идентификации, а не узкая смена пароля.

Ответственный стандарт для такого типа инцидентов поэтому выше, чем «были получены клиентские данные». Полезная публичная запись должна указывать, какие материалы идентификации подтверждённо были доступны, какие могли быть раскрыты, потому что границы шифрования не удалось доказать, какие нужно было ротировать в порядке предосторожности, как клиенты могли проверить завершение и что OneLogin изменила, чтобы подобная утечка инфраструктурных ключей с меньшей вероятностью добралась до клиентских объектов доверия.

Ключи AWS сделали облачную плоскость управления частью инцидента

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

Рекомендации AWS по IAM (источник: docs.aws.amazon.com) и документация о временных учётных данных (источник: docs.aws.amazon.com) дают современную контрольную терминологию: минимальные привилегии, временные учётные данные, роли, MFA для привилегированного доступа, пересмотр доступа и аккуратное обращение с ключами доступа. Эти документы не сообщают публике, как именно OneLogin настроила свою инфраструктуру AWS в 2017 году. Они определяют классы контроля, о которых должно спрашивать досье ответственности: были ли ключи долгоживущими? Были ли они привязаны к пользователям или ролям? Мог ли скомпрометированный ключ создавать инстансы? Мог ли он добраться до производственных баз данных?

Были ли права разделены по региону данных, функции и среде? Были ли оповещения об аномалиях связаны с автоматической изоляцией?

Современное обсуждение облачной безопасности от Nordcloud (источник: nordcloud.com) использовало случай OneLogin для аргументации в пользу ролевого доступа, переключения ролей с обязательной MFA и отказа от статических ключей API, где возможно. Статья опирается на то же обновление OneLogin, которое цитируется и в других местах, поэтому она не является отдельным криминалистическим авторитетом. Её ценность — в формулировке урока облачного контроля: провайдер должен проектировать доступ к AWS API так, чтобы одна раскрытая учётная запись не могла свободно создавать инфраструктуру, исследовать среду или добираться до хранилищ данных без дополнительных барьеров.

Вопрос облачной плоскости управления важен, потому что поставщики идентификации сами являются облачными арендаторами. Корпоративный клиент может купить OneLogin, чтобы сократить число систем аутентификации, которые ему приходится эксплуатировать, но он не может напрямую проверять политики AWS IAM OneLogin, дизайн хранения ключей, оповещения об инцидентах, сегментацию баз данных или хранение ключей шифрования. Поэтому провайдер должен превращать скрытые механизмы контроля в доказательства, которым клиенты могут доверять. Страницы сертификаций и соответствия помогают, но они не заменяют доказательства по конкретному инциденту при утечке ключей.

Страница соответствия OneLogin (источник: onelogin.com) и страница GDPR (источник: onelogin.com) показывают вид заявлений об управлении, которые клиенты обычно проверяют: конфиденциальность, сертификаты, обработку данных, формулировки об уведомлении об утечках, потоки данных и поддержку соответствия. Эти страницы — не посмертный отчёт о корневой причине. Они иллюстрируют обещание на этапе закупки. Утечка 2017 года проверила, выдержит ли обещание реальную компрометацию инфраструктурных ключей и хватит ли клиентам доказательств для точных действий.

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

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

Восстановление у клиентов было настоящим ремонтом идентификации

Работа клиента по восстановлению была центральной в инциденте OneLogin. Krebs сообщил, что сообщение клиентам предписывало организациям сгенерировать новые ключи API и токены OAuth, создать новые сертификаты и учётные данные безопасности, пересоздать секреты, хранящиеся в Secure Notes, и попросить конечных пользователей обновить пароли. Практический ретроспективный разбор на Medium рассматривал сертификаты SAML, токены интеграции 2FA, пароли, не связанные с SAML, Secure Notes и учётные данные API как практические объекты реагирования. Более поздний отчёт CSO (источник: csoonline.com) также описывал событие как проблему доверия клиентов, требующую быстрого реагирования и прозрачности.

Этот список важен, потому что показывает разницу между локализацией инцидента у провайдера и восстановлением у клиента. Локализация у провайдера блокирует несанкционированный доступ, отзывает скомпрометированные ключи AWS, отключает затронутую инфраструктуру, проводит расследование и выпускает рекомендации. Восстановление у клиента меняет материалы доверия, которые нижестоящие приложения используют для принятия утверждений OneLogin, вызовов API и сохранённых учётных данных. Если клиенты не выполнят этот второй шаг, провайдер может быть технически восстановлен, а среды клиентов останутся уязвимыми.

Ротация сертификатов подписи SAML — особенно полезный пример. Руководство OneLogin по сертификатам подписи SAML (источник: onelogin.com) и по настройке SAML (источник: onelogin.com) объясняют, что сертификаты, отпечатки, конечные точки и параметры SSO являются частью управления интеграцией SAML. Если сертификат подписи мог быть скомпрометирован, каждому сервис-провайдеру, доверяющему этому сертификату, может понадобиться обновлённый сертификат и метаданные. Для сложного предприятия это не ремонт в один клик.

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

Ротация токенов OAuth и API имеет другую операционную форму. Учётные данные API могут быть встроены в автоматизацию, скрипты, задания предоставления доступа, коннекторы отчётности или интеграционное промежуточное ПО. Если ротация неполная, старый токен или секрет может продолжать работать в забытом рабочем процессе. Если ротация проводится в спешке без инвентаризации, бизнес-процессы могут сломаться. Поэтому в этом случае важна автоматизация безопасности. Клиентам нужны машиночитаемые реестры приложений, сертификатов, токенов, сохранённых секретов и привилегированных коннекторов.

Им нужны журналы, показывающие, используются ли ещё старые материалы.

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

Ответственный провайдер должен поддерживать эту работу. Рекомендации по восстановлению должны быть конкретными, приоритизированными, с указанием времени и проверяемыми. Они должны отличать «немедленно ротировать» от «ротировать в порядке предосторожности» и «наблюдать за подозрительным использованием». Там, где возможно, они должны включать запросы для обнаружения, административные отчёты, экспортируемые реестры приложений, статус истечения и замены сертификатов, журналы выдачи и отзыва токенов и приоритетную поддержку для высокорисковых интеграций.

Без таких артефактов восстановление превращается в ручную суету, а ручная суета оставляет устойчивые пробелы.

Инцидент поэтому входит в досье ответственности, потому что работа по восстановлению была распределена. OneLogin контролировала скомпрометированную облачную среду и рекомендации по продукту. Клиенты контролировали свои интеграции приложений и нижестоящие точки доверия. Нижестоящие SaaS-провайдеры контролировали, как быстро можно заменить сертификат SAML или клиент OAuth. Ответственность должна следовать этой цепочке, а не делать вид, что одна сторона могла завершить сброс.

Заявления о шифровании требуют доказательства разделения ключей

В процитированном обновлении OneLogin говорилось, что компания шифрует некоторые конфиденциальные данные в состоянии покоя, но не может исключить, что злоумышленник получил возможность расшифровать данные. Это самое важное предложение в публичной картине. Оно не доказывает, что все зашифрованные данные были расшифрованы. Оно показывает, что шифрование в состоянии покоя само по себе не было достаточной публичной гарантией после утечки ключей AWS.

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

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

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

Тема суверенитета и локализации данных также появляется здесь. Текущая страница статуса OneLogin (источник: onelogin.com) сообщает, что компания предлагает вариант размещения данных в Европе, в географически распределённых центрах обработки данных в Европейской экономической зоне. Инцидент, напротив, касался региона данных в США. Вопрос ответственности не в том, находились ли все глобальные клиенты физически в одной базе данных. Вопрос в том, могли ли клиенты определить, какой регион их обслуживает, какие данные и материалы доверия находились в этом регионе, какие межрегиональные пути или пути поддержки существовали и как уведомления об инциденте соотносились с региональным воздействием.

Размещение данных иногда продаётся как местоположение. В инциденте оно должно становиться доказательством. Клиентам нужно знать, привязаны ли к региону данные аутентификации, метаданные приложений, секреты, журналы, резервные копии, экспорт для поддержки, аналитика и административный доступ, или они копируются куда-то ещё. Им нужно знать, затрагивает ли инцидент в регионе данных США только тенантов, размещённых в США, или также глобальные системы управления. Им нужно знать, могут ли ключи или журналы в одном регионе открывать данные в другом. Публичная картина OneLogin 2017 года дала региональную привязку, но не полную карту потоков данных.

GDPR (источник: eur-lex.europa.eu) делает ответственность за защиту данных шире, чем местоположение. Страница OneLogin о GDPR обсуждает потоки данных, обязанности по уведомлению об утечках и приватность по дизайну. Для поставщика идентификации приватность по дизайну должна включать минимизацию хранимых секретов, разделение полномочий на расшифровку, доступ поддержки с учётом регионов, журналирование, переживающее реагирование на инциденты, и клиентоориентированные доказательства того, что данные не реплицировались за обещанные границы. Ответственный вопрос после утечки — стали ли эти принципы измеримыми контролями.

Урок не в том, что шифрование подвело, потому что OneLogin не смогла исключить расшифровку. Урок в том, что заявления о шифровании должны подкрепляться доказательствами разделения ключей. Если провайдер может доказать, что украденная инфраструктурная учётная запись не может добраться до ключевого материала, клиенты могут сузить объём восстановления. Если провайдер не может этого доказать, клиенты должны ротировать широко, исходить из возможного раскрытия сохранённых учётных данных и рассматривать инцидент как сброс цепочки доверия.

Сроки раскрытия и границы доказательств имеют значение

Публичные доказательства показывают, что OneLogin обнаружила несанкционированный доступ 31 мая 2017 года, заблокировала его, уведомила правоохранительные органы и работала с независимой компанией по безопасности. Позднее стало известно, что атака началась около 2:00 по тихоокеанскому времени, персонал был оповещён около 9:00, а затронутые инстансы и ключи AWS были отключены в течение нескольких минут после обнаружения. Эти факты пришли из заявлений OneLogin, процитированных в своевременных публикациях, включая Krebs, SecurityWeek и ретроспективный разбор практика.

Поскольку исходная страница инцидента OneLogin больше не является стабильным актуальным источником и перенаправляет в пределах веб-инфраструктуры One Identity, с публичной картиной нужно обращаться осторожно.

Это ограничение доказательств само по себе — часть ответственности. Уведомления об инцидентах должны оставаться доступными или архивироваться в стабильном месте, потому что клиентам, аудиторам, регуляторам, исследователям и закупочным командам нужно оценивать прошлое поведение провайдера. Текущая страница соответствия не может заменить старое уведомление об инциденте. Статья третьей стороны, цитирующая уведомление, полезна, но она слабее, чем постоянный архив провайдера с оригинальным уведомлением, историей обновлений, инструкциями для клиентов и итоговыми уроками.

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

К обоснованным выводам относится заключение, что центральными объектами контроля были ограничение прав AWS IAM, разделение ключей шифрования, карта регионов данных, ротация сертификатов SAML, отзыв токенов OAuth и инвентаризация на стороне клиента.

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

Эта дисциплина важна, потому что утечки у поставщиков идентификации провоцируют спекуляции. Легко было бы заявить, что каждая нижестоящая SaaS-учётная запись была скомпрометирована. Публичная картина этого не доказывает. Легко было бы и преуменьшить инцидент, потому что OneLogin заблокировала доступ после обнаружения. Этого публичная картина тоже не подтверждает. Правильное ответственное прочтение: компрометация ключа AWS на стороне провайдера создала достаточно правдоподобный радиус поражения идентификации, чтобы клиентам велели ротировать широкий круг материалов доверия.

У сроков раскрытия есть и вторая цель: они позволяют клиентам искать в журналах. Если инцидент начался около 2:00 по тихоокеанскому времени, а обнаружение произошло около 9:00, клиенты могут проверить журналы нижестоящих приложений, журналы активности OneLogin, использование API, принятие утверждений SAML, события MFA-провайдера и изменения администраторов в этом окне и после него. Доказательства, привязанные ко времени, ценны, только если провайдер даёт достаточно отметок времени и категорий артефактов. Расплывчатое раскрытие лишает клиентов возможности искать собственный ущерб.

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

Автоматизация безопасности должна сокращать разрыв между оповещением и радиусом поражения

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

Современное реагирование на облачные инциденты должно спрашивать, вызывают ли необычные вызовы AWS API немедленную изоляцию, ограничено ли использование ключей источником, учётной записью, ролью, сервисом и ожидаемым рабочим процессом, блокируется ли или усиленно контролируется создание инстансов вне систем развёртывания, связаны ли аномалии доступа к базам данных с оценкой риска идентификации и доступны ли производственные секреты тем же учётным данным, которые управляют вычислениями. Материалы AWS, CISA и NIST дают язык. Руководство CISA по безопасному дизайну (источник: cisa.gov) подчёркивает проектирование продуктов так, чтобы клиенты не были вынуждены поглощать предотвратимый риск.

Структура NIST Cybersecurity Framework (источник: nist.gov) — это определение, защита, обнаружение, реагирование и восстановление.

Для поставщика идентификации автоматизация должна также поддерживать клиентов. Нынешние материалы продукта OneLogin говорят об адаптивной аутентификации, оценках риска и потоковой передаче событий входа в SIEM и облачные средства коммуникации. Текущая главная страница (источник: onelogin.com) сообщает, что платформа может обнаруживать подозрительное поведение и применять адаптивную аутентификацию. Статья разработчика об облачных угрозах (источник: developers.onelogin.com) обсуждает функции обнаружения и реагирования: злоупотребление валидными учётными записями, подозрительные индикаторы и автоматические уведомления.

Эти более поздние материалы продукта не доказывают, что существовало в 2017 году, но они показывают, какую автоматизацию клиенты ожидают от компании, занимающейся идентификацией.

После утечки у провайдера автоматизация, обращённая к клиентам, должна быстро помочь ответить на четыре вопроса. Какие приложения доверяют этому поставщику идентификации? Какие сертификаты и клиенты OAuth активны? У каких пользователей есть сохранённые учётные данные или Secure Notes, которые могут потребовать ротации? Какие нижестоящие приложения принимали утверждения или вызовы API в подозрительном окне? Без этих ответов командам реагирования приходится в спешке создавать электронные таблицы. Электронные таблицы плохо масштабируются, когда затронутый провайдер централен для доступа.

Автоматизация безопасности также нуждается в семантике истечения и отзыва. Отозванный токен должен перестать работать. Ротированный сертификат SAML должен заменить старую точку доверия. Сброс пароля должен по возможности аннулировать старые сеансы. Секрет интеграции MFA должен заменяться без «осиротения» пользователей или отключения аварийного доступа. Продукт должен показывать клиенту, какие старые материалы всё ещё принимаются. Если поставщик идентификации не может этого показать, он не полностью операционализировал восстановление.

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

Локализация данных меняет бремя информирования клиентов

Инцидент OneLogin был описан как затронувший регион данных в США, а текущая страница доверия OneLogin описывает вариант размещения данных в Европе. Различие важно, потому что поставщики идентификации обслуживают глобальных клиентов с разными регуляторными, контрактными и операционными ожиданиями. Уведомление о региональном воздействии должно сообщать клиентам, находятся ли они в регионе, какие категории данных привязаны к региону, пересекают ли данные поддержки или резервных копий регионы и являются ли объекты доверия локальными или глобальными.

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

Страница GDPR (источник: onelogin.com) обсуждает карты данных, соглашения об обработке данных, уведомление об утечках и клиентские инструменты для доступа, переносимости, депровижининга и аудита. Эти темы напрямую пересекаются с инцидентами у поставщиков идентификации. Если тенант содержит пользователей из ЕС, но обслуживается из региона США, клиенту может потребоваться оценить трансграничную передачу и вопросы уведомления. Если тенант обслуживается из региона ЕЭЗ, клиенту всё равно нужно знать, были ли затронуты журналы поддержки, аналитика, ключи или резервные копии где-то ещё. Размещение без карты зависимостей неполно.

Для клиентов бремя коммуникации после инцидента с идентификацией имеет два уровня. Сначала OneLogin должна была сообщить клиентам достаточно для защиты их сред. Затем эти клиенты должны были решить, рассказывать ли и как рассказывать сотрудникам, партнёрам, аудиторам, регуляторам и владельцам нижестоящих сервисов. Широкая инструкция «ротируйте всё» снижает риск недореагирования, но увеличивает сбои в бизнесе. Узкая инструкция снижает сбои, но может упустить неизвестную утечку. Лучшие доказательства позволяют клиентам выбирать пропорционально.

Локализация данных влияет и на подотчётность при закупке. Предприятия выбирают поставщиков идентификации отчасти по региону, соответствию, аптайму, поддержке и широте интеграций. Страница статуса (источник: onelogin.com) и страница соответствия становятся частью закупочной записи. Когда происходит инцидент, провайдер должен сопоставить обещания при закупке с фактической картой воздействия. Какой регион затронут? Какие клиенты в нём? Какие артефакты там хранились? Какие контроли оставили другие регионы и системы вне радиуса поражения? Какие доказательства поддерживают этот вывод?

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

Клиентской стороне нужно было собственное досье ответственности

OneLogin контролировала среду провайдера, но клиенты контролировали многие нижестоящие последствия. Клиент, использовавший OneLogin для сотен SaaS-интеграций, должен был знать, какие приложения зависят от SAML, какие используют OIDC, какие хранят пароли, какие хранят учётные данные API, какие используют интеграции с MFA-провайдерами, какие администраторы имеют привилегии и у каких пользователей есть сохранённые секреты. Если у клиента не было такого реестра, инцидент провайдера выявил ещё и слабость клиентского управления.

Это неудобная правда централизации идентификации. Покупка поставщика идентификации не снимает с клиента обязанности понимать зависимости идентификации. Она меняет форму этой обязанности. Клиенты должны поддерживать реестр приложений, реестр объектов доверия, процесс ротации сертификатов, аварийную процедуру федерации, дизайн аварийного доступа, политику для не-SAML учётных данных, политику Secure Notes, процесс отзыва токенов и послеинцидентный поиск по журналам. OneLogin могла давать рекомендации и инструменты, но каждый клиент должен был выполнять их в своей среде.

Интеграции SAML и OIDC особенно трудно ротировать, потому что владельцы бизнеса могут не знать технического владельца каждого приложения. Сервис-провайдер может принимать старые и новые сертификаты во время перехода или требовать запланированного простоя. Некоторые SaaS-администраторы могли уйти. Некоторые метаданные приложений могли устареть. Некоторые интеграции могли быть созданы для проекта и никогда не задокументированы. Утечка у поставщика идентификации превращает этот административный долг в немедленный риск.

В список восстановления, о котором сообщил Krebs, входили также секреты, хранящиеся в Secure Notes, и пароли, не связанные с SAML. Это вскрывает политический вопрос. Если платформа идентификации позволяет пользователям или администраторам хранить секреты, клиентам нужны правила: что можно хранить, кто может экспортировать, как это шифруется, можно ли отчитаться об использовании и как быстро можно найти все затронутые секреты. Если клиент не может перечислить, кто пользовался функцией, реагирование становится гаданием.

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

Клиентам также нужно было проверять нижестоящие приложения на необычный доступ. Риск компрометации сертификата SAML — это не только проблема сертификата. Это проблема доступа. Принимал ли какой-либо сервис-провайдер необычные утверждения? Менялись ли роли администраторов? Сохранялись ли пользовательские сеансы? Делали ли какие-то API-клиенты неожиданные вызовы? Видел ли какой-то MFA-провайдер использование токенов, которое стоит расследовать? Эти вопросы требуют журналов, хранящихся у нескольких поставщиков. Они также требуют часов, корреляционных идентификаторов и SIEM-конвейеров, подготовленных до инцидента.

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

При закупке нужно оценивать доказательства, а не только списки функций

Инцидент OneLogin должен был изменить то, как клиенты оценивают поставщиков идентификации. Списки функций важны, но при закупке нужно спрашивать и о практике работы с доказательствами инцидентов. Сохраняет ли провайдер старые уведомления об инцидентах? Публикует ли он, где возможно, уроки после инцидента? Предоставляет ли инструменты экспорта для реестра приложений, сертификатов, учётных данных API, интеграций MFA, хранимых секретов, журналов и действий администраторов? Документирует ли границы регионов данных? Поддерживает ли экстренную ротацию доверия в масштабе?

Соответствуют ли формулировки об уведомлении об утечках фактическим обязанностям клиента?

Текущие страницы соответствия и статуса OneLogin — полезный вход для закупки, а контекст приобретения One Identity мог изменить управление и архитектуру продукта с 2017 года. Но устойчивый обзор ответственности смотрит на поведение под стрессом. Как быстро провайдер раскрыл информацию? Насколько конкретными были рекомендации? Поняли ли клиенты вероятный радиус поражения? Заявил ли провайдер, чего не может исключить? Превратил ли провайдер инцидент в архитектурные изменения? Показывают ли более поздние материалы более сильную автоматизацию, региональные варианты и контроль рисков идентификации?

Сторонний анализ может помочь, но он не должен становиться основным источником. Ретроспективный отчёт CSO, репортажи Krebs и SecurityWeek, обсуждение ключей AWS от Nordcloud и статья практика на Medium дают полезные снимки того, что знали публика и сообщество реагирования. Они не могут полностью заменить посмертный разбор, поддерживаемый провайдером. Провайдер, обладающий полномочиями идентификации, должен рассматривать свой архив инцидентов как часть доверия клиентов.

При закупке нужно также проверять выход и запасной путь. Если поставщик идентификации деградировал или ему временно нельзя доверять, можно ли получить доступ к критическим приложениям через аварийные учётные записи? Находятся ли эти учётные записи под мониторингом и защитой? Могут ли клиенты безопасно отключить SSO для экстренного доступа без новых уязвимостей? Могут ли восстановить доверие новыми сертификатами и токенами в контролируемой последовательности? Могут ли доказать, что старые материалы доверия больше не принимаются? Это не абстрактные вопросы. Это практические задачи, с которыми клиенты столкнулись в 2017 году.

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

Ответственный стандарт закупки — не «никогда не иметь инцидентов». Это «докажи, что инцидент можно ограничить, раскрыть, устранить и извлечь из него уроки». Утечка OneLogin в 2017 году остаётся поучительной, потому что показала, насколько доверие к поставщику идентификации зависит от доказательств, которые клиенты не могут создать в одиночку.

Доказательства следует разделять на подтверждённые факты, обоснованные выводы и неизвестное

Подтверждённые публичные факты ограничены, но значимы. OneLogin раскрыла несанкционированный доступ в своём регионе данных в США. Публикации цитировали более позднее обновление OneLogin, описывающее злоумышленника, получившего ключи AWS, использовавшего AWS API, создававшего инстансы для разведки и получившего доступ к таблицам баз данных с пользователями, приложениями и типами ключей. В той же публичной картине говорилось, что OneLogin не может исключить, что злоумышленник получил возможность расшифровать данные.

Сообщённые рекомендации клиентам включали широкую ротацию ключей API, токенов OAuth, сертификатов, учётных данных, секретов и паролей конечных пользователей.

Обоснованные выводы тоже значимы. Разумно заключить, что центральными объектами ответственности были ограничение прав AWS IAM, хранение ключей, сегментация баз данных, разделение ключей шифрования, хранение сертификатов SAML, отзыв токенов OAuth, секреты интеграций MFA, управление Secure Notes и клиентская инвентаризация. Разумно заключить, что региональная привязка имела значение, поскольку инцидент был описан как затронувший регион данных в США, а OneLogin продаёт региональные варианты размещения.

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

Неизвестное остаётся, и его следует называть. Публичная картина не раскрывает точные политики AWS IAM, место и жизненный цикл раскрытых ключей, полную схему затронутых баз данных, конкретную архитектуру ключей шифрования, полный список категорий клиентских данных, полный независимый криминалистический отчёт, все инструкции по восстановлению, все послеинцидентные архитектурные изменения или статус завершения каждой клиентской ротации. Она также не позволяет внешнему наблюдателю доказать, была ли какая-либо нижестоящая SaaS-учётная запись фактически использована в результате инцидента.

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

Граница доказательств также защищает от необоснованных утверждений. Было бы неверно утверждать без доказательств, что OneLogin намеренно скрывала факты, что все клиентские учётные данные были расшифрованы или что все нижестоящие приложения были доступны. Было бы также неверно утверждать, что инцидент имел низкое влияние только потому, что несанкционированный доступ был заблокирован. Бремя восстановления у клиентов показывает, что риск был широким, даже если окончательное доказанное злоупотребление остаётся неясным.

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

Стандарт восстановления — проверяемый сброс доверия

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

Для клиентов это означает: ротированные сертификаты SAML, заменённые токены OAuth, пересозданные учётные данные API, пересмотренные сохранённые секреты, изменённые пароли там, где нужно, обновлённые секреты интеграции MFA, проверенные журналы нижестоящих систем и исключения, отслеженные до закрытия.

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

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

Обещания о регионе данных должны соответствовать фактическим границам контроля.

Вот почему инцидент остаётся актуальным и после 2017 года. Современные предприятия зависят от поставщиков идентификации больше, а не меньше. Больше приложений используют SSO. Больше API используют токены. Больше автоматизации использует нечеловеческие идентичности. Больше регуляторных режимов спрашивают, где обрабатываются данные и кто их контролирует. Поэтому утечка у провайдера создаёт составную проблему ответственности: зависимость от облачного сервиса, локализация данных и автоматизация безопасности сталкиваются одновременно.

Утечку OneLogin 2017 года следует помнить как случай радиуса поражения поставщика идентификации, а не только как случай ключей AWS. Украденный или раскрытый ключ был путём, описанным в публичной картине. Настоящим тестом была возможность провайдера и клиентов сбросить полномочия, делавшие возможными тысячи последующих входов. Ответственность начинается с документирования этого сброса, с называния неизвестного и с изменения архитектуры, чтобы следующая утечка ключа на стороне провайдера имела меньший, более ясный и быстрее локализованный радиус поражения.