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

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

כדי להעריך את מצב האבטחה של פריסות AlloyDB Omni Kubernetes ולתכנן שדרוגים של מישור הבקרה ואשכול מסד הנתונים, כדאי לעיין במדיניות האבטחה, בארכיטקטורת המפעיל, בבקרת גישה מבוססת-תפקידים (RBAC) ובהקשרי האבטחה, ובשיטות הגילוי של חשיפות ונקודות חולשה נפוצות (CVE) בדף הזה.

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

ארכיטקטורת אופרטורים והקשרי אבטחה

ב-AlloyDB Omni ב-Kubernetes, מישור הבקרה של Kubernetes מופרד מהפודים של המנוע של מסד הנתונים שמעבדים את השאילתות של האפליקציה:

  • רכיבים של מישור הבקרה והאופרטור: כל גרסה של אופרטור AlloyDB Omni כוללת 10 קובצי אימג' של קונטיינרים שמבוססים על Red Hat Universal Base Image 9 ‏(UBI 9):
    • ‫operator/fleet-operator: בקר Kubernetes ברמת ה-Fleet, שמתאים בין DBCluster לבין משאבים בהתאמה אישית של ה-Fleet
    • ‫operator/local-operator: בקר Kubernetes ברמת המכונה שמנהל את מחזורי החיים של pod של מסד נתונים מקומי ומתקשר רק עם שרת ה-API המהימן של Kubernetes בתוך האשכול
    • ‫alloydbomni-operator-catalog ו-alloydbomni-operator-olm-bundle: אינדקס קטלוג של Red Hat OpenShift Operator Lifecycle Manager (OLM) ותמונות מטא-נתונים של חבילות הצהרתיות
    • ‫operator/dbinit ו-operator/backupinit: קונטיינרים זמניים של אתחול לתהליכי עבודה של אתחול, גיבוי ושחזור של מסדי נתונים
    • ‫operator/alloydbomni-monitor (מחליף את monitoring-agent), operator/g-pgbouncer, operator/logrotate ו-operator/node-manager: קונטיינרים נלווים וקונטיינרים לניהול צמתים לבדיקת תקינות, מאגר חיבורים, החלפת יומנים וניהול אחסון
  • הקשרי אבטחה ו-RBAC: אופרטור AlloyDB Omni משתמש בהרשאות Role ו-ClusterRole של Kubernetes ברמת ההיקף כדי להתאים משאבים בהתאמה אישית במרחבי שמות של יעדים, ומריץ עומסי עבודה של מישור הבקרה ו-sidecar עם הקשרי אבטחה מוגבלים של קונטיינרים.
  • פודים של מנוע מסד הנתונים: מכונות של מסדי נתונים שמנוהלות על ידי האופרטור מריצות את קובצי האימג' של קונטיינר הליבה של מסד הנתונים העצמאי של AlloyDB Omni. כדי לבדוק אילו גרסאות של ליבת מסד הנתונים נתמכות בגרסת האופרטור שלכם, קראו את המאמר בחירת גרסאות תואמות של אשכול מסד נתונים ואופרטור Kubernetes.

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

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

  • סינון מחמיר של חומרת סיכון קריטית וגבוהה: טבלאות סיכום של נקודות חולשה ודוחות מפורטים של יומני CVE מדווחים רק על נקודות חולשה קריטיות וגבוהות, על סמך דירוגי החומרה של National Vulnerability Database (NVD)‎ ושל ספקים במעלה הזרם. התראות ברמת חומרה נמוכה ובינונית לא נכללות בסיכומים וביומנים המפורטים.
  • דיווח נפרד על מישור הבקרה ועל ליבת מסד הנתונים: הודעות על מישור הבקרה ב-AlloyDB Omni ב-Kubernetes מדווחות על נקודות חולשה ספציפיות ל-10 קובצי האימג' של הקונטיינר המשני (sidecar) ושל אופרטור AlloyDB Omni.
  • הפרדה לפי גרסה: יומני 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 כשמתפרסמות גרסאות חדשות:

  • תיקון CVE: פגיעויות שהיו קיימות בגרסה קודמת של קובץ האימג' של קונטיינר מישור הבקרה של אופרטור AlloyDB Omni, תוקנו בגרסה הבאה של האופרטור. ‫Google מחילה תיקוני אבטחה על הגרסה הנתמכת האחרונה של אופרטור AlloyDB Omni ועל גרסת המשנה האחרונה של הגרסאות הראשיות הנתמכות של 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. קובצי האימג' של הקונטיינר של אופרטור AlloyDB Omni וקובצי האימג' של הקונטיינר של מסד הנתונים Red Hat UBI 9‏ (-ubi9) תואמים ל-FIPS, והארגון שלכם אחראי להפעיל ולאמת את מצב FIPS במערכת ההפעלה המארחת הבסיסית. מידע נוסף זמין במאמר אבטחה ותאימות ל-FIPS.
  • תיקון CVE מחוץ לגבולות FIPS: ניתוח פרוטוקולים וספריות רשת, כמו מכונות מצב של TLS, ניתוח אישורי X.509 ו-ASN.1,‏ HTTP/2 וקלט/פלט של רשת, נמצאים בשכבה החיצונית מחוץ לגבולות מודול FIPS הקפוא. מכיוון שהרכיבים האלה נמצאים מחוץ לגבולות המאומתים, Google מתקנת את נקודות החולשה והחשיפה (CVE) בשכבה החיצונית בגרסאות משניות ובתיקוני באגים, בלי לשנות את המודול הקריפטוגרפי הפנימי או לבטל את אישור ה-NIST CMVP שלו. רק אם יש נקודת חולשה בתוך ההטמעה של הפרימיטיב הקריפטוגרפי ברמה הנמוכה, צריך לעדכן את מודול ה-FIPS הפנימי.
בטבלה הבאה מתוארים המחסניות הקריפטוגרפיות במישור הבקרה של אופרטור AlloyDB Omni ובקובצי האימג' של הקונטיינר המשני (sidecar), כולל גבול ה-FIPS הפנימי הקפוא והשכבה הקריפטוגרפית ושכבת הפרוטוקול החיצונית שמתוקנות בגרסאות השונות:

מחסנית קריפטוגרפית קובצי אימג' של קונטיינרים במישור הבקרה קבצים בינאריים מודול או ספק פנימיים שאומתו לפי תקן FIPS שכבת פרוטוקול ושכבה קריפטוגרפית חיצונית
שימוש ב-FIPS מובנה באמצעות הגדרת ה-build‏ 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 		‫Go Cryptographic Module v1.0.0, אישור NIST CMVP מספר 5247 חבילות הספרייה הרגילות של Go‏ crypto/tls, crypto/x509 ו-net/http, חבילות Go חיצוניות כמו golang.org/x/crypto, וסביבת זמן הריצה והקומפיילר של Go
OpenSSL 3 operator/g-pgbouncer /usr/bin/pgbouncer ספק RHEL 9 OpenSSL FIPS ‫/lib64/libssl.so.3 ו-/lib64/libcrypto.so.3 בחבילת ה-RPM של openssl-libs, והקובץ הבינארי של pgbouncer C
‫BoringSSL ו-BoringCrypto operator/alloydbomni-monitor ‫/monitoring_agent קובץ בינארי של Go שנוצר באמצעות boringcrypto Google BoringCrypto Module (BCM) חבילות Go crypto/tls,‏ crypto/x509 ו-net/http ל-monitoring_agent

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