במסמך הזה מופיעה סקירה כללית של אמצעי בקרה שונים שתומכים באבטחה של AlloyDB ל-PostgreSQL ב-Google Cloud, וקישורים למידע נוסף על אופן ההגדרה של אמצעי הבקרה. אמצעי בקרה לאבטחה, כמו אפשרויות אבטחת רשת, מדיניות וניהול גישה, יכולים גם לעזור לכם לטפל בסיכונים עסקיים ולעמוד בדרישות הפרטיות והרגולטוריות שחלות על העסק שלכם. Google Cloud
האבטחה, הפרטיות, הסיכון והתאימות של AlloyDB ל-PostgreSQL מבוססים על מודל של אחריות משותפת. לדוגמה, Google מאבטחת את התשתית שבה פועלים AlloyDB ל-PostgreSQL ושירותים אחרים של Google Cloud Google, ומספקת לכם את היכולות שיעזרו לכם לנהל את הגישה לשירותים ולמשאבים שלכם. למידע נוסף על האופן שבו אנחנו מאבטחים את התשתית, אפשר לעיין בסקירה הכללית על תכנון האבטחה בתשתית של Google.
ארכיטקטורה של AlloyDB
בתרשים הבא מוצגים הרכיבים של ארכיטקטורת AlloyDB.
הרכיבים כוללים את:
- מופעלת פריסה של מופעי AlloyDB בכמה אזורים כדי לאפשר זמינות גבוהה ועמידות.
- אפליקציה ב- Google Cloud או בסביבה אחרת שמתחברת למופע הראשי של AlloyDB. בתרשים מוצגת אפליקציה שפועלת באותו פרויקט כמו AlloyDB, אבל אפשר גם להריץ את האפליקציה בפרויקט אחר בארגון. Google Cloud Google Cloud
- בסביבה היברידית, אפשר להשתמש ב-Cloud VPN או ב-Cloud Interconnect כדי לקבל גישה למשאבים ברשת הארגונית.
- גבולות גזרה לשירות שנוצרים באמצעות VPC Service Controls. בעזרת VPC Service Controls אפשר לשלוט בתנועת הנתונים בין שירותים או משאבים של Google ולהגדיר אבטחת גבולות גזרה מבוססת-הקשר.
מידע על נקודת הקצה של AlloyDB זמין במאמר בנושא AlloyDB API. כברירת מחדל, נקודת הקצה הזו לא ניתנת לניתוב ציבורי ולא יכולה לקבל תנועה נכנסת מרשתות ציבוריות. כדי לאפשר למופעי AlloyDB לקבל תנועה נכנסת ברשתות ציבוריות, אפשר לעיין במאמר חיבור באמצעות כתובת IP ציבורית.
מידע על מחברים של AlloyDB זמין במאמר קישוריות של אפליקציות.
שירותים שהוקצו
כשמתחילים להשתמש ב-AlloyDB, מפעילים את ממשקי ה-API הבאים:
alloydb.googleapis.comcompute.googleapis.comcloudresourcemanager.googleapis.comservicenetworking.googleapis.com
מידע נוסף זמין במאמר מדריך למתחילים: יצירה של מסד נתונים וחיבור אליו.
אימות לניהול של Google Cloud
אדמינים ומפתחים שיוצרים מופעי AlloyDB ומנהלים אותם צריכים לעבור אימות כדי לוודא את הזהות שלהם ואת הרשאות הגישה שלהם. צריך להגדיר לכל משתמש חשבון משתמש שמנוהל על ידי Cloud Identity, Google Workspace או ספק זהויות שביצעתם לו פדרציה עם Cloud Identity או Google Workspace. למידע נוסף, אפשר לעיין במאמר סקירה כללית של ניהול זהויות וגישה. Google Cloud
אחרי שיוצרים את חשבונות המשתמשים, כדאי ליישם שיטות מומלצות לאבטחה, כמו כניסה יחידה (SSO) ואימות דו-שלבי. מידע נוסף על שיטות מומלצות לאימות זמין במאמר ניהול זהויות וגישה.
ניהול זהויות והרשאות גישה
כדי לנהל תפקידים ב-IAM בקנה מידה גדול עבור האדמינים והמפתחים, כדאי ליצור קבוצות פונקציונליות נפרדות עבור תפקידי המשתמשים והאפליקציות השונים במסד הנתונים. מקצים לקבוצות את תפקידי ה-IAM או ההרשאות שנדרשים לניהול AlloyDB. כשמקצים תפקידים לקבוצות, חשוב לפעול לפי העיקרון של הרשאות מינימליות ולפי שיטות מומלצות אחרות לאבטחה ב-IAM. מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש בקבוצות Google.
מידע נוסף על הגדרת IAM זמין במאמר סקירה כללית על IAM.
כשלקוחות משתמשים באימות מסד נתונים של IAM כדי לגשת ל-AlloyDB, אתם יכולים להשתמש ב-IAM גם כדי לשלוט בגישה שלהם ל-AlloyDB. במאמר תפקידים והרשאות ב-IAM ל-AlloyDB יש מידע נוסף על התפקידים ב-IAM שנדרשים ל-AlloyDB.
אם אתם משתמשים בשרת ה-Proxy לאימות או במחברים של שפות (כפי שמתואר במאמר קישוריות לאפליקציות), אתם יכולים להשתמש ב-IAM כדי לקבוע אילו עומסי עבודה של אפליקציות יכולים להתחבר ל-AlloyDB. מידע נוסף על שימוש ב-IAM עם שרת ה-Proxy לאימות זמין במאמר בחירת הגורם המורשה ב-IAM והכנתו להרשאה. כדי להשתמש באימות אוטומטי של IAM עם המחברים של שפות ב-AlloyDB, אפשר לעיין במאמר ניהול אימות IAM.
חשבונות שירות וסוכני שירות שמוגדרים כברירת מחדל
חשבון שירות הוא סוג מיוחד של חשבון Google לא אינטראקטיבי שמייצג משתמש לא אנושי, שצריך לאמת ולאשר כדי לתת לו גישה לנתונים ב-Google APIs. AlloyDB הוא שירות בניהול מלא, ולכן Google מנהלת את חשבון השירות שלכם ב-AlloyDB בשמכם. כשמפעילים את AlloyDB, נוצר חשבון שירות של AlloyDB עבור הפרויקט (service-PROJECT_NUMBER-gcp-sa-alloydb-iam.gserviceaccount.com). משאבי AlloyDB, כמו שרת PostgreSQL, משתמשים בחשבון השירות הזה כדי לפעול.
סוכני שירות הם תפקידים והרשאות ב-IAM שחלק מהשירותים של Google CloudGoogle Cloud משתמשים בהם כדי לגשת למשאבים שלכם ולפעול בשמכם. חשבון השירות המנוהל של AlloyDB משתמש בהרשאות IAM של סוכן השירות של AlloyDB.
מדיניות בנושא AlloyDB
מדיניות הארגון המוגדרת מראש שחלה על AlloyDB קובעת אם AlloyDB יכול להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) כדי להצפין את הנתונים שלכם. כדאי להגדיר את AlloyDB לשימוש ב-CMEK אם אתם מחויבים על פי תקנות לשליטה רבה יותר במפתחות שמשמשים להצפנה של נתונים באחסון ב-AlloyDB. כללי המדיניות כוללים את הדברים הבאים:
- הגבלת השירותים שיכולים ליצור משאבים בלי CMEK
(
constraints/gcp.restrictNonCmekServices) - הגבלת הפרויקטים שיכולים לספק מפתחות קריפטוגרפיים של Cloud KMS ל-CMEK (
constraints/gcp.restrictCmekCryptoKeyProjects)
מידע נוסף מופיע במאמר בנושא שימוש במדיניות ארגונית מוגדרת מראש.
אתם יכולים להשתמש במדיניות ארגונית בהתאמה אישית כדי להגדיר הגבלות על AlloyDB ברמת הפרויקט, התיקייה או הארגון. אם מפעילים כתובות IP ציבוריות, מומלץ להגדיר אילוץ מדיניות בהתאמה אישית כדי לקבוע מי יכול להשתמש בכתובת ה-IP הציבורית. כדי לשפר את המדיניות, אפשר להוסיף למדיניות שדות של מכונות AlloyDB (לדוגמה, הפעלת כתובת IP ציבורית או הפעלת כתובת IP ציבורית יוצאת). מידע נוסף זמין במאמר בנושא שימוש במדיניות מותאמת אישית לארגון.
אבטחת רשת
כברירת מחדל, Google מיישמת על הנתונים במעבר את הגנות ברירת המחדל בכלGoogle Cloud השירותים, כולל מופעי AlloyDB שפועלים ב- Google Cloud. מידע נוסף על אמצעי ההגנה שמוגדרים כברירת מחדל ברשת זמין במאמר הצפנה במעבר.
AlloyDB תומך בהצפנת TLS 1.3 לתקשורת בין מופע מסד הנתונים לבין לקוחות. AlloyDB יוצר באופן אוטומטי את אישור השרת לחיבור הזה. כדי להשתמש באישורים של לקוחות לאימות הדדי, צריך להגדיר את AlloyDB Language Connector (שמשתמש באימות mTLS) או את AlloyDB Auth Proxy.
אם הארגון שלכם דורש זאת, אתם יכולים להגדיר אמצעי בקרה נוספים לאבטחה כדי להגן על התנועה ברשת Google Cloud ועל התנועה בין רשת Google Cloud לרשת הארגונית. כדאי לשקול את האפשרויות הבאות:
AlloyDB תומך ב-VPC Service Controls. בעזרת VPC Service Controls תוכלו לשלוט בתנועת הנתונים בשירותי Google ולהגדיר אבטחה היקפית מבוססת-הקשר. מידע נוסף על הגדרת VPC Service Controls זמין במאמר הגדרת VPC Service Controls.
- אם מפעילים כתובות IP ציבוריות, צריך להשתמש ב-AlloyDB Language Connectors ובמדיניות ארגונית מותאמת אישית כדי לקבוע למי יש גישה למכונות AlloyDB.
באיור Google Cloud, כדאי להתייחס לVPC משותף כאל טופולוגיית הרשת. VPC משותף מספק ניהול ריכוזי של הגדרות הרשת, תוך שמירה על הפרדה בין הסביבות.
כדי למקסם את האבטחה והמהימנות של החיבור בין הרשת הארגונית לביןGoogle Cloud, מומלץ להשתמש ב-Cloud VPN או ב-Cloud Interconnect. למידע נוסף, אפשר לקרוא את המאמר בחירת מוצר של Network Connectivity.
מידע נוסף על שיטות מומלצות לאבטחת הרשת זמין במאמרים בנושא הטמעה של גישת אפס אמון ובחירת עיצוב הרשת לאזור הנחיתה ב- Google Cloud .
קישוריות לאפליקציות
אפשר לאבטח את החיבור בין אפליקציות לבין AlloyDB באמצעות השיטות הבאות:
- AlloyDB Auth Proxy או AlloyDB Language Connector, כדי להגדיר מנהרת TCP מאובטחת למופע AlloyDB.
- אימות מסד נתונים.
- חיבור לרשת (VPC) מאפליקציית serverless כדי לחבר את AlloyDB ישירות ל-Cloud Run.
- Private Service Connect או גישה לשירותים פרטיים כדי להתחבר לאפליקציה ב-VPC אחר ב- Google Cloud באמצעות כתובת ה-IP הפרטית של AlloyDB. כדאי להשתמש בשיטה הזו כדי לשמור את התנועה ב- Google Cloud. אם רוצים להשתמש ב-Private Service Connect, צריך להגדיר אותו כשיוצרים את אשכול מסד הנתונים של AlloyDB.
בתרשים הבא מוצגות אפשרויות הקישוריות.
מידע נוסף על אפשרויות להגדרת חיבורים לשירותים ללא כתובת IP חיצונית זמין במאמר אפשרויות גישה פרטיות לשירותים.
אימות מסד נתונים
AlloyDB מספק את שיטות האימות הבאות ללקוחות של מסדי נתונים:
- אימות מובנה של מסד נתונים באמצעות שם משתמש וסיסמה. ההרשאה נקבעת באמצעות הצהרות
GRANTאוREVOKE. מידע נוסף זמין במאמר ניהול תפקידי משתמש ב-AlloyDB. - אימות IAM באמצעות חשבונות IAM, כמו משתמשים וחשבונות שירות.
המחברים של AlloyDB Language יכולים לבצע אוטומציה של תהליך האימות של IAM. מידע נוסף מופיע בסקירה הכללית על AlloyDB Language Connectors.
לאימות IAM יש את היתרונות הבאים:
- בקרת גישה מאוחדת: IAM מרכזת את בקרת הגישה לכל המשאבים ב- Google Cloud , כולל מסדי נתונים. אמצעי בקרה מאוחדים לגישה מאפשרים מדיניות עקבית וניהול קל יותר של משתמשים ותפקידים.
- פחות ניהול של פרטי כניסה: המשתמשים לא צריכים סיסמאות נפרדות למסד הנתונים. האימות ב-IAM מתבצע באמצעות פרטי הכניסה הקיימים שלהם לחשבון Google.
- אסימונים לטווח קצר: אימות IAM משתמש באסימוני גישה לטווח קצר, וכך מצמצם את הסיכון לדליפת סיסמאות או לפריצה לפרטי כניסה.
מחברים
אתם יכולים להשתמש בAlloyDB Auth Proxy או בAlloyDB Language Connector כדי להגדיר חיבור מוצפן ללקוח מסד הנתונים. AlloyDB Auth Proxy הוא שרת proxy בצד הלקוח שמשדרג באופן שקוף חיבורים ללא TLS לחיבורי TLS 1.3. Language Connector הם ספריות לקוח שמתחברות לשרת proxy באשכול AlloyDB. שני המחברים משתמשים ב-IAM כדי לאשר את החיבור ומגנים על החיבור באמצעות mTLS. לחלופין, אתם יכולים להגדיר אימות ללא סיסמה במקום אימות IAM.
אם אתם משתמשים ב-Auth Proxy, כדאי לעיין בשיטות המומלצות לשימוש ב-AlloyDB Auth Proxy.
הגנה על נתונים ופרטיות
בקטע הזה מוסבר איך AlloyDB מגן על הנתונים שלכם ועל הפרטיות של הנתונים האלה.
AlloyDB מצפין את הנתונים שמאוחסנים באשכול (לדוגמה, שם המכונה, הגדרת המכונה, תוכן הטבלה, שמות השורות ופונקציות בהתאמה אישית) באמצעות הצפנה כברירת מחדל. אפשר לגשת לנתונים האלה רק באמצעות מכונות AlloyDB.
אתם יכולים להפעיל מפתחות הצפנה בניהול הלקוח (CMEK) כדי להצפין את נתוני האשכול במנוחה. ב-CMEK, המפתחות מאוחסנים ב-Cloud KMS כמפתחות מוגנים על ידי תוכנה או כמפתחות מוגנים על ידי חומרה (עם Cloud HSM), אבל אתם מנהלים אותם. כדי להקצות מפתחות הצפנה באופן אוטומטי, אפשר להפעיל את Cloud KMS Autokey. כשמפעילים את Autokey, מפתחן יכול לבקש מפתח מ-Cloud KMS, וסוכן השירות מספק מפתח שתואם לכוונת המפתחן. עם Cloud KMS Autokey, המפתחות זמינים לפי דרישה, הם עקביים ועומדים בשיטות המומלצות בתעשייה.
בנוסף, AlloyDB תומך ב-Cloud External Key Manager (Cloud EKM), שמאפשר לכם לאחסן את המפתחות במנהל מפתחות חיצוני מחוץ ל- Google Cloud. אם אתם משתמשים ב-Cloud EKM, Key Access Justifications מוסיף שדה לבקשות שלכם ב-Cloud EKM, שמאפשר לכם לראות את הסיבה לכל בקשה. עם שותפים נבחרים לניהול מפתחות חיצוני, אתם יכולים לאשר או לדחות את הבקשות האלה באופן אוטומטי, על סמך ההצדקה.
איפה הנתונים מעובדים
AlloyDB תומך בשמירת נתונים במאגר מקומי של הנתונים שמאוחסנים באשכול. שמירת נתונים במאגר מקומי מאפשרת לכם לבחור את האזורים שבהם אתם רוצים לאחסן את הנתונים באמצעות הגבלת המדיניות על מיקום המשאבים. אתם יכולים להשתמש במאגר משאבי ענן כדי לוודא את המיקום של משאבי AlloyDB.
אם אתם צריכים שהנתונים בשימוש יהיו במיקום מסוים, אתם יכולים להגדיר Assured Workloads. למידע נוסף, ראו Assured Workloads ומיקום של נתונים.
פרטיות נתונים
כדי להגן על פרטיות הנתונים, AlloyDB עומד בדרישות של עקרונות הפרטיות המשותפים.
AlloyDB פועל כמעבד נתונים של נתוני לקוחות. Google פועלת גם כנאמן מידע לגבי מידע כמו חיוב, ניהול חשבונות וזיהוי שימוש לרעה. למידע נוסף, אפשר לעיין בGoogle Cloud הודעת הפרטיות.
רישום ביומן ביקורת
AlloyDB כותב את סוגי יומני הביקורת הבאים:
- יומני הביקורת Admin Activity: כוללים פעולות
ADMIN WRITEשכותבות מטא-נתונים או מידע על ההגדרות. - יומני הביקורת Data Access: כוללים פעולות
ADMIN READשבהן נקרא מידע ממטא-נתונים או מהגדרות. היומנים כוללים גם פעולות שלDATA READו-DATA WRITEשבהן נקראים או נכתבים נתונים שהמשתמשים סיפקו. - יומני ביקורת System Event: מזהים רישום של פעולות אוטומטיות שמשנות את ההגדרות של משאבים. Google Cloud
מידע נוסף זמין במאמר בנושא יומני ביקורת של AlloyDB.
בנוסף, כדי לעמוד בדרישות הרגולטוריות, אפשר להשתמש בתוסף pgAudit כדי להפעיל שביל ביקורת של פקודות מסד נתונים. יומני התוסף pgAudit כוללים פרטים על הפקודות שבוצעו, מתי הן בוצעו ומי ביצע אותן.
שקיפות גישה
אתם יכולים להשתמש ב-Access Approval וב-Access Transparency כדי לשלוט בגישה למופעי AlloyDB של אנשי Google שתומכים בשירות. אישור גישה מאפשר לכם לאשר או לדחות בקשות גישה של עובדי Google. יומני Access Transparency מספקים תובנות כמעט בזמן אמת כשGoogle Cloud אדמינים ניגשים למשאבים.
מעקב ותגובה לאירועים
אתם יכולים להשתמש במגוון כלים כדי לעקוב אחרי הביצועים והאבטחה של AlloyDB. כמה נקודות שכדאי לחשוב עליהן:
- אפשר להשתמש ב-Logs Explorer כדי להציג ולנתח יומני אירועים וליצור מדדים מותאמים אישית והתראות.
- כדי לעקוב אחרי הביצועים של מופעי AlloyDB, אפשר להשתמש בלוח הבקרה של תובנות המערכת של AlloyDB או בלוח הבקרה של Cloud Monitoring. למידע נוסף, אפשר לעיין במאמר בנושא מעקב אחרי מופעים.
- מפעילים את התוסף pgAudit כדי לבצע ביקורת על פעולות ב-AlloyDB (כמו פקודות ושאילתות שבוצעו במכונת AlloyDB). היומנים האלה כוללים יומנים של מסד נתוני PostgreSQL ויומנים של מאגרי מידע של סוכני מישור הנתונים.
- מגדירים את Security Command Center לזיהוי נקודות חולשה ב-SQL ואיומים ב-AlloyDB (כמו העלאת הרשאות). אתם יכולים להגדיר התראות ומדריכים לאנליסטים במרכז האבטחה (SOC) שלכם, כדי שהם יוכלו להגיב לממצאים.
אישורים ועמידה בדרישות
העמידה בדרישות הרגולטוריות היא אחריות משותפת שלכם ושל Google.
AlloyDB קיבל אישורים רבים, כולל האישורים הבאים:
- הארגון הבינלאומי לתקינה (ISO) 27001, ISO 27017, ISO 27018, ISO 27701
- Service and Organization Controls (SOC) 1, SOC 2, SOC 3
- תקני אבטחת נתונים בתעשיית כרטיסי התשלום (PCI DSS)
- Health Insurance Portability and Accountability Act (חוק היבילות ואחריות הדיווח של ביטוח בריאות, HIPAA)
מידע נוסף על Google Cloud תאימות למסגרות רגולטוריות שונות ולאישורים זמין במרכז המשאבים בנושא תאימות.
AlloyDB תומך גם ב-Assured Workloads, שמאפשרת להחיל אמצעי בקרה על תיקיות ספציפיות בארגון שלכם ב-Google, שתומכות בדרישות רגולטוריות, אזוריות או ריבוניות. למידע נוסף, אפשר לעיין במאמר מוצרים נתמכים לפי חבילת אמצעי בקרה.
המאמרים הבאים
- הגדרת עמידות באמצעות אשכולות.
- הפעלת הגיבויים
- שימוש ב-Terraform לפריסת AlloyDB.
- אפשר להשתמש ב-Google Threat Intelligence כדי לעקוב אחרי איומים חיצוניים שרלוונטיים לעסק שלכם.