Инфраструктурная платформа для ML: от сетей до Kubernetes и безопасности

Фундаментальные основы корпоративных сетей и протоколов

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

Сетевые модели: OSI и TCP/IP на практике

Для стандартизации сетевого взаимодействия используются две основные концепции: модель OSI (Open Systems Interconnection) и стек TCP/IP. Модель OSI состоит из семи уровней и является теоретическим эталоном, тогда как TCP/IP — это практическая реализация, на которой работает современный интернет.

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

| Уровень OSI | Название | Оборудование / Протоколы | Практический смысл для инженера | | :--- | :--- | :--- | :--- | | L7 | Прикладной | HTTP, DNS, LDAP, SMTP | Работа самих приложений и API. Балансировка Ingress в K8s. | | L4 | Транспортный | TCP, UDP, порты | Обеспечение доставки. Балансировка MetalLB, проброс портов. | | L3 | Сетевой | Маршрутизаторы, IP, ICMP | Маршрутизация между подсетями. Настройка BGP, проверка ping. | | L2 | Канальный | Коммутаторы, MAC, VLAN | Передача кадров внутри одного сегмента сети. Изоляция трафика. | | L1 | Физический | Кабели, оптика, радио | Физическое соединение серверов в ЦОД. |

Процесс передачи данных сверху вниз называется инкапсуляцией. Приложение формирует данные (L7), транспортный уровень добавляет порты отправителя и получателя (L4), сетевой уровень оборачивает это в IP-пакет (L3), а канальный уровень добавляет MAC-адреса, формируя кадр (L2).

Адресация и сегментация: IP, VLAN и NAT

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

Расчет подсетей

IP-адрес состоит из адреса сети и адреса узла. Границу между ними определяет маска подсети. В современной бесклассовой маршрутизации (CIDR) маска записывается как количество единичных бит, например /24.

Количество доступных хостов в подсети вычисляется по формуле:

Где — количество доступных адресов для устройств, а — префикс маски подсети. Вычитание двойки необходимо, так как первый адрес резервируется за самой сетью, а последний — за широковещательным запросом (broadcast).

Пример: для подсети 10.0.0.0/24 количество адресов составит устройства. Если кластеру Kubernetes требуется 500 IP-адресов для подов, маски /24 будет недостаточно, и потребуется выделить сеть /23 (510 адресов).

Изоляция через VLAN

VLAN (Virtual Local Area Network) позволяет логически разделить один физический коммутатор на несколько независимых виртуальных сетей на уровне L2. Трафик одного VLAN не может попасть в другой без прохождения через маршрутизатор (L3), где его можно отфильтровать правилами межсетевого экрана.

> Разделение окружений (Production, Stage, Test) на уровне физической инфраструктуры часто реализуется именно через VLAN. Это гарантирует, что тестовый скрипт случайно не отправит широковещательный запрос в продуктивную базу данных.

Трансляция адресов (NAT)

NAT (Network Address Translation) подменяет IP-адреса в заголовках пакетов.

Протоколы корпоративной среды

Инфраструктура ML-платформы тесно интегрируется с корпоративными сервисами. Для настройки доступов и прохождения проверок ИБ необходимо знать порты и назначение базовых протоколов.

Сетевая безопасность: Межсетевые экраны, ДМЗ и SPAN

В корпоративном контуре весь трафик между сегментами контролируется межсетевыми экранами (Firewalls). Классические экраны работают на уровнях L3/L4 (фильтрация по IP и портам), а современные NGFW (Next-Generation Firewall) анализируют трафик на уровне L7, распознавая конкретные приложения и блокируя вредоносные паттерны.

!Архитектура демилитаризованной зоны (ДМЗ)

Для публикации сервисов наружу используется архитектура ДМЗ (Demilitarized Zone). Это изолированный сегмент сети, зажатый между двумя межсетевыми экранами. Внешний экран разрешает доступ из интернета только к определенным портам (например, 443 для HTTPS) серверов в ДМЗ (балансировщиков). Внутренний экран разрешает серверам из ДМЗ обращаться во внутреннюю сеть только по строго заданным правилам (например, к базе данных на порт 5432).

Для мониторинга инцидентов службы ИБ используют технологию SPAN (Switched Port Analyzer). Она зеркалирует копию всего сетевого трафика с определенного порта коммутатора на специализированные системы анализа (IDS/IPS). Это позволяет выявлять аномалии без вмешательства в работу самой сети.

