במאמר הזה מובאת סקירה כללית של אמצעי בקרה שונים שתומכים באבטחה של AlloyDB ל-PostgreSQL ב- Google Cloud , וקישורים למידע נוסף על אופן ההגדרה של אמצעי הבקרה. אמצעי בקרה לאבטחה, כמו אפשרויות אבטחת רשת, מדיניות וניהול גישה, יכולים גם לעזור לכם לטפל בסיכונים העסקיים ולעמוד בדרישות הפרטיות והרגולטוריות שחלות על העסק שלכם.
האבטחה, הפרטיות, הסיכון והתאימות של AlloyDB ל-PostgreSQL מבוססים על מודל של אחריות משותפת. לדוגמה, Google מאבטחת את התשתית שבה פועלים AlloyDB ל-PostgreSQL ושירותים אחרים של Google Cloud , ומספקת לכם את היכולות שיעזרו לכם לנהל את הגישה לשירותים ולמשאבים שלכם. למידע נוסף על האופן שבו אנחנו מאבטחים את התשתית, אפשר לעיין בסקירה הכללית על תכנון האבטחה בתשתית של 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 צריכים לעבור אימות ב- Google Cloud כדי לאמת את הזהות שלהם ואת הרשאות הגישה שלהם. צריך להגדיר לכל משתמש חשבון משתמש מנוהל על ידי Cloud Identity, Google Workspace או ספק זהויות שנוצר איתו חשבון מאוחד עם Cloud Identity או Google Workspace. למידע נוסף, קראו את המאמר סקירה כללית של ניהול זהויות והרשאות גישה.
אחרי שיוצרים את חשבונות המשתמשים, כדאי ליישם שיטות מומלצות לאבטחה כמו כניסה יחידה (SSO) ואימות דו-שלבי. מידע נוסף על שיטות מומלצות לאימות מופיע במאמר בנושא ניהול זהויות וגישה.
ניהול זהויות והרשאות גישה
כדי לנהל תפקידים ב-IAM בהיקף גדול עבור האדמינים והמפתחים, כדאי ליצור קבוצות פונקציונליות נפרדות עבור תפקידי המשתמשים והאפליקציות השונים במסד הנתונים. מקצים לקבוצות את תפקידי ה-IAM או ההרשאות שנדרשים לניהול AlloyDB. כשמקצים תפקידים לקבוצות, חשוב לפעול לפי העיקרון של הרשאות מינימליות ולפי שיטות מומלצות אחרות לאבטחה ב-IAM. מידע נוסף זמין במאמר בנושא שיטות מומלצות לשימוש בקבוצות Google.
מידע נוסף על הגדרת IAM זמין במאמר סקירה כללית על IAM.
כשלקוחות משתמשים באימות מסד נתונים של IAM כדי לגשת ל-AlloyDB, אפשר גם להשתמש ב-IAM כדי לשלוט בגישה שלהם ל-AlloyDB. במאמר תפקידים והרשאות ב-IAM ל-AlloyDB תוכלו לקרוא מידע נוסף על התפקידים ב-IAM שנדרשים ל-AlloyDB.
אם אתם משתמשים ב-Auth Proxy או ב-Language Connectors (כפי שמתואר במאמר Application connectivity), אתם יכולים להשתמש ב-IAM כדי לשלוט בעומסי העבודה של האפליקציות שיכולים להתחבר ל-AlloyDB. מידע נוסף על שימוש ב-IAM עם שרת ה-Proxy לאימות זמין במאמר בחירת הגורם הראשי ב-IAM והכנתו לאימות. כדי להשתמש באימות אוטומטי של IAM עם AlloyDB Language Connectors, אפשר לעיין במאמר בנושא ניהול אימות 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, אתם יכולים להגדיר את AlloyDB לשימוש ב-CMEK. כללי המדיניות כוללים את הדברים הבאים:
- הגבלת השירותים שיכולים ליצור משאבים ללא 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 יכולים לבצע אוטומציה של תהליך האימות של IAM. מידע נוסף מופיע בסקירה הכללית על AlloyDB Language Connectors.
לאימות IAM יש את היתרונות הבאים:
- בקרת גישה מאוחדת: IAM מרכזת את בקרת הגישה לכל המשאבים ב- Google Cloud , כולל מסדי נתונים. אמצעי בקרה מאוחדים לגישה מאפשרים מדיניות עקבית וניהול קל יותר של משתמשים ותפקידים.
- ניהול פשוט יותר של פרטי הכניסה: המשתמשים לא צריכים סיסמאות נפרדות למסד הנתונים. אימות IAM מתבצע באמצעות פרטי הכניסה הקיימים לחשבון Google.
- אסימונים לטווח קצר: אימות IAM משתמש באסימוני גישה לטווח קצר, וכך מצמצם את הסיכון לדליפת סיסמאות או לפריצה לפרטי כניסה.
מחברים
אתם יכולים להשתמש ב-AlloyDB Auth Proxy או ב-AlloyDB Language Connector כדי להגדיר חיבור מוצפן ללקוח מסד הנתונים. AlloyDB Auth Proxy הוא פרוקסי בצד הלקוח שמשדרג באופן שקוף חיבורים ללא TLS לחיבורים עם TLS 1.3. מחברי השפה הם ספריות לקוח שמתחברות לשרת 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שכותבות מטא-נתונים או מידע על הגדרות. - יומני ביקורת גישה לנתונים: כוללים פעולות
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)
- חוק היבילות ואחריות הדיווח של ביטוח בריאות (HIPAA)
מידע נוסף על Google Cloud תאימות למסגרות רגולטוריות שונות ולאישורים זמין במרכז המשאבים בנושא תאימות.
AlloyDB תומך גם ב-Assured Workloads, שמאפשר לכם להחיל אמצעי בקרה על תיקיות ספציפיות בארגון שלכם ב-Google, שתומכות בדרישות רגולטוריות, אזוריות או ריבוניות. מידע נוסף זמין במאמר בנושא מוצרים נתמכים לפי חבילת בקרה.
המאמרים הבאים
- הגדרת עמידות באמצעות אשכולות.
- הפעלת גיבויים
- שימוש ב-Terraform לפריסת AlloyDB.
- אפשר להשתמש ב-Google Threat Intelligence כדי לעקוב אחרי איומים חיצוניים שרלוונטיים לעסק שלכם.