Хранение классифицированных данных

Всем привет!

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

Исходник запроса

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

Введение

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

Если совсем кратко: «защита от кражи бэкапов и от доступа привилегированных пользователей». В рамках последовавшего обсуждения одними из самых сложных оказались три вопроса (хотя, казалось бы…):

1. Как хранить зашифрованные данные в базе?

2. Как по ним искать?

3. Где держать ключи?

Я планирую сначала провести вас по обсуждению, по чату, так сказать, местами дополняя, а в конце сделать некоторые выводы из этой истории. Конечно, мне пришлось кое-что добавить от себя, так как обсуждения в чатах порой рваные, порой в них скрыты некоторые предположения, поэтому статья получилась длиннее, чем само обсуждение (ссылка в конце). Изображений в статье нет, потому что я не придумал, что можно вставить, а вставлять картинки ради картинок выглядит как моветон 🙂

Приступим.

Анализ проблемы

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

• PCI DSS и номера карт

• 152-ФЗ, GDPR и персональные данные

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

PCI-DSS – это явное требование, стандарт из 12 разделов, несоблюдение которого может привести к штрафам, а в итоге право принимать платежи может быть и вовсе отозвано. И эти жесткие стандарты не в полной мере соответствуют требованиям 152-ФЗ и работе с персональными данными в принципе, для которых, например, существует требование полного удаления данных по запросу. В ходе обсуждения пришли к тому, что работа с персональными данными выходит далеко за рамки только ли шифрования.

Мы сосредоточимся на вопросах шифрования, так как именно в этом заключался изначальный запрос автора кейса.

Скрытый текст

Здесь же прозвучало еще одно интересное и не очевидное наблюдение, которое можно свести к одной фразе — «номер вашей карты в общем случае не является секретом». Если точнее, то «у большинства банков диапазоны PANов почти полностью исчерпаны, так что ткнув в любой PAN можно быть уверенным с некоторой долей вероятности, что он существует» 🙂

Номер карты – 16 цифр. Первые 6-8 цифр – BIN (банк и тип карты). Последняя цифра – контрольная сумма. Таким образом, свободных для перебора остается 7-9 цифр, что дает 10–1000 миллионов вариантов на один BIN.

Это к тому, что если захешировать PAN и разместить соль рядом с данными, злоумышленник, получив дамп, может перебрать все существующие номера за часы на обычном GPU. И это одна из причин, почему хранение хешей PAN в базе без внешнего секрета не подходит. Простые хеши карт бесполезны, так как легко перебираются. Соль для хеширования PAN должна приходить извне (из аппаратного или софтверного HSM) и никогда не лежать рядом с данными.

Шифрование и софтверный HSM

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

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

Для безопасного формирование ключа при использовании софтверного HSM можно использовать схему Ади Шамира (один из авторов RSA, S в RSA – это он), которая заключается в том, что секрет (ключ) разбивается на N частей так, что для его восстановления нужно минимум K из N частей (где K < N). Любые K-1 частей не дают никакой информации о секрете.

И здесь как раз можно наблюдать первый архитектурный компромисс между стоимостью реализации и организационной сложностью. Конкретно: мастер-ключ разбивается на 5 частей. Эти пять частей раздаются пяти ответственным лицам. Для запуска сервиса нужно 3 из 5. Ни один человек в одиночку не может скомпрометировать ключ. Фактически мы перевели часть технической проблемы в организационную и если организационное решение всех устраивает, то серьезно сэкономили на техническом решении.

Как искать то, что зашифровано?

Это порой даже более сложная задача, чем зашифровать. Пришла транзакция по карте… система же должна найти запись в базе по номеру карты. Но номер зашифрован.

Было предложено три варианта:

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

Где хранить ключи?

В Vault! HashiCorp Vault, Azure Key Vault, AWS Secrets Manager. Это то, что было на поверхности и прозвучало буквально сразу. И как оно обычно бывает, появились несоглсаные, причем по делу несокласные: «Этот подход дает иллюзию безопасности. Все хранилища ключей уязвимы перед сисадмином, что губит идею безопасности на корню».

В комнату входит модель угроз. Vault защищает от чего?

• От разработчика, который случайно закоммитил секрет в git

• От утечки env-переменных

• От неавторизованного чтения секретов

И при этом не защищает от:

• Администратора Vault (у него полный доступ ко всем секретам)

