Прочитал — и кивал процентов восемьдесят текста. У меня история была не про ВКС, а про сборку ИБ-каркаса для одного финтеха пару лет назад, но узор тот же самый: «давайте просто запустим Х» → выясняется, что Х тянет за собой связку из трёх десятков НПА → выясняется, что половина инфраструктуры под это не подходит → выясняется, что проект минимум на квартал. У вас тут это ВКС, у меня была DLP/NGFW-обвязка, но болит одинаково. :_)
Про ВКС, кстати, отдельная боль. У нас её внутри тоже разворачивали примерно в тех же условиях, и пришли к похожему выводу: облака исключаются, импортные сервисы исключаются (даже если очень хочется), внутри банка остаётся выбор из «свой кластер» или «отечественный сервис в свою инфру». После того как в 22–23 году всё, что начиналось на Zoom / Teams / WebEx, начало схлопываться, многие банки сидели на этой задаче по полгода — потому что одно дело «развернуть TrueConf», и совсем другое — развернуть его так, чтобы оно не подсветилось красным на ближайшем аудите по ГОСТ Р 57580.2. Сертифицированное СКЗИ, журналирование, разграничение, привязка к AD, проброс в DMZ, каскад между внутренней и внешней частью — и да, это то самое «открыть на NGFW не порт, а ещё один контур». Не назвал бы это «избыточностью», если честно, это плата за то, что банк не имеет права уронить сервис, через который завтра могут идти переговоры с регулятором или показ прод-данных на демо.
И тут же сразу про общее ощущение от того, как у нас сейчас регуляторика двигается — потому что без этого контекста ваш текст вообще не читается. ЦБ с 2018–19 годов планомерно перетягивает на себя всё, что касается ИБ финансовых организаций, и темп этот только нарастает. 683-П / 757-П / 802-П — это уже не «методические рекомендации», это операционные требования с проверками и санкциями; ГОСТ Р 57580 фактически стал отраслевой нормой и спрашивают по нему в полный рост, без скидок. Плюс отдельно идёт КИИ — а под 187-ФЗ попадает почти каждый крупный банк автоматически. На моей памяти за последние лет пять регуляторная нагрузка в финансах не падала ни разу, только росла, и каждый новый Указание/Положение добавляет очередной слой к архитектуре. Отсюда и эффект, который вы описываете: даже «простой» сервис вроде ВКС у нас — это не «поставить и забыть», а полноценный мини-проект с моделью угроз, аттестацией и регламентом. В западных банках значительная часть этой истории решается аутсорсом в гипероблако под SOC2/ISO27001, и они над нашими разговорами про «выбрать между двумя вариантами VPN-схемы» искренне посмеиваются — у нас этого варианта просто нет.
Раз уж тема пошла, поделюсь, как у меня сложился аналогичный каркас под финтех. Может пригодится кому-то для сравнения. ;)
Объект. Типичный цифровой банк: онлайн-онбординг, KYC, эквайринг, скоринг, контакт-центр, мобильное приложение, своя разработка бэка. Главная особенность — вся ценность в данных и в коде, никаких хранилищ с наличными и никаких касс. Поэтому внутренние угрозы для такого банка критичнее, чем для классического: один сотрудник с правильным доступом может натворить дел, сопоставимых с ограблением хранилища. Из этого вытекает весь остальной дизайн.
Угрозы. Не буду заходить с «общего ТОП-100», лучше так, как у нас в МУ зафиксировано — двенадцать штук, и они вполне типовые для отрасли:
Массовая выгрузка ПДн через АРМ (флешка, личная почта, мессенджер) — самый частый бытовой сценарий, причём как с умыслом, так и по неосторожности.
Утечка через корпоративную почту во внешние домены — «переслал на личный gmail чтобы поработать дома», классика жанра.
Утечка исходного кода и API-ключей из dev-сегмента — push в публичный git, архивы по почте, секреты в тестовых дампах. Особенно весело, если в test-БД лежат реальные ПДн под предлогом «нагрузочного тестирования».
Компрометация привилегированной учётки (админ БД, DevOps) — кража пароля, перехват токена, сессия без MFA, sudo без записи.
Цепочка через подрядчика — взломали внешнего исполнителя, у которого VPN в твой контур. Больно, потому что его гигиена ИБ — за пределами твоего контроля.
Таргетированный фишинг на сотрудника КЦ или на руководителя — внешний нарушитель получает «инсайдера» без необходимости его вербовать.
Шифровальщик в пользовательском сегменте — вложение из почты, USB, заражённый сайт; самое неприятное — если доберётся до сетевых шар или до бэкап-сервера через подмонтированную папку.
DDoS на web/mobile-фронт — для онлайн-банка часы простоя = прямые убытки + жалобы в ЦБ + штрафы по № 161-ФЗ за нарушение непрерывности расчётов.
Атака на VPN-шлюз — эксплуатация уязвимости, password spray по учёткам удалёнки, перехват OTP через фишинг.
Утечка через печать — да, бумага, но на сетевом принтере у вас регулярно зависает 50-страничный отчёт по топ-клиентам, и кто-то его рано или поздно заберёт.
Утечка через бэкап — самый «жирный» канал, потому что в бэкапе нет масок, нет rate-limit'ов, нет журналирования доступа к отдельным записям. Иногда забывают зашифровать — и это праздник.
MITM на канале к регулятору / НСПК — низкая вероятность, очень высокий impact; обязательная для реестра по № 161-ФЗ и Положению № 719-П.
Под каждую — связка «канал × актив × мера × НПА × ответственный». Без этой матрицы реестр живёт отдельно от инфраструктуры и при первом же аудите рассыпается, потому что аудитор первым делом спрашивает «покажите, как угроза №7 закрывается технически и кто за это отвечает». На бумаге «политикой ИБ» — не считается.
Нормативка. Тут я подписываюсь под вашим текстом полностью. То, что в обычной отрасли называется «комплаенс на бумаге», в банке — прямые техтребования. У меня в проекте шорт-лист получился такой: ст. 26 № 395-1 (банковская тайна), № 152-ФЗ (ПДн), № 98-ФЗ (КТ), № 149-ФЗ (об информации), № 63-ФЗ (об ЭП), № 187-ФЗ (КИИ), № 161-ФЗ (НПС), № 115-ФЗ (ПОД/ФТ), № 218-ФЗ (кредитные истории); из подзаконки — ПП РФ № 1119, № 127, № 1085; по линии ЦБ — Положения № 683-П, № 716-П, № 719-П, № 757-П, № 802-П, плюс ГОСТ Р 57580.1 и 57580.2 (последний — про методику оценки соответствия, которая вам ещё понадобится после внедрения); приказы ФСТЭК № 17, 21, 31, БДУ и методика УБИ; приказы ФСБ № 378 и регламенты по СКЗИ; стандарты ИСО/МЭК 27001/27002, исторически СТО БР ИББС; отраслевое — PCI DSS и правила НСПК. Из этого списка ничего не выкинуть — у каждого пункта есть прямой выхлоп на конкретное техтребование (классы СКЗИ, наличие IPS, обязательность DLP, аттестация, форма уведомления регулятора и т.д.). Хотел бы поспорить, но не с чем.
Категории информации. Когда раскладываешь — получается 10–11 категорий: БТ, ПДн, биометрические ПДн, КТ, инсайдерская, НПС, ПОД/ФТ, кредитные истории, КИИ, служебная. Матрица «категория ↔ НПА ↔ мера» — самое скучное упражнение в проекте, согласен, но без неё ты потом не объяснишь аудитору, почему для биометрии стоит СКЗИ КС3, а для внутренней переписки хватает КС2. И, что хуже, не объяснишь сам себе через год, когда придёт время пересматривать.
Каркас защиты — что я в итоге собрал и сейчас эксплуатирую. Меры старался делать адресные, под конкретные угрозы из реестра, а не «всё подряд из брошюр вендоров». Получилось так: DLP с агентом на каждом АРМ + сетевой контроль каналов почты/web/мессенджеров; аналитический слой над DLP с UBA и графом связей (отдельный дашборд под расследование, отдельный — под группу риска, в которую автоматом попадают увольняющиеся и привилегированные); SIEM, в который сливается вообще всё подряд (потом разберёмся, чего нам не хватало, и так далее); PAM с записью привилегированных сессий и JIT-выдачей прав на тикет; EDR на эндпоинтах; NGFW с микросегментацией и default deny на всех направлениях; IPS поверх NGFW с сигнатурами из БДУ ФСТЭК; WAF перед публичными API; антифрод; бэкап с обязательной offline-копией для критичных систем; MFA везде, где есть доступ к prod и к данным ограниченного доступа, для админов — аппаратный токен; ViPNet КС3 для удалёнки и каналов к ЦБ / СМЭВ / БКИ / НСПК. Принципы доступа стандартные: least privilege, need-to-know, separation of duties (админ БД не видит данные в открытом виде, офицер ИБ не меняет данные в АБС), 4-eyes на критичные операции, RBAC с атрибутами.
Сегментация. Тот самый ползунок «удобно ↔ безопасно», который у вас в статье выкручен в безопасность, у меня вылился в 10 сегментов: Интернет, удалёнка через VPN, внешние интеграции (ЦБ/ФинЦЕРТ/СМЭВ/БКИ/НСПК — отдельным контуром, не через общий internet-канал), DMZ, внешний NGFW, внутренний NGFW, пользовательский сегмент, серверный PROD, изолированная разработка (деплой в PROD только через bastion с PAM), сегмент управления ИБ. Всё между ними — через NGFW с явным правилом и логированием. Карту с расположением сегментов и СЗИ прикладываю отдельным файлом — это финальная версия того, что у меня сейчас в эксплуатации, причём дочищенная руками после автогенерации, потому что автогенераторы сегментации до сих пор делают сюрпризы (один раз молча выкинули правило на интеграцию с БКИ — отдельный квест был).
Что я бы пощупал по NGFW в первую очередь, если кому-то делать аналогичное с нуля. Прежде чем хвататься за новые правила — стоит просто пройтись по матрице «откуда → куда» и убедиться, что то, что в принципе не должно ходить, действительно не ходит. По опыту, дыры всплывают именно здесь:
Default deny на всех интерфейсах. Банально, но в legacy-сетях часто стоит «разрешить из user в prod по любому tcp» под предлогом «потом разберёмся». Никогда не разбираются.
User-сегмент → PROD-БД напрямую — не должно быть никогда. Только через прикладные серверы (АБС, CRM, антифрод) по конкретным app-портам. Если АРМ оператора резолвит IP боевой БД клиентов — это уже флаг.
DEV → PROD — полностью запрещён. Деплой только через bastion + CI/CD, никаких «временных правил для тестов» с TTL «до пятницы», который потом живёт три года.
PROD → Интернет — закрыт. Если приложению нужен внешний API (НСПК, БКИ, СМЭВ) — только через явно прописанный destination IP/порт, через ViPNet, и только тот микросервис, которому это реально нужно.
User → Интернет только через прокси с URL-фильтром (pastebin / file-sharing / webmail / анонимайзеры — в block; иначе DLP можно и не разворачивать, всё уйдёт в обход).
Между АРМ внутри user-сегмента — peer-to-peer закрыт. SMB, RDP, WMI между рабочими станциями обычному пользователю не нужны, а шифровальщику открывают горизонтальное движение по всему офису.
Сегмент управления ИБ — асимметричный. Логи туда «втекают» отовсюду, а исходящий трафик из него — строго в AD, к обновлениям СЗИ и наружу к вендорским репозиториям по whitelist. Если из этого сегмента кто-то лезет в интернет «по любому» — это сам по себе инцидент.
На внешнем NGFW: GeoIP-блок по странам, с которыми банк не работает; включённые IPS-сигнатуры из БДУ ФСТЭК; Anti-DDoS на фронт; TLS-инспекция везде, кроме каналов регулятора (где это запрещено политикой ЦБ).
Пара показательных правил, которые в такой архитектуре прописываются явно (а не получаются «само собой» из default deny):
ID Src Dst Service Action Log01 USER-KC PROD-CRM-APP tcp/443 ALLOW yes02 USER-ANY PROD-DB-ANY any DENY yes → alert SIEM03 DEV-ANY PROD-ANY any DENY yes → alert SIEM04 PROD-APP EXT-NSPK-IP tcp/443 ALLOW yes (via ViPNet)05 ANY ANY any DENY yes (default deny)
Правило №2 здесь не «лишнее» — это explicit deny с логированием, чтобы любая попытка из user-сегмента дотянуться до боевой БД сразу падала в SIEM как инцидент, а не молча отбрасывалась дефолтом и терялась в фоне. То же самое с №3 — «капкан» на разработчика или подрядчика, который попробует зайти в прод напрямую вместо bastion. По опыту, такие явные deny-правила с алертом ловят на удивление много интересного — от честного «ой, забыл что нельзя» до вполне сознательных попыток.
Документация. Это та часть, которая, по-моему, лучше всего иллюстрирует ваш тезис про «четыре месяца вместо одного». У меня нормативный пакет разложился на 5 этапов: основания и приказы → аудит и модель угроз → политики верхнего уровня → регламенты под СЗИ → согласия и договоры-поручения → журналы и отчётность. Параллельно с этапами 2–3 идёт внедрение техники. После — оценка соответствия по 57580.2 и независимый аудит ПДн. PDCA: пересмотр модели угроз минимум раз в год и обязательно после любого инцидента. Когда говорят «банк живёт регламентами», вот это оно — у меня даже на «обновить версию агента DLP на парке АРМ» есть отдельный регламент со сроками, ответственными и формой уведомления внутреннего ИБ.
Этапы внедрения и эксплуатации, по документам. Если тот же пакет разложить не по типам, а по фазам жизненного цикла — получается шесть подходов. Этап 0, основания: приказы о назначении ответственного за ПДн, о комиссии по ИБ, о категорировании информации, об утверждении модели угроз. Этап 1, аудит и модель угроз: акт аудита, модель угроз и нарушителя, перечень ИС, перечень защищаемой информации, уведомление в Роскомнадзор. Этап 2, политики верхнего уровня: политика ИБ, политика защиты ПДн, политика паролей, политика доступа, политика реагирования на инциденты, политика резервного копирования. Этап 3, регламенты под СЗИ: инструкции по эксплуатации каждого СЗИ, регламент управления учётками, регламент работы с СКЗИ, регламент управления инцидентами, регламент изменения правил NGFW. Этап 4, работа с субъектами: формы согласий на обработку ПДн (включая биометрию и трансграничную передачу), договоры-поручения с подрядчиками, NDA с сотрудниками. Этап 5, эксплуатация: журналы учёта СКЗИ и носителей ПДн, журнал инцидентов ИБ, журналы доступа, формы уведомлений регулятору по № 187-ФЗ и Положению № 683-П. Выглядит как «много», но без любого из этих документов аудитор честно подвешивает соответствующее техсредство — и формально оказывается прав.
К теме статьи — в целом подписываюсь под каждым словом. В банке практически не существует «простого» ИТ-проекта. Любой контур, который касается клиентских данных или платёжного трафика, моментально утягивает за собой полный комплект: сегментацию, СКЗИ из реестра ФСБ, DLP, аналитику, регламенты, согласия, журналы. Зато когда такой каркас уже стоит — на нём гораздо легче навешивать новые сервисы, в том числе ту же ВКС из вашего примера: потому что половина требований к ним уже закрыта инфраструктурой. У меня запуск нового внутреннего сервиса после полной пересборки занимает недели, а не месяцы — ради этого, в общем-то, всё и затевалось. И когда от регулятора в очередной раз прилетает новая редакция Положения, у нас это вызывает уже не панику, а пожимание плечами и пометку в роадмапе на ближайший квартал. Не самое плохое состояние, кстати.
P.S. Прикладываю свою карту сети с размещением СЗИ и обзорный пакет по этому проекту (со сводной матрицей «угроза → НПА → документ → СЗИ»). Если кто-то делает аналогичное под финтех — может пригодиться как образец структуры, не как готовое решение, специфика всегда своя. :)
Ждем статью про планирование бэкапа сисколлами, чего уж мелочиться)
Прочитал — и кивал процентов восемьдесят текста. У меня история была не про ВКС, а про сборку ИБ-каркаса для одного финтеха пару лет назад, но узор тот же самый: «давайте просто запустим Х» → выясняется, что Х тянет за собой связку из трёх десятков НПА → выясняется, что половина инфраструктуры под это не подходит → выясняется, что проект минимум на квартал. У вас тут это ВКС, у меня была DLP/NGFW-обвязка, но болит одинаково. :_)
Про ВКС, кстати, отдельная боль. У нас её внутри тоже разворачивали примерно в тех же условиях, и пришли к похожему выводу: облака исключаются, импортные сервисы исключаются (даже если очень хочется), внутри банка остаётся выбор из «свой кластер» или «отечественный сервис в свою инфру». После того как в 22–23 году всё, что начиналось на Zoom / Teams / WebEx, начало схлопываться, многие банки сидели на этой задаче по полгода — потому что одно дело «развернуть TrueConf», и совсем другое — развернуть его так, чтобы оно не подсветилось красным на ближайшем аудите по ГОСТ Р 57580.2. Сертифицированное СКЗИ, журналирование, разграничение, привязка к AD, проброс в DMZ, каскад между внутренней и внешней частью — и да, это то самое «открыть на NGFW не порт, а ещё один контур». Не назвал бы это «избыточностью», если честно, это плата за то, что банк не имеет права уронить сервис, через который завтра могут идти переговоры с регулятором или показ прод-данных на демо.
И тут же сразу про общее ощущение от того, как у нас сейчас регуляторика двигается — потому что без этого контекста ваш текст вообще не читается. ЦБ с 2018–19 годов планомерно перетягивает на себя всё, что касается ИБ финансовых организаций, и темп этот только нарастает. 683-П / 757-П / 802-П — это уже не «методические рекомендации», это операционные требования с проверками и санкциями; ГОСТ Р 57580 фактически стал отраслевой нормой и спрашивают по нему в полный рост, без скидок. Плюс отдельно идёт КИИ — а под 187-ФЗ попадает почти каждый крупный банк автоматически. На моей памяти за последние лет пять регуляторная нагрузка в финансах не падала ни разу, только росла, и каждый новый Указание/Положение добавляет очередной слой к архитектуре. Отсюда и эффект, который вы описываете: даже «простой» сервис вроде ВКС у нас — это не «поставить и забыть», а полноценный мини-проект с моделью угроз, аттестацией и регламентом. В западных банках значительная часть этой истории решается аутсорсом в гипероблако под SOC2/ISO27001, и они над нашими разговорами про «выбрать между двумя вариантами VPN-схемы» искренне посмеиваются — у нас этого варианта просто нет.
Раз уж тема пошла, поделюсь, как у меня сложился аналогичный каркас под финтех. Может пригодится кому-то для сравнения. ;)
Объект. Типичный цифровой банк: онлайн-онбординг, KYC, эквайринг, скоринг, контакт-центр, мобильное приложение, своя разработка бэка. Главная особенность — вся ценность в данных и в коде, никаких хранилищ с наличными и никаких касс. Поэтому внутренние угрозы для такого банка критичнее, чем для классического: один сотрудник с правильным доступом может натворить дел, сопоставимых с ограблением хранилища. Из этого вытекает весь остальной дизайн.
Угрозы. Не буду заходить с «общего ТОП-100», лучше так, как у нас в МУ зафиксировано — двенадцать штук, и они вполне типовые для отрасли:
Массовая выгрузка ПДн через АРМ (флешка, личная почта, мессенджер) — самый частый бытовой сценарий, причём как с умыслом, так и по неосторожности.
Утечка через корпоративную почту во внешние домены — «переслал на личный gmail чтобы поработать дома», классика жанра.
Утечка исходного кода и API-ключей из dev-сегмента — push в публичный git, архивы по почте, секреты в тестовых дампах. Особенно весело, если в test-БД лежат реальные ПДн под предлогом «нагрузочного тестирования».
Компрометация привилегированной учётки (админ БД, DevOps) — кража пароля, перехват токена, сессия без MFA, sudo без записи.
Цепочка через подрядчика — взломали внешнего исполнителя, у которого VPN в твой контур. Больно, потому что его гигиена ИБ — за пределами твоего контроля.
Таргетированный фишинг на сотрудника КЦ или на руководителя — внешний нарушитель получает «инсайдера» без необходимости его вербовать.
Шифровальщик в пользовательском сегменте — вложение из почты, USB, заражённый сайт; самое неприятное — если доберётся до сетевых шар или до бэкап-сервера через подмонтированную папку.
DDoS на web/mobile-фронт — для онлайн-банка часы простоя = прямые убытки + жалобы в ЦБ + штрафы по № 161-ФЗ за нарушение непрерывности расчётов.
Атака на VPN-шлюз — эксплуатация уязвимости, password spray по учёткам удалёнки, перехват OTP через фишинг.
Утечка через печать — да, бумага, но на сетевом принтере у вас регулярно зависает 50-страничный отчёт по топ-клиентам, и кто-то его рано или поздно заберёт.
Утечка через бэкап — самый «жирный» канал, потому что в бэкапе нет масок, нет rate-limit'ов, нет журналирования доступа к отдельным записям. Иногда забывают зашифровать — и это праздник.
MITM на канале к регулятору / НСПК — низкая вероятность, очень высокий impact; обязательная для реестра по № 161-ФЗ и Положению № 719-П.
Под каждую — связка «канал × актив × мера × НПА × ответственный». Без этой матрицы реестр живёт отдельно от инфраструктуры и при первом же аудите рассыпается, потому что аудитор первым делом спрашивает «покажите, как угроза №7 закрывается технически и кто за это отвечает». На бумаге «политикой ИБ» — не считается.
Нормативка. Тут я подписываюсь под вашим текстом полностью. То, что в обычной отрасли называется «комплаенс на бумаге», в банке — прямые техтребования. У меня в проекте шорт-лист получился такой: ст. 26 № 395-1 (банковская тайна), № 152-ФЗ (ПДн), № 98-ФЗ (КТ), № 149-ФЗ (об информации), № 63-ФЗ (об ЭП), № 187-ФЗ (КИИ), № 161-ФЗ (НПС), № 115-ФЗ (ПОД/ФТ), № 218-ФЗ (кредитные истории); из подзаконки — ПП РФ № 1119, № 127, № 1085; по линии ЦБ — Положения № 683-П, № 716-П, № 719-П, № 757-П, № 802-П, плюс ГОСТ Р 57580.1 и 57580.2 (последний — про методику оценки соответствия, которая вам ещё понадобится после внедрения); приказы ФСТЭК № 17, 21, 31, БДУ и методика УБИ; приказы ФСБ № 378 и регламенты по СКЗИ; стандарты ИСО/МЭК 27001/27002, исторически СТО БР ИББС; отраслевое — PCI DSS и правила НСПК. Из этого списка ничего не выкинуть — у каждого пункта есть прямой выхлоп на конкретное техтребование (классы СКЗИ, наличие IPS, обязательность DLP, аттестация, форма уведомления регулятора и т.д.). Хотел бы поспорить, но не с чем.
Категории информации. Когда раскладываешь — получается 10–11 категорий: БТ, ПДн, биометрические ПДн, КТ, инсайдерская, НПС, ПОД/ФТ, кредитные истории, КИИ, служебная. Матрица «категория ↔ НПА ↔ мера» — самое скучное упражнение в проекте, согласен, но без неё ты потом не объяснишь аудитору, почему для биометрии стоит СКЗИ КС3, а для внутренней переписки хватает КС2. И, что хуже, не объяснишь сам себе через год, когда придёт время пересматривать.
Каркас защиты — что я в итоге собрал и сейчас эксплуатирую. Меры старался делать адресные, под конкретные угрозы из реестра, а не «всё подряд из брошюр вендоров». Получилось так: DLP с агентом на каждом АРМ + сетевой контроль каналов почты/web/мессенджеров; аналитический слой над DLP с UBA и графом связей (отдельный дашборд под расследование, отдельный — под группу риска, в которую автоматом попадают увольняющиеся и привилегированные); SIEM, в который сливается вообще всё подряд (потом разберёмся, чего нам не хватало, и так далее); PAM с записью привилегированных сессий и JIT-выдачей прав на тикет; EDR на эндпоинтах; NGFW с микросегментацией и default deny на всех направлениях; IPS поверх NGFW с сигнатурами из БДУ ФСТЭК; WAF перед публичными API; антифрод; бэкап с обязательной offline-копией для критичных систем; MFA везде, где есть доступ к prod и к данным ограниченного доступа, для админов — аппаратный токен; ViPNet КС3 для удалёнки и каналов к ЦБ / СМЭВ / БКИ / НСПК. Принципы доступа стандартные: least privilege, need-to-know, separation of duties (админ БД не видит данные в открытом виде, офицер ИБ не меняет данные в АБС), 4-eyes на критичные операции, RBAC с атрибутами.
Сегментация. Тот самый ползунок «удобно ↔ безопасно», который у вас в статье выкручен в безопасность, у меня вылился в 10 сегментов: Интернет, удалёнка через VPN, внешние интеграции (ЦБ/ФинЦЕРТ/СМЭВ/БКИ/НСПК — отдельным контуром, не через общий internet-канал), DMZ, внешний NGFW, внутренний NGFW, пользовательский сегмент, серверный PROD, изолированная разработка (деплой в PROD только через bastion с PAM), сегмент управления ИБ. Всё между ними — через NGFW с явным правилом и логированием. Карту с расположением сегментов и СЗИ прикладываю отдельным файлом — это финальная версия того, что у меня сейчас в эксплуатации, причём дочищенная руками после автогенерации, потому что автогенераторы сегментации до сих пор делают сюрпризы (один раз молча выкинули правило на интеграцию с БКИ — отдельный квест был).
Что я бы пощупал по NGFW в первую очередь, если кому-то делать аналогичное с нуля. Прежде чем хвататься за новые правила — стоит просто пройтись по матрице «откуда → куда» и убедиться, что то, что в принципе не должно ходить, действительно не ходит. По опыту, дыры всплывают именно здесь:
Default deny на всех интерфейсах. Банально, но в legacy-сетях часто стоит «разрешить из user в prod по любому tcp» под предлогом «потом разберёмся». Никогда не разбираются.
User-сегмент → PROD-БД напрямую — не должно быть никогда. Только через прикладные серверы (АБС, CRM, антифрод) по конкретным app-портам. Если АРМ оператора резолвит IP боевой БД клиентов — это уже флаг.
DEV → PROD — полностью запрещён. Деплой только через bastion + CI/CD, никаких «временных правил для тестов» с TTL «до пятницы», который потом живёт три года.
PROD → Интернет — закрыт. Если приложению нужен внешний API (НСПК, БКИ, СМЭВ) — только через явно прописанный destination IP/порт, через ViPNet, и только тот микросервис, которому это реально нужно.
User → Интернет только через прокси с URL-фильтром (pastebin / file-sharing / webmail / анонимайзеры — в block; иначе DLP можно и не разворачивать, всё уйдёт в обход).
Между АРМ внутри user-сегмента — peer-to-peer закрыт. SMB, RDP, WMI между рабочими станциями обычному пользователю не нужны, а шифровальщику открывают горизонтальное движение по всему офису.
Сегмент управления ИБ — асимметричный. Логи туда «втекают» отовсюду, а исходящий трафик из него — строго в AD, к обновлениям СЗИ и наружу к вендорским репозиториям по whitelist. Если из этого сегмента кто-то лезет в интернет «по любому» — это сам по себе инцидент.
На внешнем NGFW: GeoIP-блок по странам, с которыми банк не работает; включённые IPS-сигнатуры из БДУ ФСТЭК; Anti-DDoS на фронт; TLS-инспекция везде, кроме каналов регулятора (где это запрещено политикой ЦБ).
Пара показательных правил, которые в такой архитектуре прописываются явно (а не получаются «само собой» из default deny):
01 USER-KC PROD-CRM-APP tcp/443 ALLOW yes02 USER-ANY PROD-DB-ANY any DENY yes → alert SIEM03 DEV-ANY PROD-ANY any DENY yes → alert SIEM04 PROD-APP EXT-NSPK-IP tcp/443 ALLOW yes (via ViPNet)05 ANY ANY any DENY yes (default deny)Правило №2 здесь не «лишнее» — это explicit deny с логированием, чтобы любая попытка из user-сегмента дотянуться до боевой БД сразу падала в SIEM как инцидент, а не молча отбрасывалась дефолтом и терялась в фоне. То же самое с №3 — «капкан» на разработчика или подрядчика, который попробует зайти в прод напрямую вместо bastion. По опыту, такие явные deny-правила с алертом ловят на удивление много интересного — от честного «ой, забыл что нельзя» до вполне сознательных попыток.
Документация. Это та часть, которая, по-моему, лучше всего иллюстрирует ваш тезис про «четыре месяца вместо одного». У меня нормативный пакет разложился на 5 этапов: основания и приказы → аудит и модель угроз → политики верхнего уровня → регламенты под СЗИ → согласия и договоры-поручения → журналы и отчётность. Параллельно с этапами 2–3 идёт внедрение техники. После — оценка соответствия по 57580.2 и независимый аудит ПДн. PDCA: пересмотр модели угроз минимум раз в год и обязательно после любого инцидента. Когда говорят «банк живёт регламентами», вот это оно — у меня даже на «обновить версию агента DLP на парке АРМ» есть отдельный регламент со сроками, ответственными и формой уведомления внутреннего ИБ.
Этапы внедрения и эксплуатации, по документам. Если тот же пакет разложить не по типам, а по фазам жизненного цикла — получается шесть подходов. Этап 0, основания: приказы о назначении ответственного за ПДн, о комиссии по ИБ, о категорировании информации, об утверждении модели угроз. Этап 1, аудит и модель угроз: акт аудита, модель угроз и нарушителя, перечень ИС, перечень защищаемой информации, уведомление в Роскомнадзор. Этап 2, политики верхнего уровня: политика ИБ, политика защиты ПДн, политика паролей, политика доступа, политика реагирования на инциденты, политика резервного копирования. Этап 3, регламенты под СЗИ: инструкции по эксплуатации каждого СЗИ, регламент управления учётками, регламент работы с СКЗИ, регламент управления инцидентами, регламент изменения правил NGFW. Этап 4, работа с субъектами: формы согласий на обработку ПДн (включая биометрию и трансграничную передачу), договоры-поручения с подрядчиками, NDA с сотрудниками. Этап 5, эксплуатация: журналы учёта СКЗИ и носителей ПДн, журнал инцидентов ИБ, журналы доступа, формы уведомлений регулятору по № 187-ФЗ и Положению № 683-П. Выглядит как «много», но без любого из этих документов аудитор честно подвешивает соответствующее техсредство — и формально оказывается прав.
К теме статьи — в целом подписываюсь под каждым словом. В банке практически не существует «простого» ИТ-проекта. Любой контур, который касается клиентских данных или платёжного трафика, моментально утягивает за собой полный комплект: сегментацию, СКЗИ из реестра ФСБ, DLP, аналитику, регламенты, согласия, журналы. Зато когда такой каркас уже стоит — на нём гораздо легче навешивать новые сервисы, в том числе ту же ВКС из вашего примера: потому что половина требований к ним уже закрыта инфраструктурой. У меня запуск нового внутреннего сервиса после полной пересборки занимает недели, а не месяцы — ради этого, в общем-то, всё и затевалось. И когда от регулятора в очередной раз прилетает новая редакция Положения, у нас это вызывает уже не панику, а пожимание плечами и пометку в роадмапе на ближайший квартал. Не самое плохое состояние, кстати.
P.S. Прикладываю свою карту сети с размещением СЗИ и обзорный пакет по этому проекту (со сводной матрицей «угроза → НПА → документ → СЗИ»). Если кто-то делает аналогичное под финтех — может пригодиться как образец структуры, не как готовое решение, специфика всегда своя. :)
https://viewer.diagrams.net/?tags={}&lightbox=1&highlight=0000ff&edit=\_blank&layers=1&nav=1&title=Карта\_сети\_Аврора\_с\_СЗИ\_готово.drawio.xml&dark=auto#R<mxfile><diagram name%3D"Сеть Авроры" id%3D"aurora-net">7VvbcqNIEv0aRdgP6uAueERC6nZEe1Zh927v7hsSJYloBFqEbGse5tun7pUFyLZkQc%2FMTncEhqwLReY5SWYWGtiT7cvnMt5t7osEZQPLSF4GdjSwLNMf2fgPkRyZJHB9JliXacI7KcFj%2BiviQoNLD2mC9lrHqiiyKt3pwmWR52hZabK4LItnvduqyPS77uI1aggel3HWlH5Pk2rDpY5hqIYvKF1vKvF8vGEbi85csN%2FESfEMRPZ0YE%2FKoqjY2fZlgjKiPKEXNm52olUurER59Z4ByGUjUNJ4YjUFF%2B2LQ7nkvfLhU7rLUcVbqqNQDcqTkGgYXy2zeL9PlwN7vKm2GRaY%2BLQsDnmCyN0NfLWvyuKH1KElJZMiK0o6oe0ko8WS9MXLKY%2F%2FJgM%2FuRhAXPAfLBganwwrEJLohU%2FOro7wao7KdIsqVHIhx05crlElHiwut3GaV9IYGMWowIPKI%2B5aoiyu0iddVzGH01r240OxJuIj6LAr8MR7MPO8oHcyODN8AQvOC9vUrIdP2IziCixNiaiF261dpRW200n7KitW6KXS7abbJS9y3HO8SrOsJoqzdJ0T4%2BPZiZrHT6isUkydkDds0yQhtxk%2Fb9IKPe5iCqln7Cga6FgVecXJb%2Frimi%2FSlNZ7irMDX%2FYADwtCchwbA9zFZ0eLSyx2adJLFzT5tAmfmGIsPkb0KGazvHhLVpgv9jt1a%2Fxs6AUosQmYDXADDrfuM%2FAZtseFfJoaAoTHa4MYgMWrVs%2BHKbGFZOvrpsdjsRslBsK%2BaYcoj4tDcsJgACEQDJi3K5f8b2O0R%2F%2FV7Gu12tPysop31Fbp%2Fe9QiIbhnk4R4g6ms3uh84h2fLamfwkwfHqkZg0ZVFx6big5l8gbL0oxww1Aw5iDhsOIYYWBCR%2FxTScCTxN6nAJs%2BWIG3HMCcDbls%2FGBMwFfOER28%2FRbg8WQW9eXTpss0JlB328MD8TdowaFbDDEB8xx4ePcintjRDKT8QVcQpagSRbH0rni6FzxrsKVEm2L6l1OUjkr82x2JDHyV8tWdix9tFi1sONt73cuW0avsCW0KR8cemQMoXLmPTlbGJfGnDkMPCHrMFU0YwTTJowAIUN%2Bzoark5m6NZ%2FBUmPZMrh83Dfugi6Ax2OOLlG3MJCNvDbUGcg3fP%2Bnoy4AJua%2B2G8AxlVQaXXogQ3cOkOIB%2Fr77R6S9zHJ5NhoHMwOcI8R6OZqsNSGMPxT3x5G%2FKFgh8Csw141RWCGGe%2FWL7aDTpwqialJSNkxvlf%2BEi1bverCdx23mXHYNcTbvSL%2Bl8%2Bz77j95vwX9Ax0g0HCRA9tSettE%2B5hXqXDKCoeyXQTazAe4ZPv4Qxe3kW4dXY31%2Fr88%2BHrkM4KaSFjGXXPa2LWb2LWez0OMIOrYBYmuN1BVqa3DcjiNsdNTkIWwp7%2B%2B6lQBn5LhNDkSALhf81%2FafO4Ei02gLmEP4iyOeRDkb6x%2Fo4IUQUCmVvVsjYZTftirAHmt8FsbD0zENhOQX8Ry3eM6pGOai%2FoBNbJ9tfO3fBqZbW74cRbeK7XwLQ1%2BJmBR3T%2F3yZAv6MF1uV9sUhJxcSYlXgylCfQG4bzO3z8HFfomVZ5ZMN9nBKdP6BMl3%2F59m3%2BOGzkd1MBWVmb8OGoB4SxtSeLmJfFy7FjFJr2687Vvk5FAhTZ%2Fg4I3ggIZPptNXwY9Jo8RLgl2JlapB9OtrQ6hA%2BAZgAvZ%2BpeEcYRsLYhSwIeKAPMWLUjQav4kFX0LD8yGQghrgdZ73zIyhD3Y5A97FH5BygLvO05O07RZiq%2FZyWBkKIlGAG5BXIvmJmB%2FqGeBpGjCG9hIMGSOZZOcYlI%2BBo%2B%2B7eRIRIpUDbAY%2B1QyEOew9VLdDA8EMEDrA8rmtls7JeH07U2E3AWsgpEK6p8BiN4xSd6Pm20mm11RhizkFfLsI3C8pwFTt5Jml%2BRq2ZLwfuNGp57ndfLriySzrnqIj9x2rjqWwvb%2B6NFOY0I3QBMbRTCeVHvXEYa84d%2FRO2sCEDxIzRhgDN5uIeXqpt6f71Zd5fot%2FSYX7Giwbfau4yl16dXrt3LF1lwLYhz6g%2FCFMfXX%2BMzdClq1PiuudfUMyWDTjiZoKeuKYlMTMpRGyUDb2TH76NkfxR8lUmAkYZ6v2qSRqVdFRXbt68Y6EYAsGMAZwhkGe5RkComsVcEpXlLYelzWn2NFxq3MZpnk0inRe31Z7aQmL3gIpDEK5fQylEHeIUZeLSpYLYh3QPzUc0XJ9yUE4Tl3UYN7%2BFyVWLCxvsqLfK%2BWVov1F6Jpdv19syszOgiK6t%2FNVAVu4sys7MZxzrMGlxj%2FBrXB7LINZQFfJ9DFSdx91iTw0e0PJRpdby9CAfya4Azsh3vOmWiatt5bh4no7gdBY7nGk7DWf%2Fc3Dz6Ou%2Ba4ravW9bXLTtyrmLZp3RP3dXf1q29mrXvfmSuZugfPPjg9XDVfY73AKIemV0JEUW16b608Q6n338ho1YIG2kJhpZ7sBBhAuKLKUBL61dA%2BhvBDpuRy%2BPdVEt9Qi1Qmoda4zR60PKEePnjsOs96jA6QCDiSDv%2FI1T9w7YrfobKJmx%2BGMo3sT%2FwYei7lWJdqhT4BVMvX%2Ba2KUvtnvahK%2FsDAPq%2FUpRzqaK0Lzg6JhrfouxDH96l%2BpDbqD04nY9%2Fjf5ufYw%2Bgo8uyNSmE7ET04dC%2FD%2BDQkS5uw%2BFBH8GhfBaYx%2F6EGWX8xWiNhQv1kYS7zcyHn%2FHm0jmXjDUlqE3X4UoiraNa1O2KBW0BOpJ%2BqRCUiba7%2BK8NXZf4IB2TR9vuGR3JiF8RuLTYRKXP27Ul0504%2BspLm%2BGwzWijXwI2xGzbNMi%2F29v6X2N9unK9eLGJAkWGWMaJjtxbtlf0moJoWnzXT8n4HO25o%2Bw4miLTQgZn7MH15WBxZqKeoLsxfG22lf760H2pAV7MsrF8b7cWPlr2sQA1nj91zYfsx7PcIfGJ8vk%2BQRPcofOafvWfsgnuhSr1Z6npRAA5%2F1cD5kX5zVCmV2mNZ2gAFYnNSTI75Tkr6nYFlFtT5ZU4mmptgvW4kv101xmUPUDZ3v6Ow%3D%3D<%2Fdiagram><%2Fmxfile>