אבטחה, פרטיות, סיכון ותאימות ב-AlloyDB ל-PostgreSQL

כדי להגן על עומסי העבודה של AlloyDB ל-PostgreSQL ב- Google Cloud, לטפל בסיכונים עסקיים ולעמוד בדרישות של פרטיות ותאימות לתקנות, אתם יכולים להגדיר אמצעי בקרה לאבטחת הרשת, כללי מדיניות של הארגון, הצפנה וניהול זהויות והרשאות גישה.

האבטחה, הפרטיות, הסיכונים והתאימות של AlloyDB מבוססים על מודל של אחריות משותפת. לדוגמה, Google מאבטחת את התשתית שבה פועלים AlloyDB ושירותי Google Cloud אחרים, ומספקת לכם את היכולות שעוזרות לכם לנהל את הגישה לשירותים ולמשאבים שלכם. במאמר סקירה כללית על תכנון האבטחה בתשתית של Google תוכלו לקרוא איך Google מאבטחת את התשתית.

הארכיטקטורה של AlloyDB

התרשים הבא מציג את הרכיבים של ארכיטקטורת AlloyDB.

הארכיטקטורה של AlloyDB.

הרכיבים כוללים:

  • מכונות AlloyDB נפרסות בכמה אזורים כדי לאפשר זמינות גבוהה ועמידות.
  • אפליקציה ב- Google Cloud או בסביבה אחרת שמתחברת למכונה הראשית של AlloyDB. בתרשים מוצגת האפליקציה שפועלת באותו פרויקט ב- Google Cloud כמו AlloyDB, אבל אפשר גם להריץ את האפליקציה בפרויקט אחר בארגון ב-Google Cloud .
  • בסביבה היברידית, Cloud VPN או Cloud Interconnect יכולים לספק גישה למשאבים ברשת הארגונית.
  • גבולות גזרה לשירות שנוצרו באמצעות VPC Service Controls. בעזרת VPC Service Controls אתם יכולים לשלוט בתנועת הנתונים בין שירותים או משאבים של Google, ולהגדיר אבטחה היקפית מבוססת-הקשר.

מידע על נקודת הקצה של AlloyDB זמין במאמר AlloyDB API. כברירת מחדל, נקודת הקצה הזו לא ניתנת לניתוב באופן ציבורי, ולא יכולה לקבל תנועה נכנסת מרשתות ציבוריות. כדי לאפשר למכונות AlloyDB לקבל תנועה נכנסת דרך רשתות ציבוריות, קראו את המאמר התחברות באמצעות כתובת IP ציבורית.

למידע נוסף על מחברי AlloyDB, קראו את המאמר קישוריות של אפליקציות.

שירותים שהוקצו

כשמתחילים להשתמש ב-AlloyDB, מפעילים את ממשקי ה-API הבאים:

מידע נוסף זמין במאמר מדריך למתחילים: יצירת מסד נתונים והתחברות אליו.

אימות לניהול של 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.

אם אתם משתמשים ב-AlloyDB Auth Proxy או במחברי השפות ל-AlloyDB (כפי שמתואר בקטע קישוריות של אפליקציות), אתם יכולים להשתמש ב-IAM כדי לקבוע אילו עומסי עבודה של אפליקציות יכולים להתחבר ל-AlloyDB. במאמר בחירת חשבון המשתמש ב-IAM והכנתו לאימות מוסבר איך משתמשים ב-IAM עם שרת ה-proxy לאימות. כדי להשתמש באימות אוטומטי ב-IAM עם מחברי שפה, קראו את המאמר ניהול אימות ב-IAM.

חשבונות שירות וסוכני שירות שמוגדרים כברירת מחדל

חשבון שירות הוא סוג מיוחד של חשבון Google לא אינטראקטיבי, שמייצג משתמש לא אנושי שצריך לאמת ולאשר כדי לתת לו גישה לנתונים ב-Google APIs. מכיוון ש-AlloyDB הוא שירות שמנוהל במלואו, Google מנהלת את סוכן השירות של AlloyDB בשבילכם. כשמפעילים את AlloyDB, נוצר סוכן שירות של AlloyDB בפרויקט (service-PROJECT_NUMBER@gcp-sa-alloydb.iam.gserviceaccount.com). משאבי AlloyDB, כמו שרת PostgreSQL, משתמשים בסוכן השירות הזה כדי לפעול.

