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

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

סקירה כללית

כברירת מחדל, Artifact Registry מצפין את התוכן של הלקוחות במצב מנוחה. ‫Artifact Registry מטפל בהצפנה בשבילכם בלי שתצטרכו לבצע פעולות נוספות. האפשרות הזו נקראת Google default encryption.

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

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

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

למידע נוסף על CMEK באופן כללי, כולל מתי ולמה כדאי להפעיל אותו, אפשר לעיין בסקירה הכללית על CMEK.

יצירת מפתח והענקת הרשאות

בהוראות הבאות מוסבר איך ליצור מפתח למאגר ולהעניק הרשאות להצפנה ולפענוח של נתוני המאגר באמצעות המפתח. אתם יכולים להשתמש במפתח שנוצר ישירות ב-Cloud KMS או במפתח שמנוהל באופן חיצוני וזמין באמצעות Cloud External Key Manager.

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

    1. הפעלת Cloud KMS API.

    2. כדי ליצור אוסף מפתחות ומפתח, משתמשים באחת מהאפשרויות הבאות:

      ‫

  2. אם לא יצרתם מאגר בפרויקט Artifact Registry, חשבון השירות של Artifact Registry לא קיים. כדי ליצור את חשבון השירות, מריצים את הפקודה הבאה:

    gcloud beta services identity create --service=artifactregistry.googleapis.com --project=PROJECT

    מחליפים את PROJECT במזהה הפרויקט שבו פועל Artifact Registry.

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

    המסוף

    1. עוברים לדף Cryptographic keys.

      פתיחת הדף Cloud KMS

    2. בוחרים את המפתח שיצרתם.

    3. נותנים גישה לחשבון השירות של Artifact Registry:

      1. אם חלונית המידע מוסתרת, לוחצים על Show info panel.
      2. לוחצים על הענקת גישה.
      3. בשדה New principals, מוסיפים את חשבון השירות של Artifact Registry. חשבון השירות הוא service-PROJECT-NUMBER@gcp-sa-artifactregistry.s3ns-system.iam.gserviceaccount.com, כאשר PROJECT-NUMBER הוא מספר הפרויקט של פרויקט Cloud de Confiance שבו פועל Artifact Registry.
      4. ברשימת התפקידים Select a role בוחרים באפשרות Cloud KMS > Cloud KMS CryptoKey Encrypter/Decrypter.
      5. לוחצים על Save.

    4. חוזרים על השלב הקודם כדי להעניק גישה לחשבון שדרכו ייצרו מאגרי קוד.

    5. חוזרים לדף ניהול מפתחות ובוחרים שוב את המפתח.

    6. אם חלונית המידע מוסתרת, לוחצים על Show info panel. התפקידים צריכים להופיע בקטע Role/Principal.

    gcloud

    1. מריצים את הפקודה הבאה כדי להעניק גישה לחשבון השירות של Artifact Registry:

      gcloud kms keys add-iam-policy-binding [--project=PROJECT] \
       KEY --location LOCATION --keyring=KEYRING \
       --member serviceAccount:service-PROJECT-NUMBER@gcp-sa-artifactregistry.s3ns-system.iam.gserviceaccount.com \
       --role roles/cloudkms.cryptoKeyEncrypterDecrypter

      כאשר:

      • ‫PROJECT הוא מזהה הפרויקט שמכיל את המפתח.
      • ‫KEY הוא שם המפתח.
      • ‫LOCATION הוא מיקום המפתח.
      • ‫KEYRING הוא השם של אוסף המפתחות.
      • ‫PROJECT-NUMBER הוא מספר הפרויקט של הפרויקט Cloud de Confiance שבו פועל Artifact Registry.

    2. חוזרים על השלב הקודם כדי להעניק גישה לחשבון שדרכו ייצרו מאגרי קוד.

    מידע נוסף על הפקודה הזו זמין במאמר gcloud kms keys add-iam-policy-binding.

בשלב הבא, יוצרים מאגר ומציינים את המפתח שבו רוצים להשתמש להצפנה.

הסרת הגישה

יש כמה דרכים להסיר גישה למאגר מוצפן באמצעות CMEK:

מומלץ לבטל את ההרשאות מחשבון השירות של Artifact Registry לפני השבתה או מחיקה של מפתח. השינויים בהרשאות מתבצעים תוך שניות, כך שאפשר לראות את ההשפעות של השבתה או מחיקה של מפתח.

כשמשביתים או משמידים את מפתח ההצפנה של מאגר, מאבדים את היכולת להציג או לאחזר נתוני ארטיפקטים. לא תהיה יותר גישה לכל נתוני הארטיפקטים שמאוחסנים במאגר, כולל ארטיפקטים שנבנו, נתונים בינאריים שרירותיים (blobs) ומניפסטים כמו מניפסט של Docker או קובץ packument של npm. משתמשים עם התפקיד 'קריאה ב-Artifact Registry' (roles/artifactregistry.reader) או התפקיד 'צפייה' (roles/artifactregistry.viewer) עדיין יכולים לראות מטא-נתונים של ארטיפקטים, כמו שם הארטיפקט, הגרסה או התג.

משתמשים עם הרשאת אדמין ב-Artifact Registry‏ (roles/artifactregistry.admin) או הרשאת בעלים (roles/owner) יכולים למחוק את המאגר.

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

‫Artifact Registry תומך באילוצים של מדיניות הארגון שיכולים לדרוש הגנה באמצעות CMEK.

כללי המדיניות יכולים להגביל את השימוש במפתחות CryptoKey ב-Cloud KMS להגנה באמצעות CMEK.

  • אם Artifact Registry API מופיע בDenyרשימת השירותים של מדיניות האילוץ constraints/gcp.restrictNonCmekServices, ‏ Artifact Registry לא מאפשר ליצור מאגרים חדשים שלא מוגנים באמצעות CMEK.

  • כשמגדירים את constraints/gcp.restrictCmekCryptoKeyProjects,‏ Artifact Registry יוצר מאגרי מידע שמוגנים באמצעות CMEK, ומוגנים באמצעות CryptoKey מפרויקט, מתיקייה או מארגון מורשים.

‫Pub/Sub תומך באותם אילוצים. כשמפעילים את Artifact Registry API ב Cloud de Confiance by S3NS פרויקט, Artifact Registry מנסה ליצור אוטומטית נושא Pub/Sub עם מזהה הנושא gcr באמצעות מפתחות הצפנה שמבוססים על Google Cloud . עם זאת, אם Pub/Sub API נמצא ברשימת המדיניות Deny של האילוץ constraints/gcp.restrictNonCmekServices, הנושא לא ייווצר ב-Pub/Sub. בתרחיש הזה, אתם צריכים ליצור את הנושא gcr עם הצפנה באמצעות CMEK. מידע נוסף זמין בהוראות להצפנת נושאים ב-Pub/Sub.

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

מה השלב הבא?