הפעלת מפתחות הצפנה בניהול הלקוח

במאמר הזה מוסבר איך להצפין נתונים ב-Knowledge Catalog (לשעבר Dataplex Universal Catalog) באמצעות מפתחות הצפנה בניהול הלקוח (CMEK).

סקירה כללית

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

אם אתם רוצים לשלוט במפתחות ההצפנה, אתם יכולים להשתמש במפתחות הצפנה בניהול הלקוח (CMEK) ב-Cloud KMS עם שירותים שמשולבים ב-CMEK, כולל Knowledge Catalog. כשמשתמשים במפתחות של Cloud KMS, אפשר לשלוט ברמת ההגנה, במיקום, בלוח הזמנים של הרוטציה, בהרשאות השימוש והגישה ובגבולות הקריפטוגרפיים שלהם. באמצעות Cloud KMS אתם יכולים גם לעקוב אחרי השימוש במפתחות, לצפות ביומני הביקורת ולשלוט במחזורי החיים של המפתחות. במקום ש-Google תהיה הבעלים של מפתחות ההצפנה (KEK) הסימטריים שמגינים על הנתונים שלכם ותנהל אותם, אתם שולטים במפתחות האלה ומנהלים אותם ב-Cloud KMS.

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

ב-Knowledge Catalog נעשה שימוש במפתח CMEK אחד לכל מיקום, לכל המשאבים של Knowledge Catalog.

אתם יכולים להגדיר מפתח CMEK ברמת הארגון ב-Knowledge Catalog.

מידע נוסף על CMEK באופן כללי, כולל מתי ולמה להפעיל אותו, זמין במאמר מפתחות הצפנה בניהול הלקוח (CMEK).

היתרונות של CMEK

באמצעות CMEK אפשר:

• ניהול פעולות במחזור החיים של המפתחות והרשאות הגישה.
• מעקב אחרי השימוש במפתחות באמצעות Key Inventory API ומרכזי הבקרה של Key Usage ב-Cloud KMS, שמאפשרים לראות דברים כמו אילו מפתחות מגינים על אילו משאבים. ב-Cloud Logging אפשר לראות מתי ניגשו למפתחות ומי ניגש אליהם.
• לעמוד בדרישות רגולטוריות ספציפיות באמצעות ניהול מפתחות ההצפנה.

איך CMEK עובד עם Knowledge Catalog

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

התכונות הנתמכות

• ב-Knowledge Catalog אפשר להשתמש בהצפנת CMEK בתכונות הבאות:

  • איכות נתונים אוטומטית
  • יצירת פרופיל נתונים
  • איתור נתונים
  • תובנות מנתונים
  • Knowledge Catalog
  • מילון המונחים הארגוני
  • חיפוש ב-Knowledge Catalog

• בשושלת נתונים לא מאוחסנים נתונים רגישים או תוכן ליבה של הלקוח, ולכן לא נדרשת הצפנת CMEK.

• לקוחות Assured Workloads לא יכולים להשתמש בתכונות אחרות של Knowledge Catalog כי הצפנת CMEK לא נתמכת בהן.

• לקוחות שלא משתמשים ב-Assured Workloads יכולים להשתמש בתכונות אחרות, אבל הנתונים מוצפנים באמצעות הצפנת ברירת המחדל של Google.

לתשומת ליבכם

• כברירת מחדל, כל ארגון מוגדר באמצעות הצפנת ברירת המחדל של Google.
• אדמין של הארגון (roles/resourcemanager.organizationAdmin) יכול לעבור ל-CMEK ב-Knowledge Catalog בכל מיקום.
• ב-Knowledge Catalog יש תמיכה במפתחות של Cloud KMS, של Cloud HSM ושל Cloud External Key Manager.
• יש תמיכה ברוטציית מפתחות, ואחרי שהיא זמינה, גרסת המפתח החדשה משמשת באופן אוטומטי להצפנת נתונים. גם הנתונים הקיימים מוצפנים באמצעות הגרסה החדשה הזו.
• גיבויי הנתונים נשמרים ב-Knowledge Catalog למשך 15 ימים לכל היותר. כל הגיבויים שנוצרים אחרי שמפעילים את CMEK מוצפנים באמצעות מפתח ה-KMS שצוין. נתונים שגובו לפני הפעלת CMEK נשארים מוצפנים באמצעות הצפנת ברירת המחדל של Google למשך 15 ימים לכל היותר.

מגבלות

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

