Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Création d'un rôle IAM pour AWS Security Agent
AWS Security Agent utilise les rôles IAM de trois manières :
1. **Rôle de l'application :** utilisé lors de la création de l'application AWS Security Agent. Pour les cas d'utilisation du centre d'identité IAM et du lien d'accès administrateur, le service assume ce rôle pour accorder aux WebApp utilisateurs les autorisations nécessaires pour interagir avec les API d'AWS Security Agent.
1. **Rôle du service de test d'intrusion :** spécifié lors de la création des espaces d'agent sous forme de liste des rôles disponibles. WebApp Les utilisateurs sélectionneront ultérieurement l'un de ces rôles lors de la création d'un test d'intrusion. Le service AWS Security Agent assume ce rôle pour accéder à vos ressources AWS pendant les tests.
1. **Rôle d'acteur :** utilisé pour authentifier et autoriser les demandes adressées à votre application Web cible (par exemple, les API AWS API Gateway). Ces rôles sont fournis lors de la création de l'espace agent. L'agent AWS Security Agent joue le rôle d'acteur pour interagir avec votre application cible.
## Rôle de l'application
Le rôle d'application est utilisé lors de la création de votre application AWS Security Agent dans le service. Pour les scénarios d'authentification du centre d'identité IAM et du lien d'accès administrateur, le service AWS Security Agent assume ce rôle afin d'accorder WebApp aux utilisateurs les autorisations nécessaires pour interagir avec les API d'AWS Security Agent.
### Autorisations nécessaires
Ce rôle nécessite des autorisations pour :
+ Invoquer les opérations de l'API AWS Security Agent
+ Lire et écrire les données de configuration des applications
+ Accès aux informations de session utilisateur
+ Gérer les jetons d'authentification pour WebApp les utilisateurs
### Stratégie d’approbation
La politique de confiance doit permettre au service AWS Security Agent d'assumer ce rôle :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "securityagent.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
### Stratégie d’autorisations
Le rôle doit inclure des autorisations pour :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"securityagent:GetApplication",
"securityagent:UpdateApplication",
"securityagent:ListAgentInstances",
"securityagent:CreatePentestSession"
],
"Resource": "arn:aws:securityagent:*:*:application/*"
}
]
}
```
**Note**
Personnalisez les autorisations en fonction des exigences spécifiques de votre application et du principe du moindre privilège.
## Rôle du service de test de pénétration
Le rôle du service de test de pénétration est spécifié lors de la création d'espaces d'agent sous la forme d'une liste de rôles disponibles. Lorsque WebApp les utilisateurs créent un test d'intrusion, ils sélectionnent l'un de ces rôles. Le service AWS Security Agent assume ensuite ce rôle pour accéder à vos ressources AWS et les tester.
### Autorisations nécessaires
Ce rôle a besoin d'autorisations pour accéder à vos ressources AWS et les analyser lors des tests d'intrusion :
+ Lire et décrire les configurations VPC et la topologie du réseau
+ Inspectez les instances EC2, les groupes de sécurité et les ACL réseau
+ Analyser les politiques IAM et les autorisations de ressources
+ Lire CloudWatch les journaux et les statistiques
+ Accédez aux configurations des services AWS pertinentes pour les tests de sécurité
### Stratégie d’approbation
La politique de confiance doit permettre au service AWS Security Agent d'assumer ce rôle pour les opérations de test d'intrusion :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "securityagent.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "your-external-id"
}
}
}
]
}
```
**Note**
Utilisez un identifiant externe pour renforcer la sécurité lorsque vous autorisez l'accès entre comptes ou services.
### Stratégie d’autorisations
Le rôle doit inclure un accès en lecture seule à vos ressources AWS. Envisagez d'utiliser les politiques gérées suivantes :
+ `SecurityAudit`- Politique gérée par AWS pour l'audit de sécurité
+ `ViewOnlyAccess`- Read-only accès à la plupart des services AWS
Ou créez une politique personnalisée avec des autorisations spécifiques :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:Describe*",
"vpc:Describe*",
"iam:Get*",
"iam:List*",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams",
"cloudwatch:Describe*",
"cloudwatch:Get*",
"cloudwatch:List*",
"s3:GetObject",
"s3:ListBucket"
],
"Resource": "*"
}
]
}
```
**Important**
N'accordez que les autorisations minimales requises pour la portée de vos tests d'intrusion. Passez en revue et ajustez les autorisations en fonction des services AWS que vous souhaitez inclure dans les tests de sécurité.
## Rôle d'acteur
Le rôle d'acteur est utilisé pour authentifier et autoriser les demandes adressées à votre application Web cible lors des tests d'intrusion. Ces rôles sont fournis lors de la création de l'espace agent, et l'agent AWS Security Agent suppose qu'ils interagissent avec les points de terminaison de votre application cible (tels que les API AWS API Gateway, les URL des fonctions Lambda ou AWS-hosted d'autres applications).
### Autorisations nécessaires
Ce rôle nécessite des autorisations pour :
+ Invoquer les points de terminaison API Gateway
+ Exécuter les fonctions Lambda
+ Accédez à des ressources AWS spécifiques aux applications
+ Authentifiez-vous à l'aide des mécanismes d'authentification de votre application cible
+ Effectuez des opérations HTTP sur les points de terminaison de votre application
### Stratégie d’approbation
La politique de confiance doit permettre au service d'agent de sécurité AWS d'assumer ce rôle :
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "securityagent.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "your-external-id"
}
}
}
]
}
```
### Stratégie d’autorisations
Les autorisations dépendent de l'architecture de votre application cible. Voici des exemples de scénarios courants :
#### Pour les applications API Gateway
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"execute-api:Invoke"
],
"Resource": "arn:aws:execute-api:us-east-1:*:your-api-id/*"
}
]
}
```
#### Pour les URL des fonctions Lambda
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"lambda:InvokeFunctionUrl",
"lambda:InvokeFunction"
],
"Resource": "arn:aws:lambda:us-east-1:*:function:your-function-name"
}
]
}
```
#### Pour Application Load Balancer avec authentification Cognito
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"cognito-idp:InitiateAuth",
"cognito-idp:RespondToAuthChallenge"
],
"Resource": "arn:aws:cognito-idp:us-east-1:*:userpool/your-user-pool-id"
}
]
}
```
**Important**
Configurez les autorisations de rôle d'acteur en fonction des exigences d'authentification et d'autorisation de votre application cible. Le rôle doit avoir le même niveau d'accès que les utilisateurs ou les services que l'agent de sécurité simulera lors des tests d'intrusion.