Когда в компании впервые звучит фраза: «Нам нужно определить класс защищённости», в переговорной обычно разворачивается небольшой спектакль в трёх действиях. Специалист по информационной безопасности открывает несколько десятков вкладок с приказами, методиками и разъяснениями регуляторов. DevOps-инженер незаметно пытается вспомнить, сколько серверов работают на версиях операционных систем, которые давно сняты с поддержки, и какие именно сервисы никто не обновлял последние три года, потому что "трогать страшно - вдруг перестанет работать". Бизнес, как правило, задаёт самый прагматичный вопрос:

А можно всё это сделать подешевле? И желательно без остановки сервисов?!

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

При этом существует ещё одно распространённое заблуждение. Многие воспринимают К1, К2, К3 и К4 как исключительно бюрократическую классификацию, интересную только специалистам по информационной безопасности и аудиторам. В реальности же классы защищённости напрямую влияют на архитектуру инфраструктуры, выбор технологий, процессы сопровождения и даже на то, как выглядит ежедневная работа инженеров эксплуатации. Они определяют, какие журналы необходимо хранить, как организовывать удалённый доступ, каким образом обновлять системы и какие технические средства защиты придётся использовать.

Именно поэтому эта статья не будет пересказом приказов ФСТЭК. Она будет попыткой показать, как устроена жизнь внутри защищённых контуров глазами людей, которым потом приходится всё это проектировать, эксплуатировать и поддерживать в работоспособном состоянии.

Откуда вообще появились К1-К4

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

Основными источниками требований являются:

  • Федеральный закон №152-ФЗ;

  • приказы ФСТЭК России №17 и №21;

  • методические документы ФСТЭК;

  • государственные стандарты в области защиты информации;

  • документы, посвящённые моделированию угроз безопасности.

На практике уровни К1-К4 чаще всего встречаются в контексте:

  • государственных информационных систем;

  • информационных систем персональных данных;

  • автоматизированных систем;

  • объектов критической информационной инфраструктуры;

  • защищённых контуров предприятий.

Самая важная мысль заключается в том, что класс защищённости отражает не стоимость системы и не её технологическую "крутость". Он отражает возможные последствия нарушения её безопасности.

Условно это выглядит следующим образом:

Класс Уровень требований Практический смысл
К1 Максимальный Компрометация может привести к крайне тяжёлым последствиям
К2 Высокий Система критична для организации или государства
К3 Средний Типичный уровень для многих корпоративных систем
К4 Базовый Минимально допустимый уровень защиты

На бумаге таблица выглядит достаточно просто. Однако именно здесь начинается первое столкновение бизнеса и эксплуатации с реальностью. Потому что классы защищённости определяют не только набор технических средств, но и уровень зрелости процессов внутри организации.

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

И здесь появляется, пожалуй, самый парадоксальный тезис всей отрасли.

Защищённой считается не система сама по себе.

Защищённой считается система, соответствие которой подтверждено документально.

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

Как на практике определяют уровень защищённости

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

Обычно он выглядит примерно так:

Бизнес-процесс
        ↓
Определение обрабатываемых данных
        ↓
Категорирование системы
        ↓
Модель угроз
        ↓
Выбор мер защиты
        ↓
Проектирование контура
        ↓
Внедрение
        ↓
Испытания
        ↓
Аттестация
        ↓
Эксплуатация

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

При определении уровня защищённости обычно оценивают:

  • объём и тип данных;

  • последствия их утечки;

  • последствия изменения информации;

  • последствия уничтожения данных;

  • наличие подключения к интернету;

  • способы удалённого администрирования;

  • количество пользователей;

  • наличие интеграций;

  • участие подрядчиков;

  • влияние инцидента на бизнес-процессы.

Особенно часто подобная оценка требуется при работе с персональными данными.

И именно здесь многие компании неожиданно обнаруживают себя операторами персональных данных.

Потому что персональные данные - это не только паспортные сведения и медицинские карты.

