Securitatea rețelei și containerizarea, două deziderate compatibile
În ultimii ani, organizațiile au început să își schimbe radical modul de abordare a securității, migrând de la modelul perimetral de protecție și controlul traficului Nord-Sud, către tehnicile de micro-segmentare a workload-urilor mai bine adaptate cerințelor de lucru în medii distribuite și arhitecturi multi-Cloud. Schimbarea vine cu o serie de avantaje, dar și cu provocări concrete, de genul unde și cum pot fi create, aplicate și actualizate regulile de securitate fără a afecta agilitatea proceselor de business și eficiența dezvoltatorilor.
Problema se complică în contextul adopției extinse a tehnologiilor de containerizare, care impun utilizarea unor sisteme de orchestrare – precum Kubernetes – și necesită conectarea clusterelor la rețea prin intermediul Container Networking Interface. CNI funcționează, practic, ca un plugin prin care nodurile ce rulează containere sunt conectate la rețele VxLAN (prin intermediul Flannel), BGP (prin Calico) sau direct la switch-urile hardware. Indiferent însă de ce interfață CNI este utilizată, crearea instanțelor de rețea nu se mai realizează în mod tradițional prin intermediul CLI la nivel de switch, ci prin cod structurat în format YAML sau JSON, care este trimis către clusterele Kubernetes via API server.
Să presupunem, însă, că avem o operațiune relativ mică, cu 500 de workload-uri, din care unele au fost migrate în containere. Într-o abordare tradițională, pentru asigurarea protecției lor avem nevoie de 500 de firewall-uri, mai puțin pentru pentru workload-urile „containerizate“. Dar și pentru acestea avem nevoie de o metodă centralizată de aplicare a regulilor de securitate necesare.
Să complicăm însă puțin datele problemei, introducând în „ecuație“ un nou server Active Directory (AD) cu rol LDAP. Pentru a permite workload-urilor pe care vrem să le protejăm să comunice cu serverul AD prin diverse porturi (TCP 389, 686, 88 etc.) trebuie să creăm noi reguli pe fiecare firewall.
Este evident că, și într-un astfel de scenariu de dimensiuni relativ reduse, firewall-urile fizice devin rapid greu de controlat. Iar complexitatea crește și în cazul firewall-urilor virtuale, pentru că este necesară aplicarea centralizată a politicilor în medii distribuite.
Pentru a putea gestiona eficient astfel de situații, departamentele IT au nevoie de soluții care să fie capabile să se ocupe de toate scenariile și mediile de lucru în mod egal și care să permită aplicarea centralizată și ierarhizată a acestor politici, care să poată fi formulate folosind un limbaj natural – de tipul „dev cannot talk to prod“ –, în locul arhaicelor metode de adresare IP/CIDR (precum „deny ip 10.4.20.0/24 10.27.8.0/24“).
Să privim acum problema din perspectiva dezvoltatorilor care trebuie să răspundă rapid și eficient la noile solicitări de business apărute. Pentru aceasta trebuie să scrie cod, să îl verifice într-un sistem SCM precum Git, să construiască aplicația, să o testeze și – dacă trece probele și este validată – să o lanseze în mediul de producție. Dacă totul funcționează corect, acest proces durează undeva între 5 minute și câteva ore, în funcție de complexitatea cerințelor.
Însă, indiferent dacă ia 5 minute sau 5 ore, este puțin probabil ca într-un mediu de lucru real politicile de securitate să poată fi actualizate pentru a reflecta noile cerințe de cod într-o singură zi. Cel mai adesea un astfel de proces durează de la două zile până la două săptămâni și reprezintă una din principalele cauze pentru care asigurarea securității este un proces dificil, greoi și predispus erorilor.
Soluția e simplă – politica trebuie să acompanieze codul și să fie implementată direct prin procesul de construcție al aplicației în sine. Este o condiție-cheie mai ales în cazul dezvoltării bazate pe containere și care poate fi pusă simplu în aplicare cu ajutorul Cisco Secure Workload (Tetration), care automatizează crearea și aplicarea politicilor de securitate.
Pentru a înțelege cum funcționează, haideți să analizăm modul standard în care lucrează dezvoltatorii atunci când implementează aplicații în Kubernetes: creează un fișier de tipul deployment.yml în care trebuie să introducă, minim, portul L4 de acces. Poate că majoritatea dezvoltatorilor sunt familiarizați la nivel general cu politicile de rețea, dar e la fel de probabil ca ei să nu știe efectiv modul în care aplicația lor respectă cerințele de securitate ale companiei.
Iată un exemplu simplu de fișier „deploy-dev.yml“ pentru implementarea unei aplicații de Load balancing și a unei Webapp conectată la baza de date de producție (PROD_DB), cât și la cea de dezvoltare (DEV_DB):
Acum, iată efortul minim pe care un dezvoltator trebuie să îl facă pentru a coda un mic fișier yaml adițional de tipul NetworkPolicy, care să fie implementat automat în momentul construirii lui în motorul de politici Cisco Secure Workload. Care motor este integrat la rândul lui cu clusterul Kubernetes și schimbă astfel automat informațiile necesare pentru a identifica sursa și destinația traficului și chiar și pentru a specifica utilizatorul LDAP la care poate ajunge aplicația. Iată mai jos cum arată un exemplu de fișier „policy-dev.yml“ pentru o asemenea implementare:
După cum se poate vedea, nivelul de dificultate pentru echipa de dezvoltare este scăzut. Valoarea generată pentru business este însă considerabilă, pentru că permite corelarea automată a politicii și verificarea ei cu regulile de securitate și conformitate existente, așa cum sunt ele definite la acel moment în cadrul organizației.
Cisco Secure Workload oferă dezvoltatorilor posibilitatea de a include politici de securitate împreună cu codul software, permițându-le să protejeze și să automatizeze implementarea respectivei politici folosind aceleași procese utilizate pentru implementarea codului. Astfel, organizațiile beneficiază de viteza și agilitatea de care au nevoie în procesul de dezvoltare și de respectarea cerințelor de securitate.
Dacă doriți să aflați mai multe detalii despre Cisco Secure Workload și modul în care poate eficientiza procesele de dezvoltare în cadrul organizației dvs., vă invităm să ne contactați la solutiicisco@cisco.com
Tags:
