Поделиться через

Рекомендации по обеспечению безопасности в Azure

  • Статья

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

Сведения о видеоматериале см . в рекомендациях по обеспечению безопасности Azure.

1. Люди. Проводите обучение по безопасности в облаке

Сотрудники должны понимать, что их ожидает и что от них требуется.

Что?

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

  • Угрозы в облаке.
  • Модель общей ответственности и как она влияет на безопасность
  • Изменения языка и региональных ролей и обязанностей, которые обычно приходят с внедрением облака

Почему?

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

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

Кто?

Все специалисты по безопасности и ИТ-организации с любой ответственностью за безопасность, от ИТ-отдела или CISO до технических специалистов, должны быть знакомы с изменениями.

Как это сделать?

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

Майкрософт опубликовала следующие выводы, которые сделали клиенты и ИТ-организации во время перехода в облако.

Дополнительные сведения см. в ролях, обязанностях и подотчетности Azure Security Benchmark.

2. Люди. Обучение сотрудников по технологиям безопасности в облаке

Люди должны понимать, в каком направлении они движутся.

Что?

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

  • Облачные технологии и технологии безопасности облака.
  • Рекомендуемые конфигурации и рекомендации.
  • Где можно получить дополнительные технические сведения.

Почему?

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

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

Кто?

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

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

Как это сделать?

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

Важно!

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

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

3. Процесс. Назначение ответственных за принятие решений по безопасности в облаке

Решения по безопасности не будут приниматься, если никто не отвечает за их принятие.

Что?

Выберите, кто отвечает за принятие каждого типа решений по обеспечению безопасности для корпоративной среды Azure.

Почему?

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

  • Бизнес-цели
  • Сроки разработки.
  • Цели ИТ.
  • Гарантии безопасности.

Разногласия могут привести к следующим проблемам:

  • Остановленные проекты, ожидающие утверждения по безопасности.
  • Небезопасные развертывания, которые не могли ждать утверждения по безопасности.

Кто?

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

Как это сделать?

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

Задокументируйте этих владельцев и их контактные данные и сообщите эту информацию командам по безопасности, ИТ и облаку. Это позволит всем заинтересованным лицам связываться с ними.

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

Решение Description Команда
Сетевая безопасность Настройте и поддерживайте Брандмауэр Azure, виртуальные сетевые (модуль) и связанные маршрутизации, Брандмауэр веб-приложений (WAFs), группы безопасности сети, ASG и т. д. Команда по безопасности инфраструктуры и конечных точек занимается безопасностью сети
Управление сетями Управление корпоративными виртуальными сетями и выделение подсетей. Существующая группа сетевых операций в центральных ИТ-операциях
Безопасность конечных точек сервера Мониторинг и исправление нарушений безопасности сервера, включая установку исправлений, настройку, защиту конечных точек и т. д. Централизованные ИТ-операции и группы безопасности конечных точек совместно
Мониторинг инцидентов и реагирование на них Изучите и исправьте инциденты безопасности в SIEM или исходной консоли, включая Microsoft Defender для облака, Защита идентификации Microsoft Entra и т. д. Команда операций безопасности
Управление политикой Задайте направление использования управления доступом на основе ролей Azure (Azure RBAC), Defender для облака, стратегии защиты администраторов и Политика Azure для управления ресурсами Azure. Группы по вопросам политики и стандартов и архитектуры безопасности совместно
Безопасность и стандарты идентификации Задайте направление для каталогов Microsoft Entra, PIM/pam usage, многофакторной проверки подлинности, конфигурации паролей и синхронизации, стандартов удостоверений приложения. Совместное управление удостоверениями и ключами, политика и стандарты и команды по архитектуре безопасности

Примечание.

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

4. Процесс. Обновление процессов реагирования на инциденты для облака

Спланируйте заранее. В случае кризиса у вас не будет времени на планирование.

Что?

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

Почему?

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

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

