Глава 10. Микросегментация

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

Зачем нужна микросегментация

Проблема плоских сетей

Традиционная сетевая сегментация делит сеть на несколько зон: DMZ, внутренняя, серверная, управления. Между зонами стоят межсетевые экраны. Внутри зоны — плоская сеть, где все могут общаться со всеми. Это модель «твёрдая оболочка, мягкая начинка».

Проблемы этого подхода:

Латеральное перемещение. Атакующий, получивший доступ к одному хосту внутри зоны, свободно сканирует и атакует соседние хосты. SolarWinds (2020) — пример: через скомпрометированный Orion-сервер атакующие переместились к Active Directory и получили доступ к электронной почте федеральных агентств. Микросегментация ограничила бы радиус поражения одним сегментом.
East-west трафик доминирует. В современных средах 70-80% трафика — east-west (между серверами внутри ЦОД), а не north-south (от пользователей к серверам). Периметровые межсетевые экраны видят только north-south.
Статичность. VLAN-ы и подсети привязаны к физической топологии. Добавление нового микросервиса требует перенастройки сети. В облаке и Kubernetes сервисы эфемерны — IP-адреса меняются каждые минуты.

Что говорят стандарты

NIST SP 800-207 выделяет микросегментацию как один из трёх подходов к ZTA (Section 3.1.2: ZTA Using Micro-Segmentation). Подход основан на размещении шлюзов (gateway devices) на границе каждого микросегмента — интеллектуальные коммутаторы, маршрутизаторы или межсетевые экраны нового поколения. Другие два подхода — Enhanced Identity Governance (Section 3.1.1) и Software Defined Perimeters (Section 3.1.3). На практике организации комбинируют все три.

Источник: NIST SP 800-207, Section 3.1

Тенет 2 NIST SP 800-207 формулирует: «All communication is secured regardless of network location». Микросегментация — прямая реализация этого принципа: даже два сервера в одной подсети общаются только через авторизованный канал.

CISA выпустила «Microsegmentation in Zero Trust, Part One: Introduction and Planning» (29 июля 2025) — первое официальное руководство по микросегментации в рамках серии Journey to Zero Trust. Документ определяет четырёхфазный подход:

Identify candidate resources — оценить приложения, данные и среды для перехода на микросегментацию
Identify dependencies — понять, какие ресурсы взаимодействуют с кандидатом и построить карту зависимостей
Determine appropriate segmentation policies — создать правила, разрешающие только необходимые бизнес-потоки
Deploy updated segmentation policies — тестирование в permissive-режиме (только логирование), затем полное применение

Источник: CISA Microsegmentation Guidance, July 2025

Gartner Market Guide for Network Security Microsegmentation (6 мая 2025, авторы: Hils, Kaur, Bhogal) рекомендует строить архитектуру микросегментации, ограничивающую латеральное перемещение вредоносного ПО в сети и облачных средах.

Уровни микросегментации

Микросегментация может быть реализована на разных уровнях стека:

Уровень	Технология	Где применяется	Гранулярность
Сеть (L3-L4)	Security Groups, NSG, VPC Firewall, K8s NetworkPolicy	Облака, SDN	IP + порт
Идентичность (L3-L4+)	Cilium, Calico, NSX tags	Kubernetes, VMware	Метка/идентичность
Приложение (L7)	Cilium L7, service mesh, WAF	Kubernetes, service mesh	HTTP-метод, путь, gRPC-сервис
Хост	iptables/nftables, WFAS, Illumio VEN	Bare-metal, legacy	Процесс + порт

Наиболее зрелая архитектура комбинирует несколько уровней: сетевой (default deny) + идентичность (разрешить только определённым сервисам) + L7 (ограничить HTTP-методы).

Kubernetes: сетевые политики

Стандартный NetworkPolicy

Kubernetes NetworkPolicy API (networking.k8s.io/v1) — базовый механизм микросегментации в кластере. Без NetworkPolicy все поды общаются со всеми — это плоская сеть.

Ключевые ограничения стандартного NetworkPolicy:

