Dona accés als usuaris de VPN a un sol servei, no a la subxarxa

Un contractista necessita una aplicació web interna i res més, i la resposta fàcil és donar-li un túnel cap a la subxarxa del servidor. Això funciona fins al dia que l’escaneja. El disseny més estret requereix més reflexió, perquè l’abastabilitat, l’encaminament i el permís de l’aplicació són tres controls separats que han de coincidir.

Escriviu el requisit com un servei, no com una subxarxa

Comenceu per l’amfitrió de destinació, el protocol i el port, i després afegiu el grup d’usuaris o de dispositius que hi ha d’arribar. Incloeu la zona DNS privada només si l’aplicació resol un nom, i incloeu un proveïdor d’identitat només si el flux d’inici de sessió en necessita un. Tota la resta és una dependència que encara no heu justificat.

Una subxarxa és un detall d’implementació de l’equip de xarxa, mentre que un servei és el que va demanar el negoci i la unitat que es pot revisar i retirar.

Si la llista de dependències passa de tres elements, probablement l’aplicació necessita la seva pròpia conversa de disseny.

Encamineu estret, però apliqueu-ho en un altre lloc

Una ruta o un selector estret diu al túnel quins paquets ha de portar; no és una política d’autorització. El filtre de la passarel·la, el tallafoc de l’amfitrió de destinació i el model de permisos de l’aplicació són on es decideix l’accés. Una ruta que cobreix una adreça és un bon començament, i no és el control que atura un usuari decidit. Aquesta separació és el que us permet canviar el filtre sense redissenyar el túnel.

Al contrari, una ruta àmplia amb un filtre estricte pot ser legítima, però només si tothom qui hi participa sap quin dels dos fa complir la norma.

Documenteu explícitament el punt d’aplicació, o el proper canvi el mourà per accident.

Comproveu la font que el servei veu realment

L’objectiu veu o bé l’adreça del pool del client o bé l’adreça de la passarel·la, segons si traduïu. Les regles del tallafoc de l’amfitrió i els registres han de coincidir amb la font real. Si diversos usuaris comparteixen una font traduïda, cap regla per usuari en aquell amfitrió no els pot distingir, i això és una restricció de disseny, no un error.

Trieu la traducció deliberadament: simplifica l’encaminament i destrueix la identitat de la font, cosa que importa per a l’auditoria i per a les regles per usuari.

Anoteu quina de les dues heu triat, al costat de la regla que en depèn.

L’autorització de l’aplicació no és opcional

Arribar a un port no atorga un rol. L’aplicació encara necessita el seu propi inici de sessió i els seus propis permisos, perquè la capa de xarxa no pot expressar quins registres pot editar un usuari. Un servei que confia en qualsevol petició de la subxarxa interna converteix un túnel estret en accés complet per a una credencial compromesa. El túnel decideix qui pot obrir el sòcol, i l’aplicació decideix què pot fer amb ell.

Aquí és on el disseny estret compensa dues vegades, perquè menys amfitrions accessibles significa menys llocs on es pot explotar un error a nivell d’aplicació.

Manteniu la regla de xarxa i el rol de l’aplicació en sistemes separats, i retireu-los per separat.

Demostreu tant el camí permès com el denegat

Connecteu-vos com a usuari autoritzat i feu una operació representativa inofensiva, i després proveu una destinació que hauria de ser inabastable. Un disseny que només prova la primera meitat no està provat, i la prova denegada és la que demostra el disseny. Proveu una sessió nova després de cada canvi de regla, i mireu el camí de tornada si les peticions arriben però les respostes no.

No desactiveu els filtres de reenviament per fer passar la prova d’acceptació, perquè això canvia la cosa que s’està provant.

Quan l’usuari ja no necessiti el servei, retireu la identitat remota i el rol de l’aplicació en els seus sistemes respectius, i registreu tots dos. La guia de reenviament de strongSwan cobreix el costat de la passarel·la del camí.