Лучшие методы шифрования для безопасности ИИ-API

Если бы мне пришлось уместить это в одну строку — TLS 1.3 это базовый уровень, mTLS доказывает машинную идентичность, а шифрование полезной нагрузки покрывает данные, которые всё ещё важны после завершения TLS.

Атаки на ИИ-API выросли на 681% с первой половины 2022 года до первой половины 2023 года. Так что если я защищаю ИИ-API, я не ищу одно решение. Я смотрю на слои. Эта статья сравнивает 7 методов шифрования по наиболее важным пунктам:

• охват безопасности
• стоимость производительности
• усилия по управлению ключами
• покрытие транспортного уровня против прикладного
• пригодность для развёртываний в США

Вот краткая версия:

• Симметричное шифрование лучше всего подходит для больших полезных нагрузок и хранимых данных.
• Шифрование с открытым ключом лучше всего подходит для обмена ключами и подписей.
• Гибридное шифрование смешивает оба, поэтому оно подходит для большинства случаев на прикладном уровне.
• TLS 1.2/1.3 защищает данные в пути, при этом TLS 1.3 по умолчанию.
• mTLS проверяет обе стороны соединения.
• Шифрование на уровне полей защищает только те поля, которые должны оставаться скрытыми.
• Конвертное шифрование значительно облегчает ротацию ключей в больших масштабах.

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

Защита конфиденциальных данных в ИИ-приложениях

Быстрое сравнение

Так что если вам нужен краткий ответ, вот он: используйте TLS 1.3 по умолчанию, добавьте mTLS для идентичности сервисов и применяйте шифрование на уровне полей, гибридное или конвертное, когда данные должны оставаться защищёнными за пределами самого соединения.

1. Симметричное шифрование

Симметричное шифрование — это быстрый способ защитить массовые данные. Но само по себе оно не решает проблему обмена ключами. Оно использует один общий ключ и для шифрования, и для расшифровки, что делает его ключевой частью безопасности ИИ-API. Обычный выбор — AES-256-GCM, потому что он быстрый и включает встроенные проверки целостности ^[4][10].

Охват безопасности

AES-256-GCM хорошо работает в двух местах: данные в покое и данные в пути. Сюда входят хранимые обучающие наборы, веса моделей, архивированные выводы и массовое шифрование, используемое внутри TLS 1.3 ^[3][2]. Поскольку GCM — это режим AEAD, он защищает секретность и добавляет тег аутентификации, который помогает выявить подмену промптов или мультимодальных полезных нагрузок ^[4].

Есть одно ограничение, которое нельзя игнорировать: симметричное шифрование защищает данные только до того, как они достигнут модели. Во время инференса модель должна работать с открытым текстом. Это значит, что открытые данные всё ещё могут быть раскрыты в оперативной памяти или памяти GPU ^[7].

Влияние на производительность

AES-256-GCM может достигать 4.2 GB/s на стандартных серверных CPU с поддержкой AES-NI ^[8]. Проще говоря, шифрование небольшого промпта занимает микросекунды, что намного меньше сетевой задержки или времени выполнения модели ^[8].

На мобильных клиентах или граничных устройствах без AES-NI ChaCha20-Poly1305 обычно подходит лучше. Он настроен на программную производительность, достигает 3.4 GB/s на оборудовании вроде Apple A17 Pro и даёт тот же 256-битный уровень безопасности ^[8].

Управление ключами

Вот в чём загвоздка: обеим сторонам нужен один и тот же секрет. Так что трудная часть — безопасно поделиться этим ключом, что обычно означает привлечение асимметричной криптографии.

В масштабе команды часто обёртывают симметричные ключи с помощью KEK, чтобы можно было перевыпускать ключи данных без перешифровки всей полезной нагрузки ^[2][11]. Ротация KEK должна быть автоматизирована, а ключи должны находиться в валидированном по FIPS 140-3 Level 3 HSM или выделенном менеджере секретов, а не в файлах конфигурации или исходном коде приложения ^[11][10].

Именно эта проблема общего ключа и есть причина, по которой асимметричное шифрование идёт следующим.

Наиболее подходящий сценарий использования ИИ-API

Симметричное шифрование подходит для массовых полезных нагрузок. Подумайте об изображениях высокого разрешения, видеофайлах, длинных аудиоклипах и больших телах JSON-запросов ^[4]. Оно также хорошо работает для долгосрочного архивирования и изоляции по арендаторам, где DEK обёртываются ключами конкретного арендатора, чтобы держать данные разделёнными ^[2][10].

