Сделали сайт неуязвимым для DDoS - перевели портал банка в управляемую и защищённую инфраструктуру
КОНТЕКСТ / ПРОБЛЕМА
У банка было несколько разрозненных точек:
- публичный сайт с критичной информацией для клиентов и регулятора
- корпоративный портал для сотрудников
- интранет с внутренними сервисами
Фактически это были разные среды, которые жили отдельно.
Что происходило на практике:
- обновления на сайте выкатывались вручную, без контроля версий
- часть данных дублировалась между сайтом и интранетом
- self-service сценарии (заявки, внутренние запросы) не фиксировались централизованно
- при DDoS-атаках сайт ложился, вместе с ним - доступ к критичной информации
- требования регулятора по доступности и актуальности данных контролировались вручную
В итоге:
банк не мог гарантировать доступность информации,
не видел, какие данные где используются,
и не контролировал, что именно показывается клиентам и регулятору в моменте.
ЧТО СДЕЛАЛИ
Разделили архитектуру на три уровня и связали их через единый слой данных и управления.
1. Публичный сайт вынесли в отдельный контур
- развернули публичную часть, как отдельное приложение за CDN и балансировщиком
- статический контент (регламентные страницы, раскрытие информации) вынесли в отдельное хранилище с кешированием
- динамические блоки (курсы, продукты, уведомления) подтягиваются через API
Теперь сайт не зависит напрямую от внутренних сервисов банка.
2. Ввели единый слой данных для сайта и портала
Создали централизованное хранилище сущностей:
- страницы с обязательной регуляторной информацией
- версии документов
- продуктовые карточки
- уведомления и статусы сервисов
Для каждой сущности фиксируется:
- версия
- дата публикации
- источник изменения (кто и из какого интерфейса обновил)
- статус (черновик / опубликовано / архив)
Сайт и интранет получают данные из одного источника, а не из разных баз.
3. Корпоративный портал и интранет перевели в единую контур
- авторизация через единый модуль
- роли (сотрудник, юрист, комплаенс, администратор) управляют доступом к функциям
- интерфейс редактирования данных (контент, документы, статусы сервисов) доступен только через портал
То есть любые изменения сначала фиксируются внутри, а потом публикуются наружу.
4. Self-service сценарии перевели в цифровую модель
Ввели типы заявок:
- изменение информации на сайте
- публикация регуляторного документа
- обновление продуктовых данных
Каждая заявка:
- создаётся в портале
- проходит этапы согласования (например: юрист → комплаенс → публикация)
- привязана к конкретной сущности (страница, документ, продукт)
Вся история изменений теперь сохраняется.
5. Защита от DDoS
- сайт поставили за CDN с фильтрацией трафика
- включили rate limiting и блокировку аномальных запросов
- критичный контент кешируется и доступен даже при недоступности backend
- внутренние сервисы (портал, интранет) изолированы и не доступны извне
Даже при атаке сайт остаётся доступным, а внутренние сервисы не затрагиваются.
ЧТО АВТОМАТИЗИРОВАЛИ
- публикация регуляторной информации: из заявки → в утверждённую версию → автоматически на сайт
- контроль актуальности данных: система отслеживает дату последнего обновления и сигнализирует о просрочке
- маршрутизация заявок: вместо переписки - фиксированные этапы согласования
- управление доступами: роли определяют, кто может менять, утверждать и публиковать данные
- логирование изменений: каждое изменение фиксируется с пользователем и временем
Ручные обновления через “попросили веб-мастера” исчезли.
ЧТО ЭТО ИЗМЕНИЛО В БИЗНЕСЕ
- стало видно, какая версия информации сейчас опубликована на сайте
- можно отследить, кто именно утвердил конкретный документ
- регуляторные данные больше не теряются и не дублируются
- сайт продолжает работать даже при нагрузке или атаке
- внутренние сервисы не падают вместе с публичным контуром
Раньше это был набор независимых точек.
Теперь - управляемая среда с контролем на уровне данных и публикации.
РЕЗУЛЬТАТ
Банк получил:
- единый источник данных для сайта и внутреннего портала
- контролируемую публикацию критичной информации
- устойчивость к DDoS без влияния на внутренние сервисы
- прозрачную историю изменений для регулятора
Главное - появилась управляемость:
что опубликовано, кем, когда и на каком основании.
ИНСАЙТ
Пока сайт банка живёт отдельно от внутренних данных - любая атака или ошибка превращается в риск от регулятора и для репутации.
