Infrastructure de sécurité : Autorisation | Mesures de correction

Produit/Service	Article
Délimitation d’approbation machine	Vérifier que les ACL appropriées sont configurées pour limiter l’accès non autorisé aux données sur l’appareil Vérifier que le contenu sensible d’application spécifique à l’utilisateur est stocké dans le répertoire du profil utilisateur Vérifier que les applications déployées sont exécutées avec des privilèges minimum
Application Web	Appliquer l’ordre d’étapes séquentiel pendant le traitement du flux de logique d’entreprise Implémenter le mécanisme de limitation du débit pour empêcher une énumération Vérifier que l’autorisation appropriée est en place et que le principe de privilèges minimum est respecté Les décisions de logique d’entreprise et d’autorisation d’accès aux ressources ne doivent pas être basées sur les paramètres de demande entrante Vérifier que le contenu et les ressources ne sont pas énumérables ou accessibles via la navigation forcée
Sauvegarde de la base de données	Vérifier que des comptes avec des privilèges minimum sont utilisés pour se connecter au serveur de base de données Implémenter la sécurité au niveau des lignes (RLS) pour empêcher les locataires d’accéder aux données des autres Le rôle Administrateur système doit comporter uniquement des utilisateurs valides nécessaires
Passerelle de cloud IoT	Se connecter à la passerelle de cloud à l’aide de jetons avec des privilèges minimum
Azure Event Hub	Utiliser une clé SAP d’autorisations d’envoi seulement pour générer des jetons d’appareil Ne pas utiliser des jetons d’accès qui fournissent un accès direct au concentrateur d’événement Se connecter au concentrateur d’événement à l’aide des clés SAP qui disposent des autorisations minimales requises
Azure Document DB	Utiliser des jetons de ressource pour se connecter à Azure Cosmos DB le cas échéant
Délimitation d’approbation Azure	Activer la gestion précise des accès à un abonnement Azure en utilisant RBAC
Délimitation d’approbation Service Fabric	Restreindre l’accès du client aux opérations de cluster en utilisant Azure RBAC
Dynamics CRM	Effectuer la modélisation de sécurité et utiliser la sécurité au niveau des champs si nécessaire
Portail Dynamics CRM	Effectuer la modélisation de sécurité des comptes du portail en gardant à l’esprit que le modèle de sécurité pour le portail est différent du reste de CRM
Stockage Azure	Accorder une autorisation précise sur un ensemble d’entités dans Azure Table Storage Activer le contrôle d’accès en fonction du rôle Azure (Azure RBAC) sur le compte de stockage Azure en utilisant Azure Resource Manager
Client mobile	Implémenter la libération implicite ou la détection du rootage
WCF	Référence de classe faible dans WCF WCF - Implémenter le contrôle de l’autorisation
API Web	Implémenter le mécanisme d’autorisation approprié dans l’API web ASP.NET
Appareil IoT	Effectuer des vérifications d’autorisation dans l’appareil s’il prend en charge diverses actions nécessitant différents niveaux d’autorisation
Passerelle de champ IoT	Effectuer des vérifications d’autorisation dans la passerelle de champ si elle prend en charge diverses actions nécessitant différents niveaux d’autorisation

Vérifier que les ACL appropriées sont configurées pour limiter l’accès non autorisé aux données sur l’appareil

Intitulé	Détails
Composant	Délimitation d’approbation machine
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Vérifier que les ACL appropriées sont configurées pour limiter l’accès non autorisé aux données sur l’appareil

Vérifier que le contenu sensible d’application spécifique à l’utilisateur est stocké dans le répertoire du profil utilisateur

Intitulé	Détails
Composant	Délimitation d’approbation machine
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Vérifiez que le contenu sensible d’application spécifique à l’utilisateur est stocké dans le répertoire du profil utilisateur. Cela vise à empêcher plusieurs utilisateurs de la machine d’accéder aux données des autres.

Vérifier que les applications déployées sont exécutées avec des privilèges minimum

Intitulé	Détails
Composant	Délimitation d’approbation machine
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Vérifiez que l’application déployée est exécutée avec des privilèges minimum.

