Выбор метода хранения и передачи секретной информации и его настройки могут серьёзно сказаться на общей безопасности инфраструктуры. Наши аналитики Нина Степовик и Виктор Кузнецов рассказали об этом со сцены Positive Hack Days Fest 2, а мы выкладываем видеозапись и дополненную текстовую версию доклада.

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

Видеоверсия доклада

Что такое секреты?

Для большего понимания секретные данные (или попросту секреты) В ИБ можно разделить на следующие категории:

1. Интеллектуальная собственность: коммерческая тайна, производственная тайна.

2. Стратегические планы: стратегии развития бизнеса, маркетинговые гипотезы, планы слияний и поглощений.

3. Конфиденциальные данные: клиентские базы данных, финансовые отчёты.

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

5. Идентификационные данные: пароли, ключи доступа, токены пользователей и API-ключи. 

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

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

Основные этапы жизненного цикла секретов 

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

1. Создание: этап генерирования секретов. Важно, чтобы процесс создания был безопасным, а секреты были достаточно сложными, чтобы предотвратить их угадывание или взлом.

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

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

4. Истечение срока действия: секреты могут иметь заранее определённый срок действия, после которого они автоматически становятся недействительными. Это предотвращает неограниченное использование секретов и заставляет периодически проверять их и обновлять.

Методы хранения и передачи секретов

У секретов есть специфические методики хранения и передачи, которые имеют свои преимущества и недостатки.  

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

Плюсы: удобство доступа. 

Минусы: пользователи могут получит доступ к секретам.

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

Плюсы: 

• Понятный и простой подход; 

• Подходит для библиотек, требующих секреты в виде файлов;

• Есть возможность выбора точки монтирования. 

Минусы: 

• Требуется настройка монтирования; 

• Секреты доступны на диске даже после остановки контейнера.

В переменных окружения. Секреты можно размещать в переменных среды, которые доступны процессу приложения. 

Плюсы: 

• Это распространённый подход, не требующий интеграции с приложением; 

• Большинство облачных платформ, контейнерных оркестраторов и CI/CD-систем предлагают встроенные механизмы для установки и передачи переменных окружения; 

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

Минусы: 

• Передача файлов невозможна; 

• Смена секрета требует перезапуска контейнера;

• Доступны другим процессам в контейнере;

• Хранятся в незашифрованном виде и могут быть случайно раскрыты через логи системы, дампы памяти или в случае уязвимостей на уровне ОС;

• Переменными окружениями труднее централизованно управлять и менять их;

• Любой процесс, запускаемый из приложения, будет наследовать его переменные окружения.

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

Плюсы: 

• Полный контроль над доступом к секретам; 

• Подходит для передачи файлов и сложных данных. 

Минусы: 

• Требуется интеграция с хранилищем, причём её реализация может значительно отличаться от решения к решению; 

• Усложняет код приложения.

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

Популярные хранилища секретов и их потенциальные уязвимости

Сравним основные характеристики и функции востребованных и зарекомендовавших себя open source-систем управления секретами с точки зрения безопасности: 

• HashiCorp Vault;

• CyberArk Conjur;

• Infisical;

• Kubernetes Secrets.

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

HashiCorp Vault

Начнём со структуры всем известного HashiCorp Vault. 

Категории секретов: 

Функционально хранимые в Vault секреты можно разделить на две категории:

1. Статические — это пары ключ-значение (key-value, или kv). Например, пароли, API-ключи и т. п.

2. Динамические — это учётные данные для баз данных, облачных провайдеров (AWS, Azure и Google Cloud) и SSH-доступов. 

Особенности:

• Ограниченный доступ для сервисных сущностей Kubernetes Service Account и AWS IAM (Identity and Access Management) Role.

• Функционал Encryption As Service позволяет приложениям шифровать данные без необходимости самостоятельного управления ключами шифрования.

Теперь рассмотрим модель угроз, опубликованную и составленную компанией HashiCorp.

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

• TLS-шифрование: клиент-серверное взаимодействие защищено с помощью TLS для обеспечения конфиденциальности и целостности передаваемых данных.

• Шифрование при передаче и хранении: Vault использует так называемый «барьер безопасности» для всех запросов к бэкенду. 

• Управление доступом: включает в себя Role-Based Access Control (RBAC), использование токенов клиентов для удостоверения действий и ACL-политики, определяющие, какие действия разрешены или запрещены для конкретных токенов.

