High Level Design

Cerințe

Infrastructura IT descrisă în acest articol a fost construită de la zero cu câteva obiective în minte:

• Să profite de cele mai noi și cele mai bune tehnologii disponibile, deoarece nu există constrângeri provenite din lucruri vechi
• Să se bazeze pe principii și tehnologii de securitate testate și dovedite
• Să fie cât mai flexibilă posibil (adaugarea și ștergerea de lucruri noi după necesitate, scalarea în sus și în jos fără modificări semnificative de design)
•  Să fie foarte disponibilă, dar fără a irosi resursele

Obiectivele de business, totuși, devin constrângeri de design conflictuale atunci când analizăm detaliile. Să reformulăm nevoile:

•  Integrarea mai multor medii cloud (AWS datorită funcționalităților, Cisco SD-WAN datorită rețelelor securizate și flexibile de filiale, Azure datorită gestionării punctelor terminale, a securității și a instrumentelor de productivitate)
• Segmentarea logică, adică separarea mediilor de aplicații în cloud-ul AWS, din motive de securitate
• Inspecția traficului între mediile de aplicații AWS înșiși (numit trafic E-W) și între mediile de aplicații și Internet (numit trafic N-S), de asemenea, din motive de securitate
• Păstrarea unor aparate de securitate mai capabile (față de cele native în cloud)
• Scalabilitate fără modificări semnificative de design
• Disponibilitate ridicată și echilibrare a load-ului

Cel mai dificilă problemă în acest context este securitatea și disponibilitatea ridicată a mediilor de aplicații utilizând appliance-uri de securitate 3^rd party pentru segmentare și inspecție a traficului. Centralizarea inspecției cu Gateway Load Balancer (GWLB) și Transit Gateway (TGW) de la AWS este concepută pentru a rezolva această problemă.

Cealaltă problemă este o rețea WAN scalabilă și rezistentă, care are acces atât la AWS, cât și la resursele Azure, și oferă, de asemenea, o cale alternativă între resursele AWS și Azure, în scopul simplificării rutării. Soluția Cisco SD-WAN se integrează bine atât cu TGW de la AWS, cât și cu Virtual WAN de la Azure.

Centralizarea inspecției cu Gateway Load Balancer și Transit Gateway de la AWS

Concepte de bază

Cu doar un an în urmă, nu exista o modalitate ușoară de a implementa, scala și oferi o disponibilitate ridicată pentru echipamentele virtuale de rețea 3^rd party în AWS. 

Amazon a lansat VPC ingress routing, facilitând rutarea traficului către instanțe specifice EC2 într-o VPC, dar încă lipsea capacitatea de a vizat un load balancer și puncte terminale de interfață VPC într-o tabelă de rutare a VPC-ului. Prin combinarea unui gateway transparent și a unui load balancer, noul Gateway Load Balancer (GWLB) de la AWS îndeplinește această cerință.

Dispozitivele virtuale de rețea stau in-line cu traficul de rețea și inspectează fluxurile de trafic de intrare și ieșire. Acest tip de inserție transparentă are multe denumiri, cum ar fi service chaining, bump in the wire sau virtualizarea funcțiilor de rețea (NFV).

Un Gateway Load Balancer (GWLB) este un serviciu gestionat (sau un plan de control) care facilitează clienților să implementeze și să administreze o flotă de appliance-uri virtuale de rețea scalabile în mod orizontal într-un mod transparent în scopuri precum inspecția de securitate, conformitatea, controalele de politică și alte servicii de rețea.

Un Gateway Load Balancer Endpoint (GWLBE) este o componentă al planului de date al GWLB și oferă o modalitate clienților de a plasa puncte terminale de interfață VPC într-o implementare centralizată și distribuită într-un mod flexibil. Un GWLBE este similar cu AWS PrivateLink, care vă permite să plasați serviciul dvs. în mai multe conturi și VPC-uri fără a pierde controlul și administrarea centralizate.

O adresă IP elastică este o adresă IPv4 statică și publică concepută pentru cloud-computing dinamic, fiind accesibilă de pe Internet. O adresă IP elastică este alocată unui cont AWS și poate fi înregistrată cu DNS-ul public.

