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. | Provisionner des serveurs physiques, des VM ou des appareils de périphérie (alimentation, refroidissement et matériel, par exemple) |
| Système d'exploitation hôte (OS) | Indiquez la configuration minimale et recommandée, le cas échéant. | Gérer le noyau Linux, appliquer des correctifs de sécurité de l'OS et renforcer les nœuds hôtes. | |
| Kubernetes | Gestion des clusters | Indiquez la configuration minimale et recommandée, le cas échéant. | Gérer le cluster au quotidien, y compris les mises à niveau, en suivant les bonnes pratiques du secteur. |
| Stockage (CSI/PV) | Indiquez la configuration minimale et recommandée, le cas échéant. | Provisionner la classe de stockage et gérer les appareils sous-jacents. AlloyDB Omni nécessite un appareil de stockage en mode bloc. Veillez donc à choisir une classe d'appareil de stockage en mode 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ôles 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ôles supplémentaires. | |
| Gestion des secrets | Lire les secrets Kubernetes standards pour provisionner des ressources, telles que l'utilisateur postgres initial. |
Créer, sécuriser et effectuer la rotation des secrets Kubernetes dans le cluster | |
| Gestion des certificats | S'appuyer sur 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 de l'opérateur AlloyDB Omni et les CRD, puis publiez des images de conteneurs, des charts Helm et des bundles OLM. | Aucune. Vous pouvez utiliser des 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 base de données | Fichier 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 | Publier 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 la criticité de chaque version. | |
| Gestion des utilisateurs |
|
|
|
| Gestion des données | Sauvegardes | Fournir les CRD `BackupPlan` et `Backup` et la logique de gestion des sauvegardes, qui sont gérées à l'aide de pgBackrest avec une intégration compatible avec S3. |
Configurez les planifications et la conservation des sauvegardes, puis provisionnez le bucket de stockage cible local, S3 ou Cloud Storage. |
| Haute disponibilité (HA) | Fournir 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) | Fournit une compatibilité avec le chiffrement transparent des données (TDE). | Gérez le chiffrement de la couche de stockage pour vous assurer qu'il répond à vos exigences. | |
| Chiffrement (en transit) | Fournir mTLS pour les composants d'opérateur internes et configurer TLS côté serveur pour les connexions utilisateur-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'OpenTelemetry ou d'autres solutions compatibles et de leur pile de stockage. Surveiller l'état général du système. |
| Journalisation | Écrire les journaux PostgreSQL et d'audit dans des fichiers sur le disque du conteneur, et les faire tourner. | Déployez des collecteurs de journaux (par exemple, Fluentd et Fluent Bit) pour envoyer les journaux vers un backend de stockage (comme Splunk ou ELK). Assurez-vous que les collecteurs de journaux sont configurés pour conserver les journaux pendant au moins un mois. | |
| Visualisation | Fournir 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, tel que Grafana. Créez des tableaux de bord et intégrez-les à vos tâches opérationnelles quotidiennes. | |
| Alertes | Aucun | Gérer le pipeline d'alertes (par exemple, l'intégration de PagerDuty) | |
| Assistance | Dépannage | Fournir une assistance pour les bugs logiciels et les erreurs du moteur. Pour obtenir cette assistance, vous devez disposer d'un abonnement à une licence. | Fournir une assistance initiale via 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 par les normes 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 sur les couches architecturales d'AlloyDB Omni.
Le tableau suivant décrit les limites et les responsabilités FIPS pour AlloyDB Omni :
| Couche de limites FIPS | Responsabilité | Description |
|---|---|---|
| Matériel conforme à la norme FIPS | Client | Le matériel physique et les composants cryptographiques doivent être certifiés par le 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 (par exemple, RHEL) 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, ainsi que les plug-ins de mise en réseau et de stockage, doivent utiliser des modules cryptographiques validés par la norme FIPS (par exemple, créés avec Go-BoringCrypto). |
| Contrôleurs de l'opérateur AlloyDB Omni | Développé par Google, basé 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 aux normes FIPS, telles que BoringSSL, et applique des algorithmes approuvés par les normes FIPS pour le hachage des mots de passe (scram-sha-256) et les suites de chiffrement TLS. |
|
| Certificats d'une autorité de certification personnalisée | Partagé | Les certificats numériques doivent respecter les normes FIPS concernant la force de la clé et les algorithmes de signature. La chaîne de certificats doit remonter à une autorité de certification racine conforme à la norme FIPS. |
Responsabilité partagée des STIG
La Defense Information Systems Agency (DISA) publie des guides d'implémentation technique de sécurité (STIG) 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.
Le renforcement de votre environnement conformément aux exigences STIG est essentiel pour obtenir une autorisation d'exploitation (ATO) dans des secteurs hautement sécurisés ou gouvernementaux. Bien qu'AlloyDB Omni implémente par défaut de nombreux contrôles de sécurité au niveau de la base de données, la conformité totale au 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 répertorie tous les ID de faille STIG qui nécessitent une action, une validation ou une configuration de la part du client. Pour en savoir plus, consultez la checklist de conformité au guide de mise en œuvre technique de sécurité (STIG) de PostgreSQL 9.x sur Red Hat Enterprise Linux.
| 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 de la part du client |
|---|---|---|---|
| V-233535 | Alertez immédiatement l'équipe d'assistance en cas d'échec des journaux d'audit. | Les diagnostics d'erreur standard sont écrits dans les conteneurs stdout et stderr. |
Le client doit configurer les métriques SIEM ou de transfert de journaux (par exemple, les alertes Splunk/Elastic) pour qu'elles se déclenchent lorsque l'ingestion diminue. |
| V-233599 | Alerter le personnel d'assistance lorsque l'espace de stockage 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 avertir l'assistance lorsque l'espace disque de /obs/ dépasse 75%. |
| V-233610 | Déchargez les données d'audit vers un service de journalisation continue distinct. | Les journaux d'audit sont écrits de manière persistante dans le volume /obs/diagnostic/. |
Le client doit configurer un redirecteur 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 une infrastructure à clé publique (PKI) ou par des 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 CA racine et intermédiaire PKI à l'opérateur pour établir la chaîne de confiance. |
| V-233520 | Appliquer les autorisations d'accès logique approuvées. | Rejette les mots de passe en texte brut et l'algorithme MD5 (Message-Digest algorithm 5). 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 limité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 | Utiliser 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é sur le noyau de l'hôte Kubernetes sous-jacent. |
| V-233515 | Intégration aux mécanismes d'authentification Active Directory (AD) et LDAP (Lightweight Directory Access Protocol) au niveau de l'organisation. | 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 bases de données. |
| V-233583 | Utilisez des modules cryptographiques validés par la norme FIPS pour les hachages. | Le conteneur s'appuie sur les modules FIPS OpenSSL 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 | Utiliser un 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 la norme FIPS. | Le client doit vérifier que les nœuds hôtes sont validés par la norme 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 compatibles avec UBI9 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 FIPS OpenSSL 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 | Mappez les identités authentifiées par PKI aux comptes utilisateur associés. | L'opérateur utilise l'authentification par mot de passe SCRAM-SHA-256 sécurisée pour les identités. |
Le client doit mapper les rôles de l'annuaire organisationnel externe aux rôles de la base de données s'il n'utilise pas la connexion directe par mot de passe. |
| V-233540 | Limitez l'accès au compte d'installation de la base de données aux seuls utilisateurs autorisés. | Le conteneur limite les autorisations de fichiers et l'exécution à 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. |