Accounts voor noodtoegang beheren in Azure AD

Het is belangrijk dat u voorkomt dat u per ongeluk wordt vergrendeld voor uw Azure Active Directory-organisatie (Azure AD), omdat u zich niet kunt aanmelden of het account van een andere gebruiker niet als beheerder kunt activeren. U kunt de gevolgen van onbedoelde gebrek aan beheerderstoegang beperken door twee of meer accounts voor toegang in noodgevallen in uw organisatie te maken.

Accounts voor toegang in noodgevallen hebben hoge bevoegdheden en worden niet toegewezen aan specifieke personen. Accounts voor noodtoegang zijn alleen bestemd voor echte noodsituaties waarin normale beheerdersaccounts niet kunnen worden gebruikt. We raden u aan om het gebruik van noodaccounts te beperken tot alleen de tijden waarop het absoluut noodzakelijk is.

Dit artikel bevat richtlijnen voor het beheren van accounts voor toegang in noodgevallen in Azure AD.

Waarom een account voor toegang in noodgevallen gebruiken

Een organisatie moet in de volgende situaties mogelijk een account voor toegang in noodgevallen gebruiken:

  • De gebruikersaccounts zijn federatief en federatie is momenteel niet beschikbaar vanwege een onderbreking van het celnetwerk of een storing van de id-provider. Als bijvoorbeeld de host van de id-provider in uw omgeving is uit bedrijf, kunnen gebruikers zich mogelijk niet aanmelden wanneer Azure AD wordt omgeleid naar hun id-provider.
  • De beheerders worden geregistreerd via Azure AD Multi-Factor Authentication en al hun afzonderlijke apparaten zijn niet beschikbaar of de service is niet beschikbaar. Gebruikers kunnen Multi-Factor Authentication mogelijk niet voltooien om een rol te activeren. Een storing in een celnetwerk verhindert bijvoorbeeld dat ze telefoongesprekken beantwoorden of sms-berichten ontvangen, de enige twee verificatiemechanismen die ze hebben geregistreerd voor hun apparaat.
  • De persoon met de meest recente globale beheerderstoegang heeft de organisatie verlaten. Azure AD voorkomt dat het laatste globale beheerdersaccount wordt verwijderd, maar het voorkomt niet dat het account on-premises wordt verwijderd of uitgeschakeld. In beide situaties kan de organisatie het account mogelijk niet herstellen.
  • Onvoorziene omstandigheden, zoals een noodgeval bij een natuurramp, waarbij een mobiele telefoon of andere netwerken mogelijk niet beschikbaar zijn.

Accounts voor toegang in noodgevallen maken

Maak twee of meer accounts voor toegang in noodgevallen. Deze accounts moeten cloudaccounts zijn die gebruikmaken van het .onmicrosoft.com-domein en die niet zijn ge federeerd of gesynchroniseerd * vanuit een on-premises omgeving.

Bij het configureren van deze accounts moet aan de volgende vereisten worden voldaan:

  • De accounts voor toegang in noodgevallen mogen niet worden gekoppeld aan een afzonderlijke gebruiker in de organisatie. Zorg ervoor dat uw accounts niet zijn verbonden met door werknemers geleverde mobiele telefoons, hardwaretokens die worden geleverd met individuele werknemers of andere werknemersspecifieke referenties. Deze voorzorgsmaatregel geldt voor gevallen waarin een afzonderlijke werknemer onbereikbaar is wanneer de referentie nodig is. Het is belangrijk om ervoor te zorgen dat geregistreerde apparaten op een bekende, veilige locatie worden bewaard met meerdere communicatiemiddelen met Azure AD.
  • Gebruik sterke verificatie voor uw accounts voor toegang in noodgevallen en zorg ervoor dat deze niet dezelfde verificatiemethoden gebruikt als uw andere beheerdersaccounts. Als uw normale beheerdersaccount bijvoorbeeld de Microsoft Authenticator gebruikt voor sterke verificatie, gebruikt u een FIDO2-beveiligingssleutel voor uw noodaccounts. Houd rekening met de afhankelijkheden van verschillende verificatiemethodenom te voorkomen dat externe vereisten aan het verificatieproces worden toegevoegd.
  • Het apparaat of de referentie mag niet verlopen of valt binnen het bereik van geautomatiseerde opschoning vanwege gebrek aan gebruik.
  • In Azure AD Privileged Identity Management moet u de roltoewijzing van de globale beheerder permanent maken in plaats van in aanmerking te komen voor uw accounts voor toegang in noodgevallen.

Ten minste één account uitsluiten van meervoudige verificatie op basis van de telefoon

Om het risico op een aanval als gevolg van een aangetast wachtwoord te verminderen, raadt Azure AD u aan multi-factor authentication te vereisen voor alle afzonderlijke gebruikers. Deze groep omvat beheerders en alle andere (bijvoorbeeld financieel verantwoordelijken) waarvan de gecompromitteerde account een aanzienlijke impact zou hebben.

