En tant que client AlloyDB Omni, vous êtes responsable de la configuration et de l'exploitation d'AlloyDB Omni pour vous assurer que vos charges de travail tirent le meilleur parti du service.
| intégrée | Responsabilité de Google | Responsabilité du client | |
|---|---|---|---|
| Matériel et hôte | Infrastructure physique | Indiquez la configuration minimale et recommandée, le cas échéant. | Provisionnez des serveurs physiques, des VM ou des appareils de périphérie tels que l'alimentation, le refroidissement et le matériel. |
| Système d'exploitation hôte | Indiquez la configuration minimale et recommandée, le cas échéant. | Gérez le noyau Linux, appliquez les correctifs de sécurité de l'OS et renforcez les nœuds hôtes. | |
| Kubernetes | Gestion des clusters | Indiquez la configuration minimale et recommandée, le cas échéant. | Gérez le cluster au quotidien, y compris les mises à niveau, en suivant les bonnes pratiques standards du secteur. |
| Stockage (CSI/PV) | Indiquez la configuration minimale et recommandée, le cas échéant. | Provisionnez la classe de stockage et gérez les appliances sous-jacentes. AlloyDB Omni nécessite un périphérique de bloc, alors assurez-vous de choisir une classe de périphérique de bloc. | |
| Mise en réseau (CNI) | Indiquez la configuration minimale et recommandée, le cas échéant. | Provisionner et gérer la couche réseau (par exemple, la mise en réseau des pods, les contrôleurs d'entrée, les équilibreurs de charge et les règles de pare-feu entre les nœuds). | |
| Contrôle des accès basé sur les rôles (RBAC) | Fournissez les comptes de service, les rôles et les liaisons de rôle requis pour l'opérateur Kubernetes AlloyDB Omni. | Appliquez ces règles de contrôle des accès basé sur les rôles (RBAC) au cluster et assurez-vous qu'elles sont conformes aux règles de sécurité internes. Pour accéder aux ressources AlloyDB Omni, créez des rôles RBAC et des liaisons de rôle supplémentaires. | |
| Gérer les secrets | Lisez les secrets Kubernetes standards pour provisionner des ressources, comme l'utilisateur postgres initial. |
Créez, sécurisez et faites pivoter les secrets Kubernetes dans le cluster. | |
| Gestion des certificats | Utilisez les secrets Kubernetes standards et cert-manager pour l'intégration des certificats. |
Installez, configurez et gérez le cycle de vie de cert-manager. |
|
| Logiciel de l'opérateur | Développement et publication | Développez la logique et les CRD de l'opérateur AlloyDB Omni, puis publiez les images de conteneurs, les charts Helm et les bundles OLM. | Aucune. Vous pouvez utiliser les artefacts stockés dans Artifact Registry pour vos déploiements. |
| Installation et cycle de vie | Fournissez la documentation et les artefacts de mise à niveau. |
|
|
| Moteur de la base de données | Binaire de base de données | Fournissez les images de conteneur AlloyDB Omni avec des optimisations propriétaires telles que le moteur de données en colonnes et l'accélération de l'IA. | Aucune. |
| Application de correctifs | Publiez des correctifs de sécurité et des mises à jour de versions mineures et majeures pour le moteur. Fournissez des instructions de mise à niveau. | Planifiez les mises à niveau dès que possible, en fonction de l'importance de chaque version. | |
| Gestion des utilisateurs |
|
|
|
| Gestion des données | Sauvegardes | Fournissez les CRD et la logique `BackupPlan` et `Backup` pour gérer les sauvegardes, qui sont gérées à l'aide de pgBackrest avec une intégration compatible avec S3. |
Configurez les plannings et la durée de conservation des sauvegardes, et provisionnez le bucket de stockage cible local, S3 ou Cloud Storage. |
| Haute disponibilité (HA) | Fournissez la logique de basculement automatique et les mécanismes de réparation. | Provisionnez suffisamment de nœuds et de zones pour fournir une cible de secours permettant de prendre en charge le basculement. | |
| Chiffrement (au repos) | Compatible avec le chiffrement transparent des données (TDE, Transparent Data Encryption). | Gérez le chiffrement de la couche de stockage pour vous assurer qu'il répond à vos exigences. | |
| Chiffrement (en transit) | Fournissez mTLS pour les composants d'opérateur internes et pour configurer TLS côté serveur pour les connexions utilisateur à la base de données. | Connectez-vous à la base de données à l'aide de clients TLS sécurisés et gérez l'infrastructure de certificats sous-jacente. | |
| Observabilité | Métriques | Exposez les métriques de la base de données interne à l'aide d'un point de terminaison compatible avec Prometheus. | Déployez et gérez le scraper à l'aide de Prometheus, d'Open Telemetry ou d'autres solutions compatibles et de leur pile de stockage. Surveillez l'état général du système. |
| Journalisation | Écrivez les journaux PostgreSQL et d'audit dans des fichiers sur le disque du conteneur, puis faites-les pivoter. | Déployez des collecteurs de journaux (Fluentd et Fluent Bit, par exemple) pour envoyer les journaux à un backend de stockage (Splunk ou ELK, par exemple). Assurez-vous que les collecteurs de journaux sont configurés pour conserver les journaux pendant au moins un mois (durée recommandée). | |
| Visualisation | Fournissez des exemples de tableaux de bord de métriques et de journaux pour surveiller les charges de travail standards. | Déployez et surveillez l'état de l'outil de visualisation, comme Grafana. Créez des tableaux de bord et intégrez-les à vos tâches opérationnelles quotidiennes. | |
| Alertes | Aucun | Gérez le pipeline d'alerte, par exemple l'intégration PagerDuty. | |
| Assistance | Dépannage | Fournir une assistance pour les bugs logiciels et les erreurs du moteur Pour bénéficier de cette assistance, vous devez disposer d'un abonnement à une licence. | Fournissez une assistance initiale grâce à la documentation et à la base de connaissances. Déboguer les problèmes liés à l'infrastructure. |
Sécurité et conformité FIPS
Pour sécuriser vos données, AlloyDB Omni utilise des modules de chiffrement validés FIPS (Federal Information Processing Standards) 140-2 ou 140-3. La conformité FIPS est une responsabilité partagée entre Google et le client.
Le schéma suivant montre comment la responsabilité de la conformité FIPS est répartie entre Google et le client dans les couches architecturales d'AlloyDB Omni.
Le tableau suivant décrit les limites et les responsabilités FIPS pour AlloyDB Omni :
| Couche limite FIPS | Responsabilité | Description |
|---|---|---|
| Matériel conforme à la norme FIPS | Client | Les composants matériels et cryptographiques physiques doivent être certifiés NIST et configurés dans un état approuvé par la norme FIPS. |
| OS des nœuds Kubernetes | Client | Le système d'exploitation hôte du nœud de calcul (RHEL, par exemple) doit s'exécuter en mode FIPS. L'état FIPS doit être vérifié (cat /proc/sys/crypto/fips_enabled renvoie 1). |
| Plan de contrôle Kubernetes | Client | Les composants du plan de contrôle tels que kubelet et les plug-ins de mise en réseau et de stockage doivent utiliser des modules cryptographiques validés par FIPS (par exemple, ceux créés avec Go-BoringCrypto). |
| Contrôleurs de l'opérateur AlloyDB Omni | Développée par Google, basée sur une image de base conforme à la norme FIPS (Red Hat UBI), avec la conformité FIPS activée sur le conteneur sur lequel la base de données s'exécute. | |
| Image de conteneur AlloyDB Omni | Utilise des bibliothèques cryptographiques conformes à la norme FIPS, comme BoringSSL, et applique des algorithmes approuvés par la norme FIPS pour le hachage des mots de passe (scram-sha-256) et les suites de chiffrement TLS. |
|
| Certificats provenant d'une CA personnalisée | Partagé | Les certificats numériques doivent respecter les normes FIPS concernant la puissance des clés et les algorithmes de signature. La chaîne de certificats doit remonter jusqu'à une autorité de certification racine conforme à la norme FIPS. |
Responsabilité partagée STIG
La DISA (Defense Information Systems Agency) publie des guides de mise en œuvre technique de sécurité (STIG, Security Technical Implementation Guides) pour établir des normes de cybersécurité et des exigences de renforcement pour les logiciels, les systèmes d'exploitation et les bases de données. Ces guides définissent des paramètres de sécurité spécifiques pour protéger les systèmes contre les failles et les cybermenaces.
Pour obtenir la liste complète des règles STIG, consultez Conformité STIG d'AlloyDB Omni.
Il est essentiel de renforcer votre environnement conformément aux exigences STIG pour obtenir une autorisation d'exploitation (ATO, Authorization to Operate) dans les secteurs gouvernementaux ou hautement sécurisés. Bien qu'AlloyDB Omni implémente de nombreux contrôles de sécurité au niveau de la base de données par défaut, la conformité complète à la STIG est une responsabilité partagée qui nécessite que le client configure et vérifie les paramètres au niveau de l'infrastructure.
Le tableau suivant liste tous les ID de failles STIG qui nécessitent une action, une validation ou une configuration de la part du client. Pour obtenir des informations complètes, consultez la liste de contrôle de la conformité du guide d'implémentation technique de sécurité PostgreSQL 9.x sur Red Hat Enterprise Linux (STIG).
| ID STIG ou SRG | Description du contrôle de sécurité | Comportement par défaut de la plate-forme et de l'opérateur | Action ou configuration requise du client |
|---|---|---|---|
| V-233535 | Alertez immédiatement l'équipe d'assistance en cas d'échec du journal d'audit. | Les diagnostics d'erreur standard sont écrits dans les conteneurs stdout et stderr. |
Le client doit configurer des métriques SIEM ou de transfert de journaux (par exemple, des alertes Splunk/Elastic) pour qu'elles se déclenchent en cas de baisse de l'ingestion. |
| V-233599 | Alertez le personnel d'assistance lorsque l'espace de stockage des journaux d'audit atteint 75% de sa capacité. | Les métriques du système de fichiers sont exposées via des points de terminaison Prometheus standards. | Le Client doit configurer des règles d'alerte dans Prometheus et Grafana pour informer l'assistance lorsque l'espace disque /obs/ dépasse 75%. |
| V-233610 | Déchargez les données d'audit dans un journal continu distinct. | Les journaux d'audit sont écrits de manière persistante dans le volume /obs/diagnostic/. |
Le client doit configurer un transmetteur de journaux (par exemple, FluentBit et Vector) pour diffuser en continu les fichiers journaux vers un SIEM central. |
| V-233603 | Ne faites confiance qu'aux certificats d'entité finale émis par l'infrastructure à clé publique (PKI) ou les autorités de certification (AC) approuvées. | L'opérateur utilise cert-manager pour configurer les configurations TLS locales. |
Le client doit fournir ses certificats PKI racine et CA intermédiaire à l'opérateur pour établir la chaîne de confiance. |
| V-233520 | Appliquez les autorisations d'accès logiques approuvées. | Rejette les mots de passe en texte brut et l'algorithme Message-Digest 5 (MD5). Autorise scram-sha-256 via SSL. |
Le client doit configurer les clients pour qu'ils utilisent SCRAM-SHA-256 avec sslmode=verify-full dans leurs chaînes de connexion. |
| V-233522 | Limitez les seuils de sessions simultanées par utilisateur. | Les rôles de base de données par défaut ont des limites infinies, bornées par max_connections. |
Le client doit modifier explicitement les limites de connexion (ALTER ROLE ... CONNECTION LIMIT) pour les rôles d'application personnalisés. |
| V-233584 | Utilisez une cryptographie approuvée par la NSA pour les informations classifiées au repos. | Le conteneur de base de données utilise des couches de base UBI9 sécurisées et renforcées. | Le client doit vérifier que le mode FIPS 140 est activé dans le noyau de l'hôte Kubernetes sous-jacent. |
| V-233515 | Intégrez-vous aux mécanismes d'authentification au niveau de l'organisation Active Directory (AD) et LDAP (Lightweight Directory Access Protocol). | L'opérateur est compatible avec les configurations d'authentification personnalisées. | Le client doit mapper les identités AD et LDAP dans la configuration du cluster de base de données. |
| V-233583 | Utilisez des modules cryptographiques validés par FIPS pour les hachages. | Le conteneur s'appuie sur les modules OpenSSL FIPS de l'hôte pour les fonctions de hachage. | Le client doit activer le mode FIPS sur les nœuds de VM hôtes. |
| V-233585 | Utilisez le chiffrement validé par la norme FIPS pour protéger les informations non classifiées. | Chiffre les communications et le stockage à l'aide de chiffrements compatibles avec FIPS. | Le client doit vérifier que les nœuds hôtes sont validés FIPS. |
| V-233619 | Utilisez des modules de chiffrement validés par la norme FIPS pour toutes les opérations. | Applique les binaires d'image de conteneur UBI9 compatibles avec FIPS. | Le client doit activer le mode FIPS sur le noyau hôte. |
| V-233623 | Assurez-vous que le SGBD s'exécute sur un hôte avec OpenSSL FIPS certifié. | Les pods de base de données s'appuient sur les configurations OpenSSL FIPS de l'hôte. | Le client doit vérifier que l'hôte OpenSSL correspond à la liste FIPS certifiée par le NIST. |
| V-233615 | Associez les identités authentifiées par PKI aux comptes utilisateur correspondants. | L'opérateur utilise une authentification par mot de passe SCRAM-SHA-256 sécurisée pour les identités. |
Si le client n'utilise pas la connexion directe par mot de passe, il doit mapper les rôles de l'annuaire organisationnel externe sur les rôles de la base de données. |
| V-233540 | Limitez le compte d'installation de la base de données aux utilisateurs autorisés uniquement. | Le conteneur limite les autorisations et l'exécution des fichiers à l'utilisateur postgres. |
Le client doit verrouiller l'accès au nœud hôte (SSH/Kubectl) pour empêcher tout accès non autorisé au terminal des pods. |