SharePoint et OneDrive : Maitriser le Partage Externe et Prevenir les Fuites

Introduction

SharePoint Online et OneDrive for Business constituent le socle documentaire de Microsoft 365 pour des millions d'organisations. Avec la generalisation du travail hybride, le partage externe est devenu une necessite operationnelle : collaboration avec des prestataires, envoi de livrables aux clients, co-edition de documents avec des partenaires. Mais cette ouverture expose les donnees a des risques majeurs de fuite, d'exfiltration et de non-conformite reglementaire.

Selon le rapport Microsoft Digital Defense 2025, 68 % des incidents de fuite de donnees dans les environnements M365 impliquent un partage externe mal configure. Les entreprises soumises au RGPD, a la directive NIS2 ou aux normes PCI-DSS ne peuvent pas se permettre de laisser le partage externe en mode "tout autorise". Pourtant, bloquer purement et simplement le partage externe n'est pas une option realiste : cela pousse les utilisateurs vers le shadow IT (WeTransfer, Google Drive personnel, cles USB).

Cet article propose une approche structuree pour maitriser le partage externe sans paralyser la collaboration. Nous couvrirons les quatre niveaux de partage, la classification par Sensitivity Labels, les policies DLP specifiques a SharePoint et OneDrive, la gouvernance des permissions et des sites hub, et le monitoring via les audit logs et Defender for Cloud Apps. Chaque section inclut des configurations PowerShell concretes et des recommandations actionnables.

1. Controle du Partage Externe : les 4 Niveaux

1.1 Comprendre les niveaux de partage

SharePoint Online propose quatre niveaux de partage externe, configures au niveau du tenant et surchargeables par site. Chaque niveau represente un compromis entre ouverture collaborative et securite des donnees.

Niveau 1 - Anyone (liens anonymes) : Le niveau le plus permissif. N'importe qui disposant du lien peut acceder au fichier ou au dossier, sans authentification. Ce mode est adapte uniquement pour des contenus publics (brochures, communiques de presse). Le risque est majeur : un lien forward dans un email atteint des destinataires non prevus, et l'organisation n'a aucune tracabilite sur les acces.

Niveau 2 - New and Existing External Users : Les utilisateurs externes doivent s'authentifier via un compte Microsoft ou un code OTP envoye par email. L'organisation conserve une trace de qui accede a quoi. Ce niveau permet la collaboration avec des partenaires identifies tout en maintenant une forme d'accountability. L'invite est enregistree dans Azure AD en tant que guest user (B2B).

Niveau 3 - Existing External Users Only : Seuls les utilisateurs externes deja presents dans l'annuaire Azure AD (invites precedemment ou provenant d'un tenant partenaire via Cross-Tenant Access) peuvent acceder aux ressources partagees. Aucune nouvelle invitation n'est possible. Ce niveau convient aux organisations avec des partenaires stables et pre-approuves.

Niveau 4 - Only People in Your Organization : Le partage externe est completement desactive. Les documents ne peuvent etre partages qu'en interne. Ce mode est recommande pour les sites contenant des donnees sensibles (RH, juridique, R&D) ou classifiees.

1.2 Configuration au niveau tenant

La configuration globale se fait via le SharePoint Admin Center ou PowerShell. Le parametre tenant definit le plafond : un site ne peut jamais etre plus permissif que le tenant. Voici la configuration recommandee pour un environnement d'entreprise standard.

# Connexion au module SharePoint Online
Connect-SPOService -Url https://contoso-admin.sharepoint.com

# Configurer le tenant en mode "New and Existing External Users"
Set-SPOTenant -SharingCapability ExternalUserSharingOnly

# Forcer l'expiration des liens de partage externe (30 jours)
Set-SPOTenant -ExternalUserExpireInDays 30
Set-SPOTenant -ExternalUserExpirationRequired $true

# Limiter les domaines autorises pour le partage
Set-SPOTenant -SharingDomainRestrictionMode AllowList
Set-SPOTenant -SharingAllowedDomainList "partenaire1.com partenaire2.fr cabinet-audit.com"

