Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA

src/pentesting-cloud/aws-security/aws-basic-information/README.md

@@ -12,7 +12,7 @@ Dans AWS, il y a un **compte root**, qui est le **conteneur parent pour tous les
 
 C'est très intéressant d'un point de vue **sécurité**, car **un compte ne pourra pas accéder aux ressources d'un autre compte** (sauf si des ponts sont spécifiquement créés), de cette manière vous pouvez créer des limites entre les déploiements.
 
-Par conséquent, il y a **deux types de comptes dans une organisation** (nous parlons de comptes AWS et non de comptes utilisateurs) : un seul compte désigné comme le compte de gestion, et un ou plusieurs comptes membres.
+Par conséquent, il y a **deux types de comptes dans une organisation** (nous parlons de comptes AWS et non de comptes utilisateurs) : un seul compte désigné comme compte de gestion, et un ou plusieurs comptes membres.
 
 - Le **compte de gestion (le compte root)** est le compte que vous utilisez pour créer l'organisation. À partir du compte de gestion de l'organisation, vous pouvez faire ce qui suit :
 
@@ -40,7 +40,7 @@ aws organizations create-organizational-unit --parent-id r-lalala --name TestOU
 ```
 ### Service Control Policy (SCP)
 
-Une **service control policy (SCP)** est une politique qui spécifie les services et actions que les utilisateurs et rôles peuvent utiliser dans les comptes que la SCP affecte. Les SCP sont **similaires aux politiques de permissions IAM** sauf qu'elles **ne grantissent aucune permission**. Au lieu de cela, les SCP spécifient les **permissions maximales** pour une organisation, une unité organisationnelle (OU) ou un compte. Lorsque vous attachez une SCP à la racine de votre organisation ou à une OU, la **SCP limite les permissions pour les entités dans les comptes membres**.
+Une **service control policy (SCP)** est une politique qui spécifie les services et actions que les utilisateurs et rôles peuvent utiliser dans les comptes que la SCP affecte. Les SCP sont **similaires aux politiques de permissions IAM** sauf qu'elles **ne donnent aucune permission**. Au lieu de cela, les SCP spécifient les **permissions maximales** pour une organisation, une unité organisationnelle (OU) ou un compte. Lorsque vous attachez une SCP à la racine de votre organisation ou à une OU, la **SCP limite les permissions pour les entités dans les comptes membres**.
 
 C'est le SEUL moyen par lequel **même l'utilisateur root peut être arrêté** de faire quelque chose. Par exemple, cela pourrait être utilisé pour empêcher les utilisateurs de désactiver CloudTrail ou de supprimer des sauvegardes.\
 Le seul moyen de contourner cela est de compromettre également le **compte maître** qui configure les SCP (le compte maître ne peut pas être bloqué).
@@ -53,20 +53,18 @@ Exemples de SCP :
 - Refuser complètement le compte root
 - Autoriser uniquement des régions spécifiques
 - Autoriser uniquement des services sur liste blanche
-- Refuser la désactivation de GuardDuty, CloudTrail et S3 Public Block Access
-
-- Refuser la suppression ou la modification des rôles de sécurité/réponse aux incidents.
-
-- Refuser la suppression des sauvegardes.
+- Refuser que GuardDuty, CloudTrail et S3 Public Block Access soient désactivés
+- Refuser que les rôles de sécurité/réponse aux incidents soient supprimés ou modifiés.
+- Refuser que les sauvegardes soient supprimées.
 - Refuser la création d'utilisateurs IAM et de clés d'accès
 
 Trouvez des **exemples JSON** dans [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples.html)
 
 ### Resource Control Policy (RCP)
 
-Une **resource control policy (RCP)** est une politique qui définit les **permissions maximales pour les ressources au sein de votre organisation AWS**. Les RCP sont similaires aux politiques IAM en syntaxe mais **ne grantissent pas de permissions**—elles limitent seulement les permissions qui peuvent être appliquées aux ressources par d'autres politiques. Lorsque vous attachez une RCP à la racine de votre organisation, à une unité organisationnelle (OU) ou à un compte, la RCP limite les permissions des ressources sur toutes les ressources dans le champ d'application affecté.
+Une **resource control policy (RCP)** est une politique qui définit les **permissions maximales pour les ressources au sein de votre organisation AWS**. Les RCP sont similaires aux politiques IAM en syntaxe mais **ne donnent pas de permissions**—elles ne font que plafonner les permissions qui peuvent être appliquées aux ressources par d'autres politiques. Lorsque vous attachez une RCP à la racine de votre organisation, à une unité organisationnelle (OU) ou à un compte, la RCP limite les permissions des ressources sur toutes les ressources dans le champ d'application affecté.
 
-C'est le SEUL moyen de garantir que **les ressources ne peuvent pas dépasser les niveaux d'accès prédéfinis**—même si une politique basée sur l'identité ou sur la ressource est trop permissive. Le seul moyen de contourner ces limites est de modifier également la RCP configurée par le compte de gestion de votre organisation.
+C'est le SEUL moyen de s'assurer que **les ressources ne peuvent pas dépasser des niveaux d'accès prédéfinis**—même si une politique basée sur l'identité ou sur la ressource est trop permissive. Le seul moyen de contourner ces limites est de modifier également la RCP configurée par le compte de gestion de votre organisation.
 
 > [!WARNING]
 > Les RCP ne restreignent que les permissions que les ressources peuvent avoir. Elles ne contrôlent pas directement ce que les principaux peuvent faire. Par exemple, si une RCP refuse l'accès externe à un bucket S3, elle garantit que les permissions du bucket ne permettent jamais d'actions au-delà de la limite fixée—même si une politique basée sur la ressource est mal configurée.
@@ -75,7 +73,7 @@ Exemples de RCP :
 
 - Restreindre les buckets S3 afin qu'ils ne puissent être accessibles que par des principaux au sein de votre organisation
 - Limiter l'utilisation des clés KMS pour n'autoriser que les opérations des comptes organisationnels de confiance
-- Limiter les permissions sur les files d'attente SQS pour prévenir les modifications non autorisées
+- Plafonner les permissions sur les files d'attente SQS pour empêcher les modifications non autorisées
 - Faire respecter des limites d'accès sur les secrets de Secrets Manager pour protéger les données sensibles
 
 Trouvez des exemples dans [AWS Organizations Resource Control Policies documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)
@@ -118,7 +116,7 @@ Un _utilisateur_ IAM est une entité que vous créez dans AWS pour **représente
 
 Lorsque vous créez un utilisateur IAM, vous lui accordez des **permissions** en le rendant **membre d'un groupe d'utilisateurs** qui a des politiques de permission appropriées attachées (recommandé), ou en **attachant directement des politiques** à l'utilisateur.
 
-Les utilisateurs peuvent avoir **MFA activé pour se connecter** via la console. Les jetons API des utilisateurs avec MFA activé ne sont pas protégés par MFA. Si vous souhaitez **restreindre l'accès des clés API d'un utilisateur en utilisant MFA**, vous devez indiquer dans la politique qu'il est nécessaire que MFA soit présent pour effectuer certaines actions (exemple [**ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
+Les utilisateurs peuvent avoir **MFA activé pour se connecter** via la console. Les jetons API des utilisateurs avec MFA activé ne sont pas protégés par MFA. Si vous souhaitez **restreindre l'accès des clés API d'un utilisateur en utilisant MFA**, vous devez indiquer dans la politique qu'en vue d'effectuer certaines actions, MFA doit être présent (exemple [**ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)).
 
 #### CLI
 
@@ -140,7 +138,7 @@ Les politiques avec des conditions MFA peuvent être attachées aux éléments s
 - La politique de confiance d'un rôle IAM qui peut être assumé par un utilisateur
 
 Si vous souhaitez **accéder via CLI** à une ressource qui **vérifie MFA**, vous devez appeler **`GetSessionToken`**. Cela vous donnera un jeton avec des informations sur MFA.\
-Notez que les **informations d'identification `AssumeRole` ne contiennent pas cette information**.
+Notez que **les informations d'identification `AssumeRole` ne contiennent pas cette information**.
 ```bash
 aws sts get-session-token --serial-number <arn_device> --token-code <code>
 ```
@@ -156,8 +154,8 @@ Voici quelques caractéristiques importantes des groupes d'utilisateurs :
 
 - Un **groupe d'utilisateurs** peut **contenir plusieurs utilisateurs**, et un **utilisateur** peut **appartenir à plusieurs groupes**.
 - **Les groupes d'utilisateurs ne peuvent pas être imbriqués** ; ils ne peuvent contenir que des utilisateurs, pas d'autres groupes d'utilisateurs.
-- Il n'y a **pas de groupe d'utilisateurs par défaut qui inclut automatiquement tous les utilisateurs du compte AWS**. Si vous souhaitez avoir un groupe d'utilisateurs comme ça, vous devez le créer et assigner chaque nouvel utilisateur à celui-ci.
-- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes, et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [les quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
+- Il n'y a **pas de groupe d'utilisateurs par défaut qui inclut automatiquement tous les utilisateurs du compte AWS**. Si vous souhaitez avoir un groupe d'utilisateurs comme cela, vous devez le créer et assigner chaque nouvel utilisateur à celui-ci.
+- Le nombre et la taille des ressources IAM dans un compte AWS, comme le nombre de groupes et le nombre de groupes dont un utilisateur peut être membre, sont limités. Pour plus d'informations, voir [les quotas IAM et AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html).
 
 ### [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
 
@@ -171,16 +169,16 @@ Le Service de jetons de sécurité AWS (STS) est un service web qui facilite **l
 
 ### [Credentials temporaires dans IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) <a href="#id_temp-creds" id="id_temp-creds"></a>
 
-Les **credentials temporaires sont principalement utilisés avec des rôles IAM**, mais il existe également d'autres utilisations. Vous pouvez demander des credentials temporaires qui ont un ensemble d'autorisations plus restreint que votre utilisateur IAM standard. Cela **empêche** que vous **effectuiez accidentellement des tâches qui ne sont pas autorisées** par les credentials plus restreints. Un avantage des credentials temporaires est qu'ils expirent automatiquement après une période déterminée. Vous avez le contrôle sur la durée pendant laquelle les credentials sont valides.
+Les **credentials temporaires sont principalement utilisés avec des rôles IAM**, mais il existe également d'autres utilisations. Vous pouvez demander des credentials temporaires qui ont un ensemble de permissions plus restreint que votre utilisateur IAM standard. Cela **empêche** que vous **effectuiez accidentellement des tâches qui ne sont pas autorisées** par les credentials plus restreints. Un avantage des credentials temporaires est qu'ils expirent automatiquement après une période déterminée. Vous avez le contrôle sur la durée pendant laquelle les credentials sont valides.
 
 ### Politiques
 
 #### Permissions de politique
 
-Sont utilisées pour attribuer des autorisations. Il existe 2 types :
+Sont utilisées pour attribuer des permissions. Il existe 2 types :
 
 - Politiques gérées par AWS (préconfigurées par AWS)
-- Politiques gérées par le client : configurées par vous. Vous pouvez créer des politiques basées sur des politiques gérées par AWS (en modifiant l'une d'elles et en créant la vôtre), en utilisant le générateur de politiques (une vue GUI qui vous aide à accorder et refuser des autorisations) ou en écrivant la vôtre.
+- Politiques gérées par le client : configurées par vous. Vous pouvez créer des politiques basées sur des politiques gérées par AWS (en modifiant l'une d'elles et en créant la vôtre), en utilisant le générateur de politiques (une vue GUI qui vous aide à accorder et refuser des permissions) ou en écrivant la vôtre.
 
 Par **défaut, l'accès** est **refusé**, l'accès sera accordé si un rôle explicite a été spécifié.\
 Si **un "Deny" unique existe, il remplacera le "Allow"**, sauf pour les demandes qui utilisent les credentials de sécurité root du compte AWS (qui sont autorisées par défaut).
@@ -226,7 +224,7 @@ Les limites IAM peuvent être utilisées pour **limiter les autorisations auxque
 
 Une limite est simplement une politique attachée à un utilisateur qui **indique le niveau maximum d'autorisations que l'utilisateur ou le rôle peut avoir**. Donc, **même si l'utilisateur a un accès Administrateur**, si la limite indique qu'il ne peut lire que des buckets S·, c'est le maximum qu'il peut faire.
 
-**Cela**, **les SCP** et **le respect du principe du moindre privilège** sont les moyens de contrôler que les utilisateurs n'ont pas plus d'autorisations que celles dont ils ont besoin.
+**Cela**, **les SCPs** et **le respect du principe du moindre privilège** sont les moyens de contrôler que les utilisateurs n'ont pas plus d'autorisations que celles dont ils ont besoin.
 
 ### Politiques de Session
 
@@ -240,9 +238,9 @@ aws sts assume-role \
 [--policy-arns <arn_custom_policy1> <arn_custom_policy2>]
 [--policy <file://policy.json>]
 ```
-Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés de cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles), par défaut (en utilisant l'authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels cette session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
+Notez qu'en défaut, **AWS peut ajouter des politiques de session aux sessions** qui vont être générées pour d'autres raisons. Par exemple, dans [les rôles supposés cognito non authentifiés](../aws-services/aws-cognito-enum/cognito-identity-pools.md#accessing-iam-roles), par défaut (en utilisant l'authentification améliorée), AWS générera **des identifiants de session avec une politique de session** qui limite les services auxquels cette session peut accéder [**à la liste suivante**](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#access-policies-scope-down-services).
 
-Par conséquent, si à un moment donné vous rencontrez l'erreur "... parce qu'aucune politique de session ne permet le ...", et que le rôle a accès pour effectuer l'action, c'est parce que **il y a une politique de session qui l'empêche**.
+Par conséquent, si à un moment donné vous rencontrez l'erreur "... parce qu'aucune politique de session ne permet le ...", et que le rôle a accès pour effectuer l'action, c'est parce que **il y a une politique de session qui l'en empêche**.
 
 ### Fédération d'identité
 
@@ -251,7 +249,7 @@ Un exemple de fournisseur d'identité peut être votre propre **Microsoft Active
 
 Pour configurer cette confiance, un **fournisseur d'identité IAM est généré (SAML ou OAuth)** qui **fera confiance** à la **autre plateforme**. Ensuite, au moins un **rôle IAM est attribué (faisant confiance) au fournisseur d'identité**. Si un utilisateur de la plateforme de confiance accède à AWS, il le fera en accédant au rôle mentionné.
 
-Cependant, vous voudrez généralement donner un **rôle différent en fonction du groupe de l'utilisateur** dans la plateforme tierce. Ensuite, plusieurs **rôles IAM peuvent faire confiance** au fournisseur d'identité tiers et la plateforme tierce sera celle qui permettra aux utilisateurs d'assumer un rôle ou un autre.
+Cependant, vous voudrez généralement donner un **rôle différent en fonction du groupe de l'utilisateur** sur la plateforme tierce. Ensuite, plusieurs **rôles IAM peuvent faire confiance** au fournisseur d'identité tiers et la plateforme tierce sera celle qui permettra aux utilisateurs d'assumer un rôle ou un autre.
 
 <figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
 
@@ -261,7 +259,7 @@ AWS IAM Identity Center (successeur d'AWS Single Sign-On) étend les capacités
 
 Le domaine de connexion sera quelque chose comme `<user_input>.awsapps.com`.
 
-Pour connecter les utilisateurs, il y a 3 sources d'identité qui peuvent être utilisées :
+Pour connecter des utilisateurs, il y a 3 sources d'identité qui peuvent être utilisées :
 
 - Répertoire Identity Center : Utilisateurs AWS réguliers
 - Active Directory : Prend en charge différents connecteurs
@@ -275,7 +273,7 @@ Pour donner accès à un utilisateur/groupe du Centre d'identité à un compte,
 
 #### AwsSSOInlinePolicy
 
-Il est possible de **donner des permissions via des politiques en ligne aux rôles créés via IAM Identity Center**. Les rôles créés dans les comptes recevant **des politiques en ligne dans AWS Identity Center** auront ces permissions dans une politique en ligne appelée **`AwsSSOInlinePolicy`**.
+Il est possible de **donner des permissions via des politiques en ligne aux rôles créés via IAM Identity Center**. Les rôles créés dans les comptes étant donnés **politiques en ligne dans AWS Identity Center** auront ces permissions dans une politique en ligne appelée **`AwsSSOInlinePolicy`**.
 
 Par conséquent, même si vous voyez 2 rôles avec une politique en ligne appelée **`AwsSSOInlinePolicy`**, cela **ne signifie pas qu'ils ont les mêmes permissions**.
 
@@ -302,10 +300,10 @@ L'application utilise AssumeRoleWithWebIdentity pour créer des identifiants tem
 
 ### Autres options IAM
 
-- Vous pouvez **définir une politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe.
+- Vous pouvez **définir un paramètre de politique de mot de passe** avec des options comme la longueur minimale et les exigences de mot de passe.
 - Vous pouvez **télécharger un "Rapport d'identifiants"** avec des informations sur les identifiants actuels (comme le temps de création de l'utilisateur, si le mot de passe est activé...). Vous pouvez générer un rapport d'identifiants aussi souvent qu'une fois toutes les **quatre heures**.
 
-La gestion des identités et des accès AWS (IAM) fournit un **contrôle d'accès granulaire** sur l'ensemble d'AWS. Avec IAM, vous pouvez spécifier **qui peut accéder à quels services et ressources**, et sous quelles conditions. Avec les politiques IAM, vous gérez les permissions de votre main-d'œuvre et de vos systèmes pour **assurer des permissions de moindre privilège**.
+AWS Identity and Access Management (IAM) fournit un **contrôle d'accès granulaire** sur l'ensemble d'AWS. Avec IAM, vous pouvez spécifier **qui peut accéder à quels services et ressources**, et sous quelles conditions. Avec les politiques IAM, vous gérez les permissions de votre main-d'œuvre et de vos systèmes pour **assurer des permissions de moindre privilège**.
 
 ### Préfixes d'ID IAM
 
@@ -377,7 +375,7 @@ Si vous recherchez quelque chose de **similaire** à cela mais pour le **navigat
 
 #### Automatisation des identifiants temporaires
 
-Si vous exploitez une application qui génère des identifiants temporaires, il peut être fastidieux de les mettre à jour dans votre terminal toutes les quelques minutes lorsqu'ils expirent. Cela peut être corrigé en utilisant une directive `credential_process` dans le fichier de configuration. Par exemple, si vous avez une application web vulnérable, vous pourriez faire :
+Si vous exploitez une application qui génère des identifiants temporaires, il peut être fastidieux de les mettre à jour dans votre terminal toutes les quelques minutes lorsqu'ils expirent. Cela peut être résolu en utilisant une directive `credential_process` dans le fichier de configuration. Par exemple, si vous avez une application web vulnérable, vous pourriez faire :
 ```toml
 [victim]
 credential_process = curl -d 'PAYLOAD' https://some-site.com

src/pentesting-cloud/aws-security/aws-persistence/aws-cloudformation-persistence.md

@@ -12,7 +12,7 @@ Pour plus d'informations, accédez à :
 
 ### CDK Bootstrap Stack
 
-Le AWS CDK déploie une pile CFN appelée `CDKToolkit`. Cette pile prend en charge un paramètre `TrustedAccounts` qui permet aux comptes externes de déployer des projets CDK dans le compte victime. Un attaquant peut en abuser pour se donner un accès indéfini au compte victime, soit en utilisant l'interface en ligne de commande AWS pour redéployer la pile avec des paramètres, soit l'interface en ligne de commande AWS CDK.
+Le AWS CDK déploie une pile CFN appelée `CDKToolkit`. Cette pile prend en charge un paramètre `TrustedAccounts` qui permet aux comptes externes de déployer des projets CDK dans le compte de la victime. Un attaquant peut en abuser pour se donner un accès indéfini au compte de la victime, soit en utilisant l'interface en ligne de commande AWS pour redéployer la pile avec des paramètres, soit l'interface en ligne de commande AWS CDK.
 ```bash
 # CDK
 cdk bootstrap --trust 1234567890

src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-cloudformation-privesc/README.md

@@ -51,9 +51,9 @@ La permission `cloudformation:SetStackPolicy` peut être utilisée pour **vous d
 
 ### `iam:PassRole`,((`cloudformation:CreateChangeSet`, `cloudformation:ExecuteChangeSet`) | `cloudformation:SetStackPolicy`)
 
-Un attaquant ayant des permissions pour **passer un rôle et créer & exécuter un ChangeSet** peut **créer/mettre à jour une nouvelle pile cloudformation et abuser des rôles de service cloudformation** tout comme avec CreateStack ou UpdateStack.
+Un attaquant ayant les permissions de **passer un rôle et de créer & exécuter un ChangeSet** peut **créer/mettre à jour une nouvelle pile cloudformation et abuser des rôles de service cloudformation** tout comme avec CreateStack ou UpdateStack.
 
-L'exploitation suivante est une **variation de la**[ **CreateStack one**](#iam-passrole-cloudformation-createstack) utilisant les **permissions ChangeSet** pour créer une pile.
+L'exploitation suivante est une **variation de**[ **CreateStack one**](#iam-passrole-cloudformation-createstack) utilisant les **permissions ChangeSet** pour créer une pile.
 ```bash
 aws cloudformation create-change-set \
 --stack-name privesc \