Обеспечение высокой доступности: VIP и VRRP

ML-модели и базы данных должны быть доступны даже при выходе из строя одного из серверов. Для этого применяется концепция VIP (Virtual IP).

VIP — это IP-адрес, который не привязан жестко к одной физической сетевой карте. Он «плавает» между несколькими серверами в кластере. Управление этим адресом часто реализуется через протокол VRRP (Virtual Router Redundancy Protocol) или утилиту keepalived.

!Схема работы протокола VRRP и Virtual IP

В кластере назначается один основной узел (Master) и один или несколько резервных (Backup). Master удерживает VIP и обрабатывает трафик. Он постоянно рассылает multicast-сообщения (heartbeats), сообщая о своей работоспособности. Если Backup перестает получать эти сообщения, он инициирует процесс выборов, забирает VIP себе и начинает обслуживать клиентов.

Пример конфигурации приоритетов в keepalived:

В данном примере сервер с приоритетом 100 будет удерживать адрес 192.168.1.100. Если он выйдет из строя, сервер с приоритетом 90 мгновенно подхватит этот IP, и для конечного пользователя (или приложения) сервис останется доступным без изменения настроек подключения.

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

Управление доступом и идентификацией в корпоративном контуре

Надежная сетевая инфраструктура обеспечивает физическую и логическую связность узлов, но сама по себе не отвечает на главный вопрос информационной безопасности: кто именно пытается получить доступ к ресурсам и имеет ли он на это право. В корпоративной среде за это отвечает управление идентификацией и доступом (Identity and Access Management, IAM). Для инженера, разворачивающего платформу машинного обучения (ML), понимание IAM критически важно: модели, наборы данных и вычислительные кластеры должны быть надежно защищены от несанкционированного доступа, но при этом оставаться доступными для автоматизированных пайплайнов.

Доменные службы: Архитектура доверия

Основой корпоративного IAM выступают доменные службы. Исторически стандартом де-факто является Active Directory (AD) от Microsoft, однако в условиях импортозамещения и перехода на Linux-инфраструктуру все чаще внедряется ALD Pro — решение на базе FreeIPA.

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

Лес (Forest*) — глобальная граница безопасности. Все объекты внутри леса доверяют друг другу. Если ML-платформа разворачивается в изолированном лесу, она не сможет по умолчанию аутентифицировать пользователей из основного корпоративного леса. Дерево (Tree*) — набор доменов, имеющих общее непрерывное пространство имен (например, corp.local и ml.corp.local). Домен (Domain*) — базовая административная единица, хранящая базу данных пользователей и компьютеров. Организационное подразделение (Organizational Unit*, OU) — контейнер внутри домена, позволяющий группировать объекты (пользователей, серверы) для делегирования прав или применения политик.

> В ALD Pro архитектура несколько отличается от классического AD, так как опирается на Linux-специфичные механизмы (Kerberos, LDAP, SSSD), но концептуально решает те же задачи: централизованное управление учетными записями и политиками доступа для парка серверов и рабочих станций.

Типы учетных записей: От людей к машинам

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

ТУЗ — это фундамент автоматизации. Когда кластер Kubernetes скачивает Docker-образ из корпоративного Nexus, или когда Apache Airflow запускает задачу по выгрузке данных из ClickHouse, они используют ТУЗ.

Главное правило безопасности для ТУЗ: запрет интерактивного входа. Техническая учетная запись не должна иметь возможности авторизоваться через графический интерфейс или SSH. Если злоумышленник завладеет паролем от ТУЗ, он не сможет зайти под ней на сервер как обычный пользователь.

Глубокое погружение в Kerberos

Kerberos — это основной протокол строгой сетевой аутентификации в доменных службах. Его главная особенность заключается в том, что пароли никогда не передаются по сети ни в открытом, ни в зашифрованном виде. Вместо этого используется система билетов (Tickets).

!Схема аутентификации Kerberos

Процесс аутентификации состоит из трех этапов:

Важнейшее требование Kerberos — строгая синхронизация времени. Если разница во времени между клиентом и сервером KDC составляет минут, аутентификация будет отклонена. Это защита от атак повторного воспроизведения (Replay Attacks), когда хакер перехватывает старый билет и пытается использовать его снова.

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

LDAP: Структура каталога и интеграция

Если Kerberos отвечает на вопрос «Кто ты?», то LDAP (Lightweight Directory Access Protocol) отвечает на вопрос «Какие у тебя атрибуты и в каких группах ты состоишь?». Это протокол для чтения и поиска информации в службе каталогов.

Каждый объект в LDAP имеет уникальное отличительное имя — DN (Distinguished Name). Оно строится от частного к общему.

Пример DN для технической учетной записи: CN=svc-ml-pipeline,OU=ServiceAccounts,DC=corp,DC=local

Разберем компоненты: CN (Common Name*) — имя самого объекта (svc-ml-pipeline). OU (Organizational Unit*) — папка, в которой он лежит (ServiceAccounts). DC (Domain Component*) — части доменного имени (corp и local).

В инфраструктуре ML протокол LDAP (а точнее его защищенная версия LDAPS, работающая поверх TLS) используется для интеграции. Например, брокер аутентификации Keycloak подключается к AD по LDAP, вычитывает группы пользователей и на их основе выдает JWT-токены для доступа к API моделей машинного обучения.

Группы, роли и политики

Для управления доступом в крупных системах применяется концепция RBAC (Role-Based Access Control — управление доступом на основе ролей). В корпоративной среде это реализуется через связку групп безопасности и политик.

| Сущность | Назначение | Пример в ML-инфраструктуре | Практический смысл | | :--- | :--- | :--- | :--- | | Группа доступа | Объединяет пользователей по функциональному признаку в AD. | GG_ML_Engineers | Удобно добавлять новых сотрудников в одну группу, а не выдавать права поштучно. | | Роль | Набор конкретных разрешений внутри целевой системы (например, в Kubernetes). | Role: model-deployer | Определяет, что можно делать (создавать поды, читать секреты). | | Привязка (Binding) | Связывает группу из AD с ролью в системе. | GG_ML_Engineers model-deployer | Интеграция корпоративного IAM с локальным RBAC приложения. |

Для обеспечения безопасности на уровне операционных систем используются групповые политики (Group Policy Objects, GPO в Windows или политики FreeIPA в Linux). Они позволяют централизованно применять настройки к множеству серверов.

Пример использования политик для ТУЗ: создается специальное OU ServiceAccounts, куда помещаются все технические учетные записи. На это OU назначается политика, которая явно запрещает права Log on locally (локальный вход) и Allow log on through Remote Desktop Services (вход по RDP). Таким образом, даже если пароль от ТУЗ скомпрометирован, злоумышленник столкнется с серьезными барьерами при попытке проникнуть на сервер.

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

Архитектура Kubernetes: сеть, хранение данных и операторы

Корпоративная инфраструктура для машинного обучения требует не только надежной системы управления доступом, но и отказоустойчивой среды исполнения. Когда права доступа настроены, а технические учетные записи защищены, на первый план выходит оркестрация контейнеров. Стандартом де-факто для развертывания ML-нагрузок является Kubernetes (K8s). Для инфраструктурного инженера кластер K8s — это не просто набор серверов, а сложная программно-определяемая система, где сеть, хранилища и логика управления абстрагированы от физического оборудования.

Сетевая модель: от подов до балансировщиков

По умолчанию Kubernetes придерживается модели плоской сети. Это означает, что все рабочие нагрузки могут обмениваться трафиком друг с другом без использования трансляции сетевых адресов (NAT). За реализацию этой логики отвечает CNI (Container Network Interface) — плагин, который назначает IP-адреса и настраивает маршрутизацию на уровне узлов.

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

Поскольку поды (минимальные единицы развертывания) эфемерны и их IP-адреса постоянно меняются при перезапусках, для обеспечения стабильной связности используется абстракция Service. Существует три основных типа сервисов:

* ClusterIP — сервис получает внутренний IP-адрес, доступный только внутри кластера. Это идеальный выбор для баз данных или внутренних микросервисов. * NodePort — открывает определенный порт (обычно в диапазоне 30000-32767) на каждом узле кластера. Трафик, приходящий на этот порт, перенаправляется в нужный под. * LoadBalancer — интегрируется с облачным провайдером для автоматического создания внешнего балансировщика нагрузки.

