Drie toestande bepaal of die kantoor se enigste Windows-bediener ook die VPN moet beëindig: hoeveel internetgerigte sagteware jy bereid is om op die gids te laat loop, of jy afgeleë gebruikers sonder daardie rol kan verifieer, en wat met jou bestuurstoegang gebeur wanneer die gasheer weer begin. As enige van die drie 'n slegte antwoord het, skei die rolle. Dat die kantoor klein is, verander die begroting, nie die risiko nie.

'n Domeinbeheerder word deur elke masjien in die domein vertrou; 'n VPN-poort is vir enigiemand op die internet bereikbaar. Daardie asimmetrie is die hele argument.

Twee take met twee verskillende blootstellingsprofiele

Die poort aanvaar verbindings van buite, so sy luisteraar, sy TLS-stapel en sy verifikasieoppervlak is almal vanaf onvertroude netwerke bereikbaar. Die gids hou 'n gesag wat ander masjiene vertrou, en daarom beskou Microsoft se verhardingsriglyne die domeinbeheerderrol en sy gasheeromgewing as besonder sensitief. Elke diens wat by daardie gasheer gevoeg word, erf die gids se vertrouensposisie terwyl dit sy eie aanvalsoppervlak byvoeg. Gemak van installasie is nie 'n vertrouensgrens nie.

Die skeiding van die rolle verwyder nie die afhanklikhede nie. Afgeleë gebruikers het steeds verifikasie, roetes, DNS en toegangsreëls nodig, en 'n poort wat dit oorslaan is nie veiliger nie, net minder nuttig.

Verifikasie sonder die gidsrol

'n Poort kan geloofsbriewe deur 'n ondersteunde eksterne integrasie valideer sonder om die gids self te huisves. Wat daardie integrasie ook al is, gee dit 'n rekening waarvan die regte by die doel pas: die eienskappe lees wat nodig is om te verifieer, niks meer nie. Om VPN-gebruikers toe te laat vereis nooit dat hul gewone rekeninge domeinadministrateurs word nie, en dit vereis nooit dat die poort 'n kopie van die gids hou nie.

Bepaal dan die netwerkpaaie wat die afgeleë kliënt werklik nodig het. Toegang tot een interne lêerdiens, plus die naamoplossing en identiteitsdienste waarvan daardie werkvloei afhang, is 'n bepaalde stel paaie. Dit is nie 'n rede om elke domeinbeheerderpoort of elke administratiewe koppelvlak vanaf die VPN-poel toe te laat nie.

Een gasheer is steeds een foutdomein

Twee gaste op een hipervisor skei hul bedryfstelselkonfigurasie en skei nie hul lot nie. Die hipervisor se administrateurs, virtuele skakeling, berging en rugsteune bly deel van die ontwerp, en 'n herbegin van die gasheer verwyder beide dienste gelyktydig. Om dit hoë beskikbaarheid te noem omdat die diagram twee VM's wys, is 'n algemene en duur fout. As die enigste pad terug deur die VPN op daardie gasheer loop, neem 'n fout die verbinding weg wat nodig is om dit te herstel.

Beplan dus 'n onafhanklike bestuurspad wat nie van die tonnel afhang nie, en skryf neer wat tydens instandhouding beskikbaar bly. Beplan poortopdaterings en gidsinstandhouding afsonderlik, en let op watter gebruikers of toepassings elke onderbreking raak.

'n Instandhoudingsvenster wat vereis dat die VPN aan is om die VPN te herstel, is nie 'n instandhoudingsvenster nie.

Skuif dit sonder om jouself uit te sluit

As die rolle reeds een installasie deel, vermy 'n haastige afgeleë migrasie. Inventariseer wat die poort vandag besit: adresse, aanstuurrelëls, NAT, DNS-instellings, verifikasiekonfigurasie en enige gepubliseerde dienste. Berei beide die vervanging en 'n weg terug voor voordat jy die luisteraar skuif of 'n verstekroete verander. Toets dan 'n gewone afgeleë gebruiker se werklike werk deur die nuwe grens, en bevestig dat onnodige administratiewe toegang steeds misluk.

Die doel is nie 'n mooier diagram nie. Dit is die vermoë om die VPN te herstel of herbou sonder om aan die kas te raak wat gidsvertroue vir die hele kantoor veranker. Dit is verskillende doelwitte, en net een van hulle het 'n tweede bediener nodig.

Teken die besluit in elk geval aan, insluitend die toestande wat dit sou heropen. 'n Klein kantoor groei, en die antwoord wat by een bediener gepas het, pas dalk nie by die volgende nie.

Verwante artikels