Responsabilité partagée d'AlloyDB Omni

Sélectionnez une version de la documentation :

Cette page décrit vos responsabilités, en tant que client AlloyDB Omni, et les responsabilités de Google lorsque vous utilisez l'option de déploiement de l'outil d'orchestration RPM.

En tant que client AlloyDB Omni, vous êtes responsable de la configuration et de l'exploitation d'AlloyDB Omni afin que vos charges de travail tirent le meilleur parti du service.

Matrice de responsabilités partagées

Le tableau suivant récapitule les responsabilités de Google et du client pour chaque couche d'un déploiement de l'outil d'orchestration RPM AlloyDB Omni :

Couche 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, y compris l'alimentation, le refroidissement et le matériel.
Système d'exploitation hôte 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 (tels que RHEL 9 ou Rocky Linux 9).
Composants d'infrastructure et de système d'exploitation Stockage Fournir les exigences minimales et recommandées, le cas échéant. Provisionner des disques locaux ou des volumes SAN. AlloyDB Omni nécessite un périphérique de bloc configuré avec un système de fichiers compatible tel que XFS ou ext4.
Mise en réseau Fournir les exigences minimales et recommandées, le cas échéant. Provisionner et gérer la couche réseau (telle que le routage IP, les équilibreurs de charge et les règles de pare-feu à l'aide de firewalld ou iptables) pour ouvrir les ports requis tels que 5432 pour PostgreSQL et 2379 et 2380 pour etcd.
Contrôle des accès hôte Fournir les comptes de service et les rôles requis pour les composants de l'outil d'orchestration AlloyDB Omni. Gérer l'accès SSH, les droits sudo, les stratégies SELinux et les comptes utilisateur Linux pour les aligner sur vos stratégies de sécurité internes.
Gestion des secrets Lire les variables standards et les fichiers d'inventaire pour provisionner des ressources, telles que l'utilisateur postgres initial. Stocker de manière sécurisée les mots de passe, les clés SSH et les jetons utilisés pour l'orchestration Ansible et l'accès à la base de données.
Gestion des certificats Fournir des options de configuration pour l'intégration des certificats. Générer, distribuer et gérer le cycle de vie des certificats TLS (Transport Layer Security) et SSL sur les machines hôtes.
Logiciel d'orchestration Développement et publication Développer l'outil d'orchestration AlloyDB Omni, y compris les collections CLI et Ansible, et publier des packages RPM. Aucune. Vous pouvez utiliser des artefacts du dépôt Yum fourni pour vos déploiements.
Installation et cycle de vie Fournir de la documentation, des artefacts RPM et des modèles d'inventaire de déploiement.

Vérifier la compatibilité avant l'installation.

Suivre les instructions pour installer ou mettre à niveau AlloyDB Omni à l'aide de la CLI de l'outil d'orchestration alloydbctl ou des playbooks Ansible.
Moteur de base de données Binaire de base de données Fournir les packages RPM 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

Provisionner les utilisateurs administratifs initiaux.

Provisionner le super-utilisateur postgres visible par l'utilisateur.

Fournir des instructions pour l'intégration de LDAP (Lightweight Directory Access Protocol) et d'Active Directory (AD).

Fournir le mot de passe du super-utilisateur initial.

Créer et gérer tous les autres rôles et utilisateurs.
Gestion des données Sauvegardes Fournir l'automatisation pour gérer les sauvegardes à l'aide de pgBackRest avec une intégration compatible S3. Configurer les planifications et la conservation des sauvegardes, et provisionner le bucket cible local, S3 ou Cloud Storage.
Haute disponibilité (HA) Fournir la logique de basculement automatique et les mécanismes de réparation à l'aide de etcd et du gestionnaire de cluster. Provisionner suffisamment de nœuds (tels qu'un nœud de contrôle, des nœuds etcd et des nœuds de base de données principaux et de secours) pour prendre en charge les architectures de basculement et de haute disponibilité.
Chiffrement au repos Prendre en charge les déploiements sur des volumes chiffrés au niveau des blocs. Gérer le chiffrement de la couche de stockage, tel que Linux Unified Key Setup (LUKS) et dm-crypt, pour répondre à vos exigences de sécurité.
Chiffrement en transit Configurer TLS côté serveur pour les connexions utilisateur-base de données et les communications de cluster internes. 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, 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 d'audit et PostgreSQL dans des fichiers sur disque et gérer la rotation. Déployer des collecteurs de journaux, tels que Fluent Bit ou Vector, pour envoyer les journaux à un backend de stockage tel que Splunk ou la pile ELK. Conserver les journaux pendant au moins un mois.
Visualisation Fournir des exemples de métriques et de tableaux de bord pour surveiller les charges de travail standards. Déployer et surveiller l'état d'un 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'aide d'une 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. Fournir une assistance initiale par le biais de la documentation et de 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 certifiés FIPS (Federal Information Processing Standards) 140-2 ou 140-3. La conformité FIPS est une responsabilité partagée entre Google et le client, comme décrit dans le tableau suivant :

