Поделиться через


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

Применимо к Power Platform рекомендациям контрольного списка Well-Architected Security:

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

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

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

Определения

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

Ключевые стратегии проектирования

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

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

Ниже приведены несколько примеров сегментов:

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

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

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

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

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

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

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

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

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

Удостоверение как периметр

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

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

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

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

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

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

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

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

Дополнительные сведения о средствах контроля удостоверений см. в разделе Рекомендации для управления идентификацией и доступом.

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

Сеть как периметр

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

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

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

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

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

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

Роли и обязанности

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

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

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

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

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

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

Возможности в Power Platform

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

Удостоверение

Все продукты Power Platform используют Microsoft Entra ID (ранее Azure Active Directory или Azure AD) для системы управления идентификацией и доступом. Вы можете использовать встроенные роли безопасности, условный доступ, управление привилегированными удостоверениями и управление групповым доступом в Entra ID, чтобы определить ваши периметры удостоверений.

Microsoft Dataverse использует безопасность на основе ролей для группировки коллекции привилегий. Эти роли безопасности могут быть связаны непосредственно с пользователями, или они могут быть связаны с командами и бизнес-подразделениями Dataverse. Дополнительные сведения см. в разделе Концепции безопасности в Microsoft Dataverse.

Сеть

Поддержка виртуальной сети Azure для Power Platform помогает интегрировать Power Platform с ресурсами внутри вашей виртуальной сети, не показывая ваши ресурсы в общественном Интернете. Поддержка виртуальной сети использует делегирование подсети Azure для управления исходящим трафиком во время выполнения из Power Platform. Использование представителя позволяет избежать необходимости перемещения защищенных ресурсов через Интернет для интеграции с Power Platform. Компоненты виртуальной сети, Dataverse и Power Platform могут вызывать ресурсы, принадлежащие вашему предприятию, внутри вашей сети, независимо от того, размещены ли они в Azure или локально, и использовать подключаемые модули и соединители для совершения исходящих звонков. Дополнительную информацию см. в разделе Обзор поддержки виртуальной сети для Power Platform.

IP-брандмауэр для Power Platform сред помогает защитить ваши данные, ограничивая доступ пользователей Dataverse только из разрешенных IP-адресов.

Microsoft Azure ExpressRoute предоставляет расширенный способ подключения вашей сети локальный к Microsoft облачным сервисам с использованием частного подключения. Одно подключение ExpressRoute можно использовать для доступа к нескольким онлайн-службам; например, Microsoft Power Platform, Dynamics 365, Microsoft 365 и Azure.

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

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