Только L3-L4: IP-адреса, порты, протоколы (TCP/UDP/SCTP). Нет фильтрации по HTTP-методу или пути
Нет правил deny: Можно только разрешить (allow). Для deny — просто не создавать allow-правило
Нет кластерных политик: Политики привязаны к namespace
Нет логирования: Заблокированные соединения не логируются по умолчанию

Паттерн default deny — первый шаг к микросегментации:

yaml

# Kubernetes NetworkPolicy: блокировать весь ingress-трафик в namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}   # применить ко всем подам
  policyTypes:
    - Ingress
# Без ingress-правил = весь входящий трафик заблокирован

Источник: Kubernetes Network Policies

Важно: NetworkPolicy — только спецификация. Её применяет CNI-плагин (Calico, Cilium, или Amazon VPC CNI v1.14+). Без поддерживающего CNI политики игнорируются.

Calico

Calico (Tigera) — один из первых и наиболее распространённых CNI для Kubernetes. Помимо стандартных NetworkPolicy, Calico предлагает собственные CRD:

yaml

# Calico GlobalNetworkPolicy: запретить весь трафик по умолчанию кластерно
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: default-deny
spec:
  selector: all()
  types:
    - Ingress
    - Egress

Ключевые отличия Calico CRD от стандартного K8s NetworkPolicy:

Возможность	K8s NetworkPolicy	Calico CRD
Область	Namespace	Namespace + кластер (GlobalNetworkPolicy)
Правила deny	Нет	Да (Allow, Deny, Pass¹)
Приоритет правил	Нет (все additive)	Да (order: 100, 200...)
Endpoint types	Только поды	Поды, VM, хосты
L7	Нет	С Istio/Envoy (HTTP, gRPC)
ServiceAccount matching	Нет	Да
API	`networking.k8s.io/v1`	`projectcalico.org/v3`

¹ Pass передаёт решение следующему tier/profile в цепочке обработки Calico — используется для делегирования между командами безопасности (GlobalNetworkPolicy) и разработчиками (NetworkPolicy в namespace).

Calico и Kubernetes NetworkPolicy могут сосуществовать: команда безопасности управляет Calico GlobalNetworkPolicy, разработчики — стандартными NetworkPolicy в своих namespace.

Источник: Calico Network Policy docs

Cilium: eBPF и L7-политики

Cilium — CNI на базе eBPF, обеспечивающий сетевые политики без iptables. Текущая стабильная версия — v1.19.0 (февраль 2026, 10-летний юбилей проекта). Предыдущая — v1.18.0 (июль 2025).

Источник: Cilium GitHub Releases

Ключевые отличия Cilium:

eBPF вместо iptables. Традиционные CNI программируют iptables (линейный обход правил, O(n) на пакет). Cilium загружает eBPF-программы непосредственно в ядро Linux — решения принимаются на уровне tc и XDP с O(1) lookup по хеш-таблицам.
Identity-based security. Cilium присваивает каждому endpoint числовой идентификатор (uint32) на основе меток Kubernetes. Все поды с одинаковым набором меток получают одну identity. Политики оперируют identity, а не IP-адресами — не ломаются при перезапуске подов.
L7-фильтрация. CiliumNetworkPolicy поддерживает правила на уровне HTTP (метод, путь), gRPC, Kafka, DNS — без sidecar-прокси.
Hubble. Встроенная подсистема наблюдаемости: визуализация потоков, мониторинг policy verdict, экспорт в Prometheus/Grafana.

Пример L3-L4 политики (из официального Star Wars demo):

yaml

# CiliumNetworkPolicy: разрешить доступ к deathstar только кораблям Empire
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: rule1
spec:
  description: "L3-L4: restrict deathstar access to empire ships only"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
    - fromEndpoints:
        - matchLabels:
            org: empire
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP

Добавление L7-правила — ограничить HTTP-методы:

yaml

# CiliumNetworkPolicy: разрешить только GET на /v1/
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: rule1-l7
spec:
  description: "L7: allow only GET to /v1/"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
    - fromEndpoints:
        - matchLabels:
            org: empire
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/v1/.*"

Источник: Cilium Star Wars Demo, Cilium HTTP-Aware Policy

DNS-based egress control — ещё одна уникальная возможность:

yaml