Однако для транспорта и обмена ключами симметричное шифрование — лишь одна часть стека.

2. Асимметричное шифрование

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

• открытый ключ, к которому может получить доступ каждый
• закрытый ключ, который хранит только владелец

Если данные зашифрованы открытым ключом, только соответствующий закрытый ключ может их расшифровать.

Охват безопасности

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

Вот тут-то и появляется шифрование на уровне сообщений. Когда вы шифруете данные асимметричными ключами, конфиденциальное содержимое — вроде PII внутри промпта — может оставаться зашифрованным по мере прохождения через внутренние системы логирования, сервисные меши и распределённые конвейеры трассировки ^[4][12].

Оно также поддерживает цифровые подписи. Эти подписи помогают проверить, что промпт пришёл от заявленного отправителя, и обеспечивают неотказуемость ^[4].

Компромисс прост: этот уровень защиты стоит гораздо больше вычислительных ресурсов.

Влияние на производительность

Асимметричное шифрование слишком медленное для больших полезных нагрузок вроде изображений, видео или аудио. Используйте его для ключей и подписей, а не для массовых данных ^[14].

Для подписей ECC и Ed25519 работают лучше RSA и лучше подходят для современной аутентификации ИИ-API ^[14].

Управление ключами

Закрытые ключи должны находиться в валидированном по FIPS 140-3 Level 3 HSM или доверенной среде выполнения (TEE) ^[10]. Открытые ключи часто распространяются через конечную точку JWKS (JSON Web Key Set), что позволяет партнёрам API находить и проверять ключи автоматически ^[5].

Ротация ключей должна происходить по 90-дневному циклу, чтобы ограничить ущерб в случае компрометации ключа ^[5].

Разрыв в стоимости здесь трудно игнорировать. В AWS KMS асимметричные RSA-операции могут стоить до $12.00 за 10,000 запросов, тогда как симметричные операции стоят около $0.03 за 10,000 запросов ^[14].

Наиболее подходящий сценарий использования ИИ-API

Асимметричное шифрование работает лучше всего для обмена ключами и аутентификации. В многоарендных ИИ-API оно чаще всего используется для обёртывания симметричных ключей и проверки подлинности промпта ^[4]. Оно также поддерживает аутентификацию клиента через mTLS ^[1].

Есть ещё одна проблема, к которой командам нужно готовиться уже сейчас: постквантовая миграция. Стандартные RSA и ECC будут уязвимы для будущих квантовых атак. NIST финализировал свои первые стандарты постквантовой криптографии — FIPS 203, 204 и 205 — в августе 2024 года, и ранние бенчмарки показывают, что ML-KEM добавляет менее 5% накладных расходов на производительность по сравнению с RSA-2048 на стандартном серверном оборудовании ^[3][10].

На практике асимметричное шифрование защищает ключи, а симметричное шифрование защищает полезную нагрузку.

3. Гибридное шифрование

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

Охват безопасности

Гибридное шифрование держит полезные нагрузки зашифрованными даже после завершения TLS, включая внутри сервисных мешей, прокси и логов. Каждый запрос получает свой собственный недолговечный DEK, что сокращает радиус поражения в случае раскрытия одного ключа.

Использование AES-256-GCM также добавляет тег аутентификации. Этот тег помогает выявить подмену, прежде чем ИИ-система коснётся полезной нагрузки. Для транспорта этот слой работает вместе с TLS, а не вместо него.

Влияние на производительность

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

Управление ключами

Держите KEK в HSM, генерируйте недолговечный DEK для каждого запроса и прикрепляйте key_id, чтобы DEK можно было переобёртывать без перешифровки полезной нагрузки. Такая настройка делает ротацию ключей гораздо менее болезненной.

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

Наиболее подходящий сценарий использования ИИ-API

Гибридное шифрование имеет смысл для путей ИИ-API, где данные пересекают границу доверия после завершения TLS, таких как:

• многоузловые архитектуры
• обратные прокси
• балансировщики нагрузки
• сервисные меши

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

Для постквантовой миграции нужно изменить только слой обёртывания. Замена RSA или ECDH на ML-KEM (FIPS 203) помогает защитить хранимый шифротекст, который мог бы быть расшифрован позже, тогда как симметричный слой AES-256 остаётся тем же ^[10]. Гибридное шифрование обеспечивает защиту полезной нагрузки за пределами TLS; следующий слой — транспортная аутентификация с TLS и mTLS.