• כשמפעילים את CMEK ב-Knowledge Catalog, התכונות הבאות לא פועלות:

  • חיפוש מטא-נתונים בין ארגונים שונים

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

שדרוג הגדרות CMEK קיימות

אם הפעלתם את CMEK ב-Knowledge Catalog לפני 7 בנובמבר 2025, הריצו את הפקודה הבאה כדי להרחיב את הכיסוי של CMEK ל-Knowledge Catalog ולחיפוש ב-Knowledge Catalog:

  gcloud dataplex encryption-config update organizations/ORG_ID/locations/LOCATION/encryptionConfigs/default --enable-metastore-encryption

• מחליפים את ORG_ID במזהה של הארגון שמכיל את המפתח.
• מחליפים את LOCATION במיקום של הארגון שמכיל את המפתח.

כשהנתונים מוצפנים, יכול להיות שתופיע בעיה בזמינות של Knowledge Catalog.

אם תפעילו את CMEK בפעם הראשונה אחרי 7 בנובמבר 2025, החיפוש והמטא-נתונים של Knowledge Catalog ייכללו בכיסוי של CMEK כברירת מחדל.

הגנה על מפתחות ההצפנה

אזהרה: אתם אחראים לניהול מפתחות ה-CMEK שלכם. אם מפתח מושבת או מושמד, תאבדו את הגישה לנתונים שמוצפנים באמצעות המפתח הזה.

כדי להבטיח גישה רציפה לנתונים שמוצפנים באמצעות CMEK, כדאי לפעול לפי השיטות המומלצות הבאות:

• חשוב לוודא שמפתחות ה-CMEK נשארים מופעלים ונגישים. אם מפתח מושבת או מושמד, אי אפשר לגשת לנתונים של Knowledge Catalog. אם המפתח לא זמין במשך יותר מ-30 ימים, הנתונים שהוצפנו באמצעות המפתח הזה נמחקים באופן אוטומטי ואי אפשר לשחזר אותם.
• אם המפתח של Cloud KMS נהרס ואי אפשר לשחזר אותו, כל הנתונים המשויכים של Knowledge Catalog יאבדו באופן סופי.
• במקרים שבהם Cloud KMS לא זמין באופן זמני, Knowledge Catalog ממשיך לתמוך בפעולות מלאות על בסיס המאמץ המרבי, למשך עד שעה. אחרי התקופה הזו, הנתונים לא יהיו נגישים באופן זמני כאמצעי הגנה.
• כשמשתמשים ב-Cloud EKM, חשוב לזכור ש-Google לא שולטת בזמינות של המפתחות שמנוהלים באופן חיצוני. אם המפתח לא זמין לזמן קצר, אי אפשר לגשת לנתונים באופן זמני. אם המפתח לא יהיה זמין במשך 30 ימים, הנתונים יאבדו באופן סופי.

זמינות של Knowledge Catalog

בקטעים הבאים מפורטים התהליך וההשפעה התפעולית הצפויה כשמפעילים את CMEK בארגון ב-Knowledge Catalog.

הקצאת תשתית ראשונית

אחרי ששומרים את הגדרות ההצפנה, Knowledge Catalog מגדיר את התשתית הנדרשת. בדרך כלל התהליך הזה נמשך בין 6 ל-8 שעות. במהלך שלב ההקצאה, יש לכם גישה מלאה לכל התכונות והפונקציות של Knowledge Catalog, והנתונים נשארים מוצפנים באמצעות הצפנה בניהול Google. אם מדיניות הארגון constraints/gcp.restrictNonCmekServices מוגדרת, בקשות ליצירת משאבים נכשלות עד ששלב ההקצאה מסתיים.

הצפנת נתונים וזמינות API

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

פעולות אחרי ההצפנה

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

יצירת מפתח והפעלת CMEK

בהוראות הבאות מוסבר איך ליצור מפתח ולהפעיל את CMEK ב-Knowledge Catalog. אתם יכולים להשתמש במפתח שנוצר ישירות ב-Cloud KMS או במפתח שמנוהל באופן חיצוני וזמין באמצעות Cloud EKM.

