Principe du moindre privilège, appliqué dans le diff.
CC6.1 est l'un des critères des Trust Services Criteria qu'une pull request ordinaire peut affaiblir discrètement, car il concerne l'accès logique, et l'accès logique réside souvent dans le code et la configuration. Ce critère exige que l'accès à vos systèmes et données soit limité aux utilisateurs et processus autorisés à y accéder. En pratique, cela signifie le principe du moindre privilège : un rôle peut accéder uniquement à ce dont il a besoin pour son travail, et rien de plus.
The shapes the same control failure takes.
CC6.1 ne se brise pas avec une ligne qui dit 'accorder l'admin à tout le monde'. Il se brise avec des modifications ordinaires et raisonnables. Voici les formes qui reviennent souvent.
Une politique d'accès s'élargit
Un rôle IAM, un groupe de sécurité ou une autorisation obtient des actions plus larges ou un joker, de sorte qu'un composant peut désormais faire plus que ce que son rôle nécessite.
Une vérification d'autorisation est supprimée
Une route perd sa vérification de rôle ou de propriété, ou un middleware d'autorisation cesse d'être appliqué à un nouvel endpoint, de sorte qu'une requête qui devrait être rejetée aboutit désormais.
Une autorisation de données s'élargit
Un rôle de base de données obtient l'accès à des tables ou des lignesqu'il n'avait pas, la sécurité au niveau des lignes est assouplie, ou un compte de service est pointé vers une base de données qu'il n'avait aucune raison d'atteindre.
Un paramètre par défaut passe à autoriser
L'accès passe de 'refus par défaut' à 'autorisation par défaut' : une nouvelle ressource est livrée en lecture mondiale, ou une vérification de permission prend la valeur 'vrai' par défaut pour un cas inconnu.
Un chemin d'élévation de privilèges s'ouvre
Un acteur à faible privilège obtient un moyen d'agir comme un acteur à privilège plus élevé : un indicateur interne qui contourne la vérification de rôle, ou un jeton émis avec une portée supérieure à celle détenue par l'appelant.
Un refactoring qui supprime une vérification d'autorisation.
Une route est en cours de nettoyage. La vérification de rôle au milieu semble redondante à côté du middleware d'authentification, elle est donc supprimée. L'endpoint nécessite toujours un utilisateur connecté, mais il ne nécessite plus le bon : désormais, n'importe quel utilisateur authentifié peut supprimer n'importe quel projet.
- router.delete("/projects/:id", requireRole("admin"),- loadProject, deleteProject)+ router.delete("/projects/:id", loadProject, deleteProject)Cela supprime la vérification de rôle d'un endpoint destructeur. Le middleware d'authentification confirme que l'appelant est connecté, mais CC6.1 concerne le fait de savoir s'il est autorisé pour cette action, et supprimer n'importe quel projet n'est pas quelque chose que chaque utilisateur devrait pouvoir faire. Restaurez la vérification d'autorisation (une vérification de rôle ou de propriété sur le projet) avant le gestionnaire.
CC6.1 est échantillonné, pas seulement déclaré.
Dans un audit SOC 2, CC6.1 n'est pas satisfait par un document de politique indiquant que vous appliquez le principe du moindre privilège. L'auditeur échantillonne l'accès réel : qui et quoi peut accéder à un système donné, si ces autorisations correspondent aux rôles documentés, et si quelque chose est plus large que son objectif. Un rôle générique, un endpoint manquant de vérification d'autorisation ou un compte de service avec un accès permanent qu'il n'utilise jamais est exactement le type d'exception qui devient une observation, et il est généralement entré dans le système via une seule pull request des mois plus tôt. Détecter le changement dans le diff aide à éviter que ces exceptions d'accès ne fassent partie de l'échantillon.
Une revue, pas une attestation.
heygrc signale les modifications qui concernent CC6.1 et cite le critère afin que la correction ait lieu dans la pull request. Il n'exécute pas votre audit ni ne formule d'avis. Il détecte le changement d'accès tôt pour que l'audit ait moins d'exceptions à expliquer.