КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА NOSQL БАЗ ДАННЫХ НА УРОВНЕ ПРИЛОЖЕНИЯ

Введение

Широкое внедрение NoSQL систем управления базами данных в корпоративные и облачные инфраструктуры порождает новые угрозы безопасности: в отличие от реляционных СУБД, большинство NoSQL-платформ исторически разрабатывалось с акцентом на горизонтальное масштабирование и высокую доступность, а не на встроенные механизмы шифрования [1, с. 14]. По данным аналитического отчёта Gartner за 2023 год, свыше 40% утечек корпоративных данных связано с недостаточной защитой документных и ключ-значение хранилищ [2, с. 7]. В частности, MongoDB, занимающая первое место среди документных СУБД по индексу DB-Engines, вплоть до версии 4.2 не поддерживала нативное шифрование на уровне поля [3, с. 122].

Данная работа ставит целью разработку архитектурного решения и программной реализации middleware-уровня криптографической защиты, прозрачно интегрируемого в существующие приложения вне зависимости от конкретной NoSQL СУБД. Принципиальное отличие предложенного подхода от конкурентных решений состоит в реализации дифференцированной политики шифрования: поля с высокой кардинальностью (идентификаторы, числовые показатели) защищаются детерминированным AES-256-SIV, допускающим операции сравнения и range-запросы; поля с персональными данными (ФИО, адреса, биометрика) – рандомизированным AES-256-GCM с уникальным вектором инициализации для каждого документа [4, с. 310].

Анализ существующих подходов к защите NoSQL СУБД

Традиционно выделяют три уровня реализации шифрования в контексте баз данных: уровень хранилища (disk encryption), уровень транспорта (TLS/SSL) и уровень приложения. Шифрование на уровне хранилища, реализованное, например, в MongoDB Enterprise через WiredTiger Engine, защищает данные «в покое», однако не предотвращает несанкционированный доступ со стороны администратора СУБД или при компрометации учётных данных суперпользователя [5, с. 89]. Транспортное шифрование защищает данные при передаче, оставляя их открытыми непосредственно в СУБД.

Шифрование на уровне приложения (Application Level Encryption, ALE) устраняет оба недостатка: данные поступают в СУБД уже в зашифрованном виде, ключи шифрования никогда не передаются в базу данных, а сам движок СУБД не имеет доступа к открытому тексту [6, с. 201]. Данный подход реализован в облачных продуктах (MongoDB Atlas FLE, AWS DynamoDB Client-Side Encryption), однако его применение в on-premise инсталляциях требует самостоятельной реализации, что и определяет актуальность настоящей работы [3, с. 130].

Таблица 1 – Сравнительный анализ подходов к шифрованию в NoSQL СУБД

Архитектура middleware-слоя криптографической защиты

Предлагаемая архитектура включает три основных компонента: Crypto Engine (движок шифрования), Key Management Service (служба управления ключами) и Policy Manager (менеджер политик). Crypto Engine реализует алгоритмы AES-256-GCM для рандомизированного и AES-256-SIV для детерминированного шифрования. KMS обеспечивает иерархическое управление ключами по схеме Data Encryption Key (DEK) → Key Encryption Key (KEK), что соответствует рекомендациям NIST SP 800-57 [7, с. 44].

На рисунке 1 представлена IDEF0-диаграмма функциональной модели системы. Вход A0 получает данные приложения, ключи шифрования и запросы пользователей; управляющими воздействиями выступают корпоративные политики безопасности и криптографические стандарты (ГОСТ Р 34.12-2015, NIST FIPS 197); механизмами – программный модуль шифрования и аппаратный модуль безопасности (HSM/KMS). На выходе формируются зашифрованные документы, журнал аудита и метаданные ключей.

Рисунок 1. IDEF0-диаграмма криптографической защиты NoSQL баз данных.

Программная реализация на языке python

Реализация выполнена на Python 3.14 с использованием библиотеки cryptography версии 41.0, обеспечивающей безопасные примитивы AESGCM и AES-SIV, и pymongo 4.6 для взаимодействия с MongoDB [8, с. 77]. Ниже приведён листинг основного класса FieldEncryptor, реализующего шифрование/расшифрование полей документа:

# Листинг 1. Модуль криптографической защиты полей (field_encryptor.py)
import os, json
from cryptography.hazmat.primitives.ciphers.aead import AESGCM, AESSIV
from pymongo import MongoClient
from base64 import b64encode, b64decode

class FieldEncryptor:

“”"Шифрует/расшифровывает отдельные поля документа MongoDB.”"”


def __init__(self, key_hex: str):
key = bytes.fromhex(key_hex)

self.gcm = AESGCM(key) # рандомизированное (AES-256-GCM)

self.siv = AESSIV(key * 2) # детерминированное (AES-256-SIV)

# — шифрование —

def encrypt_rand(self, plaintext: str) -> str:
nonce = os.urandom(12) # уникальный IV для каждого поля

ct = self.gcm.encrypt(nonce, plaintext.encode(), None)

return b64encode(nonce + ct).decode()


def encrypt_det(self, plaintext: str) -> str:
ct = self.siv.encrypt(plaintext.encode(), None)

return b64encode(ct).decode()


# — расшифрование —

def decrypt_rand(self, token: str) -> str:
raw = b64decode(token)

return self.gcm.decrypt(raw[:12], raw[12:], None).decode()


def decrypt_det(self, token: str) -> str:

return self.siv.decrypt(b64decode(token), None).decode()


# — применить политику к документу —

def protect(self, doc: dict, policy: dict) -> dict:

“”"policy = {‘field’: ‘rand’|'det’|'plain’}”"”

out = {}

for k, v in doc.items():
mode = policy.get(k, ‘plain’)

if mode == ‘rand’:
out[k] = self.encrypt_rand(str(v))

elif mode == ‘det’:
out[k] = self.encrypt_det(str(v))

else:
out[k] = v

return out

# — пример использования —
if __name__ == ‘__main__’:
KEY = os.urandom(32).hex() # генерация 256-битного ключа

enc = FieldEncryptor(KEY)

policy = {‘full_name’: ‘rand’, ‘email’: ‘rand’,

‘user_id’: ‘det’, ‘city’: ‘det’}

doc = {‘user_id’: ‘U-1042′, ‘full_name’: ‘Алиев Данияр’,

‘email’: ‘daniyar@example.kz’, ‘city’: ‘Алматы’}

protected = enc.protect(doc, policy)

print(“Защищённый документ:”, json.dumps(protected, ensure_ascii=False, indent=2))


# сохранение в MongoDB

