Хранилище HashiCorp – Суперпользователи

Вопрос или проблема

path "ssh/roles/*" {
  capabilities = ["read"]
}

path "sys/mounts*" {
  capabilities = ["read", "list"]
}

path "ssh/sign/ssh-admin-standard" {
  capabilities = ["create", "update"]
}

path "*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

➜  ~ vault login -method=ldap username="clarg"
Password (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                    Value
---                    -----
token                  
token_accessor         
token_duration         768h
token_renewable        true
token_policies         ["default" "ssh-admin-standard" "superadmin"]
identity_policies      []
policies               ["default" "ssh-admin-standard" "superadmin"]
token_meta_username    clarg

.

Ответ или решение

HashiCorp Vault — это мощный инструмент управления секретами, который предоставляет возможность централизованного хранения и контроля доступа к конфиденциальной информации. Он поддерживает интеграцию с LDAP и Active Directory, а также позволяет использовать различные секретные движки, такие как SSH. В вашем сценарии вы настроили Vault для использования с LDAP/Active Directory и SSH Secrets Engine, что позволяет пользователям получать подписанные сертификаты для доступа к серверам на базе Linux.

Теория (Theory)

Настройка политик безопасности в Vault является ключевым аспектом обеспечения правильного уровня доступа для различных пользователей и групп. Политики в Vault определяют, какие операции могут выполняться и на каких путях. Каждая политика может содержать один или несколько путей с определёнными возможностями, такими как "read", "create", "update" и т. д. Важно понимать принцип, по которому Vault обрабатывает совпадения политик: наиболее специфическое совпадение для данного пути будет иметь приоритет. При этом, политика "deny" имеет абсолютный приоритет и всегда выигрывает.

Пример (Example)

В вашем случае имеются две политики: ssh-admin-standard-policy и superadmin. Первая предназначена для доступа к стандартным серверам Linux, вторая — для суперпользовательского доступа к самим ресурсам Vault. Политика ssh-admin-standard-policy ограничивает возможности лишь чтением определённых путей и созданием/обновлением сертификатов для SSH. Политика superadmin, напротив, предоставляет полный набор возможностей на уровне всего хранилища.

Вот примерный вид этих политик:

// ssh-admin-standard-policy
path "ssh/roles/*" {
  capabilities = ["read"]
}

path "sys/mounts*" {
  capabilities = ["read", "list"]
}

path "ssh/sign/ssh-admin-standard" {
  capabilities = ["create", "update"]
}

// superadmin
path "*" {
  capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}

Когда пользователи принадлежат к обеим группам, то они наследуют политики "ssh-admin-standard" и "superadmin". Теоретически, политика "superadmin" должна предоставлять больше прав. Однако, если возникает ситуация, когда какое-то действие запрещено, это может произойти из-за специфичного ограничения на определённые пути или из-за неверного применения политик.

Применение (Application)

Теперь, как вы можете управлять доступом суперпользователей в вашей среде? Если политика ssh-admin-standard-policy излишне ограничивает права на доступ к определённым ресурсам, существует несколько путей для решения этой проблемы:

1. Разделение пользователей на группы: Убедитесь, что пользователи, которым требуется суперпользовательский доступ, не объединяются в группу с politикой ssh-admin-standard-policy. Дайте им только членство в группе Access - Vault Admin, которая предоставляет права superadmin.

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

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

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

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

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