Quand je regarde un "contexte de demande" dans Cloudrail, je vois des matières d'enregistrement énumérées ici .
existe-t-il un mappage entre le contenu de l'enregistrement "contexte de la requête" et les touches de la condition? Lorsque j'utilise une clé de condition dans une stratégie, comment puis-je être sûr que la clé de condition est présente dans le contexte de la demande? J'ai posté une question différente mais connexe ici aussi.
Ou est-il correct de dire qu'il n'est pas obligatoire pour une condition d'être présent dans le «contexte de la demande», mais une clé de condition correspondant à la condition peut encore être disponible (AWS Magic) à utiliser dans une politique pour évaluer cette demande? Sont des clés aws à large qui utilisent le préfixe AWS: disponible dans tous les contextes de demande?
Bien sûr, je peux ajouter une clause "ifexists" pour vérifier la disponibilité d'une clé de condition, mais qui est un mécanisme "attraper tout". Comment puis-je être certain que je n'ai pas besoin d'utiliser la clause "ifexists" lors de la vérification d'une condition dans une stratégie?
3 Réponses :
Je pense que vous confondez le contenu des données d'événement de journal CT:
avec clés de condition iam pour le cloudtrial:
Aussi pour vérifier si la clé de stratégie existe à l'aide de ... Ifexists ou chèque null .
Si la clé que vous spécifiez dans une condition de stratégie n'est pas présente dans le contexte de la demande, les valeurs ne correspondent pas.
La première contient des informations sur les appels API dans votre essai CT, tandis que la seconde est utilisée dans les stratégies IAM pour accorder des autorisations conditionnelles.
Merci @marcin, vous voulez donc dire que le mécanisme d'évaluation des politiques dans AWS n'a rien à voir avec ce qui est connecté comme un contexte de demande dans CloudTrail - Droite? Le «contexte de demande» complet n'est probablement pas connecté au cloudtrail et que seul un sous-ensemble du «contexte de la demande» complet est enregistré?
@Abhishekpalakkkalkaliyath n'est pas sûr de ce que vous voulez dire. Par exemple, lorsque des journaux CT ERRORMESSAGE , Voulez-vous utiliser ERRORMESSAGE comme clé de la condition dans la stratégie IAM? Malheureusement, je ne sais pas quels champs enregistrés par CT peuvent être utilisés dans les politiques IAM, le cas échéant.
Ok @marcin - je vais expliquer. Si je devais utiliser "AWS: SourceVPC" comme clé de la condition, où est AWS à la recherche de ces informations lors de l'évaluation des autorisations pour une demande - Je pensais que AWS a été examinée dans le "contexte de la demande" qui est également connecté en tant qu'événement dans CloudTrail. Cependant, lorsque je consulte l'événement Cloudrail, je ne pouvais pas voir des informations sur la source VPC enregistrée dans l'événement spécifique. Alors, ne sont-ils jamais visibles pour nous ou enregistrés nulle part?
@Abhishekpalakkkalkaliyath Tu veux dire SessionContext dans ct? Ceci est uniquement pour les crédentifions temporaires (lorsque vous assumez un rôle avec STS). Je ne pense pas que le contexte de la demande d'actualité que IAM utilise pour évaluer les autorisations est dans les journaux CT.
Merci @ Marcin - Je ne pense pas que le contexte de la demande réelle que IAM utilise pour évaluer les autorisations est dans les journaux CT. -Yah, c'est ce que j'étais après. Non, je n'étais pas après sessionContext dans ct. Je pense que je suis confondre entre les détails dans les événements de Cloudrail et demander le contexte de la même manière. Comme vous l'avez dit, nous ne pouvons jamais voir tous les détails d'un contexte de demande AWS - un sous-ensemble de celui-ci est présent dans l'événement CloudTrail. Inversement, un événement Cloudrail enregistre certains éléments du contexte de la demande réel mais pas tous les éléments.
@Abhishekpalakkkalkaliyath Je suis d'accord. Cela semble être le cas.
Merci @marcin;
@Abhishekpalakkkalkaliyath Aucun problème. Si ma réponse était utile, son acceptation serait appréciée.
Fait, j'ai également ajouté une réponse séparée pour plus de clarté.
L'événement Cloudrail n'a qu'un sous-ensemble d'informations à partir du contexte de la demande. Nous n'arrivons jamais à voir l'ensemble (Détails d'un) Demande aws Contexte - Un sous-ensemble de celui-ci est consigné comme Contenu de l'enregistrement dans l'événement CloudTrail.
L'événement Cloudrail et le contexte de la demande sont 2 choses différentes. Vous pouvez afficher des informations sur le contexte de la demande comme Contenu de l'enregistrement dans l'événement CloudTrail (Seulement AWS voit tout le contexte de la demande et vérifie la tâche contre les autorisations octroyées via des stratégies pour autoriser / nier la demande).