Surveiller l’état de conformité entre comptes et entre régions avec AWS Config
AWS Config est un service de surveillance continue de vos ressources AWS, qui simplifie l’évaluation et l’enregistrement des configurations et des modifications de vos ressources AWS. Cette surveillance est effectuée à l’aide de règles qui définissent l’état de configuration souhaité de vos ressources AWS.
AWS Config fournit un certain nombre de règles gérées qui répondent à un large éventail de problèmes de sécurité, de calcul, de gestion, de réseautique et de diffusion de contenu, d’identité, de conformité et de stockage. Vous pouvez également créer des règles personnalisées pour coder vos propres exigences de conformité grâce à l’utilisation des fonctions AWS Lambda.
Dans cet article, nous montrerons comment utiliser AWS Config dans une organisation multi-comptes et multi-régions pour surveiller toutes les règles de configuration via un compte central.
Nous déploierons notamment des règles pour contrôler les groupes de sécurité afin d’éviter la création de règles qui autorisent un accès public aux ressources AWS. En cas de violation de cette politique, un événement Amazon CloudWatch sera déclenché pour informer les équipes concernées via Amazon Simple Notification Service (Amazon SNS).
Déploiement – Architecture et synthèse de la démarche
L’implémentation d’AWS Config est relativement simple. Ci-dessous les cinq étapes principales, qui sont reprises en détail dans la suite de l’article :
- Activez AWS Config pour surveiller la conformité des règles mises en place.
- Créez une stratégie IAM qui accorde des autorisations d’écriture au compartiment S3 auquel AWS Config fournira les éléments de configuration.
- Créez et configurez Amazon CloudWatch Events pour filtrer les notifications AWS Config et prendre des mesures.
- Configurez l’agrégation des règles AWS Config dans le compte de sécurité.
- Vérifiez la solution de surveillance en vous assurant de l’envoi d’une notification en cas de non-respect d’une règle de conformité.
Étape 1: activez la surveillance AWS Config
Nous allons voir ici comment configurer AWS Config pour surveiller les groupes de sécurité.
Conception d’une stack Terraform permettant de déployer AWS Config :
resource "aws_config_configuration_recorder_status" "config" {
name = "${aws_config_configuration_recorder.config.name}"
is_enabled = true
depends_on = ["aws_config_delivery_channel.config"]
}
resource "aws_config_delivery_channel" "config" {
name = "${aws_config_configuration_recorder.config.name}"
s3_bucket_name = "${var.bucket_name}"
snapshot_delivery_properties {
delivery_frequency = "${var.config_delivery_frequency}"
}
depends_on = ["aws_config_configuration_recorder.config"]
}
Mise en place des règles de surveillance des groupes de sécurité :
Les règles ci-dessous permettent de vérifier que les groupes de sécurité sont attachés à des ressources et si un groupe de sécurité contient la valeur entrante 0.0.0.0/0.
Ec2-security-group-attached-to-eni et Vpc-sg-open-only-to-authorized-ports
resource "aws_config_config_rule" "ec2-security-group" {
name = "ec2-security-group"
source {
owner = "AWS"
source_identifier = "EC2_SECURITY_GROUP_ATTACHED_TO_ENI"
}
depends_on = ["aws_config_configuration_recorder.config"]
}
resource "aws_config_config_rule" "vpc-sg-open" {
name = "vpc-sg-open-only"
source {
owner = "AWS"
source_identifier = "VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS"
}
depends_on = ["aws_config_configuration_recorder.config"]
}
Remarque : il existe différentes solutions pour déployer AWS Config, en utilisant AWS Management Console, AWS CLI ou AWS SDK.
Étape 2 : créez une stratégie IAM qui accorde des autorisations d’écriture au compartiment S3 sécurisé.
Le compartiment S3 servira à recevoir l’historique et les snapshots des configurations, qui contiennent les détails sur les ressources enregistrées par AWS Config.
Dans cet exemple notre Bucket S3 se trouve dans le compte sécurité, pour assurer une gestion centralisée des fichiers d’historique et des snapshot des comptes.
data "template_file" "template" {
template = <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AWSConfigBucketPermissionsCheck",
"Effect": "Allow",
"Action": "s3:GetBucketAcl",
"Resource": "$${bucket_arn}"
},
{
"Sid": "AWSConfigBucketExistenceCheck",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "$${bucket_arn}"
},
{
"Sid": "AWSConfigBucketDelivery",
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "$${resource}",
"Condition": {
"StringLike": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
EOF
vars = {
bucket_arn = "${format("arn:aws:s3:::%s", var.bucket_name)}"
resource = "${format("arn:aws:s3:::%s/AWSLogs/*", var.bucket_name)}"
}
}
data "aws_iam_policy_document" "policy_document" {
statement {
actions = ["sts:AssumeRole"]
principals {
type = "Service"
identifiers = ["config.amazonaws.com"]
}
effect = "Allow"
}
}
resource "aws_iam_role" "role" {
name = "${var.config_role_name}"
path = "/"
description = ""
assume_role_policy = "${data.aws_iam_policy_document.policy_document.json}"
}
resource "aws_iam_policy" "policy" {
name = "${var.config_policy_name}"
policy = "${data.template_file.template.rendered}"
}
resource "aws_iam_role_policy_attachment" "custom_policy" {
role = "${aws_iam_role.role.name}"
policy_arn = "${aws_iam_policy.policy.arn}"
}
resource "aws_iam_role_policy_attachment" "managed_policy" {
role = "${aws_iam_role.role.name}"
policy_arn = "arn:aws:iam::aws:policy/service-role/AWSConfigRole"
}
Étape 3: créez et configurez Amazon CloudWatch Events pour filtrer les notifications AWS Config et prendre des mesures.
Cette configuration permet à AWS Config de transmettre toutes les notifications liées aux modifications de configuration et du niveau de conformité aux événements CloudWatch.
Cela permet d’utiliser les fonctionnalités de filtrage natives dans CloudWatch Events pour filtrer les événements AWS Config afin de pouvoir diriger chaque type de notifications vers une cible spécifique.
data "aws_caller_identity" "current" {}
resource "aws_cloudwatch_event_rule" "event_config_sg_open" {
name = "${var.cloudwatch_event_config_sg_open}"
description = "${var.cloudwatch_event_description}"
event_pattern = <<PATTERN
{
"source": [
"aws.config"
],
"detail-type": [
"Config Rules Compliance Change"
],
"detail": {
"messageType": [
"ComplianceChangeNotification"
],
"configRuleName": [
"vpc-sg-open-only-to-authorized-ports"
]
}
}
PATTERN
}
resource "aws_cloudwatch_event_target" "config_target_sg_open" {
rule = "${aws_cloudwatch_event_rule.event_config_sg_open.name}"
target_id = "${var.topic_name}"
arn = "${var.topic_arn}"
input_transformer = {
input_paths = {
"annotation" = "$.detail.newEvaluationResult.annotation"
"awsRegion" = "$.detail.awsRegion"
"awsAccountId" = "$.detail.awsAccountId"
"resourceid" = "$.detail.resourceId"
"complianceType" = "$.detail.newEvaluationResult.complianceType"
}
input_template = "${file("./input.json")}"
}
}
Étape 4: utilisez la fonction d’agrégation de données pour agréger les résultats de conformité dans le compte de sécurité.
Cette fonctionnalité permet d’agréger les statuts de conformité des règles de configuration AWS de plusieurs comptes et régions en un seul compte pour fournir une vue à l’échelle de l’organisation de votre conformité. Il est également possible de créer un agrégateur basé sur les organisations pour agréger les données AWS Config de l’ensemble de votre organisation.
Remarque – Définitions :
- Compte agrégateur (aggregator) : un compte AWS qui collecte des données AWS Config de d’un ou plusieurs comptes source.
- Compte source (account 1, account 2, account 3..) : un compte AWS contenant des données de conformité à agréger
- Autorisation : une action qui autorise le compte agrégateur à collecter des données AWS Config à partir d’un compte source
- Vue agrégée : un tableau de bord qui montre l’état de conformité d’un agrégateur
Etapes :
- Configuration de l’agrégateur de configuration AWS Config
resource "aws_config_configuration_aggregator" "accounts" {
count = "${var.enabled_config_aggregator ? 1 : 0}"
name = "${var.config_aggregator_name}"
account_aggregation_source {
account_ids = ["${var.account_lists}"]
all_regions = “true”
}
}
- Ajout d’une autorisation qui permet à l’agrégateur de collecter des données AWS Config sur les comptes sources
resource "aws_config_aggregate_authorization" "accounts" {
count = "${var.enabled_config_aggregator ? 1 : 0}"
account_id = "${var.authorized_aggregator_account_id}"
region = "${var.authorized_aggregator_region}"
}
Étape 5 : Vérifiez la solution de surveillance en assurant l’envoi d’une notification en cas de non-respect d’une règle de conformité.
Cette dernière étape passe par la simulation d’une non-conformité (sur une règle ou un type de ressources) pour tester l’envoi des notifications associées à des adresses mails spécifiques ou encore l’acheminement des modification de configuration vers un outil ITSM/CMDB externe.
Conclusion
Nous avons maintenant identifié les non-conformités ! Bravo, mais votre travail n’est pas terminé pour autant, il reste à savoir comment gérer la remédiation. La remédiation doit-elle être automatisée ou manuelle ? Et qui s’en charge ? Est-ce l’équipe « propriétaire » ou responsable de la ressource concernée ou une équipe tiers, comme une équipe sécurité ? C’est un vaste sujet qui mériterait un article à lui seul.