Regles d'isolation et flux autorises¶

Principe fondamental¶

Tout est interdit par defaut. Chaque flux entre zones ou entre services doit etre explicitement autorise, documente et justifie.

Politique de firewalling¶

Regles par defaut¶

# Politique par defaut : deny all
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# Loopback autorise
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# Connexions etablies
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Ouvertures par perimetre¶

Chaîne logicielle → Production¶

# Flux CI/CD vers registre de production
- name: cicd-to-prod-registry
  source: 10.10.0.0/16      # Chaine logicielle
  destination: 10.30.10.0/24  # Registre production
  port: 443/tcp
  protocol: HTTPS + mTLS
  justification: "Push d'artefacts valides par CI"
  owner: team-platform
  review: 2026-10-17

Services communs (accessibles depuis toutes les zones)¶

# IAM (authentification centralisee)
- name: all-to-iam
  source: 10.0.0.0/8
  destination: 10.20.1.0/24  # Segment IAM dedie
  ports: [443/tcp, 636/tcp]
  protocol: OIDC, LDAPS
  justification: "Authentification centralisee"

# DNS (resolution de noms)
- name: all-to-dns
  source: 10.0.0.0/8
  destination: 10.30.2.0/24  # Segment DNS
  port: 53/udp+tcp
  protocol: DNS over TLS
  justification: "Resolution de noms interne"

# Observabilite (push de metriques et logs)
- name: all-to-observability
  source: 10.0.0.0/8
  destination: 10.30.3.0/24  # Segment observabilite
  ports: [443/tcp, 9090/tcp, 3100/tcp]
  protocol: HTTPS, Prometheus remote write, Loki push
  justification: "Monitoring centralise"

Micro-segmentation applicative¶

Au-delà du réseau, chaque service est isole au niveau applicatif :

Network Policies Kubernetes¶

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-default
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  # Deny all par defaut — chaque service ouvre ses propres flux

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              name: dns-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Service Mesh (optionnel)¶

Pour une micro-segmentation avancee, un service mesh (Istio, Linkerd) ajoute :

mTLS automatique entre tous les pods
Politiques d'autorisation declaratives
Observabilité des flux inter-services
Rate limiting et circuit breaking

# Istio AuthorizationPolicy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-cicd-to-registry
  namespace: production
spec:
  selector:
    matchLabels:
      app: registry
  action: ALLOW
  rules:
    - from:
        - source:
            namespaces: ["cicd"]
            principals: ["cluster.local/ns/cicd/sa/pipeline-runner"]
      to:
        - operation:
            methods: ["PUT", "POST"]
            paths: ["/v2/*"]

Revue des flux¶

Chaque ouverture de flux a une date de revue. Le processus :

Demande : ticket avec justification metier
Validation : équipe sécurité verifie la légitimité
Implementation : ouverture avec tag de revue
Revue periodique : tous les 6 mois, les flux non utilises sont fermes
Audit : rapport annuel des flux actifs vs documentes