Tranzitul criptat nu acordă acces la operator
Criptarea ascunde încărcătura utilă de observatorii tranzitului. Nu oferă unei gazde cu încredere mai mică rute către rețeaua operatorului, DNS sau servicii private.
Două gateway-uri aprobate transportă traficul unei rețele cu încredere mai mică printr-o rețea de transport restricționată. Criptarea încărcăturii utile o menține ilizibilă pentru observatorii obișnuiți ai tranzitului, iar aceasta este partea pe care oamenii o proiectează prima și apoi încetează să se mai gândească la ea. Ce nu face criptarea este să definească ce resurse poate atinge partea cu încredere mai mică. Proiectul are nevoie de două granițe: una în jurul conversației transportate și una în jurul accesului la operatorul însuși.
Executați pașii de mai jos în ordine și tratați orice eșec la orice pas ca o schimbare de proiect, nu ca o ajustare a configurației.
Definiți ambele granițe înainte de a atinge o configurație
Prima graniță este conversația: ce perechi de gateway-uri pot stabili un tunel și ce trafic intern are voie să treacă prin el. A doua este operatorul: ce adrese și servicii pot atinge gazdele cu încredere mai mică în afara tunelului. Echipele construiesc de obicei prima și moștenesc a doua din orice rutare care exista deja, și așa un proiect restricționat devine în liniște unul larg. Această moștenire este cauza rădăcină obișnuită atunci când o revizuire găsește o gazdă cu încredere mai mică vorbind cu ceva ce nimeni nu a aprobat.
Scrieți ambele ca liste de adrese, porturi și direcții. Dacă o listă nu poate fi scrisă, granița nu este încă definită.
Pasul 1: restricționați tunelul exterior
Pe interfața orientată spre operator, permiteți doar ce are nevoie tunelul: IKE pe UDP 500 și 4500 între cele două adrese de gateway, și ESP acolo unde nu se folosește traversarea NAT. Respingeți tot restul care ajunge pe acea interfață, inclusiv protocoalele de administrare. Specificația ESP acoperă serviciile de protecție; nu spune nimic despre ce servicii proprii ale operatorului pot folosi gateway-urile. Exprimați acest lucru ca o listă explicită de permisiuni, astfel încât un serviciu al operatorului publicat recent să nu devină accesibil implicit.
Acesta este setul de reguli care face proiectul un proiect de tranzit și nu o înțelegere de peering.
Verificați-l din partea cu încredere mai mică, nu din consola gateway-ului. O gazdă de acolo ar trebui să nu poată atinge un server DNS al operatorului chiar înainte ca tunelul să fie ridicat.
Pasul 2: decideți ce livrează gateway-ul îndepărtat
La capătul îndepărtat, traficul recuperat trebuie să meargă într-un loc anume. Definiți ce servicii interne sunt permise, din ce intervale sursă și dacă se așteaptă ca răspunsurile să fie simetrice. Analizați separat accesul de administrare, pentru că același gateway expune adesea o interfață administrativă care nu a făcut niciodată parte din planul de tranzit.
O diagramă care se oprește la decriptarea reușită a omis decizia care contează cel mai mult.
Pasul 3: păstrați proprietatea pe fiecare strat
Echipamentul de tranzit primește și transmite în continuare pachete exterioare, așa că are nevoie de patch-uri și de planificarea capacității. Punctele de capăt ale tunelului procesează protocolul protejat și expun traficul intern căii lor de transmitere, așa că au nevoie de propriile reguli și de propria monitorizare. Aplicațiile finale procesează încărcătura utilă, iar o încărcătură opacă nu este dovada că o descărcare decriptată este inofensivă.
Atribuiți un proprietar fiecărui strat. Straturile fără proprietar sunt cele care derivă.
Pasul 4: verificați, apoi predați autorității
Verificați calea exterioară cu tunelul ridicat și regulile operatorului în vigoare. Apoi încercați fiecare resursă pe care partea cu încredere mai mică nu ar trebui să o atingă și confirmați că eșecul este o refuzare, nu un timeout care ascunde o rută. Verificați și disponibilitatea și limitele de resurse, pentru că o legătură criptată poate fi și ea saturată.
Pentru medii reglementate sau clasificate, duceți proiectul la autoritatea de securitate responsabilă și folosiți arhitectura sa de separare aprobată. O configurație VPN și o explicație conceptuală nu stabilesc acreditare. Acel pas nu este birocrație; el decide dacă proiectul are voie să existe.