אבטחה, פרטיות, סיכונים ותאימות ב-Knowledge Catalog

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

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

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

‫Knowledge Catalog משתמש בממשקי ה-API הבאים:

כדי להתחיל, אפשר לעיין במאמר בנושא הפעלת Knowledge Catalog.

אימות לניהול של Google Cloud

אדמינים ומפתחים שיוצרים ומנהלים מופעים של Knowledge Catalog צריכים לעבור אימות ב- Google Cloud כדי לאמת את הזהות שלהם ואת הרשאות הגישה שלהם. צריך להגדיר לכל משתמש חשבון משתמש מנוהל באמצעות Cloud Identity,‏ Google Workspace או ספק זהויות שאיחדתם עם Cloud Identity או Google Workspace. מידע נוסף זמין במאמר סקירה כללית על ניהול זהויות ב-Google.

אחרי שיוצרים את חשבונות המשתמשים, כדאי ליישם שיטות מומלצות לאבטחה, כמו כניסה יחידה (SSO) ואימות דו-שלבי.

אימות לגישה למשאבים ב- Google Cloud

איחוד שירותי אימות הזהות של כוח עבודה מאפשר להשתמש בספק זהויות חיצוני (IdP) כדי לאמת את משתמשי כוח העבודה, כך שהם יוכלו לגשת למשאבי Google Cloud . משתמשים באיחוד שירותי אימות הזהות של כוח העבודה כשמשתמשים צריכים גישה פרוגרמטית למשאבים שלכם Google Cloud ואתם מאחסנים את פרטי הכניסה של המשתמשים בספקי זהויות שתומכים ב-OpenID Connect ‏ (OIDC) או ב-Security Assertion Markup Language ‏ (SAML).

איחוד שירותי אימות הזהות של עומסי עבודה מאפשר לכם להשתמש ב-IdP החיצוני כדי להעניק לעומסי העבודה המקומיים או מרובי העננים (multi-cloud) גישה למשאבי Google Cloud , בלי להשתמש במפתח של חשבון שירות. אפשר להשתמש באיחוד שירותי אימות הזהות עם ספקי זהויות כמו Amazon Web Services ‏ (AWS),‏ Microsoft Entra ID,‏ GitHub או Okta.

מידע נוסף על התמיכה של Knowledge Catalog בזהות מאוחדת זמין במאמר שירותים שתומכים באיחוד זהויות.

למידע נוסף על אימות ב- Google Cloud, ראו אימות.

ניהול זהויות והרשאות גישה

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

מידע נוסף על שימוש ב-IAM עם Knowledge Catalog זמין במאמר ניהול גישה באמצעות IAM. מידע נוסף על הגדרת IAM זמין במאמר סקירה כללית על IAM.

אתם יכולים להקצות תפקידים מוגדרים מראש ותפקידים בהתאמה אישית למשאבים של Knowledge Catalog, כמו קבוצות ורשומות.

חשבונות שירות של Knowledge Catalog

כשמפעילים את Knowledge Catalog, ‏ Google יוצרת בשבילכם חשבונות שירות. חשבון שירות הוא סוג מיוחד של חשבון Google לא אינטראקטיבי, שמשמש בדרך כלל אפליקציה או עומס עבודה, כמו מכונה של Compute Engine, ולא אנשים. אפליקציות משתמשות בחשבונות שירות כדי לגשת ל-Google APIs.

סוכני שירות

כדי לאפשר ל-Knowledge Catalog לגשת למשאבים שלכם בשמכם, Google Cloud יוצרת חשבון שירות מיוחד שנקרא סוכן שירות.

כשמפעילים את Knowledge Catalog, נוצרים סוכני השירות הבאים של Knowledge Catalog:

  • service-PROJECT_NUMBER@gcp-sa-dataplex.iam.gserviceaccount.com
  • service-org-ORGANIZATION_NUMBER@gcp-sa-dataplex.iam.gserviceaccount.com
  • service-org-ORGANIZATION_NUMBER@gcp-sa-dataplex-cmek.iam.gserviceaccount.com
  • service-PROJECT_NUMBER@gcp-sa-datalineage.iam.gserviceaccount.com

