Менеджеры секретов - два разных мира

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

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

Вводная часть

Сначала еще раз: что такое аутентификация? Это подтверждения что ты – это ты, что пришедший в систему очередной Вовней – действительно Вовней. Следующим шагом является авторизация – выдача талона на совершение одного действия, например - раскатывания ПО.

Ну хорошо, а как мы можем аутентифицироваться? Самый часто используемый вариант – пара логин-пароль. Не менее часто используемый – аусвайс, то есть простите сертификат (скажем, от сайта). Аналогично, API токен - и все что связано с управлением секретами: хранение, логи «кто брал ключи от склада», откуда заходил на склад и не пора ли менять замки и пароли.

Все это детально разобрано в первой лекции от hashicorp по теме vault по ссылке

https://learn.hashicorp.com/tutorials/vault/getting-started-intro

Секреты

Какие же «секреты» у нас бывают? Очевидно, личные (у каждого свой) и групповые. Групповая – как пример, пароль от рута системы, где есть всего две учетные записи – служебная для входа по SSH и root. Больше не нужно. Сертификаты – напомню, что сертификат состоит из нескольких частей, а именно: заранее розданный или как-то еще гарантированно безопасно полученный сертификат удостоверяющего центра, свой закрытый ключ в системе, запрос на сертификат (CSR - Certificate Signing Request), и открытый ключ, который сервер раздает всем желающим. Однако, как легко заметить, для wildcard сертификатов нужен единый «контейнер закрытого ключа», или единый контейнер закрытый плюс открытый ключ. Есть секреты служебные – скажем, токены. Еще можно упомянуть одноразовые ключи - известные со времен одноразовых шифроблокнотов, которыми пользовался еще Штирлиц, сеансовые ключи и, скажем, «ключ для получения ключей» - ticket granting ticket.

Много их всяких, вот что я сказать хочу. И все шифрованные. И очень многие из них требуют где-то хранить один пароль, и раздавать его многим участникам для рутинных операций. Причем за всеми секретами нужен глаз да глаз – одни утекают, другие имеют срок жизни, третьи надо не забывать регулярно менять и (или) отключать в случае увольнения сотрудника или потере сотрудником ноутбука. Еще одни ключи наоборот, надо хранить в разных местах и среди разных людей, чтобы ключ мог быть целиком собран только от разных людей. Но при этом было бы неплохо, чтобы Самый Главный Ключ имел резервирование – но не одинаковые ключи у разных людей а у всех разные.

С групповыми ключами все тоже не так просто. Нужно как-то разделять ключи по группам – вот к этим ключам техподдержка может ходить, а к этим – внешняя поддержка сайта, но их сразу после использования надо поменять, или поставить этим секретам срок жизни в 2 дня, чтобы на третий день секреты обязательно сменились, или перестали работать. Контрольные суммы – тоже не помешает хранить, для рутинной проверки контейнеров, и своих и чужих, через Docker Notary.

Почти все эти требования по управлению паролей может и выполняет «из коробки» давно известная система – MS Active directory. Для сертификатов есть PKI / CA от них же. Отличная система, давно работает, но совершенно не пригодна для хранения групповых паролей, от того же root какой-то системы. Конечно, если у вас везде авторизация MS AD - все прекрасно, а если у вас скажем 1С, которая не умеет ходить в MS SQL, кроме как через SQL логин-пароль? И которая для нормальной работы требует запуска своей службы от имени пользователя AD, и где этот групповой – служебный пароль хранить? (В данном случае его не надо хранить, а надо менять каждый раз при необходимости. Но некоторые разработчики – любители захардкодить этот пароль для своих процедур - могут взгрустнуть)

Что еще? Ведь важно не только хранить секреты, но и иметь к ним доступ в случае внезапной утери сотрудника – хоть ДТП, хоть корова-вирус, хоть сердоболка на трамвае, хоть лично бро кукуратор. И еще неплохо иметь резервную копию этих секретов, а еще лучше, если эти секреты постоянно в работе – и в состоянии высокой доступности. И историю паролей, или хотя бы MD5 от них, тоже не помешает иметь.

Что у нас есть для хранения секретов из повседневного?

Текстовый файл, иногда даже на зашифрованной bitlocker-ом или VeraCrypt флешке.

