Gebruikers en groepen voorbereiden voor Azure Information Protection

Notitie

Zoekt u Microsoft Purview Informatiebeveiliging, voorheen Microsoft Information Protection (MIP)?

De Azure Information Protection-invoegtoepassing wordt buiten gebruik gesteld en vervangen door labels die zijn ingebouwd in uw Microsoft 365-apps en -services. Meer informatie over de ondersteuningsstatus van andere Azure Information Protection-onderdelen.

De nieuwe Microsoft Information Protection-client (zonder de invoegtoepassing) is momenteel beschikbaar als preview-versie en is gepland voor algemene beschikbaarheid.

Voordat u Azure Information Protection voor uw organisatie implementeert, moet u ervoor zorgen dat u accounts hebt voor gebruikers en groepen in Microsoft Entra-id voor de tenant van uw organisatie.

Er zijn verschillende manieren om deze accounts te maken voor gebruikers en groepen, waaronder:

  • U maakt de gebruikers in de Microsoft 365-beheercentrum en de groepen in het Exchange Online-beheercentrum.

  • U maakt de gebruikers en groepen in Azure Portal.

  • U maakt de gebruikers en groep met behulp van Azure AD PowerShell- en Exchange Online-cmdlets.

  • U maakt de gebruikers en groepen in uw on-premises Active Directory en synchroniseert deze met Microsoft Entra-id.

  • U maakt de gebruikers en groepen in een andere directory en synchroniseert deze met Microsoft Entra-id.

Wanneer u gebruikers en groepen maakt met behulp van de eerste drie methoden uit deze lijst, met één uitzondering, worden ze automatisch gemaakt in Microsoft Entra ID en kan Azure Information Protection deze accounts rechtstreeks gebruiken. Veel bedrijfsnetwerken gebruiken echter een on-premises directory om gebruikers en groepen te maken en te beheren. Azure Information Protection kan deze accounts niet rechtstreeks gebruiken; u moet ze synchroniseren met Microsoft Entra-id.

De uitzondering waarnaar in de vorige alinea wordt verwezen, is dynamische distributielijsten die u voor Exchange Online kunt maken. In tegenstelling tot statische distributielijsten worden deze groepen niet gerepliceerd naar Microsoft Entra-id en kunnen ze dus niet worden gebruikt door Azure Information Protection.

Hoe gebruikers en groepen worden gebruikt door Azure Information Protection

Er zijn drie scenario's voor het gebruik van gebruikers en groepen met Azure Information Protection:

Voor het toewijzen van labels aan gebruikers wanneer u het Azure Information Protection-beleid configureert, zodat labels kunnen worden toegepast op documenten en e-mailberichten. Alleen beheerders kunnen deze gebruikers en groepen selecteren:

  • Het standaardbeleid van Azure Information Protection wordt automatisch toegewezen aan alle gebruikers in de Microsoft Entra-id van uw tenant. U kunt echter ook extra labels toewijzen aan opgegeven gebruikers of groepen met behulp van een bereikbeleid.

Voor het toewijzen van gebruiksrechten en toegangsbeheer wanneer u de Azure Rights Management-service gebruikt om documenten en e-mailberichten te beveiligen. Beheer istrators en gebruikers kunnen deze gebruikers en groepen selecteren:

  • Gebruiksrechten bepalen of een gebruiker een document of e-mailbericht kan openen en hoe hij of zij het kan gebruiken. Bijvoorbeeld, of ze het alleen kunnen lezen of lezen en afdrukken, of lezen en bewerken.

  • Besturingselementen voor toegang omvatten een vervaldatum en of een verbinding met internet vereist is voor toegang.

Voor het configureren van de Azure Rights Management-service ter ondersteuning van specifieke scenario's, en daarom selecteren alleen beheerders deze groepen. Voorbeelden zijn het configureren van het volgende:

  • Supergebruikers, zodat aangewezen services of personen versleutelde inhoud kunnen openen, indien nodig voor eDiscovery of gegevensherstel.

  • Gedelegeerd beheer van de Azure Rights Management-service.

  • Onboarding-besturingselementen ter ondersteuning van een gefaseerde implementatie.

