Bulletin de sécurité

Sélectionnez une version de la documentation :

Pour évaluer la stratégie de sécurité de vos déploiements AlloyDB Omni Kubernetes et planifier les mises à niveau du plan de contrôle et du cluster de bases de données, consultez les règles de sécurité, l'architecture de l'opérateur, le contrôle des accès basé sur les rôles (RBAC) et les contextes de sécurité, ainsi que les pratiques de divulgation des failles et expositions courantes (CVE) sur cette page.

Pour recevoir les dernières notes de version et mises à jour de sécurité d'AlloyDB Omni dans votre lecteur de flux, abonnez-vous au flux des notes de version d'AlloyDB Omni.

Architecture de l'opérateur et contextes de sécurité

AlloyDB Omni sur Kubernetes dissocie le plan de contrôle Kubernetes des pods du moteur de base de données qui traitent les requêtes d'application :

  • Composants du plan de contrôle et de l'opérateur : chaque version de l'opérateur AlloyDB Omni comprend 10 images de conteneur basées sur Red Hat Universal Base Image 9 (UBI 9) :
    • operator/fleet-operator : contrôleur Kubernetes au niveau du parc qui rapproche les ressources personnalisées DBCluster et du parc
    • operator/local-operator : contrôleur Kubernetes au niveau de l'instance qui gère les cycles de vie des pods de base de données locaux et communique uniquement avec le serveur d'API Kubernetes interne au cluster de confiance.
    • alloydbomni-operator-catalog et alloydbomni-operator-olm-bundle : index du catalogue Red Hat OpenShift Operator Lifecycle Manager (OLM) et images de métadonnées de bundle déclaratives
    • operator/dbinit et operator/backupinit : conteneurs d'initialisation éphémères pour les workflows d'amorçage, de sauvegarde et de restauration de la base de données
    • operator/alloydbomni-monitor (remplace monitoring-agent), operator/g-pgbouncer, operator/logrotate et operator/node-manager : conteneurs side-car et de gestion des nœuds associés pour les vérifications d'état, le regroupement des connexions, la rotation des journaux et la gestion du stockage
  • RBAC et contextes de sécurité : l'opérateur AlloyDB Omni utilise des autorisations Kubernetes Role et ClusterRole limitées pour rapprocher les ressources personnalisées dans les espaces de noms cibles, et exécute les charges de travail du plan de contrôle et du side-car avec des contextes de sécurité de conteneur restreints.
  • Pods du moteur de base de données : les instances de base de données gérées par l'opérateur exécutent les images de conteneur du noyau de base de données AlloyDB Omni autonome. Pour vérifier les versions de noyau de base de données compatibles avec votre version d'opérateur, consultez Choisir des versions compatibles de l'opérateur Kubernetes et du cluster de bases de données.

Filtrage par champ d'application et niveau de gravité

Pour concentrer les workflows de correction sur les avis de sécurité exploitables et réduire le bruit du scanner, les résumés des failles AlloyDB Omni et les journaux CVE détaillés suivent les règles de signalement suivantes :

  • Filtrage strict des niveaux de gravité "Critique" et "Élevé" : les tableaux récapitulatifs des failles et les journaux CVE détaillés ne signalent que les CVE de gravité "Critique" et "Élevé" en fonction des niveaux de gravité de la National Vulnerability Database (NVD) et des fournisseurs en amont. Les avis de gravité faible et moyenne sont exclus des nombres récapitulatifs et des journaux détaillés.
  • Séparation des rapports sur le plan de contrôle et le noyau de la base de données : les bulletins du plan de contrôle sous AlloyDB Omni sur Kubernetes signalent les failles spécifiques aux 10 images de conteneur de l'opérateur AlloyDB Omni et du side-car.
  • Isolation spécifique à la version : les journaux CVE détaillés sont organisés en sous-pages dédiées par version de publication à l'aide d'un schéma standardisé à quatre colonnes (CVE ID, Severity, Impacted images et Mitigated in). Dans chaque journal de publication, les failles corrigées dans une version ultérieure affichent la version de publication de correction dans la colonne Mitigated in.

Évaluation des failles et règle d'actualisation

