J'ai cette politique de godet et cela fonctionne correctement. Le seul problème est que cela ne permet pas à Athena Requête. Comment puis-je modifier cela à tous ATHENA?
{
"Version": "2008-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:*",
"Resource": "arn:aws:s3:::13cols/*",
"Condition": {
"NotIpAddress": {
"aws:SourceIp": [
"18.72.1.2/32",
"11.119.2.8/32",
"12.939.49.346/32",
"4.26.2.219/32"
]
}
}
}
]
}
3 Réponses :
Vous avez une stratégie de godet, qui est scopée au seau et s'applique à tout utilisateur ou rôle qui essaie de faire des opérations sur ce seau. Le lien que vous vous référez concerne concerne les stratégies utilisateur et rôle, qui s'appliquent uniquement à des utilisateurs spécifiques. Lorsqu'un utilisateur ou un rôle rend les opérations sur un seau, la combinaison de leurs politiques et de la politique du seau est ce qui régit ce qu'ils sont autorisés à faire.
La combinaison de l'utilisateur ou de la politique de rôle avec la politique de godet n'est pas une union, mais plus comme une intersection. Ce que j'entends par là, c'est que si l'utilisateur ou la politique de rôle n'accorde pas dites Vous dites que votre politique fonctionne, mais n'autorise pas les requêtes d'Athéna. Cela est vrai, puisque c'est une politique de seau, il n'accorde aucun utilisateur ni rôle, cela spécifie simplement ce qu'un utilisateur ou quel rôle serait autorisé à faire, s'ils n'étaient autrement autorisés à accéder au seau. De plus, votre politique nie simplement les choses. Déni explicitement ne signifie pas permettre de laisser tout le reste, cela signifie simplement que même si quelque chose d'autre permet aux choses mentionnées dans votre police, votre politique sera annulée (dans ce cas: même si une stratégie d'utilisateur ou de rôle autorisée L'utilisateur ou le rôle que vous utilisez pour exécuter la requête Athena doit avoir la permission à
Les stratégies gérées que vous liez pour aideront avec 1-3, mais vous devez écrire 4. Lorsqu'une requête est exécutée, IAM évaluera 1-4 plus la stratégie de godet, de voir si l'utilisateur ou le rôle est autorisé à exécuter. la requête. S3: getObject , peu importe que la politique du seau accorde à cette action. L'utilisateur ou la politique de rôle et la politique du seau doit l'accorder. En fait, il est encore plus compliqué lorsque vous prenez en compte les directeurs - mais votre politique de godet s'applique à tout le monde, ce n'est donc pas le cas ici.
S3: GetObject < / Code> Votre politique refuserait cette action si l'IP source correspondait à l'une des mentionnées - qui est votre intention, je présume).
c'est correct. Votre stratégie de godet indique: Si la demande entrante ne provient pas de l'une de ces adresses IP, ne laissez personne faire quelque chose à ce seau S3.
Donc, même si une requête d'Athena est dirigée par quelqu'un qui est autorisé à accéder au seau, la politique ci-dessus les bloque car Athena n'arrive pas à l'une de ces adresses IP.
Pour éviter cela, vous devriez trouver toutes les politiques accordant aux gens l'accès et mettez la restriction de l'adresse IP sur ces politiques , de sorte qu'ils disent "permettent à ces personnes d'accéder au seau mais seulement S'ils venaient de l'une de ces adresses IP ". de cette façon, il s'agit d'une stratégie de purement , plutôt que ALORS, autoriser et nier < / code>.
Autoriser Accès à la godet à l'utilisateur qui exécute les requêtes Athena, mais ne les limite pas par adresse IP (car les demandes d'Athéna ne proviendront pas de votre plage d'adresses IP).
Je ne pense pas que cela soit correct. Que vous autorisiez l'IPS sur un niveau d'utilisateur / rôle, ou de les refuser sur un niveau de seau, le résultat final devrait être identique, l'opération doit avoir le même contexte d'évaluation, n'est-ce pas? Pourquoi AWS: SecteurIP Évaluez-vous à une valeur différente juste parce que la règle qu'elle est assortie est dans une politique de seau?
La question est que les politiques ci-dessus nient toutes les demandes en dehors des adresses IP données. Malheureusement, les requêtes d'Athena sont en dehors de ces adresses IP. Donc, la voie à suivre est pas d'utiliser une politique de refus, mais de limiter à la place les autorisations accordées via les politiques autorisées qui accordaient un accès en premier lieu.
Athéna ne prend pas en charge la restriction ou permettant l'accès à Amazon S3 Ressources basées sur la clé de condition AWS: source de source.
PAR AWS ATHENA Documentation ici: https://docs.aws.amazon.com/ATHENA/ DERNIÈRES / UG / S3-PERMISSIONS.HTML