Bulletin de sécurité

Sélectionnez une version de la documentation :

Pour évaluer la stratégie de sécurité de vos déploiements de l'orchestrateur RPM AlloyDB Omni sur Red Hat Enterprise Linux (RHEL) et Rocky Linux, et planifier les mises à niveau, consultez les règles de sécurité, le champ d'application des failles et 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.

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.
  • 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, AlloyDB Omni version 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 tous les packages RPM de l'outil d'orchestration RPM AlloyDB Omni et de la base de données RPM publiés par rapport aux bases de données de failles NVD, Red Hat Security Data 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 un package RPM de base de données ou d'outil d'orchestration RPM AlloyDB Omni antérieur sont corrigées dans une version mineure ou un correctif ultérieur. Google applique des correctifs de sécurité à la dernière version mineure de la version majeure 18 de PostgreSQL compatible, ainsi qu'à la dernière version compatible de l'orchestrateur RPM AlloyDB Omni.
  • Packages d'OS hôte pour les déploiements RPM : lorsque vous déployez AlloyDB Omni à l'aide de l'outil d'orchestration RPM, AlloyDB Omni fournit le noyau de base de données PostgreSQL et les packages d'extensions groupés. Votre distribution Linux hôte gère les bibliothèques système telles que openssl-libs, glibc, libevent, systemd et le noyau Linux. Appliquez régulièrement les mises à jour de sécurité de l'OS hôte en exécutant sudo dnf update --security sur vos hôtes RHEL ou Rocky Linux.

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 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. L'outil d'orchestration RPM pour AlloyDB Omni et les packages RPM de base de données 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. 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.
Pour les déploiements de l'orchestrateur RPM sur RHEL ou Rocky Linux, le package de base de données alloydbomni18 est lié de manière dynamique aux bibliothèques OpenSSL 3 de l'OS hôte dans le package RPM openssl-libs et utilise le fournisseur FIPS OpenSSL RHEL 9 de l'hôte lorsque le mode FIPS est activé sur le noyau hôte. L'application des mises à jour de sécurité openssl-libs sur l'OS hôte corrige les failles TLS et X.509 de la couche externe tout en préservant la limite du fournisseur OpenSSL FIPS certifié.

Étapes suivantes