Что интересно, причины закрытия TrueCrypt начиная с 2014 года / 7.1а – так и не выяснены, как открытй свободный аудит в 2014-2015 году не показал проблем .. до выявления CVE-2015-7358 / CVE-2015-735 уже после аудита. Насколько надежен VeraCrypt – ну, думайте, уточняйте.

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

Keepass и аналоги. Найти 10 отличий от шифрованного файла (контейнера) можно. Если захотеть.

Чего мы хотим?

Это не такой простой вопрос как кажется. Есть два не очень связанных мира: мир так скажем секретов для людей и мир секретов для роботов систем автоматизации. В первом случае нам надо управлять в большей степени удобством доступа для людей, работающих с системой. Это и удобный поиск, и гранулярный доступ (create, read, edit, delete, list) и теги, и масса других текстовых редактируемых и уникальных полей, тегов, свойств и, самое главное, связь с LDAP (читай, привязка к Microsoft AD), особенно через привязки к группам и вложенным группам – а там хоть ролевую модель (RBAC) организуйте. При этом, учитывая что системой пользуются в основном люди – не так критична высокая доступность и API, то есть High availability можно организовать средствами системы виртуализации. При работе людей задержка в работе на 1-2 минуты как-то приемлема в некоторых общих случаях (иногда нет).

Мир для систем автоматизации предъявляет немного другие требования. Нам нужно и очень широкое управление паролями и всеми видами секретов, и выписывание одноразовых или (это не синонимы) эфемерных паролей, и система к нам может приходить не только через приложение или браузер. И работать системе придется в абсолютно не доверенном окружении. Тут надо заметить, что в облаке все равно можно сдампить оперативную память виртуалки и оттуда уже достать что, что потребуется. Долго, дорого, хлопотно – но память VM может быть как разделена между двумя физическими серверами, так и записана в файл. Это штатная функция.

Более того, система хранения секретов для систем автоматизации не «проверяет» секреты, а только хранит их, и отдает – поэтому важен в первую очередь API, легкий перенос в любое облако, между ОС, и доступность средствами приложения, то есть репликация собственными силами. Что, опять же, умеет Active Directory из коробки (как и много чего еще, ну про леса и FSMO вы же знаете?).

AD умеет хранить даже текстовые поля, да и при наличии расширений схемы (а она расширяема), там можно хоть часть паролей хранить обратимо, и класть хоть войну и мир, но это же все про-при-е-тарное и просто берет и работает, так нельзя!

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

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

