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

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

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

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

מטריצת אחריות משותפת

בטבלה הבאה מפורטת חלוקת האחריות בין Google לבין הלקוח בכל שכבה של פריסת תזמור ב-AlloyDB Omni RPM:

שכבה באחריות Google באחריות הלקוח
חומרה ומארח תשתית פיזית לספק דרישות מינימליות ומומלצות, אם רלוונטי. הקצאת שרתים פיזיים, מכונות וירטואליות או מכשירי קצה, כולל חשמל, קירור וחומרה.
מערכת ההפעלה (OS) המארחת לספק דרישות מינימליות ומומלצות, אם רלוונטי. לנהל את ליבת Linux, להחיל תיקוני אבטחה של מערכת ההפעלה ולהקשיח את צומתי המארח (כמו RHEL 9 או Rocky Linux 9).
רכיבי תשתית ומערכת הפעלה אחסון במקומות שבהם זה רלוונטי, מציינים את דרישות המינימום והדרישות המומלצות. הקצאת נפחי SAN או דיסקים מקומיים. ‫AlloyDB Omni דורש מכשיר בלוק שהוגדר עם מערכת קבצים נתמכת כמו XFS או ext4.
Networking במקומות שבהם זה רלוונטי, מציינים את דרישות המינימום והדרישות המומלצות. להקצות ולנהל את שכבת הרשת – כמו ניתוב IP, מאזני עומסים וכללי חומת אש באמצעות firewalld או iptables – כדי לפתוח את היציאות הנדרשות, כמו 5432 ל-PostgreSQL ו-2379 ו-2380 ל-etcd.
בקרת גישה למארחים מספקים את חשבונות השירות והתפקידים שנדרשים לרכיבי התזמור ב-AlloyDB Omni. כדי לעמוד בדרישות של מדיניות האבטחה הפנימית שלכם, אתם יכולים לנהל את הגישה ל-SSH, את ההרשאות של sudo, את כללי המדיניות של SELinux ואת חשבונות המשתמשים ב-Linux.
ניהול סודות קריאת משתנים רגילים וקבצים של מלאי שטחי פרסום כדי להקצות משאבים, כמו משתמש postgres ראשוני. אחסון מאובטח של סיסמאות, מפתחות SSH וטוקנים שמשמשים לתזמור של Ansible ולגישה למסדי נתונים.
ניהול אישורים לספק אפשרויות הגדרה לשילוב אישורים. יצירה, הפצה וניהול של מחזור החיים של אישורי Transport Layer Security ‏ (TLS) ו-SSL במכונות המארחות.
תוכנת Orchestrator פיתוח והשקה פיתוח תזמור ב-AlloyDB Omni, כולל אוספי CLI ו-Ansible, ופרסום חבילות RPM. אין. אתם יכולים להשתמש בארטיפקטים ממאגר Yum שסופק לפריסות שלכם.
התקנה ומחזור חיים לספק מסמכים, פריטי מידע שנוצרו בתהליך הפיתוח (artifacts) של RPM ותבניות של מלאי שטחי פרסום לפריסה.

לפני ההתקנה, חשוב לוודא שהמכשיר תואם.

פועלים לפי ההוראות כדי להתקין או לשדרג את AlloyDB Omni באמצעות alloydbctl CLI של כלי התזמור או קובצי Ansible playbooks.
המנוע של מסד הנתונים קובץ בינארי של מסד נתונים חבילות ה-RPM של AlloyDB Omni כוללות אופטימיזציות קנייניות כמו מנוע מבוסס-עמודות והאצת AI. אין.
תיקון מפיצים תיקוני אבטחה ועדכוני גרסאות ראשיות ומשניות למנוע. לספק הוראות לשדרוג. כדאי לתזמן שדרוגים בהקדם האפשרי, בהתאם לחשיבות של כל גרסה.
ניהול משתמשים

הקצאת המשתמשים הראשוניים עם הרשאות אדמין.

מקצים את משתמש-העל של postgres שגלוי למשתמשים.

תספק הוראות לשילוב של Lightweight Directory Access Protocol‏ (LDAP) ו-Active Directory‏ (AD).

מזינים את הסיסמה של משתמש העל הראשוני.