Ten minste één van uw accounts voor toegang in noodgevallen mag echter niet hetzelfde meervoudige verificatiemechanisme hebben als uw andere niet-noodaccounts. Dit omvat oplossingen voor meervoudige verificatie van derden. Als u een beleid voor voorwaardelijke toegang hebt om meervoudige verificatie te vereisen voor elke beheerder voor Azure AD en andere verbonden SaaS-apps (Software as a Service), moet u accounts voor noodtoegang uitsluiten van deze vereiste en in plaats daarvan een ander mechanisme configureren. Bovendien moet u ervoor zorgen dat de accounts geen multi-factor authentication-beleid per gebruiker hebben.

Ten minste één account uitsluiten van beleid voor voorwaardelijke toegang

Tijdens een noodgeval wilt u niet dat een beleid uw toegang blokkeert om een probleem op te lossen. Als u voorwaardelijke toegang gebruikt, moet ten minste één account voor toegang in noodgevallen worden uitgesloten van alle beleidsregels voor voorwaardelijke toegang.

Richtlijnen voor federatie

Sommige organisaties gebruiken AD Domain Services en AD FS of een vergelijkbare id-provider om te federeren met Azure AD. De toegang in noodgevallen voor on-premises systemen en de toegang in noodgevallen voor cloudservices moeten afzonderlijk worden gehouden, zonder afhankelijkheid van de ene op de andere. Mastering en of sourcing van verificatie voor accounts met bevoegdheden voor toegang in noodgevallen van andere systemen voegt onnodig risico toe in het geval van een storing van deze systemen.

Accountreferenties veilig opslaan

Organisaties moeten ervoor zorgen dat de referenties voor accounts voor toegang in noodgevallen veilig blijven en alleen bekend zijn bij personen die zijn gemachtigd om ze te gebruiken. Sommige klanten gebruiken een smartcard en anderen gebruiken wachtwoorden. Een wachtwoord voor een account voor toegang in noodgevallen wordt meestal gescheiden in twee of drie delen, geschreven op afzonderlijke stukjes papier en opgeslagen in veilige, brandveilige safes die zich op veilige, afzonderlijke locaties bevinden.

Als u wachtwoorden gebruikt, moet u ervoor zorgen dat de accounts sterke wachtwoorden hebben die het wachtwoord niet laten verlopen. In het ideale geval moeten de wachtwoorden minstens 16 tekens lang zijn en willekeurig worden gegenereerd.

Aanmeldings- en auditlogboeken bewaken

Organisaties moeten aanmeldings- en auditlogboekactiviteiten van de noodaccounts bewaken en meldingen aan andere beheerders activeren. Wanneer u de activiteit op break glass-accounts bewaakt, kunt u controleren of deze accounts alleen worden gebruikt voor test- of daadwerkelijke problemen. U kunt Azure Log Analytics gebruiken om de aanmeldingslogboeken te bewaken en e-mail- en sms-waarschuwingen naar uw beheerders te activeren wanneer u zich aanmeldt met een break glass-account.

Vereisten

  1. Azure AD-aanmeldingslogboeken verzenden naar Azure Monitor.

Object-ID's van de break glass-accounts verkrijgen

  1. Meld u aan bij Azure Portal of het Azure AD-beheercentrum met een account dat is toegewezen aan de rol Gebruikersbeheerder.

  2. Selecteer Azure Active Directory > Gebruikers.

  3. Zoek het break-glass-account en selecteer de naam van de gebruiker.

  4. Kopieer het kenmerk Object-id en sla het op, zodat u het later kunt gebruiken.

  5. Herhaal de vorige stappen voor het tweede break-glass-account.

