Bastion SSH sau acces VPN direct: ce politică se aplică?

Dacă utilizatorii VPN pot ajunge la servere fără a trece printr-un host de salt este o întrebare de politică îmbrăcată în haine de rețea. Dacă bastionul îndeplinește un control obligatoriu, atunci conectarea la VPN trebuie să ducă spre el, nu în jurul lui. Dacă hostul de salt doar puntea un segment care înainte era inaccesibil, o cale directă îngustă poate fi înlocuirea onestă. Faceți verificările de mai jos în ordine și opriți-vă la prima care eșuează, pentru că acel răspuns decide restul.

Verificați ce controlează bastionul de fapt

Începeți cu dovezi despre prezent, nu cu o diagramă din documentul de proiectare. Uitați-vă la configurația SSH și la filtrul de pachete al țintei: dacă portul 22 de intrare este acceptat doar de la adresa bastionului, hostul de salt este un control impus. Dacă același port acceptă conexiuni din întregul pool VPN, bastionul a fost doar o comoditate, iar impunerea se află cu totul în altă parte. Istoricul tichetelor confirmă de obicei care dintre cele două a existat primul.

Formulați constatarea într-o singură propoziție care numește controlul oferit de bastion: restricționarea destinației, un al doilea pas de autentificare, înregistrarea sesiunii sau vizibilitate operațională în timpul unui incident. Aceasta este propoziția pe care politica de înlocuire trebuie să o păstreze.

Verificați dacă ținta distinge căile

Regulile de adresă sursă funcționează doar cât timp cele două căi sosesc cu adrese sursă diferite. Un gateway VPN care maschează traficul către subrețeaua serverelor șterge acea diferență, iar atunci fiecare conexiune la portul 22 pare să vină de la gateway. Verificarea este locală pe țintă și durează o clipă: listați sesiunile SSH stabilite și citiți adresa perechii pentru fiecare.

Când ambele căi se prăbușesc într-o singură adresă, distincția trebuie făcută mai devreme, prin destinațiile pe care VPN-ul are voie să le împingă și prin filtrele proprii ale gateway-ului. Adăugarea unei reguli pe țintă în această situație creează iluzia unei granițe fără a schimba ce ajunge.

Verificați ce păstrează cu adevărat fiecare înregistrare

Trei jurnale diferite descriu trei evenimente diferite și niciunul nu înlocuiește altul. Înregistrarea conexiunii VPN arată că o identitate a intrat în perimetrul rețelei. Înregistrarea de redirecționare a bastionului arată un canal TCP care îl părăsește spre o destinație și un port. Jurnalul de autentificare al țintei arată că un cont s-a autentificat prin SSH. Citirea lor împreună este cea care produce o cronologie; citirea unuia singur produce o presupunere.

Niciuna dintre aceste înregistrări nu conține ce s-a întâmplat în interiorul sesiunii criptate dintre client și țintă. Dacă revizuirea la nivel de comandă este o cerință, ea are nevoie de un mecanism de înregistrare implementat în mod deliberat, cu propriile reguli de prelucrare a datelor. Să te aștepți la asta de la jurnalele hostului de salt este modul în care o lacună de audit rămâne ascunsă până când contează.

Verificați unde se aplică de fapt politica

O setare de client precum ProxyJump este o cerere, nu o restricție. OpenSSH va deschide bucuros o conexiune directă atunci când destinația este accesibilă, așa că fișierele de configurare de pe laptopuri descriu intenția, în timp ce firewall-urile decid rezultatul. Aplicarea aparține destinațiilor permise ale gateway-ului VPN și regulilor de acces ale țintei însăși, iar utilizatorul nu poate edita niciuna dintre ele. Auditați în același timp căile alternative: o a doua interfață, un ascultător public, un strat mesh sau un tunel mai vechi între locații pot fiecare restabili scurtătura pe care tocmai ai închis-o.

Configurați totuși ProxyJump, pentru că face ruta aprobată cea ușoară și împiedică munca de rutină să genereze excepții. Confirmați ce rezolvă clientul de fapt înainte de a avea încredere în el.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Verificați printr-o încercare directă deliberată

O politică netestată vreodată este o speranță. Dintr-un client conectat la VPN, încercați calea care ar trebui acum refuzată, apoi încercați-o pe cea aprobată, și păstrați ambele rezultate. Încercarea refuzată este dovada că schimbarea a intrat în vigoare.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Un rezultat curat arată ca o conexiune directă refuzată sau expirată către adresa țintei, urmată de o autentificare reușită pe hostul de salt și de o înregistrare de autentificare pe partea țintei care numește sursa acceptată. Orice altceva înseamnă că granița este încă poroasă, orice ar spune documentația. Notați data, regula modificată și cele două rezultate, apoi dați căii de recuperare un proprietar și o dată de expirare astfel încât accesul de urgență să nu devină în tăcere ruta zilnică.