Кратко

  • Сбой аутентификации Azure Active Directory в сентябре 2020 года важен, потому что идентификация была общим входом для Microsoft 365 и зависимых облачных сервисов, поэтому восстановление приходилось оценивать по практическому восстановлению доступа, а не по видимой исправности отдельного компонента.
  • В открытых сообщениях описывались ошибки аутентификации в сервисах Microsoft после изменения, затронувшего Azure Active Directory, с последующим откатом и мерами по устранению последствий. Открытые материалы полезны, но не раскрывают всех внутренних артефактов развёртывания, влияния на конкретных клиентов или результатов проверок контролей.
  • Вопрос подотчётности — кто фактически контролировал безопасность развёртывания, проверку отката, карту зависимостей аутентификации, видимость для администраторов, рекомендации клиентам по обходным путям, последовательность восстановления и доказательства того, что зависимые облачные сервисы снова реально стали доступны.
  • У клиентов тоже была обязанность понимать, насколько их работа зависит от одного поставщика идентификации, какие привилегированные действия останутся возможными во время инцидента с аутентификацией и являются ли ручные или альтернативные пути доступа реальными, а не теоретическими.

Идентификация стала плоскостью управления облаком

Azure Active Directory, ныне часть Microsoft Entra ID, — это не просто экран входа. Это плоскость управления доступом к почте, совместной работе, офисным документам, администрированию, управлению устройствами, SaaS-приложениям, инструментам безопасности, автоматизации процессов и партнёрским интеграциям. Когда этот слой идентификации выходит из строя, пострадавший пользователь может не видеть проблему «платформы идентификации». Он видит, что недоступны Outlook, Teams, SharePoint, Office.com, портал Azure, бизнес-приложения или интегрированный SaaS-процесс. Для пользователя зависимость абстрактна, для организации — конкретна.

Сбой сентября 2020 года важен, потому что он сделал эту абстракцию видимой. В публичных сводках статуса и тогдашних репортажах описывались проблемы аутентификации в Microsoft 365 и связанных сервисах после изменения Microsoft, затрагивавшего Azure Active Directory. Затем Microsoft провела откат и применила меры по устранению последствий. Эта статья аккуратно обращается с публичным материалом. Она не утверждает, что у неё есть доступ к приватным журналам развёртывания Microsoft, изменениям кода, телеметрии клиентских тенантов или внутреннему анализу первопричин.

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

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

Именно это различие — суть проблемы плоскости управления.

Текущая страница истории статуса Azure наисточник: status.azure.comи руководство Microsoft по состоянию служб Microsoft 365 по адресуисточник Microsoftпоказывают публичные и администраторские каналы, через которые клиенты должны классифицировать инциденты служб. Обзор API Service Communications для Microsoft 365 по адресуисточник Microsoftпоказывает более автоматизированный путь к данным о состоянии служб и сообщениям центра сообщений. Сами по себе эти источники не доказывают каждую деталь сентября 2020 года. Они показывают, что доказательства состояния служб — часть операционной модели клиентов облака Microsoft.

Текущая документация Microsoft также определяет контур идентификации. Основы Microsoft Entra ID по адресуисточник Microsoftописывают платформу идентификации. Документация по аутентификации по адресуисточник Microsoftи документация по многофакторной аутентификации по адресуисточник Microsoftописывают клиентские контроли идентификации. Руководство по мониторингу и состоянию по адресуисточник Microsoftдаёт клиентам словарь для наблюдения за состоянием идентификации. Эти документы — текущий продуктовый контекст, а не ретроспективный разбор инцидента. Они по-прежнему необходимы, потому что объясняют, почему сбой аутентификации — событие уровня плоскости управления.

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

Запись о статусе — не то же самое, что восстановление доступа

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

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

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

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

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

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

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

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

Безопасность развёртывания должна включать доказательство отката

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

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

Если мониторинг сосредоточен на исправности компонентов, а не на доступе к зависимым сервисам, восстановление могут объявить слишком рано.

Более широкая документация Microsoft по надёжности и архитектуре помогает задать стандарт. Руководство по надёжности Azure по адресуисточник Microsoftи опора надёжности Azure Well-Architected по адресуисточник Microsoftрассматривают надёжность как проектирование, мониторинг, реакцию на сбои и непрерывное улучшение. Материалы Azure Architecture Center об устойчивости по адресуисточник Microsoftдают общий язык для устойчивости и планирования режимов отказа. Это широкие актуальные справочники, а не конкретный разбор первопричин сентября 2020 года. Важно то, что безопасность развёртывания и доказательство отката входят в надёжность, а не находятся вне её.

