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

Архитектурные подходы к управлению и соответствию в мультитенантных решениях

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

Основные рекомендации и требования

Рассмотрим следующие ключевые аспекты и требования.

Изоляция ресурсов

Убедитесь, что ресурсы Azure настроены в соответствии с требованиями к изоляции клиентов. Дополнительные сведения см. в разделе "Организация ресурсов Azure" в мультитенантных решениях.

Управление данными

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

Изоляция

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

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

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

Суверенитет

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

Дополнительные сведения о местонахождении и суверенитете данных см. в техническом документе Enabling data residency and data protection in Microsoft Azure regions.

Доступ клиентов к данным, которые вы храните

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

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

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

Дополнительные сведения об интеграции с системами клиентов и внешними системами см. в разделе "Архитектурные подходы для интеграции клиентов и доступа к данным".

Доступ к данным клиентов

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

Агрегирование данных из нескольких арендаторов

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

Требования к соответствию требованиям

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

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

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

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

Важный

Соответствие — это общая ответственность между корпорацией Майкрософт, вами и вашими клиентами.

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

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

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

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

Подходы и шаблоны для рассмотрения

Теги ресурсов

Используйте теги ресурсов для отслеживания идентификатора арендатора для ресурсов конкретного арендатора или идентификатора метки при масштабировании с помощью паттерна Deployment Stamps. Используя теги ресурсов, можно быстро определить ресурсы, связанные с определенными арендаторами или штампами.

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

Используйте Azure RBAC, чтобы ограничить доступ к ресурсам Azure, составляющим мультитенантное решение. Следуйте рекомендациям Azure RBAC, таким как применение назначений ролей к группам вместо пользователей. Определите распределение ролей таким образом, чтобы они предоставляли минимально необходимые разрешения. Избегайте длительного доступа к ресурсам, используя JIT-доступ и функции, такие как Microsoft Entra ID Privileged Identity Management.

Граф ресурсов Azure

Используйте Azure Resource Graph для работы с метаданными ресурсов Azure. Используя Resource Graph, вы можете запрашивать большое количество ресурсов Azure, даже если они распределяются по нескольким подпискам. Resource Graph может запрашивать ресурсы определенного типа или определять ресурсы, настроенные определенными способами. Его также можно использовать для отслеживания истории конфигурации ресурса.

Resource Graph поможет вам управлять большими ресурсами Azure. Например, предположим, что вы развертываете ресурсы Azure для конкретного клиента в нескольких подписках Azure. Применяя теги к ресурсам, вы можете использовать API Resource Graph для поиска ресурсов, используемых определенными клиентами или метками развертывания.

Microsoft Purview

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

Проверка соответствия стандартам

Используйте такие средства, как Политика Azure, портал соответствия нормативным требованиям Defender для облака и Помощник по Azure. Эти средства помогают настроить ресурсы Azure в соответствии с требованиями соответствия требованиям и следовать рекомендациям.

Создание документации по соответствию

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

Некоторые мультитенантные решения включают Microsoft 365 и используют такие службы, как Microsoft OneDrive, Microsoft SharePoint и Microsoft Exchange Online. Портал Microsoft Purview помогает понять, как эти службы соответствуют нормативным стандартам.

Шаблон меток развертывания (Deployment Stamps)

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

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

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

Антипаттерны, которых следует избегать

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

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

  • Предположим, что требования к соответствию отсутствуют. При первом запуске мультитенантного решения может быть не известно о требованиях к соответствию, или вам может не потребоваться выполнить какие-либо действия. По мере роста, скорее всего, вам потребуется предоставить доказательства того, что вы соответствуете различным стандартам. Используйте Защитник для облака, чтобы отслеживать состояние соответствия по общему базовому уровню, например CIS Microsoft Azure Foundations Benchmark, даже до того, как будет установлено любое официальное требование.

  • Не планируется управление. При развертывании ресурсов Azure рассмотрите способ их управления. Если вам нужно сделать массовое обновление ресурсов, убедитесь, что вы понимаете средства автоматизации, такие как Azure CLI, Azure PowerShell, Resource Graph и API Azure Resource Manager.

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

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

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

Участники

Корпорация Майкрософт поддерживает эту статью. Следующие авторы написали эту статью.

Главный автор

  • Джон Даунс | Главный инженер по программному обеспечению, шаблоны и практики Azure

Другие участники:

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.