סוכני שירות הם התפקידים וההרשאות ב-IAM שחלק משירותי Google Cloudמשתמשים בהם כדי לגשת למשאבים שלכם ולפעול בשמכם. חשבון השירות המנוהל של AlloyDB משתמש בהרשאות ה-IAM של סוכן השירות של AlloyDB.

כללי מדיניות ל-AlloyDB

כללי המדיניות המוגדרים מראש של הארגון שחלים על AlloyDB קובעים אם AlloyDB יכול להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) כדי להצפין את הנתונים שלכם. אם אתם כפופים לדרישות רגולטוריות שמחייבות אתכם לשלוט בצורה טובה יותר במפתחות שמשמשים להצפנת נתונים במנוחה ב-AlloyDB, אתם יכולים להגדיר את AlloyDB לשימוש ב-CMEK. כללי המדיניות כוללים את:

  • הגבלת השירותים שיכולים ליצור משאבים בלי CMEK‏ (constraints/gcp.restrictNonCmekServices)

  • הגבלת הפרויקטים שיכולים לספק מפתחות קריפטוגרפיים של Cloud Key Management Service ‏ (Cloud KMS) ל-CMEK ‏ (constraints/gcp.restrictCmekCryptoKeyProjects)

מידע נוסף זמין במאמר שימוש במדיניות מוגדרת מראש של הארגון.

אתם יכולים להשתמש במדיניות ארגון בהתאמה אישית כדי להגדיר הגבלות על AlloyDB ברמת הפרויקט, התיקייה או הארגון. אם אתם מפעילים כתובות IP ציבוריות, Google ממליצה להגדיר אילוץ מדיניות בהתאמה אישית כדי לאכוף מי יכול להשתמש בכתובת ה-IP הציבורית. כדי לשפר את המדיניות, אתם יכולים להוסיף למדיניות שדות של מכונות AlloyDB (לדוגמה, הפעלת כתובת IP ציבורית או הפעלת כתובת IP ציבורית יוצאת). מידע נוסף זמין במאמר שימוש במדיניות ארגונית בהתאמה אישית.

אבטחת רשת

כברירת מחדל, Google מיישמת את הגנות ברירת המחדל על נתונים במעבר בכל שירותיGoogle Cloud , כולל מכונות AlloyDB שפועלות ב- Google Cloud. מידע נוסף על הגנות ברירת המחדל ברשת זמין במאמר הצפנה במעבר.

‫AlloyDB תומך בהצפנת TLS 1.3 לתקשורת בין מכונת מסד הנתונים לבין הלקוחות. ‫AlloyDB יוצר באופן אוטומטי את אישור השרת לחיבור הזה. כדי להשתמש באישורי לקוח לאימות הדדי, צריך להגדיר את מחברי השפות ל-AlloyDB (שמשתמשים באימות mTLS) או את שרת ה-Proxy לאימות ב-AlloyDB.

אם הארגון שלכם דורש זאת, אתם יכולים להגדיר אמצעי בקרה נוספים לאבטחה כדי להגן על התנועה ברשת Google Cloud ועל התנועה בין הרשת Google Cloud לבין הרשת של הארגון. כמה נקודות שכדאי לזכור:

  • ‫AlloyDB תומך ב-VPC Service Controls. בעזרת VPC Service Controls אתם יכולים לשלוט בתנועת הנתונים בשירותי Google ולהגדיר אבטחה היקפית מבוססת-הקשר. מידע נוסף על הגדרת VPC Service Controls זמין במאמר הגדרת VPC Service Controls.

  • אם אתם מפעילים כתובות IP ציבוריות, השתמשו במחברי השפות ל-AlloyDB ובמדיניות ארגונית בהתאמה אישית כדי לקבוע למי יש גישה למכונות של AlloyDB.

  • ב- Google Cloud, כדאי להשתמש ב-VPC משותף כטופולוגיית הרשת. VPC משותף מאפשר לנהל את הגדרות הרשת באופן מרוכז, תוך שמירה על הפרדה בין הסביבות.

  • כדי למקסם את האבטחה והאמינות של החיבור בין הרשת הארגונית ל-Google Cloud, השתמשו ב-Cloud VPN או ב-Cloud Interconnect. למידע נוסף, קראו את המאמר בחירת מוצרים של Network Connectivity.