Un Gateway de Tranzit AWS oferă o configurație de tip hub și spoke pentru conectarea rețelelor VPC și a rețelelor on-premises ca un serviciu complet gestionat. Nu este necesar un VPN overlay și AWS gestionează disponibilitatea ridicată și scalabilitatea. Gateway-ul de Tranzit controlează modul în care traficul este rutat între toate rețelele spoke conectate utilizând tabele de rutare. Acest model hub și spoke simplifică gestionarea și reduce costurile operaționale deoarece VPC-urile se conectează doar la instanța Gateway-ului de Tranzit pentru a accesa rețelele conectate. Gateway-ul de Tranzit este un resursă regională și poate conecta mii de VPC-uri în aceeași regiune AWS.

Unele echipamente de rețea, cum ar fi firewall-urile de tip stateful, necesită vizibilitate asupra tranzacției bidirecționale a fluxului de rețea pentru a evalua traficul valid și a detecta amenințări sau atacuri potențiale. Pentru aceste scenarii, rutarea asimetrică poate împiedica eficacitatea stateful. În mod implicit, Gateway-ul de Tranzit AWS încearcă să izoleze traficul în cadrul zonei de disponibilitate de unde a pornit traficul. Deși acest comportament este optim pentru majoritatea arhitecturilor, nu este ideal pentru implementările centralizate de firewall stateful care se extind pe mai multe zone de disponibilitate. Poate introduce rutarea asimetrică, ceea ce poate duce la întreruperi ale traficului. Pentru a rezolva această problemă, Gateway-ul de Tranzit AWS suportă acum appliance mode. Acest mod asigură rutarea traficului bidirecțional către aceleași atașamente VPC, cunoscută și sub numele de rutare simetrică. Aceasta elimină necesitatea soluțiilor complexe de rezolvare a problemei, cum ar fi sursa-NAT, pentru a forța traficul să revină la aparatul corect.

Modele pentru Inspectare Inline – Trafic N/S și E/W 

Clienții care implementează echipamente inline se încadrează în mod obișnuit în una dintre următoarele modele arhitecturale: 

•  O singură VPC cu conectivitate nord/sud 
• Multe VPC-uri cu conectivitate centralizată nord/sud 
• Multe VPC-uri cu conectivitate centralizată est/vest 
• O singură VPC cu conectivitate est/vest între subneturi în aceeași VPC 

Termenii nord/sud și est/vest sunt utilizați de ani de zile în rețelele tradiționale și mediile de date pentru a descrie fluxul de trafic. Nord/sud se referă în general la traficul care părăsește rețeaua sau centrul de date și descrie cel mai frecvent traficul care vine de la sau merge către Internet. Est/vest se referă la traficul care circulă între resursele din cadrul centrului de date sau rețelei. 

Cu modelul cu un singur VPC cu conectivitate nord/sud, se poate alege să se centralizeze sau să se distribuie planul de control și să se mențină un plan de date distribuit. Nu este necesar un Gateway de Tranzit.

Single VPC, Distributed Control and Data Plane (GWLB and GWLBE)

Single VPC, Centralized Control Plane (GWLB), Distributed Data Plane (GWLBE)

Atunci când mai multe VPC-uri necesită o conectivitate centralizată nord/sud, funcționalitatea inline bump-in-the-wire este mutată într-un VPC centralizată. Acest lucru este realizat în mod obișnuit cu ajutorul AWS Transit Gateway pentru a controla separarea atribuțiilor între conturile care efectuează funcționalitatea inline și VPC-urile auxiliare care găzduiesc aplicațiile. În acest model, atât funcționalitatea planului de control, cât și a planului de date sunt centralizate.

Many VPC’s, Centralized Control and Data Plane, North/South traffic (GWLB and GWLBE plus TGW)

Configurația cu un singur VPC care necesită funcționalitatea est-vest între subrețelele din același VPC nu este acceptată, deoarece VPC-ul nu permite definiția rutelor mai specifice decât alocarea CIDR a VPC-ului într-o tabelă de rute a VPC-ului. Din acest motiv, o tabelă de rute a VPC-ului nu permite redirecționarea traficului prin intermediul unui appliance dacă sursa și destinația se află în același VPC. Există o excepție de la această regulă și se aplică tabelelor de rutare edge. O tabelă de rutare edge permite traficului să intre într-un VPC de la o Poartă de internet prin intermediul unui Gateway Load Balancer.