4. TLS 1.2/1.3

TLS — это базовый слой транспортной безопасности для любого ИИ-API. TLS 1.3 должен быть по умолчанию. Если гибридное шифрование защищает данные за пределами сетевого края, то TLS защищает путь через саму сеть. Проще говоря: TLS защищает данные в пути, а шифрование полезной нагрузки покрывает то, что всё ещё может быть раскрыто после завершения TLS.

Охват безопасности

TLS 1.3 отбрасывает слабые устаревшие наборы шифров вроде RC4, DES и 3DES. TLS 1.2 всё ещё может их разрешать, если вы сами их не отключите ^[10][18]. TLS 1.3 также требует Perfect Forward Secrecy (PFS) и шифрует сертификат клиента во время рукопожатия, что значительно усложняет пассивный мониторинг внутренних отношений между сервисами ^[15][17].

Влияние на производительность

TLS 1.3 сокращает рукопожатие с 2 RTT до 1 ^[15][9]. Это может показаться незначительным, но на высокочастотных нагрузках вроде аудио или видеостриминга в реальном времени это помогает снизить задержку p99 и облегчить нагрузку на CPU.

TLS 1.3 также допускает возобновление 0-RTT, поэтому возобновлённые сессии могут отправлять данные сразу. Это быстро, но есть компромисс: у 0-RTT есть риск повторного воспроизведения. Для конфиденциальных маршрутов API отключите 0-RTT ^[16].

Управление ключами

Работа с сертификатами — это то, где многие команды либо остаются собранными, либо становятся небрежными. Безопасный путь прост:

• Ротируйте сертификаты каждые 90 дней ^[16][9]
• Используйте автоматический выпуск для публичных конечных точек, таких как Let's Encrypt ^[1]
• Храните закрытые ключи в HSM или TEE, а не в экспортируемых PEM-файлах ^[3][10]
• В регулируемых установках используйте модули, валидированные по FIPS 140-3 ^[10]
• Если TLS 1.2 нельзя обновить, разрешайте только наборы шифров на основе ECDHE, чтобы сохранить прямую секретность ^[10]
• Включите сшивание OCSP, чтобы проверки сертификатов были быстрее и не добавляли ещё один сетевой круговой обход во время рукопожатия ^[9]

Наиболее подходящий сценарий использования ИИ-API

TLS 1.3 — правильный выбор по умолчанию для публичных конечных точек, браузерных приложений и мультимодальных WebSocket-потоков реального времени ^[15][16]. TLS 1.2 всё ещё приемлем как совместимый минимум для более старых корпоративных интеграций, но только если он ограничен наборами шифров исключительно с PFS ^[10].

Для трафика между сервисами mTLS добавляет проверку идентичности.

5. Взаимный TLS (mTLS)

mTLS строится поверх TLS, проверяя обе стороны — клиента и сервер — с помощью сертификатов до отправки любых данных приложения.

Охват безопасности

Это закрывает пробел, который оставляют API-ключи. API-ключ доказывает секрет. Он не доказывает, какая рабочая нагрузка совершает вызов.

Для ИИ-агентов, микросервисов и других идентичностей рабочих нагрузок mTLS ограничивает доступ проверенными сервисами. Это важно на конфиденциальных конечных точках моделей и когда системы обмениваются мультимодальными данными вроде изображений и голоса ^[15][13][20].

Влияние на производительность

Главный недостаток — дополнительная работа рукопожатия. mTLS обычно добавляет около 1–2 миллисекунд задержки и на 5–10% больше времени рукопожатия, чем стандартный TLS ^[21].

Распространённый способ уменьшить этот удар — завершать mTLS на API-шлюзе или граничном фаерволе. Это держит асимметричную криптографическую работу вдали от среды выполнения модели ^[17][15]. Пул соединений и заголовки keep-alive также помогают распределить эту стоимость по многим запросам, вместо того чтобы платить её с нуля каждый раз ^[21].

Управление ключами

mTLS требует надёжного PKI-процесса для выпуска, ротации и отзыва сертификатов ^[6][19]. Эту часть нельзя обрабатывать небрежно. Если пропущено продление сертификата, трафик между сервисами может тут же отказать ^[19].