Google analyse régulièrement toutes les images de conteneurs AlloyDB Omni publiées par rapport aux bases de données de failles NVD, Red Hat Security Data, Debian Security Tracker et Go. Google actualise les bulletins de sécurité AlloyDB Omni lorsque de nouvelles versions sont publiées :

  • CVE corrigées : les failles présentes dans une image de conteneur du plan de contrôle de l'opérateur AlloyDB Omni antérieure sont corrigées dans une version ultérieure de l'opérateur. Google applique des correctifs de sécurité à la dernière version compatible de l'opérateur AlloyDB Omni et à la dernière version mineure des versions majeures compatibles de PostgreSQL 18, 17, 16 et 15.
  • Images de conteneurs remplacées : lorsqu'une nouvelle version de l'opérateur AlloyDB Omni corrige des failles et expositions courantes d'une version antérieure, Google marque les condensés d'images de conteneurs remplacés comme obsolètes. Déployez toujours les images de l'opérateur et de l'agent du plan de contrôle qui correspondent à la dernière version compatible.

Conformité FIPS 140-3 et application de correctifs CVE

Pour maintenir la conformité avec les normes FIPS (Federal Information Processing Standards) 140-3 tout en corrigeant en continu les failles de sécurité dans les versions mineures et les correctifs, AlloyDB Omni dissocie ses modules cryptographiques internes validés par FIPS de ses bibliothèques cryptographiques et de protocoles externes :

  • Validation FIPS pour les modules cryptographiques : le programme de validation des modules cryptographiques (CMVP) du National Institute of Standards and Technology (NIST) certifie un module ou un fournisseur cryptographique interne figé et émet un numéro de certificat. La modification d'une instruction à l'intérieur de cette limite validée modifie la somme de contrôle d'intégrité du code d'authentification de message basé sur le hachage (HMAC) intégré et invalide le certificat.
  • Conformité FIPS pour les déploiements : un déploiement AlloyDB Omni fonctionne en mode conforme à la norme FIPS 140-3 lorsqu'il s'exécute sur un OS hôte compatible FIPS, tel que Red Hat Enterprise Linux (RHEL) 9 avec le fichier /proc/sys/crypto/fips_enabled défini sur 1. Dans ce mode, le déploiement achemine toutes les opérations cryptographiques pertinentes pour la sécurité via un module validé par la norme FIPS avec des tests de réponse connus (KAT) et des vérifications d'intégrité HMAC activés. Il applique également les versions approuvées de Transport Layer Security (TLS) (TLS 1.2 ou version ultérieure), les suites de chiffrement approuvées et la méthode d'authentification par mot de passe scram-sha-256. Les images de conteneur de l'opérateur AlloyDB Omni et les images de conteneur de base de données Red Hat UBI 9 (-ubi9) sont compatibles avec la norme FIPS. Votre organisation est chargée d'activer et de vérifier le mode FIPS sur l'OS hôte sous-jacent. Pour en savoir plus, consultez Sécurité et conformité FIPS.
  • Application de correctifs CVE en dehors de la limite FIPS : les bibliothèques d'analyse de protocoles et de mise en réseau, telles que les machines d'état TLS, l'analyse de certificats X.509 et ASN.1, HTTP/2 et les E/S réseau, résident dans la couche externe en dehors de la limite du module FIPS figé. Comme ces composants se trouvent en dehors de la limite validée, Google corrige les CVE de la couche externe dans les versions mineures et les correctifs sans modifier le module cryptographique interne ni invalider sa certification NIST CMVP. Seule une faille dans l'implémentation de la primitive cryptographique de bas niveau elle-même nécessite une mise à jour du module FIPS interne.
Le tableau suivant décrit les piles cryptographiques des images de conteneur du plan de contrôle et du side-car de l'opérateur AlloyDB Omni, y compris la limite FIPS interne figée et la couche cryptographique et de protocole externe qui est corrigée d'une version à l'autre :

Pile cryptographique Images de conteneurs du plan de contrôle Binaires Module ou fournisseur interne validé par la norme FIPS Couche cryptographique et de protocole externe
FIPS intégré à Go avec le paramètre de compilation GOFIPS140=v1.0.0 operator/fleet-operator
operator/local-operator
operator/logrotate
operator/node-manager
operator/dbinit
operator/backupinit 		/operator
/local
/logrotate
/nodemgr
dbinit
dbdaemon
credfetcher
backupinit
backupdaemon 		Module cryptographique Go v1.0.0, certificat NIST CMVP n° 5247 Packages de bibliothèque standards Go crypto/tls, crypto/x509 et net/http, packages Go externes tels que golang.org/x/crypto, ainsi que l'environnement d'exécution et le compilateur Go
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer Fournisseur FIPS OpenSSL RHEL 9 /lib64/libssl.so.3 et /lib64/libcrypto.so.3 dans le package RPM openssl-libs, et le binaire C pgbouncer
BoringSSL et BoringCrypto operator/alloydbomni-monitor /monitoring_agent Binaire Go créé avec boringcrypto Module Google BoringCrypto (BCM) Packages Go crypto/tls, crypto/x509 et net/http pour monitoring_agent

Étapes suivantes