При создании и сопровождении веб-ресурсов мы закладываем защиту на каждом уровне: в архитектуре приложения, в серверной логике, в канале передачи данных и в инфраструктуре, на которой система работает. Меры не сводятся к одному средству. Они дополняют друг друга, чтобы сбой или обход одного рубежа не открывал доступ к данным и функциям системы.
Решение строится на разделении контуров. Пользовательский интерфейс, серверная логика и хранилища данных работают отдельно и общаются только по явно разрешённым маршрутам. Наружу публикуется только то, что необходимо для работы сайта. Базы данных, кэш и служебные интерфейсы во внешнюю сеть не выводятся.
Ниже — контур, который мы применяем в проектах на Next.js, NestJS, Docker и Redis. При размещении в контуре заказчика он стыкуется с уже принятыми у вас средствами: межсетевым экранированием, WAF, средствами криптографической защиты, журналированием и регламентами доступа.
Пользовательская часть на Next.js и серверное приложение на NestJS разделены. Браузер не обращается к базе данных и к служебным хранилищам напрямую. Все операции проходят через серверную логику, где проверяются права, состав запроса и допустимость действия.
Для компонентов задаются отдельные сетевые зоны:
- публичная зона — сайт и точки входа, доступные пользователям;
- зона приложений — серверная логика и фоновые задачи;
- зона данных — база данных, Redis и резервные копии.
Между зонами разрешён только необходимый обмен. Redis, база данных и панели администрирования в интернет не публикуются. Административный доступ организуется через защищённый контур заказчика: выделенная сеть, VPN или бастион, по регламенту вашей службы безопасности.
Обмен с пользователем и между компонентами системы идёт по защищённому протоколу TLS актуальных версий. Открытая передача учётных данных и содержимого запросов исключается.
На стороне веб-сервера включаются заголовки безопасности: политика содержимого страницы (CSP), запрет встраивания сайта во внешние фреймы, ограничение определения типа содержимого, политика обращения к сторонним источникам. Для сессий используются cookie с признаками HttpOnly, Secure и SameSite, чтобы идентификатор сессии нельзя было прочитать скриптом страницы и он не уходил на сторонние сайты.
Если регламент заказчика требует сертифицированные средства криптографической защиты или отечественные алгоритмы на периметре, прикладной контур к ним подключается: TLS терминируется на вашем шлюзе, приложение работает за ним во внутреннем сегменте.
Вход в закрытые разделы выполняется по учётной записи. Пароли не хранятся в открытом виде: сохраняется только стойкий необратимый отпечаток. Сессия ограничена по времени. Для служебных операций предусмотрена повторная проверка прав на каждый запрос, а не только в момент входа.
Полномочия строятся по ролям. Пользователь, редактор, администратор и сервисная учётная запись получают только те действия, которые нужны их функции. Массовые и чувствительные операции — выгрузка, удаление, смена прав, публикация — выделяются отдельно и при необходимости подтверждаются дополнительным шагом или журналируются как события безопасности.
Число попыток входа и частота запросов к формам авторизации, обратной связи и публичным API ограничиваются. Это снижает риск подбора пароля и перегрузки сервиса. Повторяющиеся неуспешные попытки фиксируются в журнале.
Сервер принимает только те поля, которые описаны для конкретной операции. Лишние и непредусмотренные параметры отбрасываются. Формат, длина и состав значений проверяются до того, как данные попадут в базу или в кэш.
Запросы к базе формируются через параметризованный доступ, без подстановки пользовательского ввода в текст запроса. Вывод на страницу проходит через механизмы экранирования фреймворка, чтобы введённый текст не исполнялся как код в браузере других пользователей.
Для форм применяется защита от подделки межсайтового запроса. Загрузка файлов, если она есть в системе, ограничена по типу, размеру и месту хранения: файл не исполняется на сервере и не кладётся в каталог с кодом приложения.
Секреты — пароли баз, ключи сессий, токены интеграций — не помещаются в исходный код и не попадают в образы контейнеров. Они задаются в защищённом хранилище окружения и выдаются приложению при запуске. Доступ к ним есть только у контура эксплуатации.
Каждый компонент поставляется отдельным контейнером со своим минимальным набором программ. В образ не входят средства разработки, лишние пакеты и учётные данные.
Контейнеры приложений запускаются от непривилегированного пользователя, без лишних прав на хост. Сети контейнеров разделены: публичный сервис не видит сеть данных целиком, а видит только те адреса, которые ему назначены. Проброс портов наружу делается только для точки входа сайта.
Для образов фиксируются версии. Базовые образы и зависимости обновляются по регламенту, а не остаются неизменными на годы. Сборка воспроизводима: в промышленный контур попадает собранный и проверенный образ, а не произвольная копия с рабочей машины разработчика.
Среды разработки, проверки и промышленной эксплуатации разделены. Данные промышленного контура в среды разработки не копируются. Если для отладки нужен похожий набор данных, он обезличивается.
Redis используется как внутреннее хранилище: кэш, сессии, очереди фоновых задач. Наружу он не публикуется и доступен только из сети приложений.
Подключение защищено паролем или списками доступа. Опасные служебные команды, которые позволяют очистить хранилище или изменить конфигурацию из приложения, отключаются. Для кэша задаётся предельный объём памяти и политика вытеснения, чтобы рост данных не остановил сервис.
В Redis не складывается единственная копия сведений, потеря которых недопустима. Сессии и кэш восстанавливаемы. Постоянные данные живут в базе и попадают в резервное копирование. Каналы между приложением и Redis остаются внутри закрытого сегмента.
Состав собираемых сведений определяется задачей сайта. Лишние персональные данные не запрашиваются и не хранятся «впрок». Срок хранения и порядок удаления согласуются с заказчиком и с назначением системы.
Резервные копии создаются по расписанию, хранятся отдельно от рабочего контура и проверяются на возможность восстановления. Доступ к копиям ограничен так же, как доступ к промышленным данным.
Передача данных между компонентами шифруется. Доступ сотрудников исполнителя к промышленному контуру выдаётся адресно, на время работ, и снимается по их окончании. Постоянных общих учётных записей для команды разработки на боевом контуре нет.
Если система обрабатывает персональные данные, организационные и технические меры согласуются с вашей моделью угроз, политикой обработки и уровнем защищённости, установленным для этого ресурса. Размещение выполняется в сегменте, который определяет заказчик, в том числе на площадке госоргана.
Фиксируются вход и выход, отказ в доступе, смена прав, изменение критичных настроек, выгрузки и действия администраторов. В журнал попадает, кто выполнил действие, когда и над каким объектом. Пароли, содержимое сессий и полные массивы персональных данных в журналы не пишутся.
Журналы приложения готовы к передаче в систему мониторинга заказчика. Формат и состав событий согласуются с вашей SIEM или регламентом учёта, чтобы события сайта попадали в общий контур наблюдения, а не оставались только на сервере приложения.
Срок хранения журналов задаётся вашим регламентом.
Зависимости и базовые образы проверяются на известные уязвимости до выкладки. Исправления безопасности включаются в плановые обновления, критичные — вне очереди, по согласованному окну работ.
Изменения попадают в промышленный контур через сборку и проверку, с сохранением предыдущей рабочей версии для быстрого возврата. Правка «на сервере вручную» в промышленной среде не используется.
Код проходит просмотр до включения в основную ветку. Доступ к репозиторию, реестру образов и средам разделён: разработчик не совмещает в одном лице право выкладки и право бесконтрольного доступа к данным.
Прикладная защита рассчитана на работу внутри вашего периметра, а не вместо него. По требованиям технического задания подключаются:
- размещение в выделенном сегменте и публикация через ваш обратный прокси или WAF;
- терминация TLS на сертифицированном шлюзе, если это требует модель угроз;
- передача журналов в вашу систему мониторинга;
- административный доступ только из сети управления;
- ограничение интеграций белым списком адресов и учётных данных, выданных заказчиком.
Состав мер фиксируется в техническом задании и в регламенте эксплуатации конкретного ресурса: что защищается силами приложения, что — средствами площадки, кто отвечает за учётные записи, резервные копии и реагирование на инцидент.
