mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-27 15:24:32 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-basic-information/REA
This commit is contained in:
Translator
@@ -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 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 le 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 :
|
||||
|
||||
@@ -53,18 +53,20 @@ Exemples de SCP :
|
||||
- Refuser complètement le compte root
|
||||
- Autoriser uniquement des régions spécifiques
|
||||
- Autoriser uniquement des services sur liste blanche
|
||||
- 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 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 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 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é.
|
||||
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é.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
> [!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.
|
||||
@@ -73,7 +75,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
|
||||
- Plafonner les permissions sur les files d'attente SQS pour empêcher les modifications non autorisées
|
||||
- Limiter les permissions sur les files d'attente SQS pour prévenir 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)
|
||||
@@ -124,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é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_
|
||||
_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_
|
||||
|
||||
### 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 appareil 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 dispositif 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 :
|
||||
|
||||
@@ -138,15 +140,15 @@ 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>
|
||||
```
|
||||
As [**indiqué ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), il existe de nombreux cas où **MFA ne peut pas être utilisé**.
|
||||
Comme [**indiqué ici**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html), il existe de nombreux cas où **MFA ne peut pas être utilisé**.
|
||||
|
||||
### [Groupes d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) <a href="#id_iam-groups" id="id_iam-groups"></a>
|
||||
|
||||
Un [groupe d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) est un moyen de **joindre des politiques à plusieurs utilisateurs** à la fois, ce qui peut faciliter la gestion des autorisations pour ces utilisateurs. **Les rôles et les groupes ne peuvent pas faire partie d'un groupe**.
|
||||
Un [groupe d'utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) est un moyen de **joindre des politiques à plusieurs utilisateurs** en même temps, ce qui peut faciliter la gestion des autorisations pour ces utilisateurs. **Les rôles et les groupes ne peuvent pas faire partie d'un groupe**.
|
||||
|
||||
Vous pouvez attacher une **politique basée sur l'identité à un groupe d'utilisateurs** afin que tous les **utilisateurs** du groupe d'utilisateurs **reçoivent les autorisations de la politique**. Vous **ne pouvez pas** identifier un **groupe d'utilisateurs** comme un **`Principal`** dans une **politique** (comme une politique basée sur les ressources) car les groupes sont liés aux autorisations, pas à l'authentification, et les principaux sont des entités IAM authentifiées.
|
||||
|
||||
@@ -154,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 ç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>
|
||||
|
||||
@@ -165,11 +167,11 @@ 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>
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
### Politiques
|
||||
|
||||
@@ -209,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 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.\
|
||||
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.\
|
||||
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 sujet, 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 égard, et qu'une politique de ressource leur accorde l'accès, alors ils sont autorisés.
|
||||
|
||||
### Limites IAM
|
||||
|
||||
@@ -230,7 +232,7 @@ Une limite est simplement une politique attachée à un utilisateur qui **indiqu
|
||||
|
||||
Une politique de session est une **politique définie lorsqu'un rôle est assumé** d'une manière ou d'une autre. Cela sera comme une **limite IAM pour cette session** : Cela signifie que la politique de session ne donne pas d'autorisations mais **les restreint à celles indiquées dans la politique** (les autorisations maximales étant celles que le rôle a).
|
||||
|
||||
Ceci est utile pour **les mesures de sécurité** : Lorsqu'un administrateur va assumer un rôle très privilégié, il pourrait restreindre l'autorisation uniquement à celles indiquées dans la politique de session au cas où la session serait compromise.
|
||||
Ceci est utile pour **des mesures de sécurité** : Lorsqu'un administrateur va assumer un rôle très privilégié, il pourrait restreindre l'autorisation uniquement à celles indiquées dans la politique de session au cas où la session serait compromise.
|
||||
```bash
|
||||
aws sts assume-role \
|
||||
--role-arn <value> \
|
||||
@@ -238,9 +240,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 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 la 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'en 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'empêche**.
|
||||
|
||||
### Fédération d'identité
|
||||
|
||||
@@ -273,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 se voyant **attribuer 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 **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**.
|
||||
|
||||
@@ -296,7 +298,7 @@ Non pris en charge :
|
||||
|
||||
#### Fédération Web ou authentification OpenID
|
||||
|
||||
L'application utilise AssumeRoleWithWebIdentity pour créer des identifiants temporaires. Cependant, cela ne donne pas accès à la console AWS, seulement accès aux ressources au sein d'AWS.
|
||||
L'application utilise AssumeRoleWithWebIdentity pour créer des identifiants temporaires. Cependant, cela n'accorde pas l'accès à la console AWS, seulement l'accès aux ressources au sein d'AWS.
|
||||
|
||||
### Autres options IAM
|
||||
|
||||
@@ -323,7 +325,7 @@ Dans [**cette page**](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference
|
||||
| APKA | Clé publique |
|
||||
| AROA | Rôle |
|
||||
| ASCA | Certificat |
|
||||
| ASIA | [Identifiants de clé d'accès temporaires (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilisent ce préfixe, mais ne sont uniques qu'en combinaison avec la clé d'accès secrète et le jeton de session. |
|
||||
| ASIA | [Identifiants de clé d'accès temporaires (AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html) utilisent ce préfixe, mais sont uniques uniquement en combinaison avec la clé d'accès secrète et le jeton de session. |
|
||||
|
||||
### Permissions recommandées pour auditer les comptes
|
||||
|
||||
|
||||
@@ -99,13 +99,13 @@ Pour créer une base de données SQL, il est nécessaire d'indiquer le serveur S
|
||||
|
||||
Une base de données SQL pourrait faire partie d'un **pool élastique**. Les pools élastiques sont une solution rentable pour gérer plusieurs bases de données en partageant des ressources de calcul (eDTUs) et de stockage configurables entre elles, avec une tarification basée uniquement sur les ressources allouées plutôt que sur le nombre de bases de données.
|
||||
|
||||
#### Sécurité au niveau des colonnes et des lignes d'Azure SQL
|
||||
#### Sécurité au niveau des colonnes Azure SQL (Masquage) & Sécurité au niveau des lignes
|
||||
|
||||
Le **masquage dynamique des données** d'Azure SQL est une fonctionnalité qui aide à **protéger les informations sensibles en les cachant** des utilisateurs non autorisés. Au lieu de modifier les données réelles, il masque dynamiquement les données affichées, garantissant que des détails sensibles comme les numéros de carte de crédit sont obscurcis.
|
||||
Le **masquage dynamique** des données d'Azure SQL est une fonctionnalité qui aide à **protéger les informations sensibles en les cachant** des utilisateurs non autorisés. Au lieu de modifier les données réelles, il masque dynamiquement les données affichées, garantissant que des détails sensibles comme les numéros de carte de crédit sont obscurcis.
|
||||
|
||||
Le **masquage dynamique des données** s'applique à tous les utilisateurs sauf à ceux qui ne sont pas masqués (ces utilisateurs doivent être indiqués) et aux administrateurs. Il dispose de l'option de configuration qui spécifie quels utilisateurs SQL sont exemptés du masquage dynamique des données, avec **les administrateurs toujours exclus**.
|
||||
Le **masquage dynamique des données** affecte tous les utilisateurs sauf ceux qui sont non masqués (ces utilisateurs doivent être indiqués) et les administrateurs. Il dispose de l'option de configuration qui spécifie quels utilisateurs SQL sont exemptés du masquage dynamique des données, avec **les administrateurs toujours exclus**.
|
||||
|
||||
La **sécurité au niveau des lignes d'Azure SQL (RLS)** est une fonctionnalité qui **contrôle quelles lignes un utilisateur peut voir ou modifier**, garantissant que chaque utilisateur ne voit que les données qui le concernent. En créant des politiques de sécurité avec des filtres ou des prédicats de blocage, les organisations peuvent appliquer un accès granulaire au niveau de la base de données.
|
||||
La **sécurité au niveau des lignes Azure SQL (RLS)** est une fonctionnalité qui **contrôle quelles lignes un utilisateur peut voir ou modifier**, garantissant que chaque utilisateur ne voit que les données qui le concernent. En créant des politiques de sécurité avec des prédicats de filtrage ou de blocage, les organisations peuvent appliquer un accès granulaire au niveau de la base de données.
|
||||
|
||||
### Azure SQL Managed Instance
|
||||
|
||||
|
||||
Reference in New Issue
Block a user