mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-02-04 19:11:41 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -64,9 +64,9 @@ Trouvez des **exemples JSON** dans [https://docs.aws.amazon.com/organizations/la
|
||||
|
||||
### 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 ne font que limiter 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 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é.
|
||||
|
||||
C'est le SEUL moyen de s'assurer 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 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.
|
||||
|
||||
> [!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.
|
||||
@@ -118,7 +118,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'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)).
|
||||
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)).
|
||||
|
||||
#### CLI
|
||||
|
||||
@@ -126,12 +126,12 @@ Les utilisateurs peuvent avoir **MFA activé pour se connecter** via la console.
|
||||
- **ID de clé d'accès secrète** : 40 caractères aléatoires en majuscules et minuscules : S836fh/J73yHSb64Ag3Rkdi/jaD6sPl6/antFtU (Il n'est pas possible de récupérer les ID de clé d'accès secrète perdus).
|
||||
|
||||
Chaque fois que vous devez **changer la clé d'accès**, voici le processus que vous devez suivre :\
|
||||
_Créer une nouvelle clé d'accès -> Appliquer la nouvelle clé au système/application -> Marquer l'original comme inactif -> Tester et vérifier que la nouvelle clé d'accès fonctionne -> Supprimer l'ancienne clé d'accès_
|
||||
_Créez une nouvelle clé d'accès -> Appliquez la nouvelle clé au système/application -> marquez l'original comme inactif -> Testez et vérifiez que la nouvelle clé d'accès fonctionne -> Supprimez l'ancienne clé d'accès_
|
||||
|
||||
### MFA - Authentification Multi-Facteurs
|
||||
|
||||
Il est utilisé pour **créer un facteur supplémentaire pour l'authentification** en plus de vos méthodes existantes, telles que le mot de passe, créant ainsi un niveau d'authentification multi-facteurs.\
|
||||
Vous pouvez utiliser une **application virtuelle gratuite ou un dispositif physique**. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.
|
||||
Vous pouvez utiliser une **application virtuelle gratuite ou un appareil physique**. Vous pouvez utiliser des applications comme Google Authenticator gratuitement pour activer un MFA dans AWS.
|
||||
|
||||
Les politiques avec des conditions MFA peuvent être attachées aux éléments suivants :
|
||||
|
||||
@@ -140,7 +140,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 +156,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 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).
|
||||
- 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).
|
||||
|
||||
### [Rôles IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) <a href="#id_iam-roles" id="id_iam-roles"></a>
|
||||
|
||||
@@ -167,7 +167,7 @@ Un rôle IAM se compose de **deux types de politiques** : une **politique de con
|
||||
|
||||
#### Service de jetons de sécurité AWS (STS)
|
||||
|
||||
Le service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour :
|
||||
Le Service de jetons de sécurité AWS (STS) est un service web qui facilite **l'émission de credentials temporaires à privilèges limités**. Il est spécifiquement conçu pour :
|
||||
|
||||
### [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>
|
||||
|
||||
@@ -177,10 +177,10 @@ Les **credentials temporaires sont principalement utilisés avec des rôles IAM*
|
||||
|
||||
#### Permissions de politique
|
||||
|
||||
Sont utilisées pour attribuer des permissions. Il existe 2 types :
|
||||
Sont utilisées pour attribuer des autorisations. 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 permissions) 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 autorisations) 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).
|
||||
@@ -211,14 +211,14 @@ Les [champs spécifiques qui peuvent être utilisés pour des conditions par ser
|
||||
|
||||
#### Politiques Inline
|
||||
|
||||
Ce type de politiques est **directement attribué** à un utilisateur, un groupe ou un rôle. Ainsi, elles n'apparaissent pas dans la liste des Politiques car d'autres peuvent les utiliser.\
|
||||
Ce type de politiques est **directement assigné** à un utilisateur, un groupe ou un rôle. Ainsi, elles n'apparaissent pas dans la liste des Politiques car d'autres peuvent les utiliser.\
|
||||
Les politiques inline sont utiles si vous souhaitez **maintenir une relation stricte un à un entre une politique et l'identité** à laquelle elle est appliquée. Par exemple, vous voulez vous assurer que les autorisations dans une politique ne sont pas attribuées par inadvertance à une identité autre que celle pour laquelle elles sont destinées. Lorsque vous utilisez une politique inline, les autorisations dans la politique ne peuvent pas être attachées par inadvertance à la mauvaise identité. De plus, lorsque vous utilisez la console de gestion AWS pour supprimer cette identité, les politiques intégrées à l'identité sont également supprimées. C'est parce qu'elles font partie de l'entité principale.
|
||||
|
||||
#### Politiques de Bucket de Ressources
|
||||
|
||||
Ce sont des **politiques** qui peuvent être définies dans des **ressources**. **Toutes les ressources d'AWS ne les prennent pas en charge**.
|
||||
|
||||
Si un principal n'a pas de refus explicite à leur égard, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
|
||||
Si un principal n'a pas de refus explicite à leur sujet, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
|
||||
|
||||
### Limites IAM
|
||||
|
||||
@@ -240,7 +240,7 @@ 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 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 la 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 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).
|
||||
|
||||
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**.
|
||||
|
||||
@@ -251,7 +251,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** 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.
|
||||
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.
|
||||
|
||||
<figure><img src="../../../images/image (247).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -261,7 +261,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 des utilisateurs, il y a 3 sources d'identité qui peuvent être utilisées :
|
||||
Pour connecter les 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 +275,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 étant donnés **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 recevant **des 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 +302,10 @@ L'application utilise AssumeRoleWithWebIdentity pour créer des identifiants tem
|
||||
|
||||
### Autres options IAM
|
||||
|
||||
- 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 **définir une 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**.
|
||||
|
||||
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**.
|
||||
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**.
|
||||
|
||||
### Préfixes d'ID IAM
|
||||
|
||||
@@ -375,6 +375,23 @@ aws --profile acc2 ...
|
||||
```
|
||||
Si vous recherchez quelque chose de **similaire** à cela mais pour le **navigateur**, vous pouvez consulter l'**extension** [**AWS Extend Switch Roles**](https://chrome.google.com/webstore/detail/aws-extend-switch-roles/jpmkfafbacpgapdghgdpembnojdlgkdl?hl=en).
|
||||
|
||||
#### 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 :
|
||||
```toml
|
||||
[victim]
|
||||
credential_process = curl -d 'PAYLOAD' https://some-site.com
|
||||
```
|
||||
Notez que les identifiants _doivent_ être renvoyés à STDOUT dans le format suivant :
|
||||
```json
|
||||
{
|
||||
"Version": 1,
|
||||
"AccessKeyId": "an AWS access key",
|
||||
"SecretAccessKey": "your AWS secret access key",
|
||||
"SessionToken": "the AWS session token for temporary credentials",
|
||||
"Expiration": "ISO8601 timestamp when the credentials expire"
|
||||
}
|
||||
```
|
||||
## Références
|
||||
|
||||
- [https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started_concepts.html)
|
||||
|
||||
Reference in New Issue
Block a user