מידע נוסף על שיטות מומלצות לאבטחת רשת זמין במאמרים הטמעה של אבטחה בגישת Zero Trust ובחירת עיצוב הרשת לאזור הנחיתה ב- Google Cloud .

קישוריות האפליקציה

אתם יכולים לאבטח את החיבור בין האפליקציות ל-AlloyDB בדרכים הבאות:

בתרשים הבא מוצגות אפשרויות הקישוריות.

אפשרויות הקישוריות של AlloyDB.

למידע נוסף על אפשרויות להגדרת חיבורים לשירותים ללא כתובת IP חיצונית, קראו את המאמר אפשרויות גישה פרטיות לשירותים.

אימות מסד נתונים

ב-AlloyDB יש את שיטות האימות הבאות ללקוחות של מסדי נתונים:

  • אימות מובנה של מסד נתונים באמצעות שם משתמש וסיסמה. ההרשאה נקבעת באמצעות הצהרות GRANT או REVOKE. מידע נוסף זמין במאמר ניהול תפקידי משתמשים ב-AlloyDB.
  • אימות באמצעות IAM, באמצעות חשבונות משתמשים ב-IAM כמו משתמשים וחשבונות שירות. מחברי השפות ל-AlloyDB יכולים להפוך את תהליך האימות ב-IAM לאוטומטי. מידע נוסף זמין במאמר סקירה כללית על מחברי שפות ל-AlloyDB. לאימות ב-IAM יש את היתרונות הבאים:
    • בקרת גישה מאוחדת: IAM מרכז את בקרת הגישה לכל המשאבים ב- Google Cloud , כולל מסדי נתונים. בקרת גישה מאוחדת מאפשרת מדיניות עקבית וניהול קל יותר של משתמשים ותפקידים.
    • פחות ניהול של פרטי כניסה: המשתמשים לא צריכים סיסמאות נפרדות למסד הנתונים. אימות IAM משתמש בפרטי כניסה לחשבון Google הקיימים שלהם.
    • טוקנים לטווח קצר: האימות ב-IAM משתמש בטוקני גישה לטווח קצר, וכך מפחית את הסיכון לדליפת סיסמאות או לפריצה לפרטי כניסה.

מחברים

אתם יכולים להשתמש ב-AlloyDB Auth Proxy או במחברי שפות ל-AlloyDB כדי להגדיר חיבור מוצפן ללקוח של מסד הנתונים. שרת ה-proxy לאימות של AlloyDB הוא שרת 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. כשמפעילים את Cloud KMS Autokey, המפתח יכול לבקש מפתח מ-Cloud KMS, וסוכן השירות מקצה מפתח שתואם לבקשה של המפתח. באמצעות Cloud KMS Autokey, המפתחות זמינים על פי דרישה, הם עקביים ופועלים לפי שיטות מקובלות בתחום.

בנוסף, AlloyDB תומך ב-Cloud External Key Manager ‏ (Cloud EKM), שמאפשר לאחסן את המפתחות במנהל מפתחות חיצוני מחוץ ל- Google Cloud. אם אתם משתמשים ב-Cloud EKM, הצדקות לבקשות גישה למפתחות מוסיפות שדה לבקשות של Cloud EKM שמאפשר לכם לראות את הסיבה לכל בקשה. עם שותפים נבחרים לניהול מפתחות חיצוניים, אתם יכולים לאשר או לדחות את הבקשות האלה באופן אוטומטי, על סמך ההצדקה.

איפה הנתונים מעובדים

ב-AlloyDB יש תמיכה במיקום אחסון הנתונים של הנתונים שמאוחסנים באשכול. מיקום אחסון הנתונים מאפשר לכם לבחור את האזורים שבהם הנתונים יאוחסנו באמצעות המגבלה על מיקומי המשאבים. אתם יכולים להשתמש במאגר משאבי ענן כדי לאמת את המיקום של משאבי AlloyDB.

אם אתם צריכים לאחסן נתונים במיקום ספציפי, אתם יכולים להגדיר את Assured Workloads. מידע נוסף זמין במאמר Assured Workloads ומיקום אחסון הנתונים.