Для провайдера идентификации доказательство отката должно включать несколько уровней. Во-первых, могут ли новые входы завершаться во всех основных сегментах клиентов? Во-вторых, могут ли существующие сеансы безопасно продлеваться или продолжаться? В-третьих, могут ли администраторы добраться до интерфейсов состояния, поддержки и политик? В-четвёртых, могут ли зависимые сервисы, такие как приложения Microsoft 365, операции портала Azure и интегрированные сторонние приложения, нормально использовать идентификацию? В-пятых, видят ли клиенты достаточно деталей статуса, чтобы не создавать вредных обходных путей?

В-шестых, может ли провайдер доказать, что проблема устранена, не скрывая остаточной восстановительной работы на стороне клиента?

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

Они не позволяют всему реагированию клиента на инцидент зависеть от той самой плоскости идентификации, которая нарушена.

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

Доказательство отката должно поэтому учитывать здоровье автоматизации наравне с человеческим входом.

Видимость администраторов может отказать из-за той же зависимости от идентификации

Сбой идентификации может нарушить именно те каналы, которые нужны для управления инцидентом. Администраторам может понадобиться доступ к центру администрирования Microsoft 365, порталу Azure, центру администрирования Entra, страницам состояния служб, каналам поддержки и журналам тенанта. Если эти пути зависят от нарушенного слоя идентификации, видимость администраторов становится риском непрерывности. Клиент может увидеть жалобы пользователей раньше, чем статус провайдера. Служба поддержки может вынужденно отвечать с неполной информацией.

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

Поэтому руководство Microsoft по состоянию служб — источник, определяющий подотчётность. Документация по состоянию служб по адресуисточник Microsoftобъясняет, как администраторы просматривают инциденты и уведомления. API Service Communications по адресуисточник Microsoftдаёт организациям способ интегрировать сообщения о состоянии служб в собственные системы. Ценность API не только в удобстве. Если процесс реагирования клиента может принимать сообщения о состоянии провайдера в канал, который не зависит от затронутого портала, видимость становится устойчивее.

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

Аварийный доступ — связанный контроль. Руководство Microsoft по аварийному доступу по адресуисточник Microsoftрекомендует поддерживать аварийные учётные записи для привилегированных операций. Это руководство — не вывод о сентябре 2020 года. Оно релевантно, потому что инциденты с идентификацией проверяют, является ли аварийный доступ документированным, отслеживаемым и отработанным контролем. Аварийная учётная запись, которую никто не тестировал, которая заблокирована тем же сбоем условного доступа или недоступна руководителю реагирования, — ненадёжный контроль.

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

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

Обходные пути должны быть реальными при нарушенной идентификации

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

Альтернативные SaaS-инструменты могут существовать, но не если они используют федерацию с тем же поставщиком идентификации.

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

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

Материалы Microsoft о доверии и отношениях с клиентами дают договорной и гарантийный контекст для этих вопросов. Microsoft Trust Center по адресуисточник Microsoft— публичная точка входа в материалы о безопасности, конфиденциальности, соответствии требованиям и доверии. Страница Microsoft Customer Agreement по адресуисточник Microsoftдаёт контекст отношений для облачных сервисов. Эти источники не решают никаких споров по инциденту 2020 года. Они напоминают покупателям, что зависимость от сервисов регулируется сочетанием публичных доказательств статуса, договорных условий, гарантийных материалов, собственной архитектуры клиента и локальных планов непрерывности.

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

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

Подотчётность требует обеих полос.

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

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

Публичные отчёты должны сохранять неопределённость

Публичные репортажи того времени полезны, но ограниченны. СМИ описывали широкие проблемы аутентификации Microsoft 365 и Azure Active Directory, включая влияние на такие сервисы, как Outlook, Teams, Office.com и доступ администраторов. Например, BleepingComputer сообщал о проблемах аутентификации Microsoft 365 по адресуисточник: bleepingcomputer.com, а The Verge сообщал о сбое Microsoft 365 по адресуисточник: theverge.com. Эти репортажи — полезные доказательства публичного влияния и публичных сообщений. Они не заменяют внутренние журналы Microsoft или телеметрию конкретного клиента.

Публичная неопределённость должна оставаться видимой. Разумно говорить, что сбой был связан с аутентификацией Azure Active Directory и последовательностью «изменение и устранение последствий» в Microsoft, — именно так описывалось публичное событие. Неразумно из одних публичных репортажей утверждать точный эффект по каждому тенанту, каждый внутренний провал контроля развёртывания, каждый бизнес-убыток или каждый успешный обходной путь. Зрелый материал о подотчётности не должен превращать публичный сбой в судебный вердикт.

Сохранение неопределённости не ослабляет урок. Оно усиливает его. Урок не в том, что посторонние знают каждый внутренний факт Microsoft. Урок в том, что клиенты всё равно могут определить класс контролей и улучшить собственные доказательства. Доступность поставщика идентификации — системная зависимость. Откат развёртывания должен оцениваться по практическому восстановлению доступа. Состояние служб должно быть видно вне нарушенного пути. Аварийный доступ должен быть проверен. Бизнес-процессы должны знать, что делать, когда идентификация деградирует. Эти выводы не требуют приватного исходного кода.

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

