אחריות משותפת ב-AlloyDB Omni

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

בדף הזה מתוארת חלוקת האחריות בין Google לבין הלקוחות של AlloyDB Omni.

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

שכבה באחריות Google באחריות הלקוח
חומרה ומארח תשתית פיזית לספק דרישות מינימליות ומומלצות, אם רלוונטי הקצאת שרתים פיזיים, מכונות וירטואליות או מכשירי קצה, כמו חשמל, קירור וחומרה.
מערכת ההפעלה (OS) המארחת לספק דרישות מינימליות ומומלצות, אם רלוונטי ניהול ליבת Linux, החלת תיקוני אבטחה של מערכת ההפעלה והקשחת צומתי המארח.
Kubernetes ניהול אשכולות לספק דרישות מינימליות ומומלצות, אם רלוונטי לנהל את האשכול על בסיס יומי, כולל שדרוגים, בהתאם לשיטות המומלצות המקובלות בתחום.
אחסון (CSI/PV) לספק דרישות מינימליות ומומלצות, אם רלוונטי הקצאת מחלקת האחסון וניהול המכשירים שעומדים בבסיס שלה. ל-AlloyDB Omni נדרש התקן בלוקים, לכן חשוב לבחור מחלקה של התקן בלוקים.
רשתות (CNI) לספק דרישות מינימליות ומומלצות, אם רלוונטי להקצות ולנהל את שכבת הרשת – לדוגמה, רשתות Pod, בקרי Ingress, מאזני עומסים וכללי חומת אש בין צמתים.
בקרת גישה מבוססת-תפקידים (RBAC) מגדירים את חשבונות השירות, התפקידים וקישורי התפקידים שנדרשים ל-AlloyDB Omni Kubernetes Operator. מחילים את הכללים האלה של בקרת גישה מבוססת-תפקידים (RBAC) על האשכול, ומוודאים שהם תואמים למדיניות האבטחה הפנימית. כדי לגשת למשאבים של AlloyDB Omni, צריך ליצור תפקידי RBAC נוספים וקישורי תפקידים.
ניהול סודות לקרוא סודות סטנדרטיים של Kubernetes כדי להקצות משאבים, כמו המשתמש הראשוני של postgres. ליצור, לאבטח ולשנות את הסודות של Kubernetes באשכול.
ניהול אישורים להסתמך על סודות רגילים של Kubernetes ועל cert-manager לשילוב אישורים. התקנה, הגדרה וניהול של מחזור החיים של cert-manager.
תוכנה של המפעיל פיתוח והשקה לפתח את הלוגיקה של אופרטור AlloyDB Omni ואת ה-CRD, ולפרסם קובצי אימג' של קונטיינרים, תרשימי Helm וחבילות OLM. אין. אתם יכולים להשתמש בפריטי מידע שמאוחסנים ב-Artifact Registry לפריסות שלכם.
התקנה ומחזור חיים לספק תיעוד ולשדרג פריטי מידע שנוצרו בתהליך הפיתוח (artifacts).
  • לפני שמתקינים או משדרגים את אופרטור AlloyDB Omni, חשוב לבדוק את טבלת התאימות.
  • פועלים לפי ההוראות כדי להתקין או לשדרג את הרכיבים של AlloyDB Omni.
המנוע של מסד הנתונים קובץ בינארי של מסד נתונים לספק קובצי אימג' של קונטיינרים של AlloyDB Omni עם אופטימיזציות קנייניות, כמו מנוע מבוסס-עמודות והאצת AI. אין.
תיקון הפצת תיקוני אבטחה ועדכוני גרסאות ראשיות ומשניות למנוע. לספק הוראות שדרוג. תזמנו שדרוגים בהקדם האפשרי, בהתאם לחשיבות של כל גרסה.
ניהול משתמשים
  • מקצים את המשתמשים הראשוניים שקשורים לאופרטור AlloyDB Omni.
  • הקצאת משתמש-העל postgres שגלוי למשתמשים באמצעות סיסמה שסופקה על ידי המשתמש מ-Kubernetes Secret.
  • הוראות לשילוב עם Microsoft Active Directory.
  • מזינים את הסיסמה של משתמש-העל הראשוני באמצעות Kubernetes Secret.
  • ליצור ולנהל את כל התפקידים והמשתמשים האחרים.
