Ĉu vi ankoraŭ bezonas retejan VPN kiam la aplikaĵo uzas mTLS kaj SSO?
Trairu la kanalojn, kiujn via aplikaĵa ensaluto neniam kovras, poste decidu ĉu privata reta aliro estas superflua aŭ ankoraŭ la sola vojo al la gastiganto.
Vi ensalutas per mTLS, la panelo ŝarĝiĝas, kaj la aserto ke la reteja VPN nun estas superflua sonas racia proksimume tiom longe kiom daŭras ĝis vi bezonos restaŭri datumbazon je la dua matene. La TLS-limo de la aplikaĵo priskribas unu kanalon. La gastiganto, la datumbazo, la celo de sekurkopioj kaj la nuba konto portas ĉiu sian propran enirvojon, sian propran identecon kaj sian propran aprobanton, kaj neniun el ili ekzercas sukcesa ensaluto.
Iru eksteren de la ensaluta ekrano
Ensalutu kiel ordinara uzanto kaj notu ĉiun salton, kiun la peto tuŝas: retumilo, rando, aplikaĵa aŭskultanto, seja konservejo, malantaŭa API. Ĉiu salto havas posedanton kaj aŭtentikigan decidon. Nun ripetu la iradon por la persono, kiu flikas la gastiganton, kaj por la tasko, kiu skribas la noktan sekurkopion. Tiuj iradoj kutime disiĝas jam ĉe la unua salto.
Tiu disiĝo estas la demando, kiun indas respondi. Reteja VPN estas superflua nur kiam ĉiu kanalo en tiu dua irado havas eniran kaj rajtigan politikon, kiu staras per si mem.
Kvin kanaloj, kiujn la aplikaĵa ensaluto neniam kovras
La suba tabelo estas inventara ŝablono, ne deploja kontrol-listo. Plenigu la duan kolumnon per tio, kion via propra medio efektive devigas hodiaŭ.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
Kunhavigi identigan provizanton ne kunfandas tiujn rajtigojn. Uzanto, kiu rajtas sendi API-peton, per tio ne rajtas anstataŭigi VM-diskon aŭ restaŭri datumbazon per la akreditaĵoj de la aplikaĵo. NIST en la resumo de la nula-fida arkitekturo tenas ĝuste pro tio la aŭtentikigon kaj rajtigon de rimedoj aparte de reta loko.
Subtena inĝeniero, kiu povas legi bileton, per tio ne rajtas malfermi konzolon sur la gastiganto malantaŭ ĝi.
Vojo estas reala nur se la alternativo restas fermita
Limigi atingeblon al privataj administraj aŭskultantoj estas laŭleĝa anstataŭaĵo por reteja VPN, kondiĉe ke la limigo estas devigata kaj ne nur desegnata. La kutima fiasko estas alterna aŭskultanto, kiun neniu memoris: servo ankoraŭ ligita al ĉiuj interfacoj, sekureca-grupa regulo malfermita por kontraktisto, administra pordo atingebla de la interreto.
Kontrolu aŭskultantojn, ne diagramojn. Sur la gastiganto, listigu tion, kio efektive estas ligita per ss -ltnp, kaj konfirmu ke la administraj pordoj sidas sur privata adreso. En la nuba konzolo, legu la enirajn regulojn por la laborŝarĝa subreto kaj serĉu 0.0.0.0/0 sur io ajn administra. Poste provu la konekton de ekster la privata vojo, ĉar tiu testo estas la sola, kiu respondas la demandon.
Unu sola tutmonde malfermita regulo sur SSH nuligas ĉiun argumenton, kiun faris la tunela dezajno.
Skribu la mapon antaŭ ol kompari dezajnojn
Por ĉiu vico de la inventaro, notu kiu aprobas identecojn, kiu ĝisdatigas la alirregulojn, kiu forigas akreditaĵojn kiam iu foriras, kaj kiu traktas restaŭron kiam la vojo mem rompiĝas. Kvar nomoj por vico sufiĉas por malkovri la vicojn, kie la respondo estas komuna konto kaj vikia paĝo el antaŭ tri jaroj.
Poste validigu unu permeson kaj unu rifuzon por kanalo. Permeso pruvas, ke la celata identeco povas atingi la rimedon laŭ la celata vojo. Rifuzo pruvas, ke simila identeco ne povas, kaj ĝuste tiun teston homoj preterlasas, tial alternaj aŭskultantoj postvivas reviziojn. Komparu la proponitan dezajnon kun tiuj rezultoj, ne kun la TLS-agordo de la aplikaĵo, kiu neniam ekzercis eĉ unu el ili.
Kie reteja VPN ankoraŭ meritas sian lokon
Tunelo aŭ mallarĝa enirejo estas la ĝusta respondo, kiam rimedo ne havas propran aŭtentikigon por peto: bontenaj pordoj de datumbazo, celoj de sekurkopioj, konzoloj de hipervizoro, eksterbenda administrado. Tiuj aŭskultantoj fidas la reton, do la reto devas esti tio, kio aŭtentikigas la alvokanton.
Ĝi ne estas la sola respondo. Enirejo, kiu finas rajtigon por ĉiu rimedo, povas esti pli mallarĝa ol tunelo tra la tuta subreto, kaj ĝi lasas pli bonan revizian spuron ol komuna salt-gastiganto.
Ordo de laboro: finu la inventaron, fermu la alternativojn, validigu unu rifuzon por vico, kaj nur poste retiriĝu de la tunelo. Se vico ne povas produkti rifuzon, tenu la privatan vojon ĝis ĝi povos.