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

Это лучшие рекомендации по обеспечению безопасности в Azure, которые корпорация Майкрософт рекомендует на основе уроков, полученных от клиентов, и наших сред.

В видеоролике с рекомендациями см. 10 лучших рекомендаций по безопасности Azure.

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

Группа должна понять, на каком пути они находятся.

Что?обучение безопасности и ИТ – специалистов в облаке Cloud Security и изменениях, которые они будут перемещать, включая:

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

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

Во многих случаях переход в облако аналогичен переходу с автономного дома на высокоскоростной люкс апартамента. У вас по-прежнему есть базовая инфраструктура (например, коммуникации и электричество) и выполняются аналогичные действия (например, соЦиализинг, приготовление, Телевизор и Интернет и т. д.). Однако часто возникают различия в том, что происходит с зданием (например, рестораны или ГИМ), которые предоставляют и поддерживают их, а также повседневную рутинную работу.

Кто. все пользователи в области безопасности и ит-организации с любыми обязанностями в области безопасности должны быть знакомы с этим контекстом и изменениями (от директора/перспективы до технических практик).

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

Корпорация Майкрософт опубликовала уроки, полученные от наших клиентов и нашей ИТ организации по их пути к облаку:

См. также контрольный тест системы безопасности Azure GS-3: Выровняйте роли Организации, обязанности и подотчетности.

2. люди. обучение групп по технологиям Cloud Security

Люди должны понимать, где они намерены.

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

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

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

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

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

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

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

Важно!

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

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

См. также контрольный тест системы безопасности Azure GS-3: Выровняйте роли Организации, обязанности и подотчетности

3. процесс: назначение отчетности для решений безопасности в облаке

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

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

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

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

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

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

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

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

Решение Описание Типичная команда
Безопасность сети Настройка и обслуживание брандмауэра Azure, сетевых виртуальных устройств (и связанных маршрутов), WAF, группы безопасности сети, ASG и т. д. Обычно группа безопасности инфраструктуры и конечных точек посвящена безопасности сети
Управление сетью выделение виртуальной сети и подсети на уровне Enterprise Существующая группа работы с сетью в Центральной ИТ эксплуатации
Безопасность конечных точек сервера Мониторинг и исправление безопасности сервера (установка исправлений, Настройка, безопасность конечных точек и т. д.) Как правило, централизованные ИТ и группы управления инфраструктурой и конечными группами могут совместно взаимодействовать
Мониторинг и реагирование на инциденты Изучите и исправьте инциденты безопасности в SIEM или исходной консоли (защитник Майкрософт для облака, Защита идентификации Azure AD и т. д.). Обычно группа " операции безопасности "
Управление политикой Задайте направление использования управления доступом на основе ролей Azure (Azure RBAC), защитника Майкрософт для облака, стратегии защиты администратора и политики Azure для управления ресурсами Azure. обычно архитектура безопасности политики и стандартов Teams совместно
Безопасность и стандарты идентификации Задать направление для каталогов Azure AD, использования PIM и PAM, многофакторной проверки подлинности, конфигурации паролей и синхронизации, стандартов удостоверений приложений обычно политики удостоверений и управления ключамииархитектура безопасности стандартов Teams совместно

Примечание

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

См. также контрольный тест системы безопасности Azure GS-3: Выровняйте роли Организации, обязанности и подотчетности

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

