Общие сведения об управлении ключами для Always Encrypted

Статья
08/21/2023

Область применения: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

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

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

Ключи шифрования столбцов — это ключи шифрования содержимого, используемые для шифрования данных. Как следует из названия, ключи шифрования столбцов применяются для шифрования данных в столбцах базы данных. Вы можете зашифровать один или несколько столбцов с одним ключом шифрования столбцов или использовать несколько ключей шифрования столбцов в зависимости от требований приложения. Ключи шифрования столбцов являются зашифрованными. В базе данных хранятся только зашифрованные значения ключей шифрования столбцов (в составе метаданных ключа шифрования столбца). Метаданные ключа шифрования столбца хранятся в представлениях каталога sys.column_encryption_keys (Transact-SQL) и sys.column_encryption_key_values (Transact-SQL) . Длина ключей шифрования столбцов, используемых с алгоритмом AES-256, составляет 256 бит.
Главные ключи столбцов используются для защиты путем шифрования ключей шифрования столбцов. Главные ключи столбцов должны храниться в надежном хранилище ключей, например хранилище сертификатов Windows, хранилище ключей Azure или аппаратном модуле безопасности. В базе данных содержатся только метаданные о главных ключах столбцов (тип хранилища ключей и местоположение). Метаданные главного ключа столбца хранятся в представлении каталога sys.column_master_keys (Transact-SQL) .

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

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

Задачи управления ключами

Процесс управления ключами можно разделить на следующие высокоуровневые задачи:

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

Роли в управлении ключами

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

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

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

Управление ключами с разделением ролей

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

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

Управление ключами без разделения ролей

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

Средства для управления ключами постоянного шифрования

Для управления ключами постоянного шифрования можно использовать среду SQL Server Management Studio (SSMS) и PowerShell.

SQL Server Management Studio (SSMS) предоставляет диалоговые окна и мастеры, которые объединяют задачи, связанные с доступом к хранилищу ключей и доступом к базам данных, поэтому SSMS не поддерживает разделение ролей, но упрощает настройку ключей. Дополнительные сведения об управлении ключами с помощью среды SSMS см. в разделе:
- Подготовка к работе ключей Always Encrypted с помощью SQL Server Management Studio
- Ротация ключей Always Encrypted с помощью SQL Server Management Studio
SQL Server PowerShell содержит командлеты для управления ключами Always Encrypted с разделением ролей и без него. Дополнительные сведения см. в разделе:
- Настройка ключей постоянного шифрования с помощью PowerShell
- Смена ключей Always Encrypted с помощью PowerShell

Вопросы безопасности для управления ключами

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

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

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

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

Поделиться через