Кто?

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

  • Спонсорство. Директор по безопасности или аналогичный руководитель обычно выступает спонсором модернизации процессов.

  • Выполнение: адаптация существующих процессов или их запись в первый раз — это совместная работа с участием:

    • Команда операций безопасности. Команда управления инцидентами или ее руководитель управляют процессом и уведомляют ключевых сторонних заинтересованных лиц. Например, юридический отдел, отдел коммуникаций или отдел по связям с общественностью.
    • Команда операций безопасности. Аналитики безопасности консультируют по вопросам расследования технических инцидентов и расстановки приоритетов.
    • Центральный отдел ИТ-сопровождения: Эта команда предоставляет консультации по облачной платформе напрямую, через центр передовых знаний об облаке или сторонних консультантов.

Как это сделать?

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

  • Процессы и сборники схем. Адаптируйте существующие процессы расследования, исправления и обнаружения угроз под особенности облачных платформ. Эти особенности связаны с другими инструментами, источниками данных, протоколами удостоверений и т. д.
  • Обучение. Организуйте для аналитиков обучение по общим принципам облачной трансформации, техническим деталям работы платформ и новым или обновленным процессам. Эти сведения позволяют им узнать, что может измениться и где можно найти то, что им нужно.
  • Ключевые области внимания: хотя в ссылках на ресурсы описано много деталей, эти области предназначены для фокусировки усилий по обучению и планированию:
    • Модель общей ответственности и облачные архитектуры. Для аналитика безопасности Azure представляет собой программно-определяемый центр обработки данных, который предоставляет множество служб. К этим службам относятся виртуальные машины и другие, отличные от локальных, например База данных SQL Azure Функции Azure. Лучшие данные находятся в журналах служб или специализированных службах обнаружения угроз. Их не найти в журналах для базовой ОС или виртуальных машин, которые обслуживаются Майкрософт и предназначены для нескольких клиентов. Аналитикам необходимо понимать и интегрировать этот контекст в ежедневные рабочие процессы. Таким образом, они узнают, какие данные ожидать, где их можно получить и в каком они формате.
    • Источники данных конечных точек: получение аналитических сведений и данных для атак и вредоносных программ на облачных серверах часто быстрее, проще и точнее с помощью собственных средств обнаружения облака. Такие средства, как Microsoft Defender для облака и решения для обнаружения угроз на конечных точках и реагирования на них (EDR) предоставляют более точные данные, чем традиционные подходы с прямым доступом к диску. Форензика с исследованием дисков доступна по возможности, если это необходимо в юридических целях. Дополнительные сведения см. в статье о судебной экспертизе компьютеров в Azure. Однако часто этот подход является самым неэффективным способом обнаружения и расследования атак.
    • Источники данных о сети и удостоверениях. Многие функции облачных платформ, в основном, используют удостоверения для контроля доступа. Этот метод управления доступом включает доступ к порталу Azure, хотя средства управления доступом к сети также широко используются. Для использования этого метода управления доступом аналитики должны понимать протоколы облачных удостоверений, чтобы получить полную картину действий злоумышленника и легитимной активности пользователей для поддержки расследования инцидентов и исправления. Каталоги удостоверений и протоколы отличаются от существующих в локальной среде. Обычно они основаны на SAML, OAuth и OpenID Connect и облачных каталогах, а не LDAP, Kerberos, NTLM и Active Directory.
    • Практические упражнения. Имитация атаки и реагирования может помочь построить техническую память и техническую готовность организации. Они позволяют подготовить аналитиков безопасности, специалистов, занимающихся активным поиском угроз, менеджеров по инцидентам и других заинтересованных лиц в организации. Обучение на рабочем месте и адаптация — это естественная часть реагирования на инциденты, но вы можете постараться как следует подготовиться к кризису, чтобы допускать меньше ошибок.

Основные ресурсы

Дополнительные сведения см. в процессе реагирования на инциденты Azure Security Benchmark для Azure.

5. Процесс. Организация управления состоянием безопасности

Сначала необходимо изучить состояние безопасности в организации.

Что?

Убедитесь, что вы активно управляете состоянием безопасности среды Azure, выполняя следующие действия:

  • Назначение четкой собственности на обязанности:
    • Мониторинг состояния безопасности
    • Устранение рисков для ресурсов
  • Автоматизация и упрощение этих задач.

Почему?

Быстрое выявление и устранение общих угроз безопасности значительно сокращает риски для организации.

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

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

Примечание.

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

Кто?

