Архитектурные подходы к управлению и обеспечению соответствия требованиям в мультитенантных решениях
При использовании Azure важно учитывать управление облачными ресурсами. Управление включает хранение и управление данными клиентов, а также организацию ресурсов Azure. Также может потребоваться соблюдать нормативные, юридические или договорные стандарты. В этой статье содержатся сведения о том, как рассмотреть вопросы управления и соответствия в мультитенантном решении. Он также предлагает некоторые ключевые функции платформы Azure, которые поддерживают эти проблемы.
Ключевые рекомендации и требования
Изоляция ресурсов
Убедитесь, что ресурсы Azure настроены в соответствии с требованиями к изоляции клиентов. Сведения об изоляции ресурсов Azure см . в многотенантных решениях по изоляции ресурсов Azure.
Управление данными
При хранении данных от имени клиентов могут потребоваться требования или обязательства. С точки зрения клиента, они часто ожидают владения и контроля над их данными. Рассмотрим способ изоляции, хранения, доступа и агрегирования данных клиентов. Узнайте о ожиданиях и требованиях клиентов, которые могут повлиять на работу вашего решения.
Изоляция
Ознакомьтесь с подходами к архитектуре для хранения и данных в мультитенантных решениях, чтобы понять, как изолировать данные клиентов. Рассмотрите, имеют ли клиенты требования к использованию собственных ключей шифрования данных.
Независимо от того, какие подходы к изоляции вы реализуете, подготовьтесь к тому, чтобы клиенты запрашивали аудит своих данных. Рекомендуется документировать все хранилища данных, в которых могут храниться данные клиентов. К общим источникам данных относятся следующие:
- Базы данных и учетные записи хранения, развернутые в рамках решения.
- Системы удостоверений, которые часто используются между клиентами.
- Журналы.
- Хранилища данных.
Независимость
Узнайте, существуют ли ограничения на физическое расположение данных клиента, которые должны храниться или обрабатываться. Вашим клиентам может потребоваться хранить данные в определенных географических расположениях. Кроме того, им может потребоваться, чтобы данные не сохранялись в определенных местах. Хотя эти требования обычно основаны на законодательстве, они также могут быть основаны на культурных ценностях и нормах.
Дополнительные сведения о местонахождении и суверенитете данных см. в техническом документе , включаемом в службу "Размещение данных" и "Защита данных" в регионах Microsoft Azure.
Доступ клиентов к данным, которые вы храните
Клиенты иногда запрашивают прямой доступ к данным, которые вы храните от имени. Например, они могут потребовать приема данных в собственное озеро данных.
Планирование реагирования на эти запросы. Рассмотрите, хранится ли любой из данных клиента в общих хранилищах данных. Если это так, запланируйте, как избежать доступа к данным других клиентов.
Избегайте прямого доступа к базам данных или учетным записям хранения, если вы не разработали это требование, например с помощью шаблона ключа valet. Рассмотрите возможность создания API или автоматического процесса экспорта данных в целях интеграции.
Дополнительные сведения об интеграции с системами клиентов и внешними системами см. в разделе "Архитектурные подходы для интеграции клиентов и доступа к данным".
Доступ к данным клиентов
Рассмотрите, ограничивают ли требования клиентов персонал, который может работать с данными или ресурсами. Например, предположим, что вы создаете решение SaaS, используемое многими различными клиентами. Правительственным агентством может потребоваться, чтобы только граждане их страны или региона могли получить доступ к инфраструктуре и данным для их решения. Это требование можно выполнить с помощью отдельных групп ресурсов Azure, подписок или групп управления для конфиденциальных рабочих нагрузок клиентов. Можно применять строго ограниченные назначения ролей на основе ролей Azure (RBAC) для определенных групп пользователей для работы с этими ресурсами.
Агрегирование данных из нескольких клиентов
Рассмотрите необходимость объединения или агрегирования данных из нескольких клиентов. Например, вы анализируете агрегированные данные или обучаете модели машинного обучения, которые могут применяться к другим клиентам? Убедитесь, что клиенты понимают способы использования своих данных. Включите любое использование агрегированных или анонимных данных.
Соответствие нормативным требованиям
Важно понимать, нужно ли соответствовать любым стандартам соответствия. Требования к соответствию могут быть введены в нескольких ситуациях, в том числе:
- Вы или любой из ваших клиентов работаете в определенных отраслях. Например, если любой из клиентов работает в отрасли здравоохранения, может потребоваться соблюдать стандарт HIPAA.
- Вы или любой из ваших клиентов находятся в географических или геополитических регионах, требующих соответствия местным законам. Например, если любой из ваших клиентов находится в Европе, может потребоваться выполнить общее регулирование защиты данных (GDPR).
- Вы приобретаете политику киберстраховки, чтобы снизить риск нарушений. Поставщики киберстраховок могут требовать, чтобы вы соблюдали свои стандарты и применяли определенные элементы управления, чтобы политика была допустимой.
Внимание
Соответствие — это общая ответственность между корпорацией Майкрософт, вами и вашими клиентами.
Корпорация Майкрософт гарантирует, что наши службы соответствуют определенному набору стандартов соответствия требованиям и предоставляют такие средства, как Microsoft Defender для облака, которые помогают проверить, настроены ли ресурсы в соответствии с этими стандартами.
Однако в конечном счете вы несете ответственность за полное понимание требований соответствия, которые применяются к решению, и как настроить ресурсы Azure в соответствии с этими стандартами. Дополнительные сведения см . в предложениях по соответствию Azure.
В этой статье нет конкретных рекомендаций по обеспечению соответствия определенным стандартам. Вместо этого он предоставляет некоторые общие рекомендации по рассмотрению соответствия требованиям и управлению в мультитенантном решении.
Если разные клиенты должны соответствовать различным стандартам соответствия, планируйте соблюдать самый строгий стандарт во всей среде. Проще следовать одному строгому стандарту последовательно, чем следовать разным стандартам для разных клиентов.
Подходы и шаблоны, которые следует учитывать
Теги ресурсов
Используйте теги ресурсов для отслеживания идентификатора клиента для ресурсов конкретного клиента или идентификатора метки при масштабировании с помощью шаблона меток развертывания. С помощью тегов ресурсов можно быстро определить ресурсы, связанные с определенными клиентами или метками.
Управление доступом
Используйте Azure RBAC , чтобы ограничить доступ к ресурсам Azure, составляющим мультитенантное решение. Следуйте рекомендациям RBAC, таким как применение назначений ролей к группам вместо пользователей. Область назначения ролей, чтобы они предоставляли минимальные необходимые разрешения. Избегайте длительного доступа к ресурсам с помощью JIT-доступа и функций, таких как Microsoft Entra ID Privileged Access Management.
Azure Resource Graph
Azure Resource Graph позволяет работать с метаданными ресурсов Azure. Используя Resource Graph, вы можете запрашивать большое количество ресурсов Azure, даже если они распределяются по нескольким подпискам. Resource Graph может запрашивать ресурсы определенного типа или определять ресурсы, настроенные определенными способами. Его также можно использовать для отслеживания истории конфигурации ресурса.
Resource Graph может оказаться полезным для управления большими ресурсами Azure. Например, предположим, что вы развертываете ресурсы Azure для конкретного клиента в нескольких подписках Azure. Применяя теги к ресурсам, можно использовать API Resource Graph для поиска ресурсов, используемых определенными клиентами или метками развертывания.
Microsoft Purview
Рекомендуется использовать Microsoft Purview для отслеживания и классификации сохраненных данных. Когда клиенты запрашивают доступ к своим данным, можно легко определить источники данных, которые следует включить.
Проверка соответствия стандартам
Используйте такие средства, как Политика Azure, портал соответствия нормативным требованиям Microsoft Defender для облака и помощник по Azure. Эти средства помогают настроить ресурсы Azure в соответствии с требованиями к соответствию требованиям и следовать рекомендациям.
Создание документации по соответствию
Клиентам может потребоваться продемонстрировать соответствие определенным стандартам. Используйте портал управления безопасностью служб для создания документации по соответствию требованиям, которую можно предоставить клиентам или сторонним аудиторам.
Некоторые мультитенантные решения включают Microsoft 365 и используют такие службы, как Microsoft OneDrive, Microsoft SharePoint и Microsoft Exchange Online. Портал соответствия требованиям Microsoft Purview помогает понять, как эти службы соответствуют нормативным стандартам.
Шаблон меток развертывания
Рассмотрите возможность выполнения шаблона меток развертывания, если необходимо соответствовать требованиям для конкретного клиента.
Например, можно развернуть метки решения в нескольких регионах Azure. Затем вы можете назначить новым клиентам метки на основе регионов, в которых они должны находиться.
Аналогичным образом новый клиент может ввести строгие требования к соответствию, которые невозможно выполнить в существующих компонентах решения. Вы можете развернуть выделенную метку для этого клиента, а затем настроить ее в соответствии с требованиями.
Неподходящие антишаблоны
- Не понимать требования к соответствию клиентов. Важно не делать предположений о требованиях к соответствию требованиям, которые могут ввести ваши клиенты. Если вы планируете развивать свое решение на новых рынках, помните о нормативной среде, в которой клиенты, скорее всего, будут работать в пределах.
- Игнорируя рекомендации. Если у вас нет немедленной необходимости придерживаться стандартов соответствия требованиям, при развертывании ресурсов Azure вам по-прежнему следует следовать рекомендациям. Например, изолируйте ресурсы, примените политики для проверки конфигурации ресурсов и примените назначения ролей к группам вместо пользователей. Следуя рекомендациям, вы упрощаете соблюдение стандартов соответствия, когда в конечном итоге необходимо сделать это.
- Предположим, что требования к соответствию отсутствуют. При первом запуске мультитенантного решения может быть не известно о требованиях к соответствию, или вам может не потребоваться выполнить какие-либо действия. По мере роста вам, скорее всего, потребуется предоставить доказательства того, что вы соответствуете различным стандартам. Используйте Microsoft Defender для облака для отслеживания состояния соответствия по общему базовому плану, например cis Microsoft Foundations Benchmark, даже прежде чем у вас есть явное требование сделать это.
- Не планируется управлять. При развертывании ресурсов Azure рассмотрите способ их управления. Если вам нужно сделать массовое обновление ресурсов, убедитесь, что у вас есть представление о средствах автоматизации, таких как Azure CLI, Azure PowerShell, Azure Resource Graph и API Azure Resource Manager.
- Не используется группы управления. Запланируйте иерархию подписок и групп управления, включая управление доступом и Политика Azure ресурсы в каждой области. При использовании ресурсов в рабочей среде может возникнуть трудность и нарушить работу с этими элементами.
- Не удается спланировать стратегию управления доступом. Azure RBAC обеспечивает высокую степень контроля и гибкости в том, как управлять доступом к ресурсам. Убедитесь, что вы используете группы Microsoft Entra, чтобы избежать назначения разрешений отдельным пользователям. Назначьте роли в областях, которые обеспечивают соответствующий баланс между безопасностью и гибкостью. Используйте встроенные определения ролей везде, где это возможно, и назначьте роли, которые предоставляют минимальные необходимые разрешения.
- Не используется Политика Azure. Важно использовать Политика Azure для управления средой Azure. После планирования и развертывания политик убедитесь, что вы следите за соответствием политик и тщательно просматриваете все нарушения или исключения.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Автор субъекта:
- Джон Даунс | Главный инженер программного обеспечения
Другие участники:
- Богдан Черчик | Старший инженер по работе с клиентами, FastTrack для Azure
- Лора Николас | Старший инженер по работе с клиентами, FastTrack для Azure
- Арсен Владимирский | Главный инженер клиента, FastTrack для Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
Ознакомьтесь с подходами к управлению затратами и распределению.