В корпоративной среде (on-premise), где нет облачного провайдера, тип LoadBalancer по умолчанию не работает — сервис навсегда остается в статусе ожидания. Эту проблему решает MetalLB. Он реализует L4-балансировку (на транспортном уровне модели OSI) для bare-metal кластеров. Архитектура MetalLB включает два компонента: контроллер, который назначает IP-адреса из выделенного пула, и speaker (анонсер), который использует протоколы ARP или BGP для оповещения корпоративной сети о том, какой физический узел в данный момент обслуживает конкретный IP-адрес.

!Схема маршрутизации сетевого трафика в Kubernetes

Для маршрутизации HTTP/HTTPS трафика (L7-балансировка) применяется Ingress Controller (например, NGINX или Traefik) и ресурс Ingress. В отличие от L4-балансировщика, который оперирует только IP-адресами и портами, Ingress анализирует содержимое запроса. Это позволяет направить запрос ml.corp.local/api на сервис инференса модели, а ml.corp.local/ui — на веб-интерфейс JupyterHub, используя всего один внешний IP-адрес.

Хранение данных: персистентность в эфемерной среде

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

В зависимости от задач ML-платформы применяются разные типы хранилищ:

| Тип хранилища | Режим доступа | Пример решения | Сценарий использования в ML | | :--- | :--- | :--- | :--- | | Блочное | ReadWriteOnce (один узел) | OpenEBS, Rook Ceph | Базы данных (PostgreSQL, ClickHouse), где важна максимальная скорость ввода-вывода (IOPS). | | Файловое | ReadWriteMany (много узлов) | NFS, CephFS | Общие директории для распределенного обучения, где несколько воркеров читают один датасет. | | Объектное | S3 API | MinIO, Ceph RGW | Хранение артефактов (весов моделей), бэкапов и сырых данных. |

Для построения отказоустойчивого хранилища из локальных дисков серверов часто используется Rook Ceph. Ceph — это мощная распределенная система хранения, а Rook выступает в роли интегратора, который разворачивает и обслуживает компоненты Ceph внутри Kubernetes.

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

Где — общий объем сырого хранилища, — полезный объем данных, а — коэффициент репликации. При стандартном коэффициенте репликации , для хранения 10 ТБ датасетов потребуется 30 ТБ физических дисков.

!Архитектура динамического выделения хранилища в Kubernetes

Операторы: кодификация знаний администратора

Управление сложными системами с состоянием (stateful), такими как базы данных или распределенные хранилища, требует выполнения множества рутинных операций: настройки репликации, выполнения резервного копирования, переключения при сбоях (failover). В Kubernetes эта задача решается с помощью паттерна Operator.

Оператор — это программный контроллер, который расширяет API Kubernetes с помощью пользовательских ресурсов (Custom Resource Definitions, CRD). Он инкапсулирует в себе знания инженера по эксплуатации конкретного продукта.

Яркий пример — оператор CloudNativePG для управления базами данных PostgreSQL. Вместо того чтобы вручную создавать поды, настраивать потоковую репликацию и писать скрипты для резервного копирования, инженер создает один манифест типа Cluster. Оператор CloudNativePG самостоятельно разворачивает primary-узел, подключает к нему standby-реплики, настраивает TLS-сертификаты и непрерывно следит за состоянием кластера. Если primary-узел выходит из строя, оператор автоматически повышает одну из реплик до роли мастера, минимизируя время простоя.

Стратегии резервного копирования

Даже самая отказоустойчивая архитектура нуждается в резервном копировании. В контексте Kubernetes бэкапы делятся на две независимые категории:

Бэкап состояния (State). Конфигурация кластера (манифесты Deployment, Service, Ingress) должна храниться в системе контроля версий (Git). При подходе GitOps* кластер синхронизирует свое состояние с репозиторием. В случае полной потери кластера его конфигурацию можно восстановить за минуты простым применением манифестов. Бэкап данных (Data). Данные внутри Persistent Volumes и объектных хранилищ бэкапятся отдельно. Для этого используются инструменты вроде Velero, которые умеют делать консистентные снапшоты томов (Volume Snapshots) и отправлять их в S3-совместимое хранилище (например, MinIO*).

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

Эксплуатация баз данных и мониторинг в Kubernetes

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

Базы данных в Kubernetes: от транзакций к аналитике

Платформы для ML требуют различных типов хранилищ: от реляционных баз для хранения метаданных экспериментов до колоночных аналитических систем для обработки огромных массивов сырых данных. Управление ими в эфемерной среде контейнеров требует строгих подходов к безопасности и репликации.