Особо надо выделить следующий пункт: ввиду сложной международной обстановки и наличия в инфраструктуре закрытого (напрочь, Air gap, one-way) контура, ни про какие онлайн-веб системы речь не идет. Только он-прем, только развертывания у себя. Прочие полезные вещи, типа 2FA – настоящего 2FA – TOTP (Yubico), RSA SecurID (взломан через сеть поставок - https://habr.com/en/company/itsumma/blog/558604/ ) – необходимы как опция. Иногда, в серьезных системах, используется система с числом факторов авторизации больше 2. Например, для загрузки используется зашифрованный системный диск, плюс контроль загрузки (Соболь, TPM), внутри сертификат, только с этой точки можно подключиться (с использованием 2FA и отдельного генератора одноразовых паролей) к джамп-хосту, и после этого вам позвонит СБ со словами «а вы сегодня точно вы, а чем докажете».

Что же есть на рынке за пределами «локальный файл и варианты».

AD и варианты, типа Samba, PKI и далее. Это не те дроиды, которых мы ищем.

Okta (с использованием OAuth2), Google Authenticator – это прекрасные облачные решения, про который можно и нужно говорить отдельно. У нас – он прем и закрытый контур.

Посмотрим, что описывалось и упоминалось в русском интернете.

12 лучших менеджеров паролей - https://habr.com/en/post/357192/

Статья не так плоха, за исключением того что там 2/3 облачные (как и добаляемый в комментах SafeInCloud, KeeWeb), а из тогдашних лидеров - RatticDB, Passbolt, Php password manager и домашний KeePass (KeepassX )– упомянут только последний.

В комментариях добавили Enpass, Pocket, Intel TrueKey (или он McAfee TrueKey? Лень выяснять), passwordstore, Password state от ClickStudion, Password Safe

Если немного погуглить, то выясняется, что:

https://github.com/pklink/ppma - заброшен с 2017,

https://www.clipperz.com/ - облачный,

teampass - https://teampass.net/ плюс https://github.com/nilsteampassnet/TeamPass

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

FortNotes http://fortnotes.com/ - а что там как, чего умеет ?

Кроме того, LastPass был взломан в 2015, и идет в комплекте с трекерами: Исследователь безопасности Майк Кукетц рекомендовал не использовать диспетчер паролей LastPass для Android, поскольку обнаружил в нем семь встроенных трекеров

RatticDB – см. https://habr.com/en/company/big/blog/330444/

дальше поиск вывел меня на прекрасный обзор 2020 - 2021 года: Менеджеры паролей ( Перечень "парольных менеджеров", кандидатов на использование в корпоративной среде. )

https://www.umgum.com/password-managers

Приведу выдержку: Passbolt – нет, Pleasant Password Server – нет, Psono – нет и дорого,

RatticDB - https://github.com/tildaslash/RatticWeb , к сожалению разработка и обновления закончились в 2015 году. Попытка собрать его в 2022 крайне сложэна – там и PHP5, и Python2, и масса всего – что сейчас не соберется. Существует штук 10 контейнеров с ним, у самого популярного варианта для скачивания (vikas027)– база на sqlite, у двух других – инструкция в стиле «запустите три контейнера» и «сами читайте что там как – galloplabs, groventure и далее.

Но оно хотя бы есть и даже можно что-то переделать.

Там же упомянут Passwork – типа, российская разработка и его даже можно запустить на Астра линукс. На этом его достоинства заканчиваются.

Пока писал эту статью и добавлял ссылки, нашел обзор: 46 Open-source Free Password managers for Windows, Linux, macOS, iOS, and Android - https://medevel.com/46-os-password-managers/

Надо добавить passwordcockpit, Bitwarden (включая Vault Warden, bitwarden_rs, rubywarden, bitwarden-go), syspass (https://syspass-doc.readthedocs.io/en/3.1/index.html)

При этом «как бы бесплатный но нет» Bitwarden - урезан по самое, в частности LDAP и SSO бесплатно нет

Про него писали на хабре скажем тут (как обычно, самый жир в комментах) - https://habr.com/en/company/vdsina/blog/540574/

Обзор менеджеров паролей - Most secure password managers in 2022 https://cybernews.com/best-password-managers/

Пока писал эту заметку и перебирал разнообразные ссылки, заметки и прочее, нашел и бегло просмотрел еще массу всякого –

devolutions Remote Desktop Manager - https://devolutions.net/remote-desktop-manager/features/password-management,

упоминаемый ранее по ссылкам zoho vault, и наконец сам Hashicorp Vault с дополнениями - https://www.vaultproject.io/

Обзор выбранного.

Еще раз напомню требования: бесплатно, с интеграцией с AD / LDAP, по возможности без контейнеров, с тегами и группами.

- RatticDB. Я очень, очень был к нему привязан. Грамотно настроенный – он близок к идеалу решения для вменяемой группы людей. Но его никто не поддерживает, не форкнул -

Adieu, O soldier,

You of the rude campaigning, (which we shared,)

The rapid march, the life of the camp,

The hot contention of opposing fronts, the long manoeuvre ..

Walt Whitman, Drum Taps, 1871

- syspass. Просто не собрался, ввиду зависимостей и странноватой инструкции.

Hashicorp Vault – он крут. Он активно используется, поддерживается, расширяем (например https://github.com/banzaicloud/bank-vaults) – но сделан совсем не для людей. СР! УВЧ!

Hashicorp Vault: первые шаги

Скачать vault_1.11.0_windows_amd64.zip с официального сайта без бубна нельзя, по крайней мере с русских IP. При этом написать, как делают белые люди, MD5 / SHA файла – чтобы его можно было проверить после скачивания – почему то не хотят.

На русских, не афишируемых зеркалах, дистрибутив лежит (хотя, какой он дистрибутив – готовый пакет). По приложенной инструкции на сайте - из исходников vault у меня не собрался, ошибка где-то в переменных. Разбираться было лень, возможно, какие-то мелочи, и вполне возможно у меня в ДНК.

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

Пока что из проблем всплыло:

Общая смена модели использования (парадигмы).

Это не GUI / browser human-use self-hosted password manager, совсем нет. GUI там есть, но это вся эта конструкция предназначена для обеспечения доступа одних автономных кусков инфраструктуры к другим, таким же автономным, частям. Роботам для роботов.

Поэтому там и запуск через

vault server -config=config.hcl

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

На пилотном запуске – ничего сложно, все по инструкциям с сайта.

Работа из командной строки.

Огромную массу действий из GUI сделать нельзя или очень неудобно. Банально – завести юзера (локального) и назначить ему права (точнее, прописать один, два и так далее access lists ACL, тут называемые policy). Завести пользователя можно, выдать права – я не осилил сразу, хотя в CLI это делается в одну строку (с 8 пробелами, как же без этого). Есть плюс – эта командная строка есть в User GUI в браузере.

Несоответствие официальной инструкции / документации.

И иные неочевидные глюки.

Начну с авторизации. Если ты заводишь локального пользователя четко по инструкции, с путями по умолчанию – все создается и работает. Шаг влево, например путь path1 при создании engine – все, не работает.

Ключевым отличием новой модели мышления (как без нового мышления-то?) является то, что права теперь надо прописывать вручную, точно (можно гранулярно), и в виде текстовых файлов. Этакие Cisco ACL, только по путям к объектам.

Есть огромный плюс – можно посмотреть, как оно работает на примере политики default и описанных образцов. Например, вот тут - Associating Policies / https://www.vaultproject.io/docs/concepts/policies

И тут - Write a policy / https://learn.hashicorp.com/tutorials/vault/policies

Превосходно сделанные примеры.

Жалко только, что в той части, где они описывают добавление доступа к secret через

# List, create, update, and delete key/value secrets

path "secret/*"

или path "secret/foo"

- оно не работает.

Зато работает в виде path "foo" (учитывая, что foo заведен в секретах).

Не знаю как так, но вот так.

Теперь поговорим про AD

У AD есть .. два .. режима? Когда хоть что-то про AD можно без AD авторизации, и когда без этого нельзя. Я сейчас не хочу углубляться в эту тему, но ВОЗМОЖНО (скорее всего) вам придется заводить служебного пользователя, если вы хотите прикрутить право входа в Vault к какому-то пользователю в AD. Вопрос слабо описан в документации, документация больше про связывание прав группы AD и группы Vault, и про механизм поиска вхождения пользователя в связанную группу AD.

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

$ vault auth enable ldap

https://www.vaultproject.io/docs/auth/ldap

Единственная проблема (учтите до того, как перейдете к примерам) – это перенос строк. Почему-то здесь Windows перенос строк не работает, нужно сделать файл mysuperconfug.sh на целевой системе и вписать все туда. Странноватая магия.

Дальше (после того ,как у вас заработает с 10-й попытки логин служебного пользователя в AD (через тестирование curl ))

ADDON.

curl - неудобное по для отладки LDAP. Сразу apt install ldap-utils и сразу же tcpdump.

После этого ключевых моментов 3:

1. ВНИМАТЕЛЬНО смотрите на CN в bidndn, это вовсе НЕ usernake / login. В AD атрибутах все видно.

2. В примере указано

bindpass='My$ecrt3tP4ss'(ПРОБЕЛ)\

Вот именно так и надо писать, пробел ЗНАЧИМ.

3. Смотрите через что идет проверка пользователя - dn, cn, sam. В примере все есть, и еще парочка примеров есть в интернете.

upndomain (string, optional)) – внезапно не очень нужен (depends on). Дальше ничего сложного:

vault auth delete ldap

vault auth enable ldap

vault auth list

vault login -method=ldap username=tesla

vault write auth/ldap/groups/engineers policies=foobar

Просто все из командной строки, включая тесты.

детальней все описано в ссылках:

https://shapeshed.com/hashicorp-vault-ldap/

https://xmj.github.io/articles/sysadmin/vault_and_activedirectory.html

https://www.jasonneurohr.com/articles/hashicorp-vault-ldap-authentication-and-ldap-groups/

https://www.insecurewi.re/setting-up-ad-auth-with-hashicorp-vault/