עדכון אבטחה דחוף

בוחרים גרסת תיעוד:

כדי להעריך את מצב האבטחה של פריסות AlloyDB Omni העצמאיות ולתכנן שדרוגים של מסדי נתונים, כדאי לעיין במדיניות האבטחה, בהיקף נקודות החולשה, בשיטות החשיפה ובגבולות המודול הקריפטוגרפי של Federal Information Processing Standards (FIPS) 140-3 בדף הזה:

כדי לקבל את עדכוני האבטחה ונתוני הגרסאות האחרונים של AlloyDB Omni בקורא הפידים, הירשמו לפיד של נתוני הגרסאות של AlloyDB Omni.

סינון לפי היקף וחומרה

כדי למקד את תהליכי העבודה לתיקון בהמלצות אבטחה שניתן לפעול לפיהן ולצמצם את הרעש של הסורק, סיכומי נקודות החולשה ויומני ה-CVE המפורטים של AlloyDB Omni פועלים לפי מדיניות הדיווח הבאה:

  • סינון מחמיר של חומרת סיכון קריטית וגבוהה: טבלאות סיכום של נקודות חולשה ודוחות מפורטים של יומני CVE מדווחים רק על נקודות חולשה קריטיות וגבוהות, על סמך דירוגי החומרה של National Vulnerability Database (NVD)‎ ושל ספקים במעלה הזרם. התראות ברמת חומרה נמוכה ובינונית לא נכללות בסיכומים וביומנים המפורטים.
  • דיווח נפרד על ליבת מסד הנתונים ומישור הבקרה: עדכוני אבטחה דחופים עצמאיים של AlloyDB Omni מדווחים על נקודות חולשה ספציפיות לקובצי האימג' של קונטיינר ליבת מסד הנתונים (18.x,‏ 17.x,‏ 16.x ו-15.x). ההמלצות לגבי אופרטור Kubernetes וקונטיינר משני (sidecar) מנוהלות בנפרד בבעדכון האבטחה הדחוף של AlloyDB Omni ב-Kubernetes.
  • הפרדה לפי גרסה: יומני CVE מפורטים מאורגנים בדפי משנה ייעודיים לכל גרסת הפצה, באמצעות סכימה סטנדרטית של 4 עמודות (CVE ID,‏ Severity,‏ Impacted images ו-Mitigated in). בכל יומן הפצה, חולשות אבטחה שתוקנו בהפצה הבאה מוצגות בתור גרסת ההפצה שבה הן תוקנו בעמודה Mitigated in.

מדיניות הערכת נקודות חולשה ורענון

‫Google סורקת באופן קבוע את כל קובצי האימג' של קונטיינרים של AlloyDB Omni שפורסמו, בהשוואה למאגרי המידע של נקודות חולשה NVD, ‏ Red Hat Security Data, ‏ Debian Security Tracker ו-Go. ‫Google מרעננת את עדכוני האבטחה הדחופים של AlloyDB Omni כשמתפרסמות גרסאות חדשות:

  • ‫CVEs שתוקנו: נקודות חולשה שהיו קיימות בקובץ אימג' של קונטיינר הליבה של מסד הנתונים של AlloyDB Omni, טופלו בגרסה משנית או בתיקון באגים מאוחרים יותר. ‫Google מחילה תיקוני אבטחה על גרסת המשנה האחרונה של הגרסאות הראשיות הנתמכות של PostgreSQL‏: 18,‏ 17,‏ 16 ו-15.
  • קובצי אימג' של קונטיינרים שהוחלפו: כשגרסה חדשה של AlloyDB Omni מפחיתה את החשיפה ל-CVE מגרסה קודמת, Google מסמנת את תקצירי קובצי האימג' של הקונטיינרים שהוחלפו ככאלה שהוצאו משימוש. תמיד צריך למשוך קובצי אימג' של ליבת מסד הנתונים שתואמים לגרסה הנתמכת האחרונה.

תאימות ל-FIPS 140-3 ותיקון CVE

כדי לשמור על תאימות לתקן Federal Information Processing Standards (FIPS) 140-3, ובמקביל להמשיך לתקן נקודות חולשה באבטחה בגרסאות משניות ובתיקוני באגים, ב-AlloyDB Omni יש הפרדה בין המודולים הקריפטוגרפיים הפנימיים שאושרו על ידי FIPS לבין הספריות הקריפטוגרפיות וספריות הפרוטוקולים החיצוניות:

  • אימות FIPS למודולים קריפטוגרפיים: התוכנית לאימות מודולים קריפטוגרפיים (CMVP) של המכון הלאומי לתקנים וטכנולוגיה (NIST) מאשרת מודול או ספק קריפטוגרפי פנימי קפוא ומנפיקה מספר אישור. שינוי של הוראה כלשהי בתוך הגבול המאומת הזה משנה את סיכום הביקורת (checksum) של קוד אימות ההודעות המבוסס על גיבוב (HMAC) שמוטמע בו, ומבטל את תוקף האישור.
  • תאימות לפריסות של FIPS: פריסה של AlloyDB Omni פועלת במצב תואם ל-FIPS 140-3 כשהיא פועלת במערכת הפעלה מארחת שתומכת ב-FIPS, כמו Red Hat Enterprise Linux (RHEL) 9, כשהקובץ /proc/sys/crypto/fips_enabled מוגדר ל-1. במצב הזה, הפריסה מנתבת את כל הפעולות הקריפטוגרפיות שקשורות לאבטחה דרך מודול מאומת FIPS, עם בדיקות KAT (בדיקות תשובה ידועה) ובדיקות תקינות של HMAC שמופעלות בהפעלה. הוא גם אוכף גרסאות מאושרות של Transport Layer Security ‏(TLS) – גרסה 1.2 ואילך, סט אלגוריתמים להצפנה (cipher suite) מאושרים ושיטת אימות הסיסמה של scram-sha-256. קובצי אימג' של קונטיינר ליבה של מסד נתונים (-ubi9) של Red Hat Universal Base Image 9 (UBI 9)‎ מוכנים ל-FIPS, והארגון שלכם אחראי להפעיל ולאמת את מצב FIPS במערכת ההפעלה המארחת הבסיסית.
  • תיקון CVE מחוץ לגבולות FIPS: ניתוח פרוטוקולים וספריות רשת, כמו מכונות מצב של TLS, ניתוח אישורי X.509 ו-ASN.1,‏ HTTP/2 וקלט/פלט של רשת, נמצאים בשכבה החיצונית מחוץ לגבולות מודול FIPS הקפוא. מכיוון שהרכיבים האלה נמצאים מחוץ לגבולות המאומתים, Google מתקנת את נקודות החולשה והחשיפה (CVE) בשכבה החיצונית בגרסאות משניות ובתיקוני באגים, בלי לשנות את המודול הקריפטוגרפי הפנימי או לבטל את אישור ה-NIST CMVP שלו. רק אם יש נקודת חולשה בתוך ההטמעה של הפרימיטיב הקריפטוגרפי ברמה הנמוכה, צריך לעדכן את מודול ה-FIPS הפנימי.
בטבלה הבאה מתוארים הסטאקים הקריפטוגרפיים בקובצי האימג' של קונטיינר ליבת מסד הנתונים של AlloyDB Omni Red Hat UBI 9‏ (-ubi9), כולל הגבול הפנימי הקפוא של FIPS והשכבה החיצונית של הקריפטוגרפיה והפרוטוקול שמתוקנת בגרסאות השונות:

מחסנית קריפטוגרפית קובץ אימג' של קונטיינר ליבת מסד הנתונים קבצים בינאריים מודול או ספק פנימיים שאומתו לפי תקן FIPS שכבת פרוטוקול ושכבה קריפטוגרפית חיצונית
‫BoringSSL ו-BoringCrypto alloydbomni (-ubi9) קובצי בינארי של postgres ו-pgbackrest C Google BoringCrypto Module (BCM) ‫BoringSSL libssl וחבילות libcrypto שאינן BCM‏ x509,‏ asn1,‏ pem ו-bio ל-postgres ול-pgbackrest
OpenSSL 3 שכבת מערכת ההפעלה הבסיסית של Red Hat UBI 9 ב-alloydbomni (-ubi9) ספריות משותפות וכלי עזר של מערכת ההפעלה הבסיסית ספק RHEL 9 OpenSSL FIPS ‫/lib64/libssl.so.3 ו-/lib64/libcrypto.so.3 בחבילת ה-RPM של openssl-libs

המאמרים הבאים