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

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

Видео-презентация см. в статье Рекомендации по обеспечению безопасности Azure.

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

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

Что?

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

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

Почему?

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

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

Кто?

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

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

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

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

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

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

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

Что?

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

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

Почему?

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

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

Кто?

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

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

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

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

Важно!

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

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

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

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

Что?

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

Почему?

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

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

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

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

Кто?

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

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

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

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

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

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

Примечание

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

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

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

Что?

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

Почему?

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

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

Кто?

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

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

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

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

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

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

  • Процессы и сборники схем. Адаптируйте существующие процессы расследования, исправления и обнаружения угроз под особенности облачных платформ. Эти особенности связаны с другими инструментами, источниками данных, протоколами удостоверений и т. д.
  • Обучение. Организуйте для аналитиков обучение по общим принципам облачной трансформации, техническим деталям работы платформ и новым или обновленным процессам. Эти сведения позволяют им узнать, что может измениться и где можно найти то, что им нужно.
  • Ключевые области. Хотя в ссылках на ресурсы описано много деталей, в этих областях можно сосредоточить усилия в области образования и планирования.
    • Модель общей ответственности и облачные архитектуры. Для аналитика безопасности Azure представляет собой программно-определяемый центр обработки данных, который предоставляет множество служб. К этим службам относятся виртуальные машины и другие, отличные от локальных, например Функции Azure базы данных Azure SQL. Лучшие данные находятся в журналах служб или специализированных службах обнаружения угроз. Их не найти в журналах для базовой ОС или виртуальных машин, которые обслуживаются Майкрософт и предназначены для нескольких клиентов. Аналитикам необходимо понимать и интегрировать этот контекст в ежедневные рабочие процессы. Таким образом, они узнают, какие данные ожидать, где их можно получить и в каком они формате.
    • Источники данных конечных точек. Получение аналитических сведений и данных для атак и вредоносных программ на облачных серверах часто выполняется быстрее, проще и точнее с помощью собственных средств обнаружения в облаке. Такие средства, как 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, data lake store: команда по базам данных
      • Учетные записи хранения: команда по хранению и инфраструктуре
    • Ресурсы удостоверений и доступа
      • Подписки: команды удостоверений
      • Хранилище ключей: группа безопасности удостоверений или информации и данных
    • Сетевые ресурсы: команда безопасности сети
    • Безопасность Интернета вещей: команда обслуживания Интернета вещей

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

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

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

Важно!

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

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

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

Совет

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

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

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

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

Что?

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

Почему?

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

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

Кто?

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

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

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

Примечание

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

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

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. Архитектура. Стандартизация процесса с помощью использования одного каталога и одного удостоверения

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

Что?

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

Примечание

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

Почему?

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

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

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

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

Кто?

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

Что?

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

Почему?

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

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

Кто?

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

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

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

Процесс

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

Технологии

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

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

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

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

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

Что?

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

Почему?

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

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

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

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

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

Кто?

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

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

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

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

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

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

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