ניהול נתונים גיבויים מספקים את ה-CRD של `BackupPlan` ו-`Backup` ואת הלוגיקה לניהול הגיבויים, שמנוהלים באמצעות pgBackrest עם שילוב תואם ל-S3. מגדירים את לוחות הזמנים לגיבוי ואת משך השמירה, ומקצים את קטגוריית היעד לאחסון מקומי, ב-S3 או ב-Cloud Storage.
זמינות גבוהה (HA) לספק את הלוגיקה של יתירות כשל אוטומטית ומנגנוני תיקון. מקצים מספיק צמתים ואזורים כדי לספק יעד המתנה לתמיכה ביתירות כשל.
הצפנה (במנוחה) תמיכה בהצפנת נתונים שקופה (TDE). לנהל את ההצפנה של שכבת האחסון כדי לוודא שהיא עומדת בדרישות שלכם.
הצפנה (בזמן ההעברה) לספק mTLS לרכיבי מפעיל פנימיים ולהגדיר TLS בצד השרת לחיבורים בין המשתמש למסד הנתונים. להתחבר למסד הנתונים באמצעות לקוחות TLS מאובטחים ולנהל את תשתית האישורים הבסיסית.
ניראות (observability) מדדים חשיפת מדדי מסד נתונים פנימיים באמצעות נקודת קצה (endpoint) שתואמת ל-Prometheus. פורסים ומנהלים את ה-scraper באמצעות Prometheus,‏ Open Telemetry או פתרונות תואמים אחרים ומחסנית האחסון שלהם. לפקח על התקינות הכוללת של המערכת.
רישום ביומן כותבים את יומני הביקורת ו-PostgreSQL לקבצים בדיסק בקונטיינר, ומבצעים רוטציה שלהם. פורסים אוספי יומנים, כמו Fluentd ו-Fluent Bit, כדי לשלוח יומנים לקצה עורפי של אחסון (כמו Splunk או ELK). חשוב לוודא שהכלים לאיסוף יומנים מוגדרים לשמור את היומנים למשך חודש לפחות (מומלץ).
המחשה לספק מדדים לדוגמה ולוחות בקרה של יומנים כדי לעקוב אחרי עומסי עבודה רגילים. פורסים את כלי ההמחשה (למשל Grafana) ועוקבים אחרי התקינות שלו. ליצור מרכזי בקרה ולשלב אותם במשימות התפעוליות היומיומיות.
שליחת התראות ללא ניהול צינור עיבוד הנתונים של ההתראות – לדוגמה, שילוב עם PagerDuty.
תמיכה פתרון בעיות לספק תמיכה בבאגים בתוכנה ובשגיאות במנוע. כדי לקבל את התמיכה הזו, צריך מינוי לרישיון. לספק תמיכה ראשונית באמצעות מסמכי תיעוד ומאגר ידע. לנפות באגים שקשורים לתשתית.

אבטחה ותאימות ל-FIPS

כדי לאבטח את הנתונים, AlloyDB Omni משתמש במודולים קריפטוגרפיים שאומתו לפי Federal Information Processing Standards (FIPS) 140-2 או 140-3. התאימות ל-FIPS היא באחריות משותפת של Google ושל הלקוח.

בתרשים הבא מוצג איך האחריות לתאימות ל-FIPS מתחלקת בין Google לבין הלקוח בשכבות הארכיטקטורה של AlloyDB Omni.

תרשים שמציג את גבולות האחריות לתאימות ל-FIPS, ומחלק את תחומי האחריות בין Google, הלקוח והאזורים המשותפים.

בטבלה הבאה מתוארים הגבולות ותחומי האחריות של FIPS ב-AlloyDB Omni:

