Security-by-Design: как построить защищенный хостинг в режиме непрекращающихся киберугроз

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

Масштаб угроз хорошо иллюстрирует статистика. По данным StormWall, в первом полугодии 2026 года число DDoS-атак в России увеличилось на 73% по сравнению с аналогичным периодом 2025 года. Атаки становятся и мощнее: в начале 2026 года компании сталкивались с инцидентами свыше 2 Тбит/с, а пиковые значения доходили до 3,5 Тбит/с. Для сравнения, годом ранее самые крупные атаки фиксировались на заметно меньших уровнях. 

Можно было бы сказать: «купим защиту от DDoS, и всё». Но проблема глубже. Атаки становятся точечными: вместо массовых сетевых нагрузок злоумышленники всё чаще используют многоуровневые воздействия на критичные для бизнеса сервисы — например, платежные системы. Доля DDoS-атак, инициированных внутри страны, превысила 50% — это значительно усложняет их выявление и нейтрализацию.

Безопасность нельзя «прикрутить» к инфраструктуре постфактум: ее нужно закладывать в архитектуру с самого начала. Это и есть принцип Security-by-Design — о нем и рассказываем в статье.

Навигация по тексту:

• Что такое Security‑by‑Design и почему это не buzzword

• Уровень 1. Сетевая архитектура и изоляция

• Уровень 2. Защита от DDoS как часть архитектуры

• Уровень 3. IAM и Zero Trust для управления доступом

• Уровень 4. Соответствие регуляторным требованиям как часть архитектуры

• Уровень 5. Мониторинг, логирование и реагирование на инциденты

• Что меняется, когда Security-by-Design реализован правильно

Что такое Security-by-Design и почему это не buzzword

Security-by-Design — подход, при котором требования безопасности учитываются еще при проектировании системы: от сетевой архитектуры и разграничения доступа до обновлений и реагирования на инциденты. Ключевое отличие от традиционного подхода: здесь не существует «доверенного периметра» — каждый компонент, каждый запрос и каждый пользователь считаются потенциально скомпрометированными до тех пор, пока не доказано обратное.

Это созвучно концепции Zero Trust, но Security-by-Design шире: речь не только о контроле доступа, но и об архитектурных решениях — сетевой изоляции, сегментации, принципе минимальных привилегий, управлении секретами, аудите на всех уровнях.

Для хостинг-провайдера и облачной платформы это принципиально важно: атаки на облачных провайдеров несут риск деградации производительности всего облака и затрагивают всех клиентов. Конечный пользователь в такой ситуации ничего не может сделать самостоятельно — защиту должен обеспечивать сам провайдер.

Уровень 1. Сетевая архитектура и изоляция

Фундамент защищенного хостинга — правильная сетевая архитектура. Здесь важны несколько принципов.

Микросегментация вместо плоской сети

Плоская сеть, где все виртуальные машины и сервисы находятся в одном сегменте, — это приглашение к lateral movement. Если злоумышленник компрометирует один узел, он получает потенциальный доступ ко всей инфраструктуре.

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

На практике это означает разделение инфраструктуры на зоны с различными политиками безопасности: управляющая плоскость отдельно от пользовательской, production-окружения отдельно от dev/stage, разные клиенты в изолированных сетевых сегментах с явным контролем трафика между ними.

Принцип наименьших привилегий на сетевом уровне

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

Защита управляющей плоскости

Отдельного внимания заслуживает управляющая плоскость — API, консоли управления, системы оркестрации. Это наиболее критичная часть инфраструктуры: компрометация управляющей плоскости означает потерю контроля над всей платформой. Доступ к ней должен быть строго ограничен по IP, защищен MFA, и весь трафик к ней должен проходить через отдельный, жестко контролируемый канал.

Изоляция на уровне гипервизора

В мультитенантной среде изоляция между клиентами — это базовое требование. Клиентские сети должны быть изолированы друг от друга. Это требует правильной настройки гипервизора, сетевых оверлеев (VXLAN, GRE) и явного аудита всех межсетевых связей.

Уровень 2. Защита от DDoS как часть архитектуры

DDoS-защита, встроенная в архитектуру, принципиально отличается от DDoS-защиты как внешнего сервиса, подключенного «сверху».

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

По внутренней статистике ГК «Гарда», доля DDoS-атак, инициированных внутри страны, превысила 50%. Это значительно усложняет их выявление и нейтрализацию.

Security-by-Design в контексте DDoS может означать сразу несколько вещей.

Многоуровневая фильтрация с первого дня. Защита на уровнях L3/L4 (объемные атаки, TCP SYN Flood, UDP Flood) и L7 (атаки на приложения, HTTP Flood, slowloris) должна быть встроена в платформу, а не подключаться по запросу после инцидента. По итогам 2025 года TCP SYN Flood и TCP PSH/ACK Flood составили 87% всех зафиксированных атак.

Scrubbing-центры и анонс BGP. Для крупных объемных атак эффективна схема с перенаправлением трафика через центры очистки (scrubbing centers) с анонсом BGP в момент атаки. Это позволяет снижать влияние масштабных атак на доступность клиентских сервисов.

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

Rate limiting и connection limiting на уровне платформы. Ограничения по скорости и количеству соединений, встроенные в сетевой стек платформы, снижают радиус поражения при атаке даже до ее идентификации.

Уровень 3. IAM и Zero Trust для управления доступом

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

Принципы Zero Trust, примененные к хостингу и облачной платформе:

Явная аутентификация каждого запроса. Ни один запрос не считается доверенным по умолчанию, даже если он приходит из внутренней сети. Сервис-аккаунты, API-ключи, пользовательские сессии — всё проходит проверку при каждом обращении к ресурсу.

Минимальные привилегии. Каждый сервис, пользователь и сервис-аккаунт получают ровно те права, которые нужны для выполнения конкретной задачи. Не «дадим побольше, потом уберем», а «дадим минимум, расширим при необходимости».

Управление секретами. Хранение учетных данных, API-ключей и сертификатов в переменных окружения или в коде — распространенная проблема, которая при утечке репозитория или компрометации CI/CD-пайплайна немедленно открывает доступ к production-инфраструктуре. Секреты должны храниться в специализированных системах (Vault и аналоги) с ротацией и аудитом доступа.

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

Уровень 4. Соответствие регуляторным требованиям как часть архитектуры

Для российских компаний, которые обрабатывают персональные данные, обязательны требования 152-ФЗ и применимых приказов ФСТЭК и ФСБ. Ключевой момент в том, что это архитектурное требование, которое влияет на выбор инфраструктуры и средств защиты с самого начала.

Что требует 152-ФЗ на инфраструктурном уровне

Закон обязывает хранить персональные данные на серверах в России, обеспечивать их защиту в соответствии с уровнем защищенности (УЗ) и документировать организационные и технические меры. Если облачный провайдер оказывает клиентам услуги для размещения ИСПДн с выполнением части требований регулятора, он должен обеспечить применимые меры не только на уровне инфраструктуры, но и процессов. Лицензии ФСБ и ФСТЭК требуются при оказании отдельных видов деятельности, например при внедрении или администрировании средств защиты. 

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

Уровни защищенности и их практический смысл

152-ФЗ и подзаконные акты определяют четыре уровня защищенности. Чем чувствительнее данные, чем выше тип актуальных угроз для системы и чем больше субъектов ПДн, тем выше требуемый уровень. Например, обработка медицинских данных более 100 000 субъектов может требовать УЗ-2, биометрические данные или данные о судимостях — УЗ-1. Аттестат соответствия, выданный лицензиатом ФСТЭК, подтверждает, что система соответствует установленному уровню защищенности.

Архитектурные следствия

Security-by-Design в контексте 152-ФЗ означает, что требования к защите ПДн нужно учитывать на этапе проектирования ИСПДн. Если система размещается на собственной инфраструктуре, весь набор организационных и технических мер оператор реализует сам. Если в облаке — сначала нужно понять, какие меры уже обеспечивает сервис-провайдер, а какие останутся на стороне клиента. Для этого важно:

• При выборе сервис-провайдера — проверить, какие меры защиты он предоставляет «из коробки» и какие требования закрывает его инфраструктура;

• Подготовить не только модель угроз, но и комплект обязательной документации: политики и регламенты, ТЗ на систему, структурно-логическую схему и другие документы — и затем внедрить описанные процессы на практике;

• Подтвердить, что организационные и технические меры действительно работают и соответствуют требованиям регулятора; 

• При передаче обработки ПДн провайдеру — оформить необходимые договорные условия.

На стороне клиента остаются отдельные меры защиты: например, в нашем защищенном контуре клиент обеспечивает канальное шифрование для доступа, антивирус и СЗИ от НСД или сертифицированную ОС, а провайдер берет на себя межсетевой экран (МЭ), систему обнаружения вторжений (СОВ), средства доверенной загрузки (СДЗ), а также меры защиты на уровне ЦОД.

Уровень 5. Мониторинг, логирование и реагирование на инциденты

Security-by-Design предполагает, что инциденты всё равно будут происходить. Вопрос не в том, произойдут ли они, а в том, насколько быстро вы их обнаружите и насколько ограничен будет радиус поражения.

Централизованное логирование. Все события — сетевые, системные, приложения — должны агрегироваться в централизованную систему. Логи, хранящиеся только на самом скомпрометированном узле, могут оказаться недоступны при расследовании инцидента.

Метрики безопасности в реальном времени. Аномалии в объеме трафика, нетипичные паттерны авторизации, внезапный рост числа ошибок на отдельных эндпоинтах — всё это должно отображаться в дашбордах безопасности с настроенными алертами и дальнейшей эскалацией на ответственных лиц.

Заранее описанные сценарии реагирования (runbooks). Когда инцидент происходит, у команды не должно быть вопроса, что делать сначала. Изоляция скомпрометированного сегмента, уведомление клиентов, переключение трафика, сбор forensics — всё это должно быть задокументировано и отработано на учениях до того, как произошел реальный инцидент.

Immutable audit trail. Журналы аудита должны быть защищены от изменения — это требование и регуляторов (в части ИСПДн), и здравого смысла: скомпрометированный злоумышленник не должен иметь возможности удалить следы своего присутствия.

Что меняется, когда Security-by-Design реализован правильно

Разница между «безопасностью как отдельным продуктом» и «безопасностью как свойством архитектуры» проявляется не в моменты спокойствия, а в моменты атаки.

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

Для бизнеса это переводится в конкретные показатели: время обнаружения инцидента (MTTD), время восстановления (MTTR) и, в конечном счете, SLA, который провайдер готов гарантировать своим клиентам.