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

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

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

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

שכבה באחריות Google באחריות הלקוח
חומרה ומארח תשתית פיזית לספק דרישות מינימליות ומומלצות, אם רלוונטי הקצאת שרתים פיזיים, מכונות וירטואליות או מכשירי קצה, כמו חשמל, קירור וחומרה.
מערכת ההפעלה (OS) של המארח במקרים הרלוונטיים, מציינים את דרישות המינימום והדרישות המומלצות ניהול ליבת Linux, החלת תיקוני אבטחה של מערכת ההפעלה והקשחת צומתי המארח.
‫Kubernetes ניהול אשכולות לספק דרישות מינימליות ומומלצות, אם רלוונטי לנהל את האשכול על בסיס יומי, כולל שדרוגים, בהתאם לשיטות המומלצות המקובלות בתחום.
אחסון (CSI/PV) לספק דרישות מינימליות ומומלצות, אם רלוונטי הקצאת מחלקת האחסון וניהול המכשירים שעומדים בבסיס שלה. ל-AlloyDB Omni נדרש התקן בלוקים, לכן חשוב לבחור מחלקה של התקן בלוקים.
נטוורקינג (CNI) לספק דרישות מינימליות ומומלצות, אם רלוונטי הקצאה וניהול של שכבת הרשת – לדוגמה, רשתות של פודים, בקרי כניסה, מאזני עומסים וכללי חומת אש בין צמתים.
בקרת גישה מבוססת-תפקידים (RBAC) מציינים את חשבונות השירות, התפקידים וקישורי התפקידים שנדרשים לאופרטור של AlloyDB Omni Kubernetes. מחילים את הכללים האלה של בקרת גישה מבוססת-תפקידים (RBAC) על האשכול, ומוודאים שהם תואמים למדיניות האבטחה הפנימית. כדי לגשת למשאבים של AlloyDB Omni, צריך ליצור תפקידי RBAC נוספים וקישורי תפקידים.
ניהול סודות לקרוא סודות סטנדרטיים של Kubernetes כדי להקצות משאבים, כמו המשתמש הראשוני של postgres. ליצור, לאבטח ולשנות את הסודות של Kubernetes באשכול.
ניהול אישורים להסתמך על סודות סטנדרטיים של Kubernetes ועל cert-manager לשילוב אישורים. התקנה, הגדרה וניהול של מחזור החיים של cert-manager.
תוכנה של המפעיל פיתוח והשקה לפתח את הלוגיקה של אופרטור AlloyDB Omni ואת ה-CRD, ולפרסם קובצי אימג' של קונטיינרים, תרשימי Helm וחבילות OLM. אין. אתם יכולים להשתמש בארטיפקטים שמאוחסנים ב-Artifact Registry לפריסות שלכם.
התקנה ומחזור חיים צריך לספק תיעוד וארטיפקטים של שדרוג.
  • לפני שמתקינים או משדרגים את אופרטור 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. פורסים ומנהלים את כלי הגירוד באמצעות 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 compliance.

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

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

מזהה STIG או SRG תיאור אמצעי הבקרה לאבטחה התנהגות ברירת המחדל של הפלטפורמה והמפעיל פעולה או הגדרה שנדרשת מצד הלקוח
V-233535 התראה מיידית לנציגי התמיכה על כשלים ביומן הביקורת. תוצאות האבחון של שגיאות סטנדרטיות (stderr) נכתבות למאגר 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. הלקוח צריך לוודא שמצב FIPS 140 מופעל בקרנל של מארח Kubernetes הבסיסי.
V-233515 שילוב עם מנגנוני אימות ברמת הארגון של Active Directory‏ (AD) ו-Lightweight Directory Access Protocol‏ (LDAP). המפעיל תומך בהגדרות אימות בהתאמה אישית. הלקוח צריך למפות את הזהויות של AD ו-LDAP להגדרת אשכול מסד הנתונים.
V-233583 להשתמש במודולים קריפטוגרפיים עם אישור FIPS לגיבוב (hash). המאגר מסתמך על מודולי OpenSSL FIPS של המארח לפונקציות גיבוב. הלקוח חייב להפעיל את מצב 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) כדי למנוע גישה לא מורשית של הטרמינל לפודים.