שכבת גבולות FIPS אחריות תיאור
חומרה שתואמת לתקן FIPS לקוח/ה הרכיבים הפיזיים של החומרה והקריפטוגרפיה חייבים להיות מאושרים על ידי NIST ומוגדרים במצב שאושר על ידי FIPS.
מערכת ההפעלה של צומתי Kubernetes לקוח/ה מערכת ההפעלה המארחת של צומת העובד, למשל RHEL, צריכה לפעול במצב FIPS. צריך לאמת את מצב ה-FIPS (הפונקציה cat /proc/sys/crypto/fips_enabled מחזירה 1).
מישור הבקרה של Kubernetes לקוח/ה רכיבים של מישור הבקרה כמו kubelet ופלאגינים של רשתות ואחסון חייבים להשתמש במודולים קריפטוגרפיים שאושרו על ידי FIPS – לדוגמה, כאלה שנוצרו באמצעות Go-BoringCrypto.
בקרי אופרטור AlloyDB Omni Google הוא פותח על ידי Google, מבוסס על קובץ אימג' בסיסי שתואם ל-FIPS‏ (Red Hat UBI), והתאימות ל-FIPS מופעלת בקונטיינר שבו פועל מסד הנתונים.
קובץ אימג' של קונטיינר ב-AlloyDB Omni Google שימוש בספריות קריפטוגרפיות שתואמות ל-FIPS, כמו BoringSSL, ואכיפת אלגוריתמים שאושרו על ידי FIPS לגיבוב סיסמאות (scram-sha-256) ולסט אלגוריתמים להצפנה (cipher suite) של TLS.
אישורים מ-CA בהתאמה אישית משותף אישורים דיגיטליים חייבים לעמוד בתקני FIPS בנוגע לחוזק המפתח ולאלגוריתמים של החתימה. שרשרת האישורים צריכה להגיע עד לרשות אישורי בסיס (Root CA) שתואמת לתקן FIPS.

אחריות משותפת ל-STIG

הסוכנות למערכות מידע ביטחוניות (DISA) מפרסמת מדריכים טכניים להטמעת אבטחה (STIG) כדי לקבוע תקנים לאבטחת סייבר ודרישות הקשחה לתוכנות, למערכות הפעלה ולמסדי נתונים. המדריכים האלה מגדירים פרמטרים ספציפיים של אבטחה כדי להגן על המערכות מפני נקודות חולשה ואיומי סייבר.

רשימה מלאה של כללי STIG מופיעה במאמר תאימות של AlloyDB Omni ל-STIG.

כדי לקבל אישור לפעול (ATO) במגזרים ממשלתיים או במגזרים עם רמת אבטחה גבוהה, חיוני להקשיח את הסביבה בהתאם לדרישות של STIG. למרות ש-AlloyDB Omni מיישם כברירת מחדל הרבה אמצעי בקרה לאבטחה ברמת מסד הנתונים, השגת תאימות מלאה ל-STIG היא אחריות משותפת המחייבת את הלקוח להגדיר ולאמת את ההגדרות ברמת התשתית.

בטבלה הבאה מפורטים כל מזהי נקודות החולשה של STIG שדורשים פעולה, אימות או הגדרה על ידי הלקוח. למידע מקיף, עיינו ברשימת המשימות לתאימות של PostgreSQL 9.x ב-Red Hat Enterprise Linux Security Technical Implementation Guide (STIG)‎.

