Zero Trust și mTLS între servicii în România

Ce înseamnă Zero Trust între servicii

Modelul clasic presupune că tot ce este în rețeaua internă este de încredere. Zero Trust elimină presupunerea: fiecare apel este autentificat și autorizat, indiferent de unde vine. Practic, fiecare serviciu primește un certificat propriu, prezintă acel certificat la fiecare conexiune și verifică certificatul celuilalt. Fără certificat valid, apelul nu trece, chiar dacă atacatorul rulează deja cod pe un server din aceeași rețea privată.

• mTLS obligatoriu pe traficul dintre servicii, nu doar la marginea rețelei
• Identitate per serviciu, nu per server sau per rețea
• Politici de autorizare explicite: cine poate apela pe cine
• Jurnal al conexiunilor respinse, util la depanare și la audit

Bune practici pe care le aplicăm în Zero Trust

Zero Trust nu se cumpără de la un furnizor, se construiește în pași care se pot verifica unul câte unul. Lista de mai jos o aplicăm gradual, începând cu serviciile care ating date cu caracter personal, și o lăsăm scrisă în documentația ta, cu ordinea urmată. Fiecare pas este reversibil, ca să nu ajungi cu o rețea sigură pe hârtie, în care nimeni din echipă nu mai poate depana un apel respins.

• Nicio încredere implicită în rețeaua locală: fiecare apel se autentifică
• Identitate per serviciu, legată de sarcina de lucru, nu de adresa IP
• Privilegiu minim: fiecare serviciu ajunge doar la ce îi trebuie
• Rotație automată a certificatelor, cu viață scurtă și fără intervenție manuală
• Secrete criptate în git cu SOPS sau păstrate în Vault, cu jurnal de acces

Service mesh sau fără sidecar

Un service mesh precum Linkerd sau Istio îți dă mTLS și politici fără să modifici aplicația, dar adaugă componente de operat și consum de resurse pe fiecare pod. Pentru zece servicii, mesh-ul este de obicei prea mult: obținem același rezultat cu cert-manager sau step-ca și cu configurație de TLS în aplicație ori în proxy. Îți spunem sincer unde este limita, în funcție de numărul de servicii și de echipa care le operează.

• Puține servicii: cert-manager plus TLS în proxy, fără sidecar
• Multe servicii și echipe: Linkerd pentru mTLS uniform
• Cerințe fine de rutare și politici: Istio, cu costul de operare asumat

Context local și orele incluse

Pentru firmele din România care intră sub NIS2, transpusă prin OUG 155/2024, controlul accesului între sisteme este o cerință concretă, nu o preferință de arhitectură. Neconformitatea se sancționează administrativ, iar măsurile corective sunt obligatorii. Implementarea intră în orele lunare din abonament, 1–8 ore pe VPS și 5–10 ore pe servere dedicate, în funcție de plan, cerute din panoul de client la Servicii DevOps. Ce depășește cota se facturează separat.

Cum lucrăm

1. Ceri lucrarea din panou

   Ne spui ce servicii ai, care ating date sensibile și cum comunică între ele acum, apoi propui un termen din panoul de client.

2. Stabilim scopul și termenul

   Desenăm harta apelurilor, alegem între mesh și cert-manager, stabilim ordinea serviciilor și estimăm orele necesare din cotă.

3. Livrăm în pași reversibili

   Pornim autoritatea internă, emitem certificate, activăm mTLS în modul permisiv, verificăm traficul, apoi trecem pe obligatoriu.

4. Predăm cu documentație

   Primești harta identităților, politicile de autorizare, procedura de rotație și pașii de depanare pentru un apel respins.

Cazuri de utilizare

Tehnologii

• cert-manager
• step-ca
• SPIFFE
• Linkerd
• Istio
• Envoy
• HashiCorp Vault
• SOPS
• Kubernetes

Întrebări frecvente

• Ce este Zero Trust și ce înseamnă concret?

  Este modelul în care nicio rețea nu este considerată de încredere: fiecare cerere se autentifică și se autorizează separat. Concret, între servicii înseamnă certificate proprii, verificare reciprocă la fiecare conexiune și politici explicite despre cine poate apela pe cine.

• Ce este mTLS și prin ce diferă de TLS obișnuit?

  La TLS obișnuit doar serverul își dovedește identitatea, cu certificatul pe care îl vezi în browser. La mTLS o dovedesc ambele părți: și clientul prezintă un certificat. Așa un serviciu nu poate fi apelat de o componentă necunoscută, chiar dacă aceasta are acces la rețea.

• Cum implementezi Zero Trust fără să blochezi echipa?

  În pași reversibili. Pornim autoritatea internă, emitem certificate, activăm mTLS în mod permisiv, adică acceptăm și trafic necriptat cât timp verificăm ce se conectează, apoi trecem pe obligatoriu serviciu cu serviciu. Fiecare etapă are procedură de revenire.

• Istio sau Linkerd?

  Linkerd este mai simplu, consumă mai puțin și acoperă bine nevoia obișnuită de mTLS și politici. Istio are mai multe posibilități de rutare și control, cu un cost de operare pe măsură. Pentru un număr mic de servicii, ambele sunt probabil prea mult.

• Cum rotesc automat certificatele între servicii?

  Cu cert-manager sau step-ca, care emit certificate cu viață scurtă și le reînnoiesc înainte de expirare, fără intervenție manuală. Serviciile le reîncarcă din volum sau din memorie. Rotația se testează la livrare, ca să nu descoperi problema în ziua expirării.

• Am nevoie de mTLS dacă serverele sunt deja în VPN?

  VPN-ul îți protejează traficul față de internet, dar înăuntru rămâne încredere implicită: orice proces compromis poate apela orice serviciu. mTLS adaugă identitate pe fiecare apel. Cele două se completează, iar împreună fac lateralizarea unui atac mult mai grea.