# Desactiver les liens Anyone par defaut
Set-SPOTenant -DefaultSharingLinkType Internal
Set-SPOTenant -FileAnonymousLinkType View
Set-SPOTenant -FolderAnonymousLinkType View

# Exiger la reauthentification des guests tous les 15 jours
Set-SPOTenant -BccExternalSharingInvitations $true
Set-SPOTenant -BccExternalSharingInvitationsList "securite@contoso.com"

1.3 Surcharge par site

Chaque site SharePoint peut avoir un niveau de partage plus restrictif que le tenant. Cette granularite est essentielle pour segmenter les donnees par sensibilite. Un site "Projets Clients" peut autoriser le partage avec des guests authentifies, tandis qu'un site "Donnees RH" bloque tout partage externe.

# Site RH : pas de partage externe
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/DonneesRH" `
    -SharingCapability Disabled

# Site Projets Clients : guests existants uniquement
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/ProjetsClients" `
    -SharingCapability ExistingExternalUserSharingOnly

# Site Marketing : partage externe avec nouveaux guests (domaines restreints)
Set-SPOSite -Identity "https://contoso.sharepoint.com/sites/Marketing" `
    -SharingCapability ExternalUserSharingOnly `
    -SharingDomainRestrictionMode AllowList `
    -SharingAllowedDomainList "agence-com.fr media-partner.com"

1.4 Expiration et revocation

Les liens de partage sans expiration sont un vecteur de fuite dormant. Un collaborateur partage un document avec un prestataire en janvier ; le prestataire quitte sa mission en mars, mais le lien reste actif indefiniment. Pour contrer cela, Microsoft propose plusieurs mecanismes : l'expiration automatique des liens anonymes, la revocation des acces guest via Access Reviews dans Entra ID, et le controle des sharing links via les policies de site.

2. Sensitivity Labels : Classification et Protection

2.1 Microsoft Information Protection (MIP)

Les Sensitivity Labels (etiquettes de sensibilite) constituent le mecanisme central de classification des donnees dans Microsoft 365. Ils permettent d'appliquer des protections automatiques aux documents et emails en fonction de leur niveau de sensibilite : chiffrement, restrictions d'acces, marquages visuels (filigrane, en-tete, pied de page).

La taxonomie de classification doit etre definie en amont avec les metiers et la RSSI. Une approche courante comprend quatre niveaux :

Label	Description	Protection	Partage externe
Public	Informations publiables sans restriction	Aucune	Autorise (Anyone)
Interne	Usage interne general	Marquage visuel	Guests authentifies
Confidentiel	Donnees sensibles metier	Chiffrement + IRM	Domaines autorises uniquement
Tres Confidentiel	Secret des affaires, donnees RH, M&A	Chiffrement fort + No Forward + No Print	Interdit

2.2 Auto-labeling : classification automatique

L'auto-labeling applique automatiquement un Sensitivity Label lorsque du contenu sensible est detecte dans un document. Cette fonctionnalite repose sur les Sensitive Information Types (SIT) natifs de Microsoft ou des SIT personnalises. Par exemple, un document contenant des numeros de carte bancaire sera automatiquement classe "Confidentiel - PCI".

L'auto-labeling fonctionne en deux modes : cote client (dans les applications Office, le label est suggere a l'utilisateur) et cote service (les fichiers deja stockes dans SharePoint et OneDrive sont analyses et etiquetes automatiquement sans intervention utilisateur). Le mode service est plus puissant car il couvre le stock existant de documents.

# Creer une policy d'auto-labeling cote service pour les donnees RGPD
New-AutoSensitivityLabelPolicy -Name "RGPD-AutoLabel" `
    -SharePointLocation "All" `
    -OneDriveLocation "All" `
    -ApplySensitivityLabel "Confidentiel" `
    -Mode "TestWithNotifications"

# Ajouter une regle basee sur les SIT
New-AutoSensitivityLabelRule -Policy "RGPD-AutoLabel" `
    -Name "Detection IBAN et NIR" `
    -ContentContainsSensitiveInformation @(
        @{Name="France National ID Card (CNI)"; MinCount=1},
        @{Name="International Banking Account Number (IBAN)"; MinCount=1},
        @{Name="France Social Security Number (INSEE/NIR)"; MinCount=1}
    )

2.3 Protection IRM sur les sites SharePoint

L'Information Rights Management (IRM) etend la protection au-dela du perimetre SharePoint. Lorsqu'un document est telecharge depuis une bibliotheque protegee par IRM, le chiffrement et les restrictions d'acces persistent. L'utilisateur ne peut pas copier le contenu, l'imprimer ou le transmettre (selon la configuration). Cette protection est essentielle pour les documents qui quittent le perimetre du tenant, notamment lors de partages externes.

La combinaison Sensitivity Label + IRM + partage externe restreint cree une defense en profondeur : meme si un document est partage avec un destinataire non autorise, le chiffrement empeche son ouverture. Les droits sont verifies a chaque ouverture aupres du service Azure RMS, ce qui permet de revoquer l'acces a posteriori.

3. DLP SharePoint et OneDrive : Politiques Anti-Fuite

3.1 Architecture DLP dans Microsoft 365

Les politiques Data Loss Prevention (DLP) de Microsoft Purview sont le dernier filet de securite avant qu'un document sensible ne quitte le perimetre de l'organisation. Contrairement aux Sensitivity Labels qui classifient, les DLP policies agissent : elles bloquent le partage, alertent les administrateurs, ou affichent des notifications educatives aux utilisateurs.

Une politique DLP s'applique a trois workloads dans le contexte documentaire : SharePoint Online, OneDrive for Business et Microsoft Teams (qui utilise SharePoint en backend pour le stockage des fichiers). Les policies sont evaluees en temps reel lors du partage et en arriere-plan lors du scan periodique du contenu existant.

3.2 Policy DLP RGPD

Le RGPD impose la protection des donnees personnelles des residents europeens. Une politique DLP RGPD pour SharePoint doit couvrir les principaux identifiants personnels francais et europeens : numeros de securite sociale (NIR), numeros de carte d'identite (CNI), IBAN, numeros de passeport, adresses email combineedifferents types de donnees medicales.

# Creer une policy DLP pour la conformite RGPD
New-DlpCompliancePolicy -Name "RGPD-SharePoint-OneDrive" `
    -SharePointLocation "All" `
    -OneDriveLocation "All" `
    -Mode "Enable"