Vereisten voor Azure Information Protection voor gebruikersaccounts

Voor het toewijzen van labels:

  • Alle gebruikersaccounts in Microsoft Entra-id kunnen worden gebruikt voor het configureren van beleidsregels binnen het bereik die extra labels aan gebruikers toewijzen.

Voor het toewijzen van gebruiksrechten en toegangsbeheer en het configureren van de Azure Rights Management-service:

  • Voor het autoriseren van gebruikers worden twee kenmerken in Microsoft Entra-id gebruikt: proxyAddresses en userPrincipalName.

  • Het kenmerk Microsoft Entra proxyAddresses slaat alle e-mailadressen voor een account op en kan op verschillende manieren worden ingevuld. Een gebruiker in Microsoft 365 met een Exchange Online-postvak heeft bijvoorbeeld automatisch een e-mailadres dat is opgeslagen in dit kenmerk. Als u een alternatief e-mailadres voor een Microsoft 365-gebruiker toewijst, wordt dit ook opgeslagen in dit kenmerk. Het kan ook worden ingevuld door de e-mailadressen die vanuit on-premises accounts worden gesynchroniseerd.

    Azure Information Protection kan elke waarde in dit microsoft Entra proxyAddresses-kenmerk gebruiken, mits het domein is toegevoegd aan uw tenant (een 'geverifieerd domein'). Voor meer informatie over het verifiëren van domeinen:

  • Het kenmerk Microsoft Entra userPrincipalName wordt alleen gebruikt wanneer een account in uw tenant geen waarden heeft in het kenmerk Microsoft Entra proxyAddresses. U maakt bijvoorbeeld een gebruiker in Azure Portal of maakt een gebruiker voor Microsoft 365 die geen postvak heeft.

Gebruiksrechten en toegangsbeheer toewijzen aan externe gebruikers

Naast het gebruik van de Microsoft Entra proxyAddresses en Microsoft Entra userPrincipalName voor gebruikers in uw tenant, gebruikt Azure Information Protection deze kenmerken ook op dezelfde manier om gebruikers van een andere tenant te autoriseren.

Andere autorisatiemethoden:

  • Voor e-mailadressen die zich niet in Microsoft Entra ID bevinden, kan Azure Information Protection deze autoriseren wanneer ze worden geverifieerd met een Microsoft-account. Niet alle toepassingen kunnen beveiligde inhoud openen wanneer een Microsoft-account wordt gebruikt voor verificatie. Meer informatie

  • Wanneer een e-mailbericht wordt verzonden met office 365-berichtversleuteling met nieuwe mogelijkheden voor een gebruiker die geen account in Microsoft Entra-id heeft, wordt de gebruiker eerst geverifieerd met federatie met een sociale id-provider of met behulp van een eenmalige wachtwoordcode. Vervolgens wordt het e-mailadres dat is opgegeven in de beveiligde e-mail gebruikt om de gebruiker te autoriseren.

Azure Information Protection-vereisten voor groepsaccounts

Voor het toewijzen van labels:

  • Als u een bereikbeleid wilt configureren dat extra labels toewijst aan groepsleden, kunt u elk type groep gebruiken in Microsoft Entra-id met een e-mailadres dat een geverifieerd domein voor de tenant van de gebruiker bevat. Een groep met een e-mailadres wordt vaak aangeduid als een groep met e-mail.

    U kunt bijvoorbeeld een beveiligingsgroep met e-mail, een statische distributiegroep en een Microsoft 365-groep gebruiken. U kunt geen beveiligingsgroep (dynamisch of statisch) gebruiken omdat dit groepstype geen e-mailadres heeft. U kunt ook geen dynamische distributielijst van Exchange Online gebruiken omdat deze groep niet wordt gerepliceerd naar Microsoft Entra-id.

Voor het toewijzen van gebruiksrechten en toegangsbeheer:

  • U kunt elk type groep gebruiken in Microsoft Entra-id met een e-mailadres dat een geverifieerd domein voor de tenant van de gebruiker bevat. Een groep met een e-mailadres wordt vaak aangeduid als een groep met e-mail.