Внешние рамки помогают сохранять дисциплину обзора. Рамка кибербезопасности NIST по адресуисточник: nist.govдаёт публичный словарь для управления, выявления, защиты, обнаружения, реагирования и восстановления. Руководство NIST по планированию непрерывности по адресуисточник: csrc.nist.govдаёт жизненный цикл планирования и проверок непрерывности. NIST SP 800-53 по адресуисточник: csrc.nist.govдаёт семейства контролей для управления доступом, планирования непрерывности, аудита, реагирования на инциденты и управления конфигурацией. Эти источники — не выводы об инциденте Microsoft. Они дают клиентам способ превратить облачный сбой идентификации в проверяемый обзор контролей.

Обзор должен охватывать и автоматизацию корпоративного ПО. Если автоматизированные процессы используют идентификацию Microsoft для учётных записей служб, делегированных разрешений, коннекторов или административных API, сбой может создать незаметную очередь отложенных задач. Люди жалуются быстро. Автоматизированные задания могут падать тихо, повторяться, дублировать работу или ждать токен. Разбор после инцидента должен изучать журналы автоматизации, а не только пользовательские тикеты о входе. Идентификация — это не только слой доступа сотрудников; это зависимость рабочих процессов «машина — машина».

Данные тенанта должны разделять сбой входа, сеанса и приложения

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

Файл доказательств клиента должен быстро разделять эти возможности.

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

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

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

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

Третье разделение — видимость администратора против полномочий администратора. Администратор может видеть, что у Microsoft есть инцидент, но не может выполнить привилегированное действие, необходимое для изменения маршрутизации, отправки сообщений тенанта, просмотра журналов входа или открытия обращения в поддержку. Другой администратор может иметь аварийный доступ, но колебаться его применять, потому что организация не определила, кто санкционирует активацию аварийного доступа. Проверенный контроль аварийного доступа должен отвечать на оба вопроса: работает ли учётная запись и кому разрешено ею пользоваться и при каких условиях?

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

Например, организация может проверить вход нового пользователя, сценарий MFA, вход в портал администратора, критичное SaaS-приложение, задание субъекта-службы, действие управления устройствами и сообщение в канале поддержки. Без названных проверок восстановление превращается в ощущение.

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

Закупки должны явно оценивать концентрацию идентификации

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

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

Эта классификация превращает идентификацию из фонового допущения в оценённую операционную зависимость.

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

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

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

Контроль недорог по сравнению с путаницей, которую он предотвращает.

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

Последний вопрос закупок — принятие остаточного риска. Если организация решает, что крупный сбой идентификации приостановит часть работы, это может быть приемлемо. Решение должно называть затронутую работу, ожидаемую толерантность, план коммуникации с пользователями и владельца. Тихий приём риска — другое дело. Тихий приём оставляет пользователям, администраторам и советам директоров обнаруживать зависимость во время сбоя. Инцидент Azure AD сентября 2020 года остаётся ценным именно потому, что превращает эту тихую зависимость в конкретный пункт управления.

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

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

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

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

Разделение этих состояний предотвращает и несправедливые обвинения, и преждевременное закрытие.

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

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

Доказательная база для читателя

В этой статье в качестве доказательной базы для сбоя аутентификации Azure Active Directory в сентябре 2020 года, зависимости Microsoft 365, коммуникации о статусе, устойчивости идентификации, видимости администраторов, проектирования запасных путей клиента и непрерывности бизнеса и государственного сектора используются следующие публичные источники. Источники Microsoft рассматриваются как документация провайдера и контекст состояния служб. Источники СМИ рассматриваются как публичные репортажи об инциденте, а не как полное судебное доказательство.

Вопросы для совета директоров

Совет директоров или комитет по рискам не должен спрашивать только, был ли у Microsoft сбой Azure Active Directory в сентябре 2020 года. Он должен спросить, какие бизнес-процессы зависят от идентификации Microsoft, какие приложения и автоматизированные процессы падают при сбое входа, какие пути администраторов остаются доступными, какие пользователи могут работать в существующих сеансах, какие каналы состояния служб отслеживаются вне затронутого пути и какие локальные проверки доказывают восстановление.

Совет должен требовать разделения доказательств. Статус провайдера может доказать, что публично сообщила Microsoft. Журналы входа тенанта могут доказать локальное влияние. Записи API состояния служб могут доказать, что получила организация. Проверки аварийного доступа могут доказать непрерывность администраторов. Записи поддержки могут доказать коммуникацию с пользователями. Журналы процессов могут доказать, восстановилась ли автоматизация. Договорные и доверительные материалы могут задать обязательства. Ни один из этих документов не должен выполнять работу других.

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