da organisationer arbejder for at sikre ekstern arbejdsstyrkeproduktivitet, vises spørgsmålet om cachelagrede legitimationsoplysninger uundgåeligt, hvilket forårsager et problem for den påvirkede bruger og IT-servicedesk.
det er ingen hemmelighed, at en væsentlig del af næsten enhver arbejdsstyrke fungerer eksternt. Du har brugt de sidste par måneder på at scurrying for at etablere fjernforbindelse, skybaseret produktivitet og en eller anden form for omfattende sikkerhed-alt sammen for at give dine fjernansatte mulighed for at få deres arbejde gjort, mens de opfylder kravene til virksomhedsledelse omkring sikkerhed og overholdelse så godt som muligt. Men med cirka 40% af eksterne arbejdsstyrker, der bruger virksomhedsenheder, mens de arbejder hjemmefra, er der et problem, der kan være lige rundt om hjørnet, der sandsynligvis er ved at blive et problem, der vil involvere den delmængde af hele din eksterne arbejdsstyrke – udløber lokalt cachelagrede legitimationsoplysninger.
for dem af jer nye til det, der ikke er bekendt med lokalt cachelagrede legitimationsoplysninger, er her den meget korte primer: fordi brugeren er fjernbetjening, kan de ikke nemt (hvis overhovedet) oprette forbindelse til en domænecontroller (DC) på virksomhedens netværk. Så, vinduer holder en kopi af brugerens legitimationsoplysninger cachelagret på den lokale enhed, og brugeren kan frit logge ind lokalt, mens fjernbetjening uden at skulle oprette forbindelse til virksomhedens netværk. På trods af at Microsoft dræber kravet om at kræve, at brugerne ændrer adgangskoder ofte, er der stadig scenarier, hvor adgangskoder skal nulstilles:
- gammel politik forbliver på plads, og en adgangskode udløber
- brugerens legitimationsoplysninger mistænkes for at være kompromitteret af insider-trussel eller cyberangreb og skal nulstilles administrativt
- den aktuelt etablerede adgangskode viser sig at bruge en kompromitteret/lækket adgangskode og nulstilles administrativt
- brugeren glemmer deres adgangskode (som i, det er blevet cachelagret så længe, de ved ikke engang, hvad det er)
problemet ved hånden er, når adgangskoden skal genoprettes på Active Directory-siden af ligningen, hvordan opdaterer du lokalt cachelagrede legitimationsoplysninger? Den berørte bruger skal forbindes til virksomhedsnetværket (specifikt til en domænecontroller (DC)) for at have et nyetableret sæt legitimationsoplysninger cache lokalt. Nu er nogle af jer allerede foran mig og tænker: “mine brugere bruger en VPN og er derfor logisk på netværket, så vi har det godt.”Men ifølge en nylig undersøgelse fra Proofpoint har kun 39% af brugerne en VPN installeret, og kun 47% af disse mennesker bruger det konsekvent. Derudover er mange VPN-forbindelser til DC etableret efter login, så ikke alle potentielle scenarier, der måtte opstå, vil blive løst uden IT-support.
kort sagt, til sidst vil problemet med lokalt cachelagrede legitimationsoplysninger indhente dig.
så hvad er dine muligheder for at opdatere udløbne legitimationsoplysninger, og hvad er sikkerhedsforringelserne for hver?
for det første, fordi det problem, vi løser for, er, at fjernendepunktsenheden skal opdatere de cachelagrede legitimationsoplysninger, er den underliggende proces stort set den samme: Enheden skal være logisk forbundet til virksomhedens netværk (igen, specifikt med adgang til en DC) via VPN, og skal (forudsat at du kører vinduer 10) tryk på Ctrl-Alt-Del og vælg Skift en adgangskode.
når du ser denne proces i praktisk anvendelse, er der et par scenarier at overveje omkring opdatering af lokalt cachelagrede legitimationsoplysninger, og hvordan hver påvirker virksomhedens sikkerhed og IT.
1. Kendt, ikke-udløbet adgangskode, der er i stand til at oprette forbindelse – Dette er guldstandarden for mulige scenarier. Den teknisk kyndige bruger opretter simpelthen forbindelse til VPN, og ændrer deres adgangskode, og går om deres dag. Ren det nirvana.
2. Kendt, udløbet adgangskode, ikke i stand til at oprette forbindelse – uden tredjeparts nulstillingsløsninger til adgangskode er VPN et krav her. Servicedesk vil være involveret for at hjælpe med at lette i det mindste “tilslutning til virksomhedsnetværket” ved manuelt at nulstille deres adgangskode til den eksisterende som en potentiel løsning og få dem til at ændre det med det samme, hvilket kan indebære at hjælpe med at finde de nøgler, der er nødvendige for at komme til at ændre en adgangskode.
3. Ukendt adgangskode-at lægge forbindelsesproblemet til side, det er her ægte sikkerhedsrisiko begynder. Når brugerne ikke ved, hvad deres adgangskode er til at begynde med, kræver det naturligvis en indledende nulstilling af servicedesk, og derefter en adgangskodeændring ved første login, ligesom scenariet ovenfor. Sikkerhedsrisikoen kommer i form af at identificere brugeren som legitimationsejer, inden han overleverer nulstillingsadgangskoden. I det første scenario i det mindste, de kendte den gamle adgangskode, selvom det ikke er en meget sikker verifikationsmetode, det er en start. Så i dette tilfælde uden en form for en anden godkendelsesfaktor, der går ud over, ” hvem er dette?”eller” hvad er dit medarbejder-ID?”det er virkelig risikabelt.
4. Tvungen nulstilling – i tilfælde, hvor det tvinger en nulstilling af en brugers legitimationsoplysninger (igen på grund af problemer som mistanke om, at det er blevet kompromitteret af cyberangreb), skal handlingen med at arbejde med brugeren for at kommunikere en nyligt nulstillet adgangskode involvere en meget specifik og sikker form for validering af legitimationsejeren, inden du overleverer nulstillingsadgangskoden.
få cachelagret legitimationsoplysninger opdatering korrekt
problemet her er todelt, cachelagrede legitimationsoplysninger vil i sidste ende føre til en stigning i IT-supportopkald og tab af produktivitet, men der er et sikkerhedsproblem her. Overdragelsen mellem brugeren, der hævder at være legitimationsejer, og servicedesk-agenten, der skal aflevere en midlertidig adgangskode for at lette legitimationsopdateringen, kan efterlade en organisation udsat for angreb.
brugere i din organisation har forskellige adgangsniveauer og derfor iboende risiko. Så tilføj til blandingen her, at de med forhøjede niveauer af adgang til følsomme, proprietære og ellers værdifulde oplysninger har brug for meget mere Validering end nogen af de forenklede metoder, der ofte bruges på IT-servicedesk.
opdatering af de lokalt cachelagrede legitimationsoplysninger er et sikkerhedsproblem. Og den bedste sikkerhed er den, brugeren ikke kender til. Hertil kommer, at den bedste løsning er den, den ikke behøver at blive involveret i. Det er indlysende, fra scenarierne ovenfor, scenariet, der involverer en proaktiv, teknisk kyndig bruger, opfylder kriterierne. Men det er bare ikke virkeligheden det meste af tiden. Så der kan være behov for at se til tredjeparts adgangskode selvbetjeningsløsning, der integreres med Logonprocessen for at hjælpe med at forenkle de tre ukendte, jeg har nævnt i denne artikel: brugerens tekniske dygtighed, deres evne til at oprette forbindelse til virksomhedsnetværket, og det er evnen til at validere den person, der anmoder om nulstilling af adgangskode, er faktisk legitimationsejeren.
uden nogen tredjepartsløsning er svaret simpelt: VPN, Skift adgangskode. Når det generelt ikke er muligt, anbefaler jeg, at du kigger efter en løsning, der opfylder din eksterne arbejdsstyrke, hvor de er, mens de hjælper med at opretholde produktivitet og virksomhedssikkerhed.