• Root ключи и многофакторная аутентификация: для разблокировки Vault требуется несколько ключей (по умолчанию 5), созданных при помощи алгоритма разделения ключа Шамира. 

• Отслеживание операций, проводимых над секретами: полноценное логирование всех поступающих запросов и ответов.

Безопасность хранения

Для шифрования данных «в покое» Vault использует алгоритм AES-256 в режиме GCM, а также алгоритм с 96-битными нонсами (nonce). Нонс генерируется случайным образом для каждого зашифрованного объекта. Чтобы обнаружить любые несанкционированные действия, в процессе расшифровки проверяется метка аутентификации GCM или GMAC. 

Vault поддерживает Encryption As Service (шифрование как сервис) дополнительный функционал встроенного движка Transit Secrets Engine, позволяющий шифровать требуемые данные, оставляя вопрос управления и генерации ключей самому Vault.  

Vault использует RBAC-подобную модель с отсутствием ролей пользователей «по умолчанию» (не считая root-пользователя). RBAC «собирается» путем программного описания таких сущностей, как «роль» и «политика». 

Политика в Vault — конфигурационный файл на языке JSON или HCL (HashiCorp Configuration Language), описывающий правила доступа к секретам в каталогах хранилища. Каждая политика может содержать нескольких правил, каждое из которых устанавливает набор прав на секреты в том или ином каталоге. Политики могут быть установлены напрямую пользователю или использованы при создании ролей. 

Роль в Vault — конфигурация, связывающая одну или несколько политик с аутентификационными методами. В контексте реализации динамических секретов для баз данных роль — набор действий, который произведёт Vault в БД при вызове роли. 

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

CyberArk Conjur

В этом решении функциональные секреты также подразделяются на статические и динамические. 

Хранимые категории секретов: 

1. Статические — пары ключ-значение (key-value, или kv). 

2. Динамические — учётные данные для баз данных и облачных провайдеров. В отличие от HashiCorp Vault в Conjur не поддерживается обращение с SSH-доступами как динамическими секретами.

Особенности:

• Управление секретами в CI/CD-инструментарии через интеграцию с автоматизационными и конфигурационными системами вроде Jenkins, Ansible и Puppet гарантирует безопасность процесса разработки и доставки кода.

• Будучи специально разработанным для использования в контейнерах, Conjur обеспечивает безопасное распределение и защиту секретов в различных публичных и частных облачных средах с учётом динамичности и краткосрочности экземпляров.

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

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

• Логирование реализовано только для событий предварительно определенных категорий.

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

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

• Перехват данных в процессе коммуникации — TLS-протокол. 

• Вмешательство в данные — шифрование AES-256 в режиме GCM.

• Доступ к данным без аутентификации или авторизации — RBAC и ACL.

• Доступ к данным без логирования — логирование событий определённых категорий.  

Безопасность хранения

Также, как в HashiCorp Vault, в Conjur и используется алгоритм AES-256 в режиме GCM для шифрования в состоянии «покоя». Однако, проверка метки безопасности (GMAC) не заявляется.

Как и в HashiCorp Vault, RBAC реализуется посредством программного описания (с помощью так называемого «синтаксиса языка политик YAML») специфических сущностей, список которых в случае Conjur ограничен только «политикой».

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

Infisical

Рассмотрим третье решение. Здесь идет речь об использовании всё того же формата хранения статических секретов: пары ключ-значение (key-value, или kv). Динамические секреты так же, как и в рассмотренных ранее примерах, поддерживают автоматизацию всех этапов жизненного цикла секрета. Infisical позволяет автоматизированным системам обрабатывать создание, распространение, отзыв и ротацию секретных данных без вмешательства человека, что снижает риск человеческой ошибки. Встроенные динамические шаблоны: PostgreSQL, MySQL, Cassandra, Oracle, AWS IAM.

Особенности: 

• Предотвращает утечку секретов в Git.

• Предлагает использование Infisical Cloud или самостоятельный хостинг на собственной инфраструктуре.

• Облегчает работу с изменением секретов, запросами на доступ и предоставлением временного доступа.

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

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

• Перехват данных в процессе коммуникации — TLS-шифрование для всех взаимодействий клиентов с API Infisical.

• Вмешательство в данные — проверки целостности данных для обнаружения вмешательства. При обнаружении несоответствий Infisical отменяет транзакции и выводит предупреждения.

• Несанкционированный доступ — строгая аутентификация и проверка прав на все входящие запросы, многофакторная аутентификация и контроль доступа на основе ролей.

• Нарушение конфиденциальности данных хранилища — AES-256-GCM.

