«Если открываете сайт в браузере, вы уже запускаете чужой код. Но браузер, это песочница для вас. Для IT-системы песочницей становится архитектура, где каждый запрос — подозреваемый, а каждый сервис — независимый судья.»
Почему нельзя просто закрыть всё на замок
Представьте: вы запрещаете всем сотрудникам подключаться к корпоративным сервисам из дома или в дороге. Формально сеть безопасна — доступ только с доверенных IP в офисе. Но это не работает. Jira, GitLab, CRM, почта — всё это работает в облаках или доступно через интернет. Сотрудники пользуются тем, что удобно. Попытки запретить приводят к «серым» решениям: теневым VPN, прокси, пересылке файлов через личные почты.
Традиционный подход «периметр безопасности» предполагает защиту границ сети: брандмауэр закрывает порты, VPN даёт доступ внутрь. Но внутри этой сети всё равно доверяют всем. Успешный вход через VPN даёт доступ ко всему внутреннему пространству. Если логин и пароль утекли из-за фишинга или утечки на стороннем сайте, злоумышленник становится «доверенным» пользователем в системе. Периметр не спасает от тех, кто уже внутри.
Современная работа не имеет фиксированной границы. Подрядчики, удалённые сотрудники, мобильные приложения, интеграции с SaaS — всё это происходит через публичные сети. IP-адрес уже не говорит о доверии. Запрос из офиса и запрос из домашней сети должны оцениваться одинаково — по тому, кто его делает, а не где он находится.
Zero Trust, это не лозунг, а техническая архитектура
Zero Trust, это архитектурный принцип: каждый запрос к любому ресурсу проверяется полностью, независимо от его источника. Нет «внутреннего» трафика, которому можно доверять автоматически. Сервис в той же подсети должен подтвердить свою легитимность так же строго, как запрос из интернета.
Что проверяется:
- Идентичность пользователя или системы (не просто логин/пароль, а токены с коротким сроком жизни).
- Контекст запроса: время, геолокация, устройство (есть ли зашифрованный диск, актуальный антивирус).
- Состояние приложения: версия, патчи, наличие регистрации в каталоге устройств.
- Принципы работы: система не хранит состояние доверия. Сессия не создается на сервере. Каждый транзакционный вызов — GET, POST, вызов API — должен содержать проверенный идентификатор (например, JWT), который сервис валидирует самостоятельно.
Это приводит к архитектуре, где безопасность становится свойством каждого компонента, а не надстройкой над сетью.
Что можно безопасно разместить в публичной сети
Веб-приложения без состояния сессии на сервере
Если приложение не хранит сессию в памяти или файлах, а использует токены (JWT), выдаваемые центральным сервисом идентификации, его можно размещать открыто. Каждый запрос содержит токен, который проверяется на уровне кода приложения. Сервер не управляет «входом» — он лишь реагирует на корректные запросы. Пример: большинство современных SPA (Single Page Application), где авторизация реализована через OAuth 2.0 / OpenID Connect.
API Gateway как единственная точка входа
Вместо прямого доступа к множеству внутренних API, весь трафик направляется через API Gateway. Шлюз выполняет аутентификацию, проверку токенов, лимитирование запросов (rate limiting), валидацию структуры данных, и только затем передаёт очищенный запрос внутрь. Бэкенд-сервисы могут работать в закрытой подсети, не имея публичных IP, и не заниматься проверкой контекста самостоятельно.
Статические ресурсы через подписанные URL (Signed URLs)
Файлы — HTML, CSS, JS, документы, медиа — можно хранить в S3-совместимых хранилищах и раздавать через CDN. Доступ контролируется через подписанные URL, которые содержат хеш, срок действия и привязку к конкретному объекту. После истечения времени ссылка становится недействительной. Это безопасный способ делиться файлами без открытия всей папки и без обязательной аутентификации на уровне хранилища.
Serverless функции (FaaS)
Функции, такие как AWS Lambda, Яндекс Cloud Functions, по своей природе не имеют постоянно открытых портов. Они запускаются только по триггеру от доверенного источника: вызов от API Gateway, событие в защищённой очереди. Функция выполняется и завершается. Даже если злоумышленник узнает endpoint, он не сможет вызвать функцию без токена, который проверяется шлюзом до исполнения.
Что нельзя выставлять в интернет, даже с проверками
Системы управления базами данных (MySQL, PostgreSQL, MongoDB)
Прямой доступ к БД через стандартные порты (3306, 5432, 27017) должен быть закрыт из интернета. Эти протоколы не поддерживают сложные механизмы контекстной аутентификации — обычно только логин и пароль. Они становятся целью для автоматических сканеров, которые проводят постоянные попытки подключения и подбора. Защита через изменение порта или правила брандмауэра — лишь обфускация, не устраняющая риски.
Протоколы прямого управления (SSH, RDP)
SSH (22 порт) и RDP (3389) — главные цели для автоматических бот-сетей. Попытки подключения происходят постоянно. Эти протоколы не анализируют контекст: устройство, состояние ОС, поведение. Они не блокируют запросы на основе отклонений от нормы. Если доступ нужен для администрирования, его следует предоставлять через защищённые шлюзы доступа (например, Bastion host в isolated сети или решения типа Teleport), а не напрямую.
Служебные сервисы мониторинга и управления (Grafana, Prometheus, Consul)
Сервисы вроде Grafana (без аутентификации), Prometheus с открытым доступом к метрикам, или Consul для управления кластером раскрывают структуру инфраструктуры. Они показывают узлы, их имена, версии ПО, нагрузку. Эта информация становится основой для целевых атак. Такие компоненты не предназначены для публичного доступа и обычно не имеют механизмов идентификации на уровне приложения.
Внутренние инфраструктурные компоненты (очереди, кэши, блокировки)
Сервисы, такие как RabbitMQ (очереди), Redis (кэш), или распределённые блокировки, полагаются на сетевую изоляцию как на основную защиту. Их архитектура не предполагает проверки каждого запроса по полному контексту. Если они попадают в публичную сеть, даже с добавленной аутентификацией, они остаются уязвимыми из-за своих внутренних протоколов. Их нужно либо изолировать в приватных сетях, либо заменять на решения, архитектурно безопасные для публичного доступа.
Практические паттерны для безопасного размещения
Шлюз с проверкой идентификации (Identity-aware Gateway)
Весь трафик в приложение проходит через шлюз, который выполняет аутентификацию до попадания в основное приложение. Примеры: Cloudflare Access, oauth2-proxy, Zitadel. Пользователь попадает на домен, шлюз перехватывает запрос, перенаправляет на Identity Provider (IdP), получает подтверждение, и только затем пропускает запрос дальше. Приложение видит уже проверенные запросы с заголовками, содержащими информацию о пользователе (например, email, группы). Это позволяет размещать приложение публично, не встраивая логику авторизации внутрь.
Сервисная сеть (Service Mesh) с mTLS
Сервисы внутри системы общаются через взаимную аутентификацию TLS (mTLS) — каждый узел имеет сертификат, и перед передачей данных происходит взаимная проверка. Весь внутренний трафик шифруется. Публичный доступ осуществляется через единый шлюз (ingress gateway), который выступает как точка аутентификации для внешних вызовов. Остальные узлы не имеют публичных IP, их нельзя достичь напрямую. Решения: Istio, Linkerd, Consul Connect.
API-ключ как временный токен (Ephemeral API Key)
Вместо постоянных API-ключей, которые при утечке остаются активными до явного отзыва, используется подписанный JWT-токен с коротким сроком жизни (минуты, часы). Процесс: внешний сервис или клиент сначала обращается к центру аутентификации, который выдаёт токен с указанием ресурса, операции и срока действия. Этот токен проверяется каждым сервисом на входе. Преимущества: если ключ скомпрометирован, он самоуничтожается через короткое время; центральный сервис может принудительно отозвать токен мгновенно; снижается поверхность атаки и упрощается аудит.
С чего начать внедрение в своём проекте
Первый шаг — инвентаризация доступов. Составьте таблицу всех сервисов, принимающих входящие соединения.
| Сервис | Пользователи/Системы | Данные | Текущий доступ | Критичность |
|---|---|---|---|---|
| Веб-интерфейс CRM | Клиенты, менеджеры | Контакты, сделки | Публичный IP, базовая аутентификация | Высокая |
| Admin API | Внутренние системы | Конфигурация | Внутренняя сеть, без аутентификации | Средняя |
| Статический сайт | Все | Документы, блог | Публичный, без контроля | Низкая |
Второй шаг — выбрать «крайнюю точку». Самый важный публичный сервис, например, веб-интерфейс для клиентов или панель администратора. Для него внедрите шлюз аутентификации. Уберите все правила доступа по IP. Переведите пользователей на единый Identity Provider. Добавьте MFA для администраторов. Это создаёт рабочий шаблон.
Третий шаг — централизовать идентификацию. Используйте один источник истины для пользователей и устройств: Active Directory, LDAP, или решения типа Keycloak. Это исключает дублирование учётных данных, упрощает отзыв доступа и позволяет вести единый контекст для проверок.
Четвертый шаг — сегментировать workload’ы. Каждый микросервис, функция или контейнер должен работать в своей изолированной среде. Используйте механизмы облачных провайдеров: VPC, security groups, IAM на уровне функций. Рассмотрите решения типа OpenZiti, которые создают программные безопасные пути подключения без открытия портов. Цель: даже при компрометации одного компонента, злоумышленник не может перемещаться дальше без повторной проверки подлинности на каждом шаге.