# Regle : bloquer le partage externe de documents contenant des donnees RGPD
New-DlpComplianceRule -Policy "RGPD-SharePoint-OneDrive" `
    -Name "Block External Sharing PII FR" `
    -ContentContainsSensitiveInformation @(
        @{Name="France Social Security Number (INSEE/NIR)"; MinCount=1; MaxConfidence=100; MinConfidence=75},
        @{Name="France National ID Card (CNI)"; MinCount=1},
        @{Name="EU Debit Card Number"; MinCount=1},
        @{Name="International Banking Account Number (IBAN)"; MinCount=3}
    ) `
    -AccessScope "NotInOrganization" `
    -BlockAccess $true `
    -BlockAccessScope "All" `
    -NotifyUser "SiteAdmin,LastModifier" `
    -NotifyEmailCustomText "Ce document contient des donnees personnelles protegees par le RGPD. Le partage externe a ete bloque automatiquement. Contactez l'equipe securite si ce partage est necessaire." `
    -GenerateIncidentReport "SiteAdmin" `
    -IncidentReportContent "All"

3.3 Policy DLP PCI-DSS

Les organisations qui traitent des donnees de cartes de paiement doivent se conformer a PCI-DSS. Les numeros de cartes bancaires (PAN) ne doivent jamais etre stockes en clair dans SharePoint ou OneDrive. Une politique DLP PCI cible specifiquement les numeros de cartes (Visa, Mastercard, AmEx) et les codes CVV.

# Policy DLP PCI-DSS
New-DlpCompliancePolicy -Name "PCI-DSS-Protection" `
    -SharePointLocation "All" `
    -OneDriveLocation "All" `
    -Mode "Enable"

