Рекомендации по построению стратегии сегментации
Применяется к рекомендации по контрольным спискам безопасности Well-Architected Framework:
| SE:04 | Создайте преднамеренную сегментацию и периметры в архитектуре, а также занимаемое рабочей нагрузкой место на платформе. Стратегия сегментации должна включать сети, роли и обязанности, удостоверения рабочей нагрузки и организацию ресурсов. |
|---|
Сегмент — это логический раздел решения, который необходимо защитить как единое целое. Стратегия сегментации определяет, как одна единица должна быть отделена от других, используя собственный набор требований и мер безопасности.
В этом руководстве описываются рекомендации по созданию единой стратегии сегментации. Используя периметры и границы изоляции в рабочих нагрузках, вы можете разработать подход к обеспечению безопасности, который подходит вам.
Определения
| Термин | Определение |
|---|---|
| Containment | Метод для сдерживания радиуса взрыва, если злоумышленник получает доступ к сегменту. |
| Доступ с минимальными привилегиями | Принцип "Никому не доверяй", направленный на минимизацию набора разрешений для выполнения функции задания. |
| Периметр | Граница доверия вокруг сегмента. |
| Организация ресурсов | Стратегия группировки связанных ресурсов по потокам в сегменте. |
| Роль | Набор разрешений, необходимых для выполнения функции задания. |
| Segment | Логическая единица, изолированная от других сущностей и защищенная набором мер безопасности. |
Ключевые стратегии проектирования
Концепция сегментации обычно используется для сетей. Однако один и тот же базовый принцип можно использовать в решении, включая сегментирование ресурсов для целей управления и управления доступом.
Сегментация помогает разработать подход к обеспечению безопасности, который применяет глубинную защиту на основе принципов модели "Никому не доверяй". Убедитесь, что злоумышленник, который взломает один сегмент сети, не может получить доступ к другому, сегментируя рабочие нагрузки с разными элементами управления удостоверениями. В защищенной системе атрибуты удостоверений и сети блокируют несанкционированный доступ и скрывают доступ к ресурсам. Ниже приведены некоторые примеры сегментов.
- Подписки, которые изолируют рабочие нагрузки организации
- Группы ресурсов, которые изолируют ресурсы рабочей нагрузки
- Среды развертывания, которые изолируют развертывание по этапам
- Команды и роли, которые изолируют функции заданий, связанные с разработкой рабочих нагрузок и управлением ими
- Уровни приложений, которые изолируются с помощью служебной программы рабочей нагрузки
- Микрослужбы, которые изолируют одну службу от другой
Рассмотрим следующие ключевые элементы сегментации, чтобы убедиться, что вы создаете комплексную стратегию глубинной защиты:
Граница или периметр — это граница входа сегмента, в котором применяются элементы управления безопасностью. Элементы управления периметром должны блокировать доступ к сегменту, если это не разрешено явным образом. Цель состоит в том, чтобы злоумышленник не прорваться через периметр и получить контроль над системой. Например, уровень приложения может принимать маркер доступа конечного пользователя при обработке запроса. Но для уровня данных может потребоваться другой маркер доступа, имеющий определенное разрешение, которое может запрашивать только уровень приложения.
Автономность — это край выхода сегмента, который предотвращает боковое смещение в системе. Цель сдерживания заключается в том, чтобы свести к минимуму последствия нарушения. Например, виртуальную сеть Azure можно использовать для настройки маршрутизации и групп безопасности сети, чтобы разрешить только ожидаемые шаблоны трафика, избегая передачи трафика в произвольные сегменты сети.
Изоляция — это практика группировки сущностей с аналогичными гарантиями для защиты их с помощью границы. Цель — простота управления и сдерживание атаки в среде. Например, можно сгруппировать ресурсы, относящиеся к определенной рабочей нагрузке, в одну подписку Azure, а затем применить управление доступом, чтобы только определенные команды рабочей нагрузки могли получить доступ к подписке.
Важно отметить различие между периметром и изоляцией. Периметр — это точки расположения, которые должны быть проверены. Изоляция — это группирование. Активное сдерживание атаки, используя эти понятия вместе.
Изоляция не означает создание изолированных объектов в организации. Единая стратегия сегментации обеспечивает согласованность между техническими командами и устанавливает четкие границы ответственности. Clarity снижает риск человеческих ошибок и сбоев автоматизации, которые могут привести к уязвимостям системы безопасности, рабочему простою или и тому, и тому, и другое. Предположим, что в компоненте сложной корпоративной системы обнаружено нарушение безопасности. Важно, чтобы все понимали, кто несет ответственность за этот ресурс, чтобы соответствующий человек был включен в группу рассмотрения. Организация и заинтересованные лица могут быстро определить, как реагировать на различные виды инцидентов, создавая и документируя хорошую стратегию сегментации.
Компромисс: сегментация усложняется, так как в управлении возникают издержки. Существует также компромисс в стоимости. Например, при сегментации сред развертывания, которые выполняются параллельно, подготавливаются дополнительные ресурсы.
Риск. Микросекционация, превышающая разумный предел, теряет преимущество изоляции. При создании слишком большого количества сегментов становится трудно определить точки связи или разрешить допустимые пути связи в пределах сегмента.
Удостоверения как периметр
Различные удостоверения, такие как люди, компоненты программного обеспечения или устройства, получают доступ к сегментам рабочей нагрузки. Удостоверение — это периметр, который должен быть основной линией защиты для проверки подлинности и авторизации доступа через границы изоляции, независимо от того, откуда исходит запрос на доступ. Используйте удостоверение в качестве периметра для выполнения:
Назначение доступа по роли. Удостоверениям нужен только доступ к сегментам, необходимым для выполнения своей работы. Сведите к минимуму анонимный доступ, понимая роли и обязанности запрашивающего удостоверения, чтобы узнать сущность, которая запрашивает доступ к сегменту и с какой целью.
Удостоверение может иметь разные области доступа в разных сегментах. Рассмотрим типичную настройку среды с отдельными сегментами для каждого этапа. Удостоверения, связанные с ролью разработчика, имеют доступ на чтение и запись в среду разработки. По мере перехода развертывания на промежуточное хранение эти разрешения ограничиваются. К тому времени, когда рабочая нагрузка будет повышена до рабочей среды, область для разработчиков становится доступом только для чтения.
Рассмотрите возможность использования удостоверений приложений и управления отдельно. В большинстве решений уровень доступа пользователей отличается от уровня доступа разработчиков или операторов. В некоторых приложениях для каждого типа удостоверения можно использовать разные системы идентификации или каталоги. Рассмотрите возможность использования областей доступа и создания отдельных ролей для каждого удостоверения.
Назначьте доступ с минимальными привилегиями. Если удостоверению разрешен доступ, определите уровень доступа. Начните с наименьших привилегий для каждого сегмента и расширяйте область только при необходимости.
Применяя минимальные привилегии, вы ограничиваете негативные последствия, если удостоверение когда-либо скомпрометировано. Если доступ ограничен по времени, область атаки уменьшается. Ограниченный по времени доступ особенно применим к критически важным учетным записям, таким как администраторы или компоненты программного обеспечения с скомпрометированной идентификацией.
Управление доступом на основе ролей (RBAC) также приводит к дополнительным затратам на управление. Отслеживание удостоверений и их областей доступа может усложняться при назначении ролей. Обходной путь — назначить роли группам безопасности, а не отдельным удостоверениям.
Дополнительные сведения об элементах управления удостоверениями см. в разделе Управление удостоверениями и доступом.
В отличие от элементов управления доступом к сети, удостоверение проверяет управление доступом во время доступа. Настоятельно рекомендуется проводить регулярную проверку доступа и требовать рабочего процесса утверждения, чтобы получить привилегии для учетных записей критического воздействия. Например, см. раздел Шаблоны сегментации удостоверений.
Сеть как периметр
Периметры удостоверений не зависят от сети, в то время как периметры сети дополняют удостоверение, но никогда не заменяют его. Периметры сети устанавливаются для управления радиусом взрыва, блокировки неожиданного, запрещенного и небезопасного доступа, а также маскировки ресурсов рабочей нагрузки.
Хотя основной задачей периметра удостоверений являются минимальные привилегии, следует предположить, что при проектировании периметра сети возникнет нарушение.
Создавайте программно-определяемые периметры в сетевом пространстве с помощью служб и функций Azure. Когда рабочая нагрузка (или части данной рабочей нагрузки) помещается в отдельные сегменты, вы управляете трафиком из этих сегментов или в них для защиты путей связи. Если сегмент скомпрометирован, он содержится и не допускается боковое распространение по остальной части вашей сети.
Думайте, как злоумышленник, чтобы закрепиться в рабочей нагрузке и установить элементы управления, чтобы свести к минимуму дальнейшее расширение. Элементы управления должны обнаруживать, содержать и останавливать доступ злоумышленников ко всей рабочей нагрузке. Ниже приведены некоторые примеры элементов управления сетью в качестве периметра.
- Определите периметр границы между общедоступными сетями и сетью, в которой размещена рабочая нагрузка. Максимально ограничьте прямую видимость от общедоступных сетей к сети.
- Реализуйте демилитаризованные зоны (DMZ) перед приложением с соответствующими элементами управления через брандмауэры.
- Создайте микросемпцию в частной сети, группируя части рабочей нагрузки на отдельные сегменты. Установите безопасные пути связи между ними.
- Создание границ на основе намерения. Например, сегментируйте функциональные сети рабочей нагрузки из операционных сетей.
Общие шаблоны, связанные с сегментацией сети, см. в разделе Шаблоны сегментации сети.
Частное подключение изменяет архитектуру архитектуры, часто добавляя дополнительные компоненты, такие как блоки перехода для частного доступа к вычислительным узлам.
Так как периметры сети основаны на контрольных точках или прыжках в сети, каждый прыжок может быть потенциальной точкой отказа. Эти точки могут повлиять на надежность системы.
Сведения об элементах управления сетью см. в статье Сеть и подключение.
роли и обязанности.
Сегментация, которая предотвращает путаницу и риски безопасности, достигается путем четкого определения направлений ответственности в команде рабочей нагрузки.
Документируйте и делитесь ролями и функциями, чтобы обеспечить согласованность и упростить взаимодействие. Назначьте группы или отдельные роли, отвечающие за ключевые функции. Прежде чем создавать настраиваемые роли для объектов, рассмотрите встроенные роли в Azure.
При назначении разрешений для сегмента рекомендуется обеспечить согласованность при использовании нескольких организационных моделей. Эти модели могут варьироваться от отдельной централизованной ИТ-группы до в основном независимых ИТ-групп и групп DevOps.
Организация ресурсов
Сегментация позволяет изолировать ресурсы рабочей нагрузки от других частей организации или даже в команде. Конструкции Azure, такие как группы управления, подписки, среды и группы ресурсов, — это способы организации ресурсов, которые способствуют сегментации. Ниже приведены некоторые примеры изоляции на уровне ресурсов.
- Сохраняемость polyglot включает сочетание технологий хранения данных вместо единой системы базы данных для поддержки сегментации. Используйте сохраняемость полиглотов для разделения по различным моделям данных, разделения функциональных возможностей, таких как хранение и аналитика данных, или для разделения по шаблонам доступа.
- При организации вычислений выделите одну службу для каждого сервера. Такой уровень изоляции минимизирует сложность и может помочь сдержать атаку.
- Azure обеспечивает встроенную изоляцию для некоторых служб, например разделение вычислительных ресурсов и хранилища. Другие примеры см. в статье Изоляция в общедоступном облаке Azure.
Упрощение 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. Сегментация в рабочей нагрузке
Этот шаблон является примером сегментации на уровне платформы. Омпоненты рабочей нагрузки c распределены по нескольким сетям без пиринга между ними. Весь обмен данными направляется через посредника, который выступает в качестве общедоступной точки доступа. Команда рабочей нагрузки владеет всеми сетями.
Шаблон 2 обеспечивает автономность, но имеет дополнительную сложность управления виртуальной сетью и определения размера. Обмен данными между двумя сетями осуществляется через общедоступный Интернет, что может быть сопряжено с риском. Существует также задержка при использовании общедоступных подключений. Тем не менее две сети могут быть одноранговые, нарушая сегментацию путем их соединения, чтобы создать более крупный сегмент. Пиринг следует выполнять, если другие общедоступные конечные точки не требуются.
| Рекомендации | Шаблон 1 | Шаблон 2 |
|---|---|---|
| Подключение и маршрутизация: взаимодействие между каждым сегментом | Маршрутизация системы обеспечивает подключение по умолчанию к компонентам рабочей нагрузки. Никакие внешние компоненты не могут взаимодействовать с рабочей нагрузкой. | В виртуальной сети, аналогично шаблону 1. Между сетями трафик проходит через общедоступный Интернет. Между сетями нет прямого подключения. |
| Фильтрация трафика на уровне сети | Трафик между сегментами разрешен по умолчанию. Используйте группы безопасности сети или ГРУППЫ ASG для фильтрации трафика. | В виртуальной сети, аналогично шаблону 1. Между сетями можно фильтровать как входящий, так и исходящий трафик через брандмауэр. |
| Непреднамеренно открытые общедоступные конечные точки | Сетевые карты (NIC) не получают общедоступные IP-адреса. Виртуальные сети не предоставляются для управления API Интернета. | То же, что и шаблон 1. Предполагаемая открытая общедоступная конечная точка в одной виртуальной сети, которая может быть неправильно настроена для приема большего объема трафика. |
Организация ресурсов
Организация ресурсов Azure на основе ответственности владельца
Рассмотрим пространство Azure, которое содержит несколько рабочих нагрузок и компонентов общих служб, таких как центральные виртуальные сети, брандмауэры, службы удостоверений и службы безопасности, такие как Microsoft Sentinel. Компоненты во всем пространстве должны группироваться в зависимости от их функциональных областей, рабочих нагрузок и владения. Например, общие сетевые ресурсы должны быть сгруппированы в одну подписку и управляться командой сетей. Компоненты, выделенные для отдельных рабочих нагрузок, должны находиться в отдельном сегменте и могут быть дополнительно разделены в зависимости от уровней приложений или других организационных принципов.
Предоставьте доступ к управлению ресурсами в отдельных сегментах путем создания назначений ролей RBAC. Например, команде облачных сетей может быть предоставлен административный доступ к подписке, содержащей их ресурсы, но не к отдельным подпискам рабочей нагрузки.
Хорошая стратегия сегментации позволяет легко определить владельцев каждого сегмента. Рассмотрите возможность использования тегов ресурсов Azure для создания заметок к группам ресурсов или подпискам в команде владельцев.
Настройка и проверка управления доступом
Предоставьте соответствующий доступ на основе необходимости, четко определив сегменты ресурсов.
Учитывайте принцип минимальных привилегий при определении политик управления доступом. Важно различать операции уровня управления (управление самим ресурсом) и операции плоскости данных (доступ к данным, хранящимся в ресурсе). Например, предположим, что у вас есть рабочая нагрузка, содержащая базу данных с конфиденциальной информацией о сотрудниках. Вы можете предоставить доступ к управлению некоторым пользователям, которым требуется настроить такие параметры, как резервное копирование базы данных или пользователи, которые отслеживают производительность сервера базы данных. Однако эти пользователи не должны иметь возможности запрашивать конфиденциальные данные, хранящиеся в базе данных. Выберите разрешения, предоставляющие минимальный область, необходимый пользователям для выполнения своих обязанностей. Регулярно просматривайте назначения ролей для каждого сегмента и удаляйте доступ, который больше не требуется.
Примечание
Некоторые высокопривилегированные роли, такие как роль владельца в RBAC, дают пользователям возможность предоставлять другим пользователям доступ к ресурсу. Ограничьте количество пользователей или групп, которым назначена роль владельца, и регулярно просматривайте журналы аудита, чтобы убедиться, что они выполняют только допустимые операции.
Связанные ссылки
- Изоляция в общедоступном облаке Azure
- Рекомендации по RBAC
- Общие сведения о виртуальных сетях
- ГРУППЫ ASG
- Брандмауэр Azure
- Обзор диспетчера брандмауэра
Контрольный список по безопасности
Ознакомьтесь с полным набором рекомендаций.
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по