# CiliumNetworkPolicy: разрешить egress только к определённым доменам
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: dns-egress
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            io.kubernetes.pod.namespace: kube-system
            k8s-app: kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchPattern: "*.example.com"
    - toFQDNs:
        - matchPattern: "*.example.com"
      toPorts:
        - ports:
            - port: "443"

Cilium как CNI по умолчанию. GKE использует Cilium (GKE Dataplane V2) по умолчанию с 2023 года. EKS поддерживает Cilium в режиме CNI chaining (Amazon VPC CNI для connectivity, Cilium для policy и encryption) и как standalone CNI. AKS поддерживает Cilium dataplane с Azure CNI Powered by Cilium.

Сравнение CNI для микросегментации

Критерий	K8s NetworkPolicy	Calico	Cilium
Dataplane	Зависит от CNI	iptables / eBPF	eBPF
L7 policy	Нет	С Envoy	Встроенная (eBPF proxy)
Identity-based	Нет	Через метки	Числовая identity
DNS policy	Нет	Calico Enterprise	Встроенная
Cluster-wide policy	Нет	GlobalNetworkPolicy	CiliumClusterwideNetworkPolicy
Наблюдаемость	Нет	Calico Enterprise	Hubble (open source)
Шифрование	Нет	WireGuard	WireGuard / IPsec
Лицензия	K8s API	Apache 2.0 (Open Source)	Apache 2.0

Облачная микросегментация

AWS: Security Groups и VPC Lattice

Security Groups (SGs) — stateful-фильтры на уровне Elastic Network Interface (ENI):

Правила только разрешающие (allow-only), нет deny
Stateful: ответный трафик пропускается автоматически
До 5 SG на ENI (увеличивается до 16), до 60 inbound + 60 outbound правил на SG
Можно ссылаться на другие SG как источник/назначение (вместо IP) — identity-like подход

Ограничения для полной микросегментации: нет L7, нет deny, нет централизованной видимости потоков без VPC Flow Logs.

AWS VPC Lattice — управляемый сервис L7-маршрутизации для service-to-service взаимодействий:

Auth policies на базе IAM (PARC: principal–action–resource–condition). Аутентификация через SigV4/SigV4A
Три уровня защиты: (1) VPC-ассоциация с service network, (2) Security Groups, (3) IAM auth policies
Поддерживает cross-VPC и cross-account коммуникацию
NIST SP 1800-35, Enterprise Build 5 (E4B5) использует VPC Lattice как PEP для микросегментации

Источник: AWS VPC Lattice Auth Policies, NIST E4B5

Azure: NSG + Application Security Groups

Network Security Groups (NSGs) — stateful-фильтры на уровне подсети или NIC:

Правила с приоритетом (100-4096): Allow или Deny
Default-правила: AllowVNetInBound, DenyAllInBound, AllowVNetOutBound, DenyAllOutBound

Application Security Groups (ASGs) — ключ к микросегментации в Azure:

NSG Rule:  WebServers (ASG) → DatabaseServers (ASG), Port 1433, Allow

ASG группирует VM по роли приложения, а не по IP. Несколько приложений могут существовать в одной подсети и быть изолированными через ASG.

Источник: Azure NSG Overview, Azure ASG Overview

GCP: IAM-governed Tags и Cloud NGFW

GCP реализует микросегментацию через три уровня файрвольных политик:

Hierarchical Firewall Policies — на уровне организации/папки (базовые правила для всех проектов)
Global/Regional Network Firewall Policies — на уровне VPC-сети
VPC Firewall Rules (legacy) — замещаются network firewall policies

IAM-governed Tags (Secure Tags) — основа микросегментации в GCP:

Характеристика	IAM-governed Tags	Network Tags (legacy)
Контроль доступа	IAM-роли (tagAdmin, tagUser)	Нет — любой администратор VM может добавить
Привязка	К VM, enforcement per-NIC	Ко всей VM (все NIC)
Поддержка в политиках	Hierarchical, global, regional	Только VPC firewall rules
Безопасность	Нельзя назначить без IAM-разрешения	Риск злоупотребления

Secure Tags обеспечивают intra-subnet microsegmentation: Secure Tags привязываются к VM, но matching и enforcement в firewall policy выполняются на уровне network interfaces (NIC), что позволяет гранулярный контроль для multi-NIC VM.

