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

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

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

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

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

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

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

Изоляция

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

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

• Базы данных и учетные записи хранения, развернутые в рамках решения.
• Системы удостоверений, которые часто разделяются арендаторами.
• Логи.
• Хранилища данных.

Суверенитет

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

Дополнительные сведения о местонахождении и суверенитете данных см. в белой книге «Обеспечение размещения и защиты данных в регионах Microsoft Azure».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Используйте Azure RBAC, чтобы ограничить доступ к ресурсам Azure, составляющим мультитенантное решение. Следуйте рекомендациям RBAC , например применение назначений ролей к группам вместо пользователей. Настройте назначение ролей так, чтобы они предоставляли минимальные необходимые разрешения. Избегайте длительного доступа к ресурсам, используя доступ по запросу (Just-In-Time) и возможности, такие как 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 Policy, портал регулирования соответствия Microsoft Defender для облакаи Azure Advisor. Эти средства помогают настроить ресурсы Azure в соответствии с нормативными требованиями и следовать рекомендуемым лучшим практикам.

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

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

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

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

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

Например, можно развернуть метки решения в нескольких регионах 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.

Дальнейшие действия

Просмотрите подходы к управлению затратами и распределению.