• Администратора сервера, на котором работает Vault (memory dump)

• Обладателя сертификата, используемого для mTLS между сервисом и Vault

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

В этой точке появилось очередное озарение, если так можно выразиться. Vault не может быть бесполезным, ну он же работает, его используют, просто Vault – инструмент управления секретами, а не инструмент безопасности криптографических ключей. Для первого он отлично подходит, а вот для второго нужен HSM.

Скрытый текст

Здесь можно сделать небольшую сноску от участника, который использует Azure Key Vault — «В Azure я могу создать вольт с не экспортированным ключом, который будет хранить мои данные в HSM. И есть API для криптоопераций». Azure Key Vault Premium фактически является интерфейсом к аппаратному HSM, размещенному в дата-центрах Microsoft. То есть админы не могут получить доступ к ключу.

Kubernetes

В обсуждении прозвучала идея использовать Kubernetes Secrets и vault-integration в k8s и его разобрали буквально по косточкам 🙂

Kubernetes Secrets — это объекты, хранящие конфиденциальные данные, передаваемые подам через mounted volumes или environment variables. По умолчанию Secrets хранятся в etcd в base64 (не зашифрованными). Любой, кто имеет доступ к API-серверу Kubernetes с правами чтения Secrets, может получить все секреты кластера.

Проблема контейнеров несколько глубже. Docker-контейнер — это процесс с изоляцией на уровне namespace и cgroups. Рутовый пользователь на хосте может:

• Прочитать файловую систему контейнера

• Подключиться к процессу контейнера через nsenter

• Сделать дамп памяти процесса

• Перехватить сетевой трафик контейнера

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

Скрытый текст

Справедливости ради, существуют решения для усиления изоляции: gVisor (от Google, виртуализация syscalls), Kata Containers (контейнеры внутри легковесных VM), Confidential Computing (шифрование памяти процесса аппаратно через Intel SGX / AMD SEV). Но они не обсуждались в контексте данного кейса.

А что там в облаках?

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

Модель разделяемой ответственности является основой облачной безопасности. На практике это означает, что PCI DSS-сертифицированное облако — это облако, в котором можно построить PCI DSS-совместимое решение, а не облако, которое является PCI DSS-совместимым для ваших данных.

Одна из цитат из обсуждения: «Сервис работы с PAN стоит соединить с HSM физически отдельным сетевым кабелем. Это можно сделать в ДЦ, но нельзя в облаке. А без этого проблема защиты от админа уже не решается нормально». В облаке весь трафик идет по «общей» виртуальной сети, которую, теоретически, может перехватить админ инфраструктуры провайдера.

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

Практический итог

К концу обсуждения вырисовалась архитектура, которую можно считать консенсусной (мы ведь помним, что архитектура – это принятые решения):

• Выделенный crypto-сервис, изолированный от остальной инфраструктуры, не в контейнерах, с минимумом сетевых интерфейсов

• Неизвлекаемый ключ в аппаратном HSM (идеал), в софтверном HSM (компромисс) или в облачном Vault с HSM-бэкендом (облачный компромисс)

• Формирование ключа по схеме Шамира, если нет аппаратного HSM

• Криптохеш для поиска с солью из HSM, хранящейся отдельно от данных

• Разделение PAN и ПДн из-за разных требований регуляторов

• Аудит всех обращений к crypto-сервису

• Поддержка нескольких ключей для ротации и перешифрования

Послесловие

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

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

Таким образом стратегический выбор с точки зрения архитектуры:

• Два различных архитектурных решения для персональных данных и для PAN

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

• Исходя из модели угроз и бюджета есть варианты от «дешевого crypto‑сервиса + софтверный HSM» до «аппаратный HSM + выделенная инфраструктура»

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

• Архитектор, формирующий целевую модель и баланс компромиссов

• Безопасник, задающий уровень планки через модель угроз

• DevOps/Cloud инженеры, определяющие, что реально сделать в текущей инфраструктуре

• Юристы и комплаенс, определяющие обязательный минимум исходя из требований регуляторов

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

Ссылка на сам кейс и его обсуждение: https://t.me/archicases/968/969

Если у вас есть сложности с архитектурными решениями, пишите, опубликуем и поищем решением вместе, разместить можно анонимно, можно с указанием автора – не принципиально.

Спасибо за уделенное внимание!