New-DlpComplianceRule -Policy "PCI-DSS-Protection" `
    -Name "Block Credit Card Sharing" `
    -ContentContainsSensitiveInformation @(
        @{Name="Credit Card Number"; MinCount=1; MinConfidence=85}
    ) `
    -AccessScope "All" `
    -BlockAccess $true `
    -NotifyUser "SiteAdmin,LastModifier" `
    -GenerateAlert "High"

4. Gouvernance des Permissions

4.1 Heritage des permissions

SharePoint repose sur un modele d'heritage des permissions : les sous-sites, bibliotheques et dossiers heritent par defaut des permissions du site parent. Rompre cet heritage (via "Stop Inheriting Permissions") est techniquement possible mais cree une dette de securite. Chaque rupture d'heritage represente un point de controle supplementaire a auditer et a maintenir. Dans un site de 500 documents avec 50 ruptures d'heritage, il devient quasi impossible de repondre a la question : "qui a acces a quoi ?".

La recommandation est de limiter les ruptures d'heritage au strict minimum et de privilegier une architecture de sites granulaire. Plutot que d'avoir un mega-site "Projets" avec des ruptures d'heritage par dossier, creez un site par projet avec des permissions uniformes. L'approche "un site, un perimetre de securite" simplifie enormement la gouvernance.

4.2 Types de Sharing Links

Microsoft 365 propose quatre types de liens de partage, chacun avec un perimetre de visibilite different :

• Anyone link : Accessible sans authentification. A proscrire sauf exception validee par la securite.
• People in your organization link : Accessible par tous les employes du tenant. Utile pour la diffusion interne large.
• People with existing access link : Ne confere pas de nouveaux droits. Genere une URL pratique pour ceux qui ont deja acces.
• Specific people link : Accessible uniquement par les personnes nommees. Le plus securise, impose une authentification individuelle.

# Audit des liens de partage actifs via Microsoft Graph
$GraphToken = (Get-MgContext).AccessToken
$sites = Get-MgSite -All

foreach ($site in $sites) {
    $drives = Get-MgSiteDrive -SiteId $site.Id
    foreach ($drive in $drives) {
        $items = Get-MgDriveItemChild -DriveId $drive.Id -DriveItemId "root" -All
        foreach ($item in $items) {
            $permissions = Get-MgDriveItemPermission -DriveId $drive.Id -DriveItemId $item.Id
            $externalLinks = $permissions | Where-Object { $_.Link -ne $null -and $_.GrantedToV2.User.Email -notlike "*@contoso.com" }
            if ($externalLinks) {
                Write-Output "Fichier: $($item.Name) | Site: $($site.DisplayName) | Liens externes: $($externalLinks.Count)"
            }
        }
    }
}

4.3 Access Reviews pour les guests

Les Access Reviews d'Entra ID Governance permettent de revalider periodiquement les acces des utilisateurs guests. Sans ce mecanisme, les comptes guests s'accumulent dans l'annuaire : anciens prestataires, contacts ponctuels, partenaires d'un projet termine. Chaque guest inactif est un risque latent, surtout si son compte dans son organisation d'origine a ete compromis.

Configurez des Access Reviews trimestrielles ciblant les guest users ayant acces aux sites SharePoint sensibles. Le reviewer peut etre le proprietaire du site ou le manager du collaborateur qui a initie l'invitation. Les guests non revalides sont automatiquement desactives puis supprimes apres un delai de grace de 30 jours.

5. Sites Hub et Gouvernance du Cycle de Vie

5.1 Architecture Hub Sites

Les Hub Sites sont un mecanisme de gouvernance qui permet d'associer plusieurs sites SharePoint a un hub central, sans heritage de permissions. Le hub fournit une navigation commune, un theme visuel, et surtout la possibilite d'appliquer des policies de maniere coherente a travers tous les sites associes. C'est l'outil ideal pour structurer les sites par departement (Hub RH, Hub Finance, Hub Projets) avec des politiques de partage specifiques a chaque hub.

Contrairement a la hierarchie classique de sous-sites (qui cree un couplage fort et des problemes de migration), les hub sites maintiennent l'independance de chaque site membre tout en assurant une coherence de gouvernance. Un site peut etre deplace d'un hub a un autre sans migration de donnees.