Это могут быть:

  • ФИО клиентов;

  • номера телефонов;

  • адреса электронной почты;

  • кадровые базы;

  • CRM-системы;

  • данные авторизации пользователей;

  • бухгалтерские системы.

Иногда руководители искренне удивляются, услышав, что обычная Excel-таблица на сетевом ресурсе тоже может подпадать под требования законодательства.

Но регулятору совершенно безразлично, насколько современной выглядит инфраструктура.

Если данные есть - значит их необходимо защищать.

И именно с этого момента начинается очень интересная история о том, почему современный Kubernetes-кластер и требования регуляторов иногда оказываются двумя мирами, которым приходится учиться сосуществовать.

Именно здесь начинается самая интересная часть истории. Потому что до этого момента защищённый контур можно было представить как несколько стоек с серверами, отдельный сегмент сети и набор регламентов, аккуратно сложенных в шкафу рядом с кабинетом специалиста по информационной безопасности. Многие нормативные документы действительно формировались в эпоху, когда типичная архитектура выглядела достаточно предсказуемо: физические серверы, несколько сетевых сегментов, домен Active Directory, резервное копирование на ленточные библиотеки и строго определённое количество администраторов.

Но затем индустрия придумала Kubernetes.

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

Представьте себе классический взгляд на защищённый контур.

Есть сеть.

Есть сервер.

Есть установленное программное обеспечение.

Есть ответственный администратор.

Есть утверждённая схема взаимодействия компонентов.

Выглядит это примерно так:

Пользователь
      ↓
Балансировщик
      ↓
Сервер приложений
      ↓
База данных

Теперь посмотрим на современную платформенную архитектуру:

Internet
    ↓
WAF
    ↓
VPN
    ↓
Bastion
    ↓
Ingress Controller
    ↓
Kubernetes
    ↓
Deployment
    ↓
Pod
    ↓
Service Mesh
    ↓
PostgreSQL
    ↓
SIEM
    ↓
Backup

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

Кто является владельцем контейнера?

Как контролируется состав образов?

Каким образом проверяется отсутствие запрещённого программного обеспечения?

Как обеспечивается регистрация событий безопасности внутри эфемерных Pod?

Как подтверждается неизменность компонентов?

Как контролируются обновления?

Где заканчивается зона ответственности Kubernetes и начинается зона ответственности команды сопровождения?

Именно поэтому Kubernetes внутри аттестуемых систем никогда не бывает "просто Kubernetes". Он неизбежно превращается в Kubernetes, адаптированный под требования информационной безопасности.

И здесь начинается мир компромиссов.

Например, обычная команда разработки может воспринимать контейнерный образ как расходный материал. Образ собрали, отправили в Registry, развернули, забыли.

В защищённом контуре этот же процесс выглядит значительно сложнее:

GitLab CI
      ↓
Static Analysis
      ↓
Dependency Scan
      ↓
SBOM Generation
      ↓
Trivy
      ↓
Cosign
      ↓
Harbor
      ↓
Admission Controller
      ↓
Kubernetes
      ↓
Falco
      ↓
SIEM

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

Кто собрал образ?

Какие библиотеки в него входят?

Были ли обнаружены критические уязвимости?

Подписан ли артефакт?

Кто разрешил публикацию?

Кто допустил запуск?

Можно ли доказать, что именно этот образ находился в эксплуатации?

Особенно забавно наблюдать реакцию команд, впервые сталкивающихся с подобными требованиями.

Если в обычной инфраструктуре команда спокойно пишет:

image: nginx:latest

то внутри защищённого контура такая запись способна вызвать небольшую волну коллективного ужаса.

Потому что слово latest фактически означает:

Мы не знаем, что именно будет запущено завтра.

А информационная безопасность очень не любит ситуации, в которых никто не знает, что именно работает в системе.

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

Например:

image: harbor.company.local/nginx@sha256:9d43...

Или:

image: harbor.company.local/app:v2.3.17

с обязательной подписью артефакта.

Например, при помощи Cosign:

cosign sign \
    harbor.company.local/app:v2.3.17

Проверка подписи может выполняться автоматически:

cosign verify \
    harbor.company.local/app:v2.3.17

После чего Admission Controller принимает решение о допуске контейнера к запуску.

Фактически получается очень интересная трансформация. Если раньше эксплуатация отвечала на вопрос:

Работает ли приложение?

то теперь приходится отвечать сразу на несколько дополнительных вопросов:

  • известно ли происхождение образа;

  • соответствует ли он утверждённой политике;

  • содержит ли он критические уязвимости;

  • подтверждена ли его неизменность.

Именно поэтому DevSecOps в защищённых контурах перестаёт быть модным словом из презентаций и становится необходимостью.

Но контейнеры - это только вершина айсберга.

Настоящая боль начинается тогда, когда речь заходит о доступе администраторов.

Потому что именно здесь встречаются две философии.

Современный DevOps говорит:

Автоматизируй всё. Доступ должен быть быстрым. Инженер должен иметь возможность оперативно устранить проблему.

Информационная безопасность отвечает:

Отлично. А кто именно устранил проблему? Когда? На основании какого запроса? Что именно было изменено? Где журналы?

Именно поэтому в защищённых системах практически никогда не существует прямого доступа к критичным узлам.

Типичная схема выглядит следующим образом:

Администратор
      ↓
VPN
      ↓
Bastion Host
      ↓
PAM
      ↓
Целевая система

Даже конфигурация SSH начинает выглядеть иначе.

Например:

Host bastion
    HostName bastion.company.local
    User admin
    IdentityFile ~/.ssh/id_ed25519
    ForwardAgent no

Подключение к производственному серверу происходит уже через промежуточный узел.

Причём этот узел обычно оказывается одним из самых тщательно контролируемых компонентов инфраструктуры.

На нём включается журналирование.

Настраивается многофакторная аутентификация.

Контролируются действия пользователей.

Ограничиваются временные окна доступа.

В ряде организаций даже записываются терминальные сессии.

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

Потому что одна из самых неприятных фраз, которые можно услышать во время расследования, звучит удивительно просто:

Мы не знаем, кто это сделал.

А вторая выглядит ещё хуже:

Мы знаем, что это произошло, но не можем доказать, каким образом.

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

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

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

До этого момента может сложиться впечатление, что защищённый контур - это в первую очередь история про ограничения. Нельзя использовать публичные Registry. Нельзя подключаться напрямую к серверам. Нельзя разворачивать контейнеры без проверки. Нельзя использовать общие учётные записи. Нельзя просто открыть доступ подрядчику "на пять минут". И действительно, значительная часть жизни инженеров в таких системах строится вокруг различных "нельзя". Однако если посмотреть глубже, становится очевидно, что все эти ограничения преследуют одну цель - сделать работу инфраструктуры воспроизводимой и предсказуемой.

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

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

Причём речь идёт не только о классических системных журналах Linux.

В зрелом защищённом контуре журналироваться должны события разных уровней.

Например:

Операционная система
        ↓
Средства аутентификации
        ↓
Приложения
        ↓
Базы данных
        ↓
Сетевое оборудование
        ↓
Средства защиты
        ↓
Kubernetes
        ↓
CI/CD

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

Например, в Kubernetes Pod может существовать всего несколько минут.

Сегодня он есть.

Через пять минут его заменили.

Через час о его существовании уже никто не помнит.

Но если именно внутри этого контейнера произошёл инцидент, необходимо иметь возможность восстановить картину произошедшего.

Именно поэтому журналы не должны жить внутри контейнеров.

Они должны централизованно собираться и храниться.

Типичная схема выглядит следующим образом:

Pod
 ↓
Fluent Bit
 ↓
Loki
 ↓
SIEM
 ↓
Долговременное хранение

Или:

Application
      ↓
Syslog
      ↓
Collector
      ↓
SIEM

Причём SIEM в защищённой инфраструктуре перестаёт быть "дорогой коробкой, которую купили по требованию ИБ".

