Защита Grafana, Prometheus и Alertmanager: Полное руководство по настройке двухфакторной аутентификации (2FA) в 2026 году | AdminWiki
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Защита Grafana, Prometheus и Alertmanager: Полное руководство по настройке двухфакторной аутентификации (2FA) в 2026 году

24 мая 2026 10 мин. чтения

Почему стандартного пароля недостаточно: Угрозы для DevOps-панелей в 2026 году

Интерфейсы Grafana, Prometheus и Alertmanager часто содержат метрики, алерты и конфигурации всей инфраструктуры. Компрометация этих панелей приводит к утечке данных, подмене алертов или полному отключению мониторинга. В 2026 году атаки на такие системы стали более автоматизированными. Скрипты сканируют открытые порты 3000 (Grafana) и 9090/9093 (Prometheus/Alertmanager), пытаясь подобрать стандартные пароли или использовать уязвимости в конкретных версиях ПО.

Последствия успешной атаки включают:

  • Утечка внутренних метрик и данных о производительности сервисов.
  • Создание ложных алертов для маскировки реальных инцидентов.
  • Остановка или модификация правил алертинга, что скрывает проблемы.
  • Получение доступа к данным, которые могут быть использованы для дальнейших атак.

Prometheus и Alertmanager особенно часто остаются незащищенными, поскольку их веб-интерфейсы не имеют встроенной поддержки двухфакторной аутентификации. Это создает единую точку уязвимости в стеке мониторинга.

Выбор метода двухфакторной аутентификации: Сравнение TOTP, FIDO2 и OAuth2

Для защиты панелей доступны несколько методов 2FA. Выбор зависит от требований безопасности, бюджета и удобства для команды.

Метод Принцип работы Плюсы Минусы Рекомендуемый сценарий
TOTP-приложения (Google Authenticator, Aegis) Генерация одноразовых кодов на основе времени и секретного ключа. Бесплатно, просто в настройке, широко поддерживается. Зависит от устройства пользователя, риск потерять доступ при потере телефона. Личные или небольшие развертывания, где каждый пользователь управляет своим устройством.
Аппаратные ключи (FIDO2/U2F) Физический ключ подтверждает вход криптографически. Наивысшая безопасность, устойчивость к фишингу, независимость от телефона. Стоимость ключей, необходимость их физического наличия, поддержка в Grafana требует дополнительных настроек. Корпоративные среды с высокими требованиями безопасности и бюджетом на оборудование.
OAuth2-провайдеры (GitLab, GitHub, Google) Аутентификация через внешний сервис, который может иметь свою 2FA. Централизованное управление доступом, удобство для команд, интеграция с корпоративными SSO. Зависит от внешнего сервиса, сложность настройки для self-hosted провайдеров. Команды, уже использующие GitLab или GitHub Enterprise; среды с единой системой идентификации.

Для большинства DevOps-сред оптимальным выбором является комбинация TOTP для Grafana и защита Prometheus/Alertmanager через обратный прокси с базовой аутентификацией. Если команда использует GitLab или GitHub, интеграция OAuth2 упрощает управление.

Пошаговая настройка 2FA в Grafana через Google Authenticator

Включение двухфакторной аутентификации в Grafana через TOTP - стандартный процесс. Следуйте этим шагам для Grafana версий 9.x и выше.

  1. Вход и смена пароля администратора. После первого запуска Grafana войдите с учетными данными по умолчанию (admin/admin). Немедленно измените пароль администратора в разделе Profile → Security → Change Password. Это критический шаг перед настройкой 2FA.
  2. Переход к настройке 2FA. В том же разделе Profile → Security найдите кнопку Enable 2FA и нажмите ее.
  3. Сканирование QR-кода. Grafana отобразит QR-код и секретный ключ в текстовом формате. Откройте приложение Google Authenticator (или аналогичное, например, Aegis) на вашем устройстве, добавьте новую учетную запись и сканируйте QR-код.
  4. Сохранение резервных кодов. После сканирования Grafana предложит сохранить список резервных кодов. Эти коды позволяют войти в систему, если устройство с аутентификатором недоступно. Сохраните их в безопасном месте, например, в зашифрованном файле или менеджере паролей.
  5. Первый вход с 2FA. Выйдите из Grafana и войдите снова. После ввода имени пользователя и пароля система потребует шестизначный код из приложения Authenticator. Введите его для завершения процесса.

