Bulletin de sécurité

Pour évaluer la stratégie de sécurité de vos déploiements AlloyDB Omni autonomes et planifier les mises à niveau de la base de données, consultez les règles de sécurité, le champ d'application des failles, les pratiques de divulgation et les limites des modules cryptographiques FIPS (Federal Information Processing Standards) 140-3 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.

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.
  • Rapports distincts pour le noyau de la base de données et le plan de contrôle : les bulletins de sécurité AlloyDB Omni autonomes signalent les failles spécifiques aux images de conteneur du noyau de la base de données (18.x, 17.x, 16.x et 15.x). Les avis concernant l'opérateur Kubernetes et le conteneur side-car sont suivis séparément dans lebulletin de sécurité AlloyDB Omni sur Kubernetes.
  • 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 de kernel de base de données AlloyDB Omni antérieure sont corrigées dans une version mineure ou un correctif ultérieur. Google applique des correctifs de sécurité à la dernière version mineure des versions majeures de PostgreSQL compatibles 18, 17, 16 et 15.
  • Images de conteneurs remplacées : lorsqu'une nouvelle version d'AlloyDB Omni corrige des CVE d'une version antérieure, Google marque les condensés d'images de conteneurs remplacés comme obsolètes. Extrayez toujours les images de kernel de base de données 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 noyau de base de données Red Hat Universal Base Image 9 (UBI 9) (-ubi9) sont compatibles avec FIPS. Votre organisation est chargée d'activer et de vérifier le mode FIPS sur l'OS hôte sous-jacent.
  • 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 noyau de base de données AlloyDB Omni Red Hat UBI 9 (-ubi9), 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 Image de conteneur du noyau de la base de données Binaires Module ou fournisseur interne validé par la norme FIPS Couche cryptographique et de protocole externe
BoringSSL et BoringCrypto alloydbomni (-ubi9) Binaires C postgres et pgbackrest Module Google BoringCrypto (BCM) Packages BoringSSL libssl et non-BCM libcrypto x509, asn1, pem et bio pour postgres et pgbackrest
OpenSSL 3 Couche d'OS de base Red Hat UBI 9 de alloydbomni (-ubi9) Bibliothèques et utilitaires partagés de l'OS de base Fournisseur FIPS OpenSSL RHEL 9 /lib64/libssl.so.3 et /lib64/libcrypto.so.3 dans le package RPM openssl-libs

Étapes suivantes