Appliquer l’ordre d’étapes séquentiel pendant le traitement du flux de logique d’entreprise

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Pour vérifier que cette étape a été exécutée par un utilisateur authentique, vous souhaitez forcer l’application à ne traiter que les flux de logique d’entreprise dans l’ordre séquentiel des étapes, toutes les étapes étant traitées sur une durée humainement réaliste, et à ne pas traiter des étapes ignorées externes à l’ordre, des étapes traitées par un autre utilisateur ou des transactions soumises trop rapidement.

Implémenter le mécanisme de limitation du débit pour empêcher une énumération

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Vérifiez que les identificateurs sensibles sont aléatoires. Implémentez le contrôle CAPTCHA sur les pages anonymes. Vérifier que les erreurs et les exceptions ne révèlent pas de données spécifiques

Vérifier que l’autorisation appropriée est en place et que le principe de privilèges minimum est respecté

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Le principe implique de n’accorder à un compte d’utilisateur que les privilèges essentiels pour que les utilisateurs puissent travailler. Par exemple, un utilisateur de sauvegarde n’a pas besoin d’installer de logiciels : l’utilisateur de sauvegarde dispose donc uniquement de droits d’exécution et d’applications liées à la sauvegarde. Tous les autres privilèges, comme l’installation de nouveaux logiciels, sont bloqués. Le principe s’applique également à un utilisateur d’ordinateur personnel qui utilise généralement un compte d’utilisateur normal et ouvre un compte privilégié, protégé par mot de passe (à savoir, un superutilisateur), uniquement lorsque la situation l’exige. Ce principe peut également être appliqué à vos applications web. Plutôt que de dépendre uniquement de méthodes d’authentification basées sur le rôle à l’aide de sessions, nous souhaitons affecter des privilèges aux utilisateurs au moyen d’un système d’authentification basé sur la base de données. Nous utilisons toujours des sessions pour déterminer si l’utilisateur s’est connecté correctement. Mais plutôt que d’attribuer à cet utilisateur un rôle spécifique, nous lui accordons maintenant des privilèges pour vérifier les actions qu’il est autorisé à effectuer sur le système. Un avantage considérable de cette méthode est tel que, lorsque des privilèges inférieurs doivent être accordés à un utilisateur, vos modifications sont appliquées à la volée car l’affectation ne dépend pas la session qui arriverait à expiration en premier.

Les décisions de logique d’entreprise et d’autorisation d’accès aux ressources ne doivent pas être basées sur les paramètres de demande entrante

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Chaque fois que vous vérifiez si un utilisateur est limité à la consultation de certaines données, les restrictions d’accès doivent être traitées côté serveur. L’ID utilisateur doit être stocké dans une variable de session au moment de la connexion et doit être utilisé pour récupérer les données utilisateur dans la base de données

Exemple

SELECT data 
FROM personaldata 
WHERE userID=:id < - session var 

Un éventuel intrus ne peut désormais plus altérer ni modifier l’opération de l’application, car l’identificateur de récupération des données est géré côté serveur.

Vérifier que le contenu et les ressources ne sont pas énumérables ou accessibles via la navigation forcée

Intitulé	Détails
Composant	Application Web
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Les fichiers statiques et de configuration sensibles ne doivent pas être conservés dans le webroot. Pour le contenu ne devant pas être rendu public, des contrôles d’accès appropriés doivent être appliqués ou le contenu lui-même doit être supprimé. De plus, la navigation forcée est généralement combinée à des techniques de force brute pour collecter des informations en tentant d’accéder au plus grand nombre d’URL possible afin d’énumérer des répertoires et des fichiers sur un serveur. Les personnes malveillantes peuvent vérifier toutes les variantes des fichiers existants généralement. Par exemple, la recherche de fichiers de mot de passe peut englober des fichiers tels que psswd.txt, password.htm, password.dat et d’autres variations. Pour corriger ce problème, des fonctionnalités de tentatives de détection en force brute doivent être incluses.

Vérifier que des comptes avec des privilèges minimum sont utilisés pour se connecter au serveur de base de données

Intitulé	Détails
Composant	Base de données
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Hiérarchie d’autorisations SQL, Éléments sécurisables SQL
Étapes	Des comptes avec des privilèges minimum doivent être utilisés pour se connecter à la base de données. La connexion d’application doit être limitée dans la base de données et ne doit exécuter que des procédures stockées sélectionnées. La connexion de l’application ne doit pas disposer d’un accès direct à la table.