5.2 Lifecycle management

La proliferation de sites SharePoint non geres est un probleme majeur de securite. Des sites crees pour un projet ponctuel restent actifs des annees apres la fin du projet, avec des documents sensibles et des acces exterieurs jamais revoques. Microsoft 365 propose des mecanismes de gestion du cycle de vie :

• Inactive Site Policy : Detection automatique des sites inactifs (aucune activite depuis X mois). Notification au proprietaire, puis archivage ou suppression automatique.
• Microsoft 365 Group Expiration : Les groupes M365 (et les Team Sites associes) expirent apres une duree configurable (90, 180 ou 365 jours). Le proprietaire doit renouveler activement le groupe.
• Retention Policies : Application automatique de politiques de retention qui archivent ou suppriment les documents apres une duree definie, en conformite avec les obligations legales de conservation.

# Identifier les sites inactifs (aucune activite depuis 180 jours)
$inactiveSites = Get-SPOSite -Limit All | Where-Object {
    $_.LastContentModifiedDate -lt (Get-Date).AddDays(-180)
}

$inactiveSites | Select-Object Url, Title, LastContentModifiedDate, 
    SharingCapability, StorageUsageCurrent | 
    Export-Csv -Path "C:\Audit\sites-inactifs.csv" -NoTypeInformation

Write-Output "$($inactiveSites.Count) sites inactifs detectes"

6. Monitoring et Detection

6.1 Unified Audit Log

L'Unified Audit Log (UAL) de Microsoft 365 est la source principale de telemetrie pour la securite SharePoint et OneDrive. Il enregistre toutes les operations de partage, d'acces, de modification et de suppression. Les evenements cles a surveiller incluent :

Operation	Description	Niveau d'alerte
SharingSet	Un lien de partage a ete cree ou modifie	Information
AnonymousLinkCreated	Un lien anonyme (Anyone) a ete genere	Alerte
SharingInvitationCreated	Un utilisateur externe a ete invite	Information
CompanyLinkCreated	Un lien "tous les employes" a ete cree	Information
FileDownloaded (par un guest)	Un fichier a ete telecharge par un external user	Surveillance
FileSyncDownloadedFull	Synchronisation complete d'une bibliotheque	Alerte
SiteCollectionAdminAdded	Un admin de collection de sites a ete ajoute	Critique

# Rechercher les liens anonymes crees dans les 7 derniers jours
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
    -Operations "AnonymousLinkCreated" -ResultSize 1000 |
    Select-Object CreationDate, UserIds, 
    @{N='Details';E={($_.AuditData | ConvertFrom-Json).ObjectId}} |
    Sort-Object CreationDate -Descending |
    Format-Table -AutoSize

