HashiCorp Vault перехвален, а Mozilla SOPS вместе с KMS и Git неоправданно недооценены

Когда я начал работу с Kubernetes, и Infrastructure as Code (IaC), я быстро понял, что мне нужно решение для работы с секретами. Когда я поискал в интернете, то не увидел единого мнения по поводу практического подхода к проблеме, подходящего ко всем ситуациям. Поэтому, в этом году, я поставил себе задачу изучить, какие решения для управления секретами приложения и инфраструктуры существуют, решить, которое из них я считаю лучшим и освоить его. В конце исследования, я пришел к выводу, что HashiCorp Vault перехвален, а Mozilla SOPS с KMS и Git неоправданно недооценены.

Я считаю, что SOPS недооценен по двум главным причинам.

1. Большинство людей не имеет базы знаний достаточной, чтобы понимать, что и как делает Cloud KMS.
2. Те же самые люди не осознают, что хотя в прошлом не было безопасного способа хранить зашифрованные секреты в Git, криптография сильно развилась с тех пор, и теперь надежное хранение секретов в Git стало возможно. За это спасибо Cloud Provider KMS Solutions, таким как AWS KMS, Azure KeyVault, или GCP KMS.

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

Требования к идеальному решению по управлению секретами

1. Универсальность (может работать и в облаке, и локально).
2. Легкое взаимодействие с любыми технологическими стэками через REST API или платформы включающие CLI binaries (бонусом будет беспрепятственная интеграция с Terraform, Ansible, Kubernetes, и CI/CD Pipelines).
3. Необходимость соответствовать требованиям завтрашнего дня.
   
   1. Открытый исходный код/Бесплатно (нет риска исчезновения сервиса, или скачков цены).
   2. Большое сообщество или длинная история поддержки разработчиками (у меня нет желания пользоваться заброшенными проектами, кроме нестареющего/завершенного ПО, как Unix Utilities).
   3. Легко масштабируется и предлагает высокую доступность.
4. По-настоящему безопасно (я должен иметь возможность убедить главу любой службы безопасности, что это достаточно надежно, чтобы пройти проверку безопасности).
   
   1. Шифрование хранящихся данных.
   2. Шифрование передаваемых данных.
   3. Доступ к данным должен быть отзываемым.
   4. Уязвимости должны быть известны, а контрмеры применены.
5. Поддержка Granular ACLs + опции самообслуживания при создании секретов разработчику.
   
   1. Разработчик должен иметь возможность управлять своими секретами, но не продакшна.
   2. Глава проекта может управлять секретами и разработчика, и продакшна.
   3. Изоляция на уровне проекта: Глава проекта «А» не должен видеть секреты продакшна проекта «Б».
6. История версий секретов (может поддерживать стадии и автоматизацию, развертывание, откат к предыдущей версии, технические сценарии, в которых секреты и настройки интегрируются в файле настроек и строках подключения к базе данных).

Note: Mozilla SOPS также соответствует моим требованиям, но тогда это не было очевидно, потому что изначально я полагал, что нет безопасного способа хранить зашифрованные секреты в git.

Проблемы безопасности с хранением секретов в репозитории git

• Множество инструментов хранят ключи дешифровки в корневом каталоге пользователя или связке ключей, таким образом данные и ключ от них лежат на одной и той же машине.
• В таком случае раскрытие ключей дешифровки это статистическая неизбежность (уязвимости накапливаются с каждым копированием репозитория в геометрической прогрессии).
• Невозможно аннулировать уже утекший в сеть ключ дешифровки. Если вы беспокоитесь, что ваши ключи будут раскрыты, но шанс этого невелик, аннулировать ключи невозможно из-за распределенной истории git. Даже если вы сможете очистить историю git сервера и заново зашифровать все секреты с новыми ключами шифрования, все равно будет копия репозитория в истории, которую можно дешифровать со старым ключом.
• При подозрении на утечку ключей, единственная контрмера это полное изменение всех учетных данных. Это дорогостоящая операция и руководство обычно не позволяет делать так без соответствующих доказательств утечки.
• Некоторые из инструментов шифровки git сами себя раскрывают: запускают команду расшифровки секрета и забывают зашифровать обратно перед загрузкой в репозиторий.

Я заметил, что решения по управлению секретами можно отнести к одной из четырех категорий:

1. Специфичные для облачных провайдеров (я сразу отметаю такие по причинам 1 и 3).
2. Специфичные для одного технологического стека (Ansible, Chef, Puppet, Salt, Jenkins) (отметаю по причинам 2 и 5).
3. Репозиторий Git, зашифрованный целиком (отметаю по причинам 4 и 5).
4. Свой собственный сервис управления секретами (Есть несколько потенциально возможных вариантов, но каждый со своими сложностями, поэтому я решил сосредоточиться на одном. Vault от Hashicorp – абсолютный победитель с учетом количества его возможностей, документации, большого сообщества и истории долгой тех.поддержки и разработки).

Когда анализ был завершен, я потратил месяц свободного времени на работу с Vault Server по хранению статичных секретов, чтобы лучше освоиться с Vault. Хотел, чтобы все получилось безопасным, легким в обслуживании и простым в использовании. Я сделал все что мог: включил в проект TLS, добавил Vault Configuration, роли, политики, и Kubernetes IaC для высокодоступного кластера Vault/Consul в репозитории git, использовал Auto Unseal KMS, написал хорошую документацию, подключил хранилище ключей по версиям, аутентификацию LDAP, веб-интерфейс, и сторонний интерфейс для ПК — Cryptr от Adobe.

Пока изучал Vault, я заметил несколько его недостатков:

1. Vault все еще требует место для хранения секретов (Где Vault хранит свою инфраструктуру? HTTPS сертификаты и IAM пароль для Auto Unseal KMS).
2. Vault очень дорогой и тому есть несколько причин (Вам необходимо заплатить за инфраструктуру и хранение. Это не настолько просто, чтобы вы за час смогли настроить его с нуля, написать readme и обучить несколько людей, как пользоваться ресурсом. Вам может помочь использование Infrastructure as Code и готовый readme в репозитории git, но даже так все еще много чему необходимо научиться. Операторам потребуется потратить время на поддержку резервных копий, улучшения и мониторинг. Разработчикам — потратить время на написание пользовательских скриптов для аутентификации и получения желаемых данных).
3. Vault делает жизнь тяжелее для людей, которым необходимо хранить секреты, и те предпочитают избежать использования этой технологии, что, в свою очередь, вредит целям, которые преследует идея централизованного репозитория секретов (Разработчикам необходимо изучить некоторое количество новых команд для взаимодействия с Vault, или полагаться на медленный GUI от самого Vault. Большинство существующих инструментов разработаны для взаимодействия с файлами в файловой системе. Из-за этого использование инструментов вроде vimdiff будет требовать дополнительных шагов: входа в систему, получения секрета, конвертирования его в файл и удаления после завершения).
4. Стандартная реализация имеет уязвимости безопасности, и устранение их стоит дорого (Если кто-либо получит root права к серверу Vault, они могут получить мастер-ключ для дешифровки, сделав дамп данных. Располагать Vault в Kubernetes или Cloud VMs значит дать больше возможностей украсть root права. Чтобы значительно уменьшить риск доступа к root правам, вам необходимо обеспечить каждую машину Intel Software Guard Extensions и запускать сервер Vault в SCONE Security Enclaves (контейнеры, работающие в зашифрованной оперативной памяти). Добавление всего этого увеличит стоимость проекта за счет увеличения стоимости инфраструктуры. Twistlock, Aqua, или SysDig – альтернативные пути для частичного уменьшения рисков).

Учитывая эти недостатки, я решил копнуть глубже и дальнейшие исследования привели к Soluto’s Kamus. В нем два интересных концепта: GitOps и шифрование секретов нулевого доверия. Я запрыгнул в кроличью нору шифрования и в конце данного путешествия у меня в мыслях получилась следующая схема:

Эволюция Криптографии вкратце

1. Симметричные ключи шифрования:
   
   • Длинный пароль используемый и для шифрования, и для расшифровки.
2. Асимметричное шифрование с парой ключей — публичным и приватным:
   
   • Публичный ключ шифрует данные, а приватный дешифрует
3. HSM (Модули аппаратной безопасности)
   
   • Сделайте так, чтобы приватный ключ не смогли украсть.
   • HSM — дорогой.
   • HSM — неудобен ни для пользователя, ни для автоматизации.