ליצור ולנהל את כל התפקידים והמשתמשים האחרים.
ניהול נתונים גיבויים אפשר להשתמש באוטומציה לניהול גיבויים באמצעות pgBackRest עם שילוב תואם ל-S3. מגדירים את לוחות הזמנים לגיבוי ואת משך השמירה, ומקצים את קטגוריית היעד המקומית, ב-S3 או ב-Cloud Storage.
זמינות גבוהה (HA) לספק את הלוגיקה של מעבר אוטומטי לגיבוי בעת כשל ואת מנגנוני התיקון באמצעות etcd והתוכנה לניהול אשכולות. מקצים מספיק צמתים – כמו צומת בקרה, צומתי etcd וצומתי מסד נתונים ראשיים ומשניים – כדי לתמוך בארכיטקטורות של יתירות כשל וזמינות גבוהה.
הצפנה במנוחה תמיכה בפריסות בכרכים מוצפנים ברמת הבלוק. לנהל את ההצפנה של שכבת האחסון, כמו Linux Unified Key Setup‏ (LUKS) ו-dm-crypt, כדי לעמוד בדרישות האבטחה שלכם.
הצפנה במעבר מגדירים TLS בצד השרת לחיבורים של משתמשים למסד נתונים ולתקשורת פנימית בין צמתים באשכול. להתחבר למסד הנתונים באמצעות לקוחות TLS מאובטחים ולנהל את תשתית האישורים הבסיסית.
ניראות (observability) מדדים חשיפת מדדים של מסד נתונים פנימי באמצעות נקודת קצה (endpoint) שתואמת ל-Prometheus. פורסים את כלי הגירוד ומנהלים אותו באמצעות Prometheus,‏ OpenTelemetry או פתרונות תואמים אחרים ומערך האחסון שלהם. מעקב אחרי התקינות הכוללת של המערכת.
רישום ביומן לכתוב את PostgreSQL ויומני הביקורת לקבצים בדיסק ולנהל את הרוטציה. פורסים אוספי יומנים, כמו Fluent Bit או Vector, כדי לשלוח יומנים לקצה העורפי של האחסון, כמו Splunk או ELK stack. מומלץ לשמור את היומנים למשך חודש לפחות.
המחשה מספקים מדדים ולוחות בקרה לדוגמה למעקב אחרי עומסי עבודה רגילים. פריסה של כלי להמחשה חזותית, כמו Grafana, ומעקב אחרי התקינות שלו. ליצור לוחות בקרה ולשלב אותם במשימות התפעוליות היומיומיות.
שליחת התראות אין. לנהל את צינור עיבוד הנתונים של ההתראות, למשל באמצעות שילוב עם PagerDuty.
תמיכה פתרון בעיות מתן תמיכה בבאגים בתוכנה ובשגיאות במנוע. כדי לקבל את התמיכה הזו, צריך מינוי. מתן תמיכה ראשונית באמצעות מסמכים ומאגר ידע. ניפוי באגים בבעיות שקשורות לתשתית.

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

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

שכבת גבולות FIPS אחריות תיאור
חומרה שתואמת לתקן FIPS לקוח/ה הרכיבים הפיזיים של החומרה והקריפטוגרפיה חייבים להיות מאושרים על ידי NIST ומוגדרים במצב שאושר על ידי FIPS.
מערכת ההפעלה המארחת לקוח/ה מערכת ההפעלה של המכונה הווירטואלית או של המארח ב-Bare Metal (כמו RHEL 9) חייבת לפעול במצב FIPS. מוודאים שהפקודה cat /proc/sys/crypto/fips_enabled מחזירה את הערך 1.
מישור הבקרה של כלי התזמור לקוח/ה צומת הבקרה שמריץ את ה-CLI או את התזמור של Ansible צריך להשתמש בהגדרת מערכת הפעלה שאושרה על ידי FIPS.
רכיבי הכלי לניהול סוכנים Google פותח על ידי Google, מופץ כ-RPM שתואמים למערכת הפעלה בסיסית עם FIPS, ומנהל באופן מאובטח את פעולות האשכול.
קבצים בינאריים של מסד נתונים Google קישור למודולים קריפטוגרפיים של OpenSSL במארח שאומתו על ידי FIPS, ואכיפת אלגוריתמים שאושרו על ידי FIPS לגיבוב סיסמאות (SCRAM-SHA-256) ולסט אלגוריתמים להצפנה (cipher suite) של TLS.
אישורים מ-CA בהתאמה אישית משותף אישורים דיגיטליים חייבים לעמוד בתקני FIPS בנוגע לחוזק המפתח ולאלגוריתמים של החתימה. שרשרת האישורים צריכה להגיע עד לרשות אישורי בסיס (Root CA) שתואמת לתקן FIPS.

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

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

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

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

