Основные концепции

Секрет как запись в Пассворке

В Пассворке нет отдельной сущности «секрет» — любая парольная запись может выступать секретом. Это даёт гибкость: один и тот же интерфейс используется и для пользовательских паролей, и для инфраструктурных секретов.

Где хранить секрет внутри записи

Тип поля	Что хранить	Пример
Логин	Учётные данные с логином	postgres
Пароль	Секреты, пароли, ключ	s3cr3t-p@ss
Пользовательские поля	Дополнительные именнованные секерты, поля, токены, ключ	API_KEY, JWT_SECRET, DB_PASSWORD
Описание	Конфигурационные фрагменты, JSON, YAML	Блок переменных окружения, JSON с настройками

Рекомендация

Для автоматизации удобне использовать пользовательские поля с понятными именами (DB_PASSWORD, API_KEY). Это упрощает выборку через CLI/SDK и делает записи самодокументируемыми.

Классификация секретов

Для организации и поиска секретов используйте:

• Теги — логическая группировка: prod, stage, dev, database, api, kubernetes.
• Название — назначение секрета
• Дерево папок — группировка секретов

Структурирование секретов

Правильная структура папок — основа автоматизации. Когда секреты организованы предсказуемо, CLI и SDK могут находить и собирать их без ручной настройки.

Принцип организации

Выделите отдельное хранилище (vault) или корневую папку под инфраструктурные секреты. Внутри используйте иерархию по окружениям и категориям:

secrets/
├── prod/
│   ├── databases/
│   │   ├── postgres-main
│   │   └── redis-cache
│   ├── api/
│   │   └── payment-gateway
│   └── kubernetes/
│       └── cluster-config
├── stage/
│   ├── databases/
│   └── api/
└── dev/
    └── sandbox/

Как это упрощает автоматизацию

Задача	Решение
Получить все секреты production	passwork-cli exec --folder-id <secrets/prod ID>
Получить только БД-секреты prod	passwork-cli exec --folder-id <secrets/prod/databases ID>
Найти все kubeconfig	Поиск по тегу kubernetes

Именование записей

Используйте понятные имена, отражающие назначение:

• ✅ postgres-main, redis-session-store, stripe-api-key
• ❌ password1, new-secret, test123

Хорошее именование позволяет:

• быстро находить секреты в UI и через поиск CLI;
• понимать назначение записи без открытия;
• избежать путаницы при ротации и аудите.

Права доступа

Пассворк поддерживает гранулярное управление доступом на уровне хранилищ и папок:

• DevOps-команда → полный доступ к secrets/prod и secrets/stage.
• Разработчики → доступ только к secrets/dev.
• CI/CD-сервис (технический пользователь) → read-only к secrets/prod для деплоя.

Права наследуются по иерархии папок, но могут быть переопределены на любом уровне.

Как работает аутентификация в API

Запросы к API Пассворка выполняются от имени учётной записи. Это может быть учётная запись (личный вход в систему) или сервисная учётная запись — отдельный тип пользователя, который в Пассворке предусмотрен для скриптов, CI/CD и других автоматизаций. В обоих случаях для работы с API нужна пара токенов:

• Access Token — авторизация запросов к API, ограниченное время жизни.
• Refresh Token — получение нового access token без повторной выдачи пары с нуля (без повторного ввода учётных данных там, где это применимо).

Продление пары токенов по HTTP (полная ротация и отдельно access или refresh) описано в Ротация API-токенов. Токены выдаются для выбранной учётной записи, все вызовы API выполняются с её правами и фиксируются в аудите под этим участником. Это означает:

• Интеграция видит только те хранилища и папки, к которым у этой учётной записи есть доступ.
• Запись возможна только там, где выданы соответствующие права.
• В журнале аудита видно, от какой учётной записи выполнено действие (в т.ч. сервисной).

Сервисные учётные записи для интеграций

Для автоматизации (CI/CD, скрипты ротации, внутренние сервисы) рекомендуем использовать отдельные сервисные учётные записи, а не личные аккаунты сотрудников.

Преимущества:

• Изоляция доступа — сервисная учётка имеет доступ только к нужным папкам, без лишних прав.
• Полный аудит — в логах видно, что действие выполнено автоматизацией, а не человеком.
• Независимость от кадровых изменений — увольнение сотрудника не ломает CI/CD.
• Гибкие настройки безопасности — для сервисных учёток можно задать отдельные параметры.

Рекомендация

Объедините сервисные учётные записи в отдельную роль (например, Service Accounts или CI/CD Integration). Для этой роли настройте:

• Время жизни API-токенов — короткие токены для CI/CD, длинные для постоянных сервисов.
• Политики паролей — можно ослабить требования к «паролю» учётки, если аутентификация идёт только по токену.

Пример структуры сервисных учёток:

Учётная запись	Назначение	Доступ
ci-deploy-prod	Деплой в production	read-only к secrets/prod
ci-deploy-stage	Деплой в staging	read-only к secrets/stage
rotation-bot	Ротация секретов	read-write к secrets/prod, secrets/stage
monitoring-svc	Проверка целостности	read-only ко всем секретам

Важность с точки зрения ИБ

Архитектура «интеграция = пользователь» даёт ряд преимуществ для информационной безопасности:

1. Принцип минимальных привилегий — каждая интеграция получает ровно тот доступ, который ей нужен. CI/CD для деплоя не имеет прав на ротацию, а бот ротации не видит секреты dev-окружения.

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

3. Быстрое реагирование — при компрометации одной интеграции достаточно отозвать токены конкретной сервисной учётки, не затрагивая остальные.

4. Разделение ответственности — DevOps-команда управляет сервисными учётками для инфраструктуры, а команда разработки — для своих сервисов.

Важно

Все операции с секретами (чтение, изменение, удаление) записываются в журнал аудита Пассворка. Это включает:

• Кто выполнил операцию (имя пользователя / сервисной учётки)
• Когда (timestamp)
• Что именно было сделано (тип операции, ID записи)

Версия для LLM