Она становится одним из основных инструментов эксплуатации.

Именно туда приходят события:

  • неудачных попыток входа;

  • повышения привилегий;

  • изменения критичных файлов;

  • запуска подозрительных процессов;

  • срабатывания средств защиты;

  • изменений конфигурации;

  • действий администраторов.

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

-w /etc/passwd -p wa -k identity

-w /etc/shadow -p wa -k identity

-w /etc/sudoers -p wa -k privilege

Проверка правил:

auditctl -l

Поиск событий:

ausearch -k privilege

Для инженера эксплуатации это означает одну очень важную вещь. Если кто-то изменил файл sudoers, доказать сам факт изменения будет значительно проще.

Но журналы событий - лишь одна сторона вопроса.

Не менее интересная история связана с резервным копированием.

Существует старая инфраструктурная шутка:

Резервная копия существует только тогда, когда её удалось восстановить.

Именно в защищённых системах эта шутка превращается в очень неприятную правду.

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

Backup Job
     ↓
SUCCESS

Все довольны.

Отчёты зелёные.

Руководство спокойно.

Но затем происходит отказ оборудования.

И внезапно выясняется, что никто никогда не проверял восстановление.

Архив повреждён.

Часть данных отсутствует.

Документация не соответствует реальности.

Ответственный сотрудник давно уволился.

Именно поэтому зрелый процесс выглядит иначе:

Создание резервной копии
        ↓
Контроль успешности
        ↓
Тестовое восстановление
        ↓
Проверка целостности
        ↓
Документирование результатов
        ↓
Регулярное повторение процедуры

В Kubernetes это может выглядеть следующим образом:

Velero
    ↓
Object Storage
    ↓
Restore Cluster
    ↓
Проверка приложений

Например, запуск резервного копирования:

velero backup create \
    daily-backup \
    --include-namespaces prod

Проверка восстановления:

velero restore create \
    --from-backup daily-backup

Именно на этом этапе многие организации впервые понимают, что безопасность - это не только защита от злоумышленников.

Это ещё и способность пережить собственные ошибки.

А иногда именно собственные ошибки оказываются самым вероятным источником инцидентов.

Отдельной категорией риска традиционно становятся подрядчики.

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

Потому что реальность редко выглядит идеально.

Руководство представляет её так:

Подрядчик
      ↓
Согласование
      ↓
Временный доступ
      ↓
Контроль действий
      ↓
Закрытие доступа

Однако настоящая жизнь иногда выглядит значительно менее торжественно.

Примерно так:

Подрядчик
      ↓
Ноутбук с Windows Server 2008
      ↓
Учётная запись Administrator
      ↓
"Я только посмотрю"

И именно здесь начинает работать вся система процессов, которая на первый взгляд кажется избыточной.

Доступы должны выдаваться адресно.

Срок действия должен быть ограничен.

Все действия должны журналироваться.

Неиспользуемые учётные записи должны удаляться.

Общие учётные записи должны исключаться.

Например, аудит использования sudo можно настроить следующим образом:

Defaults logfile="/var/log/sudo.log"

Defaults log_input

Defaults log_output

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

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

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

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

Именно поэтому закрытый контур нельзя описать простой формулой:

Интернет отключили
       ↓
Безопасность достигнута

Настоящий защищённый контур выглядит значительно сложнее:

Изоляция
      ↓
Контроль каналов связи
      ↓
Контроль изменений
      ↓
Контроль подрядчиков
      ↓
Журналирование
      ↓
Резервирование
      ↓
Проверка восстановления
      ↓
Регулярный аудит
      ↓
Постоянная эксплуатация

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

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

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

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

Например, очень распространённой оказывается проблема синхронизации времени.

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

Типичная картина выглядит следующим образом:

Firewall      12:01:05
SIEM          12:01:52
Kubernetes    12:00:41
PostgreSQL    12:02:14
Bastion       12:01:08

После серьёзного инцидента начинается своеобразная археология.