Источник: GCP Secure Tags for Firewalls, GCP Firewall Policies Overview

On-prem и legacy: VMware NSX, Illumio, host-based

VMware NSX / vDefend

VMware NSX предоставляет Distributed Firewall (DFW) — программный L2-L7 stateful-фаервол, встроенный в гипервизор ESXi. После приобретения Broadcom (2024) security-функциональность NSX ребрендирована под зонтичный бренд vDefend (текущая версия — vDefend 9.0 в составе VMware Cloud Foundation 9.0), однако продуктовое имя NSX продолжает использоваться в документации и API:

Уровень ядра: DFW работает как модуль в ядре ESXi, применяя правила на каждом vNIC виртуальной машины
Горизонтальное масштабирование: каждый хост ESXi — независимый фаервол; добавление хостов автоматически увеличивает ёмкость
vMotion-aware: при миграции VM правила и состояние соединений мигрируют вместе с ней

Микросегментация в NSX основана на тегах и динамических группах:

Теги: ключ-значение пары, назначаемые VM, сегментам, портам (например, env:production, app:web)
Группы: динамические — при появлении новой VM с тегом app:web она автоматически включается в группу
5 категорий правил: Ethernet → Emergency → Infrastructure → Environment → Application (порядок обработки)

Текущее состояние (2025-2026): Broadcom перевёл все продукты VMware на подписочную модель (с февраля 2024), лицензирование per-core.

Источник: VMware vDefend 9.0 Release Notes

Illumio: агентный подход для brownfield

Для сред без SDN-инфраструктуры (bare-metal серверы, legacy VM, смешанные ОС) Illumio предлагает агентный подход:

VEN (Virtual Enforcement Node) — лёгкий агент на каждом хосте. Не inline-фаервол: программирует нативный фаервол ОС (iptables на Linux, Windows Filtering Platform на Windows)
PCE (Policy Compute Engine) — центральный мозг. Принимает label-based политики и вычисляет оптимальные правила для каждого хоста

Четыре режима enforcement:

Idle — агент установлен, но не управляет фаерволом
Visibility Only — все потоки разрешены, но логируются. Позволяет построить карту зависимостей
Selective Enforcement — часть сервисов под защитой, остальные в visibility
Full Enforcement — только разрешённый трафик проходит

Этот подход соответствует фазам CISA: visibility → selective → full.

Illumio — Leader в Forrester Wave: Microsegmentation Solutions (Q3 2024) и Customers' Choice в Gartner Peer Insights for Network Security Microsegmentation (2026).

Источник: Illumio Segmentation

Host-based: iptables/nftables и Windows Firewall

Для отдельных хостов без оркестратора:

Linux (nftables) — замена iptables (по умолчанию в Debian, Fedora, Arch с 2023):

bash

#!/usr/bin/nft -f
# nftables: default deny + разрешить только SSH и HTTPS
table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport { 22, 443 } accept
  }
  chain forward {
    type filter hook forward priority 0; policy drop;
  }
  chain output {
    type filter hook output priority 0; policy accept;
  }
}

Windows (WFAS через Group Policy):

Computer Configuration → Policies → Windows Settings →
  Security Settings → Windows Firewall with Advanced Security
  → Inbound Rules: Block by default, allow specific ports/services

Когда использовать host-based: bare-metal серверы без оркестрации, legacy-среды, промежуточный шаг перед SDN. Для масштабного управления — Ansible, Puppet или Illumio.

Архитектурные паттерны

Default deny + selective allow

Базовый паттерн Zero Trust для сети:

Многоуровневая защита

Комбинирование уровней для defense in depth:

Lab: Cilium L7-политики в Kubernetes

Предварительные требования

Docker
kind v0.20+
kubectl
Helm v3
Cilium CLI (cilium)

Шаг 1: Создание kind-кластера без CNI

bash

cat <<EOF | kind create cluster --name cilium-lab --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true    # отключить kindnet
  kubeProxyMode: none        # Cilium заменит kube-proxy
nodes:
- role: control-plane
- role: worker
- role: worker
EOF

