אבטחת שירות ה-MPC באמצעות תפקידי IAM

מודל אבטחה: הגנה לעומק

ב-Multi-party Compute (MPC) API מיושמת ארכיטקטורת אבטחה של הגנה לעומק, שמסתמכת על אמצעי בקרה מחמירים של ניהול זהויות והרשאות גישה (IAM). המודל הזה מבטיח שזהות אחת או חשבון Google אחד שנפרץ לא יוכלו לפגוע בפלטפורמה או לחלץ נכסים באופן חד-צדדי.

  • שכבה 1: ניהול זהויות והרשאות גישה (IAM): כל הבקשות מאומתות בקצה כדי לוודא שלמבצע הקריאה יש את ההרשאות המפורשות שנדרשות כדי להפעיל שיטות ספציפיות של Google Cloud API (ראו סקירה כללית על IAM). חשבונות שאין להם מספיק הרשאות נדחים מיד עם שגיאת 403 Forbidden, וכך נמנעת הגעה של תנועה לא מורשית לשכבת האפליקציה.
  • שכבה 2: הפרדת תפקידים (SoD): פלטפורמת ה-MPC אוכפת הפרדה קפדנית בין תפקידים כדי להבטיח שאותו אדם לא יוכל לבצע פעולות שונות של ניהול וביצוע. הגדרת תפקידים נפרדים – כמו הגבלת כותבי המדיניות לעריכת מדיניות בלבד, והגבלת החותמים לחתימה על נתוני עסקאות בלבד – מבטיחה שסוכן זדוני יחיד או חשבון שנפרץ לא יוכלו לבצע עסקאות רגישות באופן עצמאי.
  • שכבה 3: העיקרון של הרשאות מינימליות: הגישה ניתנת אך ורק על סמך התפקיד, כדי לוודא שלמשתמשים יש רק את ההרשאות המינימליות שנדרשות לביצוע המשימות שלהם. לדוגמה, צוות התאימות או הביקורת פועל עם הרשאות מינימליות, ושומר על גישה לקריאה בלבד כדי לעקוב אחרי הפעילות. הם יכולים לצפות בכללי המדיניות ולבדוק את יומני העסקאות לצורך פיקוח, אבל אין להם אפשרות לשנות את כללי המדיניות, לבצע עסקאות או לבצע פעולות בנכסים.

פרסונות והפרדת תפקידים

האבטחה נאכפת על ידי הפרדה בין ניהול (הגדרת הלוח) לבין משילות (הגדרת כללים) וביצוע (העברת נכסים).

פרסונה דומיין התפקיד הוקצה ב-IAM תחומי האחריות העיקריים
אדמין ניהול mpc.admin הקצאת משאבים. לא יכול לחתום על עסקאות או ליצור כללי מדיניות.
מחבר המדיניות פיקוח mpc.editor מגדיר ועורך כללי מדיניות תפעולית (למשל, מגבלות הוצאות).
בעל חתימה ביצוע mpc.editor חתימה על מטענים ייעודיים (payloads) של עסקאות. אי אפשר ליצור כללי מדיניות.
עמידה בדרישות פיקוח mpc.viewer הרשאת קריאה בלבד למעקב אחרי פעילות ולבדיקת כללי מדיניות. לא יכולים לשנות פוליסות או לבצע עסקאות.

תפקידי IAM מוגדרים מראש

בטבלה הבאה מפורטות הרשאות ה-IAM הספציפיות ל-Multi-party Compute (MPC) API והתפקידים שמעניקים אותן. מידע נוסף על פעולות ה-API זמין במאמרי העזרה של MPC API.

תפקיד הרשאות
צפייה בחישוב רב-משתתפים
(roles/mpc.viewer)

הרשאת קריאה בלבד ב-API (פעולות Get/List בכל המשאבים). התפקיד מתאים במיוחד לכלים לביקורת או למעקב.

המשאבים ברמה הנמוכה ביותר שבהם אפשר להקצות את התפקיד הזה:
  • KeyRing
 mpc.googleapis.com/keyRings.get
mpc.googleapis.com/keyRings.list
mpc.googleapis.com/keys.get
mpc.googleapis.com/keys.list
mpc.googleapis.com/policies.get
mpc.googleapis.com/policies.list
mpc.googleapis.com/policyAuthorTrustBundles.get
mpc.googleapis.com/proposals.get
mpc.googleapis.com/proposals.list
mpc.googleapis.com/signers.get
mpc.googleapis.com/signers.list
עורך חישוב רב-משתתפים
(roles/mpc.editor)

מיועד ליוצרי מדיניות ולמשתתפים (חותמים). התפקיד מאפשר לנהל כללי מדיניות, ליצור הצעות ולתעד החלטות של משתתפים.

המשאבים ברמה הנמוכה ביותר שבהם אפשר להקצות את התפקיד הזה:
  • KeyRing
 כולל את כל ההרשאות של roles/mpc.viewer, וגם:

mpc.googleapis.com/keyRings.update
mpc.googleapis.com/keys.update
mpc.googleapis.com/policies.addQuorumSignature
mpc.googleapis.com/policies.create
mpc.googleapis.com/policies.revoke
mpc.googleapis.com/proposals.create
mpc.googleapis.com/proposals.fetchProposalSignature
mpc.googleapis.com/proposals.recordParticipantDecision
אדמין לחישוב רב-משתתפים
(roles/mpc.admin)

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

המשאבים ברמה הנמוכה ביותר שבהם אפשר לתת את התפקיד הזה:
  • Instance
 כולל את כל ההרשאות של roles/mpc.editor, וגם:

mpc.googleapis.com/keyRings.create
mpc.googleapis.com/keyRings.delete
mpc.googleapis.com/keys.create
mpc.googleapis.com/policyAuthorTrustBundles.update
mpc.googleapis.com/signers.create

תפקידים בהתאמה אישית

כדי לתת למשתתף גישה קפדנית עם הרשאות מינימליות במקום להשתמש בתפקידים מוגדרים מראש רחבים יותר כמו roles/mpc.editor, אתם יכולים ליצור תפקיד IAM בהתאמה אישית שמכיל רק את ההרשאות המדויקות שהמשתתף צריך כדי להשתתף בפעולות.

דוגמה לפקודה של תפקיד בהתאמה אישית

gcloud iam roles create customMpcSigner \
  --project="PROJECT_ID" \
  --title="Custom MPC Signer" \
  --description="Restricted role for transaction participants" \
  --permissions="mpc.googleapis.com/proposals.get,mpc.googleapis.com/proposals.list,mpc.googleapis.com/proposals.recordParticipantDecision"

ניהול זהויות והרשאות גישה (IAM) ברמת המשאב ועם תנאים

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

אם כמה יחידות עסקיות פועלות באותו פרויקט ב- Google Cloud באמצעות מכונה משותפת, אפשר לאכוף הפרדה על ידי הצבת משאבים באוספי מפתחות נפרדים (למשל KeyRing A ו-KeyRing B). אפשר להעניק את התפקיד roles/mpc.editor לחשבון שירות באמצעות תנאי IAM שמגביל אותו באופן בלעדי לפעולות שמתרחשות בתוך אוסף מפתחות ייעודי (KeyRing A), תוך הגבלת הגישה לאוספי מפתחות אחרים באותו מכונה.

פקודה לדוגמה

דוגמה ליצירת קישור תפקיד ברמת KeyRing:

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="serviceAccount:sa-name@PROJECT_ID." \
  --role="roles/mpc.editor" \
  --condition="expression=resource.name.startsWith('projects/PROJECT_ID/locations/LOCATION/instances/INSTANCE_ID/mpc/keyRings/KEYRING_ID'),title=KeyRing_Scoped_Editor"

זהויות מאוחדות (Bring Your Own Identity)

אתם יכולים לאמת ולאשר בקשות של חישוב רב-משתתפים באמצעות ספקי זהויות ארגוניים חיצוניים (כמו Okta, ‏ Microsoft Entra ID או Ping Identity) או סביבות זמן ריצה חיצוניות של עומסי עבודה, בלי ליצור חשבונות Google או לנהל מפתחות של חשבונות שירות:

  • איחוד שירותי אימות הזהות של כוח עבודה: ממפה מאגרי כוח עבודה ברמת הארגון (locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>) לפרסונות אנושיות – כמו אדמינים, כותבי מדיניות, חותמים וצוות תאימות – על ידי קישור של תפקידי IAM לקבוצות IdP חיצוניות.
  • איחוד שירותי אימות הזהות של עומסי עבודה: ממפה מאגרי זהויות של עומסי עבודה ברמת הפרויקט (projects/<var>PROJECT_NUMBER</var>/locations/global/workloadIdentityPools/<var>WORKLOAD_POOL_ID</var>) לצומתי חתימה משותפת אוטומטיים שפועלים ב-AWS, ב-Azure או ב-Kubernetes.

בנוסף, צריך להקצות לחשבונות המשתמשים המאומתים את התפקיד Service Usage Consumer‏ (roles/serviceusage.serviceUsageConsumer) בפרויקט הצרכן, כדי שבקשות ה-API יוכלו לשייך את המכסה והחיוב לפרויקט.

דוגמה לקישורי תפקידים מאוחדים

# Allow members of the workforce pool to consume APIs through the consumer project
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/*" \
  --role="roles/serviceusage.serviceUsageConsumer"

# Grant MPC Admin to an external IdP administrators group
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/group/mpc-admins" \
  --role="roles/mpc.admin"

# Grant MPC Editor to an external IdP signers group
gcloud projects add-iam-policy-binding <var>PROJECT_ID</var> \
  --member="principalSet://iam.googleapis.com/locations/global/workforcePools/<var>WORKFORCE_POOL_ID</var>/group/mpc-signers" \
  --role="roles/mpc.editor"

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

  • ‫<var>PROJECT_ID</var>: מזהה הפרויקט של הצרכן במכונה של החישוב הרב-משתתפים.
  • ‫<var>WORKFORCE_POOL_ID</var>: המזהה של מאגר הזהויות של כוח העבודה ברמת הארגון.

במאמר הגדרת איחוד שירותי אימות הזהות של כוח עבודה (BYOID) מוסבר איך עושים את זה.