Возможности безопасности Базы данных SQL Azure
База данных SQL Azure предоставляет службу реляционной базы данных в Azure. Чтобы защитить данные клиентов и обеспечить надежные функции безопасности, которые клиенты ожидают от службы реляционной базы данных, База данных SQL имеет свои собственные наборы возможностей обеспечения безопасности. Эти возможности основаны на элементах управления, которые унаследованы от Azure.
Возможности системы безопасности
Использование протокола TDS
База данных SQL Azure поддерживает только протокол табличных данных (TDS), который требует, чтобы по умолчанию база данных была доступна только через порт TCP/1433.
Брандмауэр Базы данных SQL Azure
Для защиты данных клиентов база данных Azure SQL включает функцию брандмауэра, которая по умолчанию запрещает любой доступ к База данных SQL.
Шлюз брандмауэра может ограничить адреса, что позволяет детализировать контроль клиентов для определения диапазона допустимых IP-адресов. Брандмауэр предоставляет доступ на основе исходного IP-адреса каждого запроса.
Клиенты могут выполнить конфигурацию брандмауэра с помощью портала управления или программно с использованием REST API управления Базой данных SQL Azure. Шлюз брандмауэра Базы данных SQL Azure по умолчанию запрещает всем клиентам доступ TDS к Базе данных SQL Azure. Клиенты должны настроить доступ с помощью списков управления доступом (ACL), чтобы разрешать подключения к базе данных SQL Azure по исходным и целевым интернет-адресам, протоколам и номерам портов.
DoSGuard
DosGuard, служба шлюза База данных SQL, сокращает количество атак типа "отказ в обслуживании" (DoS). DoSGuard активно отслеживает неудачные попытки входа с IP-адресов. При наличии нескольких неудачных попыток входа с IP-адреса в течение определенного периода времени IP-адрес блокирует доступ к любым ресурсам в службе в течение предопределенного периода времени.
Кроме того, шлюз Базы данных SQL Azure выполняет следующее:
- Согласование возможностей безопасного канала для реализации проверенных зашифрованных соединений TDS FIPS 140-2 при подключении к серверам баз данных.
- Проверка пакета TDS с отслеживанием состояния при выполнении соединений с клиентами. Шлюз проверяет сведения о подключении. Шлюз передает пакеты TDS на соответствующий физический сервер на основе имени базы данных, указанного в строке подключения.
Ключевой принцип сетевой безопасности предложения для Базы данных SQL Azure заключается в том, чтобы разрешать только подключение и связь, которые необходимы для работы службы. Все остальные порты, протоколы и соединения блокируются по умолчанию. Виртуальные локальные сети и списки управления доступом используются для ограничения сетевой связи по исходным и целевым сетям, протоколам и номерам портов.
Механизмы, утвержденные для реализации списков управления доступом на основе сети, включают в себя: списки ACL на маршрутизаторах и подсистемах балансировки нагрузки. Эти механизмы управляются сетью Azure, брандмауэром гостевой виртуальной машины и Azure SQL правилами брандмауэра шлюза базы данных, настроенными клиентом.
Разделение данных и изоляция клиентов
Рабочая сеть Azure структурирована таким образом, что общедоступные системные компоненты отделены от внутренних ресурсов. Существуют физические и логические границы между веб-серверами, обеспечивающими доступ к публичному объекту портала Azure, и базовой виртуальной инфраструктурой Azure, где находятся экземпляры клиентских приложений и данные клиента.
Вся общедоступная информация управляется в рабочей сети Azure. Рабочая сеть:
- Применяется двухфакторная проверка подлинности и механизмы защиты границ
- Использует брандмауэр и набор функций безопасности, описанный в предыдущем разделе.
- Использует функции изоляции данных, которые описаны в следующих разделах
Неавторизованные системы и изоляция контроллера структуры
Так как контроллер структуры является центральным оркестратором структуры Azure, для него существуют значительные средства для уменьшения угроз, особенно из потенциально скомпрометированных FA в клиентских приложениях. Контроллер отказоустойчивого кластера не распознает оборудование, сведения об устройстве которого (например, MAC-адрес) не загружены в fc предварительно. DHCP-серверы в fc настроены списки MAC-адресов узлов, которые они хотят загрузить. Даже если подключены несанкционированные системы, они не включаются в инвентаризацию структуры и, следовательно, не имеют права на связь с какой-либо системой в инвентаризации структуры. Это уменьшает риск связи несанкционированных систем с контроллером структуры и доступом к виртуальным локальным сетям и Azure.
Изоляция виртуальных локальных сетей
Рабочая сеть Azure логически разделяется на три основные виртуальные локальные сети.
- Основная виртуальная локальная сеть: соединяет ненадежные узлы клиента между собой.
- Виртуальная локальная сеть контроллера структуры: содержит доверенные контроллеры структуры и вспомогательные системы.
- Виртуальная локальная сеть устройств: содержит доверенные сетевые и другие устройства инфраструктуры.
Фильтрация пакетов
IPFilter и брандмауэры программного обеспечения, реализованные в корневой ОС и гостевой ОС узлов, обеспечивают ограничения подключения и предотвращают несанкционированный трафик между виртуальными машинами.
Гипервизор, корневая ОС и гостевые виртуальные машины
Гипервизор и корневая ОС управляют изоляцией корневой ОС от гостевых виртуальных машин и гостевых виртуальных машин друг от друга.
Типы правил для брандмауэров
Правило определяется следующим образом.
{Src IP, Src Port, Destination IP, Destination Port, Destination Protocol, In/Out, Stateful/Stateless, Stateful Flow Timeout}.
Пакетам SYN разрешено входить или выходить только в том случае, если это разрешено одним из правил. Для TCP Azure использует правила без отслеживания состояния, где принцип заключается в том, что он разрешает входить в виртуальную машину или выходить из нее всему, что не есть SYN-пакетами. Предпосылка безопасности заключается в том, что любой стек узлов устойчив к игнорированию не syn, если он не видел пакет SYN ранее. Протокол TCP сам по себе отслеживает состояние, и в сочетании с правилом на основе SYN, имеющим статус "без отслеживания состояния", достигается общее поведение реализации с отслеживанием состояния.
Azure использует правило отслеживания состояния для протокола пользовательских датаграмм (UDP). Каждый раз, когда UDP-пакет соответствует правилу, создается обратный поток в другом направлении. Этот поток имеет встроенное время ожидания.
Клиенты несут ответственность за настройку собственных брандмауэров поверх того, что предоставляет Azure. Здесь клиенты могут определять правила для входящего и исходящего трафика.
Производственное управление конфигурацией
Стандартные конфигурации безопасности поддерживаются соответствующими командами операций в Azure и в Базе данных SQL Azure. Все изменения конфигурации рабочих систем документируются и отслеживаются через центральную систему отслеживания. Изменения в программном и аппаратном обеспечении отслеживаются через центральную систему отслеживания. Изменения в сети, связанные с ACL, отслеживаются с использованием службы управления ACL (AMS).
Все изменения конфигурации Azure разрабатываются и тестируются в промежуточной среде, а затем развертываются в рабочей среде. Сборка программного обеспечения рассматривается как часть тестирования. Проверки безопасности и конфиденциальности рассматриваются как часть критериев контрольного списка. Изменения будут развернуты по расписанию соответствующей группой развертывания. Выпуски проверяются и подписываются соответствующим персоналом команды развертывания перед их развертыванием в рабочей среде.
Изменения отслеживаются для успешного завершения. В случае сбоя сценария изменение отменяется до предыдущего состояния или развертывается исправление для устранения сбоя с утверждением назначенного персонала. Хранилище исходного кода, Git, TFS, Master Data Services (MDS), средство запуска, мониторинг безопасности Azure, контроллер структуры и платформа WinFabric используются для централизованного управления, применения и проверки параметров конфигурации в виртуальной среде Azure.
Аналогичным образом, аппаратные и сетевые изменения установили шаги проверки, чтобы оценить их соответствие требованиям сборки. Выпуски рассматриваются и авторизуются через скоординированный совет по изменениям (CAB) соответствующих групп по всему стеку.
Дальнейшие действия
Дополнительные сведения о действиях корпорации Майкрософт в сфере защиты инфраструктуры Azure приведены в следующих статьях:
- Объекты, локальная среда и физическая безопасность в Azure
- Доступность инфраструктуры Azure
- Компоненты и границы информационной системы Azure
- Сетевая архитектура Azure
- Рабочая сеть Azure
- Операции и управление в рабочей среде Azure
- Мониторинг инфраструктуры Azure
- Целостность инфраструктуры Azure
- Защита данных клиентов в Azure