Note : article publié à l'origine sur https://www.linkedin.com/pulse/google-cloud-s%C3%A9curisez-et-prot%C3%A9gez-vos-buckets-contre-abdennebi/

Le 22 Juillet 2020, Twilio a annoncé avoir été victime d’une compromission du contenu d’une Bucket S3. La bucket contenait des ressources web destinées au public, mais un chemin particulier était ouvert en écriture depuis 5 ans. Les droits ont été modifiés à l'époque pour diagnostiquer un problème...

L’attaque consistait en une injection de code dans un SDK JavaScript que Twilio distribue à ses clients. Le code injecté, bien que bénin, était la première étape d'une injection de code ayant pour objectif le vol de cartes bancaires par le groupe de pirates Magecart.

Le vol de données sensibles par des organisation cybercriminelles est malheureusement monnaie courante de nos jours. Il est toutefois possible de se prémunir de certaines attaques en adoptant des bonnes pratiques de sécurité rapides et efficaces.

En effet, ces buckets mal configurées sont souvent le résultat d'une erreur ou d'une étourderie. Il est tout à fait possible de les éviter en amont, en mettant en place des règles centralisées applicables à l'ensemble des buckets de l'entreprise. Le simple fait de les activer vous permettra d'améliorer grandement votre posture de sécurité.

Dans GCP, il existe de règles d'organisation (organization policies) qui contraignent la façon de créer ou de configurer certaines ressources cloud, par exemple : interdire la création de machines virtuelles avec des adresses IP publiques, forcer l’utilisation de des Golden Images de l’entreprise ou encore désactiver la création automatique de réseaux. Ces règles sont hiérarchiques. Lorsqu’une règle est appliquée à l'organisation, elle est tout autant appliquée aux folders et aux projets enfants. Les folders et les projets peuvent eux-mêmes définir des règles spécifiques à leurs besoins.

Parmi les nombreuses règles, deux d'entre elles nous intéressent :

• La première est Domain restricted sharing : cette règle est, à mon sens, la plus importante et la plus urgente à mettre en place. En effet, elle permet de contrôler les domaines auxquels vous pouvez attribuer des droit IAM. C'est un premier niveau de sécurité qui interdira de donner des droits à des utilisateurs externes à votre organisation qu’il s’agisse de comptes Gmail ou de comptes G Suite appartenant à d'autres organisations.

• La deuxième règle est Enforce uniform bucket-level access : cette règle fait appel à un peu plus de technique. En effet, elle permet de désactiver l'ancien modèle ACL des buckets, modèle qui permet une gestion plus fine des droits d'accès aux objets. Par exemple, on peut donner les droit READ à allUsers pour un répertoire qui héberge des ressources statiques d'un site web /static/public ou de fermer le reste. Avec ce modèle, les erreurs sont faciles, car cela implique une micro-gestion des ACLs. C'est pour cela que Google recommande l'utilisation de l'uniform bucket-level access où les droits sont donnés de manière uniforme à la bucket : si on veut publier des ressources statiques sur Internet, il faut alors utiliser une bucket dédiée et identifiée clairement comme publique

Configuration des règles

Il est possible de faire les actions suivantes soit à travers l'IHM soit en utilisant la CLI. On peut même utiliser Terraform. Je vais néanmoins employer la CLI car ce n'est pas verbeux et les commandes sont assez expressives.

Règle 1- Domain restricted sharing : avant d'appliquer cette règle, assurez-vous que vous n'allez pas couper l'accès à de futurs partenaires ou prestataires externes. Il faut souligner, que cette règle n'est pas rétroactive.

D'abord récupérez votre Organization Id et votre Customer Id à l'aide de la commande suivante ::

$ gcloud organizations list

-- 
DISPLAY_NAME                   ID  DIRECTORY_CUSTOMER_ID
cloudnativestack.io  855756xxxxxx              C00xxxxxx

