Modèle de rechange pour les stratégies d’application web dans SharePoint Online
Les stratégies d’application web sont un concept qui permet aux administrateurs SharePoint d’accorder ou de refuser des autorisations à des utilisateurs et des groupes pour tous les sites sous une application web. Ces autorisations accorde et refusent de préférence les autorisations définies sur les sites dans l’application web et sont donc un mécanisme généralement utilisé dans des scénarios comme ceux-ci :
- Accordez à un compte de service des autorisations sur tous les sites, car ce compte de service est utilisé pour exécuter un processus en arrière-plan qui doit manipuler les données dans tous les sites. Le compte de service peut également être utilisé par un flux de travail pour revenir en SharePoint
- Accorder à l’équipe de support un accès en lecture seule à tous les sites afin que l’ingénieur du support technique puisse parcourir le site avec l’utilisateur final
- Refuser l’accès à tout le contenu aux utilisateurs (par exemple, après avoir quitté l’entreprise)
Les stratégies d’application Web n’existent plus dans SharePoint Online et il n’existe aucune autre implémentation identique possible. Toutefois, en utilisant le modèle de sécurité SharePoint existant, vous pouvez obtenir des résultats similaires. Dans cet article et cette vidéo, vous allez en savoir plus à ce sujet.
Accorder l’accès
Quelle est la raison professionnelle de cette autorisation accordée ?
Avant de commencer à implémenter des autorisations, il est important de comprendre pourquoi un octroi était nécessaire. Les questions à poser sont les suivantes :
- L’octroi de l’accès à toutes les données dans votre client SharePoint Online est-il nécessaire ? Revenir en arrière et vérifier que l’accès à toutes les données est un must absolu pour prendre en charge un scénario d’entreprise
- La « une » utilise-t-elle l’autorisation accordée à une application ou à un utilisateur ? S’il s’agit d’une application, il peut être possible de travailler avec un principal d’application ayant des autorisations à l’échelle du client SharePoint Online, en particulier s’il s’agit d’une application développée à l’échelle de l’application.
L’image de flux ci-dessous capture les questions suivantes :

