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 | Fournir les exigences minimales et recommandées, le cas échéant | Provisionner 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 (OS) | Fournir les exigences minimales et recommandées, le cas échéant | Gérer le noyau Linux, appliquer les correctifs de sécurité du système d'exploitation et renforcer les nœuds hôtes. | |
| Kubernetes | Gestion des clusters | Fournir les exigences minimales et recommandées, le cas échéant | Gérer le cluster au quotidien, y compris les mises à niveau, en suivant les bonnes pratiques standards du secteur. |
| Stockage (CSI/PV) | Fournir les exigences minimales et recommandées, le cas échéant | Provisionner la classe de stockage et gérer les appliances sous-jacentes. AlloyDB Omni nécessite un appareil de stockage en mode bloc. Veillez donc à choisir une classe d'appareils de stockage en mode bloc. | |
| Mise en réseau (CNI) | Fournir les exigences minimales et recommandées, 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) | Fournir les comptes de service, les rôles et les liaisons de rôle requis pour l'opérateur Kubernetes AlloyDB Omni. | Appliquer ces règles de contrôle des accès basé sur les rôles (RBAC) au cluster et s'assurer qu'elles sont conformes aux règles de sécurité internes. Pour accéder aux ressources AlloyDB Omni, créez des rôles et des liaisons de rôle RBAC 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 faire pivoter les secrets Kubernetes dans le cluster. | |
| Gestion des certificats | S'appuyer sur les secrets Kubernetes standards et cert-manager pour l'intégration des certificats. |
Installer, configurer et gérer le cycle de vie de cert-manager. |
|
| Logiciel de l'opérateur | Développement et publication | Développer la logique et les CRD de l'opérateur AlloyDB Omni, et publier des images de conteneurs, des charts Helm et des bundles OLM. | Aucune. Vous pouvez utiliser les artefacts stockés dans Artifact Registry pour vos déploiements. |
| Installation et cycle de vie | Fournir de la documentation et des artefacts de mise à niveau. |
|
|
| Moteur de base de données | Binaire de base de données | Fournir les images de conteneurs 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. Fournir des instructions de mise à niveau. | Planifier 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`, ainsi que la logique permettant de gérer les sauvegardes,
qui sont gérées à l'aide de pgBackrest avec une intégration compatible avec S3. |
Configurer les planifications et la conservation des sauvegardes, et provisionner 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. | Provisionner suffisamment de nœuds et de zones pour fournir une cible de secours afin de prendre en charge le basculement. | |
| Chiffrement (au repos) | Fournit une compatibilité avec le chiffrement transparent des données (TDE). | Gérer le chiffrement de la couche de stockage pour s'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. | Se connecter à la base de données à l'aide de clients TLS sécurisés et gérer l'infrastructure de certificats sous-jacente. | |
| Observabilité | Métriques | Exposer les métriques de base de données internes à l'aide d'un point de terminaison compatible avec Prometheus. | Déployer et gérer le scraper à l'aide de Prometheus, Open Telemetry 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 disque dans le conteneur, puis les faire pivoter. | Déployer des collecteurs de journaux (par exemple, Fluentd et Fluent Bit) pour envoyer les journaux à un backend de stockage (tel que Splunk ou ELK). S'assurer que les collecteurs de journaux sont configurés pour conserver les journaux pendant au moins un mois. | |
| Visualisation | Fournir des exemples de métriques et de tableaux de bord de journaux pour surveiller les charges de travail standards. | Déployer et surveiller l'état de l'outil de visualisation, tel que Grafana. Créer des tableaux de bord et les intégrer à vos tâches opérationnelles quotidiennes. | |
| Alertes | Aucune | Gérer le pipeline d'alertes, par exemple, l'intégration PagerDuty. | |
| Assistance | Dépannage | Fournir une assistance pour les bugs logiciels et les erreurs de moteur. Pour bénéficier de cette assistance, vous devez disposer d'un abonnement de 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é avec la norme FIPS
Pour sécuriser vos données, AlloyDB Omni utilise des modules cryptographiques validés par les normes FIPS (Federal Information Processing Standards) 140-2 ou 140-3. La conformité avec la norme FIPS est une responsabilité partagée entre Google et le client.
Le schéma suivant montre comment la responsabilité de la conformité avec la norme FIPS est répartie entre Google et le client sur les différentes couches architecturales d'AlloyDB Omni.
Le tableau suivant décrit les limites et les responsabilités de la norme FIPS pour AlloyDB Omni :
| Couche limite FIPS | Responsabilité | Description |
|---|---|---|
| Matériel conforme à la norme FIPS | Client | Le matériel physique et les composants cryptographiques doivent être certifiés NIST et configurés dans un état approuvé par la norme FIPS. |
| Système d'exploitation 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 et les plug-ins de mise en réseau et de stockage doivent utiliser des modules cryptographiques validés par la norme FIPS, par exemple, ceux 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 à la norme FIPS, telles que 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 autorité de certification personnalisée | Partagé | Les certificats numériques doivent respecter les normes FIPS en matière de force des clés et d'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 d'implémentation techniques 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é avec la norme STIG pour AlloyDB Omni.
Le renforcement de votre environnement conformément aux exigences STIG est essentiel pour obtenir une autorisation d'exploitation (ATO, Authorization to Operate) dans les secteurs hautement sécurisés ou gouvernementaux. 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é totale avec la norme 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 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 checklist de conformité avec le guide d'implémentation technique de sécurité (STIG) pour 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 du client |
|---|---|---|---|
| V-233535 | Alerter immédiatement le personnel d'assistance en cas d'échec du journal d'audit. | Les diagnostics d'erreur standards sont écrits dans stdout et stderr du conteneur. |
Le client doit configurer des métriques SIEM ou de transfert de journaux (par exemple, des alertes Splunk/Elastic) pour se déclencher lorsque l'ingestion diminue. |
| V-233599 | Alerter le personnel d'assistance lorsque le 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 /obs/ dépasse 75%. |
| V-233610 | Décharger les données d'audit vers un journal continu distinct. | Les journaux d'audit sont écrits de manière persistante dans le volume /obs/diagnostic/. |
Le client doit configurer un transféreur de journaux (par exemple, FluentBit et Vector) pour diffuser en continu les fichiers journaux vers un SIEM central. |
| V-233603 | Ne faire confiance qu'aux certificats d'entité finale émis par une infrastructure à clé publique (PKI) ou des autorités de certification (CA) 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édiaires à l'opérateur pour établir la chaîne de confiance. |
| V-233520 | Appliquer 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 sur 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 | Limiter les seuils de sessions simultanées par utilisateur. | Les rôles de base de données par défaut ont des limites infinies liées à 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é pour le noyau hôte Kubernetes sous-jacent. |
| V-233515 | S'intégrer 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 bases de données. |
| V-233583 | Utiliser 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 une cryptographie validée par la norme FIPS pour protéger les informations non classifiées. | Chiffre la communication 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 | Utiliser des modules cryptographiques validés par la norme FIPS pour toutes les opérations. | Applique les binaires d'image de conteneur UBI9 compatibles avec la norme FIPS. | Le client doit activer le mode FIPS sur le noyau hôte. |
| V-233623 | S'assurer 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'OpenSSL de l'hôte correspond à la liste FIPS certifiée par le NIST. |
| V-233615 | Mapper 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 de l'organisation externe aux rôles de la base de données s'il n'utilise pas la connexion directe par mot de passe. |
| V-233540 | Limiter le compte d'installation de la base de données aux seuls utilisateurs autorisés. | Le conteneur limite les autorisations de fichier et l'exécution à l'utilisateur postgres. |
Le client doit verrouiller l'accès aux nœuds hôtes (SSH/Kubectl) pour empêcher tout accès non autorisé au terminal des pods. |