Ligu oficejan aliron al identeco, ne al la ŝaltila pordo
Segmentado, akcepto kaj serva rajtigo estas malsamaj taskoj. Tri kondiĉoj decidas ĉu identec-bazita aliro superas VLAN-ojn por pordo.
Du projektoj estas sur la tablo. Unu tenas dungitojn en rolo-bazitaj VLAN-oj kaj redaktas la pordojn de la ŝaltilo kiam homoj translokiĝas. La alia aŭtentigas la seancon kaj lasas la regularon decidi kion ĝi rajtas atingi. La elekto ne temas pri moderneco; ĝi temas pri ĉu tri kondiĉoj validas en via konstruaĵo. Se iu el ili malsukcesas, la porda projekto ne estas stulta, ĝi estas tiu, kiun vi efektive povas funkciigi.
La tri kondiĉoj estas plenumeblo, kvalito de identeco kaj konduto ĉe fiasko.
Kondiĉo 1: ĉu la aliraj aparatoj povas plenumi redonitan regularon
802.1X estas rilato inter petanto sur la finpunkto, aŭtentiganto en la ŝaltilo aŭ alirpunkto kaj aŭtentiga servilo atingata per RADIUS. La servilo povas redoni VLAN-on aŭ alian regularan rezulton, kaj RFC 3580 priskribas tiun signaladon. La ŝaltilo tamen devas realigi la rezulton, kiun vi fidas.
Petu kapablon, ne protokolon: dinamikan atribuon de VLAN, elŝuteblajn ACL-ojn aŭ redirektadon al registra portalo.
Kondiĉo 2: ĉu la identeca fonto estas aŭtoritata kaj rapide ŝanĝebla
Grupano en la adresaro helpas nur se ĝi estas la kampo, kiun la entrepreno jam redaktas kiam rolo ŝanĝiĝas. Se rola atribuo loĝas en kalkultabelo kopiata al grupoj ĉiumonate, identec-bazita aliro simple aŭtomatigas kadukan enigon. Kontrolu ankaŭ la kaŝprokraston, ĉar novulo, kiu ne povas labori dum tuta tago, estas pli malbona rezulto ol permana porda ŝanĝo. Aparata aŭtentigo, uzanta aŭtentigo kaj ambaŭ kune estas apartaj elektoj, kaj presiloj bezonas eksplicitan modelon anstataŭ neklarigitan preterpason.
Skribu la mapadon: kiu grupo donas kiun regularon, kaj kiu rajtas ŝanĝi ĝin.
Kondiĉo 3: decidu la konduton ĉe fiasko antaŭ la provo
Ĉiu deplojo havas neaŭtentigitan staton kaj staton de neatingebla servilo, kaj la regularo por ambaŭ estas sekureca decido. Silenta refalo en fidan segmenton neniigas la projekton; malmola fiasko blokas laboron dum interrompo. La kutima mezo estas limigita segmento kun nur interreta aliro kaj klara vojo al la subtena servo. Testu la refalon sur la reala ŝaltilo aŭ sendrata platformo, ĉar la implicitaj agordoj de vendistoj diferencas.
Se neniu povas priskribi la refalon per unu frazo, la projekto ne estas finita.
Kie lokas la VPN
VPN aŭtentigas aliron tra nefidinda vojo, kaj postuli ĝin ankaŭ en la oficeja LAN povas esti intenca fida decido. Ĝi ne forigas la bezonon de grupa mapado nek de la propra rajtigo de la dosierujo. Ĝi ankaŭ aldonas enirejan kapaciton, klientan programaron kaj seanccan administradon al la operacia ŝarĝo.
VPN aĉetita por eviti redakti VLAN-ojn solvis la malĝustan problemon kaj aldonis du novajn.
La tabelo, kaj la sola afero konservinda
| 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 |
Konservu segmentojn por serviloj, gastoj, aparatoj kaj operacia teknologio. Tiuj limoj temas pri trafiko, ne pri postenaj titoloj, kaj ili postvivas ajnan reorganizadon. Metu la rajtojn de dungitoj en identecan regularon, kie rola ŝanĝo estas unu redakto, kaj uzu la subtenatan malkonektan mekanismon kiam forigo devas esti rapida.
La testo de la projekto estas skribotabla translokiĝo: ĝi devas translokigi personon kaj ties ekipaĵon, ne rekonstrui ties permesojn ĉirkaŭ alia ingo.