Security by design și defense in depth

Securitatea „by design” și „defense in depth” sunt pilonii fundamentali ai arhitecturilor cloud moderne, transformând securitatea dintr-un obstacol final într-o caracteristică intrinsecă a produsului. În practică, aceste principii reduc drastic suprafața de atac și costurile remedierii vulnerabilităților post-deployare, asigurând că fiecare strat al infrastructurii contribuie la reziliența generală. Ignorarea lor duce adesea la incidente majore cauzate de configurații greșite sau acces neautorizat, riscuri evitabile prin planificare proactivă.

Concepte cheie

• Security by Design: Integrarea măsurilor de securitate direct în faza de proiectare a aplicației și infrastructurii, nu ca o etapă ulterioară.
• Defense in Depth: Strategia de a suprapune mai multe straturi de protecție (rețea, aplicație, date) astfel încât eșecul unuia să fie compensat de celălalt.
• Principiul Privilegiului Minim: Acordarea doar permisiunilor strict necesare pentru executarea unei sarcini specifice, limitând impactul unui potențial compromis.
• Zero Trust Model: Presupunerea implicită că niciun utilizator sau dispozitiv nu este de încredere, indiferent dacă se află în interiorul sau exteriorul rețelei.
• Segmentarea Rețelei: Izolarea componentelor critice în subrețele separate pentru a preveni propagarea laterală a atacurilor în caz de breșă.
• Auditabilitate și Monitorizare: Logarea continuă a tuturor acceselor și modificărilor pentru detecția rapidă a anomaliilor și analiza post-incident.

Exemplu practic

Să presupunem că implementăm o bază de date PostgreSQL într-un container Kubernetes. Aplicând defense in depth, nu ne bazăm doar pe firewall.

1. Rețea: Configurăm un NetworkPolicy care permite conexiuni doar de la podurile aplicației web, blocând accesul direct din restul clusterului.
2. Acces: Folosim PodSecurityContext pentru a rula procesul bazei de date ca utilizator non-root (runAsUser: 999).
3. Date: Criptăm volumul persistent care stochează datele sensibile folosind CSI Driver pentru criptare la repaus.

# Exemplu simplificat de NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-access-policy
spec:
  podSelector:
    matchLabels:
      app: postgres
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web-frontend # Doar frontendul poate accesa DB
    ports:
    - protocol: TCP
      port: 5432

Această abordare asigură că, chiar dacă un atacator compromite un server web, el nu poate accesa direct baza de date fără a trece de alte verificări.

Greșeli frecvente

• Supraaplicarea privilegiilor: Atribuirea rolului admin sau root la toate conturile de serviciu, creând vectori masivi de atac.
• Ignorarea patch-urilor: Amânarea actualizării imaginilor Docker sau a dependențelor, lăsând vulnerabilități cunoscute expuse.
• Configurări publice accidentale: Lansarea în producție a unui bucket S3 sau a unei instanțe de bază de date cu permisiuni de acces public („open to world”).
• Lipsa segmentării: Plasarea tuturor microserviciilor în aceeași rețea plată, permițând mișcarea liberă a atacatorului între componente.

Întrebări de interviu

1. Ce înseamnă „defense in depth” și cum îl aplici într-un mediu multi-cloud? Răspuns: Înseamnă utilizarea mai multor mecanisme de securitate suprapuse. În multi-cloud, aplici politici uniforme de identitate (IAM) și criptare a datelor la repaus și în tranzit, indiferent de providerul folosit, asigurând consistența protecției.

2. Cum diferențiezi între securitatea by design și securitatea by addition? Răspuns: By design integrează securitatea în cod și arhitectură de la început (ex: validarea input-ului în API). By addition adaugă măsuri după dezvoltare (ex: scanere de vulnerabilități pe containerul deja construit), fiind mai puțin eficient și mai costisitor.

3. De ce este crucial principiul privilegiului minim în arhitectura zero trust? Răspuns: Limita impactul unei breșe. Dacă un serviciu este compromis, atacatorul are acces doar la resursele strict necesare acelui serviciu, nu la întreaga infrastructură.

Exercițiu

Alocă 45 de minute pentru a configura o politică de securitate simplă într-un mediu local (folosind Docker Compose sau Kubernetes Minikube). Creează două servicii: una publică și una privată (bază de date). Implementează o regulă de rețea care blochează orice trafic către baza de date, cu excepția traficului provenit de la serviciul public. Verifică funcționalitatea încercând să accesezi baza de date din afara containerului autorizat. Documentează pașii și justifică de ce fiecare strat de securitate ales este necesar.