• Действия без отчетности — Infisical регистрирует все события на уровне проекта, включая обновления политик, запросы/изменения, применяемые к секретам (отсутствует в бесплатной версии).

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

Безопасность хранения

Infisical использует AES-256-GCM для симметричного шифрования и x25519-xsalsa20-poly1305 для асимметричных операций шифрования. Асимметричные алгоритмы реализованы с использованием библиотеки TweetNaCl.js, которая была хорошо проанализирована и рекомендована к использованию фирмой Cure53. 

По умолчанию Infisical применяет подход «zero-knowledge-first» (нулевое знание) для безопасного хранения и обмена секретами.

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

Исключение для свойства нулевого знания происходит, когда участник проекта явно делится уникальным ключом проекта с Infisical.

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

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

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

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

Kubernetes Secrets

Мы решили рассмотреть Kubernetes Secrets в качестве альтернативы традиционным хранилищам секретов.

Хранимые категории секретов: 

1. Встроенные — создаются автоматически служебными учётными записями системы и ассоциируются с контейнерами вместе с учетными данными API.

2. Настраиваемые — для учётных данных, которые необходимо сделать доступными для подов.

Особенности:

• Позволяет управлять секретами централизовано в рамках Kubernetes-кластера без необходимости обращения к внешним сервисам.

• Все ресурсы и приложения, работающие в Kubernetes, могут нативно использовать Kubernetes Secrets, что упрощает развертывание и интеграцию.

• Не требует сложной настройки и может быть легко включено в процессы CI/CD.

• Применение политик безопасности на уровне кластера позволяет гибко настроить доступ к секретам и их распространение.

• Kubernetes сам по себе не обеспечивает такие механизмы, как ротация секретов и их автоматический отзыв.

• Прежде чем выбирать метод для сценария использования, следует учитывать следующие моменты:

• без дополнительной настройки секреты кодируются с использованием base-64. Этот метод текстовой кодировки защищает от случайного разглашения, но не является безопасным от злонамеренных кибератак;

• секреты доступны только в том кластере, в котором они расположены;

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

Также в Kubernetes Secrets есть различные типы секретов, которые классифицируются в зависимости от их предназначения и формата данных:

1. Opaque — универсальный тип секрета, который может содержать произвольные данные. Не предполагает наличие определённого формата и подразумевает использование лишь пар key-value.

2. kubernetes.io/service-account-token — используется для хранения токенов доступа сервисных аккаунтов, которые применяются для аутентификации в API Kubernetes.

3. kubernetes.io/dockercfg — содержит сериализованный объект ~/.dockercfg, который используется для хранения конфигурации учётных данных для Docker-реестров.

4. kubernetes.io/dockerconfigjson — содержит конфигурационный файл Docker в формате JSON, известный как ~/.docker/config.json.

5. kubernetes.io/basic-auth — для хранения учётных данных для базовой аутентификации.

6. kubernetes.io/ssh-auth — для хранения личных ключей SSH, используемых, например, для доступа к Git-репозиториям.

7. kubernetes.io/tls — для предоставления информации TLS, например, для хранения TLS-сертификата и связанного с ним закрытого ключа.

8. bootstrap.kubernetes.io/token — для загрузочных жетонов (bootstrap tokens), которые предназначены для упрощения процесса добавления новых узлов в кластер Kubernetes.

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

• Перехват данных в процессе коммуникации — TLS-шифрование для взаимодействия с API.

• Нарушение конфиденциальности данных хранилища — по умолчанию секреты в Kubernetes хранятся в etcd в незашифрованном виде. Однако, начиная с версии 1.7, Kubernetes предоставляет возможность настроить шифрование данных at-rest, используя специальные поставщики (KMS, AES-CBC и т. д.), чтобы зашифровать секретные данные в хранилище.

• Доступ к данным без аутентификации или авторизации — RBAC-политики, определяющие, к каким ресурсам и операциям есть доступ; 

• Токены сервисных аккаунтов для аутентификации приложений и сервисов внутри кластера Kubernetes для доступа к секретам; 

• Сетевые политики, определяющие, какие сервисы могут общаться с API-сервером Kubernetes для доступа к секретам. 

• Доступ к данным без логирования — Kubernetes Audit Logs позволяют отслеживать, кто и когда запросил доступ или внёс изменения в секреты.

• Access management — с помощью сервисных аккаунтов можно генерировать временные токены для доступа к секретам; секреты могут быть привязаны к конкретным пространствам имён, их использование может быть ограничено лишь нужными сервисами.