Для транзакционных нагрузок стандартом является PostgreSQL. В корпоративной среде с высокими требованиями к информационной безопасности (ИБ) его развертывание осуществляется через оператор CloudNativePG (CNPG). Главное преимущество этого подхода — встроенные механизмы аудита и управления доступом.

Службы ИБ требуют детального логирования всех действий в базе данных. В CNPG это реализуется через интеграцию расширения pgAudit. Оно позволяет фиксировать не только успешные транзакции, но и попытки несанкционированного доступа. Например, если техническая учетная запись (ТУЗ) микросервиса попытается выполнить команду DROP TABLE, это событие будет немедленно записано в стандартный поток вывода пода (stdout), откуда сборщик логов перенаправит его в централизованную систему анализа событий безопасности (SIEM).

Для аналитических нагрузок и подготовки датасетов используется ClickHouse — невероятно быстрая колоночная СУБД. В отличие от PostgreSQL, где репликация часто строится по модели Primary-Standby, ClickHouse использует мультимастер-архитектуру для распределенных таблиц.

Отказоустойчивость ClickHouse в Kubernetes обеспечивается связкой с сервисом консенсуса — ZooKeeper или его современной легковесной альтернативой ClickHouse Keeper. Этот компонент хранит метаданные о состоянии реплик и гарантирует консистентность данных при сбоях узлов.

| Характеристика | CloudNativePG (PostgreSQL) | ClickHouse | Сценарий в ML-платформе | | :--- | :--- | :--- | :--- | | Тип СУБД | Реляционная (строковая) | Аналитическая (колоночная) | PG: Хранение MLflow трекинга. CH: Агрегация логов и фичей. | | Масштабирование | Вертикальное (преимущественно) | Горизонтальное (шардирование) | PG: Увеличение CPU/RAM пода. CH: Добавление новых узлов. | | Репликация | Потоковая (Primary-Standby) | Асинхронная (через Keeper) | PG: Быстрое переключение при сбое. CH: Распределенные вычисления. | | Аудит ИБ | Нативная поддержка pgAudit | Системные таблицы query_log | Отслеживание доступа к чувствительным данным моделей. |

!Архитектура отказоустойчивого кластера ClickHouse в Kubernetes

Наблюдаемость: разделение зон ответственности

Корпоративная платформа не может существовать без глубокого мониторинга. В современной инженерии используется термин наблюдаемость (observability), который объединяет сбор метрик, логирование и распределенную трассировку.

> Наблюдаемость — это не просто сбор логов и метрик, это способность системы отвечать на вопросы о своем внутреннем состоянии на основе внешних данных. > > Cloud Native Computing Foundation

В кросс-функциональных командах критически важно правильно разделить зоны ответственности за мониторинг:

* Инженеры инфраструктуры (DevOps/MLOps): Отвечают за доступность платформы. Их метрики — это утилизация CPU и оперативной памяти узлами, количество перезапусков подов (OOMKilled), статус репликации баз данных и время отклика сетевых балансировщиков. Разработчики ML-решений (Data Scientists): Отвечают за качество данных и бизнес-логику. Их метрики — это точность предсказаний модели (Accuracy/F1-score), смещение данных (Data Drift*) и количество пустых значений в обрабатываемых датасетах.

Главным показателем качества работы инфраструктуры является доступность сервиса. Она рассчитывается по классической формуле:

Где — коэффициент доступности, — суммарное время работы сервиса без сбоев, а — время простоя.

Например, в месяце 30 дней, что составляет 43 200 минут. Если кластер базы данных был недоступен из-за аварии 43 минуты, то . В корпоративных стандартах SLA (Соглашение об уровне обслуживания) обычно требует доступности не ниже 99,9%.

Документирование и изоляция контуров

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

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

Особое внимание службы ИБ уделяют разделению сред. Разработка (Development), тестирование (Preproduction) и промышленная эксплуатация (Production) должны быть строго изолированы. В Kubernetes эта задача решается на двух уровнях: логическом (через Namespaces) и сетевом (через Network Policies).

По умолчанию в Kubernetes все поды могут общаться друг с другом. Чтобы запретить тестовым ML-моделям обращаться к боевой базе данных, применяется подход Default Deny (запрет всего по умолчанию) с последующим точечным разрешением трафика.