Important
Ce n’est que dans le cas où l’accès accordé sera consommé par un utilisateur ou une application qui n’est pas compatible avec les principaux d’application si vous accordez l’accès via des utilisateurs ou des groupes. Si possible, préférez les principaux d’application au-dessus des utilisateurs et des groupes, car :
- Les principaux d’application sont accordés avec l’étendue de tous les sites, ce qui signifie que si un site est ajouté, le principal d’application y a également automatiquement accès. En cas d’accès utilisateur/groupe, l’utilisateur/groupe respectif doit d’abord être ajouté au nouveau site.
- Les principaux d’application « remplacent » le paramètre d’héritage des autorisations. Supposons qu’un sous-site ait rompu l’héritage des autorisations et que l’octroi d’un propriétaire d’utilisateur/groupe, de contribution ou d’affichage au site racine accorde l’accès au sous-site alors que le principal d’application y aura toujours accès.
Octroi de l’accès à l’aide des principaux d’application
Pour tout accès non humain, il est conseillé d’utiliser les principaux d’application comme indiqué précédemment. Il existe deux approches pour ce faire :
- Utilisation d’une application Azure AD : il s’agit de la méthode préférée lorsque vous utilisez SharePoint Online, car vous pouvez également accorder des autorisations à d’autres services Office 365 (si nécessaire) et vous avez une interface utilisateur (portail Azure) pour gérer vos principaux d’application.
- Utilisation d’SharePoint App-Only principal : cette méthode est plus ancienne et fonctionne uniquement pour SharePoint’accès, mais elle est toujours pertinente. Cette méthode est également recommandée lorsque vous travaillez toujours dans SharePoint en local, car ce modèle fonctionne dans SharePoint local comme SharePoint Online.
Les deux modèles sont expliqués en détail dans la SharePoint’accès à l’aide d’un contexte d’application, également appelé article application uniquement.
Octroi de l’accès via des utilisateurs et des groupes
Lorsque vous souhaitez accorder l’accès à tous vos sites, vous devez accorder à un utilisateur ou à un groupe l’accès à tous les sites individuellement. Ce modèle est différent de celui que vous utilisiez avec les stratégies d’application web, mais il s’agit du seul modèle que vous pouvez utiliser pour accorder à un compte d’utilisateur ou à un groupe un accès à tous les sites.
Autorisations qui peuvent être accordées
À l’aide des stratégies d’application web, vous avez la possibilité d’accorder « Contrôle total » ou « Lecture totale », qui se traduit par des autorisations SharePoint se traduit par ceci :
| Octroi de stratégie Web App | Autorisation de SharePoint équivalente |
|---|---|
| Contrôle total | Ajouter aux administrateurs de collection de sites |
| Lecture complète | Ajouter à l’aide du niveau d’autorisation « Lecture » (= visiteurs du site) |
| Ajouter à l’aide du niveau d’autorisation « Contrôle total » (= propriétaires de site) | |
| Ajouter à l’aide du niveau d’autorisation « Modifier » (= membres du site) |
Nous avons délibérément choisi d’utiliser le rôle d’administrateur de collection de sites pour l’octroi « Contrôle total », car de cette façon nous libérons du problème d’héritage des autorisations. Dans SharePoint utilisateurs peuvent rompre l’héritage des autorisations et accorder des autorisations uniques sur des objets (par exemple, sous-sites, listes, éléments de liste). Si cela a été fait et que, par exemple, vous ajoutez un utilisateur au groupe propriétaires de sites de la collection de sites, cet utilisateur n’aura pas d’autorisations sur l’objet avec des autorisations uniques.
Important
Si le scénario d’entreprise que vous implémentez peut être limité par les limitations d’héritage des autorisations, vous pouvez utiliser l’une des autorisations SharePoint décrites. Si vous devez garantir un accès sûr à 100 % à tout le contenu, la seule autorisation SharePoint est le rôle d’administrateur de collection de sites.
Accorder en ajoutant un utilisateur ou un groupe ?
Vous pouvez obtenir le même résultat en accordant les autorisations à un utilisateur ou à un groupe, mais les deux modèles ont des pro et des con’s.
| Catégorie | Groupe | Utilisateur |
|---|---|---|
| Clarté | Un groupe peut contenir un ou plusieurs comptes, généralement non visibles par les autres administrateurs de collection de sites | Le compte d’utilisateur est toujours visible, il n’y a aucun doute à ce sujet |
| Maintenance | Vous pouvez facilement accorder l’accès en ajoutant de nouveaux membres au groupe | Les nouveaux membres doivent être ajoutés à tous les sites |
| Preuve de falsification | Un groupe peut protéger les comptes réels ayant accès (par exemple, un compte juridique) et les autres administrateurs sont moins susceptibles de supprimer les autorisations pour le groupe. | Il existe une transparence totale, d’autres administrateurs peuvent être plus susceptibles de supprimer les utilisateurs « inso » de leur site. |
Important
L’octroi d’autorisations à l’aide d’un groupe est un modèle plus flexible.
Qu’en est-il des sites d’équipe modernes (c’est-à-dire, sites de groupe)?
Les sites d’équipe modernes SharePoint sites d’équipe qui sont connectés à un Microsoft 365 groupe. Ce groupe Microsoft 365 agit comme un modèle central pour accorder l’accès à tous les services au-dessus de ce groupe (par exemple, site SharePoint, boîte aux lettres Exchange, Planificateur, ...) Pour ces sites, vous avez 2 options pour accorder l’accès :
- Ajoutez des comptes d’utilisateur (aucun groupe) aux membres ou propriétaires du groupe Microsoft 365 connecté au site d’équipe moderne. L’avantage de cette approche est que l’autorisation accordée s’applique à tous les services qui utilisent ce groupe, mais lorsque vous évaluez des stratégies d’application web, cela n’est généralement pas pertinent.
- Traiter le site d’équipe moderne comme un site « normal » et accorder des autorisations comme décrit dans les chapitres précédents
Important
Nous vous recommandons d’accorder des autorisations SharePoint niveau, donc traitez les sites d’équipe modernes comme des sites d’équipe classiques SharePoint classiques. Cette approche s’aligne sur ce que les stratégies d’application web fournissaient.
Octroi d’autorisations à l’aide de PowerShell PnP
Les scripts ci-dessous montrent un moyen simple d’accorder l’accès via PowerShell PnP et ils peuvent être un bon point de départ pour votre implémentation. Les scripts ci-dessous ne prennent pas en compte les considérations suivantes :
- Get-PnPTenantSite'est pas en cours d’éumeration des sites d’équipe modernes
- Get-PnPTenantSite n’est pas pris en compte pour multigéo
- Les performances ne sont pas optimales, car les scripts s’exécutent de manière séquentielle, il n’y a pas d’exécution parallèle
Étant donné que les utilisateurs créent en permanence de nouvelles collections de sites, il est important d’exécuter ces scripts régulièrement, dans l’idéal en tant que tâche programmée.
Notes
PnP PowerShell est une solution open source pour laquelle un support est assuré par la communauté active. Il n’existe pas de contrat SLA Microsoft pour le support technique relatif à cet outil open source.
Important
Si votre client dispose d’un grand nombre de collections de sites, l’utilisation d’une application développée personnalisée est une meilleure solution pour vous.
Contrôle total
Pour donner aux utilisateurs un contrôle total sur des sites SharePoint spécifiques (ou tous), vous pouvez utiliser SharePoint PowerShell pour rendre les utilisateurs cibles administrateurs de la collection de sites des sites cibles (y compris tous). Cette fonction peut être effectuée par un administrateur général ou un administrateur SharePoint service. Il est recommandé d’ajouter l’accès en fonction des besoins, puis de le supprimer. Par exemple, le script ci-dessous affecte une liste d’administrateurs à toutes les collections de sites d’un client. L’exemple utilise SharePoint modèles et pratiques (PnP) des commandes PowerShell pour faire de deux utilisateurs des administrateurs de toutes les collections de sites dans le client.
# comma separated list of users and groups to be added
$adminAccounts = "admin1@contoso.onmicrosoft.com","admin21@contoso.onmicrosoft.com"
# Specify the tenant here
$tenant = "contoso"
# Note: This example assumes that you are managing your credentials in Windows as documented here:
# https://github.com/SharePoint/PnP-PowerShell/wiki/How-to-use-the-Windows-Credential-Manager-to-ease-authentication-with-PnP-PowerShell
write-host "Connecting to https://$($tenant)-admin.sharepoint.com"
Connect-PnPOnline -Url "https://$($tenant)-admin.sharepoint.com"
#Note: we are only fetching the root site collection and any site collection in the /sites path
#Update filters here accordingly to match your requirements
write-host "Getting list of site collections"
$sitecollections = Get-PnPTenantSite | where {($_.Url -like "*$($tenant).sharepoint.com/") -or ($_.Url -like "*$($tenant).sharepoint.com/sites/*")}
foreach($sitecollection in $sitecollections) {
write-host "Adding administrators to $($sitecollection.Url)"
Set-PnPTenantSite -Url $sitecollection.Url -Owners $adminAccounts
}
Lecture complète
Pour donner aux utilisateurs une lecture complète sur des sites SharePoint spécifiques (ou tous), vous pouvez utiliser SharePoint PowerShell pour ajouter les utilisateurs cibles à un rôle de lecture de collection de sites. Cette fonction peut être effectuée par un administrateur général ou un administrateur SharePoint service. Les étapes générales incluent la définition d’un rôle SharePoint lecture pour la collection de sites ou la réutilisation d’un rôle existant, puis l’affectation d’utilisateurs ou de groupes au rôle. Pour utiliser des groupes Azure AD, y compris ceux avec appartenance dynamique, pour contrôler l’accès aux ressources, reportez-vous à : Gérer l’accès aux ressources avec Azure Active Directory groupes. L’exemple utilise SharePoint modèles et pratiques (PnP) des commandes PowerShell pour créer un rôle de lecture pour toutes les collections de sites dans le client.
# Specify the tenant here
$tenant = "contoso"
# Note: This example assumes that you are managing your credentials in Windows as documented here:
# https://github.com/SharePoint/PnP-PowerShell/wiki/How-to-use-the-Windows-Credential-Manager-to-ease-authentication-with-PnP-PowerShell
write-host "Connecting to https://$($tenant)-admin.sharepoint.com"
Connect-PnPOnline -Url "https://$($tenant)-admin.sharepoint.com"
# Note: we are only fetching the root site collection and any site collection in the /sites/ path
# Update filters here accordingly to match your requirements
write-host "Getting list of site collections"
$sitecollections = Get-PnPTenantSite | where {($_.Url -like "*$($tenant).sharepoint.com/") -or ($_.Url -like "*$($tenant).sharepoint.com/sites/*")}
foreach($sitecollection in $sitecollections) {
write-host "Set FullRead for MyGroup to $($sitecollection.Url)"
Connect-PnPOnline -Url $($sitecollection.Url)
New-PnPGroup -Title 'FullReader'
Set-PnPGroupPermissions -Identity 'FullReader' -RemoveRole 'Full Control' -AddRole 'Read'
}
Octroi d’autorisations à l’aide d’une application développée personnalisée
Un autre modèle pour l’approche PowerShell consiste à créer une application en arrière-plan qui éume toutes les collections de sites (y compris les sites d’équipe modernes, les sites OneDrive Entreprise, dans les différents emplacements lors de l’utilisation de Multi-Géo), vérifie si l’utilisateur/groupe nécessaire a accès et si elle n’en ajoute pas une. L’architecture d’une telle application peut être aussi simple que celle définie ci-dessous :
- Vous commencez par définir une application dans Azure AD pour laquelle vous programmez l’utilisation de l’application uniquement (voir Accorder l’accès via Application Azure ADuniquement) et octroyer un contrôle total sur toutes les collections de sites
- Vous créez une application C# qui s’autorise à utiliser l’application Azure AD que vous avez définie à l’étape 1 et qui s’itérera sur toutes les collections de sites (cela peut inclure des collections de sites OD4B) pour ajouter les comptes/groupes nécessaires s’ils ne sont pas présents
- Cette C# application doit ensuite être hébergée et programmée pour s’exécuter à intervalles réguliers. L’utilisation d’un travail web Azure est un bon modèle pour le faire, mais il est possible d’en faire de même en exécutant l’application en tant que tâche programmée sur un serveur.