• Аудит и логирование — Kubernetes Audit Logs позволяют отслеживать, кто и когда запросил доступ или внёс изменения в секреты. Все операции с секретами могут быть залогированы для дальнейшего анализа.

Безопасность секретов в Kubernetes требует комплексного подхода и использования дополнительных настроек типа как шифрование в покое и решений для управления доступом и аутентификацией.

Безопасность хранения

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

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

Метод aescbc использует шифрование AES-CBC с PKCS#7 padding. Он имеет слабую надёжность из-за уязвимости CBC к атакам на заполнение данных. Также aescbc отличается высокой скоростью шифрования при использовании ключа в 32 байта. Ключи шифрования хранятся и доступны на управляющих узлах Kubernetes.

Метод aesgcm реализует шифрование AES-GCM со случайным nonce и должен быть обновлен каждые 200,000 операций записи. Это самая быстрая методика, предлагающая ключи длиной 16, 24 или 32 байта. Использование aesgcm рекомендуется только при наличии системы автоматического обновления ключей.

Для kms v1, устаревшего с Kubernetes v1.28, используется схема конвертного шифрования с отдельным ключом шифрования данных (DEK) для каждого ресурса. Вариант kms v2 также использует схему шифрования с «конвертом», но в данном случае использует отдельный DEK для каждого сервера API.

Применение secretbox, который использует шифрование XSalsa20 и Poly1305, надёжней и быстрее, чем другие методы. Длина ключа — 32 байта. Этот метод может быть не принят в высокозащищенных средах из-за использования относительно новых технологий шифрования. Ключи доступны из центрального контроллера Kubernetes.

Если же мы говорим об интеграции с системой управления доступом и управлением удостоверениями, то она позволяет контролировать доступ к кластеру, используя как IAM, так и RBAC.

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

Непосредственно используемый в Kubernetes метод управления доступом — это RBAC. Он позволяет администраторам кластера определять роли и правила доступа, присваиваемые отдельным пользователям или группам пользователей. Роли в RBAC определяют набор разрешений на выполнение определенных операций с ресурсами кластера.

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

IAM при интеграции с RBAC может использоваться для аутентификации пользователей, в то время как RBAC управляет тем, к каким ресурсам и с какими операциями есть доступ у аутентифицированных пользователей внутри кластера.

Интеграции

Мы также выделили интеграции, общие для трёх вышеупомянутых хранилищ:

Общими технологиями стали интеграция с Kubernetes, AWS, GitLab, PostgreSQL, GitLab, Google Cloud, Azure и Terraform. 

Кроме того, мы выделили специфичные для каждого из решений интеграции:

Kubernetes мы исключили, так как доступ к секретам осуществляется исключительно внутри него.

А теперь перейдём непосредственно к угрозам для секретов. 

Основные виды атак на хранилища секретов

В этой практической части мы опишем векторы атак, специфичные для HashiCorp Vault, CyberArk Conjur и Infisical.

Векторы атак на хранилища секретов

1. Неправильная маскировка данных

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

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

Пример: CVE-2023-33001, где плагин Jenkins HashiCorp Vault неправильно маскирует учётные данные в журнале сборки.

2. Неверная реализация криптографических операций

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

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

Пример: CVE-2023-2197, где HashiCorp Vault Enterprise уязвим для атаки с использованием оракула с дополнениями.

3. Уязвимости SQL-инъекций

Уязвимость: некорректная обработка пользовательских вводов в запросах к базам данных может привести к выполнению произвольного SQL-кода.

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

Пример: CVE-2023-0620, где HashiCorp Vault и Vault Enterprise уязвимы для атак SQL-инъекций при настройке MSSQL.

4. Отказ в обслуживании (DoS)

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

Последствия: легитимные пользователи не смогут получить доступ к секретным данным, что может привести к простою и финансовым потерям.

Пример: CVE-2023-5954, где Vault может быть подвержен DoS-атакам из-за неограниченного потребления памяти при проверке политик.

5. Небезопасное управление процессами

Уязвимость: злоумышленники могут управлять процессами агентов хранилища секретов для получения доступа к секретным данным или выполнения других вредоносных действий.

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

Пример: CVE-2022-23117 и CVE-2022-23116, где плагин Jenkins Conjur Secrets позволяет злоумышленникам управлять процессами агентов для получения или расшифровки секретов.

6. Недостаточный контроль доступа

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

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

