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'a pas vocation à décrire toutes les opérations de votre environnement cloud, mais présente des décisions liées aux recommandations architecturales et aux ressources 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 besoins fondamentaux peuvent évoluer 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 section 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 différents 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 si la création d'un réseau VPC est nécessaire
- Les rôles IAM à créer pour le
project-service-accountinitial créé par le pipeline - Les étiquettes de projet à appliquer
- Le dossier dans lequel le projet est déployé
- Le compte de facturation à utiliser
- Décider s'il faut ajouter le 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 la 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érer 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 règles d'autorisation qui accordent des rôles bénéficiant de droits trop élevés. Concevez un processus permettant d'examiner régulièrement les recommandations ou d'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 qu'une équipe est en charge de la gestion des ressources réseau, tandis que des équipes distinctes sont responsables du déploiement des ressources d'infrastructure de charge de travail. Lorsque les équipes responsables des charges 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 réseau centralisées nécessaires au déploiement des applications. Par exemple, vous pouvez instaurer un processus qui permet à une équipe responsable des charges de travail de solliciter 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 permettant au trafic de transiter entre les ressources dotées des tags, et délègue les rôles IAM nécessaires pour utiliser les tags à l'équipe responsable des charges de travail.
Optimiser 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, Firewall Insights ou l'outil de recommandation de projets dormants formulent des recommandations proactives pour renforcer votre stratégie de sécurité.
Concevez un processus permettant d'examiner régulièrement les recommandations ou d'appliquer automatiquement des recommandations dans vos pipelines de déploiement. Déterminez quelles recommandations relèvent de la responsabilité d'une équipe centrale et lesquelles incombent aux propriétaires de charge de travail. Appliquez ensuite les rôles IAM pour accéder aux recommandations en conséquence.
Accorder des exceptions aux règles d'administration
Le plan établit un ensemble de contraintes liées aux règles d'administration, recommandées pour la majorité des clients dans la plupart des scénarios. Toutefois, des cas d'utilisation légitimes peuvent nécessiter des exceptions limitées aux règles d'administration que vous appliquez de façon générale.
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 des conséquences très dommageables. Dans la plupart des cas, il est préférable d'utiliser des alternatives plus sécurisées aux clés de compte de service pour l'authentification. Cependant, il existe des cas d'utilisation spécifiques qui ne peuvent utiliser que des clés de compte de service, comme un serveur sur site nécessitant un accès aux services Google Cloud et ne pouvant pas utiliser la fédération d'identité de charge de travail. Dans ce cas, vous pouvez décider d'accorder une exception à cette règle, sous réserve de mettre en place d'autres contrôles compensatoires, tels que les bonnes pratiques de gestion des clés de compte de service.
Vous devez donc élaborer un processus permettant aux charges de travail de demander une exception aux règles, et veiller à ce que les décisionnaires chargés de l'octroi des exceptions possèdent les connaissances techniques requises pour évaluer le cas d'utilisation et déterminer si d'autres contrôles doivent être mis 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 à la règle d'administration sous certaines conditions en définissant un tag qui octroie une exception ou applique une règle spécifique, puis en l'appliquant à des projets et 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 à partir du 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 créer des exceptions au périmètre qui autorisent les chemins d'accès de votre choix.
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'a pas vocation à remplacer ou à dupliquer des règles d'autorisation pour un contrôle d'accès précis à des projets ou à des ressources individuels. Lorsque vous créez et concevez un périmètre, 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 entre les services 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 nécessaires pour les opérations prévues.
Pour adopter VPC Service Controls, évaluez les éléments suivants :
- Cas d'utilisation nécessitant VPC Service Controls
Déterminer si les services Google Cloud requis sont compatibles avec VPC Service Controls
Façon de configurer l'accès "bris de glace" pour modifier le périmètre en cas de perturbation de vos pipelines d'automatisation
Suivi des bonnes pratiques pour activer VPC Service Controls afin de concevoir et d'implémenter votre périmètre
Une fois le périmètre activé, nous vous recommandons de concevoir un processus permettant d'ajouter de nouveaux projets au périmètre approprié de manière cohérente, et un processus permettant de créer des exceptions lorsque les développeurs rencontrent un nouveau cas d'utilisation refusé par la configuration actuelle de votre périmètre.
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 effectuer de tests. Pour les ressources de charge de travail, cette approche est facilitée par des environnements distincts (développement, hors production et production). Cependant, certaines ressources de l'organisation ne disposent pas d'environnements distincts pour faciliter les tests.
Pour les modifications apportées 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 préconisons le déploiement d'une infrastructure immuable via le pipeline de base, le pipeline d'infrastructure et le pipeline d'application, il est également recommandé de n'accorder aux développeurs que l'accès direct à une machine virtuelle via SSH ou RDP dans des cas d'utilisation spécifiques ou 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 dans la mesure du possible. Cette approche s'appuie sur les services Google Cloud gérés pour implémenter le contrôle des accès, la gestion du cycle de vie des comptes, la validation en deux étapes et les journaux d'audit. Si vous devez autoriser l'accès via des clés SSH dans les métadonnées ou des identifiants RDP, il est impératif de gérer le cycle de vie de ces identifiants et de les stocker en dehors de Google Cloud.
Dans tous les cas, un utilisateur disposant d'un accès SSH ou RDP à une VM peut poser 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 droits 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 exploite délibérément les droits du compte de service.
Limiter les dépassements de budget en planifiant des alertes budgétaires
Le plan implémente les bonnes pratiques introduites dans Framework d'architecture Google Cloud : optimisation des coûts pour la gestion des coûts, y compris les suivantes :
Utilisez un seul compte de facturation pour tous les projets de l'entreprise.
Attribuez à chaque projet une étiquette de métadonnées
billingcodepermettant 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 des alertes de facturation. Le plan crée des alertes budgétaires 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 évidente 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é.
Selon votre cas d'utilisation, 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é au lieu de définir des budgets précis pour chaque projet. Nous vous conseillons également de déléguer la configuration du budget et des alertes 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
Dans la console, vous pouvez consulter 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-logs. Les enregistrements de facturation exportés vous permettent d'allouer des coûts dans des dimensions personnalisées, telles que vos centres de coûts internes, en fonction de métadonnées d'étiquette 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 étiquette 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 SIEM existant
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 exploiter ces signaux.
Si vous devez agréger des journaux dans tous les environnements cloud et sur site dans un SIEM existant, déterminez comment ingérer les journaux à partir du projet prj-c-logging et les résultats de Security Command Center dans vos outils et processus existants. Vous pouvez créer une seule exportation englobant tous les journaux et résultats si une seule équipe est chargée de surveiller la sécurité dans l'ensemble de votre environnement. Vous pouvez également créer plusieurs exportations filtrées correspondant à l'ensemble des journaux et des résultats requis pour plusieurs équipes aux responsabilités distinctes.
Si les volumes et les coûts associés aux journaux sont rédhibitoires, vous pouvez éviter la duplication en stockant les journaux et les résultats Google Cloud uniquement dans Google Cloud. Dans ce cas, assurez-vous que vos équipes existantes disposent d'un accès et d'une formation appropriés pour utiliser les journaux et les résultats directement dans Google Cloud.
- Pour les journaux d'audit, créez des vues de journaux afin de donner accès à des équipes spécifiques à un sous-ensemble de journaux provenant de votre bucket de journaux centralisé. Cette approche est préférable à la réplication dans plusieurs buckets, ce qui entraînerait une augmentation des 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 en continu votre bibliothèque de contrôles
Le plan commence par effectuer des contrôles de référence pour détecter et éviter les menaces. Nous vous recommandons d'examiner 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 :
| Contrôles de règles appliqués par le plan | Conseils pour étendre ces contrôles |
|---|---|
Security Command Center détecte les failles et les menaces provenant de plusieurs sources de sécurité. |
Définissez des modules personnalisés pour Security Health Analytics et des modules personnalisés pour Event Threat Detection. |
Le service de règles d'administration applique un ensemble recommandé de contraintes liées aux règles d'administration sur les services Google Cloud. |
Appliquez des contraintes supplémentaires à partir de la liste prédéfinie de contraintes disponibles ou créez des contraintes personnalisées. |
La règle Open Policy Agent (OPA) valide le code dans le pipeline de base pour les configurations acceptables avant le déploiement. |
Développez d'autres contraintes basées sur les instructions fournies dans GoogleCloudPlatform/policy-library. |
Les alertes sur les métriques basées sur les journaux et les métriques de performances configurent les métriques basées sur les journaux pour vous informer des modifications apportées aux stratégies et configurations IAM de certaines ressources sensibles. |
Créez d'autres métriques et règles d'alerte basées sur les journaux pour les événements de journaux qui ne devraient pas se produire dans votre environnement. |
Une solution personnalisée d'analyse automatisée des journaux interroge régulièrement les journaux afin de détecter des activités suspectes et crée des résultats Security Command Center. |
Rédigez d'autres requêtes pour créer des résultats pour les événements de sécurité que vous souhaitez surveiller, en utilisant l'analyse des journaux de sécurité comme référence. |
Une solution personnalisée pour répondre aux modifications d'éléments crée des résultats Security Command Center et peut automatiser des actions correctives. |
Créez d'autres flux d'inventaire des éléments cloud pour surveiller les modifications apportées à des types d'éléments spécifiques et écrivez des fonctions Cloud supplémentaires avec une logique personnalisée pour répondre aux cas de non-respect des règles. |
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 propose le chiffrement au repos par défaut pour tout le contenu client, mais aussi Cloud Key Management Service (Cloud KMS) pour vous offrir davantage de contrôle 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 Comment satisfaire les exigences de conformité de 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, 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 d'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, validez le 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 humains, sauf dans les situations de type "bris de glace". Dans ce scénario, veillez à ne pas accorder de rôles IAM permettant d'afficher ces secrets à des utilisateurs ou à des groupes.
Le plan fournit un 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, gérer les secrets séparément dans chaque environnement ou choisir 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" pour les comptes disposant de privilèges élevés
Bien que nous vous recommandions de gérer les modifications des ressources de base via l'IaC avec contrôle des versions déployé par le pipeline de base, des scénarios exceptionnels ou d'urgence peuvent se produire, nécessitant un accès privilégié pour modifier directement votre environnement. Nous vous conseillons de planifier des comptes de type "bris de glace" (parfois appelés comptes d'appels 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 certains exemples d'utilisation des comptes de type "bris de glace".
| Objectif du bris de glace | Description |
|---|---|
Super-administrateur | Accès d'urgence au rôle de super-administrateur utilisé avec Cloud Identity, par exemple pour résoudre les problèmes liés à la fédération d'identité ou à l'authentification multifacteur (MFA). |
Administrateur de l'organisation |
Accès d'urgence au rôle Administrateur de l'organisation, qui peut ensuite accorder l'accès à tout autre rôle IAM dans l'organisation. |
Administrateur du pipeline de base | Accès d'urgence permettant de modifier les ressources de votre projet CI/CD sur Google Cloud et dans le dépôt Git externe en cas d'interruption de l'automatisation du pipeline de base. |
Opérations ou ingénierie SRE |
Une équipe chargée des opérations ou de l'ingénierie SRE a besoin d'un accès privilégié pour répondre aux pannes ou aux incidents. Cela peut inclure des tâches telles que le redémarrage des VM ou la restauration des données. |
Votre mécanisme pour autoriser l'accès "bris de glace" dépend des procédures et des outils existants que vous avez mis en place, mais en 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 disposant de 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 aux administrateurs. Par exemple, la développeuse 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é limité dans le temps, qui permet à un développeur de s'octroyer des rôles disposant de privilèges plus élevés.
Quel que soit le mécanisme utilisé, réfléchissez à la manière dont vous gérez les questions suivantes :
- 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 plusieurs 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 fractionner les opérations de sorte qu'une personne détienne les identifiants et une autre le jeton MFA.
- Comment auditez-vous les accès en mode "bris de glace" et créez-vous des alertes les concernant ? 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 courantes une fois l'incident terminé ?
Pour les tâches d'élévation de 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 avoir recours à une é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).