У вас нет времени на планирование критических аварийных ситуаций.

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

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

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

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

  • Спонсорское предложение: Этот процесс, как правило, является спонсором для модернизации или эквивалента операций безопасности.

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

    • Группа управления инцидентами или лидерство в сфере безопасности — ведет к обновлениям для обработки и интеграции ключевых внешних заинтересованных лиц, включая юридические и коммуникационные группы
    • Аналитики безопасности для операций безопасности — предоставление опыта исследования технических инцидентов и рассмотрения
    • Центральная ИТ-эксплуатация — предоставляет опыт работы с облачной платформой (напрямую, с помощью облачного центра или с помощью внешних консультантов).

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

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

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

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

  • Общая модель ответственности и облачные архитектуры: в аналитике безопасности Azure — это программный центр обработки данных, который предоставляет множество служб, включая виртуальные машины (знакомые) и другие, которые сильно отличаются от локальных, таких как База данных SQL Azure функции Azure и т. д. Где лучшие данные находятся в журналах служб или специализированных службах обнаружения угроз, а не в журналах для базовой ОС или виртуальных машин (которые обслуживаются корпорацией Майкрософт и обслуживают несколько клиентов). Аналитикам необходимо понимать и интегрировать этот контекст в ежедневные рабочие процессы, чтобы они понимали, какие данные должны быть получены, где их можно получить и какой формат будет в нем.
  • Источники данных конечной точки: получение ценной информации и данных для атак и вредоносных программ на размещенных в облаке серверах часто выполняется быстрее, проще и точнее благодаря собственным средствам обнаружения облаков, таким как защитник майкрософт для облачных решений и обнаружение и нейтрализация атак на конечные точки (EDR), в отличие от традиционных подходов прямого доступа к диску. Хотя прямой судебный доступ к дискам доступен для сценариев, где это возможно и требуется для юридических материалы (судебных расследований компьютеров в Azure), это часто самый неэффективный способ обнаружения и исследования атак.
  • Источники данных сети и удостоверений: Многие функции облачных платформ в основном используют удостоверения в основном для контроля доступа, например для доступа к портал Azure (хотя элементы управления доступом к сети также используются широко). Это требует, чтобы аналитики разработали знания о протоколах облачных удостоверений, чтобы получить полную полнофункциональную картину деятельности злоумышленников (и законных действий пользователя) для поддержки расследования инцидентов и исправления. каталоги удостоверений и протоколы также отличаются от локальных, так как обычно основаны на SAML, OAuth и openid connect Подключение и облачных каталогах, а не LDAP, Kerberos, NTLM и Active Directory, которые обычно находятся в локальной среде.
  • Упражнения : Имитация атак и реагирование может помочь в создании корпоративной памяти и технической готовности для аналитиков безопасности, скидками угроз, руководителей инцидентов и других заинтересованных лиц в Организации. Обучение в задании и адаптации — это естественная часть реагирования на инциденты, но следует поработать, чтобы максимально понять, что нужно изучить в критических случаях.

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

См. также процесс реагирования на инциденты Azure Security "IR-1: подготовка-обновление" для Azure.

5. процесс: создание управления уровнями безопасности

Сначала необходимо ознакомиться с сиселф.

Что? Следите за активностью управления средой Azure с помощью следующих средств:

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

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

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

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

Примечание

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

Кто: обычно это разделено на два набора обязанностей:

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

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

    • Ресурсы вычислений и приложений:
      • Службы приложений: Группы разработки приложений и обеспечения безопасности
      • Контейнеры: Разработка приложений, инфраструктура и ИТ-операции
      • Виртуальные машины/масштабируемые наборы/вычисление: Операции ИТ-инфраструктуры
    • Данные и ресурсы хранилища:
      • SQL/редис/дата Lake Analytics/Data Lake store: группа баз данных
      • учетные записи служба хранилища: группа служба хранилища/инфраструктуре
    • Ресурсы для идентификации и доступа:
      • Подписки: Группы идентификации
      • Key Vault: Группа "удостоверение" или "информация"/"безопасность данных"
    • Сетевые ресурсы: Группа безопасности сети
    • Безопасность IOT: Группа эксплуатации IoT

Как: безопасность — это задание для всех пользователей, но не все в настоящее время знают, насколько важно, что делать и как это сделать.

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

Важно!

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

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

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

Совет

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

См. также контрольный тест системы безопасности Azure GS-2: определение стратегии управления уровнями безопасности.

6. Технология: требуется проверка подлинности с паролем или многофакторная аутентификация

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

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

Почему: так же, как молочно-скелетные ключи не защищают дома от современного взломщика, пароли не могут защитить учетные записи от распространенных атак, которые мы увидим сегодня. Технические сведения описаны в подразделе PA $ $Word не имеет значения.

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

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

