Когда мы говорим о корпоративной безопасности, основное внимание обычно уделяется людям: защите их паролей, внедрению MFA и борьбе с фишингом. Однако в современной ИТ-инфраструктуре количество «нечеловеческих» учетных записей (Non-Human Identities) — сервисных аккаунтов, ключей API, токенов CI/CD и криптографических сертификатов — уже в несколько раз превышает число реальных сотрудников.
Сервисные учетные записи связывают микросервисы в Kubernetes, позволяют скриптам автоматизации делать бэкапы, а корпоративным приложениям — забирать данные из CRM по API. При этом защищены они гораздо хуже человеческих: для них невозможно включить биометрический фактор или Push-уведомление на телефон. Хакеры прекрасно об этом знают. Сегодня компрометация забытого API-ключа в коде — один из самых популярных векторов для молниеносного взлома облачных и локальных ЦОД.
Давайте разберем главные риски, связанные с сервисными аккаунтами, и выстроим безопасную архитектуру управления машинным доступом.
Главные грехи автоматизации: где прячутся риски
Управление машинными секретами страдает от трех системных проблем, которые ИТ-инженеры часто создают ради собственного удобства.
1. Hardcoded Secrets (Секреты, зашитые в код)
Разработчику нужно, чтобы приложение на Python могло записывать логи в базу данных. Вместо настройки безопасного получения пароля он просто пишет этот пароль открытым текстом прямо в коде приложения (db_password = "SuperSecretPassword123"). Затем этот код отправляется в локальный или публичный репозиторий Git. Если хакер получит доступ к репозиторию (или проект случайно сделают публичным), инфраструктура будет скомпрометирована за секунды.
2. Избыточные привилегии (Over-privileged Accounts)
Сервисной учетной записи бэкап-скрипта нужно лишь право на чтение файлов из одной папки и запись их в сетевое хранилище. Но администратору лень настраивать гранулярные права в Active Directory или IAM-системе. Он просто добавляет сервисный аккаунт в группу Domain Admins или выдает ему роль Owner в облаке, руководствуясь принципом «чтобы точно всё работало». Если этот аккаунт взломают, хакер получит полный контроль над всей сетью.
3. Отсутствие ротации (Бессмертные ключи)
Пароли сотрудников компания принудительно заставляет менять раз в три месяца. При этом API-ключ от критической платежной системы, созданный пять лет назад уволившимся разработчиком, может не меняться годами. Чем дольше живет статический ключ, тем выше вероятность, что он уже утек на чьи-то личные компьютеры, в логи прокси-серверов или тестовые конфигурации.
Архитектура безопасного управления секретами
Чтобы навести порядок в машинном доступе, необходимо полностью отказаться от статических секретов, разбросанных по текстовым файлам серверов, и перейти к централизованной архитектуре управления — Secret Management.
Шаг 1. Централизованный сейф (Vaulting)
Все пароли, токены и API-ключи изымаются из конфигурационных файлов приложений и переносятся в специализированное зашифрованное хранилище. Мировым стандартом здесь является HashiCorp Vault, также существуют мощные отечественные Enterprise-решения. Приложение больше не хранит пароль. При старте оно обращается к сейфу по защищенному каналу, подтверждает свою подлинность (через AppRole, кубы или аппаратный профиль сервера) и запрашивает нужный ему ключ API в оперативную память.
Шаг 2. Переход на динамические секреты (Dynamic Secrets)
Высший пилотаж безопасности — полный отказ от постоянных паролей. Современные менеджеры секретов умеют генерировать пароли «на лету» по запросу. Как это работает: Приложению нужно сделать запрос к базе данных PostgreSQL. Оно обращается к Vault. Vault сам идет в СУБД, создает там временного пользователя со случайным сложным паролем и выставляет ему срок жизни (TTL), например, ровно 30 минут. Vault отдает эти данные приложению. Через 30 минут база данных автоматически удаляет этого пользователя. Даже если хакер перехватит этот пароль, использовать его завтра он уже не сможет.
Шаг 3. Внедрение Secret Scanning (Поиск утечек)
Чтобы разработчики не продолжали по привычке заливать ключи в Git, в пайплайн разработки (CI/CD) внедряются автоматические сканеры кода, такие как Gitleaks или TruffleHog. При попытке сделать git push система автоматически сканирует код по регулярным выражениям и энтропии текста. Если робот находит строку, похожую на приватный SSH-ключ или API-токен AWS, коммит блокируется, а ИБ-отдел получает алерт.
Сравнение подходов к аутентификации сервисов
При выборе способа авторизации самих сервисных аккаунтов внутри инфраструктуры используйте матрицу безопасности:
| Тип аутентификации | Удобство | Уровень безопасности | Основные риски |
|---|---|---|---|
| Статический API Key | Максимальное (простая строка в заголовке HTTP) | Низкий | Легко украсть из логов, перехватить в трафике или забыть в коде. |
| Сертификаты (mTLS) | Высокое (взаимная проверка серверов) | Высокий | Сложно управлять выпуском и отзывом сотен сертификатов вручную. |
| Временные токены (OAuth2 / OIDC) | Высокое (короткий срок жизни токенов JWT) | Высокий | Требует наличия надежного централизованного сервера авторизации. |
| IAM Roles / Managed Identities | Максимальное (без паролей в среде) | Абсолютный | Применимо только внутри однородной платформы. |
Инструмент Managed Identities (управляемые удостоверения) — идеальный выбор, если вы работаете в виртуальной среде. Например, если ваши микросервисы развернуты on-premise на корпоративных платформах виртуализации zVirt, Proxmox VE, ZStack или кластерах Брест, вы можете привязывать права доступа прямо к метаданным и сетевому профилю конкретной виртуальной машины на уровне гипервизора. Приложению вообще не нужен пароль для авторизации во внутренней сети — сама платформа подтверждает легитимность виртуального узла.
План действий: как навести порядок за 4 шага
- Проведите аудит и инвентаризацию: Выгрузите из Active Directory и баз данных списки всех учетных записей, у которых в поле «срок действия пароля» стоит галочка «Never Expires» (Никогда не истекает). Сверьте их с реальными ИТ-системами и удалите мертвые аккаунты.
- Заберите права администратора: Примените принцип наименьших привилегий (Least Privilege). Заберите у всех сервисных аккаунтов права Domain Admins и выдайте им только точечные доступы к конкретным таблицам или папкам.
- Изолируйте сервисный трафик: На уровне сетевых экранов (NGFW) жестко пропишите, с каких конкретно IP-адресов серверов приложения имеет право авторизовываться данный сервисный аккаунт. Если хакер украдет API-ключ, но попытается применить его из внешнего интернета, NGFW заблокирует запрос.
- Включите детальный аудит: Машинные учетные записи должны генерировать подробные логи. Настройте SIEM-систему на отслеживание аномалий: если сервисный аккаунт, который всегда заходил по расписанию в 3 часа ночи для бэкапа, вдруг начинает хаотично авторизовываться в разгар рабочего дня и качать другие файлы — система должна немедленно заблокировать учетную запись.
Частые вопросы
Чем API Key принципиально отличается от токена OAuth2?
API-ключ — это статическая строка (фактически постоянный пароль), которая создается один раз и работает до тех пор, пока её вручную не удалят. Если его украдут, злоумышленник получит бессрочный доступ. Токен OAuth2 (например, JWT) — это динамический временный паспорт. Приложение сначала подтверждает свою личность с помощью закрытого ключа, получает токен, который действует всего 15–60 минут, и ходит по API с ним. По истечении часа токен становится недействительным, что резко снижает риски при его перехвате.
Что такое «Слепые зоны» (Secret Zero Problem) менеджеров секретов?
Это главный парадокс систем класса Secret Management. Чтобы приложение могло зайти в HashiCorp Vault и забрать оттуда пароль от базы данных, само приложение должно иметь какой-то первичный ключ для входа в сам Vault. Этот самый первый секрет называют Secret Zero. Если разработчик зашьет в код Secret Zero, то вся безопасность Vault аннулируется. Для решения этой проблемы используют доверенную среду: Vault интегрируют с облачным провайдером или локальным гипервизором, который сам подтверждает подлинность виртуальной машины на основе её уникального аппаратного ID (UUID), избавляя инженеров от необходимости хранить Secret Zero в коде.
Можно ли использовать переменные окружения (Environment Variables) для хранения API-ключей на сервере?
Это значительно лучше, чем хардкодить ключи прямо в файлы кода (так как код можно безопасно заливать в Git). Однако переменные окружения нельзя считать абсолютно безопасным хранилищем. Если хакер сможет взломать сервер через уязвимость Remote Code Execution (RCE) или получит локальные права обычного пользователя, он сможет выполнить простую команду env или printenv и увидеть все ваши секреты и API-ключи открытым текстом на экране. Переменные окружения — это лишь промежуточный шаг на пути к внедрению полноценного менеджера секретов.