Comments 12
Хороший способ нахаляву получить логины в кучу чужих машин по ssh.
Ничего не понимаю в инфосеке, будьте добры объяснить за hashivault. Я не понимаю его ценности в плане обеспечения безопасности. Чем это лучше чем раздавать ключи пользователям? Это же дополнительный вектор атаки.
Вместо того чтобы отдать пользователю ключ для машины, вы ему отдаете токен с которым он может все ключи забрать и так. И если сценарий использования ключа вы еще можете спрогнозировать, куда пользователь засунет токен никому не известно.
Для примера, сколько людей в организации вместо curl --location 'https://vault.service/ по ошибке пульнут в http://. И ваши токены будут текстом лежать на ваших проксях и бог знает где еще.
Если вы боитесь что ключи могут "украсть" с рабочей машины, то ваш токен совершенно так же скорее всего лежит в домашней директории в виде скрипта ~/vaultssh.sh, и никто вам не намекнет тут что права у него должны быть 600.
Или дело просто в удобстве использования? Я не очень вижу удобства тут, и это все кому то надо поддерживать и не ломать слишком часто, когда есть готовые решения типа SSSD или просто нативный доступ aws/gcp/azure.
Ценность HashiCorp Vault в том, что он позволяет централизовано хранить секреты и удобно управлять доступом к ним. И соответственно позволяет минимизировать появление таких ситуаций, когда секреты лежат в plain text'е, например, в каком-нибудь гит репозитории.
В случае с OTP ключами к ssh, Vault это не единственное решение, и не факт, что самое эффективное, но в случае если вы, к примеру, уже в инфраструктуре своего проекта храните секреты в кластере HashiCorp Vault (что сейчас совсем не редкость), то при необходимости внедрения системы одноразовых паролей для ваших машин, вам будет легче использовать Vault.
По поводу кражи токенов. Токен может утечь куда-нибудь, да. Для борьбы с такими ситуациями токену можно задать время жизни и кол-во использований. И в случае, если уже понятная утечка, то инвалидировать его.
В открытом виде генерацию OTP через API Vault лучше не отдавать сотрудникам на пользование. Лучше такое прятать за внутренний корпоративный сервис, где ты уже под своей корп учёткой запрашиваешь генерацию OTP к нужной машине. Соответственно access-token к vault'у хранится у сервиса.
Лично я предполагаю, что подобный генератор OTP для ssh будет полезен для автоматизации каких-либо работ на удалённых хостах, когда worker'у нужно один раз к чему-то подключиться, выполнить свои действия и потухнуть.
point примерно в том, что ключ - сущность "долгоживущая", и rekeying\revoking в масштабах организации может быть дорогим. Нужен ли для решения этой задачи именно vault - вопрос. КМК скорее "нет" (Лишняя инфраструктурная сложность очень часто именно "лишняя") - SSSD (Опционально - с хранением открытого ключа в аттрибуте LDAP-схемы, если нужен второй фактор), GSSAPI\kerberos или SSH-сертификаты с коротким сроком жизни скорее всего будут лучшим выбором при проектировании "с нуля", но если Vault уже есть, а всего остального нет - то пуркуа бы не па?
годно
Ну, HashiCorp + OTP, это, конечно, здорово, но для крупных организаций PAM (Priviledged Access Management) система всё же желательна. И у некоторых типа CyberArk есть свои собственные сейфы (vault), но при этом ещё и сохраняется информация о том, что делал админ на сервере.
Дык хранить ключи на PAMе тем же волтом это ж хорошо.
У HashiCorp есть целый продукт для PAM - https://www.boundaryproject.io/
Стоит отметить, что они планировали сменить лицензию.
Одноразовые пароли для доступа по ssh через HashiCorp Vault