Faqja e administrimit të NAS funksionon në shtëpi dhe ndalon së funksionuari në momentin që administratori udhëton, kështu që dikush hap një portë dhe problemi zhduket bashkë me privatësinë. Për këtë ekziston një formë më e mirë. Lëreni faqen aty ku është, lëreni tunelin të sigurojë arritshmërinë, dhe atë që dokumentoni kthejeni në një URL të plotë me një shteg leje të emërtuar, jo në një adresë pajisjeje që përgjigjet rastësisht. Çdo vendim më poshtë, nga emri te certifikata dhe porta e vetme e lejuar, rrjedh nga shkrimi i saj në këtë mënyrë.

Njësia e projektimit është URL-ja, jo adresa

Shkruajeni hyrjen si URL të plotë me portën dhe skemën e saj, pastaj shtoni kushtet: kush mund ta përdorë, nga cili rrjet dhe nëpër cilin shteg. Një shembull mund të jetë https://nas.corp.example:8443 i publikuar vetëm për klientë privatë të miratuar, ku emri dhe porta përfaqësojnë atë që pajisja dëgjon në të vërtetë.

Ky kornizë i imponon vendimet herët. URL-ja nënkupton një emër, emri nënkupton një certifikatë dhe certifikata nënkupton një marrëveshje besimi. Adresa nuk nënkupton asgjë nga këto, dhe pikërisht për këtë versioni vetëm me adresë mbijeton deri në paralajmërimin e parë të shfletuesit dhe më pas kthehet në zakon për të klikuar përmes tij.

Entry pointWhat it costsWhen it fits
Private name over the tunnelA private DNS zone and a certificate for that nameAdministrators who already hold VPN access
Public reverse proxyAn exposed front end to patch and monitorA documented, reviewed need for public reach
Vendor relay serviceTrust in a third party pathA supported product design, not a workaround

Mbajeni emrin për të cilin u lëshua certifikata

Klienti ka nevojë për një rrugë të lejuar drejt adresës private të NAS, dhe një rregullim privat i DNS mund të zgjidhë emrin e synuar të hostit në atë adresë duke ruajtur emrin që pret shërbimi HTTPS. Të dyja gjysmat kanë rëndësi: rruga i çon paketat atje, emri i thotë klientit çfarë identiteti të verifikojë.

Shkrimi i adresës numerike në vend të kësaj ndryshon kërkesën për identitet. RFC 9525 ndan emrin me të cilin klienti synon të kontaktojë nga identiteti që paraqet një shërbim, kështu që një certifikatë e lëshuar për nas.corp.example mund të dështojë në mënyrë legjitime kur shfletuesi u drejtua në 10.20.0.15. Paralajmërimi është i saktë, dhe zgjidhja është emri, jo një përjashtim.

dig +short nas.corp.example
openssl s_client -connect nas.corp.example:8443 -servername nas.corp.example

Ekzekutoni të dyja përpara se të fajësoni tunelin. I pari tregon nëse emri privat zgjidhet aty ku mendoni, dhe i dyti tregon çfarë certifikate dhe çfarë emrash alternativë të subjektit paraqet në të vërtetë shërbimi. Një CA private mund të jetë një zgjedhje plotësisht e menaxhuar; ajo që nuk duhet të bëhet rutinë është t'u mësosh njerëzve të injorojnë paralajmërimet e identitetit.

Kufizoni shtegun e administrimit

Lejoni saktësisht shërbimin e administrimit nga burimi i synuar, si në portë ashtu edhe në NAS. Ai rresht fsheh një detaj që kafshon: një grup klientësh i rrugëzuar dhe një portë me përkthim burimi arrijnë në NAS me adresa burimi të ndryshme, kështu që një rregull leje i shkruar për njërën dështon në heshtje për tjetrën.

NAS ka nevojë edhe për një shteg kthimi, dhe shfletuesi duhet të përdorë portën dhe skemën e konfiguruar, jo vlerën e parazgjedhur të prodhuesit të marrë nga një postim forumi. Arritja e pajisjes nuk është leje për të arritur çdo portë të saj. Hendeku midis një pajisjeje që përgjigjet ndaj ping dhe një faqeje administrimi që ngarkohet është hendeku midis dy rregullave të ndara. Shkruajini si dy rregulla me dy komente, që personi tjetër të shohë pse ekzistojnë të dyja.

Ndani pranimin në VPN nga privilegji i NAS

Të lejohesh të kalosh përmes tunelit nuk është e njëjta gjë si të lejohesh të administrosh pajisjen. Një përdorues që ka nevojë legjitime për ruajtje skedarësh nuk duhet të trashëgojë administrimin e pajisjes vetëm sepse të dyja jetojnë pas një porte, dhe modeli i llogarive të NAS është vendi ku ajo ndarje duhet të zbatohet.

Një adresë dalëse e përbashkët ose e përkthyer nuk mund të identifikojë asnjë administrator individual. Nëse gjurma e auditimit duhet të përmendë një person, identiteti duhet të vijë nga një llogari e vërtetuar dhe jo nga adresa e burimit e një tuneli që përdorin shumë njerëz.

Çfarë nuk duhet publikuar aksidentalisht

Një proxy i kundërt publik dhe një rele e prodhuesit janë të dyja arkitektura reale, dhe secila mbart vendimet e veta të besimit dhe ekspozimit. Asnjëra nuk bëhet e nevojshme sepse një administrator është larg shtëpisë, dhe asnjëra nuk duhet të shfaqet si efekt anësor i ekspozimit të një serveri mediash ose ndarjes së skedarëve.

Dokumentoni katër gjëra dhe ndaloni: emrin privat, dëgjuesin në të cilin pasqyrohet, grupin që lejohet ta përdorë dhe shtegun e rikuperimit nëse tuneli nuk është i disponueshëm. Këto katër u përgjigjen edhe pyetjeve që do të bëjë një rishikim incidenti, gjë që nuk vlen për një pamje ekrani të një faqeje ridrejtimi portash. Në fund ju mbetet një pikë e qëndrueshme hyrjeje administrative, jo një pajisje çdo funksion i së cilës shikon nga interneti.

Artikuj të ngjashëm