Autorisation
Rendez chaque décision d'accès affectée explicite, appliquez-la à la véritable frontière et prouvez le comportement à la fois autorisé et refusé. Travaillez dans le cadre du flux demandé ; le chargement de cette compétence ne déclenche pas un audit de l'ensemble de l'application. Utilisez l'identité, la politique et les propriétaires de domaine existants avant d'introduire un nouveau framework.
Définir la politique
Lisez les décisions produit acceptées et les appelants réels. Enregistrez une petite matrice de politique pour le flux modifié : principal, opération, ressource, relation/périmètre/état applicable, champs d'entrée/sortie autorisés et résultat. Utilisez les rôles, attributs, propriété ou capacités selon le besoin réel ; un rôle seul peut ne pas établir l'accès à un enregistrement particulier. Préservez des autorisations de lecture, écriture, exportation, partage et administration intentionnellement différentes.
Séparez l'authentification de l'identité de la permission d'agir. Obtenez l'identité et les droits d'accès à partir d'un contexte de session, jeton ou service de confiance. Les identifiants de demande, les sélecteurs de locataire, les champs de rôle et l'état de l'interface utilisateur sélectionnent ou décrivent une demande ; ils ne confèrent pas d'autorité. L'accès anonyme/public peut être explicitement autorisé ou limité par des capacités. Une identité ou un périmètre manquant ne doit pas devenir silencieusement une autorisation globale/système. Gardez les opérateurs privilégiés et l'usurpation d'identité explicites et attribuables.
Par défaut, refusez tout accès non correspondant et utilisez la moindre autorité qui satisfait la politique acceptée. Une permission métier indécise est une question produit, pas une invitation à inventer une valeur par défaut permissive. Continuez le travail indépendant pendant que ce choix reste non résolu. Gardez une démo délibérément locale et non partagée distincte d'un service exposant de vraies données protégées.
Trouver chaque chemin d'accès affecté
Suivez la ressource affectée à travers ses véritables points d'entrée et propriétaires. Incluez les API web/mobiles pertinentes, les chargeurs rendus par le serveur, les actions, les imports, les opérations par lots, les jobs et les intégrations. Inspectez la recherche/le comptage/l'exportation, les fichiers, les caches et les abonnements lorsqu'ils exposent les mêmes faits protégés. Lisez Surfaces d'accès pour ces chemins ou pour les capacités, la délégation et la révocation ; sélectionnez les sections applicables.
Nommez le propriétaire de la politique et les points d'application. Centralisez la signification de la règle tout en l'appliquant partout où les données ou les effets traversent les frontières de confiance. Une simple vérification de connexion middleware, un garde d'interface utilisateur, un UUID ou une lecture réussie antérieure ne suffisent pas. Une politique de framework, une politique de base de données ou un propriétaire limité peuvent fonctionner ; vérifiez sa configuration réelle et ses identifiants d'exécution au lieu de supposer qu'elle couvre les voies de contournement.
Appliquer la décision
Pour les lectures, restreignez la population de ressources autorisées avant que les résultats ne quittent la frontière de confiance et restreignez les champs retournés. Appliquez une politique équivalente aux objets connexes et aux représentations alternatives. Utilisez la politique de divulgation du produit pour les ressources manquantes ou interdites ; les erreurs, les comptages et les propriétés sérialisées peuvent aussi révéler des faits protégés.
Pour les mutations, validez l'action, la cible et les relations résultantes, y compris les clés étrangères fournies par l'utilisateur et les champs protégés. Utilisez les champs d'entrée autorisés plutôt que de lier une requête entière à une entité durable. Lorsqu'un entrelacement accessible peut invalider l'autorité, appliquez le périmètre, l'appartenance ou l'état à l'effet en utilisant la garde atomique ou la sérialisation appropriée du magasin. Les enfants couplés et les effets secondaires suivent la même admission. Conservez un propriétaire complet existant ; n'ajoutez pas un autre rédacteur métier uniquement pour insérer des vérifications d'autorisation.
Définissez quand les droits sont évalués et quand un changement prend effet. L'accès actuel, l'attribution historique immuable et une obligation durable précédemment acceptée sont des contrats différents. Les rejeux, les livraisons différées et les jobs délégués nécessitent une autorité/durée de vie explicite ; ni les droits d'utilisateur obsolètes ni une identité système générique ne répondent à cette question. Appliquez la révocation et la récupération selon ce contrat sans annuler silencieusement des obligations valides ni élargir leur public.
Prouver la limite
Dérivez un petit ensemble de tests discriminants à partir de la matrice de politique. Via le véritable propriétaire et la limite montée pertinente, montrez un acteur valide effectuant l'opération et des refus significatifs : un autre propriétaire dans le même locataire, un autre locataire, un rôle plus faible, une capacité anonyme/malformée ou un droit modifié le cas échéant. Utilisez des enregistrements cibles réels et des leurres explicites ; affirmez les champs protégés, les effets durables inchangés et les enregistrements non liés. Sélectionnez les cas pertinents plutôt que de répéter chaque combinaison théorique.
Une politique simulée retournant vrai ou faux ne prouve ni sa décision ni la restriction de requête/écriture. Testez des prédicats réels ou des politiques de magasin avec une autorité d'exécution réaliste. Pour les revendications d'accès à l'interface utilisateur, vérifiez une demande directe indépendamment de la visibilité du bouton. Ne sondez pas les identités d'autres personnes ni les données partagées/en direct ; utilisez des fixtures autorisées isolées. Séparez les constatations statiques, les vérifications proposées, les tests exécutés et les lacunes de la politique de déploiement.
Fournissez la politique, les sources faisant autorité, les chemins affectés, l'application et la preuve, ainsi que les choix produit non résolus ou la configuration externe. Une vérification réussie est limitée à ces chemins ; la procédure ne certifie pas la sécurité globale de l'application.