Какое событие произошло первым?

Когда именно злоумышленник получил доступ?

Что являлось причиной, а что следствием?

Именно поэтому синхронизация времени относится к числу базовых требований зрелой инфраструктуры.

Например:

timedatectl status

Результат должен выглядеть примерно так:

System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Использование Chrony в корпоративных средах давно стало своеобразным стандартом:

server ntp.company.local iburst

makestep 1.0 3

driftfile /var/lib/chrony/drift

Проверка источников времени:

chronyc sources

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

Ещё одна категория проблем связана с управлением учётными записями.

Практически в каждой организации существует легендарная учётная запись, происхождение которой никто уже не может объяснить.

Например:

svc_backup_old

Создана: 2018 год
Владелец: неизвестен
Назначение: "не трогать"
Используется: "вроде бы нет"
Удалить: "а вдруг всё сломается"

Подобные артефакты встречаются удивительно часто.

Они появляются в результате:

  • срочных внедрений;

  • временных интеграций;

  • аварийных изменений;

  • работы подрядчиков;

  • смены сотрудников.

Накапливаясь годами, они превращаются в серьёзный риск.

Именно поэтому зрелый процесс управления доступом выглядит значительно менее романтично, чем хотелось бы:

Создание учётной записи
        ↓
Согласование
        ↓
Назначение прав
        ↓
Регулярный пересмотр
        ↓
Контроль использования
        ↓
Отзыв доступа
        ↓
Удаление

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

Очень похожая ситуация возникает с сегментацией сети.

На архитектурных схемах всё обычно выглядит идеально.

Например:

Users
  ↓
DMZ
  ↓
Application Zone
  ↓
Database Zone
  ↓
Management Zone

Каждый сегмент имеет чётко определённое назначение.

Доступы ограничены.

Маршруты контролируются.

Политики безопасности документированы.

Однако через несколько лет эксплуатации начинают появляться исключения.

Сначала временное правило:

Нужно открыть доступ только на время внедрения.

Потом ещё одно:

Подрядчикам необходимо срочно подключиться.

Затем возникает интеграция с новым сервисом.

Через некоторое время выясняется, что схема фактически выглядит следующим образом:

DMZ
 ↕
Application
 ↕
Database
 ↕
Management
 ↕
"Временное правило №17"
 ↕
"Временное правило №24"
 ↕
"Неизвестное исключение"

Именно поэтому аудит сетевых взаимодействий должен выполняться регулярно.

В Kubernetes эта проблема приобретает дополнительные измерения.

Платформа по умолчанию предполагает достаточно свободное взаимодействие между компонентами. Если не внедрять дополнительные ограничения, Pod'ы могут общаться друг с другом значительно шире, чем требуется бизнесу.

Именно поэтому всё чаще используются NetworkPolicy.

Например:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy

metadata:
  name: backend-policy

spec:
  podSelector:
    matchLabels:
      app: backend

  policyTypes:
    - Ingress

  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

Подобная политика означает очень важную вещь.

Не любой компонент кластера может обращаться к backend.

Только тот, кому это действительно необходимо.

Точно такой же подход постепенно распространяется и на запуск контейнеров.

Ещё несколько лет назад большинство инженеров спокойно использовали привилегированные контейнеры.

Например:

securityContext:
  privileged: true

Работает?

Да.

Удобно?

Безусловно.

Совместимо с современными подходами к безопасности?

Совсем не обязательно.

Поэтому всё чаще применяются Pod Security Standards.

Например:

securityContext:
  runAsNonRoot: true

  allowPrivilegeEscalation: false

  readOnlyRootFilesystem: true

На практике подобные ограничения сначала вызывают раздражение.

Приходится пересматривать старые контейнеры.

Исправлять Dockerfile.

Убирать привычные костыли.

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

Именно в этот момент приходит очень важное понимание.

Высокий уровень защищённости редко достигается за счёт какого-то одного выдающегося средства защиты.

Практически никогда не существует волшебной коробки, которая решает все проблемы.