Implémenter la sécurité au niveau des lignes (RLS) pour empêcher les locataires d’accéder aux données des autres

Intitulé	Détails
Composant	Base de données
Phase SDL	Build
Technologies applicables	SQL Azure, local
Attributs	Version SQL - V12, Version SQL - MsSQL2016
Informations de référence	SQL Server - Sécurité au niveau des lignes (RLS)
Étapes	La sécurité au niveau des lignes permet aux clients de contrôler l’accès aux lignes d’une table de base de données en fonction des caractéristiques de l’utilisateur qui exécute une requête (par exemple, appartenance à un groupe ou contexte d’exécution). La sécurité au niveau des lignes simplifie la conception et codage de la sécurité dans votre application. Elle vous permet d’implémenter des restrictions sur l’accès aux lignes de données. Par exemple, en s’assurant que les employés ne peuvent accéder qu’aux lignes de données utiles à leur service, ou en limitant l’accès aux données d’un client aux données relatives à son entreprise uniquement. La logique de la restriction d'accès est située dans la couche de base de données plutôt que loin des données d'une autre couche Application. Le système de base de données applique les restrictions d'accès chaque fois que cet accès aux données est tenté à partir d'une couche quelconque. Le système de sécurité est ainsi plus fiable et plus robuste en réduisant la surface d’exposition du système de sécurité.

Veuillez noter que la sécurité au niveau des lignes, en tant que fonctionnalité de base de données prête à l’emploi, s’applique uniquement à SQL Server à partir de la version 2016, à Azure SQL Database et à Azure SQL Managed Instance. Si la fonctionnalité RLS prête à l’emploi n’est pas implémentée, assurez-vous que l’accès aux données est limité à l’aide de vues et de procédures

Le rôle Administrateur système doit comporter uniquement des utilisateurs valides nécessaires

Intitulé	Détails
Composant	Base de données
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Hiérarchie d’autorisations SQL, Éléments sécurisables SQL
Étapes	Les membres du rôle serveur fixe SysAdmin doivent être très limités et ne doivent jamais contenir des comptes utilisés par des applications. Veuillez consulter la liste des utilisateurs du rôle et supprimer les comptes inutiles

Se connecter à la passerelle de cloud à l’aide de jetons avec des privilèges minimum

Intitulé	Détails
Composant	Passerelle cloud IoT
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	Choix de passerelle - Azure IoT Hub
Informations de référence	Contrôle d’accès IOT Hub
Étapes	Accordez des autorisations avec des privilèges minimum à divers composants qui se connectent à la passerelle de cloud (IoT Hub). Un exemple typique est le composant de gestion des appareils/d’approvisionnement qui utilise registryread/write et Event Processor (ASA) qui utilise Service Connect. Les appareils individuels se connectent à l’aide d’informations d’identification d’appareil

Utiliser une clé SAP d’autorisations d’envoi seulement pour générer des jetons d’appareil

Intitulé	Détails
Composant	Azure Event Hub
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Présentation du modèle de sécurité et de l’authentification Event Hubs
Étapes	Une clé SAP est utilisée pour générer des jetons d’appareils individuels. Utiliser une clé SAP d’autorisations d’envoi seulement pendant la génération du jeton d’appareil pour un éditeur donné

Ne pas utiliser des jetons d’accès qui fournissent un accès direct au concentrateur d’événement

Intitulé	Détails
Composant	Azure Event Hub
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Présentation du modèle de sécurité et de l’authentification Event Hubs
Étapes	Un jeton qui accorde un accès direct au concentrateur d’événement ne doit pas être fourni à l’appareil. L’utilisation d’un jeton avec des privilèges minimum pour l’appareil, qui n’accorde l’accès qu’à un éditeur, permet d’identifier et d’interdire un appareil s’il est jugé non fiable ou compromis.

Se connecter au concentrateur d’événement à l’aide des clés SAP qui disposent des autorisations minimales requises

Intitulé	Détails
Composant	Azure Event Hub
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Présentation du modèle de sécurité et de l’authentification Event Hubs
Étapes	Accordez des autorisations avec des privilèges minimum à diverses applications principales qui se connectent au concentrateur d’événement. Générez des clés SAP distinctes pour chaque application principale et n’accordez que les autorisations requises (envoi, réception ou gestion).

