Comment restreindre l'accès selon le principe du moindre privilège ?
l'équipe heygrc
Accordez uniquement les accès nécessaires à chaque rôle ou service, refusez par défaut et évitez les autorisations génériques. SOC 2 (CC6.1) vérifie l'accès logique, et le principe du moindre privilège est ce qu'un auditeur échantillonne : chaque identité peut-elle faire uniquement ce que son rôle exige, et rien de plus ?
Limiter les autorisations à la tâche
Attribuez à un rôle ou à un jeton les autorisations spécifiques dont il a besoin (les actions exactes sur les ressources exactes), et non une autorisation générique qui les inclut par hasard. L'autorisation générique est pratique maintenant, mais elle devient un problème lors de l'audit.
Refuser par défaut
Commencez par aucun accès et ajoutez uniquement ce qui est nécessaire, afin qu'une lacune se ferme automatiquement. Une politique par défaut autorisant avec des exceptions a tendance à accorder des accès non intentionnels.
Vérifier l'accès lorsqu'il s'élargit
Lorsqu'un changement élargit une autorisation, c'est le moment de la vérifier par rapport au principe du moindre privilège, ce qui est précisément l'objectif d'une revue sur le diff.
statement {- actions = ["s3:*"]+ actions = ["s3:GetObject", "s3:PutObject"]}L'autorisation est restreinte de toutes les actions S3 aux deux actions effectivement utilisées par le service.