Решение для сценария 2. Критически важное приложение
В предыдущем модуле мы работали со сценарием, касающимся высокого уровня доступности для системы диспетчеризации 911. В этом модуле мы рассмотрим одно потенциальное решение, а также обратим внимание на некоторые другие элементы решения.
По мере рассмотрения сравните описанное в этом модуле решение с тем решением, которое вы разработали в предыдущем уроке. У проблем часто бывает по нескольку решений, но в каждом из них приходится идти на компромиссы. Какие элементы в вашем решении отличаются от предложенного решения? Есть ли в вашем решении какие-то моменты, на которые нужно посмотреть иначе? Есть ли в приведенном решении какие-то элементы, которые, на ваш взгляд, были более тщательно раскрыты в вашем решении?
Вариант развертывания и конфигурация развертывания
Первым делом необходимо выбрать потенциально наилучший вариант развертывания SQL Azure. Если рассматривать только соглашение об уровне обслуживания (SLA), требование состоит в уровне доступности 99,995%, который может предоставить только База данных SQL Azure. Чтобы получить это соглашение об уровне обслуживания, необходимо развернуть уровень служб "Критически важный для бизнеса" и включить использование зон доступности.
Другой набор решений связан с тем, как включить геоизбыточность и обеспечить высокий уровень доступности в случае сбоев. Хотя георепликация и группы автоматической отработки отказа являются подходящими вариантами, группы автоматической отработки отказа позволят клиенту выполнить отработку отказа при необходимости без изменения строк подключения. Эта схема может помочь сократить время простоя при обновлении строк подключений приложений, поскольку обновлять их не потребуется. Можно также настроить запросы мониторинга для проверки состояния. Это позволит даже принудительно выполнить отработку отказа в случае сбоя.
В этой конфигурации также важно подумать о том, какую роль играет совместное размещение. Чтобы обеспечить высокий уровень доступности, приложение должно находиться максимально близко к базе данных и определенно — в том же регионе, что и база данных. Необходимо развернуть приложение в обоих регионах группы автоматической отработки отказа, чтобы обеспечить наличие избыточной копии приложения (например, веб-приложения). При отработке отказа можно использовать Диспетчер трафика Azure для перенаправления трафика в приложение в дополнительном регионе.
Администраторы баз данных и конфиденциальные данные
Координаторы системы диспетчеризации 911 выразили беспокойство в отношении защиты конфиденциальных данных (таких как журнал состояния здоровья и другие персональные данные) во время решения задач по администрированию базы данных.
Чтобы исключить просмотр конфиденциальных данных, хранящихся в конкретных столбцах, администраторами баз данных, и обеспечить отслеживание всех случаев доступа к таблицам, содержащим конфиденциальные данные, можно использовать определенные технологии SQL Azure. Для отслеживания доступа лучше всего подойдет аудит SQL, но с ним администраторы баз данных по-прежнему смогут просмотреть данные. Классификация конфиденциальных данных с помощью классификации данных может помочь в решении этого вопроса, поскольку конфиденциальные данные будут помечены и вы можете отслеживать доступ к ним с помощью аудита SQL. Однако администраторы баз данных все равно смогут просматривать конфиденциальные данные. Динамическое маскирование данных можно использовать для маскирования конфиденциальных данных, но запретить пользователю с правами db_owner просматривать данные пользователей только на основе разрешений невозможно.
Если в базе данных имеются данные с высокой степенью секретности, можно использовать Always Encrypted, чтобы надежно защитить данные от просмотра, в том числе и пользователями с правами db_owner. Вы можете управлять ключами Always Encrypted с помощью разделения ролей, чтобы администратор безопасности не мог получить доступ к базе данных и администратор базы данных не мог просмотреть физические ключи в виде открытого текста. Используя эту стратегию совместно с мониторингом при помощи аудита SQL, вы можете отслеживать и маскировать конфиденциальные данные и отслеживать доступ к конфиденциальным данным даже со стороны администраторов баз данных с правами db_owner.
Конфиденциальные данные должны быть замаскированы от администраторов баз данных, но администраторы должны иметь возможность устранять проблемы производительности с помощью портала Azure, SQL Server Management Studio или Azure Data Studio. И они должны иметь возможность создавать новых пользователей автономной базы данных, которые должны быть сопоставлены с субъектами Microsoft Entra.
Одним из решений является создание группы Microsoft Entra с именем SQL DBA для баз данных на каждом экземпляре. Затем назначьте эту группу роли "Участник SQL Server" Azure RBAC. Наконец, можно задать группу администратором Microsoft Entra на логическом сервере.