Решение для сценария 1. Разработка архитектуры в глобальном масштабе и безопасный доступ
В предыдущем уроке мы работали со сценарием, предполагающим глобальный масштаб для сети доставки содержимого. В этом модуле мы рассмотрим одно потенциальное решение, а также обратим внимание на некоторые элементы решения.
По мере рассмотрения сравните описанное в этом модуле решение с тем решением, которое вы разработали в предыдущем уроке. У проблем часто бывает по нескольку решений, но в каждом из них приходится идти на компромиссы. Какие элементы в вашем решении отличаются от предложенного решения? Есть ли в вашем решении какие-то моменты, на которые нужно посмотреть иначе? Есть ли в приведенном решении какие-то элементы, которые, на ваш взгляд, были более тщательно раскрыты в вашем решении?
Вариант развертывания и конфигурация развертывания
Первым делом нужно выбрать вариант развертывания SQL Azure. Хотя вариант развертывания SQL Server на виртуальной машине Azure является подходящим, платформа как услуга (PaaS) может обеспечить лучшую производительность с меньшими издержками на управление.
Клиент использует среду CLR, которая является компонентом уровня экземпляра. Управляемый экземпляр SQL Azure — это единственный вариант развертывания, который поддерживает такие компоненты уровня экземпляра, как среда CLR, Service Broker и Database Mail. Поэтому Управляемый экземпляр SQL Azure позволит клиенту перейти на предложение PaaS без необходимости переписывать его приложения среды CLR для получения решения, совместимого с Базой данных SQL Azure (такого как эластичные задания базы данных).
Далее необходимо выбрать уровень служб. Так как клиенту необходимо изолировать рабочие нагрузки для чтения и записи, самый простой способ добиться этого — использовать уровень служб "Критически важный для бизнеса". Уровень служб "Критически важный для бизнеса" имеет группу доступности Always On, развертываемую в фоновом режиме. Одну из этих вторичных реплик можно использовать под рабочие нагрузки только для чтения.
Уровень служб "Критически важный для бизнеса" — это лишь половина конфигурации, необходимой для разделения рабочих нагрузок чтения и записи. В сценарии указано, что клиенту необходима возможность масштабирования решения на несколько регионов с несколькими одновременно выполняемыми запросами и изоляцией рабочих нагрузок чтения и записи.
Два потенциальных варианта решения этой задачи — георепликация и группы автоматической отработки отказа. Однако георепликация на данный момент не поддерживается в Управляемом экземпляре SQL Azure. Таким образом, использование группы автоматической отработки отказа — единственный вариант, который поможет реализовать глобальное масштабирование чтения в этом сценарии.
Так как клиент использует группы автоматической отработки отказа, необходимость в использовании уровня служб "Критически важный для бизнеса" будет определяться количеством конечных точек только для чтения, необходимых клиенту для рабочей нагрузки аналитики. Используя группу автоматической отработки отказа на уровне служб "Критически важный для бизнеса", клиент получит три доступные для чтения конечные точки:
- одна вторичная реплика из группы доступности основного региона;
- вторичная реплика группы отработки отказа (первичная реплика базы данных в дополнительном регионе);
- вторичная реплика из группы доступности дополнительного региона.
Если для рабочей нагрузки аналитики не требуются все эти доступные для чтения реплики, более экономичным вариантом может оказаться использование уровня служб "Общего назначения".
Выбор наиболее подходящих методов проверки подлинности
В другой части этого сценария определяются наилучшие способы подключения к решению для каждого приложения и каждого лица с учетом потребности в создании и применении наиболее безопасных технологий. Если подробно разобрать сценарий, мы увидим, что в нем есть четыре отдельных клиента, которым потребуется доступ к Управляемому экземпляру SQL Azure.
- Приложение, выполняющееся на виртуальной машине Azure
- Приложения, выполняющиеся на присоединенных к домену компьютерах, не относящихся к Azure.
- Аналитики баз данных или другие пользователи средств администрирования SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) на присоединенных к домену компьютерах, не относящихся к Azure.
- Старые приложения, работающие на компьютере, не относящемся к Azure, в которых нельзя изменить драйвер или строку подключения.
Давайте взглянем на них с точки зрения того, как выбрать метод проверки подлинности, и также рассмотрим некоторые дополнительные рекомендации и ограничения.
Приложение, выполняющееся на виртуальной машине Azure
Управляемые удостоверения для ресурсов Azure, как правило, являются рекомендуемой формой проверки подлинности без пароля для приложений, работающих на виртуальных машинах Azure.
Приложения, выполняющиеся на присоединенных к домену компьютерах, не относящихся к Azure.
Для компьютеров, не относящихся к Azure, использование управляемых удостоверений не является допустимым вариантом. Встроенная проверка подлинности с помощью идентификатора Microsoft Entra — это рекомендуемый метод проверки подлинности для приложений, работающих на компьютерах, присоединенных к домену за пределами Azure, если домен был федеративн с идентификатором Microsoft Entra.
Если компьютер не относится к Azure и не присоединен к домену, вы можете сделать следующее:
- Создайте удостоверение приложения для приложения в идентификаторе Microsoft Entra.
- Связать сертификат с удостоверением приложения.
- Изменить приложение, чтобы получать маркер для Базы данных SQL Azure, указывая идентификатор клиента и сертификат.
Несмотря на то что сертификат должен содержать закрытый ключ и быть развернут на компьютере, на котором размещено приложение, ни в коем случае не следует указывать секрет приложения в коде или конфигурации приложения. (Потребуется настроить отпечаток сертификата для приложения.)
Администраторы баз данных или другие пользователи средств администрирования SQL с компьютера, не относящегося к Azure и не присоединенного к домену.
Для пользователей за пределами Azure следует по возможности исключать использование паролей. Вы можете исключить пароли с инструментами SQL с помощью интегрированной проверки подлинности Microsoft Entra. Однако средства должны работать на компьютере, присоединенном к домену, и домен должен быть федеративн с идентификатором Microsoft Entra, который не является вариантом для этого сценария.
Так как среда не соответствует предварительным требованиям для интегрированной проверки подлинности, рекомендуется использовать интерактивную проверку подлинности Microsoft Entra с многофакторной проверкой подлинности, которая поддерживает большинство средств SQL.
Старые приложения, работающие на компьютере, не относящемся к Azure, в которых нельзя изменить драйвер или строку подключения.
В сценариях, где невозможно изменить драйвер или строку подключения, вариант проверки подлинности без пароля на данный момент отсутствует. Эти устаревшие приложения должны продолжать использовать проверку подлинности SQL. Тем не менее вы можете глубже проанализировать ограничения и подумать над тем, как устранить их, чтобы реализовать более безопасный подход к проверке подлинности приложений.