В приведенном примере манифеста создается политика для пространства имен production. Она блокирует весь входящий трафик (Ingress), кроме запросов от подов, которые также находятся в пространствах имен с меткой environment: production. Таким образом, даже если разработчик случайно укажет в тестовой среде адрес боевой БД, сетевой плагин (CNI) на уровне ядра Linux отбросит эти пакеты.

!Схема изоляции сетевого трафика между пространствами имен Production и Preproduction

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

Документирование архитектуры и обеспечение информационной безопасности

Создание вычислительного кластера, настройка сетей и развертывание баз данных — это лишь техническая часть работы инфраструктурного инженера. В корпоративной среде с высокими требованиями к защите данных ни одна платформа машинного обучения не может быть введена в промышленную эксплуатацию без легализации. Этот процесс базируется на концепции Security by Design (безопасность на этапе проектирования), которая требует интеграции механизмов защиты и их документирования с самого первого дня разработки.

> Стоимость устранения ошибок на этапе проектирования архитектуры в 6-100 раз ниже, чем после внедрения системы в эксплуатацию. > > Архитектура ПО и кибербезопасность: основные принципы и практики

Паспорт информационной системы

Главным документом, легализующим работу платформы в корпоративном контуре, является Паспорт информационной системы. Это комплексный документ, который изучают службы информационной безопасности (ИБ) и IT-аудиторы перед тем, как выдать разрешение на обработку реальных данных.

Паспорт фиксирует границы системы и правила взаимодействия ее компонентов. В контексте ML-платформы он обязательно включает модель угроз, описание потоков данных (откуда забираются сырые датасеты, где обучаются модели, куда отправляются предсказания) и матрицу доступов для технических учетных записей (ТУЗ) и пользователей.

Для наглядного представления архитектуры в паспорт включаются два типа схем, которые решают разные задачи.

| Характеристика | Структурная схема | Логическая схема | | :--- | :--- | :--- | | Цель | Показать физическое или виртуальное размещение ресурсов | Отразить программное взаимодействие и потоки данных | | Элементы | Серверы, коммутаторы, системы хранения данных (СХД), маршрутизаторы | Микросервисы, базы данных, балансировщики, очереди сообщений | | Сетевой уровень | L2-L3 (VLAN, IP-адреса узлов, физические порты) | L4-L7 (TCP/UDP порты, HTTP-маршруты, DNS-имена) | | Пример для ML | Три bare-metal сервера с GPU, подключенные к коммутатору агрегации | Взаимодействие пода JupyterHub с базой данных PostgreSQL |

!Логическая схема взаимодействия компонентов ML-платформы

Например, если кластер состоит из 5 физических серверов, структурная схема покажет их подключение к двум независимым коммутаторам для отказоустойчивости. Логическая схема абстрагируется от железа и покажет, как сервис MLflow обращается к объектному хранилищу MinIO по протоколу S3.

Изоляция контуров: Production и Preproduction

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

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

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

Если в кластере работает всего 100 подов, количество возможных связей составит . Контролировать почти пять тысяч потенциальных векторов атаки вручную невозможно. Именно поэтому службы ИБ требуют строгой изоляции сред: разработка (Development), тестирование (Preproduction) и промышленная эксплуатация (Production) не должны пересекаться.

В Kubernetes эта задача решается на двух уровнях. Первый уровень — логическое разделение через Namespaces (пространства имен). Это позволяет сгруппировать ресурсы и ограничить к ним доступ на уровне ролевой модели (RBAC). Однако Namespaces сами по себе не блокируют сетевой трафик.

Второй, критически важный уровень — сетевая изоляция с помощью Network Policies (сетевых политик). Это правила межсетевого экранирования, которые реализуются на уровне сетевого плагина (CNI), например, Calico или Cilium.

Золотым стандартом корпоративной безопасности является подход Default Deny (запрет всего по умолчанию). Сначала блокируется весь трафик, а затем точечно разрешаются только необходимые соединения.

В этом примере манифеста создается политика для пространства имен preproduction. Пустой podSelector: {} означает, что правило применяется ко всем подам в этом пространстве. Директивы Ingress (входящий трафик) и Egress (исходящий трафик) без указания разрешающих правил полностью изолируют поды. После применения этой политики тестовая ML-модель физически не сможет отправить запрос к боевой базе данных, даже если разработчик ошибочно укажет ее адрес в конфигурации.

!Схема изоляции сетевого трафика с помощью Network Policies

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

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