Обеспечение безопасности sql server

Механизмы шифрования

SQL Server поддерживает следующие механизмы шифрования:

функции Transact-SQL
асимметричные ключи;
симметричные ключи;
Сертификаты
прозрачное шифрование данных.

Функции Transact-SQL

Отдельные элементы можно зашифровать по мере их вставки или обновления с помощью функций Transact-SQL. Дополнительные сведения см. в статьях ENCRYPTBYPASSPHRASE (Transact-SQL) и DECRYPTBYPASSPHRASE (Transact-SQL).

Сертификаты

Сертификат открытого ключа, или просто сертификат, представляет собой подписанную цифровой подписью инструкцию, которая связывает значение открытого ключа с идентификатором пользователя, устройства или службы, имеющей соответствующий закрытый ключ. Сертификаты поставляются и подписываются центром сертификации (certification authority, CA). Сущность, получающая сертификат от центра сертификации, является субъектом этого сертификата. Как правило, сертификаты содержат следующие сведения.

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

Сертификат действителен только в течение указанного в нем периода, который задается в каждом сертификате при помощи дат ( Valid From и Valid To ), определяющих начало и окончание срока действия. По истечении срока действия сертификата его субъект должен запросить новый сертификат.
Идентификационные данные поставщика сертификата.
Цифровая подпись поставщика.

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

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

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

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

Самостоятельно подписанные сертификаты, созданные SQL Server , соответствуют стандарту X.509 и поддерживают поля X.509 v1.

Асимметричные ключи

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

симметричные ключи;

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

прозрачное шифрование данных.

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

Угрозы для инфраструктуры

Рассмотрите следующие распространенные угрозы для инфраструктуры:

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

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

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

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

Риски для паролей

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

Создайте уникальную локальную учетную запись администратора с именем, отличным от Administrator.
Используйте сложные надежные пароли для всех учетных записей. Дополнительные сведения о том, как создать надежный пароль, см. в статье Создание надежного пароля.
По умолчанию во время настройки виртуальной машины SQL Server в Azure выбирается проверка подлинности Windows. Следовательно, имя для входа SA отключается, а пароль назначается в ходе настройки. Мы рекомендуем не использовать и не включать имя для входа SA. Если вам необходимо имя для входа SQL, используйте одну из следующих стратегий.

Создайте учетную запись SQL с уникальным именем, являющуюся участником роли sysadmin. Этого можно сделать на портале, включив аутентификацию SQL во время подготовки.

Совет

Если не включить аутентификацию SQL во время подготовки, необходимо будет вручную изменить режим аутентификации на Проверка подлинности SQL Server и Windows. Дополнительные сведения см. в статье Изменение режима проверки подлинности сервера.

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

Риски, связанные с программой-шантажистом

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

Лучшая стратегия защиты от атаки программой-шантажистом — уделить особое внимание уязвимостям RDP и SSH. Кроме того, учтите следующее:используйте брандмауэры и блокируйте порты;
убедитесь, что к операционной системе и приложениям применяются последние обновления безопасности;
используйте групповые управляемые учетные записи служб (gMSA);
ограничьте доступ к виртуальным машинам;
Требовать JIT-доступ и Бастион Azure

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

Проверка TDE

Чтобы включить TDE в базе данных, SQL Server должен выполнить проверку шифрования. Проверка считывает каждую страницу из файлов данных в буферный пул, а затем записывает зашифрованные страницы обратно на диск.

Чтобы обеспечить более полный контроль над проверкой шифрования, SQL Server 2019 (15.x) вводит сканирование TDE, которое имеет синтаксис приостановки и возобновления

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

Чтобы приостановить сканирование шифрования TDE, используйте следующий синтаксис:

Подобным образом вы можете возобновить сканирование шифрования TDE с помощью следующего синтаксиса:

Столбец encryption_scan_state добавлен в динамическое административное представление. Он показывает текущее состояние сканирования шифрования. Кроме того, появился столбец encryption_scan_modify_date, который содержит дату и время последнего изменения состояния сканирования шифрования.

Если экземпляр SQL Server перезапускается во время приостановки проверки шифрования, во время запуска в журнал ошибок записывается сообщение. Сообщение указывает, что существующее сканирование приостановлено.

Важно!

Функция приостановки и возобновления TDE сейчас недоступна в Базе данных SQL Azure, Управляемом экземпляре SQL Azure и Azure Synapse Analytics.

Проверка подлинности: кто вы?

Функция	Ссылка
Кто выполняет проверку подлинности? Проверка подлинности Windows Проверка подлинности SQL Server Azure Active Directory	Кто выполняет проверку подлинности? (Windows или SQL Server)Выбор режима проверки подлинностиПодключение к базе данных SQL с использованием аутентификации Azure Active Directory
Где выполняется проверка подлинности? В базе данных master: имена для входа и пользователи базы данных В пользовательской базе данных: включенные пользователи базы данных	Аутентификация в базе данных master (имена для входа и пользователи базы данных)создать имя входа SQL ServerУправление базами данных и учетными записями в Базе данных SQL AzureСоздание пользователя базы данных Проверка подлинности в пользовательской базе данныхПользователи автономной базы данных: создание переносимой базы данных
Использование других идентификаторов Учетные данные Выполнение в контексте другого имени входа Выполнение от имени другого пользователя базы данных	Учетные данные (компонент Database Engine)Выполнение в контексте другого имени входаВыполнение от имени другого пользователя базы данных

Как работают запросы к зашифрованным столбцам

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

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

Примечание

Если пользователю требуются разрешения базы данных для чтения данных, но нет доступа к ключам, защищающим их, он по-прежнему может получить зашифрованные данные, подключившись к базе данных, не включив Always Encrypted в подключении к базе данных.

Вот как работают запросы к зашифрованным столбцам:

Когда приложение выдает параметризованный запрос, драйвер клиента SQL в приложении прозрачно связывается с ядром СУБД (путем вызова sp_describe_parameter_encryption (Transact-SQL), чтобы определить, какие параметры предназначены для зашифрованных столбцов и которые должны быть зашифрованы. Для каждого параметра, который необходимо зашифровать, драйвер получает алгоритм шифрования, тип шифрования и метаданные ключа, включая зашифрованный ключ шифрования столбца и расположение соответствующего главного ключа столбца.
Драйвер вызывает хранилище ключей, содержащее главные ключи столбца, для расшифровки значений ключа шифрования зашифрованного столбца. Результируемые ключи шифрования столбцов в виде открытого текста кэшируются, чтобы уменьшить количество обращений в хранилище ключей при последующем использовании этих ключей шифрования столбцов.
Драйвер использует полученные ключи шифрования столбцов в виде открытого текста для шифрования параметров запроса, соответствующих зашифрованным столбцам.
Драйвер заменяет значения в виде открытого текста параметров, предназначенных для зашифрованных столбцов, их зашифрованными значениями, и отправляет запрос в ядро СУБД для обработки.
Компонент Database Engine выполняет запрос, который может включать сравнение столбцов на равенство с использованием детерминированного шифрования.
Если результаты запроса включают данные из зашифрованных столбцов, компонент Компонент Database Engine присоединяет метаданные шифрования для каждого столбца, включая сведения об алгоритме шифрования, типе шифрования и метаданные ключа к результирующем набору.
Компонент Компонент Database Engine отправляет результирующий набор в клиентское приложение.
Для каждого зашифрованного столбца в полученном результирующем наборе драйвер сначала пытается найти ключ шифрования столбца в виде открытого текста в локальном кэше и совершает круговой путь к хранилищу ключей, включающем главный ключ столбца, только если ему не удается найти ключ в кэше.
Драйвер расшифровывает результаты и возвращает в приложение значения в виде открытого текста.

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

Список клиентских драйверов, поддерживающих Always Encrypted, а также сведения о разработке приложений, запрашивающих зашифрованные столбцы, см. в статье Разработка приложений с помощью Always Encrypted.

Вы также можете запрашивать зашифрованные столбцы с помощью средств SQL, например Azure Data Studio или SSMS.

Безопасность платформы и сети

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

Физическая безопасность

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

Реализация физической сетевой безопасности начинается с запрета доступа неавторизованных пользователей к сети. Следующая таблица содержит дополнительные сведения об источниках сведений по сетевой безопасности.

Сведения о	См.
SQL Server Compact и сетевой доступ к другим выпускам SQL Server	Раздел «Настройка и обеспечение безопасности среды сервера» в электронной документации по SQL Server Compact

Безопасность операционной системы

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

Кроме того, эффективную безопасность можно реализовать с помощью брандмауэров. Брандмауэр, распределяющий или ограничивающий сетевой трафик, можно настроить в соответствии с корпоративной политикой информационной безопасности. Использование брандмауэра повышает безопасность на уровне операционной системы, обеспечивая узкую область, на которой можно сосредоточить меры безопасности. Следующая таблица содержит дополнительные сведения по использованию брандмауэра с SQL Server.

Сведения о	См.
Настройка брандмауэра для работы со службами SQL Server	Настройка брандмауэра Windows для доступа к компоненту Database Engine
Настройка брандмауэра для работы со службами Службы Integration Services	Службы Integration Services (службы SSIS)
Настройка брандмауэра для работы со службами Службы Analysis Services	Настройка брандмауэра Windows на разрешение доступа к службам Analysis Services
Открытие конкретных портов брандмауэра, чтобы предоставить доступ к SQL Server	Настройка брандмауэра Windows для разрешения доступа к SQL Server
Настройка поддержки расширенной защиты для проверки подлинности с помощью привязки каналов и привязки служб	Соединение с компонентом Database Engine с использованием расширенной защиты

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

Сведения о	См.
Службы, необходимые для SQL Server	Настройка учетных записей службы Windows и разрешений

Если в системе SQL Server используются службы IIS, необходимы дополнительные действия для обеспечения безопасности контактной зоны платформы. Следующая таблица содержит сведения о SQL Server и службах IIS.

Сведения о	См.
Безопасность служб IIS в SQL Server Compact	«Безопасность служб IIS» в электронной документации по SQL Server Compact
Службы Reporting Services Проверка подлинности	Проверка подлинности в службах Reporting Services
SQL Server Compact и доступ к службам IIS	«Блок-схема безопасности служб IIS» в электронной документации по SQL Server Compact

Безопасность файлов операционной системы SQL Server

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

Сведения о	См.
SQL Server программные файлы	Расположение файлов для экземпляра по умолчанию и именованных экземпляров SQL Server

SQL Server позволяют повысить безопасность. Для определения новейшего доступного пакета обновления для SQL Serverперейдите на веб-сайт SQL Server .

С помощью приведенного ниже скрипта можно определить установленный в системе пакет обновления.

Включение и отключение функции Always Encrypted, применяемой для подключения к базе данных

При подключении к базе данных в среде SSMS можно включить или отключить функцию Always Encrypted, применяемую для подключения к базе данных. По умолчанию функция Always Encrypted отключена.

После включения функции Always Encrypted, применяемой для подключения к базе данных, поставщик данных .NET Framework для SQL Server, используемый в SQL Server Management Studio, получает установку на прозрачное выполнение следующих действий:

расшифровка любых значений, полученных из зашифрованных столбцов и возращенных в результатах запроса;
шифрование значений параметризованных переменных Transact-SQL, предназначенных для зашифрованных столбцов базы данных.

Если функция Always Encrypted, применяемая для подключения к базе данных, не включена, поставщик данных .NET Framework для SQL Server, используемый средой SSMS, не будет пытаться зашифровать параметры запроса или расшифровать результаты.

Always Encrypted можно включить или отключить при создании подключения или изменении существующего подключения в диалоговом окне Соединение с сервером.

Чтобы включить или отключить Always Encrypted, выполните следующие действия.

Откройте диалоговое окно Соединение с сервером (см. статью ).
Нажмите кнопку » Параметры >>».
Если используется SSMS 18 или более поздние версии:
1. Выберите вкладку Always Encrypted.
2. Чтобы включить Always Encrypted, щелкните Включить Always Encrypted (шифрование столбца) . Чтобы отключить Always Encrypted, снимите флажок Включить Always Encrypted (шифрование столбца) .
Если используется SSMS 17 или более ранние версии:
1. Выберите вкладку Дополнительные свойства.
2. Чтобы включить Always Encrypted, введите . Чтобы отключить Always Encrypted, укажите или удалите параметр шифрования столбца на вкладке Дополнительные свойства (значение по умолчанию — Отключено).
Нажмите кнопку Соединить.

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

Совет

Чтобы включить или отключить функцию Always Encrypted в текущем окне редактора запросов, сделайте следующее:

Щелкните правой кнопкой мыши в любом месте окна редактора запросов.
Выберите Соединение>Изменить соединение. В окне редактора запросов откроется диалоговое окно Соединение с сервером для текущего подключения.
Включите или отключите Always Encrypted, выполнив описанные выше действия, и нажмите кнопку Подключить.

Дополнительные сведения

Шифрование пакетов входа и шифрование пакетов данных

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

SQL Server самозаверяющих сертификатов

SQL Server будет использовать сертификат из доверенного центра сертификации, если он доступен для шифрования пакетов входа. Если доверенный сертификат не установлен, SQL Server создаст самозаверяющий сертификат (резервный сертификат) во время запуска и использует этот самозаверяющий сертификат для шифрования учетных данных. Этот самозаверяющий сертификат помогает повысить безопасность, но не защищает от подмены удостоверений сервером. Если используется самозаверяющий сертификат и параметр ForceEncryption имеет значение Да, все данные, передаваемые по сети между SQL Server и клиентским приложением, будут зашифрованы с помощью самозаверяющего сертификата.

При использовании самозаверяющего сертификата SQL Server записывает в журнал ошибок следующее сообщение:

SQL Server 2016 (13.x) и более ранних версиях используется алгоритм SHA1. Однако алгоритм SHA1 и многие более старые алгоритмы стали устаревшими, начиная с SQL Server 2016 г. (13.x). Дополнительные сведения см. в статье Устаревшие функции ядра СУБД в SQL Server 2016 г.

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

Подготовьте новый самозаверяющий или сторонний сертификат, использующий более надежные алгоритмы шифрования, и настройте SQL Server для использования этого нового сертификата.
Так как теперь вы понимаете причину флага, сообщение можно игнорировать (не рекомендуется).
Выполните обновление до SQL Server 2017 (14.x) или более поздней версии, которая использует более надежный хэш-алгоритм (SHA256) для самозаверяющих сертификатов.

Скрипт PowerShell для создания самозаверяющего сертификата для SQL Server

Следующий фрагмент кода можно использовать для создания самозаверяющего сертификата на компьютере под управлением SQL Server. Сертификат соответствует требованиям к шифрованию для изолированного экземпляра SQL Server и сохраняется в хранилище сертификатов локального компьютера (PowerShell должен быть запущен от имени администратора):

Распространенные угрозы SQL

Полезно знать, какие распространенные угрозы представляют опасность для SQL Server:

Внедрение кода SQL — это атака, во время которой вредоносный код вставляется в строки, которые будут переданы экземпляру SQL Server для и выполнения.
- Атака осуществляется посредством завершения текстовой строки и присоединения к ней новой команды. Поскольку к вставленной команде перед выполнением могут быть добавлены дополнительные строки, злоумышленник заканчивает внедряемую строку меткой комментария «—«.
- SQL Server будет выполнять любой полученный синтаксически корректный запрос.
Помните о атаках на стороне канала, вредоносных программах& и других угрозах.

Риск внедрения кода SQL

Чтобы минимизировать риск внедрения кода SQL, учитывайте следующее.

Проверяйте любой процесс, создающий SQL-запросы, на наличие угроз внедрения кода.
Конструируйте динамически создаваемые операторы SQL параметризованным образом.
Разработчики и администраторы безопасности должны просматривать все фрагменты кода, вызывающие инструкции EXECUTE, EXEC или процедуру sp_executesql.
Запретите использование следующих символов в вводе
- ; Разделитель запросов
- ‘ Разделитель строк символьных данных
- — Разделитель однострочных комментариев.
- / * … * / Разделители комментариев.
- xp_
  Мы не рекомендуем использовать xp_cmdshell в среде SQL Server. Используйте вместо этой процедуры SQLCLR или постарайтесь найти другие варианты, поскольку xp_cmdshell может представлять определенные риски.
  
  Расширенные в каталоге хранимые процедуры, такие как xp_cmdshell.
Всегда , и не допускайте утечки информации об ошибках, чтобы они не попали в руки злоумышленника.

Риски атак по сторонним каналам

Чтобы минимизировать риск атак по сторонним каналам, учитывайте следующее.

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