Ei fjernakses-eining endrar nettverksgrensa til kunden sjølv når ho ringjer ut og ikkje treng noka innkommande portvideresending. Det er retninga utover som gjer ho enkel å installere og som gjer ho enkel å oversjå. Presenter ho som ein førespurnad om tilgangsdesign før ho går på nettverket. Å presentere ho som noko du ikkje trong å nemne, er måten ein teknisk suksess blir til eit kontraktproblem.

Gå ut frå at nettverkseigaren stiller fire spørsmål: kva, kven, kor langt, og korleis angrar vi det.

Be om ressursen, ikkje om subnettet

Skildre arbeidet med omgrepa eigaren brukar: kva person som treng kva teneste, på kva eining, kor lenge. Ein førespurnad avgrensa til éin applikasjon på éin vert er lett å godkjenne. Ein førespurnad om eit subnett er ein førespurnad om å organisere segmenteringa til nokon andre på nytt.

Kunden køyrer kanskje allereie eit godkjent VPN, ei gateway for eksternt skrivebord eller ein administrert støttekanal som dekkjer behovet. Sjekk det først, fordi gjenbruk av ein eksisterande veg vanlegvis er det billegaste svaret for begge partar. Passar det ikkje, sei nøyaktig kvifor. Den samanlikninga er den sterkaste delen av framlegget.

Viss ei eining verkeleg er nødvendig, ta med eigaren, programvarekjelda, oppdateringsprosessen og det planlagde installasjonspunktet.

Vis sambandet og kvar tilliten sluttar

Teikn eininga, fjernbrukaren, eventuelle meklarar eller relé og den verna ressursen. Merk kvar krypteringa sluttar og kven som administrerer kvar endepunkt. Ein økt utover introduserer framleis ein ny kontrollveg, og det er i diagrammet det blir synleg. Å seie at trafikken er kryptert svarer på eit konfidensialitetsspørsmål og ikkje på eit autorisasjonsspørsmål.

Oppgi modusen eksplisitt: pakkevideresending, applikasjonsproxy eller eit eksponert skrivebord. Kvar har ulike konsekvensar for ruting og vertstryggleik, og kvar feilar ulikt når eininga blir kompromittert.

Hald urelaterte kundenettverk og eininga sitt eige administrasjonsgrensesnitt utanfor det godkjende omfanget.

Skil brukaridentitet frå einingidentitet

Brukarregistrering, einingidentitet, fleirfaktorautentisering og applikasjonsinnlogging er fire ulike kontrollar, og framlegget bør nemne kvar av dei. Delte påloggingsdata er den vanlege snarvegen, og dei gjer eigaren ute av stand til å kalle tilbake éin person utan å forstyrre alle. Applikasjonsinnlogging bør bli hos applikasjonen. Eininga autentiserer eit samband; tenesta avgjer kva det sambandet får gjere.

Nulltillitsarkitekturen til NIST er nyttig her fordi han behandlar ressurstilgang som ei uttrykkeleg avgjerd snarare enn ei følgje av nettverksplassering.

Avtal gjenoppretting og fjerning før installasjon

Eigaren skal kunne slå av tilgang raskt via ein kontroll han sjølv betener, ikkje via ein telefon til deg. Skriv ned tilbakekalling av påloggingsdata, fjerning av eininga, ansvar for oppdateringar og ein utløps- eller revisjonsdato. Hald på ein lokal gjenopprettingsveg som ikkje er avhengig av den nye fjernkanalen. Ei eining ingen kan fjerne utan leverandøren, er ein permanent avhengigheit forkleadd som ei behendigheit.

Hald oversiktene i rimeleg omfang: godkjende identitetar, tilgangsomfang, vesentlege endringar og relevante feil.

Innsamling av urelatert nettlesarhistorikk for å bevise at eininga finst, er ikkje prov på god drift, og det skaper ei forplikting eigaren aldri bad om.

Korleis ei vellukka godkjenning ser ut

Godta designet saman med eigaren med éi tillaten teneste og éin ressurs som må halde fram med å vere nekta. Den andre halvdelen er den delen folk hoppar over, og det er den einaste delen som provar at grensa ligg der diagrammet seier. Test tilbakekalling på same måte, før eininga ber reelt arbeid. Blir godkjenninga nekta, bruk det sanksjonerte alternativet til kunden eller gjer arbeidet lokalt.

Eit fungerande samband er ikkje løyve til å opprette tilgangsvegen.

Skriv godkjenninga ned med omfanget og utløpsdatoen, og gi eigaren ein kopi. Den neste personen som rører nettverket, vil lese protokollen, ikkje minnet ditt om samtalen.

Relaterte artiklar