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 aux utilisateurs et aux groupes pour tous les sites d’une application web. Ces autorisations accordées et refusées prennent la préférence sur les autorisations définies sur les sites de 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 accéder à SharePoint
- Accorder à l’équipe du support technique un accès en lecture seule à tous les sites afin que l’ingénieur du support puisse parcourir le site avec l’utilisateur final
- Refuser aux utilisateurs (par exemple, après avoir quitté l’entreprise) l’accès à tout le contenu
Les stratégies d’application web n’existent plus dans SharePoint Online et il n’existe pas d’implémentation alternative 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 ?
Avant de commencer à implémenter des octrois d’autorisations, il est important de comprendre pourquoi une subvention a été nécessaire. Les questions à vous poser sont les suivantes :
- L’octroi de l’accès à toutes les données de votre locataire SharePoint Online est-il nécessaire ? Push back et vérifier que l’accès à toutes les données est un must absolu pour prendre en charge un scénario métier
- Le « un » utilise-t-il l’autorisation accordée à une application ou à un utilisateur ? S’il s’agit d’une application, il peut être possible d’utiliser un principal d’application disposant d’autorisations à l’échelle du locataire SharePoint Online, en particulier s’il s’agit d’une application développée en interne
L’organigramme ci-dessous capture les questions suivantes :
Importante
Dans le cas où l’accès accordé est consommé par un utilisateur ou une application qui n’est pas compatible avec les principaux d’application, vous devez accorder l’accès via des utilisateurs ou des groupes. Si possible, préférez les principaux d’application aux utilisateurs et aux groupes pour les raisons suivantes :
- 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 automatiquement accès également. 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 d’autorisation. Supposons qu’un sous-site dispose d’un héritage d’autorisation rompu et que, par conséquent, l’octroi d’un utilisateur/propriétaire de groupe, la contribution ou l’affichage de l’accès au site racine accorde l’accès au sous-site, tandis que le principal de l’application y aura toujours accès.
Octroi de l’accès à l’aide de principaux d’application
Pour tous les accès non humains, il est recommandé d’utiliser des 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 recommandée lors de l’utilisation de SharePoint Online, car vous pouvez également accorder des autorisations à d’autres services Office 365 (si nécessaire) et vous disposez d’une interface utilisateur (Portail Azure) pour gérer vos principaux d’application.
- Utilisation d’un principal de App-Only SharePoint : cette méthode est plus ancienne et ne fonctionne que pour l’accès SharePoint, mais elle est toujours pertinente. Cette méthode est également le modèle recommandé lorsque vous travaillez toujours dans SharePoint en local, car ce modèle fonctionne dans SharePoint en local comme SharePoint Online.
Les deux modèles sont expliqués en détail dans l’article Accès à SharePoint à l’aide d’un contexte d’application, également appelé 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 ce que vous aviez 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 l’accès à tous les sites.
Autorisations qui peuvent être accordées
À l’aide de stratégies d’application web, vous avez la possibilité d’accorder le « contrôle total » ou la « lecture complète », ce qui se traduit par des autorisations SharePoint :
| Octroi de stratégie d’application web | Autorisation 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 nous évitons ainsi le problème d’héritage des autorisations. Dans SharePoint, les utilisateurs peuvent interrompre l’héritage des autorisations et, par conséquent, accorder des autorisations uniques sur des objets (par exemple, des sous-sites, des listes, des éléments de liste). Si cela a été fait et que, par exemple, vous ajoutez un utilisateur au groupe de propriétaires de sites de la collection de sites, cet utilisateur n’aurait pas d’autorisations sur l’objet avec des autorisations uniques.
Importante
Si le scénario métier que vous implémentez peut respecter les limitations d’héritage des autorisations, vous pouvez utiliser l’une des autorisations SharePoint décrites. Si vous devez garantir un accès à 100 % sûr à tout le contenu, la seule autorisation SharePoint appropriée est le rôle d’administrateur de collection de sites.
Vous accordez 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 avantages et des inconvénients.
| Catégorie | Groupe | Utilisateur |
|---|---|---|
| Clarity | 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 |
| Inviolable | Un groupe peut protéger les comptes réels ayant accès (par exemple, un compte légal) et les autres administrateurs sont moins susceptibles de supprimer les autorisations pour le groupe | Il y a une transparence totale, d’autres administrateurs peuvent être plus susceptibles de supprimer les utilisateurs « bizarres » de leur site |
Importante
L’octroi d’autorisations à l’aide d’un groupe est un modèle plus flexible.
Qu’en est-il des sites d’équipe modernes (également noms de sites de groupe) ?
Les sites d’équipe modernes sont des sites d’équipe SharePoint connectés à un groupe Microsoft 365. Ce groupe Microsoft 365 agit comme un modèle central pour accorder l’accès à tous les services en plus 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 aux 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 lors de l’évaluation des stratégies d’application web, cela n’est généralement pas pertinent.
- Traitez le site d’équipe moderne comme un site « normal » et accordez une autorisation comme décrit dans les chapitres précédents
Importante
Nous vous recommandons d’accorder des autorisations au niveau SharePoint. Par conséquent, traitez les sites d’équipe modernes comme les sites d’équipe SharePoint classiques. Cette approche s’aligne sur ce que les stratégies d’application web fournissaient.
Octroi d’autorisations à l’aide de PnP PowerShell
Les scripts ci-dessous montrent un moyen simple d’accorder l’accès à l’aide de PnP PowerShell et ils peuvent constituer une bonne base de départ pour votre implémentation. Les scripts ci-dessous ne prennent pas en compte les éléments suivants :
- Get-PnPTenantSite n’énumére actuellement pas les sites d’équipe modernes
- Get-PnPTenantSite n’est pas multigéographique
- 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 des collections de sites, il est important d’exécuter ces scripts régulièrement, idéalement en tant que tâche planifiée.
Remarque
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.
Importante
Si votre locataire possède un grand nombre de collections de sites, l’approche utilisant une application personnalisée développé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). Cela peut être effectué par un administrateur Administrateur général ou 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 locataire. L’exemple utilise les modèles et pratiques SharePoint (PnP) des commandes PowerShell pour rendre deux utilisateurs administrateurs de toutes les collections de sites dans le locataire.
# 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 de certains (ou de tous) sites SharePoint, vous pouvez utiliser SharePoint PowerShell pour ajouter les utilisateurs cibles à un rôle lecture de collection de sites. Cela peut être effectué par un administrateur Administrateur général ou SharePoint Service. Les étapes générales incluent la définition d’un rôle de lecture SharePoint pour la collection de sites ou la réutilisation d’un rôle existant, puis l’attribution d’utilisateurs ou de groupes au rôle. Pour utiliser des groupes Azure AD, y compris ceux avec une appartenance dynamique, pour contrôler l’accès aux ressources, consultez : Gérer l’accès aux ressources avec des groupes Azure Active Directory. L’exemple utilise les modèles et pratiques SharePoint (PnP) des commandes PowerShell pour créer un rôle de lecture pour toutes les collections de sites dans le locataire.
# 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 énumère toutes les collections de sites (y compris les sites d’équipe modernes, OneDrive Entreprise les sites, entre les emplacements lors de l’utilisation de multigéographiques), vérifie si l’utilisateur/groupe nécessaire a accès et, si ce n’est pas le cas, ajoute celle-ci. 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 configurez l’utilisation de l’application uniquement (consultez Octroi de l’accès via Azure AD App-Only) et accordez 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 effectue une itération sur toutes les collections de sites (cela peut inclure les collections de sites OD4B) pour ajouter les comptes/groupes nécessaires s’ils ne sont pas présents
- Cette application C# doit ensuite être hébergée et planifiée pour s’exécuter à intervalles réguliers. L’utilisation d’un travail web Azure est un bon modèle pour le faire, mais la même chose peut être effectuée en exécutant l’application en tant que tâche planifiée sur un serveur
Dans le cadre de ces conseils, nous avons créé une application pour vous aider à démarrer avec cela. L’exemple est appelé Governance.EnsurePolicy et peut se trouver dans le référentiel PnP SharePoint.
Remarque
Ce scénario peut être développé dans une application qui accorde et supprime des autorisations de manière conditionnelle. Par exemple, les employés du support technique peuvent demander l’accès à un site donné en créant un élément de liste SharePoint, l’application voit cela et accorde l’accès pendant x heures... et supprime les autorisations ultérieurement. Cette application conserve également un journal indiquant qui a été autorisé à accéder à quel site et quand.
Refus d’accès
Remplacer refuser toute stratégie à l’aide de Office 365 et de contrôles d’accès SharePoint
Il n’existe aucune stratégie « Refuser tout » dans Office 365, mais notre approche recommandée consiste à gérer les autorisations à l’aide des stratégies de contrôle d’accès SharePoint O365. Le paysage doit inclure utilisateurs, applications et 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é le organization. Cette opération peut être effectuée par un administrateur Administrateur général ou de gestion des utilisateurs à l’aide du centre de Office 365 Admin ou par script à l’aide de PowerShell.
Pour limiter le partage externe afin que les fournisseurs, les clients ou les clients n’aient accès qu’à des ressources spécifiques, suivez les instructions fournies ici : 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 locataire ou de la collection de sites, suivez les instructions ici : Partage de domaines restreints dans SharePoint Online et OneDrive Entreprise. Par exemple, pour limiter le partage avec des partenaires commerciaux spécifiques dans des domaines bien connus. Cela peut être configuré par un Administrateur général ou un administrateur de service SharePoint.
Avec Office 365 Centre de sécurité et de conformité, vous pouvez utiliser les fonctionnalités d’audit pour suivre l’activité des fichiers. Pour en savoir plus, consultez les articles suivants :
- Audit de toutes vos collections de sites SharePoint à l’aide du Centre de sécurité et de conformité Office 365 : recherchez le journal d’audit dans le Centre de conformité Office 365 Sécurité &. Cette approche vous offre un audit de tous vos sites, un modèle de création de rapports flexible et vous pouvez utiliser des API pour effectuer un traitement personnalisé des données d’audit.
- Utiliser Sécurité des applications cloud Office 365 : Sécurité des applications cloud Office 365 vous donne des informations sur les activités suspectes dans Office 365 afin de pouvoir examiner les situations potentiellement problématiques et, si nécessaire, prendre des mesures pour y remédier problèmes de sécurité. Avec Sécurité des applications cloud Office 365, vous pouvez effectuer toutes les opérations suivantes :
- Voir comment les données de votre organization dans Office 365 sont consultées et utilisées
- Définir des stratégies qui déclenchent des alertes pour les activités atypiques ou suspectes
- Suspendre les comptes d’utilisateur présentant une activité suspecte
- Exiger que les utilisateurs se reconnectent à Office 365 applications après le déclenchement d’une alerte
Avec Office 365 Centre de sécurité et de conformité, vous pouvez également bloquer le partage externe de documents sensibles en définissant les types sensibles dans votre organization (choisissez parmi l’un des nombreux modèles ou créez vos propres types sensibles personnalisés). Découvrez les types sensibles intégrés ici : Types d’informations sensibles. En savoir plus sur la création de vos propres types d’informations sensibles ici : Créer des types d’informations sensibles personnalisés.
Pour utiliser des groupes Azure AD, y compris ceux avec une appartenance dynamique, pour contrôler l’accès aux ressources, consultez : Gérer l’accès aux ressources avec des groupes Azure Active Directory. Par exemple, les groupes peuvent être configurés pour supprimer les membres dont le compte n’est pas activé. En outre, Azure Active Directory Identity Protection (qui fait partie d’Azure AD Premium) permet aux administrateurs d’identifier les connexions à risque et de bloquer ou d’exiger l’authentification multifacteur.
Pour bloquer ou limiter l’accès sur les appareils non conformes ou non gérés, des fonctionnalités seront bientôt disponibles et tirent parti des stratégies d’accès conditionnel Azure Active Directory. À l’aide de cette stratégie, vous pouvez bloquer l’accès aux applications enrichies sur les appareils non gérés et autoriser l’accès du navigateur uniquement sans pouvoir télécharger, imprimer ou synchroniser. Cela empêche les fuites de données sur les appareils non gérés. Cela sera configurable par un administrateur de service Administrateur général ou SharePoint.
Pour bloquer l’accès aux emplacements réseau non approuvés, vous pouvez utiliser une stratégie basée sur l’emplacement pour configurer une liste d’adresses IP approuvées à partir desquelles l’accès est autorisé. Suivez les instructions ici : Contrôler l’accès à SharePoint et OneDrive en fonction des emplacements réseau.