Waarom elke onderwijsinstelling 'break-glass' accounts nodig heeft

Stel je voor: het is maandagochtend, de toetsweek begint, maar niemand kan inloggen. Een foutieve configuratie in de Conditional Access-regels of een storing bij een externe authenticatieprovider zet de hele organisatie op slot. Zelfs de globale beheerders zijn buitengesloten. De paniek slaat toe, want de 'normale' wegen om het probleem op te lossen zijn geblokkeerd.

Dit is het scenario waar je nooit in wilt belanden, maar waar je wel op voorbereid wilt zijn. Het antwoord? Een break-glass account.

Wat is een break-glass account?

Een break-glass account is het digitale equivalent van de noodknop met breekglas om bij noodgevallen een deur te ontgrendelen.

Het is een account bedoeld voor het verkrijgen van toegang tot een IT-omgeving bij noodgevallen, wanneer de normale toegang niet werkt. Break-glass accounts worden niet gebruikt voor het uitvoeren van dagelijkse taken. Ze zitten (figuurlijk) achter een glaasje dat je kapot moet maken om het account te kunnen gebruiken.

Waarom is dit essentieel (of niet)?

Er zijn verschillende situaties te bedenken waarin je niet je normale accounts kunt gebruiken. Om de actualiteit er maar eens bij te halen: ook datacenters blijken niet onverwoestbaar, het kan zomaar voorkomen dat je identity provider niet meer bereikbaar is. Bij SURF zou het kunnen voorkomen dat SURFconext niet bereikbaar is. Een strategisch ingericht noodplan met break-glass accounts zorgt ervoor dat de regie altijd in handen van de instelling blijft, ongeacht de omstandigheden.

Het inrichten van noodtoegang is geen verplichting vanuit compliance, maar een wel een belangrijke maatregel om beschikbaarheid van diensten te waarborgen bij noodgevallen.

De keuze voor het inzetten van break-glass accounts dient gebaseerd te zijn op risico inschatting. In een omgeving waar je niet dagelijks mutaties hoeft door te voeren kun je best zonder een break-glass account. Als je geen dagen kunt wachten totdat toegang is hersteld, dan zul je dit moeten inrichten. 

Hoe richt je dit slim (en veilig) in?

Hier zijn de zes belangrijkste uitgangspunten voor een praktische implementatie.

1. Creëer twee aparte break-glass accounts

Vertrouw niet op één enkel account. Maak minimaal twee noodaccounts aan. Zo heb je altijd een back-up voor je back-up.

2. Omzeil de standaard paden

Het heeft geen zin om een noodaccount te hebben dat afhankelijk is van dezelfde techniek als je normale accounts. Je wilt je immers beschermen tegen het falen van die techniek. Dit betekent:

  • Sluit deze accounts expliciet uit van Conditional Access-regels die je hebt geconfigureerd
  • Gebruik geen MFA die afhankelijk is van een mobiele telefoon of een on-premises infrastructuur. Gebruik in plaats daarvan bijvoorbeeld een FIDO2-beveiligingssleutel en een zeer complex, fysiek opgeslagen wachtwoord in een altijd toegankelijke password vault.

3. Gebruik de cloud-native domeinnaam en identity provider

Voor noodtoegang wil je niet afhankelijk zijn van domeinfederatie of gesynchroniseerde identiteiten. Voor noodtoegang tot een cloudomgeving maak je daarom gebruik van de identity provider van de betreffende cloud.

Denk daarbij ook na over de domeinnaam die je gebruikt. Bij Microsoft Azure gebruik je bijvoorbeeld accountnamen die eindigen op *.onmicrosoft.com. 

4. Monitoring is de sleutel

Noodaccounts hebben beheerpermissies nodig. Omdat ze veel rechten hebben en buiten de normale beveiligingsregels vallen, wil je direct weten wanneer ze worden gebruikt. Stel een alarm in dat een melding naar je security-team stuurt en/of naar je SIEM omgeving zodra er met een break-glass account wordt ingelogd. Het gebruik ervan moet immers altijd een bewuste, zeldzame gemaakte keuze zijn, die je vooraf meldt aan je ciso/secops team.

5. Veilig achter slot en grendel

De inloggegevens van deze accounts bewaar je fysiek veilig. Denk aan een kluis op de campus of bij een vertrouwde partij. Deel de toegang: persoon A weet waar de kluis staat, persoon B heeft de sleutel of code; of persoon A heeft toegang tot het wachtwoord, persoon B heeft toegang tot de tweede factor (bv. FIDO2 sleutel). Dus 1 persoon kan nooit zelfstandig inloggen met een break-glass account.

6. Na inzet

Na inzet van het break-glass account roteer je de sleutels en evalueer je het gebruik. Was de inzet van het break-glass account achteraf gezien noodzakelijk of waren er andere maatregelen te treffen die inzet hadden kunnen voorkomen. Pas waar nodig de procedure aan op basis van wat je geleerd hebt.

Wil je hulp bij het technisch inrichten van deze accounts voor je SURFcumulus cloudomgeving? Neem dan contact op met ons cloud-team.

Brandmelder
Brandmelder

Auteur

Reacties

Dit artikel heeft 0 reacties