מזהה STIG או SRG תיאור אמצעי הבקרה לאבטחה התנהגות ברירת המחדל של הפלטפורמה והמפעיל פעולה או הגדרה שנדרשת מצד הלקוח
V-233535 התראה מיידית לנציגי התמיכה על כשלים ביומן הביקורת. ניתוחי שגיאות סטנדרטיים נכתבים אל stdout ו-stderr. הלקוח צריך להגדיר מדדים של SIEM או של העברת יומנים שיופעלו כשההטמעה תרד.
V-233599 התראה לצוות התמיכה כששטח האחסון של הביקורת מגיע ל-75% מהקיבולת. מדדי מערכת הקבצים נחשפים דרך נקודות קצה רגילות של Prometheus. הלקוח צריך להגדיר כללי התראה ב-Prometheus וב-Grafana כדי להודיע לתמיכה כשמקום בכונן היומן חורג מ-75%.
V-233610 העברת נתוני הביקורת למתקן נפרד של יומן רציף. יומני הביקורת נכתבים באופן קבוע בספריית היומנים המקומית. הלקוח צריך להגדיר מעביר יומנים כדי להעביר קובצי יומן באופן רציף ל-SIEM מרכזי.
V-233603 מומלץ להסתמך רק על אישורים של ישויות קצה שהונפפו על ידי תשתית של מפתח ציבורי (PKI) או על ידי רשויות אישורים (CA) שאושרו. ‫Orchestrator משתמש בהגדרות 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 למידע מסווג במנוחה. חבילות RPM מסתמכות על ספריות מאובטחות ומוקשחות של RHEL 9. הלקוח צריך לוודא שמצב FIPS 140 מופעל בליבת Linux של המארח הבסיסי.
V-233515 שילוב עם מנגנוני אימות ברמת הארגון של AD ו-LDAP. מסד הנתונים תומך בהגדרות אימות בהתאמה אישית. הלקוח צריך למפות את הזהויות ב-AD וב-LDAP להגדרות של אשכול מסד הנתונים.
V-233583 שימוש במודולים קריפטוגרפיים שאושרו על ידי FIPS לגיבוב. חבילות RPM מסתמכות על מודולי OpenSSL FIPS של המארח לפונקציות גיבוב. הלקוח צריך להפעיל את מצב FIPS במערכת ההפעלה של המארח.
V-233585 שימוש בהצפנה מאומתת FIPS כדי להגן על מידע לא מסווג. הצפנת התקשורת והאחסון באמצעות צפנים שתואמים לתקן FIPS. הלקוח צריך לוודא שהמחשבים המארחים מאומתים לפי תקן FIPS.
V-233619 שימוש במודולים קריפטוגרפיים עם אישור FIPS לכל הפעולות. אכיפה של קובצי RPM בינאריים שמוכנים ל-FIPS. הלקוח צריך להפעיל את מצב FIPS בקרנל המארח.
V-233623 מריצים את מערכת ניהול מסדי הנתונים במארח עם מודול OpenSSL FIPS מאושר. מסד הנתונים מסתמך על הגדרות OpenSSL FIPS של המארח. הלקוח צריך לוודא שמודול OpenSSL של המארח תואם לרשימת ה-FIPS שאושרה על ידי NIST.
V-233615 למפות זהויות שאומתו באמצעות PKI לחשבונות המשתמשים המשויכים. המסד נתונים משתמש באימות סיסמה מאובטח SCRAM-SHA-256 לזהויות. אם הלקוח לא משתמש בכניסה ישירה באמצעות סיסמה, הוא צריך למפות תפקידים בספרייה ארגונית חיצונית לתפקידים במסד הנתונים.
V-233540 הגבלת הגישה לחשבון ההתקנה של מסד הנתונים למשתמשים מורשים בלבד. ‫RPM מגביל את הרשאות הקבצים וההרצה למשתמש postgres. הלקוח חייב לנעול את הגישה לצומת המארח, למשל באמצעות הגבלות SSH, כדי למנוע גישה לא מורשית של מסוף למכונות הווירטואליות.