Ключ шифрования базы данных

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

Назначение и принцип работы

Основная цель использования ключа шифрования БД — защита хранящейся информации от несанкционированного доступа, в том числе при физической краже носителей (жёстких дисков, SSD, резервных копий), перехвате трафика или атаках на уровне операционной системы. Шифрование может применяться как ко всей базе данных целиком (Transparent Data Encryption, TDE), так и к отдельным таблицам, столбцам (например, к полям с паролями, номерами кредитных карт, медицинскими записями) или даже к отдельным ячейкам.

Принцип работы основан на криптографических алгоритмах. Данные перед записью на диск шифруются с использованием ключа, а при чтении — расшифровываются. В современных системах обычно применяются симметричные алгоритмы (например, AES-256), где один и тот же ключ используется и для шифрования, и для расшифрования. Ключ генерируется случайным образом или на основе пароля пользователя (с применением функций выведения ключа, таких как PBKDF2 или bcrypt).

Типы ключей шифрования

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

Мастер-ключ (Master Key)

Мастер-ключ — это ключ самого высокого уровня в иерархии. Он защищает нижележащие ключи. Обычно хранится вне базы данных — в аппаратном модуле безопасности (HSM), в облачном хранилище ключей (AWS KMS, Azure Key Vault), в защищённом файле операционной системы или на смарт-карте. Доступ к мастер-ключу строго ограничен. Его компрометация означает компрометацию всей системы шифрования.

Ключ шифрования базы данных (Database Encryption Key, DEK)

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

Ключи столбцов (Column Encryption Keys)

В некоторых СУБД (например, Microsoft SQL Server) для шифрования отдельных столбцов применяются специальные ключи. Они могут быть как симметричными, так и асимметричными. Ключ шифрования столбца (CEK) защищается сертификатом или асимметричным ключом, который, в свою очередь, может быть защищён мастер-ключом.

Методы управления ключами

Управление жизненным циклом ключей (генерация, хранение, ротация, отзыв, уничтожение) — критически важный аспект безопасности.

Хранение ключей

• Аппаратные модули безопасности (HSM) — специализированные устройства, защищённые от физического взлома, выполняющие криптографические операции внутри себя. Ключи никогда не покидают HSM в открытом виде. Самый безопасный метод.
• Облачные сервисы управления ключами (KMS) — управляемые сервисы от провайдеров (AWS, Azure, Google Cloud), которые хранят ключи и предоставляют API для шифрования/расшифрования. Удобны для облачных инфраструктур.
• Файловая система ОС — ключи могут храниться в зашифрованных файлах, доступ к которым ограничен правами доступа ОС. Менее безопасный метод, но простой в реализации.
• Внутреннее хранилище СУБД — мастер-ключ может храниться внутри самой базы данных (в зашифрованном виде паролем), но это создаёт риск, так как доступ к БД может дать доступ и к ключу.

Ротация ключей

Ротация (смена) ключей производится периодически или при подозрении на компрометацию. В иерархических системах ротация мастер-ключа не требует перешифрования данных — достаточно перешифровать DEK. Ротация DEK требует перешифрования всех данных, что может быть ресурсоёмкой операцией, поэтому её планируют на периоды низкой нагрузки.

Резервирование и восстановление

Потеря ключа шифрования равносильна потере всех данных — расшифровать их станет невозможно. Поэтому ключи обязательно резервируются. Резервные копии ключей должны храниться в надёжном, физически и логически изолированном месте, с контролем доступа. Обычно практикуется разделение резервной копии на несколько частей (например, по схеме M из N), чтобы один человек не мог восстановить ключ.

Классификация по типу шифрования

Шифрование на уровне приложения

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

Прозрачное шифрование (TDE)

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

Шифрование на уровне файловой системы

Ключ используется для шифрования файлов БД на уровне ОС (например, с помощью dm-crypt/LUKS в Linux или BitLocker в Windows). База данных не участвует в процессе. Этот метод защищает от кражи носителей, но не защищает данные внутри работающей СУБД.

Угрозы и уязвимости

• Компрометация ключа — основная угроза. Если злоумышленник получает ключ, всё шифрование теряет смысл.
• Утечка ключа из памяти — ключи, загруженные в оперативную память, могут быть извлечены с помощью атак типа cold boot attack или через дамп памяти.
• Атаки на HSM — хотя HSM считаются надёжными, существуют атаки на их прошивку или физический интерфейс.
• Человеческий фактор — неправильное хранение резервных копий ключей, слабые пароли, утечка ключей через социальную инженерию.
• Отсутствие ротации — длительное использование одного ключа увеличивает риск его компрометации.

Правовые и нормативные требования

Использование ключей шифрования баз данных регулируется законодательством и отраслевыми стандартами. В России требования к криптографической защите информации, включая шифрование баз данных, устанавливаются Федеральной службой по техническому и экспортному контролю (ФСТЭК России) и Федеральной службой безопасности (ФСБ России). Для обработки персональных данных (ФЗ-152), государственной тайны или иной конфиденциальной информации часто требуется использование сертифицированных криптографических средств (например, на базе ГОСТ 28147-89 или ГОСТ Р 34.12-2015). Ключи шифрования должны генерироваться, храниться и уничтожаться в соответствии с утверждёнными политиками безопасности организации.

Примеры реализации в популярных СУБД

• Microsoft SQL Server — использует TDE с мастер-ключом сервера (Service Master Key) и ключом шифрования базы данных (DEK). Для шифрования столбцов применяются сертификаты и асимметричные ключи.
• Oracle Database — TDE использует мастер-ключ (кеш) и ключи для табличных пространств. Поддерживаются аппаратные модули безопасности.
• MySQL / MariaDB — TDE реализовано через подключаемые модули (например, keyring_plugin). Ключи могут храниться в файле или в HSM.
• PostgreSQL — не имеет встроенного TDE, но поддерживает расширения (например, pgcrypto для шифрования столбцов) и шифрование на уровне файловой системы.

Источники

• Федеральный закон «О персональных данных» от 27.07.2006 № 152-ФЗ.
• Методические документы ФСТЭК России по защите информации.
• Стандарты шифрования: ГОСТ 28147-89, ГОСТ Р 34.12-2015, AES (FIPS 197).
• Документация Microsoft SQL Server: «Transparent Data Encryption (TDE)».
• Документация Oracle Database: «Transparent Data Encryption Overview».
• Документация PostgreSQL: «pgcrypto».
• Книга: «Database Security and Auditing» by Hassan A. Afyouni.