מידע נוסף על סוכני שירות של Knowledge Catalog זמין במאמר בנושא הפעלת מפתחות הצפנה בניהול הלקוח.

כללי המדיניות של Knowledge Catalog

כללי מדיניות הארגון שהוגדרו מראש ורלוונטיים ל-Knowledge Catalog כוללים את ההגדרות הבאות:

  • הגבלת מיקום של משאבים (constraints/gcp.resourceLocations)
  • הגבלת הפרויקטים שיכולים לספק מפתחות קריפטוגרפיים של KMS ל-CMEK ‏ (constraints/gcp.restrictCmekCryptoKeyProjects)
  • הגבלת השירותים שיכולים ליצור משאבים ללא CMEK (constraints/gcp.restrictNonCmekServices)
  • הגבלת השימוש בנקודת קצה (constraints/gcp.restrictEndpointUsage)
  • הגבלת השימוש בשירות המשאבים (constraints/gcp.restrictServiceUsage)
  • הגבלת השימוש בסט האלגוריתמים להצפנה (cipher suite) ב-TLS (constraints/gcp.restrictTLSCipherSuites)

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

מידע נוסף על מדיניות ארגונית זמין במאמר ניהול משאבים ב-Knowledge Catalog באמצעות אילוצים מותאמים אישית.

אבטחת רשת

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

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

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

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

הגנה על נתונים ופרטיות

הנתונים שמאוחסנים ב- Google Cloudמוצפנים ב-Knowledge Catalog באמצעות הצפנה שמוגדרת כברירת מחדל. דוגמה לנתונים:

  • שם הקבוצה והשם של הרשומה
  • הגדרות של תגים ומאפיינים
  • מאפייני מטא-נתונים, תיאורים ותגים
  • מונחים וקשרים במילון המונחים העסקי

אפשר לגשת לנתונים האלה רק באמצעות מופעים של Knowledge Catalog.

אתם יכולים להפעיל מפתחות הצפנה בניהול הלקוח (CMEK) כדי להצפין את הנתונים במנוחה. ב-CMEK, המפתחות מאוחסנים ב-Cloud Key Management Service ‏ (Cloud KMS) כמפתחות שמוגנים על ידי תוכנה או כמפתחות שמוגנים על ידי חומרה באמצעות Cloud HSM, אבל אתם מנהלים אותם. כדי להקצות מפתחות הצפנה באופן אוטומטי, אפשר להפעיל את Cloud KMS Autokey. כשמפעילים את Autokey, מפתח יכול לבקש מפתח מ-Cloud KMS, וסוכן השירות מספק מפתח שתואם לכוונת המפתח. עם Cloud KMS Autokey, המפתחות זמינים לפי דרישה, הם עקביים ועומדים בשיטות המומלצות בתחום.

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

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

‫Knowledge Catalog תומך במיקום אחסון הנתונים עבור נתונים שמאוחסנים ב- Google Cloud. מיקום אחסון הנתונים מאפשר לכם לבחור את האזורים שבהם אתם רוצים שהנתונים שלכם יאוחסנו באמצעות המגבלה על מיקומי המשאבים במדיניות הארגון. אתם יכולים להשתמש במאגר משאבי ענן כדי לאמת את המיקום של משאבים בKnowledge Catalog.

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

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

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

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

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

ב-Knowledge Catalog נכתבים סוגי יומני הביקורת הבאים:

  • יומני הביקורת Admin Activity: כוללים פעולות ADMIN WRITE שכותבות מטא-נתונים או מידע על ההגדרות.

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

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

שקיפות גישה

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

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

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

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

אישורים ועמידה בדרישות

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

Knowledge Catalog קיבל מגוון אישורים, כולל האישורים הבאים:

  • ISO 27001
  • SOC 3
  • FedRAMP
  • DoD IL5
  • ITAR

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

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

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