Важные замечания: Убедитесь, что время на сервере Grafana и на вашем устройстве синхронизировано через NTP. Разница более 30 секунд может привести к ошибке «Неверный код». Если Grafana работает за прокси, убедитесь, что прокси не модифицирует заголовки запросов аутентификации.

Типовые проблемы при настройке TOTP и их решение

При внедрении могут возникнуть следующие проблемы:

  • «Неверный код» при вводе TOTP. Проверьте синхронизацию времени на сервере Grafana командой date и на устройстве пользователя. Разница должна быть минимальной. Также проверьте, что в приложении Authenticator правильно указан период генерации кода (обычно 30 секунд).
  • Потеря устройства с Authenticator. Используйте резервные коды, сохраненные на шаге 4. Если коды утеряны, потребуется аварийное отключение 2FA через базу данных. Для Grafana с базой данных SQLite или PostgreSQL выполните запрос, обновляющий поле two_factor_auth в таблице пользователей. Это критическая операция, выполняйте ее только при полной потере доступа.
  • Проблемы при работе за прокси. Некоторые прокси могут блокировать или изменять запросы к эндпоинтам аутентификации. Проверьте логи Grafana (/var/log/grafana/grafana.log) и прокси на наличие ошибок 401 или 403. Убедитесь, что прокси передает оригинальные заголовки Host и X-Forwarded-For.
  • 2FA не предлагается после входа. Убедитесь, что 2FA действительно включена в профиле пользователя. Проверьте конфигурационный файл grafana.ini: параметры [auth] не должны запрещать использование двухфакторной аутентификации.

Для более детальной диагностики включите более подробное логирование в Grafana, временно установив log.level = debug в grafana.ini.

Интеграция Grafana с корпоративным SSO через OAuth2 (GitLab/GitHub)

Интеграция Grafana с OAuth2 провайдерами позволяет использовать единую систему идентификации и часто включает двухфакторную аутентификацию на стороне провайдера. Это удобно для команд, уже использующих GitLab или GitHub.

  1. Создание OAuth Application в провайдере.
    • Для GitLab: в административном интерфейсе или профиле пользователя перейдите в Settings → Applications. Создайте новое приложение. Укажите имя (например, «Grafana»), Redirect URI: https://your-grafana-domain/login/generic_oauth. Выберите scopes: read_user, api.
    • Для GitHub: в настройках организации или пользователя перейдите в Developer settings → OAuth Apps. Создайте новое приложение. Redirect URI тот же. Scopes: user:email, read:org.
  2. Конфигурация grafana.ini. Добавьте или измените следующие параметры в конфигурационном файле Grafana:
    [auth.generic_oauth]
    name = GitLab
    enabled = true
    client_id = YOUR_CLIENT_ID
    client_secret = YOUR_CLIENT_SECRET
    scopes = read_user api
    auth_url = https://your-gitlab-instance/oauth/authorize
    token_url = https://your-gitlab-instance/oauth/token
    api_url = https://your-gitlab-instance/api/v4/user
    allowed_domains =
    allow_sign_up = false
    auto_login = false
    
    Для GitHub параметры auth_url, token_url и api_url будут соответствовать эндпоинтам GitHub API.
  3. Настройка ролей и автоматического создания пользователей. Параметр allow_sign_up контролирует, может ли Grafana автоматически создавать учетные записи для новых пользователей, аутентифицированных через OAuth. Для корпоративных сред рекомендуется allow_sign_up = false и предварительное создание пользователей в Grafana с соответствующими ролями. Роли пользователей (Admin, Editor, Viewer) можно назначать через интерфейс Grafana после их первого входа.
  4. Тестирование входа. Перезапустите Grafana после изменения grafana.ini. Попробуйте войти через новый пункт «Login with GitLab» (или GitHub) на странице входа. После успешной аутентификации провайдер вернет вас в Grafana. Если провайдер имеет свою 2FA, пользователь будет подвергнут двухфакторной проверке на стороне GitLab/GitHub.