Используйте автоматизированные PKI-инструменты для обработки выпуска, ротации и отзыва в масштабе. Для закрытых ключей аппаратное хранилище вроде HSM или TPM через PKCS#11 помогает держать ключи неэкспортируемыми ^[13]. Недолговечные сертификаты тоже снижают риск. SPIFFE рекомендует сроки жизни всего до 1 часа для идентичностей рабочих нагрузок ^[21].

Наиболее подходящий сценарий использования ИИ-API

mTLS работает лучше всего для трафика между машинами. Подумайте об ИИ-агентах, вызывающих внутренние базы данных, микросервисах, передающих конфиденциальные мультимодальные данные, и регулируемых интеграциях, которым нужно криптографическое доказательство происхождения. В таких установках mTLS действует как дополнительный слой аутентификации наряду с аутентификацией по API-ключу ^[15][20].

Используйте mTLS для идентичности на уровне соединения. Используйте шифрование на уровне полей, когда определённые поля должны оставаться защищёнными даже после транспорта.

6. Шифрование на уровне полей

mTLS говорит вам, кто вызывает. Шифрование на уровне полей защищает конфиденциальные значения внутри того, что они отправляют.

Ключевое отличие простое: вместо шифрования всей полезной нагрузки шифрование на уровне полей покрывает только те поля, которые должны оставаться скрытыми после завершения транспорта. Это значит, что защита по-прежнему важна даже после того, как TLS и mTLS сделали свою часть.

Охват безопасности

TLS защищает данные в пути. Шифрование на уровне полей защищает сами данные после завершения TLS.

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

Однако есть компромисс. Модель может работать только с полями, оставленными в открытом тексте. Так что если модели нужно значение для выполнения её задачи, это поле не может оставаться зашифрованным во время инференса. На практике это значит, что вы должны шифровать только то, что модели не нужно. Также есть небольшая стоимость обработки для каждого защищённого поля.

Влияние на производительность

Шифрование на уровне полей обычно добавляет от 5% до 10% задержки, потому что каждое защищённое поле нужно шифровать и расшифровывать по отдельности.

Эта стоимость обычно приемлема, но только если работа с ключами и идентификаторами полей ведётся аккуратно. Если нет, накладные расходы могут быстро накапливаться.

Управление ключами

Шифрование на уровне полей включает три наиболее важных элемента контроля:

• Используйте изоляцию ключей по арендаторам. Если все арендаторы используют один ключ, единственная компрометация может раскрыть данные всех ^[10].
• Включайте Key ID или тег версии рядом с каждым зашифрованным полем, чтобы устаревшие данные всё ещё можно было расшифровать после ротации, не ломая существующие записи ^[1].
• Используйте ключи полей по арендаторам, чтобы ограничить раскрытие, если один арендатор скомпрометирован.

Наиболее подходящий сценарий использования ИИ-API

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

• Многоарендный ИИ-SaaS — ключи по арендаторам ограничивают радиус поражения, если один арендатор скомпрометирован.
• Внешние конвейеры логирования — PII остаётся зашифрованной, даже когда логи отправляются за пределы платформы.
• ИИ-API в здравоохранении или финансах — конфиденциальные поля остаются зашифрованными в логах, дампах баз данных, очередях и резервных копиях.
• Рабочие процессы с частичным инференсом — модель читает только неконфиденциальные поля.

7. Конвертное шифрование

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

Вот как это работает простыми словами. Случайный ключ шифрования данных (DEK) шифрует саму ИИ-полезную нагрузку, будь то текст, изображение или видеофайл, используя быстрое симметричное шифрование вроде AES-256. Затем ключ шифрования ключа (KEK), хранящийся в KMS или HSM, шифрует сам DEK. Объект, который вы храните или отправляете, включает две вещи: зашифрованную полезную нагрузку и обёрнутый DEK. Такая настройка делает конвертное шифрование хорошим выбором, когда размер полезной нагрузки и ротация ключей важнее контроля на уровне полей.

Охват безопасности

Конвертное шифрование защищает данные на прикладном уровне. Так что даже после завершения TLS полезная нагрузка остаётся защищённой в местах вроде логов, очередей и резервных копий.

Есть одно ограничение, которое нельзя игнорировать: данные всё ещё нужно расшифровывать в памяти во время ИИ-инференса. Если вы не сочетаете конвертное шифрование с конфиденциальными вычислениями, вроде TEE, всё ещё есть окно, когда открытый текст существует в памяти GPU или CPU ^[3][7]. Это компромисс. Большой выигрыш проявляется, когда вы имеете дело с данными в масштабе и не хотите перешифровывать огромные объёмы каждый раз при смене ключа.