1. בפרויקט ב- Google Cloud שבו רוצים לנהל את המפתחות:

   1. מפעילים את Cloud Key Management Service API.

   2. יוצרים אוסף מפתחות של Cloud KMS במיקום שבו רוצים להשתמש בו.

   3. יוצרים מפתח באחת מהדרכים הבאות:

      • יצירת מפתח Cloud KMS.
      • יצירת מפתח חיצוני.

      אם אתם משתמשים במנהל מפתחות חיצוני (Cloud EKM), אתם צריכים לתת לחשבון השירות של Cloud KMS גישה למפתח שלכם במערכת של השותף החיצוני לניהול מפתחות. אם אתם מתחברים למנהל המפתחות החיצוני דרך VPC, אתם צריכים גם להקצות לחשבון השירות של Cloud EKM‏ ([e-mail]) את התפקידים צפייה ב-Service Directory‏ (roles/servicedirectory.viewer) ושירות מורשה של Private Service Connect‏ (roles/servicedirectory.pscAuthorizedService) בפרויקט ה-VPC. מידע נוסף זמין במאמר יצירת חיבור ל-EKM.

2. יוצרים ומציגים את חשבון השירות שמנוהל על ידי Google:

   gcloud beta services identity create \
       --service=dataplex.googleapis.com \
       --organization=ORG_ID
   

   מחליפים את ORG_ID במזהה של הארגון שמכיל את המפתח.

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

   הפקודה services identity של ה-CLI של gcloud יוצרת או מקבלת את חשבון השירות הספציפי שמנוהל על ידי Google, שבו Knowledge Catalog יכול להשתמש כדי לגשת למפתח Cloud KMS.

   מזהה חשבון השירות הוא בפורמט [e-mail]. בנוסף, נוצר חשבון שירות ספציפי ל-CMEK, בפורמט [e-mail]. חשבון השירות הספציפי ל-CMEK משמש להצפנה ולפענוח של נתונים שמאוחסנים ב-Knowledge Catalog. אם אתם משתמשים ב-VPC Service Controls למפתח Cloud KMS, אתם צריכים לתת גישה לחשבון השירות הספציפי ל-CMEK באמצעות כלל תעבורת נתונים נכנסת (ingress).

3. מקצים את תפקיד ה-IAM Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter) לחשבון השירות של Knowledge Catalog. צריך לתת את ההרשאה הזו במפתח שיצרתם.

   אם אתם משתמשים במנהל מפתחות חיצוני (Cloud EKM), ודאו שמערכת ניהול המפתחות החיצונית מעניקה גם הרשאות גישה לחשבון השירות של Cloud KMS‏ ([e-mail]).

   המסוף

   1. נכנסים לדף Key management.

      כניסה לדף Key management

   2. לוחצים על אוסף המפתחות.

   3. ברשימת המפתחות הזמינים, לוחצים על המפתח שיצרתם.

   4. לוחצים על הכרטיסייה Permissions.

   5. לוחצים על הענקת גישה.

   6. בחלונית Grant access שנפתחת, מבצעים את הפעולות הבאות כדי לתת גישה לחשבון השירות של Knowledge Catalog:

      1. בקטע Add principals, מזינים את חשבון השירות [e-mail].
      2. בקטע Assign roles, בוחרים את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter (roles/cloudkms.cryptoKeyEncrypterDecrypter).
      3. לוחצים על Save.

   gcloud

   מקצים לחשבון השירות את התפקיד Cloud KMS CryptoKey Encrypter/Decrypter ‏ (roles/cloudkms.cryptoKeyEncrypterDecrypter):

   gcloud kms keys add-iam-policy-binding KEY_NAME \
       --location=LOCATION \
       --keyring KEY_RING \
       --project=KEY_PROJECT_ID \
       --member serviceAccount:[e-mail] \
       --role roles/cloudkms.cryptoKeyEncrypterDecrypter
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫KEY_NAME: שם המפתח
   • ‫LOCATION: המיקום
   • ‫KEY_RING: אוסף המפתחות
   • ‫KEY_PROJECT_ID: מזהה הפרויקט של המפתח

4. מקצים לעצמכם את התפקיד אדמין הצפנה ב-Dataplex (roles/dataplex.encryptionAdmin).

   המסוף

   פועלים לפי ההוראות להקצאת תפקיד ב-IAM.

   gcloud

   gcloud organizations add-iam-policy-binding ORG_ID \
       --member='user:USER_EMAIL' \
       --role='roles/dataplex.encryptionAdmin'
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫ORG_ID: המזהה של הארגון שמכיל את המפתח.
   • ‫USER_EMAIL: כתובת האימייל של המשתמש.

