Tilkoblingsprofilen sier Produksjon, tunnelen kommer opp, og hvert vindu på skrivebordet kan nå kundens systemer. Ingenting i den sekvensen skilte den privilegerte økten fra nettleserfanen ved siden av. En VPN-profil er et navn pluss et sett ruter; grensen du faktisk bryr deg om, bygges av enhetsidentitet, et kontrollert kjøremiljø og en vei for innloggingsdetaljer. Disse tre håndheves på forskjellige steder, og derfor gir det et design som ser samsvarende ut og ikke er det, når man legger til én og hopper over de andre.

Et profilnavn er ikke en grense

Klienten bruker rutene og DNS-oppsettet når tunnelen kommer opp, og alt som deretter kjører på den maskinen, arver begge.

Et navn i en nedtrekksliste endrer hva en operatør kjenner igjen, ikke hva operativsystemet tillater.

Enhetsidentitet er det gatewayen kan kontrollere

En gateway som støtter enhetssertifikater eller tilstandskontroller, autentiserer både maskinen og personen. Det er det laget som kan avvise en tilkobling fra en ikke-styrt maskin før noen skriver et passord. Det gir deg også noe konkret å tilbakekalle når en enhet blir borte. Å kopiere ett sertifikat til tre maskiner fjerner nettopp den egenskapen, og derfor hører livssyklusen til sertifikatet hjemme i avtalen og ikke i en delt mappe.

Kunden avgjør hvilke av disse kontrollene politikken krever, og en virtuell maskin som en leverandør har bygget, oppfyller kanskje ikke en tilstandskontroll i det hele tatt.

Hvor en VM-grense lekker

En virtuell maskin holder kundens verktøy og nettilstanden sammen, og det er virkelig nyttig. Den er også avhengig av verten og av hypervisoren, og flere bekvemmeligheter krysser grensen: delte mapper, utklippstavleintegrasjon, agenter for innloggingsdetaljer og administrasjonstilgang på vertsnivå. En privilegert gjest på en vert til daglig bruk er ikke selvstendig pålitelig, fordi verten kan se hva gjesten gjør. Behandle VM-en som en kontroll som reduserer eksponering, ikke som et eget sikkerhetsdomene.

En dedikert fysisk enhet fjerner avhengigheten av verten og legger til en vedlikeholdsplikt i stedet.

Innloggingsdetaljer og overføringsveier

Bruk individuelle, tilbakekallbare identiteter per ingeniør og per kunde, og hold dem utenfor personlige nettleserprofiler og chatlogg. Innloggingsdetaljer som et helt team deler, kan ikke knyttes til en person, roteres eller tilbakekalles på en ren måte. Avgjør overføringsveien for verktøy, filer og diagnostisk utdata før den første økten, fordi tilfeldig filflytting er måten en grense stille slutter å være en grense. Hvis to kunder må nås samtidig, få godkjenning for skillet mellom nett og identitet først.

Bruk aldri bro mellom to kundenett gjennom én arbeidsstasjon bare fordi det var praktisk den ettermiddagen.

Avtalen som gjør det repeterbart

Skriv et kort notat per kunde og oppbevar det der begge parter kan finne det. Det skal navngi den godkjente enheten eller fjernmiljøet og hvem som vedlikeholder det, identitetene som er tillatt, systemene og handlingene de kan nå, overføringsveien og den vanlige måten en økt avsluttes på.

Fem linjer som noen går gjennom når en person kommer eller går, slår en policy som ingen kan bruke:

  • Godkjent enhet eller fjernmiljø, med en navngitt vedlikeholdseier.
  • Individuelle bruker- og enhetsidentiteter som er tillatt for støtte.
  • Systemer og handlinger som disse identitetene kan nå.
  • Tillatt vei for verktøy, filer og diagnostisk utdata.
  • Prosess for å avslutte økten og et autorisert nødalternativ.

Nødtilgang uten å flytte innloggingsdetaljer

Når en kontroll blokkerer en rask reparasjon, er veien unntaksprosessen, ikke en annen maskin med de samme innloggingsdetaljene. Et godkjent unntak registrerer hvem som autoriserte det, hva som ble myket opp og når det slutter. Å flytte en innloggingsdetalj til en maskin til daglig bruk endrer grensen på det verste tenkelige tidspunktet, og den blir oftest stående endret etterpå. Nødveien fortjener en øvelse mens ingenting er ødelagt.

Avslutt så økten slik avtalen sier, og bekreft at tilgangen faktisk stoppet.

Relaterte artikler