Защита данных в Azure AD

Здравствуйте!

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

Безопасность центров обработки данных и служб

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

Следующим шагом мы ограничиваем количество сотрудников с доступом к службам Azure AD, и даже те, у кого есть разрешения на доступ, работают без этих привилегий при выполнении своих ежедневных обязанностей после входа в систему. Когда им требуются привилегии для доступа к службе, им необходимо пройти многофакторную проверку подлинности, используя смарт-карту для подтверждения своей личности и отправки запроса. После утверждения запроса привилегии предоставляются пользователю только на определенное время (концепция JIT). Эти привилегии также автоматически отменяются через фиксированный период времени, и если его не хватило, пользователь должен снова пройти процедуру отправки и утверждения запроса.

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

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

Обнаружение угроз

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

• Обнаружение взломов. Мы проверяем систему на признаки, свидетельствующие о взломе. Этот набор признаков для обнаружения регулярно дополняется. Мы также используем автоматические проверки, которые имитируют появление таких признаков, чтобы дополнительно проверять правильность работы логики обнаружения взломов.
  
• Тесты на проникновение. Эти тесты проводятся постоянно. Они включают все возможные действия для нарушения безопасности нашей службы, и каждый раз мы надеемся на отрицательный результат. Положительный результат будет свидетельствовать о наличии ошибок, которые мы сразу же сможем исправить.
  
• Аудит. Все действия администраторов регистрируются в журналах. Любые подозрительные действия (например, создание привилегированных учетных записей) приводят к созданию оповещений и подвергаются тщательной проверке.
  

Мы уже упоминали о шифровании всех ваших данных в Azure AD? Это действительно так — все неактивные идентификационные данные в Azure AD шифруются с помощью технологии BitLocker. Как насчет передачи? Это мы тоже учли! Все API-интерфейсы Azure AD размещаются в Интернете и используют для шифрования данных SSL-протокол HTTPS. Все серверы Azure AD настроены для работы по протоколу TLS 1.2. Для поддержки внешних клиентов разрешаются входящие подключения по протоколу TLS 1.1 и 1.0. Все подключения с использованием устаревших версий протокола SSL, включая SSL 3.0 и 2.0, отклоняются. Доступ к информации контролируется с помощью авторизации на основе маркеров, и данные каждой клиентской организации доступны только тем учетным записям, которые в ней разрешены. Кроме того, в наши внутренние API-интерфейсы добавлено требование для использования проверки подлинности клиентов и серверов по протоколу SSL с помощью доверенных сертификатов и цепочек выдачи.

Заключение

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

(Примечание. Чтобы быстро понять, относится ли к вам эта публикация о защите и шифровании данных, воспользуйтесь простым правилом: если для управления службами Microsoft Online Services или доступа к ним вы используете URL-адреса, оканчивающиеся на «.com», эта информация для вас.)

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

С наилучшими пожеланиями,

Алекс Саймонс (Alex Simons), Twitter: @Alex_A_Simons

Директор по управлению разработкой программ

Подразделение идентификации Майкрософт

[Обновлено 03.10.2017: добавлены сведения о версиях протоколов TLS и SSL.]