Эта методика обычно делится на два набора обязанностей:

  • Управление состоянием безопасности. Эта функция часто является развитием существующих процессов управления уязвимостями или системы управления. Результат включает мониторинг общего состояния безопасности с помощью оценки безопасности Microsoft Defender для облака и других источников данных. Он включает в себя активную работу с владельцами ресурсов, чтобы снизить риски и сообщить о рисках руководителям по безопасности.

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

    • Ресурсы вычислений и приложений
      • Службы приложений: команды разработки приложений и безопасности
      • Контейнеры: команды разработки приложений или инфраструктуры и ИТ-операций
      • Виртуальные машины, масштабируемые наборы, вычислительные ресурсы: ОПЕРАЦИИ ИТ/инфраструктуры
    • Данные и ресурсы хранилища
      • SQL, Redis, Data Lake Analytics, хранилище озера данных: команда базы данных
      • учетные записи служба хранилища: команда служба хранилища и инфраструктуры
    • Ресурсы удостоверений и доступа
      • Подписки: команды удостоверений
      • Хранилище ключей: группа безопасности удостоверений или сведений или данных
    • Сетевые ресурсы: команда безопасности сети
    • Безопасность Интернета вещей: команда обслуживания Интернета вещей

Как это сделать?

Безопасность — это забота каждого. Однако не все знают, насколько она важна, что надо делать и как это сделать.

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

Важно!

Причины и способы защиты ресурсов часто похожи для различных типов ресурсов и приложений, но важно давать объяснения по тем ресурсам, которые команда знает и которые ей важны. Команды безопасности должны работать с командами ИТ и DevOps в качестве консультантов и партнеров, которые помогают им добиться успеха.

Инструментарий. Оценка безопасности в Microsoft Defender для облака позволяет оценить наиболее важные сведения о безопасности в Azure для широкого спектра активов. Эта оценка может быть отправной точкой для управления состоянием и может быть дополнена настраиваемыми политиками Azure и другими механизмами.

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

Совет

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

Дополнительные сведения см. в стратегии управления безопасностью Azure Security Benchmark.

6. Технология. Настройте обязательный вход без пароля или многофакторную проверку подлинности

Вы готовы рискнуть и понадеяться, что профессиональные злоумышленники не смогут угадать или украсть пароль администратора?

Что?

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

Почему?

Так же, как антикварные скелетные ключи не будут защищать дом от современных краж, пароли не могут защитить учетные записи от распространенных атак. Технические сведения см. в разделе "Ваш pa$$word" не имеет значения.

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

Кто?

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

Как это сделать?

Реализуйте проверку подлинности без пароля или многофакторную проверку подлинности. Обучите администраторов использовать его по мере необходимости и требовать от администраторов следовать с помощью письменной политики. Используйте одну или несколько этих технологий:

Примечание.

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

Дополнительные сведения см. в элементах управления строгой проверкой подлинности Azure Security Benchmark для всех доступа на основе идентификаторов Microsoft Entra.

7. Технология. Интеграция нативного брандмауэра и сетевой безопасности

Упростите защиту систем и данных от сетевых атак.

Что?

Упростите стратегию и обслуживание безопасности сети, интегрировав Брандмауэр Azure, брандмауэр веб-приложения Azure (WAF) и средства защиты от атак DDoS в свой подход к сетевой безопасности.

Почему?

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

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

Эта практика позволяет специалистам направить освободившееся время на решение более важных задач, например:

  • Оценка безопасности служб Azure.
  • Автоматизация операций безопасности.
  • Интеграция безопасности в приложения и ИТ-решения.

Кто?

  • Спонсорство: руководство по безопасности или ИТ-руководство обычно спонсирует обновление стратегии безопасности сети.
  • Выполнение. Интеграция стратегий в стратегию облачной сетевой безопасности — это совместная работа с участием:
    • Команда архитектуры безопасности. Создайте архитектуру облачной безопасности сети с помощью руководителей по облачной сети и облачной безопасности сети.
    • Облачная сеть ведет централизованные ИТ-операции и группа безопасности облачной сети ведет группу безопасности инфраструктуры
      • Создайте архитектуру безопасности облачной сети с помощью архитекторов системы безопасности.
      • Настройте возможности брандмауэра, NSG и WAF и работайте с архитекторами приложений над правилами WAF.
    • Архитекторы приложений. Работайте с командой безопасности сети для создания и корректировки наборов правил WAF и конфигураций средств защиты от атак DDoS для защиты приложения без ущерба для доступности

