Bonnes pratiques en matière d'opérations

Cette section présente les opérations que vous devez prendre en compte lorsque vous déployez et exploitez des charges de travail supplémentaires dans votre environnement Google Cloud. Cette section n'est pas censée être exhaustive de toutes les opérations de votre environnement cloud, mais présente des décisions liées aux recommandations et aux ressources architecturales déployées par le plan.

Mettre à jour des ressources de base

Bien que le plan constitue un point de départ avisé pour votre environnement de base, vos exigences de base peuvent augmenter au fil du temps. Après le déploiement initial, vous pouvez ajuster les paramètres de configuration ou créer des services partagés qui seront utilisés par toutes les charges de travail.

Pour modifier les ressources de base, nous vous recommandons d'effectuer toutes les modifications via le pipeline de base. Consultez la page Stratégie d'embranchement pour découvrir le processus d'écriture de code, de fusion et de déclenchement des pipelines de déploiement.

Choisir les attributs des nouveaux projets de charge de travail

Lorsque vous créez des projets via le module de fabrique de projets du pipeline d'automatisation, vous devez configurer divers attributs. Votre processus de conception et de création de projets pour les nouvelles charges de travail doit inclure les décisions suivantes:

• Les API Google Cloud à activer
• Le VPC partagé à utiliser ou s'il faut créer un réseau VPC
• Les rôles IAM à créer pour le project-service-account initial créé par le pipeline
• Les libellés de projet à appliquer
• Le dossier dans lequel le projet est déployé
• Le compte de facturation à utiliser
• L'ajout ou non du projet à un périmètre VPC Service Controls
• Décider s'il faut configurer un budget et un seuil d'alerte de facturation pour le projet

Pour obtenir une documentation de référence complète sur les attributs configurables pour chaque projet, consultez les variables d'entrée pour la fabrique de projets dans le pipeline d'automatisation.

Gérez les autorisations à grande échelle

Lorsque vous déployez des projets de charge de travail sur votre base, vous devez réfléchir à la manière dont vous accorderez l'accès aux développeurs et aux consommateurs prévus de ces projets. Nous vous recommandons d'ajouter des utilisateurs à un groupe géré par votre fournisseur d'identité existant, de synchroniser les groupes avec Cloud Identity, puis d'appliquer des rôles IAM aux groupes. Gardez toujours à l'esprit le principe du moindre privilège.

Nous vous recommandons également d'utiliser l'outil de recommandation IAM pour identifier les stratégies d'autorisation qui accordent des rôles possédant trop de privilèges. Concevez un processus pour examiner régulièrement les recommandations ou appliquer automatiquement des recommandations dans vos pipelines de déploiement.

Coordonner les modifications entre l'équipe de mise en réseau et l'équipe de développement

Les topologies de réseaux déployées par le plan supposent que vous avez une équipe responsable de la gestion des ressources réseau et des équipes distinctes responsables du déploiement des ressources d'infrastructure de charge de travail. Lorsque les équipes de charge de travail déploient une infrastructure, elles doivent créer des règles de pare-feu pour autoriser les chemins d'accès prévus entre les composants de leur charge de travail, mais elles ne sont pas autorisées à modifier les stratégies de pare-feu réseau elles-mêmes.

Planifiez la collaboration entre les équipes pour coordonner les modifications apportées aux ressources de mise en réseau centralisées nécessaires au déploiement des applications. Par exemple, vous pouvez concevoir un processus dans lequel une équipe de charge de travail demande des tags pour ses applications. L'équipe de mise en réseau crée ensuite les tags et ajoute des règles à la stratégie de pare-feu réseau qui permet le trafic entre les ressources avec les tags, et délègue les rôles IAM pour utiliser les tags à l'équipe de la charge de travail.

Optimisez votre environnement avec le portefeuille Active Assist

En plus de l'outil de recommandation IAM, Google Cloud fournit le portefeuille de services Active Assist pour émettre des recommandations sur la façon d'optimiser votre environnement. Par exemple, les insights sur le pare-feu ou l'outil de recommandation de projets dormants fournissent des recommandations exploitables pour renforcer votre stratégie de sécurité.

Concevez un processus permettant d'examiner régulièrement les recommandations ou d'appliquer automatiquement celles-ci dans vos pipelines de déploiement. Décidez quelles recommandations doivent être gérées par une équipe centrale et quelles sont les responsabilités des propriétaires de charge de travail, et appliquez les rôles IAM pour accéder aux recommandations en conséquence.

