Contenu
Mis à jour le 2022-01-24
  • OS utilisé: Ubuntu
  • Version de RDS (MySQL) utilisée: 5.7
  • Prérequis:
    • Avoir un compte AWS avec une instance RDS MySQL
    • Avoir un compte Gitlab
    • Installation de Terraform
    • Installation de Docker
    • Installation de Vault

Introduction:

Le règlement général de protection des données (RGPD) est un texte réglementaire européen qui encadre le traitement des données de manière égalitaire sur tout le territoire de l’Union Européenne. Il est entré en application le 25 mai 2018.

png

Il a été conçu autour de 3 objectifs:

  • enforcer les droits des personnes
  • responsabiliser les acteurs traitant des données
  • crédibiliser la régulation grâce à une coopération renforcée entre les autorités de protection des données.

(Source)


Procédé:

Pour résumer un besoin classique: des recetteurs veulent tester des données de Production mais dans un environnement auquel ils ont accès et qui est moins critique, Staging. Par contre, si on veut respecter les normes RGPD, il faut donc procéder à une étape d’anonymisation de ces données puis de les exporter vers un autre environnement.

Pour ce faire, nous voulons créer une sauvegarde d’une base de donnée en environnement de Production, anonymiser cette sauvegarde puis la restaurer sur une base de donnée en environnement Staging.

Pour s’assurer qu’on fasse une sauvegarde en toute sérénité sans impacter nos collaborateurs, nous allons la lancer à 4h00 du matin avec un évènement CloudWatch.

Voici un schéma qui illustre le processus de l’anonymisation:

png


Partie technique:

Sans trop rentrer dans les détails, je vous montre en quelques exemples comment, techniquement, j’ai élaboré mon projet.

Quand je déclare mon provider “aws” je précise l’assume role qui me permet d’accéder au compte AWS en question:

1
2
3
4
5
6
7
provider "aws" {
  region = var.region
  assume_role {
    role_arn = var.devops_role_env_map[terraform.workspace]
  }
}

Puis je créé ma fonction Lambda qui me permettra d’exécuter mon code python et de mettre en place des variables d’environnements grâce aux datasources qui me permettent de récupérer 2 variabes dans Vault :GITLAB_PIPELINE_TOKEN et GITLAB_ANONYMIZE_PIPELINE_URL.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
resource "aws_lambda_function" "rds_snapshot" {
  filename      = "lambda_package.zip"
  function_name = "rds_snapshot"
  role          = aws_iam_role.anonymization.arn
  handler       = "rds_snapshot.lambda_handler"

  source_code_hash = base64sha256("lambda_package.zip")

  timeout       = 900
  runtime       = "python3.7"

  environment {
    variables = {
      GITLAB_PIPELINE_TOKEN = data.vault_generic_secret.gitlab-pipeline.data.token
      GITLAB_ANONYMIZE_PIPELINE_URL = data.vault_generic_secret.gitlab-pipeline.data.url
      LAMBDA_WORKSPACE = terraform.workspace
    }
  }
}

Je veux ensuite configurer mes 3 évènements Cloudwatch qui me permettront d’effectuer une action spécifique selon l’évènement. Voici un exemple qui démontre en 3 parties, la configuration d’un évènement:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
## RDS SNAPSHOT EVENT
resource "aws_cloudwatch_event_rule" "event_create_snapshot" {
  name                = "create-snapshot"
  description         = "Create RDS Snapshot, triggers every day at 4am from monday to friday"
  schedule_expression = "cron(0 3 ? * MON-FRI *)" # caution: aws cron uses UTC time
}

resource "aws_lambda_permission" "allow_event_create_snapshot" {
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.rds_snapshot.function_name
  principal     = "events.amazonaws.com"
  source_arn    = aws_cloudwatch_event_rule.event_create_snapshot.arn
}

resource "aws_cloudwatch_event_target" "event_create_snapshot_target" {
  for_each  = local.lang
  rule      = aws_cloudwatch_event_rule.event_create_snapshot.name
  target_id = "rds_snapshot"
  arn       = aws_lambda_function.rds_snapshot.arn
  input     = <<JSON
        {
            "action": "create-snapshot",
            "lang": "${each.value}"
        }
JSON
}

Ci-dessus, par ordre

  • Je créé un event qui se lancera tous les jours à 4h00 du matin
  • J’autorise mon event à invoquer ma fonction Lambda rds_snapshot
  • Je créé mon event_target qui ciblera ma fonction Lambda rds_snapshot avec pour argument action et lang.

Vous l’aurez compris, cette architecture qui compose 3 ressources Terraform se répliquera 3 fois, ce qui fait donc 3 évènements:

  • Un évènement basé sur un cronjob pour la création du snapshot (exemple ci-dessus)
  • Un évènement qui se produit lorsque la création du snapshot est disponible, pour invoquer la restauration (en tant qu’instance RDS) du snapshot via mon script python.
  • Puis un dernier évènement qui se base sur la fin de la restauration, pour ensuite exécuter une requête POST vers Gitlab qui se chargera d’anonymiser cette instance restaurée, de la dumper et de la restaurer sur une base Staging.

Voici un schéma qui explique l’automatisation de la sauvegarde du Snapshot RDS:

png