Как это сделать?

Организациям, которые хотят упростить операции, доступно два варианта:

  • Расширение существующих возможностей и архитектур. Многие организации часто предпочитают использовать существующие возможности брандмауэра, чтобы применять имеющиеся навыки и интеграции процессов, особенно на начальных этапах внедрения облака.
  • Использование нативных средств управления безопасностью. Все больше организаций начинают переходить на нативные средства управления, чтобы не тратить усилия на интеграцию сторонних инструментов. Как правило, эти организации стремятся избежать риска неправильной настройки в балансировке нагрузки, определяемых пользователем маршрутах, брандмауэре или WAF, и задержках в разных технических командах. Этот вариант подходит для организаций, которые используют подход "инфраструктура как код", так как автоматизировать и инструментировать встроенные возможности проще, чем сторонние.

Документацию по нативным функциям безопасности сети Azure можно найти в следующих источниках:

Azure Marketplace включает многие сторонние поставщики брандмауэра.

Дополнительные сведения см. в статье "Защита от атак DDOS в Azure Security Benchmark" и защита брандмауэра веб-приложений.

8. Технология. Интеграция нативных средств обнаружения угроз

Упростите обнаружение атак на системы и данные Azure и реагирование на эти атаки.

Что?

Упростите стратегию обнаружения угроз и реагирования на них, включив нативные возможности обнаружения угроз в операции безопасности и SIEM.

Почему?

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

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

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

Кто?

Обычно управляется командой операций безопасности.

  • Спонсорство. Обычно спонсором становится директор по операциям безопасности или его эквивалент.
  • Выполнение. Интеграция собственного обнаружения угроз — это совместная работа, связанная с этими решениями:
    • Операции безопасности. Интеграция оповещений в процессы SIEM и исследования инцидентов. Команда операций безопасности может проводить для аналитиков обучение по оповещениями в облаке и использованию нативных облачных инструментов.
    • Подготовка к инцидентам. Проводите учебные тревоги по инцидентам в облаке, чтобы подготовиться к реальной ситуации.
    • Аналитика угроз. Исследование и интеграция информации об атаках в облаке для предоставления командам контекста и аналитики.
    • Архитектура безопасности. Интеграция нативных средств в документацию по архитектуре безопасности.
    • Политика и стандарты. Задайте стандарты и политику для включения нативных средств по всей организации. Отслеживайте соответствие требованиям.
    • Инфраструктура и конечная точка и центральные ИТ-операции: настройка и включение обнаружения, интеграция в автоматизацию и инфраструктуру в качестве решений кода.

Как это сделать?

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

Дополнительные сведения см. в статье об обнаружении угроз Azure Security Benchmark для ресурсов Azure.

9. Архитектура. Стандартизация процесса с помощью использования одного каталога и одного удостоверения

Никто не хочет работать с несколькими удостоверениями и каталогами.

Что?

Стандартизация в одном каталоге Microsoft Entra. Вы можете стандартизировать одно удостоверение для каждого приложения и пользователя в Azure.

Примечание.

Эта рекомендация относится только к корпоративным ресурсам. Для учетных записей партнеров используйте Microsoft Entra B2B , чтобы вам не пришлось создавать и поддерживать учетные записи в каталоге. Для учетных записей клиентов или граждан используйте Azure AD B2C для управления ими.

Почему?

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

  • Офисные пользователи
  • Разработчики
  • Администраторы ИТ и удостоверений
  • Аналитики безопасности
  • Другие роли

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

Хотя иногда кажется, что проще быстро создать пользовательский каталог LDAP для конкретного приложения или рабочей нагрузки, впоследствии потребуется делать лишнюю работу по интеграции и управлению. Эта работа аналогична настройке дополнительного клиента Azure или локального леса Active Directory вместо использования существующего корпоративного клиента. Дополнительные сведения см. в статье Важность простоты для обеспечения безопасности.

Кто?