Voor het configureren van de Azure Rights Management-service:

  • U kunt elk type groep gebruiken in Microsoft Entra-id met een e-mailadres van een geverifieerd domein in uw tenant, met één uitzondering. Deze uitzondering is wanneer u onboardingbesturingselementen configureert voor het gebruik van een groep, die een beveiligingsgroep moet zijn in Microsoft Entra ID voor uw tenant.

  • U kunt elke groep in Microsoft Entra-id (met of zonder e-mailadres) gebruiken vanuit een geverifieerd domein in uw tenant voor gedelegeerd beheer van de Azure Rights Management-service.

Gebruiksrechten en toegangsbeheer toewijzen aan externe groepen

Naast het gebruik van de Microsoft Entra-proxyAddresses voor groepen in uw tenant, gebruikt Azure Information Protection dit kenmerk ook op dezelfde manier om groepen van een andere tenant te autoriseren.

Accounts van on-premises Active Directory gebruiken voor Azure Information Protection

Als u accounts hebt die on-premises worden beheerd die u wilt gebruiken met Azure Information Protection, moet u deze synchroniseren met Microsoft Entra-id. Voor een gemakkelijke implementatie raden we u aan Microsoft Entra Verbinding maken te gebruiken. U kunt echter elke directorysynchronisatiemethode gebruiken waarmee hetzelfde resultaat wordt bereikt.

Wanneer u uw accounts synchroniseert, hoeft u niet alle kenmerken te synchroniseren. Zie de sectie Azure RMS in de Microsoft Entra-documentatie voor een lijst met kenmerken die moeten worden gesynchroniseerd.

In de lijst met kenmerken voor Azure Rights Management ziet u dat voor gebruikers, de on-premises AD-kenmerken van e-mail, proxyAddresses en userPrincipalName vereist zijn voor synchronisatie. Waarden voor mail en proxyAddresses worden gesynchroniseerd met het kenmerk Microsoft Entra proxyAddresses. Zie Hoe het kenmerk proxyAddresses wordt ingevuld in Microsoft Entra-id voor meer informatie

Bevestigen dat uw gebruikers en groepen zijn voorbereid voor Azure Information Protection

U kunt Azure AD PowerShell gebruiken om te bevestigen dat gebruikers en groepen kunnen worden gebruikt met Azure Information Protection. U kunt PowerShell ook gebruiken om de waarden te bevestigen die kunnen worden gebruikt om ze te autoriseren.

Notitie

Azure AD- en MSOnline PowerShell-modules zijn vanaf 30 maart 2024 afgeschaft. Lees de afschaffingsupdate voor meer informatie. Na deze datum is ondersteuning voor deze modules beperkt tot migratieondersteuning voor Microsoft Graph PowerShell SDK en beveiligingsoplossingen. De afgeschafte modules blijven functioneren tot en met 30 maart 2025.

Het is raadzaam om te migreren naar Microsoft Graph PowerShell om te communiceren met Microsoft Entra ID (voorheen Azure AD). Raadpleeg de veelgestelde vragen over migratie voor veelgestelde vragen over migratie. Opmerking: versies 1.0.x van MSOnline kunnen na 30 juni 2024 onderbrekingen ondervinden.

Als u bijvoorbeeld de V1 PowerShell-module voor Microsoft Entra ID, MSOnline, gebruikt in een PowerShell-sessie, maakt u eerst verbinding met de service en geeft u uw globale beheerdersreferenties op:

Connect-MsolService

Opmerking: als deze opdracht niet werkt, kunt u de MSOnline-module installeren Install-Module MSOnline .

Configureer vervolgens uw PowerShell-sessie zodat de waarden niet worden afgekapt:

$Formatenumerationlimit =-1

Controleer of gebruikersaccounts gereed zijn voor Azure Information Protection

Voer de volgende opdracht uit om de gebruikersaccounts te bevestigen:

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

