Knytt kontortilgang til identitet, ikke til svitsjporten
Segmentering, tilgangskontroll og tjenesteautorisasjon er forskjellige oppgaver. Tre betingelser avgjør om identitetsstyrt tilgang slår VLAN per port.
Det ligger to design på bordet. Det ene holder ansatte i rollebaserte VLAN og endrer svitsjporter når folk flytter seg. Det andre autentiserer økten og lar policyen avgjøre hva den kan nå. Valget handler ikke om modernitet; det handler om hvorvidt tre betingelser gjelder i bygget ditt. Hvis én av dem svikter, er det portbaserte designet ikke dumt, det er det du faktisk kan drifte.
De tre betingelsene er håndhevelse, identitetskvalitet og oppførsel ved feil.
Betingelse 1: kan tilgangsenhetene håndheve en returnert policy
802.1X er et forhold mellom en supplikant på endepunktet, en autentisator i svitsjen eller aksesspunktet og en autentiseringsserver som nås over RADIUS. Serveren kan returnere et VLAN eller et annet policyresultat, og RFC 3580 beskriver den signaleringen. Svitsjen må likevel implementere resultatet du er avhengig av.
Be om en evne, ikke en protokoll: dynamisk VLAN-tildeling, nedlastbare ACL-er eller en omdirigering til en registreringsportal.
Betingelse 2: er identitetskilden autoritativ og rask å endre
Gruppemedlemskap i katalogen hjelper bare hvis det er feltet virksomheten allerede redigerer når en rolle endres. Hvis rollefordelingen bor i et regneark som kopieres til grupper hver måned, automatiserer identitetsstyrt tilgang bare et utdatert innspill. Sjekk også latenstiden, for en nyansatt som ikke kan jobbe en hel dag er et verre utfall enn en manuell portendring. Enhetsautentisering, brukerautentisering og begge sammen er separate valg, og skrivere trenger en eksplisitt modell i stedet for en uforklart omvei.
Skriv ned mappingen: hvilken gruppe gir hvilken policy, og hvem som kan endre den.
Betingelse 3: bestem oppførselen ved feil før piloten
Hver utrulling har en uautentisert tilstand og en tilstand der serveren er utilgjengelig, og policyen for begge er en sikkerhetsbeslutning. Et stille fall tilbake til et klarert segment undergraver designet; en hard feil blokkerer arbeidet under en avbrudd. Den vanlige mellomveien er et begrenset segment med bare internettilgang og en klar rute til brukerstøtten. Test tilbakefallet på den ekte svitsjen eller den trådløse plattformen, for leverandørenes standardverdier er forskjellige.
Hvis ingen kan beskrive tilbakefallet i én setning, er designet ikke ferdig.
Hvor VPN passer inn
En VPN autentiserer tilgang over en ikke-klarert vei, og å kreve den også på kontorets LAN kan være en bevisst tillitsbeslutning. Den fjerner ikke behovet for gruppemapping eller for filserverens egen autorisasjon. Den legger også til gatewaykapasitet, klientprogramvare og øktsstyring i den operative belastningen.
En VPN kjøpt for å unngå å redigere VLAN har løst det gale problemet og lagt til to nye.
Tabellen, og den ene tingen som bør beholdes
| Condition | Holds? | Design |
|---|---|---|
| Devices enforce returned policy | Yes | 802.1X with dynamic policy, stable segments |
| Devices cannot enforce it | No | Keep segments, add an application gateway |
| Identity source lags role changes | No | Fix provisioning before admission |
| No acceptable unauthenticated state | No | Restricted segment with a portal |
| Departures must lose access quickly | Yes | Dynamic disconnect plus credential revocation |
Behold segmenter for servere, gjester, enheter og operativ teknologi. De grensene handler om trafikk og ikke om stillingstitler, og de overlever enhver omorganisering. Legg de ansattes rettigheter i identitetspolicyen, der en rolleendring er én redigering, og bruk den støttede frakoblingsmekanismen når fjerning må være rask.
Testen på designet er en skrivebordsflytting: den skal flytte en person og utstyret hans, ikke bygge opp rettighetene hans på nytt rundt en annen kontakt.