OGOwnGate

· Команда OwnGate

Логи и ошибки только для своих: закрываем Sentry и Kibana единым контуром

Стектрейсы в Sentry и логи в Kibana — настоящая золотая жила для злоумышленника: там светятся боевые токены, пароли к базам и персональные данные клиентов. Рассказываем, как закрыть системы мониторинга и трассировки за единым SSO-шлюзом с 2FA.

Безопасный контур доступа к Sentry и системам логирования

Спросите обычного разработчика, какая система в инфраструктуре компании самая секретная. Он назовёт продакшн-базу данных, хранилище секретов HashiCorp Vault или боевой репозиторий в GitLab.

А на вопрос про Sentry, Kibana или OpenSearch Dashboards он махнёт рукой: *«Да брось, там же просто логи и стектрейсы ошибок, обычный технический мусор для отладки»*.

Именно из-за этого заблуждения системы мониторинга и логирования в 80% компаний остаются с открытым анонимным доступом, базовой авторизацией kibana:kibana или инвайтами по личным почтовым ящикам на Gmail.

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

---

Что на самом деле находит хакер в ваших «просто логах»

Когда приложение падает с пятисотой ошибкой (500 Internal Server Error), оно заботливо собирает контекст падения и выгружает его в систему трекинга:

1. Строки подключения к базам данных.

В стектрейсе падения ORM на Python или Go вы регулярно увидите:

DATABASE_URL=postgresql://app_writer:SuperSecretP@ss2026!@10.0.4.12:5432/production

2. Боевые токены и ключи API.

Запрос к внешнему банку или эквайрингу упал по таймауту? Sentry зафиксировал весь объект HTTP-запроса, включая заголовок Authorization: Bearer sec_live_9481028401... и секретные ключи интеграций.

3. Персональные данные клиентов (PII).

Тело POST-запроса при регистрации или оформлении заказа содержит ФИО, паспортные данные, номера телефонов и адреса доставки. В логах это оседает в открытом виде.

4. Архитектурный рентген инфраструктуры.

Внутренние IP-адреса, версии библиотек с известными уязвимостями (CVE), пути к файлам на серверах.

Один доступ к Sentry заменяет злоумышленнику недели изнурительного сканирования сети. Он просто читает готовые пароли и токены прямо из дампов исключений.

---

Типичный кошмар управления доступами к логам

Как обычно устроен вход в Sentry и Kibana в растущей компании:

  • В Kibana админы на скорую руку вешают HTTP Basic Auth в Nginx с одним паролем на всех: devops / developer2025;
  • В Sentry инженеров зовут по ссылкам-приглашениям на личные почты: petya.coolboy@gmail.com;
  • Никакого второго фактора нет в помине;
  • Когда разработчик увольняется, его доменную учётку блокируют, а доступ к логам остаётся активным, потому что про него банально никто не вспомнил.

---

Решение: закрываем логи за единым шлюзом доступа OwnGate

Все сервисы наблюдаемости (Observability) должны быть интегрированы в единый контур безопасности так же строго, как боевой Kubernetes-кластер.

В архитектуре с шлюзом доступа OwnGate:


[Инженер] ──► [Sentry / Kibana]

                     │

         (Перенаправление на OIDC)

                     ▼

             [Шлюз OwnGate]

                     │

        (Active Directory + TOTP 2FA)

                     │

          (Маппинг ролей по группам)

                     ▼

           [Доступ разрешён]

1. Подключение Sentry по Generic OAuth (OIDC)

Self-hosted Sentry поддерживает SSO из коробки через плагин sentry-auth-oidc или протокол SAML:

  • Пользователи заходят по одной кнопке «Login with Company SSO»;
  • Никаких паролей и регистрации по сторонним email-адресам;
  • Новые разработчики при первом входе автоматически попадают в нужные организации и команды на основе доменных групп AD.

2. Защита Kibana и OpenSearch Dashboards

Для Kibana доступ настраивается через модуль OpenID Connect в kibana.yml:


xpack.security.authc.providers:

  oidc.owngate:

    order: 0

    claims.principal: sub

    claims.groups: groups

    op.authorization_endpoint: "https://auth.company.local/oauth2/authorize"

    op.token_endpoint: "https://auth.company.local/oauth2/token"

    op.jwks_path: "https://auth.company.local/oauth2/jwks"

3. Разграничение прав на уровне окружений

Не каждый разработчик должен видеть продакшн-логи:

  • Джуниор-разработчики через маппинг групп получают доступ только к проектам stage и dev;
  • Доступ к логам продакшна с клиентскими данными открыт только тимлидам и дежурным SRE-инженерам;
  • Вход в консоль логов обязательно требует подтверждения вторым фактором (TOTP) каждые 8 часов.

4. Мгновенная блокировка при оффбординге

Заблокировали инженера в корпоративном каталоге — сессии в Sentry и Kibana сгорают моментально. Бывший сотрудник не унесёт с собой ни единой строчки боевых логов.

Стектрейсы и логи — это не мусор, это концентрированная тайна вашего бизнеса. Закройте к ним доступ по стандарту, и вы лишите злоумышленников самого простого пути к компрометации продакшна.

← Все статьи