Особенности настройки для GitLab Self-Hosted и GitHub Enterprise

Для self-hosted инсталляций GitLab или GitHub Enterprise есть дополнительные нюансы:

  • URL эндпоинтов. Используйте внутренний адрес вашего инстанса, например, https://gitlab.company.internal. Убедитесь, что Grafana может обращаться к этому адресу.
  • TLS/SSL сертификаты. Если ваш инстанс использует внутренние или самоподписанные CA, Grafana должна доверять этим сертификатам. Добавьте корневой CA сертификат в доверенные хранилища системы, где работает Grafana.
  • Scopes для получения информации о группах. Для автоматического назначения ролей в Grafana на основе групп GitLab могут потребоваться дополнительные scopes, например, read_api или read_group. Это позволяет Grafana получать список групп пользователя через API.

Интеграция с OAuth2 централизует управление доступом и повышает безопасность, поскольку провайдеры обычно имеют более развитые механизмы 2FA и контроля сессий.

Защита Prometheus, Alertmanager и других компонентов без встроенного 2FA

Prometheus и Alertmanager не имеют встроенной поддержки двухфакторной аутентификации в своих веб-интерфейсах. Эффективный метод защиты - организация единой точки входа через обратный прокси с обязательной аутентификацией. Это создает дополнительный барьер перед доступом к интерфейсам.

Решения для обратного прокси:

  • Nginx - наиболее распространенный и гибкий вариант.
  • Nginx Proxy Manager - удобный веб-интерфейс для управления прокси и базовой аутентификацией.
  • Traefik - популярен в Docker и Kubernetes-средах, поддерживает множество методов аутентификации.

Базовая аутентификация (Basic Auth) на уровне прокси часто достаточна для внутренних сервисов, поскольку добавляет обязательный шаг проверки перед доступом к интерфейсу. В сочетании с 2FA для Grafana это создает многоуровневую защиту стека.

Настройка Nginx в качестве защищенного шлюза: пример конфигурации

Пример конфигурации Nginx для защиты Prometheus и Alertmanager:

server {
    listen 443 ssl;
    server_name monitor.company.internal;

    ssl_certificate /etc/nginx/ssl/monitor.crt;
    ssl_certificate_key /etc/nginx/ssl/monitor.key;

    # Защита Prometheus UI
    location /prometheus/ {
        auth_basic "Prometheus Authentication";
        auth_basic_user_file /etc/nginx/.htpasswd-prometheus;
        proxy_pass http://localhost:9090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Защита Alertmanager UI
    location /alertmanager/ {
        auth_basic "Alertmanager Authentication";
        auth_basic_user_file /etc/nginx/.htpasswd-alertmanager;
        proxy_pass http://localhost:9093;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    # Grafana уже имеет свою 2FA, проксируем без дополнительной аутентификации
    location /grafana/ {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Создайте файлы с паролями с помощью команды htpasswd:

htpasswd -c /etc/nginx/.htpasswd-prometheus admin
htpasswd /etc/nginx/.htpasswd-alertmanager admin

Эта конфигурация проксирует запросы к локальным сервисам, добавляя обязательную базовую аутентификацию для Prometheus и Alertmanager.

Развертывание стека с аутентификацией через Docker Compose

Для быстрого тестирования или внедрения можно использовать готовый Docker Compose файл, который включает все компоненты и Nginx Proxy Manager для удобного управления аутентификацией.

version: '3.8'
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus/config:/etc/prometheus
      - ./prometheus/data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    networks:
      - monitoring

  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager/config:/etc/alertmanager
    networks:
      - monitoring

  grafana:
    image: grafana/grafana:latest
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=secure_admin_password_here
    volumes:
      - ./grafana/data:/var/lib/grafana
    networks:
      - monitoring

  nginx-proxy-manager:
    image: 'jc21/nginx-proxy-manager:latest'
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    volumes:
      - ./nginx/data:/data
      - ./nginx/letsencrypt:/etc/letsencrypt
    networks:
      - monitoring

networks:
  monitoring:
    driver: bridge

После запуска docker-compose up -d доступ к Nginx Proxy Manager веб-интерфейсу осуществляется по порту 81. В нем создайте прокси-хосты для Grafana (порт 3000), Prometheus (порт 9090) и Alertmanager (порт 9093). Для Prometheus и Alertmanager включите опцию «Basic Authentication» и задайте учетные данные. Grafana будет доступна через прокси, но ее собственная 2FA будет действовать после входа.

Этот подход автоматизирует развертывание защищенного стека. Для production-сред рекомендуется использовать более продвинутые инструменты управления конфигурацией, такие как Ansible или Terraform, как описано в руководствах по отказоустойчивой инфраструктуре.

Чеклист внедрения и ответы на частые вопросы (FAQ)

Поэтапный чеклист внедрения:

  1. Аудит текущего доступа. Определите, какие интерфейсы (Grafana, Prometheus UI, Alertmanager UI) открыты для сети, и каким учетным данным доступны.
  2. Выбор метода 2FA. Выберите метод для Grafana (TOTP, OAuth2) исходя из потребностей команды и инфраструктуры.
  3. Настройка прокси для Prometheus/Alertmanager. Разверните обратный прокси (Nginx, NPM, Traefik) и настроите базовую аутентификацию для этих сервисов.
  4. Включение 2FA в Grafana или настройка OAuth2. Выполните пошаговую настройку согласно инструкции выше.
  5. Тестирование и информирование команды. Проверьте полный цикл аутентификации для всех пользователей. Сообщите команде о новых процедурах входа и предоставьте резервные коды или инструкции по восстановлению.

Ответы на частые вопросы (FAQ):

  • Что делать при потере ключа 2FA (телефона с Authenticator)? Используйте резервные коды, сохраненные при первоначальной настройке. Если они утеряны, для Grafana потребуется аварийное отключение 2FA через базу данных (см. выше). Для OAuth2 восстановление происходит через провайдера (GitLab/GitHub).
  • Как отключить 2FA для сервисного аккаунта? Grafana не рекомендует использовать 2FA для сервисных аккаунтов, которые используются API. Для таких аккаунтов лучше использовать отдельные учетные записи без 2FA, но с ограниченными правами и защищенными сильными паролями или токенами.
  • Можно ли обойтись без прокси для Prometheus? Можно, но это менее безопасно. Альтернатива - использование флага --web.external-url и настройка аутентификации через сторонние middleware, но это сложнее. Прокси - наиболее универсальный и простой метод.
  • Как настроить алерты на попытки неудачного входа? В Grafana можно отслеживать события аутентификации через логи. Для Prometheus/Alertmanager, защищенных прокси, неудачные попытки будут регистрироваться в логах Nginx. Настройте алерт в Prometheus на основе этих логов или используйте внешние системы мониторинга безопасности.
  • Подходит ли этот подход для Kubernetes? Да. В Kubernetes можно развернуть Nginx или Traefik как Ingress Controller и настроить аннотации для базовой аутентификации. Grafana в Kubernetes также поддерживает 2FA и OAuth2. Детали можно найти в специализированных руководствах.

Регулярное обновление паролей для базовой аутентификации на прокси и аудит списка пользователей Grafana завершают цикл управления безопасностью стека мониторинга.

Поделиться:
Сохранить гайд? В закладки браузера