Share via

Оценка требований к суверенитету

  • Статья

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

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

Идентификация суверенных данных

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

Организации, которые следуют платформе Cloud Adoption Framework для Azure, определяют рабочие нагрузки-кандидаты для миграции в облако на этапе планирования, а затем разрабатывают среду для размещения этих рабочих нагрузок на этапе готовности. Эти действия могут позволить организации идентифицировать типы суверенных данных, которые требуют специальной обработки в облачной среде целевого состояния.

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

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

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

Примеры требований к суверенитету данных

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

Маркировка данных при классификации

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

Дополнительные сведения см. в разделах Расстановка тегов в Azure и Решения Microsoft Purview eDiscovery.

Границы классификации данных

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

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

Для получения дополнительной информации см. раздел Группы управления в Azure и Управление данными.

Место расположения данных

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

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

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

Право собственности, хранение и переносимость данных

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

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

Дополнительные сведения см. в разделе Управление данными в Microsoft.

Сохранение операционного суверенитета в облаке

Требования у операционному суверенитету могут влиять на то, как среда в Azure проектируется, обновляется и как происходит управление этой средой. Следовательно, важно иметь четкое представление об этих требованиях до того, как технические проекты будут завершены на этапе готовности Cloud Adoption Framework для Azure. Общие требования к операционному суверенитету могут включать:

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

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

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

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

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

Примеры требований к операционному суверенитету данных

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

Безопасность ПО

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

Microsoft предоставляет различные возможности, помогающие клиентам удовлетворить требования операционного суверенитета для программного обеспечения, разработанного Microsoft и ПО заказчиков. Microsoft следует правилам жизненного цикла разработки защищенного ПО (SDL) при создании программного обеспечения уровня платформы для Azure. 12 практик SDL включены в инженерные процессы и процедуры Microsoft и регулярно оцениваются в рамках мер Microsoft по обеспечению качества. Кроме того, Microsoft предоставляет возможности, которые помогут клиентам внедрить методы жизненного цикла разработки защищенного ПО при создании собственного программного обеспечения.

Дополнительные сведения см. в разделах Жизненный цикл разработки защищенного ПО Microsoft и Рекомендации по разработке защищенного ПО в Azure.

Безопасность инфраструктуры

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

Дополнительные сведения см. в разделах Целостность и безопасность платформы и Безопасность инфраструктуры Azure.

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

Кроме того, организации, которые хотят свести к минимуму необходимость доверия к компонентам платформы, таким как ОС узла, ядро, гипервизор и административный персонал, могут внедрить шифрование используемых данных. Конфиденциальные вычисления Azure включают в себя несколько служб вычислений, развернутых в аппаратных анклавах безопасности, которые шифруют данные в памяти с помощью расширений Intel Software Guard Extensions (SGX) или AMD Secure Encrypted Virtualization (SEV-SNP).

Организациям с требованиями к операционному суверенитету, которым требуется внедрение шифрования, следует ознакомиться со следующими функциями шифрования в Azure:

Операции и устойчивость

Требования операционной безопасности могут применяться как к программному обеспечению уровня платформы, созданному и управляемому Microsoft для работы с платформой Azure, так и к программному обеспечению, управляемому клиентом, которое является частью рабочей нагрузки. Модель общей ответственности за облачные вычисления переносит административную ответственность с клиента на поставщика облачных услуг. В зависимости от типа используемой облачной службы Microsoft может нести ответственность за управление и обновление физической инфраструктуры в наших центрах обработки данных, операционных системах и во время работы служб. Подразделение Microsoft по обеспечению безопасности реализует программу операционной безопасности, основанную на методах жизненного цикла разработки защищенного ПО (SDL) и методах операционной безопасности. Эти методы включают управление секретами, тестирование на проникновение и мониторинг безопасности, реализуемые Центром по реагированию на угрозы, созданным Microsoft.

В редких случаях компании Microsoft может потребоваться доступ к данным клиентов для устранения проблем, которые могут повлиять на работу служб. Клиенты с требованиями к операционному суверенитету, связанными с контролем за изменениями и управлением привилегированным доступом (Privileged Access Management), могут захотеть включить защищенное хранилище для Azure, чтобы они могли утверждать запросы на доступ в рамках рабочих процессов поддержки Microsoft.

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

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

Организациям следует заранее оценить эти требования и рассмотреть лучший способ сбалансировать эти требования.