Шаг 2: Установка Cilium через Helm

bash

helm repo add cilium https://helm.cilium.io/
helm repo update

helm upgrade --install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=cilium-lab-control-plane \
  --set k8sServicePort=6443 \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set ipam.mode=kubernetes \
  --wait --timeout 180s

Проверка:

bash

cilium status --wait
# ✅ Cilium:             OK
# ✅ Hubble Relay:       OK

Шаг 3: Развёртывание тестовых приложений

Используем адаптированную версию Star Wars demo:

bash

# Развернуть "deathstar" (backend API), "tiefighter" (разрешённый клиент),
# "xwing" (запрещённый клиент)
kubectl create -f https://raw.githubusercontent.com/cilium/cilium/HEAD/examples/minikube/http-sw-app.yaml

# Дождаться готовности
kubectl wait --for=condition=ready pod --all --timeout=120s

Проверить, что без политик все могут общаться:

bash

# tiefighter → deathstar (должен работать)
kubectl exec tiefighter -- \
  curl -s -o /dev/null -w "%{http_code}" http://deathstar.default.svc.cluster.local/v1/

# xwing → deathstar (тоже работает — нет ограничений!)
kubectl exec xwing -- \
  curl -s -o /dev/null -w "%{http_code}" http://deathstar.default.svc.cluster.local/v1/

Шаг 4: Применить L3-L4 политику

yaml

# cilium-l3l4-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: rule1
spec:
  description: "L3-L4: restrict deathstar to empire ships only"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
    - fromEndpoints:
        - matchLabels:
            org: empire
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP

bash

kubectl apply -f cilium-l3l4-policy.yaml

# tiefighter (org: empire) → deathstar: 200 OK ✅
kubectl exec tiefighter -- \
  curl -s -o /dev/null -w "%{http_code}" http://deathstar.default.svc.cluster.local/v1/

# xwing (org: alliance) → deathstar: заблокирован ❌
kubectl exec xwing -- \
  curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 \
  http://deathstar.default.svc.cluster.local/v1/
# Timeout — трафик заблокирован

Шаг 5: Добавить L7-политику

yaml

# cilium-l7-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: rule1-l7
spec:
  description: "L7: allow only GET on deathstar API"
  endpointSelector:
    matchLabels:
      org: empire
      class: deathstar
  ingress:
    - fromEndpoints:
        - matchLabels:
            org: empire
      toPorts:
        - ports:
            - port: "80"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: "/v1/.*"

bash

kubectl apply -f cilium-l7-policy.yaml

# GET /v1/ — разрешён ✅
kubectl exec tiefighter -- \
  curl -s -o /dev/null -w "%{http_code}" http://deathstar.default.svc.cluster.local/v1/

# POST /v1/exhaust-port — заблокирован L7-правилом ❌
kubectl exec tiefighter -- \
  curl -s -o /dev/null -w "%{http_code}" -X POST \
  http://deathstar.default.svc.cluster.local/v1/exhaust-port
# 403 Access Denied

L7-политика заблокировала POST-запрос, который мог бы быть «взрывной уязвимостью» — tiefighter имеет доступ на уровне L3-L4, но L7-правило дополнительно ограничивает до read-only.

Шаг 6: Наблюдаемость с Hubble

bash

# Запустить порт-форвардинг Hubble Relay
cilium hubble port-forward &

# Наблюдать потоки в реальном времени
hubble observe --namespace default --protocol http

# Пример вывода:
# TIMESTAMP     SOURCE           DESTINATION      TYPE    VERDICT  SUMMARY
# 12:01:03      empire/tiefighter deathstar        L7/HTTP FORWARDED GET /v1/
# 12:01:05      empire/tiefighter deathstar        L7/HTTP DROPPED  POST /v1/exhaust-port
# 12:01:07      alliance/xwing   deathstar        L3/L4   DROPPED  TCP SYN

Hubble показывает:

Разрешённые и заблокированные потоки
Уровень блокировки (L3/L4 vs L7)
HTTP-детали (метод, путь, код ответа)

Шаг 7: Очистка

bash

kind delete cluster --name cilium-lab

Интеграция с архитектурой Zero Trust

