Стратегии архитектуры для создания стратегии сегментации

Применяется к рекомендации по контрольным спискам безопасности Well-Architected Framework:

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

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

Терминология 

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

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

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

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

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

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

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

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

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

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

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

Определение личности как основного периметра безопасности

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

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

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

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

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

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

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

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

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

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

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

Использование сетевых возможностей в качестве защиты периметра

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идентичность

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

Более подробную информацию см. в разделе Лучшие практики для RBAC.

Нетворкинг

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

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

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

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

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

Example

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблон 3. Изоляция PaaS

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

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

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

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

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

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

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

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

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

Связанные ссылки

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

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

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