Utiliser des jetons de ressource pour se connecter à Azure Cosmos DB le cas échéant

Intitulé	Détails
Composant	Azure Document DB
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Un jeton de ressource est associé à une ressource d’autorisation Azure Cosmos DB et capture la relation entre l’utilisateur d’une base de données et l’autorisation dont cet utilisateur dispose sur une ressource d’application Azure Cosmos DB (collection, document, etc.). Utilisez toujours un jeton de ressource pour accéder à Azure Cosmos DB si le client ne peut pas être approuvé avec la gestion des clés principales ou en lecture seule, par exemple une application d’utilisateur final comme un client mobile ou de bureau. Utilisez une clé principale ou des clés en lecture seule d’applications principales capables de stocker ces clés en toute sécurité.

Activer la gestion précise des accès à un abonnement Azure en utilisant Azure RBAC

Intitulé	Détails
Composant	Délimitation d’approbation Azure
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Attribuer des rôles Azure pour gérer l’accès aux ressources de votre abonnement Azure
Étapes	Le contrôle d’accès en fonction du rôle Azure (Azure RBAC) permet une gestion des accès affinée pour Azure. L’utilisation d’Azure RBAC vous permet d’accorder seulement les droits d’accès dont les utilisateurs ont besoin pour effectuer leur travail.

Restreindre l’accès du client aux opérations de cluster en utilisant RBAC Service Fabric

Intitulé	Détails
Composant	Délimitation d’approbation Service Fabric
Phase SDL	Déploiement
Technologies applicables	Générique
Attributs	Environnement - Azure
Informations de référence	Contrôle d’accès en fonction du rôle Service Fabric pour les clients Service Fabric
Étapes	Azure Service Fabric prend en charge deux types de contrôle d’accès différents pour les clients qui sont connectés à un cluster Service Fabric : administrateur et utilisateur. Le contrôle d'accès permet à l'administrateur du cluster de limiter l'accès à certaines opérations de cluster pour différents groupes d'utilisateurs, renforçant ainsi la sécurité du cluster. Les administrateurs ont un accès complet aux fonctions de gestion (y compris les fonctionnalités de lecture/écriture). Les utilisateurs, par défaut, ont uniquement un accès en lecture aux fonctionnalités de gestion (par exemple, aux fonctionnalités de requête) et la capacité à résoudre les applications et les services. Vous spécifiez les deux rôles clients (client et administrateur) au moment de la création du cluster en fournissant des certificats séparés pour chacun.

Effectuer la modélisation de sécurité et utiliser la sécurité au niveau des champs si nécessaire

Intitulé	Détails
Composant	Dynamics CRM
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Effectuer la modélisation de sécurité et utiliser la sécurité au niveau des champs si nécessaire

Effectuer la modélisation de sécurité des comptes du portail en gardant à l’esprit que le modèle de sécurité pour le portail est différent du reste de CRM

Intitulé	Détails
Composant	Portail Dynamics CRM
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	Effectuer la modélisation de sécurité des comptes du portail en gardant à l’esprit que le modèle de sécurité pour le portail est différent du reste de CRM

Accorder une autorisation précise sur un ensemble d’entités dans Azure Table Storage

Intitulé	Détails
Composant	Stockage Azure
Phase SDL	Build
Technologies applicables	Générique
Attributs	StorageType - Table
Informations de référence	Comment déléguer l’accès aux objets dans votre compte de stockage Azure à l’aide de SAP
Étapes	Dans certains scénarios d’entreprise, Azure Table Storage peut être nécessaire pour stocker des données sensibles répondant aux besoins des différentes parties. Par exemple, les données sensibles relatives aux différents pays ou différentes régions. Dans ce cas, les signatures SAP peuvent être créées en spécifiant les plages de clés de partitions et de lignes, de sorte qu’un utilisateur puisse accéder aux données spécifiques à un pays ou à une région en particulier.

Activer le contrôle d’accès en fonction du rôle Azure (Azure RBAC) sur le compte de stockage Azure en utilisant Azure Resource Manager