Микросегментация — не изолированная мера. Она работает в связке с другими столпами:

Связь	Описание	Глава
Идентичность → политика	Cilium identity привязана к Kubernetes labels, которые наследуются от RBAC и ServiceAccount	Глава 5
Workload identity → mTLS	SPIFFE SVID + service mesh обеспечивают криптографическую идентичность для авторизации потоков	Глава 7, Глава 12
Device posture → network access	Устройство с низким risk score получает доступ только к ограниченному сегменту	Глава 8
EDR signal → isolation	CrowdStrike/Defender обнаруживает угрозу → автоматическая сетевая изоляция хоста	Глава 9
Policy as code	Cilium/Calico/NSX-политики хранятся в Git и применяются через CI/CD	Глава 19

Итоги

Микросегментация — один из трёх подходов к ZTA по NIST SP 800-207 (Section 3.1.2) и ключевая функция столпа Network в CISA ZTMM
Kubernetes: начните со стандартного NetworkPolicy (default deny), затем переходите к Cilium/Calico для L7-политик и identity-based security
Облака: AWS Security Groups + VPC Lattice, Azure NSG + ASG, GCP IAM-governed Tags + Cloud NGFW — каждый облачный провайдер предоставляет инструменты, но с разным уровнем гранулярности
On-prem: VMware NSX (vDefend) для виртуализированных сред, Illumio для brownfield/bare-metal, nftables/WFAS для отдельных хостов
CISA рекомендует: четырёхфазный подход — определить ресурсы → карта зависимостей → политики → развёртывание с валидацией
Ключевой принцип: default deny + selective allow на каждом уровне стека

Глава 10. Микросегментация ​

Зачем нужна микросегментация ​

Проблема плоских сетей ​

Что говорят стандарты ​

Уровни микросегментации ​

Kubernetes: сетевые политики ​

Стандартный NetworkPolicy ​

Calico ​

Cilium: eBPF и L7-политики ​

Сравнение CNI для микросегментации ​

Облачная микросегментация ​

AWS: Security Groups и VPC Lattice ​

Azure: NSG + Application Security Groups ​

GCP: IAM-governed Tags и Cloud NGFW ​

On-prem и legacy: VMware NSX, Illumio, host-based ​

VMware NSX / vDefend ​

Illumio: агентный подход для brownfield ​

Host-based: iptables/nftables и Windows Firewall ​

Архитектурные паттерны ​

Default deny + selective allow ​

Многоуровневая защита ​

Lab: Cilium L7-политики в Kubernetes ​

Предварительные требования ​

Шаг 1: Создание kind-кластера без CNI ​

Шаг 2: Установка Cilium через Helm ​

Шаг 3: Развёртывание тестовых приложений ​

Шаг 4: Применить L3-L4 политику ​

Шаг 5: Добавить L7-политику ​

Шаг 6: Наблюдаемость с Hubble ​

Шаг 7: Очистка ​

Интеграция с архитектурой Zero Trust ​

Итоги ​

Глава 10. Микросегментация

Зачем нужна микросегментация

Проблема плоских сетей

Что говорят стандарты

Уровни микросегментации

Kubernetes: сетевые политики

Стандартный NetworkPolicy

Calico

Cilium: eBPF и L7-политики

Сравнение CNI для микросегментации

Облачная микросегментация

AWS: Security Groups и VPC Lattice

Azure: NSG + Application Security Groups

GCP: IAM-governed Tags и Cloud NGFW

On-prem и legacy: VMware NSX, Illumio, host-based

VMware NSX / vDefend

Illumio: агентный подход для brownfield

Host-based: iptables/nftables и Windows Firewall

Архитектурные паттерны

Default deny + selective allow

Многоуровневая защита

Lab: Cilium L7-политики в Kubernetes

Предварительные требования

Шаг 1: Создание kind-кластера без CNI

Шаг 2: Установка Cilium через Helm

Шаг 3: Развёртывание тестовых приложений

Шаг 4: Применить L3-L4 политику

Шаг 5: Добавить L7-политику

Шаг 6: Наблюдаемость с Hubble

Шаг 7: Очистка

Интеграция с архитектурой Zero Trust

Итоги