# Detecter les telechargements massifs par des guests
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) `
    -Operations "FileDownloaded" -ResultSize 5000 |
    ForEach-Object { $_.AuditData | ConvertFrom-Json } |
    Where-Object { $_.UserId -like "*#ext#*" } |
    Group-Object UserId |
    Where-Object { $_.Count -gt 50 } |
    Select-Object Name, Count |
    Sort-Object Count -Descending

6.2 Defender for Cloud Apps (MCAS)

Microsoft Defender for Cloud Apps (anciennement MCAS) offre une couche de detection comportementale au-dessus des logs bruts. Il detecte des anomalies comme un utilisateur qui telecharge un volume inhabituel de fichiers, un acces depuis un pays inhabituel, ou un pattern d'exfiltration progressive. Les policies Defender for Cloud Apps specifiques a SharePoint incluent :

• Mass download by a single user : Alerte quand un utilisateur telecharge plus de X fichiers dans une fenetre de temps. Seuil recommande : 100 fichiers en 5 minutes.
• Multiple sharing activities : Detection d'un utilisateur qui partage massivement des fichiers avec des externes en peu de temps.
• Access from risky IP : Blocage ou alerte quand un acces SharePoint provient d'une IP sur liste noire (TOR, VPN anonymes, pays sous sanctions).
• Impossible travel : Detection d'acces depuis deux localisations geographiquement incompatibles dans un delai trop court.
• Activity from inactive account : Un compte guest dormant reprend soudainement de l'activite, signe potentiel de compromission.

L'integration avec Microsoft Sentinel permet d'alimenter un SIEM centralise avec les alertes Defender for Cloud Apps. Les equipes SOC peuvent alors correler les evenements SharePoint avec d'autres signaux (connexions suspectes Entra ID, alertes Defender for Endpoint) pour detecter des scenarios d'attaque complets comme l'exfiltration post-compromission d'un compte.

7. Liens avec d'Autres Domaines de Securite

La securisation de SharePoint et OneDrive ne se fait pas en silo. Elle s'integre dans une strategie de securite globale couvrant l'identite, la protection des endpoints, la conformite reglementaire et la detection des menaces. Voici les connexions avec d'autres domaines couverts dans nos articles :

• Exfiltration furtive de donnees : les techniques d'exfiltration via SharePoint (sync OneDrive, API Graph, liens anonymes) et comment les detecter avec les mecanismes presentes dans cet article.
• Securite OAuth et tokens : les applications tierces enregistrees dans Entra ID peuvent acceder a SharePoint via des permissions defi ees (Sites.Read.All, Files.ReadWrite.All). Un consentement abusif est un vecteur d'exfiltration massif.
• RGPD 2026 et conformite CNIL : les obligations de protection des donnees personnelles qui justifient les policies DLP et les Sensitivity Labels presentes dans cet article.
• Secrets Sprawl : les fichiers SharePoint et OneDrive contiennent souvent des secrets (cles API, mots de passe, certificats) stockes dans des documents non proteges. L'auto-labeling peut detecter ces patterns.
• Web Cache Deception : les portails SharePoint exposes sur Internet (extranet) peuvent etre cibles par des attaques de cache deception si un CDN est mal configure devant le reverse proxy.
• ISO 27001 Guide Complet : la gestion des actifs informationnels (A.8) et le controle d'acces (A.9) de l'ISO 27001 s'appuient directement sur les mecanismes de gouvernance SharePoint decrits ici.

Conclusion

La securisation du partage externe dans SharePoint Online et OneDrive for Business est un equilibre permanent entre securite et productivite. L'approche recommandee repose sur cinq piliers : des niveaux de partage differencies par site en fonction de la sensibilite des donnees, une classification automatique via les Sensitivity Labels et l'auto-labeling, des policies DLP qui bloquent les fuites de donnees reglementees, une gouvernance des permissions avec des Access Reviews regulieres, et un monitoring continu croisant l'Unified Audit Log et Defender for Cloud Apps.

L'erreur la plus frequente est d'aborder la securite SharePoint de maniere reactive, apres un incident de fuite. L'approche proactive consiste a deployer ces controles de maniere progressive : commencer par l'audit de l'existant (liens actifs, guests, permissions), puis deployer les labels et DLP en mode observation avant de passer en mode bloquant. La communication avec les utilisateurs est essentielle : expliquez pourquoi un lien de partage est refuse, proposez des alternatives securisees, et formez les equipes aux bonnes pratiques de partage.

Enfin, n'oubliez pas que la securite SharePoint n'est qu'un maillon de la chaine. Un document correctement protege dans SharePoint peut etre exfiltre via un endpoint compromis, un consentement OAuth abusif, ou une synchronisation OneDrive non controlee. Seule une approche Zero Trust integrant l'identite, l'appareil, le reseau et les donnees offre une protection reellement efficace contre les fuites dans les environnements Microsoft 365 modernes.

Partagez cet Article

Cet article vous a ete utile ? Partagez-le avec votre reseau professionnel !

Partager sur X Partager sur LinkedIn Copier le Lien

Ressources & References Officielles

Documentations officielles et ressources de la communaute

Microsoft - SharePoint External Sharing

learn.microsoft.com

Microsoft Purview - Sensitivity Labels

learn.microsoft.com

Microsoft Purview - Data Loss Prevention

learn.microsoft.com