Pentru același motiv, este important să se ia în considerare plasarea funcțiilor inline pentru sarcini de lucru destinate internetului. Dacă se utilizează un Gateway NAT AWS sau instanțe NAT autogestionate, GWLBE trebuie să fie amplasat între gateway-ul de internet și resursa cu expunere publică directă. Pentru traficul care vine de pe internet, funcționalitatea inline sau GWLBE nu poate fi plasată după NAT și între instanțele private, deoarece ar necesita o rută mai specifică în cadrul tabelului de rute al VPC-ului.

Modele pentru Inspectarea Inline – Luând în considerare starea firewall-ului

Rutarea asimetrică este un termen care descrie situația în care solicitarea unui client către un server parcurge o cale de rețea diferită față de răspunsul serverului. Dacă calea de retur asimetrică trimite pachetul printr-un firewall diferit, traficul valid ar putea fi respins din cauza urmăririi conexiunilor – un component de bază al firewall-urilor stateful. Un firewall stateful urmărește o conexiune sau un flux de rețea pe întreaga durată a unei tranzacții (cum ar fi conexiunile TCP de la pachetul SYN inițial la notificarea FIN finală). Pentru ca un firewall să urmărească o conexiune eficient, rețeaua trebuie să se asigure că pachetele sunt trimise către aceeași instanță de firewall în ambele direcții (de la client la server și de la server la client). Dacă, din orice motiv, un flux activ este rutat către un firewall care nu urmărește starea fluxului, pot apărea pierderi nedorite de pachete.

În mod implicit, AWS Transit Gateway aplică un algoritm de rutare foarte specific, optimizat pentru a menține afinitatea cu zona de disponibilitate. Deși acest lucru este ideal pentru performanță și disponibilitate, poate provoca probleme pentru arhitecturile de firewall centralizate. Acest lucru este valabil în special în cazul modelului de arhitectură centralizată est-vest, în care sursa și destinația pot fi în două zone de disponibilitate diferite.

Cu modul Appliance al AWS Transit Gateway, este posibil să se specifice atașamente care să direcționeze fluxurile de rețea din aceeași zonă de disponibilitate, indiferent de direcția fluxului și de zona de disponibilitate din care a pornit. Modul Appliance al AWS Transit Gateway asigură rutarea simetrică a fluxurilor de rețea către aceeași zonă de disponibilitate și aparat de rețea. Este necesară conectarea unui singur AWS Transit Gateway la VPC-ul Appliance pentru a garanta stabilitatea fluxurilor, deoarece gateway-urile AWS Transit nu împărtășesc informații despre starea fluxului între ele.

Modele pentru inspecția în linie – Elastic Load Balancer

Până acum, Endpointurile Gateway Load Balancer (GWLB) erau inserate în mod transparent în trafic ca un „bump-in-the-wire” folosind rutarea în subrețea VPC și o rută de intrare IGW (Internet Gateway). Endpointurile GWLB erau create în subrețele individuale – câte una per Zonă de Disponibilitate. Aceste endpointuri ofereau o cale către un VPC separat care găzduia GWLB și echipamentele de securitate ale 3^rd party.

În primul rând, am direcționat traficul către Endpointul GWLB corespunzător. De acolo, a fost trimis în mod transparent către GWLB și apoi către firewall-urile de la terți. După ce traficul a fost inspectat, se întorcea la Endpointul GLWB. Acum, poate continua către Elastic Load Balancer care găzduiește serviciul. Aceasta este ultima componentă necesară.

Surse:

• https://aws.amazon.com/blogs/networking-and-content-delivery/design-your-firewall-deployment-for-internet-ingress-traffic-flows/
• https://aws.amazon.com/blogs/networking-and-content-delivery/scaling-network-traffic-inspection-using-aws-gateway-load-balancer/
• https://aws.amazon.com/blogs/networking-and-content-delivery/integrate-your-custom-logic-or-appliance-with-aws-gateway-load-balancer/
• https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/
• https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-gateway-load-balancer-supported-architecture-patterns/
• https://aws.amazon.com/blogs/networking-and-content-delivery/centralized-inspection-architecture-with-aws-gateway-load-balancer-and-aws-transit-gateway/
• https://aws.amazon.com/blogs/apn/centralized-traffic-inspection-with-gateway-load-balancer-on-aws/