Стандартизация в одном каталоге Microsoft Entra часто является кросс-командной работой. Обычно этим занимаются команды архитектуры безопасности или управления удостоверениями и ключами.

Как это сделать?

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

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

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

Идеальное время для объединения удостоверений — циклы разработки приложений, когда вы:

  • Модернизируете приложения для облака.
  • Обновляете облачные приложения с помощью процессов DevOps.

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

Дополнительные сведения см. в центре удостоверений и проверки подлинности Microsoft Entra в Azure Security Benchmark.

Важно!

Единственным исключением из правила отдельных учетных записей является то, что привилегированные пользователи, включая ИТ-администраторов и аналитиков безопасности, могут иметь отдельные учетные записи для стандартных задач пользователей по сравнению с административными задачами.

Дополнительные сведения см. в статье Azure Security Benchmark Привилегированный доступ.

10. Архитектура. Использование управления доступом на основе удостоверений вместо ключей

Что?

Используйте удостоверения Microsoft Entra вместо проверки подлинности на основе ключей везде, где это возможно. Например, службы Azure, приложения, API.

Почему?

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

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

Кто?

Реализация управления доступом на основе удостоверений часто требует участия разных команд. Обычно этим занимаются команды архитектуры безопасности или управления удостоверениями и ключами.

Как это сделать?

Настройка предпочтений организации и воспитание привычки использовать проверку подлинности на основе удостоверений требует отдельных процессов и технологий.

Процесс

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

Технологии

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

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

Дополнительные сведения см. в удостоверениях приложений Azure Security Benchmark.

11. Архитектура. Создание единой единой стратегии безопасности

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

Что?

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

Почему?

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

Одним из примеров такой изоляции, которая проявляется во многих организациях, является сегментация ресурсов:

  • Команда безопасности сети разрабатывает стратегию сегментирования плоской сети. Эта стратегия повышает безопасность, часто на основе физических узлов, назначенных IP-адресов и диапазонов или аналогичных элементов.
  • Команда удостоверений разрабатывает стратегию для групп и подразделений Active Directory на основе своего понимания и знаний об организации.
  • Команды приложений с трудом работают с этими системами. Сложность в том, что они разрабатывались на основе ограниченных данных о бизнес-операциях, целях и рисках.

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

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

Кто?

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

Как это сделать?

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

  • Мнения команд. Обычно стратегии не приводят к успеху, если сотрудники не убеждены в их эффективности. В идеале следует собрать все команды в одной комнате, чтобы вместе выработать стратегию. На семинарах, которые мы проводим с клиентами, мы часто обнаруживаем, что команды в организациях работают изолированно друг от друга, и на таких собраниях люди встречаются впервые. Мы считаем инклюзивность обязательным требованием. Если некоторые команды не приглашены, обычно такие собрания приходится проводить еще раз, пока на них не придут все участники. Пока они не придут, проект не сдвинется с места.
  • Четкое документирование и обмен информацией. Все команды должны знать о стратегии безопасности. В идеале стратегия безопасности должна быть компонентом общей технологической стратегии. Эта стратегия описывает, зачем нужно интегрировать безопасность, почему безопасность важна и к какому состоянию безопасности стремится организация. Эта стратегия включает в себя конкретные рекомендации для команд приложений и разработчиков, чтобы им не пришлось читать всю документацию, большая часть которой к ним не относится.
  • Сочетание стабильности и гибкости. Постарайтесь обеспечить согласованность и стабильность стратегий, но архитектуры и документация должны давать дополнительные разъяснения и учитывать динамическую природу облака. Например, фильтрация вредоносного внешнего трафика должна обеспечиваться даже при переходе со стороннего брандмауэра следующего поколения на брандмауэр Azure и изменении схем и рекомендаций по их использованию.
  • Начните с сегментации: существуют проблемы стратегии как с большими, так и небольшими для решения, но вам нужно начать где-то. Запустите стратегию безопасности с сегментацией корпоративных активов. Такая сегментация является базовым решением, и ее сложно будет изменить позже, поэтому тут требуется участие бизнес-специалистов и технических команд.

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

Cloud Adoption Framework включает рекомендации, которые помогут вашим командам выполнять следующие задачи:

Дополнительные сведения см. в стратегии управления Azure Security Benchmark.