Active Directory - Gebruikersbeheer en groepen

[NuKeM]

Ik heb op mijn werkplek de vraag gekregen eens na te denken over een betere manier om gebruikers te beheren. De accounts zijn zowel voor individuele personen, applicaties, algemene gebruikersaccounts, groepen etc.
Het betreft een afdeling met developers dus Microsoft Azure, MSDN, Servers, SQL, ... zitten ook de scope. Zelf heb ik geen ervaring met AD of gebruikersbeheer.
Het effectieve beheer van de AD of de infrastructuur is gelukkig niet voor mij en ik moet ook niet alles in rekening nemen (users zitten ook in groups die verder gaan dan de lokale afdeling, zo is mijn user bv. lid van honderden unieke groepen...).

De vraag is nu waar ik goede informatie kan vinden om een werkbare en veilige structuur op te zetten voor onze afdeling (dus niet de puur technische kant). Wat zijn de aandachtspunten? Zijn er interessante nieuwigheden die ook werkbaar zijn (bv. nieuwe authenticatievormen)? Zijn er tools om te zien welke rechten users niet of amper gebruiken (want die hebben ze dan mogelijk ook niet nodig) en om te zien op welke machines een gebruiker gebruikt wordt (bv. een oude algemene account, wordt die nog gebruikt, zoja waar en wanneer?). Misschien kan ik mij voor dat laatste best richten tot de beheerders van onze AD, maar het is niet slecht om hier reeds iets over te weten

[misterjo]

Dat vakgebied, "identity & access management" is best een breed gebied binnen IT security.

Dit resulteert dan ook aan een breed scala aan producten. Active Directory is in deze eigenlijk gewoon een account en authorisatie store.

Voor privileged access management (PAM) heb je tools zoals CyberArk. (Voor admins aan te melden op systemen, session recording, pwd rotation, safes/vaults, ...)

Voor access controle kan je bijvoorbeeld gebruik maken van Active Directory d.m.v. Kerberos/ntlm authenticatie of federatie protocollen zoals OIDC/SAML. (SSO,...)
Voor deze moet je dan wel ADFS opzetten en meer modern is om gebruik te maken van Azure AD.(MFA,...)
SaaS apps is OIDC/SAML voor authenticatie. Moet je nog wel provisioning inregelen. Daar is SCIM2.0 veel voorkomende. Je kan ook Just In Time provisioning doen met SAML ofzo, maar is geen aanrader. (Want wie kuist op?)

Reporting op AD niveau geeft je ook geen inzicht wat wel of niet gebruikt wordt. Je kan hoogstens zien dat er recent nog is aangemeld met een account en welke groepen zijn toegewezen.
Wil je dat wel moet je vaak applicatie specifiek gaan checken, bijvoorbeeld voor File access etc bestaan er specifieke producten als Varonis. (Draait agents op fileservers)

Voor echt identity&access management/governance zijn er specifieke producten zoals Saviynt, Omada, Sailpoint. Dit kom je dan vaak tegen in organisaties >1000mw voor B2E en B2B use cases. B2C processen zijn heel anders opgezet.
Kleinschalig zou je is naar Azure Access packages kunnen kijken.


Maar als je het simpel wilt houden en puur op AD wilt werken zou ik eerst en vooral een naamsconventie bedenken en dat enforcen.

Eveneens policies bedenken over hoe met accounts en toegangen om te springen.
Bijvoorbeeld: iedereen een persoonlijk account, de developers een dedicated admin account voor sensitieve toegang.
Is meer vanuit security perspectief hier.

Eveneens ga je geen services draaien op je persoonlijk account, dus service accounts introduceren.
Die zijn dan weer niet persoonlijk en moet er dus een eigenaar aangewezen worden. En actief bijgehouden worden...

Al deze type identiteiten/accounts hebben natuurlijk een andere levenscycli en processen.

Bijvoorbeeld: een persoonlijke account moet afgesloten worden bij vertrek van een medewerker. (IAM 101).

Wat betreft toegangen, inventariseer en documenteer ze. Vervolgens vraag je aan senior gebruikers of ze nodig zijn en stel je profielen op. Dat noemt men RBAC, "role based access control".
Je kan dat zelf dan bijhouden in Excel en er iemand verantwoordelijk voor stellen. Krijg je ooit een audit, heb je een mooi verhaal. En keep it up to date.

Denk ook dat sommige enkel tijdelijk toegang nodig hebben in bijvoorbeeld projectmodus. En iedereen waarschijnlijk een basispakket toegang nodig heeft. Ze kan je er nog wel wat bedenken.

Alternatief kan je attributen based access gebruiken als jullie applicaties dat ondersteunen. Maar dat is een ander beestje en minder gebruikelijk in B2E context.

[Sasuke]

Lol ... die laatste zin, hoeveel drama en stress dat al veroorzaakt heeft, en hoeveel het zou gescheeld hebben als klanten/bedrijven dat nu eens gewoon zouden doen ... niet normaal

Ik denk wel dat NuKeM het niet zo technisch zoekt, IAM is in zijn functie gebied een straat te ver (geen technische toegang tot AD). Lijkt me eerder dat NuKeM gevraagd werd om een RBAC model (Role Based Access Control) samen te stellen zodat ze met 1 request de toegang goed kunnen zetten door een persoon toe te voegen aan een rol, ipv 100 verschillende groepen (en ditto aanvragen).

[misterjo]

Ik had ondertussen al een aanpassing gedaan aan m'n vorig bericht. RBAC op lokaal niveau zal waarschijnlijk de doelstelling zijn.

En ja joiner/mover/leaver processen zorgen voor een goeie dosis stress

[DarkV]

Alternatief kan je attributen based access gebruiken als jullie applicaties dat ondersteunen.

Just curious... zijn er zo bekende/common applicaties die dat ondersteunen ?