Uw eerste controle is om ervoor te zorgen dat de gebruikers die u met Azure Information Protection wilt gebruiken, worden weergegeven.

Controleer vervolgens of de kolom ProxyAddresses is ingevuld. Als dat het is, kunnen de e-mailwaarden in deze kolom worden gebruikt om de gebruiker te autoriseren voor Azure Information Protection.

Als de kolom ProxyAddresses niet is ingevuld, wordt de waarde in userPrincipalName gebruikt om de gebruiker te autoriseren voor de Azure Rights Management-service.

Voorbeeld:

Weergavenaam UserPrincipalName ProxyAddresses
Jagannath Reddy jagannathreddy@contoso.com {}
Ankur Roy ankurroy@contoso.com {SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}

In dit voorbeeld:

  • Het gebruikersaccount voor Jagannath Reddy wordt geautoriseerd door jagannathreddy@contoso.com.

  • Het gebruikersaccount voor Ankur Roy kan worden geautoriseerd met behulp van ankur.roy@contoso.com en ankur.roy@onmicrosoft.contoso.com, maar niet ankurroy@contoso.com.

In de meeste gevallen komt de waarde voor UserPrincipalName overeen met een van de waarden in het veld ProxyAddresses. Dit is de aanbevolen configuratie, maar als u uw UPN niet kunt wijzigen zodat deze overeenkomt met het e-mailadres, moet u de volgende stappen uitvoeren:

  1. Als de domeinnaam in de UPN-waarde een geverifieerd domein is voor uw Microsoft Entra-tenant, voegt u de UPN-waarde toe als een ander e-mailadres in Microsoft Entra-id, zodat de UPN-waarde nu kan worden gebruikt om het gebruikersaccount voor Azure Information Protection te autoriseren.

    Als de domeinnaam in de UPN-waarde geen geverifieerd domein voor uw tenant is, kan deze niet worden gebruikt met Azure Information Protection. De gebruiker kan echter nog steeds worden geautoriseerd als lid van een groep wanneer het e-mailadres van de groep een geverifieerde domeinnaam gebruikt.

  2. Als de UPN niet routeerbaar is (bijvoorbeeld ankurroy@contoso.local), configureert u een alternatieve aanmeldings-id voor gebruikers en laat u hen instrueren hoe ze zich met deze alternatieve aanmelding kunnen aanmelden bij Office. U moet ook een registersleutel voor Office instellen.

    Met UPN-wijzigingen voor gebruikers zal er ten minste 24 uur bedrijfscontinuïteit verloren gaan of totdat de UPN-wijzigingen correct worden doorgevoerd in het systeem.

    Zie Alternatieve aanmeldings-id's en Office-app licenties regelmatig om referenties voor SharePoint, OneDrive en Lync Online configureren voor meer informatie.

Tip

U kunt de cmdlet Export-CSV gebruiken om de resultaten te exporteren naar een spreadsheet voor eenvoudiger beheer, zoals zoeken en bulksgewijs bewerken voor importeren.

Bijvoorbeeld:Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

Notitie

Met UPN-wijzigingen voor gebruikers zal er ten minste 24 uur bedrijfscontinuïteit verloren gaan of totdat de UPN-wijzigingen correct worden doorgevoerd in het systeem.

Controleren of groepsaccounts gereed zijn voor Azure Information Protection

Gebruik de volgende opdracht om groepsaccounts te bevestigen:

Get-MsolGroup | select DisplayName, ProxyAddresses

Zorg ervoor dat de groepen die u wilt gebruiken met Azure Information Protection worden weergegeven. Voor de weergegeven groepen kunnen de e-mailadressen in de kolom ProxyAddresses worden gebruikt om de groepsleden te autoriseren voor de Azure Rights Management-service.

Controleer vervolgens of de groepen de gebruikers (of andere groepen) bevatten die u wilt gebruiken voor Azure Information Protection. U kunt PowerShell gebruiken om dit te doen (bijvoorbeeld Get-MsolGroupMember) of uw beheerportal te gebruiken.