מזהה STIG או SRG תיאור אמצעי הבקרה לאבטחה פעולת ברירת המחדל של הפלטפורמה והמפעיל פעולה או הגדרה שנדרשת מצד הלקוח
V-233535 התראה מיידית לצוות התמיכה על כשלים ביומן הביקורת. אבחון שגיאות סטנדרטיות נכתב למאגר stdout ו-stderr. הלקוח צריך להגדיר מדדים של SIEM או של מעביר היומנים – לדוגמה, התראות של Splunk או של Elastic – כך שיופעלו כשיש ירידה בהטמעה.
V-233599 התראה לצוות התמיכה כשנפח האחסון של הביקורת מגיע ל-75% קיבולת. מדדי מערכת הקבצים נחשפים דרך נקודות קצה רגילות של Prometheus. הלקוח צריך להגדיר כללי התראה ב-Prometheus וב-Grafana כדי להודיע לתמיכה כשמקום האחסון בדיסק של /obs/ חורג מ-75%.
V-233610 להעביר את נתוני הביקורת למתקן נפרד של רישום רציף ביומן. יומני הביקורת נכתבים באופן קבוע בנפח האחסון /obs/diagnostic/. הלקוח צריך להגדיר מעביר יומנים – לדוגמה, FluentBit ו-Vector – כדי להעביר קובצי יומן באופן רציף ל-SIEM מרכזי.
V-233603 צריך לתת אמון רק באישורים של ישויות קצה שהונפקו על ידי תשתית של מפתח ציבורי (PKI) או רשויות מאושרות להנפקת אישורים (CA). המפעיל משתמש ב-cert-manager כדי להגדיר תצורות TLS מקומיות. הלקוח צריך לספק למפעיל את אישורי ה-CA ברמת הבסיס וברמת הביניים של ה-PKI כדי ליצור את שרשרת האמון.
V-233520 אכיפת הרשאות גישה לוגיות שאושרו. דוחה סיסמאות בטקסט פשוט ואת אלגוריתם Message-Digest 5 ‏ (MD5). מאפשר scram-sha-256 באמצעות SSL. הלקוח צריך להגדיר את הלקוחות כך שישתמשו ב-SCRAM-SHA-256 עם sslmode=verify-full במחרוזות החיבור שלהם.
V-233522 להגביל את מספר הסשנים בו-זמנית לכל משתמש. לתפקידים שמוגדרים כברירת מחדל במסד הנתונים יש מגבלות אינסופיות שמוגבלות על ידי max_connections. הלקוח צריך לשנות באופן מפורש את מגבלות החיבור (ALTER ROLE ... CONNECTION LIMIT) לתפקידי אפליקציה בהתאמה אישית.
V-233584 שימוש בקריפטוגרפיה שאושרה על ידי ה-NSA למידע מסווג במנוחה. מאגר מסד הנתונים משתמש בשכבות בסיס מאובטחות ומוקשחות של UBI9. הלקוח צריך לוודא שבקרנל המארח הבסיסי של Kubernetes מופעל מצב FIPS 140.
V-233515 שילוב עם מנגנוני אימות ברמת הארגון של Active Directory ‏ (AD) ו-Lightweight Directory Access Protocol ‏ (LDAP). המפעיל תומך בהגדרות אימות בהתאמה אישית. הלקוח צריך למפות את הזהויות של AD ו-LDAP להגדרת אשכול מסד הנתונים.
V-233583 להשתמש במודולים קריפטוגרפיים עם אישור FIPS לגיבוב (hash). הקונטיינר מסתמך על מודולים של OpenSSL FIPS במארח לפונקציות גיבוב (hash). הלקוח צריך להפעיל את מצב FIPS בצומתי המכונה הווירטואלית המארחת.
V-233585 שימוש בהצפנה מאומתת FIPS כדי להגן על מידע לא מסווג. הצפנת התקשורת והאחסון באמצעות צפנים שתואמים ל-FIPS. הלקוח חייב לוודא שצמתי המארח מאומתים לפי תקן FIPS.
V-233619 שימוש במודולים קריפטוגרפיים עם אישור FIPS לכל הפעולות. אכיפת קובצי בינארי של קובצי אימג' של קונטיינר שמוכנים ל-UBI9 FIPS. הלקוח צריך להפעיל את מצב FIPS בקרנל המארח.
V-233623 צריך לוודא שה-DBMS פועל במארח עם OpenSSL FIPS מאושר. פודים של מסדי נתונים מסתמכים על הגדרות OpenSSL FIPS של המארח. הלקוח צריך לוודא ש-OpenSSL של המארח תואם לרשימת FIPS שאושרה על ידי NIST.
V-233615 למפות זהויות שאומתו באמצעות PKI לחשבונות המשתמשים המשויכים. המפעיל משתמש באימות סיסמה מאובטח של SCRAM-SHA-256 לזהויות. אם הלקוחות לא משתמשים בכניסה ישירה באמצעות סיסמה, הם צריכים למפות את התפקידים בספריית הארגון החיצונית לתפקידים במסד הנתונים.
V-233540 הגבילו את הגישה לחשבון ההתקנה של מסד הנתונים למשתמשים מורשים בלבד. הקונטיינר מגביל את ההרשאות לקבצים ואת ההפעלה למשתמש postgres. הלקוח חייב לנעול את הגישה לצומת המארח (SSH/Kubectl) כדי למנוע גישה לא מורשית של הטרמינל לפודים.