Een waarschuwingsregel maken

  1. Meld u aan bij de Azure Portal met een account dat is toegewezen aan de rol Controlebijdrager in Azure Monitor.
  2. Selecteer Alle services , voer 'log analytics' in zoeken in en selecteer vervolgens Log Analytics-werkruimten.
  3. Selecteer een werkruimte.
  4. Selecteer in uw werkruimte Waarschuwingen > Nieuwe waarschuwingsregel.
    1. Controleer onder Resource of het abonnement het abonnement is waaraan u de waarschuwingsregel wilt koppelen.

    2. Selecteer onder Voorwaarde de optie Toevoegen.

    3. Selecteer Aangepast zoeken in logboeken onder Signaalnaam.

    4. Voer onder Zoekquery de volgende query in, en voeg de object-ID's van de twee break glass-accounts in.

      Notitie

      Voor elke extra break glass-account die u wilt opnemen, voegt u nog een 'of UserId == 'ObjectGuid' toe aan de query.

      Voorbeeldquery's:

      // Search for a single Object ID (UserID)
      SigninLogs
      | project UserId 
      | where UserId == "f66e7317-2ad4-41e9-8238-3acf413f7448"
      
      // Search for multiple Object IDs (UserIds)
      SigninLogs
      | project UserId 
      | where UserId == "f66e7317-2ad4-41e9-8238-3acf413f7448" or UserId == "0383eb26-1cbc-4be7-97fd-e8a0d8f4e62b"
      
      // Search for a single UserPrincipalName
      SigninLogs
      | project UserPrincipalName 
      | where UserPrincipalName == "user@yourdomain.onmicrosoft.com"
      

      De object-ID's van de break glass-accounts toevoegen aan een waarschuwingsregel

    5. Voer onder Waarschuwingslogica het volgende in:

      • Op basis van: Aantal resultaten
      • Operator: Groter dan
      • Drempelwaarde: 0
    6. Selecteer onder Geëvalueerd op basis van de optie Periode (in minuten) voor hoe lang u de query wilt uitvoeren en de Frequentie (in minuten) voor hoe vaak u wilt dat de query wordt uitgevoerd. De frequentie moet kleiner zijn dan of gelijk zijn aan de periode.

      waarschuwingslogica

    7. Selecteer Gereed. U kunt nu de geschatte maandelijkse kosten van deze waarschuwing bekijken.

  5. Selecteer een actiegroep met gebruikers die door de waarschuwing op de hoogte moeten worden gesteld. Zie Een actiegroep maken als u er een wilt maken.
  6. Als u de e-mailmelding wilt aanpassen die wordt verzonden naar de leden van de actiegroep, selecteert u acties onder Acties aanpassen.
  7. Geef onder Waarschuwingsdetails de naam van de waarschuwingsregel op en voeg een optionele beschrijving toe.
  8. Stel het ernstniveau van de gebeurtenis in. We raden u aan deze in te stellen op Kritiek (Sev 0).
  9. Laat onder Regel inschakelen bij het maken de instelling ja staan.
  10. Als u waarschuwingen een tijdje wilt uitschakelen, selecteert u het selectievakje Waarschuwingen onderdrukken en voert u de wachttijd in voordat de waarschuwing opnieuw wordt weergegeven. Selecteer vervolgens Opslaan.
  11. Klik op Waarschuwingsregel maken.

Een actiegroep maken

  1. Selecteer Een actiegroep maken.

    een actiegroep maken voor meldingsacties

  2. Voer de naam van de actiegroep en een korte naam in.

  3. Controleer het abonnement en de resourcegroep.

  4. Selecteer onder Actietype de optie E-mail/sms/push/spraak.

  5. Voer een actienaam in, zoals Globale beheerder waarschuwen.

  6. Selecteer bij Actietype de optie E-mail/sms/push/spraak.

  7. Selecteer Details bewerken om de meldingsmethoden te selecteren die u wilt configureren en voer de vereiste contactgegevens in. Selecteer vervolgens OK om de details op te slaan.

  8. Voeg eventuele extra acties toe die u wilt activeren.

  9. Selecteer OK.

Accounts regelmatig valideren

Wanneer u medewerkers traint om accounts voor toegang in noodgevallen te gebruiken en de accounts voor toegang in noodgevallen te valideren, moet u met regelmatige tussenpozen minimaal de volgende stappen uitvoeren:

  • Zorg ervoor dat het beveiligingsbewakingspersoneel zich ervan bewust is dat de accountcontrole actief is.
  • Zorg ervoor dat het proces voor noodgevallen voor het gebruik van deze accounts gedocumenteerd en actueel is.
  • Zorg ervoor dat beheerders en beveiligingsmedewerkers die deze stappen tijdens een noodgeval moeten uitvoeren, worden getraind op het proces.
  • Werk de accountreferenties bij, met name alle wachtwoorden, voor uw accounts voor toegang in noodgevallen en controleer vervolgens of de accounts voor toegang in noodgevallen zich kunnen aanmelden en administratieve taken kunnen uitvoeren.
  • Zorg ervoor dat gebruikers Multi-Factor Authentication of selfservice voor wachtwoord opnieuw instellen (SSPR) niet hebben geregistreerd bij het apparaat of de persoonlijke gegevens van een afzonderlijke gebruiker.
  • Als de accounts zijn geregistreerd voor Multi-Factor Authentication voor een apparaat, moet u ervoor zorgen dat het apparaat toegankelijk is voor alle beheerders die het mogelijk tijdens een noodgeval moeten gebruiken voor gebruik tijdens het aanmelden of de activering van de rol. Controleer ook of het apparaat kan communiceren via ten minste twee netwerkpaden die geen gemeenschappelijke foutmodus delen. Het apparaat kan bijvoorbeeld communiceren met internet via zowel het draadloze netwerk van een faciliteit als het netwerk van een celprovider.

Deze stappen moeten regelmatig worden uitgevoerd en voor belangrijke wijzigingen:

  • Ten minste elke 90 dagen
  • Wanneer er een recente wijziging in IT-personeel is geweest, zoals een wijziging in de functie, een vertrek of een nieuwe medewerker
  • Wanneer de Azure AD-abonnementen in de organisatie zijn gewijzigd

Volgende stappen