Intitulé	Détails
Composant	Stockage Azure
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	Comment sécuriser votre compte de stockage avec le contrôle d’accès en fonction du rôle Azure (RBAC Azure)
Étapes	Lorsque vous créez un compte de stockage, vous sélectionnez un modèle de déploiement Classique ou Azure Resource Manager. Le modèle classique de création de ressources dans Azure autorise seulement un accès « tout ou rien » à l’abonnement et, à tour de rôle, au compte de stockage. Avec le modèle Azure Resource Manager, vous devez placer le compte de stockage dans un groupe de ressources et contrôler l’accès au plan de gestion de ce compte de stockage spécifique à l’aide de Microsoft Entra ID. Par exemple, vous pouvez permettre à certains utilisateurs d’accéder aux clés de compte de stockage, pendant que d’autres pourront voir les informations relatives au compte de stockage, mais pas accéder aux clés de compte de stockage.

Implémenter la libération implicite ou la détection du rootage

Intitulé	Détails
Composant	Client mobile
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	L’application doit protéger sa propre configuration et les données utilisateur au cas où le téléphone serait rooté ou libéré. Le rootage/la libération implique un accès non autorisé, ce que les utilisateurs normaux ne feront pas sur leurs téléphones. L’application doit donc disposer d’une logique de détection implicite au démarrage de l’application pour détecter si le téléphone a été rooté. La logique de détection peut permettre d’accéder à des fichiers qui ne sont normalement accessibles qu’à l’utilisateur racine, par exemple : /system/app/Superuser.apk /sbin/su /system/bin/su /system/xbin/su /data/local/xbin/su /data/local/bin/su /system/sd/xbin/su /system/bin/failsafe/su /data/local/su Si l’application peut accéder à l’un de ces fichiers, cela signifie que l’application est exécutée en tant qu’utilisateur racine.

Référence de classe faible dans WCF

Intitulé	Détails
Composant	WCF
Phase SDL	Build
Technologies applicables	Générique, NET Framework 3
Attributs	N/A
Informations de référence	MSDN, Fortify Kingdom
Étapes	Le système utilise une référence de classe faible, permettant ainsi à une personne malveillante d’exécuter du code non autorisé. Le programme fait référence à une classe définie par l’utilisateur qui n’est pas identifiée de manière unique. Lorsque .NET charge cette classe identifiée de manière faible, le chargeur de type CLR recherche la classe dans les emplacements suivants, dans l’ordre indiqué : Si le type de l’assembly est connu, le chargeur recherche les emplacements de redirection du fichier de configuration, GAC, l’assembly actuel à l’aide d’informations de configuration et le répertoire de base d’application Si l’assembly est inconnu, le chargeur recherche l’assembly actuel, mscorlib et l’emplacement renvoyé par le gestionnaire d’événements TypeResolve Cet ordre de recherche CLR peut être modifié avec des raccordements tels que le mécanisme de transfert de type et l’événement AppDomain.TypeResolve Si une personne malveillante exploite l’ordre de recherche CLR en créant une autre classe portant le même nom et en la plaçant dans un emplacement autre que l’emplacement de chargement CLR initial, le CLR exécutera involontairement le code fourni par la personne malveillante

Exemple

L’élément <behaviorExtensions/> du fichier de configuration WCF ci-dessous indique à WCF d’ajouter une classe de comportements personnalisée à une extension WCF particulière.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""MyBehavior"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

L’utilisation de noms complets (forts) identifie de manière unique un type et renforce considérablement la sécurité de votre système. Utilisez des noms d’assembly complets lors de l’inscription des types dans les fichiers machine.config et app.config.

Exemple

L’élément <behaviorExtensions/> du fichier de configuration WCF ci-dessous indique à WCF d’ajouter une classe de comportements personnalisée référencée de manière forte à une extension WCF particulière.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
            Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

WCF - Implémenter le contrôle de l’autorisation

Intitulé	Détails
Composant	WCF
Phase SDL	Build
Technologies applicables	Générique, NET Framework 3
Attributs	N/A
Informations de référence	MSDN, Fortify Kingdom
Étapes	Ce service n’utilise pas un contrôle d’autorisation. Lorsqu’un client appelle un service WCF particulier, WCF fournit divers schémas d’autorisation qui vérifient que l’appelant est autorisé à exécuter la méthode de service sur le serveur. Si les contrôles d’autorisation ne sont pas activés pour les services WCF, un utilisateur authentifié peut obtenir une élévation des privilèges.

Exemple

