Comments 11
Во-первых перевод, на который я ссылался, он в оригинале на английском. (https://oteemo.com/hashicorp-vault-is-overhyped-and-mozilla-sops-with-kms-and-git-is-massively-underrated/)
Во-вторых сама документация SOPS'а довольно прямолинейна: https://github.com/mozilla/sops/blob/master/README.rst
Я пользуюсь обычным openssl для шифрования строк (можно и файлы целиком шифровать и отдельные куски), плюс удобство, что можно выбрать любой алгоритм, который, например дешифровать приложение может уже самостоятельно.
Удобство sops заключается в том, что там есть чуть более удобная интеграция с aws и готовые ключи для, допустим, редактирования файла ?
Если вы просто шифруете строку, то openssl удобнее. Sops даёт несколько вещей:
Поддержку списка пользователей для шифрования "для всех них".
Проверку целостности файла (что строчку файла не подменили старой без шифрования, например, или даже несвязным другим секретом).
В целом, поддержка KMS не так важна, как мне кажется (вы можете в openssl передавать секрет из kms в пару строчек), а самое важное - простая и ясная модель работы, рассчитанная на команду.
А ничего, что ключ в открытом виде в памяти нельзя хранить? По этому все установки переменных среды и особенно расшифровка файлов идут лесом? За расшифровку во временный файл вообще два раза казнить.
При использовании подобных тулзов надо очень хорошо понимать что именно вы делаете. Как именно задается мастер ключ? Через какой канал? Как защищен ввод пароля если он есть (имеется ввиде защита от кейлогеров в том числе и аппаратных)? Как долго мастер ключ хранится в памяти в открытом виде? Как оргинизвана смена мастер ключа? Что происходит при компрометации чего-либо на любом уровне? Как это обеспечено в смысле невозможности обойти процедуру смены? В конце концов какой источник энтропии был использован при генерации ключей/паролей (если пароль генерится)? Он точно был аппаратный? А что там с качеством по rfc4086?
Я к тому, что "туториалы" по таким вещам больше вреда приносят чем пользы.
Спасибо за замечания.
sops рашифровывает не в файл, а в fifo (хотя ему можно сказать "в файл" если очень надо). fifo гарантирует, что данные на диск не сохраняются в расшифрованном виде.
Насчёт "не хранить ключи в открытом виде в памяти" - а где их хранить? Вот у вас nginx читает приватный ключ от сертификата, и что он с ним делает? Складывает в регистры процессора? В /dev/null? В TMP? Вообще говоря, управление секретами вне оперативной памяти находится целиком вне зоны компетенции sops, и если вы мне покажете, где на современном линуксе, кроме оперативной памяти, можно хранить ключ к расшифровке блочного устройства, я буду очень благодарен.
Остальные вопросы, касающиеся политик ротации ключей и т.д. целиком оставляются на усмотрение пользователя и к работе самого sops'а не относятся, это утилита, а не платформа или фреймворк.
Критику качества таториала я от вас восприму более серьёзно после ответа про место нахождения приватного ключа вне оперативной памяти у nginx, dmcrypt и (например) токен докера для доступа к hub'у.
Во-первых вы не поняли. Перед подобного вида туториалами обязательно объяснять что "не знаешь зачем - не лезь". Знаешь зачем? Сначала составь модель от кого ты защищаешься и сколько ты готов потратить удобства/денег на это? Только когда ты точно знаешь как и от кого ты собираешься защищаться - можно дальше читать или не читать, когда понятно что тул в принципе не способен обеспечить требуемый уровень безопасности.
Насчет того где хранить: можно-ли хранить ключ в памяти? Да можно. Но при этом злоумышленник не должен иметь возможности ни удаленного доступа ни физического. Ну или вы можете с таким-же успехом хранить ключи в открытом виде - безопасности оно не прибавит не убавит. Где еще хранить? TPM, Smartcard, HSM. Т.е. все крипторафические операции вынесены за пределы компьютера (CPU & RAM). Повторюсь - речь идет именно о мастер ключе, компрометация которого автоматически означает компрометацию всех прошлых и настоящих секретов. Ключи уровнем ниже хранятся в соответствии с назначением (вы-же не станете доверять сертификатом выданным CA у которого ключ в памяти побывал, но при этом пароль до базы иногда можно и в памяти пошифровать).
Может я конечно слишком строго про мастер ключ... Если просто стоит задача "заткнуть рот аудиту", то и так сойдет. Но если прямо вот про хранилище уровня большой компании, то хранить мастер не в HSM это как-то...
Вы совершенно правы про то, что безопасность должна начинаться с модели угроз. Однако, я не пишу статьи по безопасности. Я пишу статью с обзором возможностей утилиты. Ровно так же инструкция по пользованию эндоскопом не заменяет медицинского образования врача. Но ровно так же наличие медицинского знания у врача не отменяет пользы от наличия "таториала" по использованию эндоскопа. Есть инструмент и есть его описание. Будет ли правильным в каждом руководстве по каждому инструменту начинать с модели угроз и CRISC.
Ваше требование хранить мастер-ключи только на аппаратных средствах сильно отличается от существующих практик в индустрии. Вы можете одеться в белые доспехи и громить еретиков, но 90% gpg-ключей, использующихся для подписи пакетов для ftpmasters в debian (а через него и в Ubuntu), хранятся в обычных keyring'ах обычных компьютеров, и имеют из средств защиты, максимум, passphrase.
Извиняюсь, что вмешиваюсь в ваш диалог.
А что за мастер ключ? Там же вроде у каждого пользователя свой ключ.
Мастер ключ, насколько я понимаю, есть у Vault, а здесь - полная децентрализация в случае использования gpg.
Этот вопрос был не очень хорошо описан, я обновил пост. В контексте sops "мастер-ключи", это то, чем расшифровывают секреты. Мастер-ключ - это то, что прислал KMS, либо приватные ключи gpg пользователей. Грубо говоря, когда sops шифрует, он берёт публичные ключи всех мастер-ключей (из .sops.yaml) и ими шифрует секрет. А при расшифровке ищет приватный мастер-ключ (хоть какой-то) и им расшифровывает.
@amarao спасибо за статью, инструмент отличный
но не очень понятно, что делать, если я хочу шифровать и главное дешифровать файлы разных окружений разными ключами?!
я написал условный конфиг
creation_rules:
path_regex: '.*\/.*develop.*.yaml'
encrypted_regex: '^(password|secret)$'
age: agekey1
path_regex: '.*\/.*master.*.yaml'
encrypted_regex: '^(password|secret)$'
age: agekey2
но sops будет брать только один ключ для дешифрования, либо в папке по умолчанию, либо указанный в SOPS_AGE_KEY_FILE
Mozilla Sops для управления секретами в гите