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

בחירת גרסה של מאמר העזרה:

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

כלקוחות 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) מדדים חשיפת מדדים של מסד נתונים פנימי באמצעות נקודת קצה שתואמת ל-Prometheus. פורסים ומנהלים את כלי הגירוד באמצעות Prometheus,‏ Open Telemetry או פתרונות תואמים אחרים ומערך האחסון שלהם. מעקב אחרי התקינות הכוללת של המערכת.
רישום ביומן לכתוב יומני ביקורת ו-PostgreSQL לקבצים בדיסק במאגר, ולסובב אותם. פריסת כלי איסוף יומנים – לדוגמה, Fluentd ו-Fluent Bit – כדי לשלוח יומנים לבק-אנד של אחסון (כמו Splunk או ELK). חשוב לוודא שכלי האיסוף של היומנים מוגדרים לשמירת היומנים למשך חודש אחד לפחות, כפי שמומלץ.
תצוגה חזותית מספקים מדדים לדוגמה ולוחות בקרה של יומנים כדי לעקוב אחרי עומסי עבודה (workloads) רגילים. פריסה ומעקב אחרי תקינות כלי הוויזואליזציה, כמו 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) ולחבילות הצפנה של TLS.
אישורים מ-CA בהתאמה אישית משותף אישורים דיגיטליים צריכים לעמוד בתקני FIPS לגבי חוזק המפתח ואלגוריתמי החתימה. שרשרת האישורים צריכה להוביל חזרה לרשות אישורים בסיסית שתואמת לתקן 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 חשוב להודיע מיד לנציגי התמיכה על כשלים ביומן הביקורת. תוצאות האבחון של שגיאות רגילות נכתבות למאגר התגים 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 מקומיות. הלקוח צריך לספק למפעיל את אישורי ה-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 עבור גיבוב. המאגר מסתמך על מודולי OpenSSL FIPS של המארח לפונקציות גיבוב. הלקוח צריך להפעיל את מצב FIPS בצמתי VM של המארח.
V-233585 כדי להגן על מידע לא מסווג, צריך להשתמש בהצפנה שאומתה על ידי FIPS. הצפנה של תקשורת ואחסון באמצעות צפנים עם יכולת FIPS. הלקוח צריך לוודא שצמתי המארח מאומתים על ידי FIPS.
V-233619 שימוש במודולים קריפטוגרפיים שעברו אימות FIPS לכל הפעולות. אוכף קבצים בינאריים של קובץ אימג' של קונטיינר שמוכן ל-FIPS UBI9. הלקוח צריך להפעיל את מצב FIPS בליבת המארח.
V-233623 מוודאים שמערכת ניהול מסדי הנתונים (DBMS) פועלת במארח עם OpenSSL FIPS מאושר. פודים של מסדי נתונים מסתמכים על הגדרות FIPS של OpenSSL במארח. הלקוח צריך לוודא ש-OpenSSL של המארח תואם לרשימת ה-FIPS שאושרה על ידי NIST.
V-233615 מיפוי של זהויות שאומתו באמצעות PKI לחשבונות משתמשים משויכים. המפעיל משתמש באימות סיסמה מאובטח SCRAM-SHA-256 לזהויות. אם הלקוח לא משתמש בכניסה ישירה באמצעות סיסמה, הוא צריך למפות תפקידים בספרייה ארגונית חיצונית לתפקידים במסד הנתונים.
V-233540 הגבלת חשבון ההתקנה של מסד הנתונים למשתמשים מורשים בלבד. המאגר מגביל את הרשאות הקבצים וההרצה למשתמש postgres. הלקוח צריך לנעול את הגישה לצומת המארח (SSH/Kubectl) כדי למנוע גישה לא מורשית לטרמינל של הפודים.