Accorder des exceptions aux règles d'administration

Le plan applique un ensemble de contraintes de règle d'administration qui sont recommandées à la plupart des clients dans la plupart des scénarios, mais des cas d'utilisation légitimes peuvent nécessiter des exceptions limitées aux règles d'administration que vous appliquez.

Par exemple, le plan applique la contrainte iam.disableServiceAccountKeyCreation. Cette contrainte est un contrôle de sécurité important, car une fuite de clé de compte de service peut avoir un impact négatif important et la plupart des scénarios doivent utiliser des alternatives plus sécurisées aux clés de compte de service pour s'authentifier. Toutefois, certains cas d'utilisation ne peuvent s'authentifier qu'avec une clé de compte de service, comme un serveur sur site qui nécessite l'accès aux services Google Cloud et ne peut pas utiliser la fédération d'identité de charge de travail. Dans ce scénario, vous pouvez décider d'autoriser une exception à cette règle, à condition que d'autres contrôles compensatoires, tels que les bonnes pratiques de gestion des clés de compte de service, soient appliqués.

Par conséquent, vous devez concevoir un processus permettant aux charges de travail de demander une exception aux règles, et vous assurer que les décideurs chargés de l'octroi des exceptions ont les connaissances techniques nécessaires pour valider le cas d'utilisation et consulter si des contrôles supplémentaires doivent être en place pour compenser cette situation. Lorsque vous accordez une exception à une charge de travail, modifiez la contrainte de règle d'administration de manière aussi restrictive que possible. Vous pouvez également ajouter des contraintes conditionnelles à une règle d'administration en définissant un tag qui accorde une exception ou une mesure d'application pour la règle, puis en l'appliquant aux projets et aux dossiers.

Protéger vos ressources avec VPC Service Controls

Le plan permet de préparer votre environnement pour VPC Service Controls en séparant les réseaux de base et restreints. Toutefois, le code Terraform n'active pas VPC Service Controls par défaut, car cette activation peut être un processus perturbateur.

Un périmètre refuse l'accès aux services Google Cloud restreints depuis le trafic provenant de l'extérieur du périmètre, y compris la console, les stations de travail des développeurs et le pipeline de base utilisé pour déployer les ressources. Si vous utilisez VPC Service Controls, vous devez concevoir des exceptions au périmètre qui autorisent les chemins d'accès souhaités.

Un périmètre VPC Service Controls est destiné aux contrôles d'exfiltration entre votre organisation Google Cloud et des sources externes. Le périmètre n'est pas destiné à remplacer ou à dupliquer des stratégies d'autorisation pour un contrôle d'accès précis à des projets ou à des ressources individuels. Lorsque vous concevez un périmètre et mettez en œuvre son architecture, nous vous recommandons d'utiliser un périmètre unifié commun pour réduire les coûts de gestion.

Si vous devez concevoir plusieurs périmètres pour contrôler le trafic de service de manière précise au sein de votre organisation Google Cloud, nous vous recommandons de définir clairement les menaces traitées par une structure de périmètre plus complexe et les chemins d'accès entre périmètres qui sont nécessaires pour les opérations prévues.

Pour adopter VPC Service Controls, évaluez les éléments suivants:

• Quels sont les cas d'utilisation nécessitant VPC Service Controls.

• Si les services Google Cloud requis sont compatibles avec VPC Service Controls.

• Comment configurer l'accès "bris de glace" pour modifier le périmètre en cas de perturbation de vos pipelines d'automatisation.

• Comment utiliser les bonnes pratiques pour activer VPC Service Controls afin de concevoir et de mettre en œuvre votre périmètre.

Une fois le périmètre activé, nous vous recommandons de concevoir un processus pour ajouter de nouveaux projets de manière cohérente au périmètre approprié, et un processus de conception d'exceptions lorsque les développeurs reçoivent un nouveau cas d'utilisation refusé par votre configuration du périmètre actuelle.

Tester les modifications à l'échelle de l'organisation dans une organisation distincte

Nous vous recommandons de ne jamais déployer de modifications en production sans tester. Pour les ressources de charge de travail, cette approche est facilitée par des environnements distincts pour le développement, hors production et la production. Cependant, certaines ressources de l'organisation ne disposent pas d'environnements distincts pour faciliter les tests.

Pour les modifications au niveau de l'organisation ou pour d'autres modifications susceptibles d'affecter les environnements de production, telles que la configuration entre votre fournisseur d'identité et Cloud Identity, envisagez de créer une organisation distincte à des fins de test.

Contrôler l'accès à distance aux machines virtuelles

Comme nous vous recommandons de déployer une infrastructure immuable via le pipeline de base, le pipeline d'infrastructure et le pipeline d'application, nous vous recommandons également de n'accorder aux développeurs que l'accès direct à une machine virtuelle via SSH ou RDP pour dans des cas d'utilisation exceptionnels.

Pour les scénarios nécessitant un accès à distance, nous vous recommandons de gérer l'accès des utilisateurs à l'aide de OS Login lorsque cela est possible. Cette approche utilise les services Google Cloud gérés pour appliquer le contrôle des accès, la gestion du cycle de vie du compte, la validation en deux étapes et la journalisation d'audit. Si vous devez autoriser l'accès via des clés SSH dans les métadonnées ou des identifiants RDP, vous devez gérer le cycle de vie des identifiants et stocker les identifiants de manière sécurisée en dehors de Google Cloud.

Dans tous les cas, un utilisateur disposant d'un accès SSH ou RDP à une VM peut présenter un risque d'élévation des privilèges. Vous devez donc concevoir votre modèle d'accès en conséquence. L'utilisateur peut exécuter du code sur cette VM avec les privilèges du compte de service associé ou interroger le serveur de métadonnées pour afficher le jeton d'accès utilisé pour authentifier les requêtes API. Il peut alors s'agir d'une élévation de privilèges si vous ne souhaitez pas que l'utilisateur utilise les droits du compte de service.

Limiter les dépassements de budget en planifiant des alertes budgétaires

Le plan met en œuvre les bonnes pratiques introduites dans le framework d'architecture Google Cloud: optimisation des coûts pour la gestion des coûts, y compris les éléments suivants :

• Utilisez un seul compte de facturation pour tous les projets de base de l'entreprise.

• Attribuez à chaque projet un libellé de métadonnées billingcode permettant d'allouer les coûts entre les centres de coûts.

• Définissez des budgets et des seuils d'alerte.

Il vous incombe de planifier les budgets et de configurer les alertes de facturation. Le plan crée des alertes de budget pour les projets de charge de travail lorsque les dépenses prévues sont sur le point d'atteindre 120% du budget. Cette approche permet à une équipe centrale d'identifier et de limiter les incidents de dépenses excessives importantes. Les augmentations inattendues et importantes des dépenses sans cause claire peuvent être un indicateur d'un incident de sécurité et doivent être examinées du point de vue du contrôle des coûts et de la sécurité.

Au lieu d'utiliser des budgets précis pour chaque projet, vous pouvez définir un budget basé sur le coût d'un dossier dans son ensemble ou pour tous les projets liés à un centre de coûts donné en fonction de votre cas de figure. Nous vous recommandons également de déléguer le paramètre de budget et d'alerte aux propriétaires de charge de travail qui peuvent définir un seuil d'alerte plus précis pour leur surveillance quotidienne.

Pour obtenir des conseils sur la création de fonctionnalités FinOps, y compris sur la prévision des budgets pour les charges de travail, consultez la page Premiers pas avec FinOps sur Google Cloud.

Allouer des coûts entre les centres de coûts internes

La console vous permet d'afficher vos rapports de facturation afin d'afficher et de prévoir les coûts dans plusieurs dimensions. En plus des rapports prédéfinis, nous vous recommandons d'exporter les données de facturation vers un ensemble de données BigQuery du projet prj-c-billing-export. Les enregistrements de facturation exportés vous permettent d'allouer des coûts sur des dimensions personnalisées, telles que vos centres de coûts internes, en fonction de métadonnées de libellé de projet telles que billingcode.

La requête SQL suivante est un exemple de requête permettant de comprendre les coûts de tous les projets regroupés par libellé de projet billingcode.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Pour configurer cette exportation, consultez la page Exporter des données Cloud Billing vers BigQuery.

Si vous avez besoin d'une comptabilité interne ou d'un rejet de débit entre les centres de coûts, il vous incombe d'intégrer les données obtenues à partir de cette requête dans vos processus internes.

Ingérer les résultats des contrôles de détection dans votre solution SIEM existante

Bien que les ressources de base vous aident à configurer des destinations agrégées pour les journaux d'audit et les résultats de sécurité, il vous incombe de décider comment utiliser et utiliser ces signaux.

Si vous devez agréger des journaux dans tous les environnements cloud et sur site dans une solution SIEM existante, décidez comment ingérer les journaux à partir duprj-c-logging projet et les résultats de Security Command Center dans vos outils et processus existants. Vous pouvez créer une seule exportation pour tous les journaux et résultats si une seule équipe est chargée de surveiller la sécurité dans l'ensemble de votre environnement, ou vous pouvez créer plusieurs exportations filtrées en fonction de l'ensemble de journaux et de résultats nécessaire pour plusieurs équipes avec des responsabilités différentes.

Par ailleurs, si le volume et les coûts des journaux sont rédhibitoires, vous pouvez éviter la duplication en ne conservant les journaux et les résultats Google Cloud que dans Google Cloud. Dans ce scénario, assurez-vous que vos équipes existantes disposent d'un accès et d'une formation appropriés pour travailler avec les journaux et les résultats directement dans Google Cloud.

• Pour les journaux d'audit, concevez des vues de journaux pour accorder l'accès à un sous-ensemble de journaux de votre bucket de journaux centralisé à des équipes individuelles, plutôt que de les dupliquer dans plusieurs buckets, ce qui augmente les coûts de stockage des journaux.
• Pour les résultats de sécurité, attribuez des rôles au niveau du dossier et du projet pour Security Command Center afin de permettre aux équipes d'afficher et de gérer les résultats de sécurité uniquement pour les projets dont elles sont responsables, directement dans la console

Développer votre bibliothèque de contrôles en continu

Le plan commence par un contrôle des détections et des menaces. Nous vous recommandons de vérifier ces contrôles et d'ajouter des contrôles supplémentaires en fonction de vos besoins. Le tableau suivant récapitule les mécanismes d'application des règles de gouvernance et comment les étendre à vos exigences supplémentaires:

Ces contrôles peuvent évoluer à mesure que vos exigences et votre maturité sur Google Cloud évoluent.

Gérer des clés de chiffrement avec Cloud Key Management Service

Google Cloud fournit un chiffrement au repos par défaut pour tout le contenu client, mais fournit également Cloud Key Management Service (Cloud KMS) pour vous fournir des contrôles supplémentaires sur vos clés de chiffrement pour les données au repos. Nous vous recommandons de déterminer si le chiffrement par défaut est suffisant, ou si vous devez gérer vous-même les clés à l'aide de Cloud KMS. Pour en savoir plus, consultez la section Décider comment répondre aux exigences de conformité concernant le chiffrement au repos.

Le plan fournit un projet prj-c-kms dans le dossier commun et un projet prj-{env}-kms dans chaque dossier d'environnement pour la gestion centralisée des clés de chiffrement. Cette approche permet à une équipe centrale d'auditer et de gérer les clés de chiffrement utilisées par les ressources des projets de charge de travail, afin de répondre aux exigences réglementaires et de conformité.

Selon votre modèle opérationnel, vous pouvez préférer une seule instance de projet centralisée de Cloud KMS sous le contrôle d'une seule équipe, vous préférez peut-être gérer les clés de chiffrement séparément dans chaque environnement ou choisir plusieurs instances distribuées afin que la responsabilité des clés de chiffrement puisse être déléguée aux équipes appropriées. Modifiez l'exemple de code Terraform si nécessaire pour l'adapter à votre modèle opérationnel.

Vous pouvez éventuellement appliquer des règles d'administration des clés de chiffrement gérées par le client (CMEK) pour exiger que certains types de ressources nécessitent toujours une clé CMEK et que seules les clés CMEK provenant d'une liste d'autorisation de projets approuvés puissent être utilisées.

Stocker et auditer les identifiants de l'application avec Secret Manager

Nous vous recommandons de ne jamais procéder au commit de secrets sensibles (clés API, mots de passe et certificats privés, par exemple) dans les dépôts de code source. À la place, procédez au commit du secret à l'aide de Secret Manager et attribuez le rôle IAM Accesseur de secrets Secret Manager à l'utilisateur ou au compte de service qui doit accéder au secret. Nous vous recommandons d'attribuer le rôle IAM à un seul secret, et non à tous les secrets du projet.

Dans la mesure du possible, vous devez générer automatiquement des secrets de production dans les pipelines CI/CD et les rendre inaccessibles aux utilisateurs, sauf dans les situations de type "bris de glace". Dans ce scénario, veillez à ne pas accorder de rôles IAM pour afficher ces secrets à des utilisateurs ou à des groupes.

Le plan fournit un seul projet prj-c-secrets dans le dossier commun et un projet prj-{env}-secrets dans chaque dossier d'environnement pour la gestion centralisée des secrets. Cette approche permet à une équipe centrale d'auditer et de gérer les secrets utilisés par les applications afin de répondre aux exigences réglementaires et de conformité.

Selon votre modèle opérationnel, vous pouvez préférer une seule instance centralisée de Secret Manager sous le contrôle d'une seule équipe ou gérer les secrets séparément dans chaque environnement, ou vous pouvez préférer plusieurs instances distribuées de Secret Manager afin que chaque équipe de charge de travail puisse gérer ses propres secrets. Modifiez l'exemple de code Terraform si nécessaire pour l'adapter à votre modèle opérationnel.

Planifier l'accès "bris de glace" aux comptes à privilèges élevés

Bien que nous vous recommandions de gérer les modifications des ressources de base via un IaC contrôlé par une version et déployé par le pipeline de base, vous pouvez avoir des scénarios exceptionnels ou d'urgence nécessitant un accès privilégié pour modifier directement votre environnement. Nous vous recommandons de planifier des comptes de type "bris de glace" (parfois appelés comptes d'appel d'urgence ou comptes d'urgence) disposant d'un accès hautement privilégié à votre environnement en cas d'urgence ou de défaillance des processus d'automatisation.

Le tableau suivant décrit quelques exemples d'utilisation des comptes de type "bris de glace".

Votre mécanisme pour autoriser le mode "bris de glace" dépend des outils et des procédures existants que vous avez mis en place, mais voici quelques exemples:

• Utilisez vos outils existants pour la gestion des accès privilégiés afin d'ajouter temporairement un utilisateur à un groupe prédéfini avec des rôles IAM à privilèges élevés ou utilisez les identifiants d'un compte à privilèges élevés.
• Préprovisionnez des comptes destinés uniquement à l'administrateur. Par exemple, le développeur Dana peut avoir l'identité dana@example.com pour une utilisation quotidienne et admin-dana@example.com pour un accès en mode "bris de glace".
• Utilisez une application telle que l'accès privilégié avec le juste-à-temps, qui permet à un développeur de s'élever à des rôles plus privilégiés.

Quel que soit le mécanisme utilisé, réfléchissez à la manière dont vous gérez les questions suivantes sur un plan opérationnel :

• Comment concevez-vous le champ d'application et la précision de l'accès en mode "bris de glace" ? Par exemple, vous pouvez concevoir un mécanisme de type "bris de glace" différent pour différentes unités commerciales afin de vous assurer qu'elles ne peuvent pas se perturber les unes les autres.
• Comment votre mécanisme empêche-t-il les abus ? Avez-vous besoin d'approbations ? Par exemple, vous pouvez avoir des opérations fractionnées où une personne détient les identifiants et une autre personne le jeton MFA.
• Comment auditez-vous des accès en mode "bris de glace" et créez-vous des alertes ? Par exemple, vous pouvez configurer un module Event Threat Detection personnalisé pour créer un résultat de sécurité lorsqu'un compte de type "bris de glace" prédéfini est utilisé.
• Comment supprimer l'accès "bris de glace" et reprendre les opérations normales une fois l'incident terminé ?

Pour les tâches d'élévation des privilèges courantes et le rollback des modifications, nous vous recommandons de concevoir des workflows automatisés permettant à un utilisateur d'effectuer l'opération sans nécessiter d'élévation de privilèges pour son identité utilisateur. Cette approche peut contribuer à réduire les erreurs humaines et à améliorer la sécurité.

Pour les systèmes nécessitant une intervention régulière, l'automatisation du correctif peut être la meilleure solution. Google encourage les clients à adopter une approche de production sans contact pour effectuer toutes les modifications de production à l'aide de l'automatisation, de proxys sécurisés ou du mode "bris de glace" audité. Google fournit des livres sur l'ingénierie SRE pour les clients qui souhaitent adopter l'approche SRE de Google.

Étapes suivantes

• Découvrez comment déployer le plan (document suivant de cette série).