Autorise l'accès aux attributs d'une entité (ABAC)

Le contrôle d’accès par attributs (ABAC) est une stratégie d’autorisation qui définit des autorisations en fonction des attributs. Les autorisations vérifiées permettent d'associer des attributs aux principes, aux actions et aux ressources. Ces attributs peuvent ensuite être référencés dans les unless clauses when et des politiques qui évaluent les attributs des principes, des actions et des ressources qui constituent le contexte de la demande.

Les exemples suivants utilisent les attributs définis dans l'application hypothétique appelée PhotoFlash décrite dans la section Exemple de schéma du Guide de référence du langage de politique Cedar.

Cet exemple montre comment créer une politique permettant à tout directeur HardwareEngineering du département dont le niveau de poste est supérieur ou égal à 5 de consulter et de répertorier les photos de l'albumdevice_prototypes.

permit(
  principal,
  action in [Action::"listPhotos", Action::"view"],
  resource in Album::"device_prototypes"
)
when {
  principal.department == "HardwareEngineering" &&
  principal.jobLevel >= 5
};

Cet exemple montre comment créer une politique permettant à l'utilisateur de alice visualiser n'importe quelle ressource de type fichierJPEG.

permit(
  principal == User::"alice",
  action == Action::"view",
  resource
)
when {
  resource.fileType == "JPEG"
};

Les actions possèdent des attributs contextuels. Vous devez transmettre ces attributs dans le cadre context d'une demande d'autorisation. Cet exemple montre comment créer une politique permettant à l'utilisateur d'aliceeffectuer n'importe quelle readOnly action. Vous pouvez également définir une appliesTo propriété pour les actions de votre schéma. Cela spécifie des actions valides pour une ressource lorsque vous voulez vous assurer que, par exemple, les utilisateurs ne peuvent tenter ViewPhoto d'autoriser qu'une ressource de typePhotoFlash::Photo.

permit(
  principal == PhotoFlash::User::"alice",
  action,
  resource
) when { 
    context has readOnly && 
    context.readOnly == true 
};

Une meilleure façon de définir les propriétés des actions dans votre schéma consiste toutefois à les organiser en groupes d'actions fonctionnels. Par exemple, vous pouvez créer une action nommée ReadOnlyPhotoAccess et définie PhotoFlash::Action::"ViewPhoto" pour être membre ReadOnlyPhotoAccess en tant que groupe d'actions. Cet exemple montre comment créer une politique qui accorde à Alice l'accès aux actions en lecture seule de ce groupe.

permit(
  principal == PhotoFlash::User::"alice",
  action,
  resource
) when {
    action in PhotoFlash::Action::"ReadOnlyPhotoAccess"
};

Cet exemple montre comment vous pouvez créer une politique qui autorise tous les principaux à effectuer n'importe quelle action sur les ressources pour lesquelles ils ont un owner attribut.

permit(
  principal,
  action,
  resource
)
when {
  principal == resource.owner
};

Cet exemple montre comment créer une politique permettant à n'importe quel principal de consulter n'importe quelle ressource si l'departmentattribut du principal correspond à l'departmentattribut de la ressource.

Note

Si aucun attribut d'une entité n'est mentionné dans une condition de stratégie, la politique sera ignorée lors de la prise d'une décision d'autorisation et l'évaluation de cette politique échouera pour cette entité. Par exemple, aucun principal qui n'a pas d'departmentattribut ne peut accéder à aucune ressource en vertu de cette politique.

permit(
  principal,
  action == Action::"view",
  resource
)
when {
  principal.department == resource.owner.department
};

Cet exemple montre comment créer une politique permettant à n'importe quel principal d'effectuer n'importe quelle action sur une ressource si le principal est le responsable owner de la ressource OU si le principal fait partie du admins groupe de la ressource.

permit(
  principal,
  action,
  resource,
)
when {
  principal == resource.owner ||
  resource.admins.contains(principal)
};