}

RBAC: sleutelrol, beheer en evolutie

Veel organisaties zijn bezig met RBAC in meer of mindere vorm; verkenning, project, implementatie, vulling of beheer. We zien dat dit gestuurd wordt door normen als NEN7510, waarin voornamelijk staat beschreven dat je moet kunnen aantonen waarom iemand een autorisatie nodig heeft en hoe deze tot stand is gekomen. Inmiddels weten we dat RBAC niet een heilige graal is, maar dat veel implementaties stuk lopen door de te grote scope en complexiteit. We combineren RBAC liever met claim-based autorisaties op basis van workflow, waarbij de aanvragen voor extra autorisaties uit de organisatie komen en daar ook worden goedgekeurd en verwerkt.

Bij de implementatie van RBAC gaat het vaak om de vraag: hoe ver moet je gaan? Een goede start is om te beginnen bij de structuur van de organisatie en deze te verdelen in lagen. Als we een grote gemeente in Nederland (+- 7500 medewerkers) analyseren komen we tot de volgende verdeling:

  1. 25 diensten
  2. 100 afdelingen
  3. 250 teams
  4. 500 functies

Bovenstaande gegevens gelden als we per organisatielaag een dekking van 80% willen realiseren. Er zijn immers veel meer dan 500 functies, maar deze zijn niet interessant voor RBAC, we zijn alleen op zoek naar de top 80%.

Op basis van bovenstaande gegevens kunnen we de RBAC matrix wat betreft rollen vullen voor deze 4 organisatielagen, elk item in de organisatielaag is dan een rol. Je kunt je afvragen of het nut heeft om de functie-laag te vullen, want dan heb je het meteen over 500 rollen. Vervolgens gaan we van bovenaf, dus startend bij dienst, invullen welke autorisaties bij elke rol horen. Op deze manier vult het systeem zich dus steeds verder aan.

Wat we echter hierbij missen is een unieke combinatie van een medewerker. We hebben bijvoorbeeld gedefinieerd wat elke medewerker mag bij dienst X en wat alle medewerkers met functie Y mogen, maar we missen op deze manier een medewerker met de combinatie van dienst X en functie Y. Dit noemen we de sleutelrol. Een sleutelrol is dus een virtuele rol die altijd een combinatie is van organisatierollen. Bij de start van een RBAC systeem zijn deze rollen niet gedefinieerd, maar door links te leggen tussen organisatielagen komen deze rollen tot stand. Op deze manier is het mogelijk om licht te beginnen en het RBAC model steeds verder te laten evolueren.

SAP koppeling met Active Directory

Bij 1 van grootste ziekenhuizen van Nederland heb ik recentelijk een SAP koppeling naar Active Directory opgeleverd met behulp van UMRA van Tools4ever. Het scenario is dat SAP elke x minuten een feed aanleverde in CSV formaat met alle wijzigingen, die vervolgens in Active Directory verwerkt moeten worden. Met behulp van specifieke codes voor bepaalde mutaties (instroom, doorstroom, uitstroom) weet de UMRA engine welke business logica uitgevoerd moet worden.

Lees meer

User- en toegangsbeheer in cloud applicaties: een uitdaging

Cloud applicaties als Google Apps, Salesforce.com, GoToMeeting, Office 365, itslearning, AFAS Online en RAET Online worden steeds meer ingezet in het bedrijfsleven. Bij cloud applicaties is het lastiger om exact te weten wie toegang heeft tot welke applicaties en data. Leveranciers van cloud oplossingen geven helaas weinig prioriteit aan het ontwikkelen van beter beheer van user accounts en toegangsrechten in hun applicaties.

Lees meer

De vooroordelen van Single Sign On

Veel IT managers en Security Officers zijn terughoudend als het gaat om het implementeren van een Single Sign On (SSO) oplossing, hoewel de voordelen van SSO duidelijk zijn. Namelijk onder andere gebruikersgemak voor de eindgebruiker en minder wachtwoord reset calls naar de helpdesk. De terughoudendheid ten aanzien van SSO wordt in de hand gewerkt door een aantal vooroordelen over SSO.

Lees meer

Single Sign On met terminal emulatie (VAX64, AS/400, Linux, SSH)

We zien dat veel organisaties steeds bewuster bezig zijn met security, waarschijnlijk mede ingegeven door regelgeving zoals NEN7510 en ICT-audit trajecten. Naast het autorisatiebeheer binnen applicaties, waar we al verschillende oplossingen voor bieden zijn we ook actief op het authenticatie-vlak, namelijk met een Single Sign On (SSO) oplossing.

Lees meer

Afas koppeling met Lotus Notes adresboek

Met UMRA doen we veel met koppelingen vanuit HRM-systemen naar de Active Directory om zo het user account beheer te automatiseren. UMRA is in staat om met 1 van de 130+ connectors gegevens te verzamelen die belangrijk zijn voor het aanmaken, muteren en uitschakelen van user accounts. We kunnen bijvoorbeeld uit een HRM systeem lezen welke gebruikers nieuw in dienst zijn of nog gaan komen, wijzigingen in functies, overplaatsingen naar andere afdelingen en alle andere gegevens die aan een dienstverband zijn gekoppeld.

Lees meer