NAS-administrasjon via VPN: behold navnet, fjern den offentlige porten
Nå administrasjonssiden gjennom tunnelen, ikke via en ny offentlig port. Løs opp det riktige navnet, tilpass sertifikatet til det, og tillat én tjeneste fra én kilde.
Administrasjonssiden for NAS fungerer hjemme og slutter å virke i samme øyeblikk som administratoren reiser, så noen åpner en port, og problemet forsvinner sammen med personvernet. Det finnes en bedre måte å gjøre dette på. La siden være der den er, la tunnelen sørge for tilgjengeligheten, og gjør det du dokumenterer til en komplett URL med en navngitt tillatelsessti i stedet for en enhetsadresse som tilfeldigvis svarer. Alle beslutningene nedenfor, fra navnet via sertifikatet til den eneste tillatte porten, følger av å skrive det på denne måten.
Enheten for design er en URL, ikke en adresse
Skriv oppføringen som en komplett URL med port og skjema, og fest så betingelsene til den: hvem som kan bruke den, fra hvilket nettverk og gjennom hvilken sti. Et eksempel kan være https://nas.corp.example:8443 som bare publiseres til godkjente private klienter, der navnet og porten representerer det enheten faktisk lytter på.
En slik ramme tvinger beslutningene fram tidlig. En URL forutsetter et navn, et navn forutsetter et sertifikat, og et sertifikat forutsetter en tillitsordning. En adresse forutsetter ingen av delene, og det er nettopp derfor adressevarianten holder til første nettleseradvarsel og deretter blir en vane med å klikke seg forbi den.
| Entry point | What it costs | When it fits |
|---|---|---|
| Private name over the tunnel | A private DNS zone and a certificate for that name | Administrators who already hold VPN access |
| Public reverse proxy | An exposed front end to patch and monitor | A documented, reviewed need for public reach |
| Vendor relay service | Trust in a third party path | A supported product design, not a workaround |
Behold navnet som sertifikatet ble utstedt for
Klienten trenger en tillatt rute til den private adressen til NAS-en, og en privat DNS-ordning kan løse opp det tiltenkte vertsnavnet til denne adressen samtidig som den bevarer navnet HTTPS-tjenesten forventer. Begge halvdeler er viktige: ruten bringer pakkene dit, navnet forteller klienten hvilken identitet som skal verifiseres.
Skriver du i stedet inn den numeriske adressen, endres identitetskravet. RFC 9525 skiller navnet klienten ønsker å kontakte fra identiteten tjenesten presenterer, så et sertifikat utstedt for nas.corp.example kan med rette mislykkes når nettleseren ble pekt mot 10.20.0.15. Advarselen er korrekt, og løsningen er navnet, ikke et unntak.
dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.exampleKjør begge før du gir tunnelen skylden. Den første viser om det private navnet løses opp der du tror, og den andre viser hvilket sertifikat og hvilke alternative subjektnavn tjenesten faktisk presenterer. En privat CA kan være et godt forvaltet valg; det som ikke bør bli rutine, er å lære folk å avfeie identitetsadvarsler.
Begrens administrasjonsstien
Tillat nøyaktig administrasjonstjenesten fra den tiltenkte kilden, både på gatewayen og på NAS-en. Den setningen skjuler en detalj som biter: en rutet klientpool og en gateway med kildeoversettelse ankommer NAS-en med forskjellige kildeaddrasser, så en tillatelsesregel skrevet for den ene feiler stille for den andre.
NAS-en trenger også en returvei, og nettleseren må bruke den konfigurerte porten og skjemaet i stedet for leverandørens standardverdi fra et foruminnlegg. Å nå enheten er ikke tillatelse til å nå hver port på den. Avstanden mellom en enhet som svarer på ping og en administrasjonsside som lastes, er avstanden mellom to separate regler. Skriv dem som to regler med to kommentarer, slik at neste person ser hvorfor begge finnes.
Skille VPN-innslipp fra NAS-privilegier
Å bli sluppet inn gjennom tunnelen er ikke det samme som å få administrere enheten. En bruker som legitimt trenger fillagring, bør ikke arve enhetsadministrasjon bare fordi begge bor bak én gateway, og kontomodellen til NAS-en er stedet der dette skillet må håndheves.
En delt eller oversatt utgangsadresse kan heller ikke identifisere en enkelt administrator. Hvis revisjonssporet må navngi en person, må identiteten komme fra en autentisert konto og ikke fra kildeadressen til en tunnel som mange bruker.
Hva du ikke bør publisere ved uhell
En offentlig reversproxy og et leverandørrelé er begge reelle arkitekturer, og hver av dem bærer egne beslutninger om tillit og eksponering. Ingen av dem blir nødvendige fordi en administrator er bortreist, og ingen av dem bør dukke opp som en bieffekt av å eksponere en medieserver eller en fildeling.
Dokumenter fire ting og stopp: det private navnet, lytteren det tilordnes, gruppen som har tillatelse til å bruke det, og gjenopprettingsveien hvis tunnelen er utilgjengelig. Disse fire svarer også på spørsmålene en hendelsesgjennomgang vil stille, noe som ikke gjelder et skjermbilde av en portvideresendingsside. Det du sitter igjen med, er ett stabilt administrativt inngangspunkt i stedet for en enhet der hver funksjon vender mot internett.