Dans le cadre de ces instructions, nous avons créé une application pour vous aider à démarrer. L’exemple est appelé Governance.EnsurePolicy et peut se trouver dans SharePoint référentiel PnP.
Notes
Ce scénario peut être étendu à une application qui accorde et supprime des autorisations de manière conditionnable. Par exemple, les employés du helpdesk peuvent demander l’accès à un site donné via la création d’un élément de liste SharePoint, l’application le voit et accorde l’accès pendant x heures... et supprime les autorisations ultérieurement. Cette application conserve également un journal indiquant qui a reçu l’accès à quel site et à quel moment.
Refus d’accès
Remplacer la stratégie Refuser tout à l’Office 365 et SharePoint contrôles d’accès
Il n’existe aucune stratégie « Refuser tout » dans Office 365, plutôt que notre approche recommandée consiste à gérer les autorisations à l’aide d’O365 SharePoint de contrôle d’accès. Le paysage doit inclure les utilisateurs, les applications et les appareils. Certaines de ces stratégies de contrôle d’accès sont décrites ci-dessous.
Pour empêcher des utilisateurs spécifiques d’accéder aux ressources Office 365, y compris SharePoint, suivez les instructions décrites ici : Supprimer un ancien employé de Office 365 . Par exemple, pour couper l’accès à un employé qui a quitté l’organisation. Cela peut être effectué par un administrateur général ou un administrateur de gestion des utilisateurs à l’aide du centre Office 365 Admin ou d’un script à l’aide de PowerShell.
Pour limiter le partage externe afin que les fournisseurs, clients ou clients n’ont accès qu’à des ressources spécifiques, suivez les instructions ci-après : Gérer le partage externe pour votre environnement SharePoint Online. Par exemple, vous pouvez configurer un site extranet SharePoint Online axé sur la collaboration externe.
Pour bloquer ou autoriser le partage avec des utilisateurs externes à partir de domaines spécifiques au niveau du client ou de la collection de sites, suivez les instructions ci-après : Partage de domaines restreintsdans SharePoint Online et OneDrive Entreprise . Par exemple, pour limiter le partage avec des partenaires commerciaux spécifiques sur des domaines connus uniquement. Cela peut être configuré par un administrateur général ou un administrateur SharePoint service.
Avec Office 365 sécurité et conformité, vous pouvez utiliser les fonctionnalités d’audit pour suivre l’activité des fichiers. Pour plus d’informations, voir les articles suivants :
- Audit de toutes vos collections de sites SharePoint à l’aide du Centre de sécurité et conformité Office 365 : recherchez le journal d’auditdans le Centre de sécurité & conformité Office 365. Cette approche vous permet d’auditer tous vos sites, d’utiliser un modèle de création de rapports flexible et d’utiliser des API pour traiter les données d’auditde manière personnalisée.
- Utilisez Sécurité des applications cloud Office 365: Sécurité des applications cloud Office 365 vous donne un aperçu des activités suspectes dans Office 365 afin que vous pouvez examiner les situations potentiellement problématiques et, si nécessaire, prendre des mesures pour résoudre les problèmes de sécurité. Avec Sécurité des applications cloud Office 365, vous pouvez :
- Découvrez comment les données de votre organisation dans Office 365 sont accessibles et utilisées
- Définir des stratégies qui déclenchent des alertes pour des activités inhabituels ou suspectes
- Suspendre des comptes d’utilisateur présentant une activité suspecte
- Exiger que les utilisateurs se connectent à Office 365 applications après le déclenchement d’une alerte
Avec le Centre de sécurité et conformité Office 365, vous pouvez également bloquer le partage externe de documents sensibles en définissant les types sensibles de votre organisation (choisissez l’un des nombreux modèles ou créez vos propres types sensibles personnalisés). Découvrez les types d’informations sensibles intégrés ici : Types d’informations sensibles. En savoir plus sur la création de votre propre ici : créer des types d’informations sensibles personnalisés.
Pour utiliser des groupes Azure AD, y compris ceux avec appartenance dynamique, pour contrôler l’accès aux ressources, reportez-vous à : Gérer l’accès aux ressources avec Azure Active Directory groupes. Par exemple, les groupes peuvent être configurés pour supprimer des membres dont le compte n’est pas activé. En outre, Azure Active Directory Identity Protection (partie de Azure AD Premium) permet aux administrateurs d’identifier les connecteurs à risque et de bloquer ou de nécessiter une authentification multifacteur.
Pour bloquer ou limiter l’accès sur les appareils non conformes ou non utilisés, des fonctionnalités seront bientôt disponible, ce qui tirera parti Azure Active Directory d’accès conditionnel. À l’aide de cette stratégie, vous pouvez bloquer l’accès aux applications enrichies sur les appareils non utilisés et autoriser l’accès au navigateur uniquement sans avoir la possibilité de télécharger, d’imprimer ou de synchroniser. Cela permet d’éviter les fuites de données sur les appareils non utilisés. Cela sera configurable par un administrateur général ou un administrateur SharePoint service.
Pour bloquer l’accès à des emplacements réseau non fiables, vous pouvez utiliser une stratégie basée sur l’emplacement pour configurer une liste d’adresses IP de confiance à partir des lesquelles l’accès est autorisé. Suivez les instructions ci-après : Contrôler l’accès aux SharePoint et OneDrive en fonction des emplacements réseau.