La configuration suivante indique à WCF de ne pas vérifier le niveau d’autorisation du client lors de l’exécution du service :

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""None"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Utilisez un schéma d’autorisation de service pour vérifier que l’appelant de la méthode de service est autorisé à le faire. WCF propose deux modes et permet de définir un schéma d’autorisation personnalisé. Le mode UseWindowsGroups utilise des rôles et utilisateurs Windows, et le mode UseAspNetRoles utilise un fournisseur de rôle ASP.NET, tel que SQL Server, pour l’authentification.

Exemple

La configuration suivante indique à WCF de vérifier que le client fait partie du groupe Administrateurs avant d’exécuter le service Ajouter :

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""UseWindowsGroups"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

Le service est ensuite déclaré comme suit :

[PrincipalPermission(SecurityAction.Demand,
Role = ""Builtin\\Administrators"")]
public double Add(double n1, double n2)
{
double result = n1 + n2;
return result;
}

Implémenter le mécanisme d’autorisation approprié dans l’API web ASP.NET

Intitulé	Détails
Composant	API Web
Phase SDL	Build
Technologies applicables	Générique, MVC5
Attributs	N/A, Fournisseur d’identité - ADFS, Fournisseur d’identité - Microsoft Entra ID
Informations de référence	Authentification et autorisation dans l’API Web ASP.NET
Étapes	Des informations de rôle pour les utilisateurs d’applications peuvent être dérivées de Microsoft Entra ID ou de revendications ADFS si l’application s’appuie sur ces derniers en tant que fournisseur d’identité ou que l’application elle-même peut lui fournir. Dans tous les cas, l’implémentation d’une autorisation personnalisée doit valider les informations de rôle utilisateur. Des informations de rôle pour les utilisateurs d’applications peuvent être dérivées de Microsoft Entra ID ou de revendications ADFS si l’application s’appuie sur ces derniers en tant que fournisseur d’identité ou que l’application elle-même peut lui fournir. Dans tous les cas, l’implémentation d’une autorisation personnalisée doit valider les informations de rôle utilisateur.

Exemple

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class ApiAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
        public async override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
        {
            if (actionContext == null)
            {
                throw new Exception();
            }

            if (!string.IsNullOrEmpty(base.Roles))
            {
                bool isAuthorized = ValidateRoles(actionContext);
                if (!isAuthorized)
                {
                    HandleUnauthorizedRequest(actionContext);
                }
            }

            base.OnAuthorization(actionContext);
        }

public bool ValidateRoles(actionContext)
{
   //Authorization logic here; returns true or false
}

}

Tous les contrôleurs et toutes les méthodes d’action qui doivent être protégés doivent inclure l’attribut ci-dessus.

[ApiAuthorize]
public class CustomController : ApiController
{
     //Application code goes here
}

Effectuer des vérifications d’autorisation dans l’appareil s’il prend en charge diverses actions nécessitant différents niveaux d’autorisation

Intitulé	Détails
Composant	Appareil IoT
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	L’appareil doit autoriser l’appelant afin de vérifier si l’appelant dispose des autorisations nécessaires pour exécuter l’action demandée. Par exemple, supposons que l’appareil est un verrouillage de porte intelligent qui peut être surveillé à partir du cloud ; il fournit en outre des fonctionnalités telles que le verrouillage à distance de la porte. Le verrouillage de porte intelligent fournit des fonctionnalités de déverrouillage uniquement lorsqu’une personne se rapproche physiquement de la porte avec une carte. Dans ce cas, l’implémentation de la commande à distance et du contrôle doit être effectuée de manière à ce que toutes les fonctionnalités pour déverrouiller la porte ne soient pas fournies étant donné que la passerelle de cloud n’est pas autorisée à envoyer une commande de déverrouillage de la porte.

Effectuer des vérifications d’autorisation dans la passerelle de champ si elle prend en charge diverses actions nécessitant différents niveaux d’autorisation

Intitulé	Détails
Composant	Passerelle de champ IoT
Phase SDL	Build
Technologies applicables	Générique
Attributs	N/A
Informations de référence	N/A
Étapes	La passerelle de champ doit autoriser l’appelant afin de vérifier si l’appelant dispose des autorisations nécessaires pour exécuter l’action demandée. Par exemple, les autorisations pour une interface/API d’utilisateur administrateur doivent être différentes de celles utilisées pour configurer une passerelle de champ par rapport aux appareils qui s’y connectent.