Exécutez ensuite la commande suivante (vous pouvez ajoutez d'autres Customer Ids mais je vous le déconseille)

gcloud beta resource-manager org-policies allow \
    --organization $CUSTOMER_ID \
    iam.allowedPolicyMemberDomains $CUSTOMER_ID

Une fois la commande validée, il ne sera plus possible d'ajouter une identité externe à votre organisation, que ce soit de manière délibérée ou accidentelle. En une seule commande vous avez éliminé le risque de rendre publiques non seulement les Buckets, mais aussi les datasets BigQuery, les Cloud Functions, Cloud Run, ainsi que vos topics Pub/Sub (ces produits sont par by-design partageables en public).

Vérifions maintenant l'effet de la règle : je vais essayer de rendre publique une bucket en donnant le droit le plus élevé (qui comprend la possibilité de supprimer la bucket) à allUsers.

J'obtiens le message d'erreur suivant :

Règle 2 - Enforce uniform bucket-level access : Attaquons maintenant la deuxième policy qui, je le rappelle, force l'utilisation du modèle d'autorisation uniforme (par opposition à fine-grained):

gcloud beta resource-manager org-policies enable-enforce constraints/storage.uniformBucketLevelAccess --organization $ORG_ID

Je veux créer une bucket avec le mode fine-grained, mais il est impossible de sélectionner cette option. Un message est affiché pour indiquer qu'une politique d'organisation l'interdit.

Dorénavant, les buckets auront des droits uniformes et il ne sera plus possible de mélanger les données publiques avec les données privées.

Enfin, une précaution par rapport à cette règle : certains services n'exportent pas leurs données dans des buckets avec un contrôle d'accès uniforme (lien).

Comme indiqué plus haut, il est toujours possible de surcharger les règles au niveau des folders ou des projets. Mais il est préférable de séparer les projets bénéficiant d'exceptions des autres projets en les mettant dans des folders différents.

Enfin, sachez que les organisation policies ne sont pas rétroactives. Si vous aviez déjà des buckets publiques, la règle ne va pas la fermer. Il nous faut un autre moyen pour les trouver et appliquer des remédiations.

Ce moyen s'appelle Security Command Center. Je vous recommande de l'activer dès que possible car il est gratuit dans sa version standard, et il vous offre une visibilité totale sur vos ressources cloud. La version standard est largement suffisante pour trouver les vulnérabilités les plus sévères. J’en parlerai probablement plus en détails dans un article futur.

Grâce à Security Command Center ou SCC, nous allons rechercher les buckets ouvertes au public :

Je veux afficher le nom des buckers et l'id du projet auquel elles appartiennent :

$ gcloud alpha scc findings list $ORG_ID \
 --filter="state=\"ACTIVE\" AND category=\"PUBLIC_BUCKET_ACL\"" \
 --field-mask="resource.name,resource.parentDisplayName"

---


---
finding:
  category: PUBLIC_BUCKET_ACL
  ...

resource:
  name: //storage.googleapis.com/xxx-project-a-bucket
  parentDisplayName: xxx-project-b
---
finding:
  category: PUBLIC_BUCKET_ACL
  ...
resource:

  name: //storage.googleapis.com/xxx-project-b-bucket
  parentDisplayName: xxx-project-b

De la même façon, je peux afficher la liste des buckets dont le contrôle d'accès est fine-grained :

gcloud alpha scc findings list $ORG_ID --filter="state=\"ACTIVE\" AND category=\"BUCKET_POLICY_ONLY_DISABLED\""

Enfin, Security Command Center vous offre une IHM riche à partir de laquelle vous pouvez faire les même recherches :

Conclusion

Les organisation policies est un des outils de sécurité qui permettent de fixer des règles en amont et de prévenir certaines erreurs. Il existe néanmoins d'autres outils qui interviennent à des niveaux différent du cycle de vie de votre projet. En voici quelques exemples :

• Utiliser l'infrastruction-as-code (Terraform, Deployment-Manager) et vérifier le code avant le déploiement avec des outils tels que Hashicorp Sentinel ou Open Policy Agent (OPA).

• VPC Service Control : est un mécanisme qui permet d'isoler les ressources de votre projet, en interdisant entrée et sortie vers l'extérieur, même avec des droits IAM adéquats.

• Le chiffrement des buckets avec vos propres clés ou avec des clés stockées chez un tiers de confiance. Même s'il y a un problème de configuration, sans la clé de déchiffrement, il est impossible de lire la donnée.

Références

Incident Report: TaskRouter JS SDK Security Incident - July 19, 2020 : https://www.twilio.com/blog/incident-report-taskrouter-js-sdk-july-2020

Restricting identities by domain : https://cloud.google.com/resource-manager/docs/organization-policy/restricting-domain

Security Command Center : https://cloud.google.com/security-command-center/

Terraform : Google Organization Policy : https://www.terraform.io/docs/providers/google/r/google_organization_policy.html