Пример: CVE-2022-25190, где плагин Jenkins Conjur Secrets не проверяет права доступа должным образом, позволяя злоумышленникам перечислять учётные данные.

7. Неправильное управление метаданными HashiCorp Vault:

Уязвимость: была обнаружена проблема в HashiCorp Vault и Vault Enterprise до версии 1.11.3, связанная с неправильной обработкой метаданных в Хранилище. В ситуации, где у сущности есть несколько доступов к точкам монтирования с одинаковыми именами псевдонимов, Vault может некорректно перезаписывать метаданные неправильному псевдониму из-за ошибки в проверке правильности присвоенного псевдонима сущности. Это позволяет получить непреднамеренный доступ к путям ключ/значение, использующим эти метаданные в Vault.

Последствия: уязвимость может дать злоумышленникам возможность использовать метаданные для доступа к защищенным данным, что нарушает ограничения доступа.

Пример: CVE-2022-40186, где могло произойти перезаписывание метаданных к ошибочным псевдонимам, в результате чего само хранилище выдавало доступ к непредназначенным ключ/значение путям.

8. Отказ в обслуживании через точки монтирования PKI в HashiCorp Vault:

Уязвимость: в HashiCorp Vault's PKI mount issuer endpoints было обнаружено, что не происходит корректная авторизация доступа к удалению центров сертификации (CA, или удостоверяющих центров - УЦ) или изменению метаданных CA, что потенциально может привести к отказу в обслуживании PKI монтирования. Этот баг не повлиял на материалы открытых или закрытых ключей, цепочки доверия или выдачу сертификатов.

Последствия: ошибка может привести к сбоям в работе системы сертификации и вызвать недоступность критических PKI-функций для пользователей.

Пример: CVE-2023-0665, где выявленная проблема авторизации могла привести к отказу в обслуживании для точек монтирования PKI.

Векторы атак в общем виде

Рассмотренные векторы можно представить в общем виде.

1. Неправильная маскировка данных: ошибка в обработке конфиденциальной информации, приводящая к её разглашению, например, в лог-файлах.

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

3. Уязвимости SQL-инъекций: вектор, позволяющий выполнять произвольный SQL-код за счёт ненадлежащей обработки пользовательского ввода.

4. Отказ в обслуживании (DoS): атаки, целью которых является нарушение доступности ресурса путем его перегрузки.

5. Недостаточный контроль доступа: дефекты в системах контроля доступа, приводящие к неавторизованному доступу к данным.

6. Неправильное управление метаданными: ошибка в ассоциации метаданных с объектами, что может привести к неправомерному доступу или нарушению целостности данных.

7. Отказ в обслуживании через управление PKI (Public Key Infrastructure): недостатки в авторизации, сопряженные с PKI, которые могут привести к отказу в обслуживании важных инфраструктурных компонентов.

Однако, хотелось бы выделить еще один вектор - он показался нам наиболее интересным:

8. Некорректные конфигурации — злоумышленники могут получить доступ к секретным данным, к которым у них нет разрешения, из-за ошибок в конфигурации или реализации системы контроля доступа.

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

Атаки на основе некорректных конфигураций

Атаки, направленные на ошибки базового функционала и конфигурации хранилищ секретов

Просмотр незашифрованного трафика

Условия реализации:

1. Наличие параметра tls_disable = true в конфигурации при запуске волта.

2. Возможность перехвата трафика.

Шаги для реализации:

Запуск захвата трафика:

На скриншоте выше можно обратить внимание на моменты, которые могут указывать на потенциальные уязвимости или проблемы безопасности:

• HTTP-протокол: данные передаются в виде открытого текста, что может создавать риски их компрометации.

• HTTP-пути: мы видим пути '/kv/hellophd' и '/sys/vault/mounts/kv/hellophd', которые выглядят как пути к файловой системе.

• Ключи доступа: в одном из HTTP-запросов указан заголовок 'X-Vault-Token' и значение токена.

Меры по предотвращению:

Указать файл TLS-сертификата в конфигурационном файле config.hcl. tlsdisable = false (либо не указывать эту строку в конфигурации).

Этот параметр отключает использование TLS для шифрованного соединения. Его установка в значение `true` приведет к тому, что шифрование соединений использоваться не будет: это делает ваши соединения уязвимыми для перехвата или атак типа «человек посередине» (man-in-the-middle, MITM). 

Пример блока конфигурации с включённым TLS:

listener "tcp" {

 address  = "0.0.0.0:8200"

 tls_cert_file = "/etc/vault/vault.crt"

 tls_key_file  = "/etc/vault/vault.key"

}