4. Облачный KMS (сервис управления ключами):
   
   • KMS это доверенный сервис. Он шифрует и дешифрует данные от имени клиента, что позволяет пользователю или компьютеру, по сути, выполнять процесс шифровки-дешифровки используя данные личности, а не ключи (Клиент аутентифицируется с помощью KMS, который проверяет их личность через ACL. Если проверка успешна, клиент может посылать зашифрованные данные в запросе KMS. Информация далее дешифруется от имени клиента и посылается в открытом виде назад, к пользователю, через защищенный TLS канал).
   • KMS – дешевый.
   • KMS доступен через REST API, т.е. удобен и для пользователей, и для автоматизации.
   • KMS крайне безопасен. Он дает возможность десятилетиями избегать утечек ключей.
     
     • Изобретение принципа шифрования KMS ввело три убойные возможности:
       
       1. При реагировании на известное нарушение:
          Без KMS: ключи шифрования утекают к злоумышленникам, и вы не можете аннулировать их. Это означает, что вам нужно изменить несколько ключей, заново зашифровать все данные с новыми ключами и постараться как только можете, чтобы удалить старые зашифрованные данные. Пока занимаетесь этим, вам необходимо "сражаться" с начальством за время простоя для нескольких продакшн систем и минимизировать это время. Даже если вы сделаете все правильно, может так случиться, что не будет возможности полностью удалить старые данные, как в случае с историей git и резервными копиями.
          Вместе с KMS: учетные данные личности утекают к злоумышленникам. Однако эти данные могут быть отозваны, и в таком виде становятся для вора бесполезными. Исчезает кошмар с повторной шифровкой данных и удалением всей старой информации. Вам все еще необходимо изменять секреты (учетные идентификационные данные vs ключи шифрования), однако этот процесс становится достаточно дешевым для автоматизации и профилактики.
       2. Менеджмент шифрованных данных превращается из невыполнимой – в тривиальную задачу управления централизованным ACL. Становится возможным с легкостью отзывать, изменять, подтверждать доступ к данным. Как бонус: с тех пор, как Cloud KMS, IAM, и SSO Identity Federations стали взаимодействовать, вы можете использовать уже существующие идентификаторы пользователей.
       3. Становится возможным использование методов Crypto Anchoring:
     • Сеть ACL может быть применена к KMS, чтобы разрешить расшифровывать данные только в вашем окружении.
     • Скорость дешифровки KMS можно отслеживать на базовом уровне, и при возникновении аномалий могут быть активированы предупреждения и ограничение скорости.
   • Ключи шифрования KMS могут быть защищены с помощью HSM.
   • Шанс утечки ключей шифрования стремится к нулю, так как клиенты не взаимодействуют с ключами напрямую.
   • Облачные провайдеры могут себе позволить нанять профессионалов в области безопасности и осуществлять дорогостоящие процессы, чтобы сохранять безопасность backend. Таким образом возможность утечки со стороны ключей серверной части тоже близка к нулю.

Изучение продвинутых технологий шифрования дало мне понять, что KMS мог быть использовать для предотвращения утечек ключей. Это, плюс возможность отозвать права дешифровки без необходимости каких-либо изменений в зашифрованных файлах, делает реальностью по-настоящему безопасное хранение секретов в Git. Я пересмотрел несколько ранее отвергнутых решений на основе Git. Удивительно, но Mozilla SOPS полностью соответствует моим критериям идеального решения по управлению секретами. Оно так же хорошо взаимодействует с инструментами CICD pipeline: SOPS Terraform Provider, Helm Secrets – лишь оболочка для SOPS и вы всегда можете откатить до:

Bash# sops --decrypt mysecret.yaml | kubectl apply -f -

(где kubectl может быть любой утилитой CLI, принимающей стандартный ввод)

SOPS не имеет недостатков других решений, основанных на базе Git:

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

SOPS не имеет недостатков Vault:

Ему не нужна инфраструктура, поэтому SOPS дешевый, как и KMS. Вы можете легко его настроить, обучить пару людей и написать readme меньше чем за час. Вот пример, как легко он настраивается и используется:

Bash# aws kms create-key --description "Mozilla SOPS” | grep Arn
"Arn": "arn:aws:kms:us-east-1:020522090443:key/4882a19d-5a98-40ae-a1ad-a60423afbddb",
Bash# cd $repo
Bash# vim .sops.yaml

(Создайте файл с именем .sops.yaml со следующими двумя строками)

creation_rules:
- kms: 'arn:aws:kms:us-east-1:020522090443:key/4882a19d-5a98-40ae-a1ad-a60423afbddb'
Bash# sops mysecret.yaml

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

Bash# cat mysecret.yaml

Это покажет вам зашифрованный yaml

Bash# sops --decrypt mysecret.yaml