Какреализовать беспарольную или многофакторную проверку подлинности, обучать администраторам использовать ее (при необходимости) и требовать от администраторов следовать за использованием письменной политики. Это можно сделать с помощью одной или нескольких из следующих технологий:

Примечание

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

см. также идентификатор производительности системы безопасности Azure — 4. используйте надежные элементы управления проверкой подлинности для всех Azure Active Directory доступа.

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

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

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

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

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

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

Кто:

  • Спонсорское предложение: Это обновление стратегии сетевой безопасности обычно спонсорства или лидера в безопасности

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

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

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

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

Документацию по функциям безопасности сети Azure Native можно найти по адресу:

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

См. также раздел "тестирование безопасности Azure" NS-4. Защита приложений и служб от сетевых атак извне.

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

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

Что?Упростите стратегию обнаружения угроз и реагирования за счет внедрения собственных возможностей обнаружения угроз в операции безопасности и SIEM.

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

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

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

Кто. обычно это управляется группой операций по обеспечению безопасности .

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

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

См. также контрольный материал по безопасности Azure lt-1: Включение обнаружения угроз для ресурсов Azure.

9. Архитектура: стандартизация для одного каталога и удостоверения

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

Что: стандартизация в одном каталоге Azure AD и единое удостоверение для каждого приложения и пользователя в Azure (для всех корпоративных функций идентификации).

Примечание

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

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

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

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

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

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

  • Нуля: Установите и реализуйте четкую политику, которую все пересылаемые корпоративные удостоверения должны использовать один каталог Azure AD с одной учетной записью для каждого пользователя.

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

Идеальное время для консолидации использования идентификации — во время цикла разработки приложения:

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

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

см. также руководство по безопасности Azure ID-1: стандартизация Azure Active Directory в качестве центральной системы идентификации и проверки подлинности.

Важно!

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

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

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

Что? при возможности используйте удостоверения Azure AD вместо проверки подлинности на основе ключей (службы Azure, приложения, API и т. д.).

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

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

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

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

Процесс:

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

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

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

См. также раздел Контрольный код безопасности Azure — 2. безопасное и автоматическое управление удостоверениями приложений.

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

Каждому пользователю необходимо присвоить строку в том же направлении, в котором они переходят вперед.

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

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

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

  • Группа безопасности сети разрабатывает стратегию сегментирования плоской сети для повышения безопасности (часто на основе физических сайтов, назначенных адресов IP-адресов, диапазонов или аналогичных).
  • По отдельности Группа разработчиков удостоверений разработала стратегию для групп и Active Directory подразделений (OU) на основе их понимания и знаний Организации.
  • Часто группы приложений не могут работать с этими системами, так как они разрабатывались с ограниченным вводом и пониманием бизнес-операций, целей и рисков.

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

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

Кто:

  • Спонсорское предложение: Единая стратегия, как правило, сопоставлена РУКОВОДИТЕЛям, перспективы и CTO (часто с поддержкой бизнес-лидера для некоторых элементов высокого уровня) и рассматривались представителями от каждой команды.
  • Выполнение: Стратегия безопасности должна быть реализована всеми пользователями, поэтому она должна интегрировать входные данные из разных групп, чтобы увеличить владение, Купить и вероятность успеха.
    • Архитектура безопасности: позволяет создавать стратегию безопасности и результирующую архитектуру, активно собирать отзывы от групп и документировать ее в презентациях, документах и схемах для различных аудиторий.
    • Политика и стандарты: записывает соответствующие элементы в стандарты и политики, а затем отслеживает соответствие.
    • Все технические ИТ и группы по безопасности: Предоставьте требования к входным данным, а затем выровняйте и реализуйте стратегию Enterprise.
    • Владельцы и разработчики приложений: Ознакомьтесь с документацией по стратегии, которая применяется к ним (в идеале это руководство, адаптированное для их роли).

Как:

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

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

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

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

См. также руководство по контролю и стратегии производительности в Azure Security.