En définissant sa stratégie IAM et le cadre d’autonomie des équipes qui travaillent sur le cloud, il n’est pas toujours simple de trouver le bon curseur entre autonomie, efficacité et sécurité.
Les bonnes pratiques nous recommandent de respecter le principe Least privilege. Cependant un cadre trop strict revient à freiner les équipes et les pousse à trouver des solutions de contournement qui deviennent parfois des nouvelles failles de sécurité.
Avec PAM sur Google Cloud, ne serait-il pas possible de réconcilier Least privilege tout en ayant la possibilité d’avoir un cadre flexible ?
P.A.M. pour Privileged Access Manager est un service intégré à Google Cloud qui nous propose un workflow d’attribution de droit temporaire avec :
Je vous propose de présenter le fonctionnement par l’exemple, avec un cas d’utilisation inspiré d’un cas réel :
En tant qu’équipe plateforme, je souhaite pouvoir autoriser l’équipe de développement à réaliser des opérations d’administration exceptionnelles en production. Par défaut, les droits en écriture sur le projet sont donnés uniquement au compte de service de la CI/CD qui déploie les ressources via Infrastructure as Code.
Pour l’exemple, je vais partir du principe que les opérations de production sont uniquement des suppressions de bucket. En pratique, on ajoutera les rôles prédéfinis correspondant aux dites opérations.
Dans IAM & Admin > PAM > Entitlements > Create :
À partir du moment où l’entitlement est créé, l'équipe de développement peut y accéder pour faire sa demande de droit temporaire :
Les admins recevront un email avec un lien permettant de rapidement valider ou refuser la demande.
Le rôle sera assigné automatiquement avec une IAM condition l’identifiant comme un rôle PAM et avec une expiration :
Le rôle sera supprimé complètement lors de l’expiration de la demande d’accès.
Un certain nombre de prérequis sont nécessaires en terme de rôles:
À noter que pour les requesters, il est possible d’utiliser des utilisateurs, groupes ou comptes de service et pour les approvers uniquement des utilisateurs et groupes.
Il n’est pas possible de créer un entitlement avec les rôles basiques (ce qui n’est pas forcément un mal).
Tous les événements de demande d’accès, validation ou refus, ainsi que les modifications sur les entitlements apparaissent dans les logs d’audits et accessibles dans l’interface PAM :
Il est possible d’ajouter à un entitlement des notifications supplémentaires par mail lors des demandes/validations d’accès, à des emails autres que ceux qui valident.
Il est également possible de configurer un entitlement pour ne pas nécessiter de validation, étonnant ?
Et bien pas forcément :
Ne pas avoir de droit élevé sur un projet, c’est une sécurité pour s’éviter soit même une erreur, il n’est pas souhaitable d’avoir les droits admin en permanence même si je suis censé avoir le droit de faire certaines opérations.
Supprimer une table BigQuery en production en partant du principe que c’était celle sur le projet de dev et bien ça peut arriver. Mieux vaut ne pas être Bigquery Admin en production et se donner ce droit temporairement, uniquement quand on en a besoin.
Dans l’idéal, les entitlements devraient être managées via Infrastructure As Code, un exemple avec Terraform pour pouvoir permettre à une équipe Data (data-engineer-team) de demander temporairement le rôle BigQuery Admint:
resource "google_privileged_access_manager_entitlement" "bigquery_admin_entitlement" {
provider = google-beta
entitlement_id = "bigquery-admin-entitlement"
location = "global"
max_request_duration = "3600s"
parent = "projects/${var.project_id}"
requester_justification_config {
unstructured {}
}
eligible_users {
principals = ["group:data-engineer-team@xxxdomain.fr"]
}
privileged_access {
gcp_iam_access {
role_bindings {
role = "roles/bigquery.admin"
}
resource = "//cloudresourcemanager.googleapis.com/projects/${var.project_id}"
resource_type = "cloudresourcemanager.googleapis.com/Project"
}
}
additional_notification_targets {
admin_email_recipients = ["data-security-team@xxxdomain.fr"]
}
approval_workflow {
manual_approvals {
require_approver_justification = true
steps {
approvals_needed = 1
approvers {
principals = ["group:data-admin-team@xxxdomain.fr"]
}
}
}
}
}
Simple et efficace, PAM simplifie et favorise le least privilege, principalement car ce nouveau service nous enlève le besoin d’avoir des droits importants pour des opérations ponctuelles.
Il est également possible d’utiliser PAM pour les droits folders et organisations de la même manière.
À noter qu’il est possible de réduire le scope du rôle attribué via PAM en ajoutant une IAM condition et éventuellement les tags mais il n’est pas possible d’attribuer des rôles au niveau ressource.
Attention tout de même à ce que cet outil supplémentaire ne soit pas utilisé pour créer une stratégie IAM trop compliquée à administrer et à auditer :