1. Фон выбора технологии
С усилением требований к защите персональных данных в системе применение шифрования данных стало обязательной задачей. В частности, такие персональные данные, как имена, номера телефонов и электронные письма, необходимо шифровать при хранении, и их необходимо безопасно управлять в рабочей среде. Изначально рассматривался вариант применения только функции шифрования базы данных, но по следующим причинам была рассмотрена структура, в которой приложение выполняет шифрование и расшифровку данных самостоятельно.
Да.Если шифрование выполняется только на уровне базы данных, пользователи, получившие доступ к данным извне приложения, могут получить права доступа к даннымВозможность просмотра открытых данныхЭто существует
Я. Руководство по безопасности для клиентовРекомендуется обрабатывать шифрование и расшифровку на уровне приложений, а не внутри базы данных
В целевой системе использовался MongoDB Atlas, и есть возможность использовать функционал CSFLE (Client Side Field Level Encryption), который официально предоставляется MongoDB.
Кстати, CSFLE — это функция, которая позволяет шифровать данные на уровне клиента с помощью библиотеки перед их сохранением в базе данных и автоматически расшифровывать их при запросе.
Особенно в некоторых полях можно применять шифрование выборочно, как это делается в операционной среде с использованием RDB, шифруя только те колонки, которые необходимы, так и в MongoDB применяется аналогичный подход. Если зашифровать все данные, это может значительно снизить эффективность поиска и эксплуатации, но CSFLE позволяет шифровать только необходимые поля, что позволяет оптимизировать процесс.
Методы управления ключами шифрования также были важным аспектом безопасности.
Существуют риски безопасности, если ключи шифрования хранятся в конфигурационных файлах приложения, поэтому было решено рассмотреть возможность использования отдельного KMS (Службы управления ключами).
Поскольку данная система работала в среде AWS, было принято решение использовать AWS KMS. AWS KMS предоставляет функции создания ключей, контроля доступа и автоматического обновления, что обеспечивает высокую степень безопасности управления.
Дополнительно была рассмотрена функция Queryable Encryption, предлагаемая MongoDB. Queryable Encryption имела преимущества в предоставлении некоторых функций поиска для зашифрованных данных, но возникала проблема с созданием дополнительных коллекций для поиска по зашифрованным данным и усложнением структуры управления.
В частности, в операционной среде ожидалось увеличение числа коллекций БД и усложнение управления, и в реальном проекте более важными факторами стали удобство работы и эффективность обслуживания.
В результате в этом проекте Комбинация CSFLE + AWS KMSВыбор был сделан.
2. Процесс применения в локальной среде
Применение CSFLE сначала было проверено в локальной среде разработки.
MongoDB предоставляла пример проекта CSFLE для Java, на основе которого мы сначала проверили основные функции.
В образце кода также была предоставлена функциональность мастер-ключа (CMK) для локальной среды, что сделало его подходящим для начального тестирования. На начальном этапе были в первую очередь проверены следующие пункты:
- Шифрование определенных полей
- Автоматическое шифрование при сохранении
- Автоматическое расшифрование при просмотре
- Способ указания полей для шифрования
- Способ генерации ключа данных (DEK)
- Способ подключения мастер-ключа (CMK)
CSFLE автоматически выполняет шифрование при сохранении данных через клиента с настроенным шифрованием. Разработчикам не нужно писать отдельную логику шифрования и дешифрования, что повышает удобство разработки.
Например, после применения настроек шифрования к полю имени (name) и сохранения данных фактические шифрованные данные в бинарном виде сохраняются внутри MongoDB. В свою очередь, при запросе данных через тот же клиент автоматически выполняется расшифровка, и приложение может использовать данные в открытом виде.
На начальном этапе тестирования мы также рассмотрели структуру Entity и способ определения схемы шифрования. В MongoDB CSFLE можно указать шифруемое поле на основе JSON Schema, при этом для определенного поля можно выбрать детерминированный или случайный режим шифрования.
Детерминированное шифрование имеет преимущество в том, что одинаковые входные значения всегда сохраняются в виде одинаковых шифров, что позволяет проводить поиск по равенству, в то время как случайное шифрование имеет высокую безопасность, но затрудняет сравнение одинаковых значений.
В проекте учитываются требования к защите персональных данных и требования к поиску Некоторые поля, требующие поиска, подлежат применению детерминированного шифрованияи, Остальные поля зашифрованы случайным образомбыли спроектированы с применением этого метода.
В процессе тестирования локальной среды удалось надежно проверить основные функции шифрования и дешифрования, а также поток хранения данных.
3. Применение облачной среды и AWS KMS
После завершения проверки локальной среды было проведено фактическое применение в облачной среде на основе MongoDB Atlas.
В облачной среде AWS KMS используется так же, как и в рабочей среде.Настроил для использования KMS в разработкеДля применения AWS KMS необходимо настроить права IAM, создать KMS Key, конфигурировать политики доступа и т.д.
Особенно важно правильно настроить IAM Role, чтобы сервер приложения мог получить доступ к KMS. Неправильная настройка прав может привести к сбоям в работе приложения из-за неудачного запроса шифровального ключа.
В локальной среде использовался локальный мастер-ключ (CMK), поэтому в процессе перехода в рабочую среду потребовалась операция преобразования ключей.
В этом процессе была использована функция Rewrap, предлагаемых библиотекой MongoDB CSFLE. Rewrap - это функция, которая позволяет повторно зашифровать существующий ключ данных (DEK) с помощью нового ключа мастер (CMK). То есть, на самом деле не происходит повторной шифровки самих данных, а только изменяется верхний ключ мастер, который защищает ключи шифрования данных (DEK).
В проекте используется DEK на основе локального ключа мастер Перемотка с использованием мастер-ключа на основе AWS KMSМы выполнили переход в рабочую среду способом, который включает в себя следующий процесс. Во время процесса Rewrap мы особенно обращали внимание на следующие моменты.
- Корректность расшифровки существующих данных
- Статус шифрования новых сохраненных данных
- Нормальное состояние доступа к AWS KMS
- Возможность повторного использования существующего DEK
- Возможность отката при возникновении сбоя
К счастью, после Rewrap старые данные по-прежнему были доступны, и новые данные также подтвердили стабильное шифрование на основе AWS KMS.
В рабочей среде в соответствии с политикой безопасности Политика автоматического обновления ключей KMSТакже применено. AWS KMS поддерживает автоматическую ротацию (Rotation) через определенные промежутки времени, что также является большим преимуществом с точки зрения эффективности управления ключами. Этот период установлен на 1 год.Сделано.
4. Основные проблемы, выявленные в ходе эксплуатации
Применяя CSFLE в реальной рабочей среде, мы смогли столкнуться с различными пробелами и проблемами в эксплуатации. Первое это Способ распространения библиотеки CSFLEЭто вопрос.
Библиотека CSFLE для MongoDB Enterprise предоставляется в виде бинарных файлов для каждой операционной системы, отдельно от клиента доступа к базе данных, и размер файлов довольно большой. В среде Linux он составлял десятки мегабайт, а в среде Windows - сотни мегабайт.
На начальном этапе рассматривался вариант включения в репозиторий Git, но это признали нецелесообразным из-за проблем с эффективностью управления бинарными файлами и увеличения размера репозитория. В результате было рекомендовано распространять через Nexus Repository или включать в Docker-изображение, и этот проект использует это решение.включён в Docker-изображениеЯ следовал заданному направлению.
Второй это Совместимость версий Spring BootЭто проблема.
Библиотека CSFLE немного отличалась в зависимости от версии MongoDB Enterprise, и даже при одинаковой мажорной версии могут возникнуть проблемы совместимости со Spring Boot.
В частности, в более низких версиях Spring Boot наблюдались случаи конфликтов драйвера MongoDB или ошибок инициализации Bean. Поскольку нет отдельного руководства, необходимо соответствовать используемой версии Spring Boot.Проверены версии библиотеки CSFLE, выпущенные в аналогичный периодСделано.
В результате было установлено, что важно избегать использования низкой версии Spring Boot и использовать версии, которые были достаточно проверены на совместимость с MongoDB Driver и библиотекой CSFLE.
Третье это Обновление мастер-ключа KMS (CMK)Это проблема.
AWS KMS по умолчанию предоставляет функцию автоматического вращения ключейСделано.
Однако, поскольку существующий ключ также может сохраняться в течение определенного времени, существующий DEK не вызывает немедленных проблем. Тем не менее, с точки зрения безопасности рекомендуется повторно обернуть DEK на основе обновленного CMK.
В проекте фактически Тест на повторную обертку с локального мастер-ключа на мастер-ключ AWS KMSМы выполнили это и смогли подтвердить нормальную работу.
Таким образом, мы получили уверенность в том, что в будущем сможем надежно реагировать на замену ключей и изменения политики безопасности.
5. Миграция данных и поддержка поиска по шаблону LIKE
В процессе миграции данных также возникли неожиданные проблемы.
В локальной среде нормально работал запрос открытых данных через клиент шифрования и дешифрования, однако в среде MongoDB Atlas при запросе некоторых открытых данных произошла ошибка.
В конечном итоге в облачной среде, где развернута продукция, Структура мульти-источников данныхбыла сформирована. Один из них Запрос открытых данныхобычный клиент MongoDB для этого, а другой - Клиент для шифрования и расшифровки с применением CSFLE.
В процессе миграции мы сначала просматривали существующие открытые данные с помощью обычного клиента, а затем сохраняли их с помощью клиента для шифрования и расшифровки.
Поскольку CSFLE автоматически выполнял шифрование на этом этапе, не было необходимости писать отдельную логику шифрования вручную.
Еще одна важная проблема заключается в Проблема поиска LIKEбыло.
Закодированные данные содержали персональные данные, такие как имя, и в функционале поиска пользователей существовали требования к частичному поиску.
Для справки, в финансовых системах используется поисковая система на основе хеширования по ключевым словамЧасто используют. Например, имя разделяется на 초성 или некоторые строковые единицы, после чего сохраняется в виде хэш-значения, и при поиске применяется тот же метод хэширования для получения результата.
Проблема заключалась в английских именах. Поскольку количество вариантов частичного поиска английских имен было значительно больше, для удобного поиска было необходимо создать как минимум 16 ключевых слов.
К счастью, MongoDB предоставляет функции поиска на основе массивовпоскольку я это делал добавить поле массива хэш-ключевых словМы смогли решить это способом. То есть, само поле имени было зашифровано, но массив хешей ключевых слов для поиска хранится отдельно, чтобы поддерживать функцию частичного поиска.
если Реляционная база данных (RDB)использовалась отдельно Хеш-таблица для ссылок на ключевые словавероятно, потребовался бы способ их размещения.
В ходе этого проекта мы еще раз подтвердили, что шифрование данных требует комплексного проектирования, включающего не только шифрование при хранении, но и поиск, эксплуатацию, миграцию и управление ключами.
Daniel(K)