Рекомендации по созданию стратегии сегментации

Применяется к рекомендации по контрольным спискам безопасности для хорошо спроектированной платформы:

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

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

Определения 

Основные стратегии проектирования

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

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

• Подписки, которые изолируют рабочие нагрузки организации
• Группы ресурсов, которые изолируют ресурсы рабочей нагрузки
• Среды развертывания, которые изолируют развертывание по этапам
• Команды и роли, которые изолируют функции заданий, связанные с разработкой рабочих нагрузок и управлением ими
• Уровни приложений, которые изолируются по служебной программе рабочей нагрузки
• Микрослужбы, которые изолируют одну службу от другой

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

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

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

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

Важно отметить различие между периметрами и изоляцией. Периметр ссылается на точки расположения, которые следует проверить. Изоляция — это группирование. Активно содержат атаку, используя эти понятия вместе.

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

Компромисс. Сегментация представляет сложность, так как в управлении есть издержки. Есть также компромисс в стоимости. Например, дополнительные ресурсы подготавливаются при сегментации сред развертывания, которые выполняются параллельно.

Риск. Микро-сегментация за пределы разумного предела теряет преимущество изоляции. При создании слишком большого количества сегментов становится трудно определить точки взаимодействия или разрешить допустимые пути связи в сегменте.

Установка удостоверения в качестве основного периметра безопасности

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

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

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

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

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

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

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

Управление доступом на основе ролей (RBAC) также приводит к затратам на управление. Отслеживание удостоверений и их областей доступа может стать сложным в назначениях ролей. Решение заключается в назначении ролей группам безопасности вместо отдельных удостоверений.

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

Сведения об элементах управления удостоверениями см. в разделе "Управление удостоверениями и доступом".

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

Улучшение сети в качестве периметра

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

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

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

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

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

Общие шаблоны, связанные с сегментацией сети, см. в разделе "Шаблоны сегментации сети".

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

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

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

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

Сведения о сетевых элементах управления см. в разделе "Сеть" и "Подключение".

Определение ролей и очистка линий ответственности

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

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

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

Риск. Членство в группах может меняться со временем, когда сотрудники присоединяются к командам или покидают команды или изменяют роли. Управление ролями в разных сегментах может привести к затратам на управление.

Упорядочение ресурсов для повышения сегментации

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

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

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

Упрощение функций Azure

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

Идентификация

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

Дополнительные сведения см. в рекомендациях по RBAC.

Сеть

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

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

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

Брандмауэр Azure: облачная служба, которая может быть развернута в виртуальной сети или в развертываниях Центра Виртуальная глобальная сеть Azure. Используйте Брандмауэр Azure для фильтрации трафика между облачными ресурсами, Интернетом и локальными ресурсами. Используйте Брандмауэр Azure или диспетчер Брандмауэр Azure для создания правил или политик, которые позволяют или запрещают трафик с помощью элементов управления уровня 3 до уровня 7. Фильтрация интернет-трафика с помощью Брандмауэр Azure и третьих сторон путем направления трафика через сторонних поставщиков безопасности для расширенной фильтрации и защиты пользователей. поддержка Azure развертывание виртуального сетевого устройства, которое помогает сегментации от сторонних брандмауэров.

Пример

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

В этом примере используется среда ИТ-технологий, созданная в базовом плане безопасности (SE:01). На схеме ниже показана сегментация на уровне группы управления, выполняемой организацией.

Шаблоны сегментации удостоверений

Шаблон 1. Группирование на основе заголовка задания

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

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

Шаблон 2. Группирование на основе функций

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

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

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

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

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

Шаблон 2 рекомендуется сделать шаблон доступа фокусом, а не организационной диаграммой. Организационные диаграммы и роли-члены иногда изменяются. Запись управления удостоверениями и доступом рабочей нагрузки с функциональной точки зрения позволяет абстрагировать организацию группы от безопасного управления рабочей нагрузкой.

Шаблоны сегментации сети

Шаблон 1. Сегментация в рабочей нагрузке (мягкие границы)

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

Шаблон 2. Сегментация в рабочей нагрузке

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

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

Организация ресурсов

Упорядочение ресурсов Azure на основе ответственности за владение

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

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

Хорошая стратегия сегментации позволяет легко определить владельцев каждого сегмента. Рекомендуется использовать теги ресурсов Azure для анимации групп ресурсов или подписок с командой владельца.

Настройка и проверка управления доступом

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

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

Дополнительные ссылки

• Изоляция в общедоступном облаке Azure
• Рекомендации по RBAC
• Общие сведения о виртуальных сетях
• ASG
• Брандмауэр Azure
• Обзор диспетчера брандмауэра

Контрольный список по безопасности

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