Acceptarea accesului la distanță prin VPC cere teste de refuz

Acceptarea accesului la distanță este un tabel de rezultate așteptate, nu o captură de ecran a unei pagini funcționale. Pentru fiecare grup, scrieți ce ar trebui să reușească și ce ar trebui să eșueze, apoi rulați ambele cu identități de test dedicate într-o fereastră controlată. Refuzurile sunt partea care dovedește granița; o autentificare reușită dovedește doar că tunelul există. Toate acestea funcționează cu produsul VPN deja ales.

Folosiți conturi separate pentru teste și etichetați-le astfel încât nimeni să nu confunde o identitate de test cu o excepție reală.

Scrieți granița ca rezultate așteptate

Începeți cu rolurile, nu cu componentele: cine are nevoie de ce serviciu, de unde și cu ce identitate. Luați un VPC ilustrativ: un grup are nevoie de mediul de test prin HTTPS, altul de o bază de date de producție, iar un al treilea grup, mai mic, administrează poarta în sine. Fiecare rând primește o permisiune așteptată și un refuz așteptat, inclusiv serviciul vecin și contul vecin care nu ar trebui să funcționeze. Tabelul respectiv este criteriul de acceptare, iar persoanele care nu rulează testele îl pot revizui.

Testați autentificarea la baza de date separat de calea de rețea. Un port TCP accesibil nu ar trebui să facă un cont de bază de date neaprobat să reușească, iar apartenența la VPN nu ar trebui să creeze un rol IAM în cloud sau să acorde acces administrativ la API. Acestea sunt trei controale independente și eșuează independent.

O rută nu este autorizare

O rută face o cale posibilă; nu acordă permisiune. Reținerea unei rute este un substitut slab pentru o restricție aplicată la destinație, deoarece un client poate adăuga oricând propria rută. Grupul de securitate, acordarea bazei de date și autorizarea proprie a aplicației rămân controalele care decid. Când un test reușește neașteptat, priviți mai întâi politica destinației și nu tabelul de rutare pe care intenționați să îl aibă clientul.

De aceea testele de refuz vizează partea de server: acele rezultate nu pot fi schimbate prin editarea clientului.

Ce sursă vede de fapt controlul?

Adresa sursă pe care o evaluează un control depinde de arhitectura porții. O poartă găzduită pe EC2 poate transmite un pool rutat, îl poate traduce în propria adresă sau poate prezenta o altă adresă după NAT; un Client VPN gestionat se asociază cu o subrețea și urmează propriul model. Grupurile de securitate și ACL-urile de rețea văd ce ajunge după acea procesare. Inspectarea unei reguli cu o presupunere greșită despre sursă este o modalitate obișnuită de a construi o graniță care pare corectă și admite traficul greșit.

Corelați fiecare rezultat cu cel mai mic eveniment util: identitate și sesiune, resursă, operațiune, timp și decizia. Un apel API în CloudTrail, o înregistrare de flux VPC și un jurnal de sesiune VPN răspund la întrebări diferite, iar niciunul singur nu este un audit al aplicației.

Retrageți o identitate și testați-o din nou

Includeți retragerea în același tabel. Eliminați o identitate de test, confirmați că o sesiune nouă este refuzată, apoi confirmați separat cum sunt tratate sesiunile existente, pentru că sunt comportamente diferite cu proprietari diferiți. Verificați ce se întâmplă după o repornire sau înlocuire a porții, astfel încât o excepție adăugată manual să nu dispară în tăcere și să nu revină mai largă. O graniță care durează doar până la următoarea implementare nu este o graniță.

Nimic din toate acestea nu înlocuiește munca de patch-uri, recuperare sau ciclul de viață al acreditărilor. Face măsurabilă o promisiune mai îngustă: oamenii potriviți ajung la serviciile potrivite, în timp ce rutele, conturile și suprafețele de administrare din apropiere rămân în afara acordării.

Păstrați tabelul împreună cu implementarea și rulați-l din nou când se schimbă poarta. Testele sunt ieftine; presupunerile din spatele lor nu.