ООО «Бегет»: как закрыть требования 152-ФЗ для облачной инфраструктуры и не сломать эксплуатацию

Бизнес-цель понятная: подтвердить соответствие так, чтобы это можно было предъявить и клиентам, и проверяющим как пройденную аттестацию выделенного контура ИСПДн, а не как устное обещание на встрече.

Сложность в том, что задача не сводилась к выбору «какое средство поставить». Систему защиты надо было спроектировать сразу под несколько ограничений:

• закрыть 152-ФЗ и приказ ФСТЭК № 21;
• выдержать аттестацию;
• остаться удобной в администрировании;
• не мешать масштабированию;
• не требовать избыточного бюджета;
• четко разграничить ответственность между провайдером и его клиентами.

Защита корпоративной ИСПДн и защита облачной инфраструктуры — это разные задачи, даже когда обе опираются на один и тот же 152-ФЗ и тот же приказ ФСТЭК № 21.

В корпоративной системе контур обычно стабилен: фиксированный набор сервисов, понятный круг пользователей, предсказуемые процессы. У провайдера логика другая. Среда обязана масштабироваться, принимать новых клиентов и держать управляемость при скачках нагрузки.

Спроектируешь слишком жестко — получишь формально корректную, но неживую систему: каждое расширение тянет за собой ручную перенастройку, любое изменение инфраструктуры воспринимается как риск для соответствия, а администраторы начинают искать обходные пути. Сделаешь слишком мягко — поплывут аттестация и доказуемость. В инфраструктурном бизнесе плохи оба варианта. Рабочая точка посередине: не перегрузить контур защитой и не оставить критичные участки без контроля.

Начали с анализа существующей среды виртуализации и процессов администрирования. Зафиксировали, какие компоненты участвуют в обработке персональных данных, где проходят границы защищаемого контура, что критично для эксплуатации и масштабирования и где лежат зоны ответственности между провайдером и клиентами.

Для облака это решающий шаг. Ошибешься с границей, и контур либо раздувается и дорожает, либо теряет участки, которые потом всплывут на аттестации и в работе.

Дальше модель угроз. В облачном проекте она нужна не для отчетности, а как инженерная база. Через нее мы связали требования закона с реальной архитектурой: какие сценарии несанкционированного доступа актуальны, какие узлы требуют усиленного контроля, что закрывается организационно, а где без технических средств не обойтись.

Это и помогло уйти от избыточности — меры подбирались под конкретную инфраструктуру, а не под абстрактный список.

Главный этап. Здесь надо было удержать сразу все: требования 152-ФЗ и ФСТЭК № 21, особенности виртуализированной среды, эксплуатационную применимость, бюджет, масштабирование и будущую аттестацию.

Отдельно проработали то, что обычно и ломает эксплуатацию:

• управление административными доступами;
• журналирование действий;
• порядок внесения изменений;
• сопровождение и администрирование СЗИ;
• встраивание мер в уже работающие процессы.

Главный критерий был в том, чтобы защиту можно было масштабировать без пересмотра всей архитектуры каждый раз.

Даже верно подобранные средства не дают устойчивого результата, если не описаны роли и регламенты. Поэтому отдельным блоком собрали организационный контур:

• правила администрирования;
• порядок эксплуатации средств защиты;
• управление доступом;
• распределение ответственности;
• регламенты по инцидентам и изменениям;
• эксплуатационную документацию.

Эффект практический. Система перестает зависеть от «героизма» отдельных админов: новые сотрудники быстрее входят в контур, изменения проходят предсказуемо, ответственность между сторонами не размывается.

Финал — подготовка и прохождение аттестации выделенного контура ИСПДн. На каждом этапе команда Б-152 сопровождала клиента: согласовывали решения, объясняли последствия, разбирали спорные места и переводили требования ИБ на язык инфраструктурного бизнеса.

По итогам проекта Бегет получил:

• контур ИСПДн, подготовленный к аттестации;
• систему защиты под реальную инфраструктуру, а не по типовой схеме с лишними закупками;
• формализованные процессы эксплуатации и администрирования;
• более прозрачное разграничение ответственности между провайдером и клиентами;
• возможность развивать инфраструктуру дальше, не переписывая архитектуру безопасности под каждое изменение.

Разграничение ответственности здесь — не деталь, а часть коммерческой зрелости: меньше конфликтов при подключении новых заказчиков. И, что было принципиально, меры защиты встроились в существующие процессы без заметного удара по производительности и управляемости.

Когда СЗИ проектируется от архитектуры и бизнес-целей, а не от списка средств, она поддерживает рост.

При этом обе крайности вредны. Провайдер, который уходит от вопросов про ПДн и аттестацию, — уже сигнал риска для клиента. Защитить можно и небольшую систему, и облачный контур. Вопрос в том, насколько точно определены угрозы и насколько вменяемо выстроена эксплуатация.

После такого проекта у клиента остается не только комплект документов и пройденная аттестация. Остается рабочая модель: как администрировать, как масштабировать, как подключать клиентов, как делить ответственность и как отвечать на вопросы о безопасности фактами.