Voor de twee configuratiescenario's van de Azure Rights Management-service die gebruikmaken van beveiligingsgroepen, kunt u de volgende PowerShell-opdracht gebruiken om de object-id en weergavenaam te vinden die kan worden gebruikt om deze groepen te identificeren. U kunt de Azure-portal ook gebruiken om deze groepen te vinden en de waarden voor de object-id en de weergavenaam te kopiëren:

Get-MsolGroup | where {$_.GroupType -eq "Security"}

Overwegingen voor Azure Information Protection als e-mailadressen veranderen

Als u het e-mailadres van een gebruiker of groep wijzigt, wordt u aangeraden het oude e-mailadres toe te voegen als een tweede e-mailadres (ook wel een proxyadres, alias of alternatief e-mailadres genoemd) aan de gebruiker of groep. Wanneer u dit doet, wordt het oude e-mailadres toegevoegd aan het kenmerk Microsoft Entra proxyAddresses. Dit accountbeheer zorgt voor bedrijfscontinuïteit voor gebruiksrechten of andere configuraties die zijn opgeslagen toen het oude e-mailadres werd gebruikt.

Als u dit niet kunt doen, loopt de gebruiker of groep met het nieuwe e-mailadres mogelijk geen toegang meer tot documenten en e-mailberichten die eerder zijn beveiligd met het oude e-mailadres. In dit geval moet u de beveiligingsconfiguratie herhalen om het nieuwe e-mailadres op te slaan. Als de gebruiker of groep bijvoorbeeld gebruiksrechten heeft gekregen in sjablonen of labels, bewerkt u deze sjablonen of labels en geeft u het nieuwe e-mailadres op met dezelfde gebruiksrechten als u hebt verleend aan het oude e-mailadres.

Het is zelden voor een groep om het e-mailadres te wijzigen en als u gebruiksrechten toewijst aan een groep in plaats van aan afzonderlijke gebruikers, maakt het niet uit of het e-mailadres van de gebruiker verandert. In dit scenario worden de gebruiksrechten toegewezen aan het groeps-e-mailadres en niet aan afzonderlijke e-mailadressen van gebruikers. Dit is de meest waarschijnlijke (en aanbevolen) methode voor een beheerder om gebruiksrechten te configureren die documenten en e-mailberichten beveiligen. Gebruikers kunnen echter meer aangepaste machtigingen toewijzen voor afzonderlijke gebruikers. Omdat u niet altijd kunt weten of een gebruikersaccount of groep is gebruikt om toegang te verlenen, is het veiligst om altijd het oude e-mailadres toe te voegen als een tweede e-mailadres.

Groepslidmaatschap opslaan in cache door Azure Information Protection

Om prestatieredenen slaat Azure Information Protection groepslidmaatschap in de cache op. Dit betekent dat het tot drie uur kan duren voordat wijzigingen in het groepslidmaatschap in Microsoft Entra ID van kracht worden wanneer deze groepen worden gebruikt door Azure Information Protection en deze periode onderhevig is aan wijzigingen.

Houd er rekening mee dat u rekening moet houden met deze vertraging in wijzigingen of tests die u uitvoert wanneer u groepen gebruikt voor het verlenen van gebruiksrechten of het configureren van de Azure Rights Management-service, of wanneer u beleidsregels met een bereik configureert.

Volgende stappen

Wanneer u hebt bevestigd dat uw gebruikers en groepen kunnen worden gebruikt met Azure Information Protection en u klaar bent om documenten en e-mailberichten te beveiligen, controleert u of u de Azure Rights Management-service moet activeren. Deze service moet worden geactiveerd voordat u de documenten en e-mailberichten van uw organisatie kunt beveiligen:

  • Vanaf februari 2018: Als uw abonnement met Azure Rights Management of Azure Information Protection is verkregen tijdens of na deze maand, wordt de service automatisch voor u geactiveerd.

  • Als uw abonnement vóór februari 2018 is verkregen: u moet de service zelf activeren.

Zie De beveiligingsservice activeren vanuit Azure Information Protection voor meer informatie, waaronder het controleren van de activeringsstatus.