5. מגדירים את Knowledge Catalog כך שישתמש במפתח CMEK.

   המסוף

   1. נכנסים לדף Knowledge Catalog במסוף Google Cloud .

      מעבר אל Knowledge Catalog

   2. לוחצים על הגדרות.

   3. בקטע Select region for CMEK, בוחרים אזור. האזור שבוחרים צריך להיות זהה למיקום של מפתח Cloud KMS.

   4. בקטע Select encryption key, בוחרים את המפתח שיצרתם.

   5. לוחצים על Save.

      תהליך הצפנת הנתונים נמשך זמן מה. בסיום התהליך, תופיע ההודעה הבאה: Data Encryption is complete. Your selected CMEK key is now protecting your data.

   gcloud

   1. מגדירים את תצורת ההצפנה ב-Knowledge Catalog:

      gcloud dataplex encryption-config create default \
          --location=LOCATION \
          --organization=ORG_ID \
          --key=KEY_RESOURCE_ID
      

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫ORG_ID: המזהה של הארגון שמכיל את המפתח.
      • ‫KEY_RESOURCE_ID: מזהה המשאב של המפתח, לדוגמה projects/PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME. מחליפים את PROJECT_ID במזהה הפרויקט של המפתח.

   2. מוודאים שתהליך ההצפנה הושלם:

      gcloud dataplex encryption-config describe default \
          --location=LOCATION \
          --organization=ORG_ID
      

   תהליך הצפנת הנתונים נמשך זמן מה. בסיום התהליך תופיע ההודעה הבאה: encryptionState: COMPLETED.

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

כדי לבדוק את הבקשות של Knowledge Catalog ל-Cloud KMS, צריך להפעיל את יומני הביקורת ב-Cloud Key Management Service API.

מדיניות הארגון לגבי CMEK

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

• ‫constraints/gcp.restrictNonCmekServices אוכף שימוש חובה ב-CMEK למשאבים של Knowledge Catalog.

  • הוספת dataplex.googleapis.com לרשימת שמות השירותים Google Cloud והגדרת האילוץ ל-Deny אוסרת על יצירת משאבים של Knowledge Catalog שאין להם הגנה של CMEK.

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

  • המדיניות הזו מאומתת ברמת הפרויקט של המשאב הספציפי.

• constraints/gcp.restrictCmekCryptoKeyProjects מגביל את הבחירה של מפתחות Cloud KMS ל-CMEK להיררכיות משאבים ייעודיות.

  • כדי להגביל את Knowledge Catalog לשימוש במפתחות CMEK רק מהמיקומים שצוינו, צריך להגדיר רשימה של אינדיקטורים להיררכיית המשאבים (פרויקטים, תיקיות או ארגונים) ולהגדיר את המגבלה לערך Allow.

  • אם תספקו מפתח Cloud KMS מפרויקט שלא מורשה, הבקשות ליצירת משאבים שמוגנים באמצעות CMEK ב-Knowledge Catalog ייכשלו.

  • המדיניות הזו מאומתת ברמת הפרויקט של המשאב בזמן יצירת המשאב.

  • המדיניות הזו מאומתת ברמת הארגון כשמגדירים את הגדרות ההצפנה של CMEK.

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

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

הרשאות CMEK לסריקות נתונים ב-Knowledge Catalog

כדי ליצור סריקות של פרופילי נתונים או של איכות הנתונים במשאבי BigQuery שמוצפנים באמצעות CMEK, צריך להקצות את התפקיד "מפענח/מצפין של מפתח הצפנה ב-Cloud KMS" (roles/cloudkms.cryptoKeyEncrypterDecrypter) במפתח Cloud KMS שמגן על מערך הנתונים ב-BigQuery, גם לסוכן השירות של Knowledge Catalog וגם לסוכן השירות של BigQuery.

מקצים את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter לסוכן השירות של Knowledge Catalog:

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location=LOCATION \
    --keyring=KEYRING_NAME \
    --member="serviceAccount:[e-mail]" \
    --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"

מקצים את התפקיד roles/cloudkms.cryptoKeyEncrypterDecrypter לסוכן השירות של BigQuery:

gcloud kms keys add-iam-policy-binding KEY_NAME \
    --location=LOCATION \
    --keyring=KEYRING_NAME \
    --member="serviceAccount:[e-mail]" \
    --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"

מחליפים את מה שכתוב בשדות הבאים:

• ‫KEY_NAME: השם של מפתח Cloud KMS שמגן על מערך הנתונים ב-BigQuery.
• ‫LOCATION: המיקום שבו נמצא אוסף המפתחות.
• ‫KEYRING_NAME: השם של אוסף המפתחות.
• ‫PROJECT_NUMBER: מספר הפרויקט ב- Google Cloud .

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

• CMEK