Архитектура OpenBao
OpenBao — это система управления доступами и шифрованием. Она обеспечивает возможности для хранения, генерации, шифрования, отзыва и аудита конфиденциальных данных (например, API-ключей, сертификатов, паролей), а также предоставляет средства аудита и управления политиками доступа. OpenBao также способен динамически генерировать доступы, устанавливать срок действия доступов, их продление, выполнять их отзыв и шифровать данные по запросу.
В этой статье описывается внутренняя архитектура OpenBao, его основные компоненты, процессы и то, как он обеспечивает управление доступами.
Основные возможности
OpenBao предоставляет следующие функции для управления доступами:
-
Централизованное управление доступами. OpenBao выступает как единая и безопасная система учета доступов, таких как API-ключи, сертификаты, пароли и токены.
-
Динамические учетные данные. OpenBao может генерировать учетные данные по запросу. Например, он может выдавать временный доступ к базе данных с определенным сроком действия.
-
Срок действия и автоматический отзыв. Все учетные данные пользователей и токены в OpenBao имеют срок действия. Когда срок действия истекает, доступ автоматически отзывается. Клиенты могут продлить срок действия, если это разрешено политикой, но после достижения максимального времени жизни доступы становятся недействительными. Этот механизм обеспечивает ротацию учетных данных и снижает риски.
-
Шифрование как сервис. OpenBao предоставляет интерфейс для выполнения криптографических операций, таких как шифрование, расшифровка и вывод ключей, без раскрытия самих ключей. Приложения могут использовать криптографические функции OpenBao вместо того, чтобы управлять ключами напрямую.
-
Тонкая настройка контроля доступа. Доступ к учетным данным и операциям контролируется политиками. Политики основаны на путях и следуют модели "запрещено по умолчанию", что гарантирует выполнение только явно разрешенных действий.
-
Аудит и логирование. Каждый запрос и ответ, проходящий через OpenBao, может быть зафиксирован устройствами аудита. Логи содержат подробные метаданные о клиенте, запрашиваемых путях и операциях.
Общая схема работы
Жизненный цикл запроса в OpenBao включает следующие этапы:
-
Аутентификация
Клиент отправляет учетные данные или использует метод аутентификации (например, имя пользователя/пароль, токен, GitHub, LDAP или открытый/приватный ключ). OpenBao идентифицирует клиента.
-
Валидация
Опциональная внешняя проверка с использованием доверенных источников или провайдеров идентификации. Например, GitHub, LDAP, AppRole.
-
Авторизация
Применение правил политики (ACL), которые определяют, какие пути или операции разрешены клиенту.
-
Доступ
После авторизации клиент может запрашивать доступы, генерировать их динамически, выполнять операции шифрования/расшифровки и другое. Доступы могут иметь срок действия, после истечения которого они отзываются.
Компоненты
-
Barrier
Barrier — это криптографический слой шифрования, защищающий все учетные данные. Каждое значение шифруется перед сохранением в базу учетных данных (Storage Backend).
-
Storage Backend
Storage Backend — это физический уровень хранения, например файловая система или облачное хранилище. В нем хранятся доступы, токены, политики, сроки действия и логи аудита. Данные хранятся в зашифрованном виде и не могут быть доступны напрямую из базы.
-
Server
OpenBao server — это центральный демон, который координирует все операции. Он обрабатывает клиентские запросы, применяет аутентификацию и авторизацию, взаимодействует с Barrier для шифрования и расшифровки, управляет жизненным циклом учетных данных и маршрутизирует запросы к нужному Secrets Engine или устройству аудита.
-
Token Store
Token Store — это внутренний компонент, управляющий токенами, которые выдаются клиентам после успешной аутентификации. Токены содержат информацию о клиенте, записи о достуных политиках и могут иметь срок жизни. Token Store гарантирует проверку и отзыв токенов.
-
Policy Store
Policy Store хранит политики контроля доступа. Политики записываются в формате ACL и привязываются к путям. Они точно определяют, какие операции может выполнять клиент. Server применяет эти правила во время авторизации.
-
Secrets Engine
Secrets Engine — это подключаемые модули, размещаемые по путям внутри OpenBao. Они могут генерировать доступы динамически (например, учетные данные для баз данных), предоставлять криптографические сервисы или хранить статические пары ключ/значение. Каждый движок работает внутри Server и взаимодействует с Barrier.
-
Audit devices
Приложения аудита (Audit devices) фиксируют каждый запрос и ответ, проходящие через OpenBao. Несколько устройств аудита может работать одновременно (например, локальные файлы, syslog, внешние системы логирования). Логи аудита защищены и должны быть доступны только администраторам.
-
Expiration Manager
Expiration Manager отслеживает сроки жизни для токенов и доступов. Он гарантирует автоматический отзыв доступов, срок действия которых истек, и продление тех, которые можно обновить.
-
Rollback Manager
Rollback Manager обеспечивает согласованность в случае сбоев. Если запрос к Secrets Engine завершается ошибкой, rollback-записи гарантируют отчистку незавершенных состояний.
Основные концепции
Sealing и unsealing
При запуске сервер находится в состоянии sealed. Root key должен быть восстановлен прежде чем OpenBao сможет начать работу.
По умолчанию OpenBao использует Shamir’s Secret Sharing для разделения ключа unseal на несколько частей. Для восстановления ключа требуется пороговое количество частей. Это обеспечивает распределенное восстановление и предотвращает компрометацию из одной точки.
При необходимости могут использоваться внешние системы управления ключами (KMS) или аппаратные модули безопасности (HSM) для авто-unsealing или защиты root key.
Аутентификация
Клиенты проходят аутентификацию с использованием поддерживаемых методов (токены, открытые/приватные ключи, LDAP, GitHub и т.д.). Сервер проверяет учетные данные через выбранный метод аутентификации. После успешной аутентификации и авторизации OpenBao выдает токен и связывает его с соответствующими политиками.
Применение политик
Когда клиент выполняет запрос, сервер проверяет политики, связанные с его токеном, по пути и операции. Политики следуют модели "запрещено по умолчанию", что означает предоставление доступа к ресурсу только при явном разрешении такого доступа.
Управление токенами
Токены являются основным идентификатором клиента после его проверки. Токены могут иметь срок действия, возможность обновления или быть дочерними относительно другого токена. Token Store проверяет токены при каждом запросе, применяет TTL и отзывает токены.