פרטיות נתונים

כדי להגן על פרטיות הנתונים שלכם, AlloyDB פועל בהתאם לעקרונות הפרטיות הנפוצים.

‫AlloyDB פועל כמעבד מידע של נתוני הלקוחות. ‫Google פועלת כנאמנת מידע גם לגבי מידע כמו חיוב, ניהול חשבונות וזיהוי ניצול לרעה. מידע נוסף זמין בהודעת הפרטיות שלGoogle Cloud .

רישום ביומן ביקורת

ב-AlloyDB נכתבים הסוגים הבאים של יומני ביקורת:

  • יומני ביקורת של פעילות אדמין: כוללים פעולות ADMIN WRITE שכותבות מטא-נתונים או מידע על הגדרות אישיות.
  • יומני בקרת הרשאות גישה לנתונים: כוללים פעולות של ADMIN READ שקוראות מטא-נתונים או מידע על הגדרות אישיות. היומנים כוללים גם פעולות במסגרת ההרשאות DATA READ ו-DATA WRITE, שבהן נקראים או נכתבים נתונים שהמשתמשים סיפקו.
  • יומני ביקורת של אירועי מערכת: מזהים פעולות אוטומטיות של Google Cloud שמשנות את ההגדרות של משאבים.

מידע נוסף על יומני ביקורת ב-AlloyDB זמין במאמר רישום ביומן ביקורת של AlloyDB.

בנוסף, כדי לעמוד בדרישות הרגולטוריות, אתם יכולים להשתמש בתוסף pgAudit כדי להפעיל נתיב ביקורת של פקודות במסד הנתונים. היומנים של תוסף pgAudit כוללים פרטים על הפקודות שבוצעו, מתי הן בוצעו ומי ביצע אותן.

Access Transparency

אתם יכולים להשתמש ב"אישור גישה מראש" וב-Access Transparency כדי לשלוט בגישה של צוות התמיכה של Google למכונות AlloyDB. בעזרת אישור גישה מראש אתם יכולים לאשר או לדחות בקשות גישה של עובדי Google. יומני Access Transparency מספקים תובנות כמעט בזמן אמת כשאדמינים שלGoogle Cloud ניגשים למשאבים.

מעקב ותגובה לאירועים

אתם יכולים להשתמש במגוון כלים כדי לעקוב אחרי הביצועים והאבטחה של AlloyDB. כמה נקודות שכדאי לחשוב עליהן:

  • אתם יכולים להשתמש ב-Logs Explorer כדי להציג ולנתח יומני אירועים, וליצור מדדים מותאמים אישית והתראות.
  • אתם יכולים להשתמש בלוח הבקרה של תובנות המערכת של AlloyDB או בלוח הבקרה של Cloud Monitoring כדי לעקוב אחרי הביצועים של מכונות AlloyDB. מידע נוסף זמין במאמר מעקב אחרי מכונות.
  • מפעילים את התוסף pgAudit כדי לבדוק את הפעולות ב-AlloyDB (כמו פקודות ושאילתות שבוצעו במכונה של AlloyDB). היומנים האלה כוללים יומנים של מסד נתונים ב-PostgreSQL ויומנים של קונטיינרים לסוכנים של מישור הנתונים.
  • להגדיר את Security Command Center כך שיזהה נקודות חולשה ב-SQL ואיומים על AlloyDB (כמו הסלמת הרשאות). אתם יכולים להגדיר התראות ופלייבוקים למנתחים במרכז תפעול האבטחה (SOC) שלכם, כדי שהם יוכלו להגיב לממצאים.

אישורים ותאימות

העמידה בדרישות הרגולטוריות היא אחריות משותפת שלכם ושל Google.

‫AlloyDB קיבל הרבה אישורים, כולל:

מידע נוסף על העמידה של Google Cloud במסגרות רגולטוריות שונות ועל האישורים שלה מופיע ב-Compliance resource center.

ב-AlloyDB יש גם תמיכה ב-Assured Workloads, שמאפשר להחיל אמצעי בקרה על תיקיות ספציפיות בארגון ב-Google, שתומכות בדרישות רגולטוריות, אזוריות או ריבוניות. מידע נוסף זמין במאמר מוצרים נתמכים לפי חבילת אמצעי בקרה.

המאמרים הבאים