SBB Microsoft Active Directory Domain Services (AD DS)

Solution architect: Rob de Groot

Diensten informatie

Het portfoliomanagement vult deze informatie aan.

Kosten en verantwoordelijkheden

Aan elk SBB zitten kosten aan verbonden. Dit gaat hierover. Daarnaast moet er worden uitgelegd aan de afnemer welke taken zelf moeten worden gedaan en welke taken bij de beherende partij liggen.

Kosten

Additionele specificaties:

AD DS is een generieke directorydienstvoorziening binnen de IAM- en infrastructuurarchitectuur. De voorziening ondersteunt centrale identiteits- en accountgerelateerde functies voor met name on-premise en hybride gekoppelde omgevingen. Gebruik van AD DS brengt structurele beheerlast met zich mee op het gebied van hardening, patching, recovery, monitoring en delegatie van beheer.

Bijvoorbeeld: kosten worden 2 jaar doorbelast en daarna door de beherende partij opgenomen in de instandhouding of bijvoorbeeld dat kosten per maand worden doorbelast

Verantwoordelijkheden

Beherende partij

• De beherende partij is verantwoordelijk voor:

  • de technische beschikbaarheid en continuïteit van het AD DS-platform;
  • installatie, configuratie en lifecyclemanagement van domain controllers;
  • patchmanagement, hardening en beveiligingsmonitoring;
  • back-up, restore en disaster recovery van directorydiensten;
  • beheer van trusts, sites, services en replicatie;
  • beheer van technische directoryconfiguratie, zoals OU-structuren, policies en delegatiemodellen;
  • waarborgen van logging, auditing en integriteit van directorygegevens;
  • beheer van de koppelingen met afhankelijke infrastructuurdiensten.
  • AD DNS zones (functioneel)

Je kan hier verwijzen naar ander bouwblokken die onderliggend zijn aan deze SBB. Bijvoorbeeld het beheer van hardware in het datacenter. Dan valt dat ook onder deze stap.

Onderliggende bouwstenen:

• Windows / Platform team (WinOps)
  • OS lifecycle & patching
  • OS hardening
  • VM / host provisioning
  • OS monitoring
• DNS / Netwerk team (Bijv. Infoblox)
  • DNS-platform
  • generieke zones
  • resolutie / forwarding
• Hosting / Datacenter / Cloud
  • compute
  • storage
  • availability
  • back-up infra
• Security / SOC
  • monitoring (SIEM)
  • detectie op AD events
  • incident response

Afnemende partij 

• De afnemende partij is verantwoordelijk voor:

  • rechtmatig en doelgebonden gebruik van de dienst;
  • het aanvragen en gebruiken van accounts, groepen en rechten conform vastgestelde processen;
  • naleving van IAM-, security- en compliancekaders;
  • het tijdig aanleveren van juiste brongegevens voor identiteiten en bevoegdheden;
  • het gebruik van AD DS uitsluitend binnen de architectonische kaders waarvoor de voorziening bedoeld is.

Roadmap en Lifecycle

Het productmanagement, dus de productowner of productmanager, vult deze informatie aan.

Roadmap en lifecycle planning zijn twee verschillende dingen. In de lifecycle wordt aangegeven wat de beschikbare versies zijn en tot wanneer deze worden ondersteund en de roadmap toont wanneer nieuwe functionaliteiten worden aangeboden door deze oplossing. Nieuwe functionaliteit is altijd gekoppeld aan een ABB. 

Microsoft Active Directory Domain Services is een rol binnen Microsoft Windows Server en volgt daarmee de lifecycle van de toegepaste Windows Server-versies. De lifecycle van deze SBB wordt daarom bepaald door:

• De supporttermijnen van de gebruikte Windows Server-versies;
• De toepasbaarheid van die versies binnen de infrastructuurstandaarden van de organisatie;
• Het moment waarop security- en compliance-eisen nopen tot migratie of vervanging.

Voor deze voorziening geldt:

• Alleen door de organisatie toegestane en ondersteunde Windows Server-versies mogen worden ingezet;
• Verouderde versies moeten planmatig worden uitgefaseerd;
• Lifecyclemanagement moet onderdeel zijn van reguliere platformsturing en niet reactief plaatsvinden;
• Nieuwe domain controllers worden alleen uitgerold op ondersteunde platformversies.

Lifecycle

Roadmap

Plan voor 202x

• Functionaliteiten die worden toegevoegd

  
  

Architectuur

Microsoft Active Directory Domain Services is een solution bouwblok voor centrale directorydiensten binnen de KA en nieuwe werkplek infrastructuur. Dit SBB voorziet in:

