Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Werkt de gewone keten niet, of is zij mogelijk aangetast, dan blijft de noodroute over: noodaccounts, certificaten en lokale beheerders uit een kluis buiten het platform. Dit onderwerp legt de noodroute in twee trappen vast, wat er bij uitval van iedere voorziening blijft werken, en hoe de voorzieningen worden hersteld zonder dat ingetrokken toegang terugkeert.
Noodtoegang die binnen het platform ligt, is weg als juist de cel is uitgevallen of aangetast. Daarom ligt zij buiten het platform, en vraagt ieder gebruik twee personen en een melding aan het SOC. Na herstel uit een back-up zou een eerder ingetrokken toegang weer kunnen werken; daarom worden de intrekkingen eerst herhaald voordat iemand zich aanmeldt.
Noodtoegang ligt buiten het platform, in een kluis, en werkt ook als de toegangsvoorziening is uitgevallen of aangetast.
Afgewezen alternatief: noodaccounts in het geheimenbeheer. Bij uitval of aantasting van de cel is de noodtoegang dan ook weg.
De noodroute heeft twee trappen. Trap 1 geldt als het identiteitsbeheer of de goedkeuringsketen niet werkt, of als een aanvaller ze mogelijk heeft bereikt: het noodaccount van de cel in de toegangsvoorziening, en voor knooppunten een SSH-certificaat van ten hoogste 1 uur uit het geheimenbeheer. Trap 2 geldt als de toegangsvoorziening niet werkt of mogelijk is aangetast: de certificaat-kubeconfig per platformcluster, voor gehoste clusters het beheerkubeconfig via de noodtoegang van het clusterbeheer, de lokale beheerders, ook van midPoint, Forgejo en de master-realm, een SSH-sleutel uit de kluis en de noodwerkplek. Het geheimenbeheer opent in trap 2 alleen met een nieuw roottoken uit drie van de vijf herstelsleutels, dat direct daarna wordt ingetrokken.
Foutopsporing op een knooppunt bij een verhoging gaat via een debugsessie van de clusterbesturing, niet via SSH; SSH naar knooppunten bestaat alleen in de noodroute. Het roottoken staat bij Sleutels, ontgrendeling en versleuteling.
Voor beide trappen halen twee personen de noodtoegang uit de kluis, en het SOC wordt waar mogelijk vooraf ingelicht. Ieder gebruik wordt binnen 5 minuten bij het SOC gemeld. Daarna wordt de noodtoegang vervangen en een gebruikt certificaat ongeldig gemaakt, en staan de noodwijzigingen binnen 1 werkdag in code.
Ook urgente wijzigingen bij stilstand van het portaal of het leverpad lopen zo. De dienstdoende platformbeheerder start de noodroute, met een tweede persoon. Beproefd ieder half jaar met het SOC.
Per cel zijn er twee noodaccounts in Keycloak, met een wachtwoord van ten minste 30 tekens. Daarnaast heeft ieder platformcluster een certificaat-kubeconfig en ieder apparaat een lokale beheerder, zoals van iLO en NetScaler, die niet van de toegangsvoorziening afhangen. Alles ligt gesplitst in een fysieke kluis; ieder gebruik wordt in de audit en de aanmeldgebeurtenissen herkend.
Bewijs: de kluisregistratie met de twee personen per uitgifte en een halfjaarlijkse test van iedere route met het SOC. De noodaccounts zijn de enige lokale gebruikers van de toegangsvoorziening.
Wijzigingen aan de platforminrichting lopen via versiebeheer. Rechtstreeks wijzigen, een noodwijziging, kan alleen met een verhoging of via de noodroute. Zij staat binnen 1 werkdag in code of is ongedaan gemaakt, en wordt achteraf beoordeeld; tot dan is de automatische terugzetting voor dat onderdeel geregistreerd opgeschort.
Invulling: Argo CD met automatische zelfcorrectie en beleid in de stand enforce, een aparte groep voor de noodroute, en een registratie van de noodwijziging in de opslagplaats Draaiboeken. Controle: een rapport van afwijkingen en registraties, en een melding van het SOC bij wijzigingen buiten versiebeheer.
Uitval van één exemplaar of server onderbreekt de aanmelding en de verhoging niet. Exemplaren van één voorziening en de beheerservers van één pool staan op verschillende knooppunten, in verschillende rekken.
Reden: de toegang draagt al het beheer. Beproefd met de uitvalproef bij de acceptatie.
Per uitval ligt vast wat er gebeurt, wat blijft werken en hoe het herstelt. Omdat de databases lokaal staan, werken aanmelding en identiteitsbeheer door terwijl het opslagcluster wordt hersteld; alleen de sessieopname hangt ervan af.
| Uitval | Gevolg | Wat blijft werken | Herstel |
|---|---|---|---|
| Eén exemplaar, knooppunt of rek | Geen merkbare onderbreking; een sessie op het getroffen exemplaar breekt af | Alle functies via de overige exemplaren | Automatische herstart; opnieuw aanmelden |
| Opslagcluster | Geen opname, dus geen bevoorrechte sessie via de gateway | Aanmelding, identiteitsbeheer, uitrol en toepassingen | Beheer van het opslagcluster via de noodwerkplek |
| Toegangsvoorziening | Geen nieuwe aanmelding van personen | OpenShift-toegangsbewijzen tot hun verloop, ten hoogste 1 uur; technische identiteiten en toepassingen | Noodroute trap 2; herstel uit back-up |
| Identiteitsbeheer | Geen instroom, wijziging, verhoging of automatische intrekking | Aanmelding met de bestaande groepen | Intrekking en verhoging via noodroute trap 1, rechtstreeks in de toegangsvoorziening |
| Directory of RWS-HR | Geen nieuwe identiteiten; zonder directory geen aanmelding met wachtwoord | Lopende sessies; noodaccounts | Herstel door de leverende dienst; grote verschillen daarna in simulatiemodus |
| Gateway of beheerservers | Geen bevoorrechte sessies via het gewone pad | Gewoon werk via de gepubliceerde API en versiebeheer | Noodwerkplek; herbouw uit code |
| Basisdienstencluster | Geen aanmelding, geheimenbeheer en gateway in de cel, in de eerste levering ook niet op het vlootcluster | Clusters en toepassingen op hun laatste inrichting | Noodroute trap 2; herbouw van het basisdienstencluster |
| Cel | Alle voorzieningen van de cel | De andere cel, vanaf groeipadstap 2 | Vlootbrede aanmelding naar cel 2; herstel van de cel |
| Toegangsvoorziening of identiteitsbeheer aangetast | Toegangsbewijzen en toekenningen onbetrouwbaar | Noodtoegang buiten de getroffen omgeving | Sessies beëindigen, realmsleutels en clientgeheimen vervangen, herbouw uit code, beheerrechten herbeoordelen; is het beheer geraakt, dan vanuit de herstelkern |
De eigen bewakingsvoorziening krijgt vanaf groeipadstap 2 een eigen exemplaar van Keycloak op haar cluster, gevuld door het identiteitsbeheer van de cel met alleen de groepen voor bewaking en onderzoek, en met een noodaccount in de kluis. Zo werkt zij zonder de toegangsvoorziening van de cel; zonder identiteitsbeheer trekt IAM-beheer rechtstreeks in.
De eerste factor controleert zij tegen de directory.
Na herstel komen de voorzieningen terug in een vaste volgorde: geheimenbeheer, toegangsvoorziening, identiteitsbeheer en beheerwerkplek. Bij de start vraagt de toegangsvoorziening haar database, een servercertificaat en de naam- en tijdvoorziening, voor aanmelding met wachtwoord ook de directory. Het identiteitsbeheer vraagt ook zijn keystore, die zonder het geheimenbeheer te herstellen is.
De herstelvolgorde van het hele basisdienstencluster staat bij Startketen, opslag en herstel.
Na herstel van de toegangsvoorziening of het identiteitsbeheer uit een back-up worden eerst de bronnen vergeleken en de intrekkingen sinds het herstelpunt herhaald, uit de audit bij het SOC. Pas daarna kunnen personen zich weer aanmelden, zodat ingetrokken toegang niet terugkeert.
Beproefd met een herstelproef met een ingetrokken testidentiteit: na herstel werkt een na het herstelpunt ingetrokken toegang niet.
De voorzieningen zijn uit code op te bouwen. Dagelijks gaat een export naar de herstelkern: accounts, rollen, toekenningen, technische identiteiten, het rollenmodel en de realm, zonder geheimen. Zo zijn de identiteiten te herstellen zonder gezonde cel.
Beproefd met een opbouwproef volgens de beproevingskalender.
De herstelomgeving krijgt een realm herstel in de toegangsvoorziening van de gezonde cel, uit code en met een tijdelijke rol; anders een noodaanmelding uit de kluis. De realm wordt met de omgeving verwijderd.