Влияние на производительность

Конвертное шифрование гораздо практичнее прямого асимметричного шифрования. Почему? Потому что AES-GCM делает тяжёлую работу над полезной нагрузкой, тогда как асимметричная криптография защищает только небольшой DEK.

Такая настройка добавляет около от 3% до 7% накладных расходов в некоторых средах ^[5].

Для мультимодальных ИИ-API, обрабатывающих изображения высокого разрешения или видео, AES-GCM — сильный выбор, потому что он обеспечивает аутентифицированное шифрование, или AEAD. Короче говоря, он помогает подтвердить, что полезная нагрузка не была изменена в пути ^[4].

Управление ключами

Именно здесь конвертное шифрование блистает. Корпуса для обучения ИИ могут вырастать до терабайтов или даже петабайтов ^[2]. Перешифровка всего датасета каждый раз при смене ключа была бы жестокой операционной задачей.

С конвертным шифрованием вы не касаетесь полезной нагрузки. Вы просто переобёртываете небольшой DEK новым KEK ^[2].

Здесь важны несколько базовых правил:

• Храните KEK в облачном KMS или HSM, а не в переменных окружения приложения.
• Добавляйте метаданные версии к долгоживущим записям, чтобы более старые данные всё ещё можно было расшифровать после смены ключа ^[1].

Наиболее подходящий сценарий использования ИИ-API

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

Плюсы и минусы по сценариям развёртывания

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

Эта таблица превращает предыдущее сравнение метод-за-методом в выбор развёртывания.

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

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

Для регулируемых мультимодальных рабочих нагрузок стек по умолчанию обычно такой:

• TLS 1.3 для транспорта
• mTLS для идентичности
• Шифрование на уровне полей или конвертное для данных, которые должны оставаться защищёнными после завершения

Этот многослойный стек — практичный вариант по умолчанию для регулируемых ИИ-API.

Используйте маскирование, а не шифрование, когда модели нужен контекст поля, но не само сырое значение. Маскирование сохраняет смысл. Шифрование его убирает. Например, замена [email protected] на [EMAIL] всё ещё позволяет модели правильно читать предложение, никогда не видя настоящий адрес.

Заключение

Ни один метод шифрования не делает всё сразу. Выбор сводится к охвату, задержке и одному простому вопросу: где ваши данные всё ещё раскрыты после завершения TLS? На практике решение распадается на три слоя: транспорт, идентичность и защита полезной нагрузки.

TLS 1.3 — транспортный слой по умолчанию для ИИ-API. TLS 1.2 следует использовать только как запасной вариант для устаревших систем. Оттуда другие методы вступают в дело, чтобы покрыть пробелы, которые оставляет TLS. Гибридное шифрование — самая практичная модель на прикладном уровне, потому что оно решает проблему распределения ключей, не замедляя массовое шифрование. Используйте mTLS для проверки машинной идентичности. Затем используйте шифрование на уровне полей или конвертное для данных, которые должны оставаться защищёнными даже после завершения TLS. Конвертное шифрование особенно полезно для больших ИИ-нагрузок, потому что ротация KEK избегает перешифровки петабайтов данных ^[2].

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

Часто задаваемые вопросы

Когда TLS 1.3 недостаточно?

TLS 1.3 помогает защитить данные, пока они движутся между системами. Но эта защита останавливается на границе сервера.

Как только данные достигают ИИ-сервера, их приходится расшифровывать, чтобы модель могла их обработать. И это создаёт пробел: данные затем могут быть раскрыты в памяти, логах или кэшах.

Вот почему одного TLS 1.3 недостаточно, когда данным нужна защита за пределами передачи.

Он также не решает несколько других проблем:

• Целостность данных на протяжении всего жизненного цикла полезной нагрузки
• Подлинность вычисляющей стороны, чтобы вы знали, кто обрабатывает данные
• Долгосрочная защита от атак на основе квантовых вычислений

Так что если вам нужен более жёсткий контроль, вам понадобятся дополнительные слои поверх TLS 1.3, вроде шифрования на уровне полезной нагрузки и подписанных токенов.

Следует ли использовать mTLS для каждого ИИ-API?

Не всегда. Стоит ли использовать mTLS для каждого ИИ-API, зависит от ваших потребностей в безопасности и того, сколько сложности может выдержать ваша установка.

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

Как выбрать между шифрованием на уровне полей и конвертным шифрованием?

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

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