• Accounts, groepen, computerobjecten en organisatorische eenheden (OU's);
• Authenticatie en Autorisatie binnen een Windows-domeinomgeving;
• Beleidsafdwinging via Group Policy;
• Ondersteuning van domein-, forest- en truststructuren;
• Replicatie van directorygegevens tussen domain controllers binnen een Forest en Domain.

Binnen de IAM-architectuur vervult AD DS geen rol als leidende bron voor digitale identiteiten op enterprise-niveau. AD DS is primair een technische directory- en authenticatievoorziening. Digitale Identiteitsgegevens en bevoegdheden behoren in beginsel te worden bestuurd vanuit daarvoor aangewezen bron- en beheerprocessen, waarna AD DS deze gegevens ontvangt of toepast binnen de grenzen van zijn functie.

Deze SBB heeft relaties met de volgende ABB’s:

• Internal (On-Premise) Authentication
• Identity Lifecycle Management
• Provisioning
• Role & Attribute Management
• Access Control

AD DS mag niet worden gepositioneerd als generieke oplossing voor alle IAM-vraagstukken. In het bijzonder geldt:

• AD DS is geen IGA-oplossing;
• AD DS is geen volwaardige federatieve authenticatievoorziening;
• AD DS is niet bedoeld als enige bron voor identiteiten of autorisatiebeleid op keten- of enterprise-niveau;

Afhankelijkheden

Geef aan welke technische afhankelijkheden er zijn voor deze SBB. Dit is enkel een lijst met links naar andere SBBs met een beschrijving wat de afhankelijkheid is. Dit hoeft maar 1 laag diep, dus een directe afhankelijkheid. Door gebruik te maken van links ontstaat er vanzelf een ketenoverzicht.

Technische architectuur

De technische inrichting van AD DS bestaat uit één of meer domeinen binnen een foreststructuur, opgebouwd uit domain controllers die directorygegevens repliceren. De inrichting omvat ten minste:

• Domain controllers verspreid conform eisen aan beschikbaarheid, performance en herstelbaarheid;
• Logische segmentatie via OU-structuren;
• Toepassing van Group Policy voor beleidsconfiguratie;
• Inrichting van sites en services ter ondersteuning van replicatie en netwerkoptimalisatie;
• Beheer van security groups en serviceaccounts;
• Afscherming en segmentatie van beheerinterfaces en beheerrechten.

Belangrijke technische uitgangspunten zijn:

• Domain controllers worden hardend ingericht volgens CIS baseline;
• Beheer vindt plaats via strikt gescheiden accounts;
• Directe handmatige mutaties in productie worden beperkt waar centrale provisioning mogelijk is;
• Wijzigingen in directorystructuur, policies en delegaties zijn herleidbaar en toetsbaar;
• Herstelprocedures voor directorydiensten zijn aantoonbaar aanwezig en jaarlijks getest;
• Logging en auditing zijn ingericht op detectie van misbruik, privilege escalation en ongeautoriseerde wijzigingen;
• Beheer wordt gestandaardiseerd en geautomatiseerd.

Voor de technische positionering binnen Rijkswaterstaat geldt:

• AD DS is primair bedoeld voor interne directory- en domeindiensten;
• Koppelingen met cloud- en SaaS-omgevingen verlopen niet rechtstreeks vanuit willekeurige directorylogica, maar via daarvoor bedoelde integratie- en synchronisatievoorzieningen;
• Technische inrichting moet aansluiten op securitykaders, patchkaders, recovery-eisen en de bredere IAM-doelarchitectuur.

Technische documentatie

 Dit bevat de technische documentatie. Dit is het HLD en de LLD.

- De HLD staat in Confluence en volgt het Arc42 framework. Onderstaand ook een knop om hiervoor een template te openen.

- De LLD mag een link zijn naar de documentatie op een externe omgeving. Dit omdat het mogelijk geïntegreerd is met het ontwikkelproces, of omdat het hoog-vertrouwelijke informatie bevat. Het is ook mogelijk om dit in Confluence te zetten.

Voor iedere implementatie van dit SBB hoort de volgende documentatie up-to-date aanwezig te zijn:

• High Level Design (HLD) op basis van ARC42 template;
• Low Level Design (LLD);
• Installatie Handleiding;
• Beheer Handleiding;
• Recovery- en restoreprocedures;
• Hardening-baseline CIS;
• Patch- en lifecycle-overzicht;
• Logging- en monitoringinrichting;
• Overzicht van trusts, koppelingen en afhankelijkheden;
• Testplan
• Eventueel Infrastructure as Code-documentatie indien van toepassing.

Maak een HLD: