La combinaison d’Azure Automation, de SharePoint Online et d’Exchange Online maintient la liste de blocage des locataires
Récemment, j’ai écrit sur le choix entre l’utilisation du filtre de courrier indésirable d’Outlook et des listes d’autorisation/blocage à l’échelle du locataire. Il s’agit d’un sujet complexe qui nécessite beaucoup de travail de la part des administrateurs pour décider de ce qui convient le mieux à un locataire. Cet article explique en détail ce qu’est la liste d’autorisations/de blocage des locataires et comment gérer automatiquement les entrées de blocage.
Exchange Online Protection (EOP) et Microsoft Defender pour Office 365 disposent de listes d’autorisation et de blocage permettant aux locataires de personnaliser le traitement des e-mails entrants. Les administrateurs ne peuvent pas ajouter d’entrées à la liste verte. Au lieu de cela, EOP ajoute des entrées pour les expéditeurs de messages bloqués qui n’auraient pas dû être bloqués lorsque les locataires soumettent ces messages à Microsoft.
Les locataires peuvent contrôler la liste de blocage en ajoutant des entrées pour les expéditeurs et les domaines dont ils ne souhaitent pas accepter les messages. Vous pouvez aussi ajouter des domaines lorsque vous ne souhaitez pas accepter les e-mails contenant des liens vers ces domaines dans le corps du message. Récemment, Microsoft a ajouté la possibilité de bloquer les domaines de premier niveau (TLD). Cette fonctionnalité permet de supprimer les tentatives probables de spam ou de phishing provenant de certains TLD tels que la liste des TLD les plus abusés maintenue par Spamhaus,
Microsoft 365 Defender et la liste de blocage
L’interface utilisateur permettant de gérer la liste de blocage se trouve dans la section E-mail et collaboration du centre d’administration Microsoft Defender 365. Accédez à Politiques et règles, puis sélectionnez Listes d’autorisation/de blocage des locataires. La figure 1 montre un ensemble de TLD dans une liste de blocage de locataires.
Il est facile d’ajouter des expéditeurs et des domaines bloqués ou des URL pour des domaines et des TLD. Cependant, à moins que vous ne marquiez une entrée de la liste de blocage comme «ne jamais expirer», la durée maximale pendant laquelle une entrée reste sur la liste de blocage est de 90jours. À certains égards, c’est une bonne idée car cela oblige les administrateurs à examiner les raisons pour lesquelles les blocages sont en place et à décider s’il faut renouveler les blocages ou laisser le trafic reprendre à partir d’un domaine.
Automatisation des mises à jour de la liste de blocage des locataires
L’automatisation du processus est la réponse. J’ai mis en place un script PowerShell qui peut s’exécuter en tant que runbook Azure Automation. Les grandes lignes de la solution sont les suivantes:
- Stockez les entrées de la liste de blocage dans SharePoint Online.
- Lisez les entrées de la liste de blocage et mettez-les à jour dans EOP.
- Mettez à jour les règles de flux de messagerie pour bloquer les e-mails provenant de TLD et de domaines spécifiques.
- Envoyez les résultats par courrier électronique aux administrateurs.
Passons à certains détails techniques.
Liste SharePoint pour les entrées de la liste de blocage des locataires
Les entrées de liste noire que l’organisation souhaite conserver sont conservées dans une liste d’un site SharePoint Online. Les listes SharePoint Online constituent un bon choix pour stocker des données de cette nature. Les listes sont faciles à mettre à jour, y compris avec un client mobile. Plus important encore, les informations sont accessibles à l’aide de requêtes Graph (ou Kit de développement logiciel Microsoft Graph PowerShell applets de commande) pour les sessions interactives et lorsqu’un runbook Azure Automation s’exécute sur un serveur sans tête.
La liste SharePoint stocke les entrées d’expéditeur et d’URL (Figure 2). Les entrées d’expéditeur demandent à EOP de bloquer les e-mails provenant d’adresses e-mail ou de domaines individuels. Les entrées d’URL demandent à EOP de bloquer les e-mails lorsque le corps du message inclut des URL avec le nom de domaine. Les URL peuvent être des TLD ou des domaines individuels.
Le script lit les données de la liste de blocage à partir de la liste SharePoint pour créer un ensemble d’entrées à traiter. Dans cet extrait de code, les applets de commande recherchent les identifiants du site et de la liste et utilisent ces informations pour récupérer les éléments de la liste. Comme dans de nombreuses requêtes Graph, les données récupérées sont un peu géniales, le script remplit donc une liste PowerShell avec les entrées.
$Site = Get-MgSite -Search 'Office 365 Adoption' | Select-Object -First 1
# List in the site with the block information
$List = Get-MgSiteList -SiteId $Site.Id -Filter "displayName eq 'Domain Blocks'"
# Read items from the list and build a PowerShell list object containing blocks to apply
Write-Output ("Fetching information about tenant blocks from SharePoint Online list {0}" -f $List.displayName)
[array]$Data = Get-MgSiteListItem -ListId $List.Id -SiteId $Site.Id -ExpandProperty Fields
[array]$Items = $Data.Fields.additionalProperties
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($Item in $Items) {
$ItemtoBlock = $Item.Title
$BlockType = $Item.DomainType
$Notes = $Item.Value
$DataLine = [PSCustomObject][Ordered]@{
ItemToBlock = $ItemtoBlock
BlockType = $BlockType
Notes = $Notes
}
$Report.Add($DataLine)
}
Mise à jour des entrées de la liste de blocage
Étant donné que les entrées de la liste de blocage (en général) ne peuvent pas être mises à jour, pour modifier la date d’expiration, il est nécessaire de supprimer l’entrée de la liste de blocage existante et de la remplacer par une nouvelle version ayant une date d’expiration de 90 jours dans le futur (le maximum).
Le script effectue un traitement différent pour les entrées de bloc d’expéditeur et d’URL, il sépare donc les données extraites de SharePoint en deux tableaux et traite chaque ensemble. Cet extrait montre le traitement de l’ensemble d’URL. Notez le traitement des blocs TLD, qui doivent être au format «.biz*» pour les entrées de la liste de blocage et le expression régulière «.biz$» pour bloquer les e-mails entrants pour un TLD dans une règle de flux de messagerie.
ForEach ($BlockURL in $URLBlocks) {
Write-Output ("Processing block for {0}" -f $BlockURL.ItemToBlock)
If (($BlockURL.ItemToBlock.Substring(0,1)) -eq ".") {
$URLToBlock = ("*{0}/*" -f $BlockURL.ItemToBlock)
$TLDBlock = ("\{0}$" -f $BlockURL.ItemToBlock)
$TLDBlocksforTransportRule += $TLDBlock
} Else {
$URLToBlock = $BlockURL.ItemToBlock
$IndividualDomainBlocks += $BlockURL.ItemToBlock
}
# If URL is already blocked, remove the current block
If ($URLToBlock -in $CurrentURLBlocks) {
Write-Output ("Removing current block for {0}" -f $URLToBlock)
$Status = Remove-TenantAllowBlockListItems -ListType URL -Entries $URLToBlock -ErrorAction SilentlyContinue
}
# Add the block for 90 days
$Status = (New-TenantAllowBlockListItems -ListType URL -Entries $URLToBlock -Block `
-ExpirationDate $ExpirationDate -ErrorAction SilentlyContinue)
If ($Status) {
Write-Output ("Block successfully applied for {0}" -f $URLToBlock)
$BlockData = [PSCustomObject][Ordered]@{
Timestamp = Get-Date -Format s
Block = $URLToBlock
BlockType = 'URL'
}
$BlockReport.Add($BlockData)
} Else {
Write-Output "Error occurred adding block"
}
}
L’effet de la liste de blocage est de déplacer les éléments entrants vers la quarantaine. Les administrateurs peuvent examiner les éléments mis en quarantaine pour évaluer le type d’e-mail capturé par le blocage provenant de différents domaines et décider s’il convient de supprimer ou de conserver les blocages pour les domaines.
Un effet secondaire à prendre en compte est que les entrées de la liste de blocage des expéditeurs empêchent tout membre du client d’envoyer des e-mails à ces adresses, même si l’adresse n’est qu’un des nombreux destinataires d’un message. La figure 3 montre une notification de non-remise (NDR) avec le code d’état 550.5.7.703 généré pour un message envoyé à un domaine bloqué. L’erreur indiquant que le fournisseur de messagerie du destinataire l’a rejeté est incorrecte. Le locataire expéditeur a appliqué le blocage.
Figure 3: Notification de non-remise pour un e-mail envoyé à un domaine bloqué
Le blocage des messages entrants est attendu. Le blocage des messages sortants, surtout lorsqu’une adresse n’est qu’un des destinataires, sera probablement une surprise.
Mise à jour des règles de flux de messagerie
Après avoir mis à jour la liste de blocage EOP, le script passe aux règles de flux de messagerie. Une entrée de blocage d’URL bloque uniquement les e-mails lorsque le corps du message inclut l’URL. Si vous souhaitez bloquer tous les e-mails d’un domaine, vous pouvez ajouter une entrée d’expéditeur à la liste de blocage. J’ai décidé d’utiliser deux règles de flux de messagerie.
- Bloquez les e-mails des TLD.
- Bloquez les e-mails provenant de domaines spécifiques.
Ce serait bien d’utiliser une seule règle, mais la détection des TLD dépend de la correspondance de modèles définie dans le FromAddressMatchesPatterns propriété tout en bloquant le courrier électronique des domaines utilise un simple tableau défini dans le SenderDomainIs propriété.
Voici le code pour mettre à jour la règle de flux de messagerie afin de bloquer les e-mails provenant des TLD. Comme vous pouvez le constater, si la règle de flux de messagerie n’existe pas, le script la crée.
If ($TLDBlocksforTransportRule) {
# Now to update the transport rule to block TLDs if any TLDs are to be blocked.
# First, check if a rule exists. If it doesn't, create it
[array]$CheckTransportRule = Get-TransportRule -Identity $TransportRuleName -ErrorAction SilentlyContinue
$Comments = ("Rule updated automatically on {0} to process TLDs: {1}" -f (Get-Date -format 'dd-MMM-yy HH:mm'), ($TLDBlocksforTransportRule -join ", "))
If (!($CheckTransportRule)) {
# Transport rule not present, so create new rule
$NewRule = New-TransportRule -Name $TransportRuleName -Enabled $True `
-FromAddressMatchesPatterns $TLDBlocksforTransportRule -SenderAddressLocation 'Header' `
-Comments $Comments -Quarantine $true
If ($NewRule) {
Write-Output "Transport rule created to block email from specified TLDs"
$NewRuleCreated = $true
}
} Else {
# We have a transport rule, so update it
Write-Output "Updating transport rule for TLD blocks..."
Set-TransportRule -Identity $TransportRuleName -FromAddressMatchesPatterns $TLDBlocksforTransportRule `
-ErrorAction SilentlyContinue -Comments $Comments
$BlockedTLDs = Get-TransportRule -Identity $TransportRuleName | Select-Object -ExpandProperty FromAddressMatchesPatterns
If (!(Compare-Object -ReferenceObject $TLDBlocksForTransportRule -DifferenceObject $BlockedTLDs)) {
Write-Output ("Transport rule updated to block email from these TLDs {0}:" -f ($TLDBlocksforTransportRule -join ", "))
}
}
}
Comme auparavant, les e-mails bloqués par la règle de flux de messagerie finissent en quarantaine. Il serait facile de modifier la règle pour supprimer les messages. La figure 4 montre les propriétés de la règle telles qu’affichées via le centre d’administration Exchange.
Utilisation d’Azure Automation pour exécuter le script
Si vous exécutez le script de manière interactive, vous saurez quand il sera terminé. Mais il s’agit d’un bon exemple de script à exécuter en tant que runbook Azure Automation planifié pour renouveler les blocs tous les 90 jours. Rien dans le code ne l’empêche de s’exécuter avec Azure Automation (Figure 5) à l’aide d’une identité managée pour se connecter à Exchange Online et au SDK Graph.
Le compte d’automatisation utilisé pour exécuter le runbook doit:
- Détenir le rôle d’administrateur Exchange Online (le processus pour attribuer le rôle est décrit dans cet article).
- Se voir attribuer le Autorisations du graphique nécessaire pour lire les informations de la liste SharePoint Online (Sites.Read.All) et envoyer un e-mail (Mail.Envoyer). Vous pouvez uniquement attribuer des autorisations au principal de service du compte d’automatisation à l’aide de PowerShell. Voir cet article pour information.
- Chargez les modules PowerShell nécessaires en tant que ressources. Ces modules incluent le module Exchange Online et le Microsoft.Graph.Authentification, Microsoft.Graph.Siteset Microsoft.Graph.Identity.DirectoryManagement modules. Assurez-vous d’utiliser les derniers modules (voici un script pratique pour mettre à jour les modules PowerShell pour les comptes Azure Automation).
Une fois tout en place, le runbook s’exécute et génère un e-mail à la fin pour signaler ce qu’il a fait (Figure 6).
Tu peux téléchargez le script complet depuis GitHub. N’oubliez pas qu’il s’agit d’un code écrit pour explorer et illustrer un principe et qu’il nécessite une meilleure gestion des erreurs et une meilleure journalisation avant d’être utilisé en production. C’est la base d’une évolution ultérieure, rien de plus.
L’automatisation des opérations des locataires n’est pas très complexe
Je suis sûr que j’ai oublié quelque chose, mais le fait est que l’automatisation de la gestion de Microsoft 365 n’est pas particulièrement complexe une fois que l’on connaît les modules, les applets de commande et les autorisations à utiliser. L’astuce consiste à découvrir quels sont ces éléments, puis à les combiner dans une solution à l’aide des outils disponibles. Espérons que l’idée décrite ici suscite une certaine créativité dans la façon dont vous abordez l’automatisation des opérations de gestion des locataires.