Безопасность представляет собой совокупность множества небольших решений:

  • журналирования;

  • контроля доступа;

  • сегментации;

  • резервного копирования;

  • проверки восстановления;

  • управления изменениями;

  • контроля поставок программного обеспечения;

  • мониторинга;

  • регулярного пересмотра настроек.

Каждое из них само по себе может показаться незначительным.

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

Именно поэтому настоящая зрелость защищённого контура определяется не количеством сертификатов на стене и не толщиной папки с организационно-распорядительными документами.

Она определяется тем, насколько организация способна ответить на несколько очень простых вопросов.

Что произошло?

Когда это произошло?

Кто это сделал?

Почему это стало возможным?

И что необходимо изменить, чтобы подобное не повторилось снова?

Чем выше класс защищённости, тем меньше ответ на эти вопросы зависит от памяти конкретного администратора, случайно сохранившего старые заметки в личном блокноте.

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

Именно в этот момент возникает вопрос, который редко задают вслух, но который волнует практически всех инженеров, впервые сталкивающихся с требованиями К1-К4.

Когда всё это заканчивается?

Когда получен аттестат соответствия?

Когда подписаны все акты?

Когда комиссия завершила работу?

Когда последняя папка с организационно-распорядительной документацией отправилась в шкаф под замок?

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

Проблема заключается в том, что именно после получения аттестата эта самая нормальная жизнь только начинается.

Почему аттестация - это не конец проекта

Существует очень опасное заблуждение, которое регулярно встречается даже в достаточно крупных организациях.

Оно звучит примерно так:

Сейчас пройдём аттестацию, а потом будем просто поддерживать систему.

На практике всё происходит совершенно иначе.

На следующий день после получения аттестата жизнь инфраструктуры продолжается.

Разработчики выпускают новую версию приложения.

Вендор публикует критическое обновление безопасности.

В компанию приходит новый сотрудник.

Подрядчик просит доступ для сопровождения.

Заканчивается срок действия сертификата.

Появляется новая интеграция.

Бизнес запускает очередной проект.

Каждое из этих событий потенциально влияет на защищённый контур.

Поэтому жизненный цикл системы выглядит вовсе не так:

Проект
    ↓
Аттестация
    ↓
Конец

А значительно ближе к следующей модели:

Проектирование
       ↓
Внедрение
       ↓
Испытания
       ↓
Аттестация
       ↓
Эксплуатация
       ↓
Изменения
       ↓
Контроль
       ↓
Переоценка рисков
       ↓
Новая аттестация

Фактически защищённость становится непрерывным процессом.

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

Например, изменение инфраструктуры перестаёт быть ночным приключением формата:

Я быстренько поправлю правило на межсетевом экране. Никому не говорите.

Вместо этого появляется управляемый процесс изменений.

Например:

Инициатор изменения
         ↓
Оценка влияния
         ↓
Согласование
         ↓
Тестирование
         ↓
Внедрение
         ↓
Контроль результатов
         ↓
Актуализация документации

Да, подобная схема требует больше времени.

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

Но именно такие процессы позволяют через три года понять:

  • кто инициировал изменение;

  • зачем оно потребовалось;

  • кто его согласовал;

  • какие системы были затронуты;

  • почему было принято именно такое решение.

А это уже не про соответствие требованиям.

Это про управляемость.

Самая недооценённая проблема - человеческий фактор

Если посмотреть на реальные расследования инцидентов, становится заметно одно любопытное наблюдение.

Очень редко причиной оказывается голливудский хакер в чёрной толстовке.

Гораздо чаще виновниками становятся совершенно обычные ситуации.

Кто-то забыл отключить доступ.

Кто-то ошибся в настройке.

Кто-то использовал тестовую учётную запись в производственной среде.

Кто-то не дочитал инструкцию.

Кто-то решил, что временное исключение можно оставить "до следующей недели".

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

Например, вместо того чтобы рассчитывать исключительно на внимательность сотрудников, внедряются технические ограничения.