Дамп процесса HashiCorp Vault 

Условия реализации:

1. Наличие параметра disable_mlock = false.

2. Доступ к машине с запущенным волтом.

3. Привилегии sudo.

4. Запуск волта без контейнера.

Шаги для реализации:

Просмотр pid волта и запуск утилиты gcore для снятия дампа:

Предварительно запись нового секрета с клиента:

Детекция секрета:

Меры по предотвращению:

1. Ограничение доступа к серверу.

2. Предотвращение повышения привилегий.

3. Запуск волта в докер-контейнере.

4. disable_mlock = true.

Функция mlock в системах на базе Unix используется для предотвращения записи частей памяти (страниц) на диск в свопинговое пространство. Это полезно для приложений, работающих с конфиденциальной информацией, поскольку предотвращает запись данной информации в свопинговое пространство, где она может стать доступной после выключения или перезагрузки системы. Параметр disable_mlock включает использование mlock, что может понизить риск утечки конфиденциальной информации через своп-файл. Однако включение mlock может требовать дополнительных привилегий и ресурсов, а в некоторых случаях его отключение может быть нужно для совместимости с определёнными средами или для улучшения производительности.

Атаки, направленные на системы с интегрированными хранилищами секретов

Отсутствие маскирования данных

Условия реализации:

1. Jenkins Pipeline.

2. Отсутствие установки специализированного Vault Plugin.

Шаги для реализации: 

Одно из самых популярных методов интеграции хранилища в пайплайн — обращение посредством shell-скрипта к Vault CLI.

В результате, опуская небезопасность самого метода обращения, мы получаем другую уязвимость — отсутствие экранирования полученных секретов в Console output Jenkins.

Меры по предотвращению: 

Рекомендуется использовать Vault Plugin для Jenkins. В нём поставляются как специализированные типы учётных данных для подключения к Vault, так и методы, возвращаемые значения которых нативно определяются Jenkins как требующие маскировки. На слайде можно видеть и аналогичный, но безопасный код пайплайна, и результат попытки «насильного» вывода полученного секрета в Console Output как через echo, и println:

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

Однако следует отметить: в ходе написания алгоритма для пайплайна, конечно, можно “спарсить” и замаскированные значения. Не следует забывать и про корректную настройку политики доступа в самих инструментах CI/CD, будь то Jenkins или Gitlab.

Ручная принудительная маскировка полученных значений

Условия реализации: отсутствуют. 

Шаги для реализации:

Установка Infisical-cli на сервер с раннером Jenkins.

Обращение к Infisical посредством установленного cli. 

В результате: 

Мы пришли к выводу, что использование Infisical с Jenkins не рекомендуется. 

Ошибки в конфигурации политик

Условия реализации: хранилища с механизмом описания политики управления доступом Policy As Code — Vault, Conjur.

Шаги для реализации: 

Уязвимостью являются ошибки в конфигурации политик управления доступом через код. Частными случаями хранилищ, поддерживающих такой механизм, являются Vault и Conjur. В последнем Policy As Code — нативный механизм.

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

Фрагмент с похожей ошибкой был обнаружен в конфигурации политики одного из множества реальных веб-сервисов. 

Меры по предотвращению: 

С одной стороны:

• Придерживаться принципа наименьших привилегий;

• Декларировать политики как можно подробнее.

С другой стороны, учитывая последний пример:

• Анализировать кодовое описание политик на соответствие формальному представлению модели;

Рекомендации по безопасности для всех хранилищ

Что можно посоветовать для повышения безопасности.

Запуск хранилища в докер-контейнере Unix-систем

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

В контексте использования отладчика GDB (GNU Debugger) преимущество использования контейнеров в изоляции своих процессов. Контейнеры используют пространство имен PID для изоляции процессов внутри контейнера от процессов хостовой операционной системы. 

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

Соблюдение принципа наименьших привилегий

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

Ролевой доступ и политики. Применяйте строгие политики доступа для каждой роли или пользователя, гарантируя, что каждый получает доступ только к тем секретам, которые необходимы для выполнения его задач. Используйте возможности RBAC (Role-Based Access Control) и ABAC (Attribute-Based Access Control), чтобы настроить доступ на основе ролей и атрибутов.

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

Минимальные настройки развёртывания. Настройте хранилища секретов так, чтобы они использовали только необходимые для работы функции и службы. Сделайте так, чтобы интерфейсы для доступа к секретам были доступны только уполномоченным лицам и системам.

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

Выводы

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

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