Войти

Обзор безопасности

Stable

Как в SPG99 разделены API-ключи и DB-креды, как защищены внешние входы и почему публичная поверхность платформы остаётся компактной.

Обновлено: 5 марта 2026 г.

Безопасность в SPG99 строится на нескольких практических принципах, которые важны и пользователю, и интегратору.

1. Разделение секретов по ролям

В SPG99 есть два разных класса секретов:

  • API key — для Control Plane, Console и автоматизации;
  • pg_user / pg_password — для PostgreSQL‑подключения через Gateway.

Они не взаимозаменяемы и не должны храниться “в одной куче”.

2. TLS на внешних входах

Пользователь работает с платформой через:

  • HTTPS для Console и Control Plane;
  • TLS для PostgreSQL‑подключений к Gateway.

Это означает, что обычный рабочий путь уже построен вокруг защищённых протоколов.

3. Компактная публичная поверхность

Наружу публикуются только необходимые пользовательские домены:

  • landing;
  • Console;
  • Control Plane API;
  • Gateway;
  • Grafana.

Внутренние storage‑сервисы и служебные маршруты остаются внутри платформы.

4. Нет скрытого backend‑суперпользователя на горячем пути

Модель доступа к базе не завязана на “магический общий root‑логин”. Платформа использует управляемые клиентские credentials и сертификаты, что делает схему более прозрачной и безопасной.

5. Секреты не должны жить в git

Для пользовательского и инфраструктурного контура это одно и то же правило: ключи, пароли и TLS‑материалы должны храниться в защищённом контуре секретов, а не в открытых репозиториях и не в конфигурациях “на память”.

Практический итог

Для пользователя это сводится к нескольким понятным правилам:

  • храните API key отдельно от DSN;
  • подключайтесь только через TLS;
  • используйте публичные домены платформы, а не внутренние адреса;
  • ротируйте токены и аккуратно обращайтесь с tenant‑credentials.
Почему SPG99АрхитектураПлан развитияДокументацияБлог