client = MongoClient(‘mongodb://localhost:27017/’)
db = client['secure_db']
db.users.insert_one(protected)

Листинг 2 демонстрирует реализацию службы управления ключами с поддержкой ротации DEK через KEK:

# Листинг 2. Служба управления ключами (key_manager.py)
import os, hashlib
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
from base64 import b64encode, b64decode

class KeyManager:

“”"Иерархическое управление ключами: KEK -> DEK.”"”


def __init__(self, master_secret: bytes):

# KEK выводится из мастер-секрета через HKDF

self.kek = HKDF(

algorithm=hashes.SHA256(), length=32,

salt=None, info=b’nosql-kek-v1′

).derive(master_secret)

self.gcm = AESGCM(self.kek)


def generate_dek(self) -> tuple[bytes, str]:

“”"Возвращает (открытый DEK, зашифрованный DEK для хранения).”"”

dek = os.urandom(32)
nonce = os.urandom(12)
encrypted = self.gcm.encrypt(nonce, dek, None)

return dek, b64encode(nonce + encrypted).decode()


def unwrap_dek(self, wrapped: str) -> bytes:
raw = b64decode(wrapped)

return self.gcm.decrypt(raw[:12], raw[12:], None)


def rotate_dek(self, old_wrapped: str) -> tuple[bytes, str]:

“”"Ротация ключа шифрования данных без смены KEK.”"”

_old = self.unwrap_dek(old_wrapped) # проверяем целостность

return self.generate_dek() # выпускаем новый DEK

Модель угроз и матрица соответствия

В соответствии с методологией STRIDE, для рассматриваемой системы выделены следующие категории угроз: перехват трафика между приложением и СУБД; несанкционированный доступ администратора СУБД к данным; компрометация файловой системы сервера. Предложенные механизмы защиты покрывают все три угрозы посредством транспортного TLS, поля-ориентированного ALE и шифрования ключей через KMS соответственно [9, с. 512]. В таблице 2 представлена матрица соответствия реализованных механизмов требованиям ГОСТ Р 34.12-2015 и NIST SP 800-111.

Таблица 2 – Матрица соответствия механизмов защиты требованиям стандартов

Результаты эксперимента и анализ производительности

Для оценки накладных расходов предложенного решения проведён нагрузочный эксперимент на тестовом стенде: сервер MongoDB 7.0, Python 3.11, 8-ядерный процессор Intel Xeon E5-2630 v4, 32 ГБ ОЗУ. Набор данных составил 10 000 документов с полями, описывающими профиль пользователя (6 текстовых и 4 числовых поля). Каждый тест повторялся 5 раз, результаты усреднялись [10, с. 88].

На рисунке 2 приведены матрица корреляции ключевых показателей производительности криптографических алгоритмов и сравнительная гистограмма скорости шифрования, задержки запроса и накладных расходов для AES-256, ChaCha20, RSA-2048, AES-GCM и SHA-3. Высокая положительная корреляция (r = 0.88) между скоростью шифрования и пропускной способностью системы подтверждает, что AES-256-GCM является оптимальным выбором для поля-уровневого шифрования: при скорости 290 MB/s накладные расходы составляют всего 12%, тогда как RSA-2048, применяемый только для оборачивания ключей, демонстрирует задержку 18.3 мс.

Рисунок 2. Анализ производительности криптографических алгоритмов при защите NoSQL баз данных на уровне приложения.

Таблица 3 – Производительность middleware-слоя при различных объёмах документов

Заключение

В настоящей работе предложена и реализована архитектура middleware-слоя криптографической защиты NoSQL баз данных на уровне приложения. Сформулированы принципы дифференцированного шифрования полей с учётом требований к поиску: детерминированный AES-256-SIV для полей с высокой кардинальностью, рандомизированный AES-256-GCM – для полей с персональными данными. Реализована иерархическая схема управления ключами KEK/DEK на основе HKDF-SHA256. Экспериментально показано, что накладные расходы предложенного решения составляют 13–31% в зависимости от размера документа, что является приемлемым для большинства корпоративных приложений.

Направлениями дальнейших исследований являются: интеграция с аппаратными модулями безопасности (HSM) класса FIPS 140-3 уровня 3; реализация поддержки Queryable Encryption для Apache Cassandra; применение гомоморфного шифрования для полей, участвующих в агрегационных запросах.

1. Fowler M., Sadalage P. J. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. - Boston : Addison-Wesley, 2013. - 192 с.
2. Gartner Inc. Market Guide for Database Security, 2023. - Stamford : Gartner, 2023. - 48 с.
3. MongoDB Inc. MongoDB Security Manual. Version 7.0. - New York : MongoDB, Inc., 2023. - 210 с.
4. Ferguson N., Schneier B., Kohno T. Cryptography Engineering: Design Principles and Practical Applications. - Indianapolis : Wiley, 2010. - 384 с.
5. Чмора А. Л. Современная прикладная криптография. - 2-е изд. - М. : Гелиос АРВ, 2002. - 256 с.
6. Viega J., Messier M. Secure Programming Cookbook for C and C++. - Sebastopol : O’Reilly, 2003. - 784 с.
7. NIST Special Publication 800-57. Recommendation for Key Management. Part 1: General. - Gaithersburg : NIST, 2020. - 156 с.
8. Python Software Foundation. cryptography 41.0 Documentation [Электронный ресурс]. - Режим доступа: https://cryptography.io (дата обращения: 10.10.2023).
9. Anderson R. Security Engineering: A Guide to Building Dependable Distributed Systems. 3rd ed. - Hoboken : Wiley, 2020. - 1232 с.
10. Bassil Y. Performance Analysis of Encryption / Decryption Algorithms // International Journal of Computer Science Issues. - 2012. - Vol. 9, No. 3. - P. 84–95.

Все статьи автора «Mar4eluk»