Если контейнер нельзя запустить без подписи - ошибка не произойдёт случайно.

Если доступ автоматически отключается после окончания срока действия - никто не забудет его отозвать через полгода.

Если резервные копии регулярно восстанавливаются в тестовой среде - проблема обнаружится до настоящего инцидента.

Если критические действия журналируются - расследование не будет зависеть от воспоминаний участников событий.

Фактически зрелая система строится вокруг очень простого принципа.

Люди ошибаются. Процессы должны учитывать эту особенность.

Это касается не только специалистов по эксплуатации.

Это касается всех участников процесса.

Бизнес может ошибаться в оценке рисков.

Разработчики могут допускать ошибки в коде.

ИБ может переусложнять требования.

Администраторы могут принимать неверные решения в условиях стресса.

Именно поэтому настоящая безопасность никогда не строится вокруг идеи безупречности отдельных сотрудников.

Она строится вокруг способности организации обнаруживать ошибки, ограничивать последствия и восстанавливаться после инцидентов.

Когда Kubernetes встречает ФСТЭК

Если попытаться сформулировать главный вывод этой статьи одной фразой, он будет звучать примерно так:

К1-К4 - это не про запрет современных технологий.

Очень часто можно услышать мнение, что Kubernetes, GitOps, DevOps и Platform Engineering несовместимы с российскими требованиями по защите информации.

На практике это не соответствует действительности.

Современные технологии прекрасно работают внутри защищённых контуров.

Просто они требуют большей зрелости.

GitLab CI превращается из удобного инструмента доставки кода в контролируемую цепочку поставки.

Harbor становится не просто Registry, а точкой контроля происхождения образов.

Falco начинает выполнять роль датчика обнаружения подозрительной активности.

SIEM превращается в центральную нервную систему инфраструктуры.

NetworkPolicy становятся способом реализации принципа минимально необходимых привилегий.

Admission Controller обеспечивает выполнение политик безопасности автоматически.

В результате современный защищённый контур может выглядеть следующим образом:

GitLab CI
      ↓
Static Analysis
      ↓
SBOM
      ↓
Trivy
      ↓
Cosign
      ↓
Harbor
      ↓
Admission Controller
      ↓
Kubernetes
      ↓
Falco
      ↓
Loki
      ↓
SIEM
      ↓
Backup

Это уже не история про изолированный сервер в запертой комнате.

Это полноцененная облачная платформа, построенная с учётом требований безопасности.

Да, её сопровождение обходится дороже.

Да, она требует квалифицированных специалистов.

Да, процессы становятся сложнее.

Но именно такие системы позволяют одновременно обеспечивать развитие бизнеса и сохранять управляемость рисков.

Вместо заключения

За годы работы вокруг К1-К4 сформировалось множество мифов.

Что безопасность мешает развитию.

Что аттестация существует исключительно ради документов.

Что современные технологии несовместимы с требованиями регуляторов.

Что достаточно купить несколько сертифицированных решений, и проблема будет решена.

Реальность оказывается значительно интереснее.

Чем выше класс защищённости, тем меньше система зависит от героизма отдельных сотрудников и тем больше зависит от воспроизводимых процессов.

Тем важнее становятся автоматизация, контроль изменений, журналирование и культура сопровождения.

Тем сильнее проявляется ценность DevOps-подходов, потому что именно они позволяют превращать сложные процедуры в повторяемые механизмы.

Именно поэтому К1, К2, К3 и К4 на самом деле отражают не только уровень требований регулятора.

Они отражают уровень зрелости организации.

Способность понимать собственную инфраструктуру.

Способность управлять изменениями.

Способность расследовать инциденты.

Способность восстанавливаться после ошибок.

И способность продолжать безопасно развивать систему даже тогда, когда аудиторы уже уехали, аттестат занял своё место в архиве, а в дверь снова стучится подрядчик с ноутбуком, искренне не понимающий, почему ему нельзя просто подключиться к производственному серверу под учётной записью Administrator.