Couche de 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 hôte Client Le système d'exploitation de la VM ou de l'hôte bare metal (tel que RHEL 9) doit s'exécuter en mode FIPS. Vérifiez que la commande cat /proc/sys/crypto/fips_enabled renvoie 1.
Plan de contrôle de l'outil d'orchestration Client Le nœud de contrôle exécutant l'outil d'orchestration Ansible ou la CLI doit utiliser une configuration de système d'exploitation certifiée FIPS.
Composants de l'outil d'orchestration Google Développé par Google, distribué sous forme de RPM compatibles avec un système d'exploitation de base compatible avec la norme FIPS, gérant de manière sécurisée les opérations de cluster.
Fichiers binaires de base de données Google Lier aux modules cryptographiques OpenSSL hôtes certifiés FIPS et appliquer 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 d'une autorité de certification personnalisée Partagé Les certificats numériques doivent respecter les normes FIPS en matière de force de clé et d'algorithmes de signature. La chaîne de certificats doit remonter à une autorité de certification racine conforme à la norme FIPS.

Responsabilité partagée STIG

La DISA (Defense Information Systems Agency) publie des 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.

Le renforcement de votre environnement conformément aux exigences STIG est essentiel pour obtenir une autorisation d'exploitation (ATO) 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 à 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 les ID de vulnérabilité 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é au guide d'implémentation technique de sécurité (STIG) 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. Le client doit configurer les métriques SIEM ou de transfert de journaux 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 du journal 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 répertoire de journaux local. Le client doit configurer un transfert de journaux 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'outil d'orchestration utilise des configurations TLS locales. Le client doit fournir ses certificats CA racine et intermédiaire de l'infrastructure à clé publique 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 à l'aide de 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. Les packages RPM s'appuient sur des bibliothèques RHEL 9 sécurisées et renforcées. Le client doit vérifier que le mode FIPS 140 est activé sur le noyau Linux de l'hôte sous-jacent.
V-233515 S'intégrer aux mécanismes d'authentification au niveau de l'organisation AD et LDAP. La base de données 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 certifiés FIPS pour les hachages. Les RPM s'appuient sur les modules FIPS OpenSSL hôtes pour les fonctions de hachage. Le client doit activer le mode FIPS sur le système d'exploitation hôte.
V-233585 Utiliser un chiffrement certifié 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 machines hôtes sont certifiées FIPS.
V-233619 Utiliser des modules cryptographiques certifiés FIPS pour toutes les opérations. Applique les binaires RPM compatibles avec la norme FIPS. Le client doit activer le mode FIPS sur le noyau hôte.
V-233623 Exécuter le SGBD sur un hôte avec un module OpenSSL certifié FIPS. La base de données s'appuie sur les configurations FIPS OpenSSL hôtes. Le client doit vérifier que le module OpenSSL hôte correspond à la liste FIPS certifiée NIST.
V-233615 Mapper les identités authentifiées par l'infrastructure à clé publique aux comptes utilisateur associés. La base de données 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 Restreindre le compte d'installation de la base de données aux seuls utilisateurs autorisés. Le RPM limite les autorisations de fichier et l'exécution à l'utilisateur postgres. Le client doit verrouiller l'accès au nœud hôte, par exemple avec des restrictions SSH, pour empêcher tout accès non autorisé au terminal des VM.