Покажет расшифрованный yaml

SOPS использует данные для входа от AWS, которые хранятся в ~/.aws, для авторизации через KMS, поэтому вы можете производить процесс шифровки/дешифровки без пароля. Также SOPS рекурсивно ищет файл .sops.yaml, в котором содержатся метаданные о том, как необходимо шифровать и расшифровывать данные. Все это приводит к двум важным выводам: во-первых, пользователю не нужно учить тонну команд или флагов. Во-вторых, дополнительный файл .sops.yaml может быть добавлен в подкаталог, представляющий производственное окружение или другой проект, так, чтобы .sops.yaml мог содержать другой, отличающийся ключ шифрования.

Вы можете предоставить разным пользователям Cloud IAM разные права на каждый ключ KMS, чтобы обеспечить детальный контроль доступа. Если вы беспокоитесь об удалении вашего ключа AWS KMS посторонним, то есть возможность настроить SOPS так, что данные будут шифроваться AWS, GCP, или Azure KMS решениями. Так можно будет хранить вторичную резервную копию KMS с ограниченным доступом.

SOPS поддерживает шаблоны рабочих процессов, что делает жизнь проще. Разработчики могут хранить свои секреты зашифрованными прямо под рукой, и синхронизировать их под версию проекта актуальную для этих секретов. Управление секретами сразу получает все преимущества git: легко проверяемый менеджер изменений, рецензирование через запрос загрузки. Различия в редактировании так же значимы: только измененные значения будут обновлены, тогда как раньше приходилось заново шифровать весь файл. Этот вариант также снижает вероятность конфликтов слияния. Согласованность и стандартизация всегда делают автоматизацию и разработку CI/CD Pipeline проще, что делает инженеров почти счастливыми. SOPS предоставляет последовательное расположение кода, настроек и секретов, а это упрощает выполнение рабочих процессов GitOps.

При использовании Hashicorp Vault могут возникнуть проблемы с работой централизованного репозитория секретов, потому что пользователи находят его сложным в использовании, devops-инженеры — тяжелым в обслуживании, а руководство – дорогостоящим. SOPS, с другой стороны, прост в использовании, легко изучаем, дешев в поддержке и поддерживает шаблоны рабочих процессов, что делает жизнь проще! Все это вместе означает – если есть кому предложить эту технологию в вашей организации, серьезных препятствий к принятию не будет, зато скорее всего увеличится общий уровень безопасности. Вот почему SOPS с KMS и Git неоправданно недооценены.

Хотелось бы уточнить – цель этой статьи не в том, чтобы сказать, что Vault плохой и вы должны использовать SOPS и KMS. Я написал эту статью по трем причинам. Первая – просто люблю учить. Вторая – мое желание указать на некоторые недостатки Vault. Третья – KMS вместе с SOPS это прекрасное сочетание, неоправданно недооцененное. Кажется никто и не знает о нем. Я ни разу не сталкивался с нормальным объяснением ни того, ни другого, пока искал информацию к статье. И наконец, согласно Google Trends, существует не так уж много сравнений SOPS и Vault.

Я бы хотел закончить статью, сказав, что искренне рекомендую каждому изучить SOPS, KMS и Vault. Зачем изучать Vault, если он сложнее, а SOPS вместе с KMS делают то же самое? Всего две причины, правда. Первая — Vault один из лучших, когда речь заходит о PKI и смене секретов, что необходимо для правительственных и банковских стандартов соответствия безопасности. Вторая причина – Vault становится проще с каждым годом. Сообщество приняло его как безусловного победителя и добавляет поддержку Vault во многие продукты: Jenkins, cert-manager, и Kubernetes.

Последний, в частности, прекрасно работает с Vault. Значительная часть неприятных моментов была удалена или автоматизирована так, чтобы эти сервисы легко работали друг с другом.

Разработчики Vault показали, что стремятся сделать свой продукт проще в использовании. Они улучшили документацию, предложили Infrastructure as Code (IaC) и реагировали на нужды сообщества. После того, как сообщество создало решения для Auto Unseal, решения для миграции внутреннего хранилища и сторонние веб-интерфейсы, разработчики Vault решили встроить эти функции в Open Source версию. Учитывая все это, я не удивлюсь, если в будущем Vault’s Transit Secrets Engine (аналог KMS от Vault) будет легко взаимодействовать с Mozilla SOPS.

---

Переводчик: DanayDemenir
Редактор: DariaRogoz