AWS vs GCP vs Azure: היררכיית ארגון, IAM, וניהול מפתחות, זה לצד זה

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

ארבע השכבות הללו — היררכיה, מעקות הגנה (guardrails), זהות, וניהול מפתחות — הן גם עמוד השדרה של כל בחינת ארכיטקטורה ואבטחת ענן. לכן, אותה קריאה שתחסוך לכם שבוע של בלבול בין עננים, היא רוב תוכנית הלימודים להסמכה. הסמכות לתרגול כל שכבה מקושרות בסוף.

שלוש הבעיות שכל ענן פותר

הסירו את השיווק וכל דיון ממשלי הוא שלוש שכבות ערומות זו על גבי זו:

• מבנה — קבוצה מקוננת של קונטיינרים (ארגון → קיבוץ → גבול עומס עבודה) כדי שתוכלו לבודד סביבות, להחיל מעקות הגנה, ולפצל את החשבון.
• זהות והרשאות — אילו principals יכולים לבצע אילו actions על אילו resources, בתוספת התקרה שמגבילה כל grant שאי פעם יינתן.
• ניהול מפתחות — היכן מפתחות קריפטוגרפיים חיים, מי רשאי להשתמש בהם, ומי רשאי לנהל אותם — שתי שאלות שונות שאנשים נוטים לבלבל ביניהן ללא הרף.

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

שכבה 1 — היררכיית המשאבים

לכל ענן יש organization node ברמה העליונה, שכבת קיבוץ אמצעית אופציונלית שניתן לקנן עבור מחלקות או סביבות, ו-workload boundary המשמש גם כיחידת חיוב ו-blast radius. מדיניות המוגדרת גבוה למעלה זורמת כלפי מטה בכל השלושה.

• Org root — AWS: Organization עם management account. GCP: ה-organization node. Azure: ה-tenant root management group, המגובה על ידי Microsoft Entra tenant.
• Grouping container (ניתן לקינון) — AWS: Organizational Unit (OU). GCP: folder. Azure: management group.
• Workload וגבול חיוב — AWS: account. GCP: project. Azure: subscription.
• קיבוץ משאבים בתוך הגבול — AWS: אין (tags, או לכל account). GCP: אין — ה-project הוא הקונטיינר. Azure: ה-resource group, שהוא חובה; כל resource חי באחד בלבד.

ההבדל המהותי הראשון מסתתר כאן. ב-AWS ה-account הוא קיר קשיח — יחידת ה-blast radius המוגדרת כברירת מחדל — וזו הסיבה שנכסי AWS מפותחים מנהלים עשרות או מאות accounts. ב-GCP ה-project מבצע שתי עבודות בו-זמנית: הוא גם יחידת הקיבוץ וגם יחידת החיוב/בידוד, כך שאין מושג נפרד של "resource group". Azure מוסיפה רמה רביעית שהאחרים חסרים — ה-resource group — יושב תחת ה-subscription כקונטיינר lifecycle שאתם פורסים ומפרקים כיחידה אחת.

שכבה 2 — מעקות הגנה מונעים (תקרת ההרשאות)

לפני שאתם מעניקים למישהו משהו, כל ענן מאפשר לכם להגדיר גבול עליון לגבי אילו הרשאות יכולות להתקיים אי פעם מתחת ל-node — תקרה שאף grant בודד לא יכול לפרוץ. זה לא זהה למתן גישה; זו שכבת ה-"אתה לעולם לא תוכל, ברחבי הארגון".

• הגבלה על מה ש-principals יכולים לעשות — AWS: Service Control Policy (SCP). GCP: Organization Policy constraints בתוספת IAM deny policies. Azure: Azure Policy.
• הגבלה על מי יכול לגעת ב-resource — AWS: Resource Control Policy (RCP). GCP: IAM allow/deny policies על ה-resource. Azure: Azure Policy בתוספת deny assignments.
• אכיפת תצורת שירות — AWS: declarative policies. GCP: Organization Policy constraints. Azure: Azure Policy (deny / audit / deployIfNotExists).

AWS פיצלה את המשימה הזו לשתיים. SCPs ממוקדות ב-principal ("האנשים שלנו לא יכולים לעשות X") וה-RCPs החדשות ממוקדות ב-resource ("אף אחד – אפילו לא account חיצוני – לא יכול לגעת ב-S3 bucket, KMS key, או role זה אלא אם כן הוא בארגון שלנו"). בשימוש משולב הן סוגרות פערים שאף אחת מהן לא מכסה לבד. המלכודת: ב-AWS וב-GCP, SCP או Org Policy לעולם לא מעניקים דבר — הם רק מחסירים. Azure פועלת אחרת, מפרידה באופן נקי בין RBAC (הרשאות) לבין Azure Policy (ציות ותצורה), כך שמשימת ה-guardrail שייכת ברובה ל-Azure Policy בעוד "מי יכול לעשות מה" שייכת לחלוטין ל-RBAC.

שכבה 3 — זהות והרשאות

כל ענן מבטא grant כשלישייה זהה — principal, role (חבילת הרשאות), ו-scope — אך מרכיב את החלקים באופן שונה.

• Identity directory — AWS: IAM בתוספת IAM Identity Center (SSO). GCP: Cloud Identity / Google Workspace בתוספת IAM. Azure: Microsoft Entra ID.
• חבילת הרשאות ("role") — AWS: IAM policy, מנוהלת או inline. GCP: IAM role — בסיסית, מוגדרת מראש, או מותאמת אישית. Azure: RBAC role definition, מובנית או מותאמת אישית.
• ה-grant עצמו — AWS: policy המצורפת למשתמש, קבוצה, או role. GCP: IAM binding (member + role, אופציונלית condition) על resource. Azure: role assignment (principal + role + scope).
• Conditions ו-explicit deny — AWS: IAM condition keys ו-Deny מפורש. GCP: IAM Conditions ו-deny policies. Azure: RBAC conditions ו-deny assignments.

ההבדל העמוק ביותר הוא היכן ה-grant נמצא. ב-AWS אתם בעיקר מצרפים את ה-policy ל-identity — role או user — וההרשאה נעה איתם. ב-GCP ה-allow policy מצורפת ל-resource: אתם מעניקים ל-principal P את ה-role R על resource X, והוא עובר בירושה במורד ההיררכיה. ה-role assignment של Azure דומה ל-binding של GCP אך מקובע ל-scope בשרשרת management-group → subscription → resource-group → resource. הפנימו "AWS = מצורף ל-identity, GCP ו-Azure = מצורף ל-resource/scope" והרבה בלבול בין עננים ייעלם.

שכבה 3ב — זהות עומס עבודה (החלק שאנשים שוכחים)

בני אדם אינם ה-principals היחידים. גם הקוד שלכם זקוק ל-identity, ולעשות את זה נכון זה המנוף הגדול ביותר על least privilege. כלל הזהב בכל מקום: לעולם אל תשלחו מפתחות סטטיים בעלי חיים ארוכים — צרפו managed identity לעומס העבודה במקום זאת.

• Identity לעומס עבודה פועל — AWS: IAM role, המקבלת הנחות (assumed) באמצעות instance profile, task role, או OIDC. GCP: service account המצורפת ל-resource. Azure: managed identity, מסוג system- או user-assigned.
• App / non-human principal — AWS: IAM role. GCP: service account. Azure: service principal.
• Keyless trust מחוץ לענן — AWS: IAM roles עם OIDC/SAML federation. GCP: Workload Identity Federation. Azure: workload identity federation.

שימו לב לחפיפת השמות שמבלבלת את כולם: "IAM role" ב-AWS הוא workload identity שאתם מניחים (assume), בעוד ש-"role" ב-GCP וב-Azure הוא רק חבילת הרשאות — ה-identity היא service account או managed identity. אותה מילה, שתי עבודות שונות. GCP service-account keys ו-Azure service-principal secrets עדיין קיימים, אך שני העננים דוחפים כעת חזק לכיוון keyless federation עבור כל דבר הפועל מחוץ להיקפם.

שכבה 4 — ניהול מפתחות

לבסוף, הצפנה. לכל ענן יש שירות מפתחות מנוהל, מארגן מפתחות בהיררכיה קטנה, ו—באופן מכריע—מפריד בין שימוש במפתח (encrypt/decrypt) לבין ניהול מפתח (rotate, disable, set policy).

• שירות — AWS: KMS, בתוספת CloudHSM לחומרה ייעודית. GCP: Cloud KMS, בתוספת Cloud HSM / חיצוני. Azure: Key Vault, בתוספת Managed HSM לחומרה ייעודית.
• ארגון מפתחות — AWS: KMS keys (CMKs), aliases, multi-Region keys. GCP: key ring → key → key version. Azure: vault → key / secret / certificate.
• בקרת גישה — AWS: key policy + grants + IAM (שלושתם משולבים). GCP: Cloud KMS IAM bindings ברמת project, key-ring, או key. Azure: RBAC כברירת מחדל, או legacy per-vault access policies; Managed HSM משתמש ב-RBAC מקומי משלו.
• הפרדה בין שימוש לניהול — AWS: פעולות encrypt/decrypt מול פעולות key-admin. GCP: cryptoKeyEncrypterDecrypter מול admin roles. Azure: roles בסגנון "Crypto User" מול "Crypto Officer".

היבט עכשווי ששווה לדעת: עבור Key Vaults חדשים בגרסאות API עדכניות, Azure RBAC הוא כעת מודל הגישה המוגדר כברירת מחדל, ומדיניות הגישה הישנה יותר לכל vault היא הדרך המיושנת — מה שמתאם סוף סוף את Key Vault עם האופן שבו שאר Azure מבצע הרשאות. AWS נשארת יוצאת הדופן: ה-key policy של KMS key היא סמכותית ויכולה להעניק גישה באופן עצמאי מ-IAM, ולכן טעות קלאסית ב-AWS היא לנעול את עצמכם מחוץ למפתח על ידי עריכת IAM תוך שכחת ה-key policy. ב-GCP, גישת KMS היא IAM רגיל כמו כל דבר אחר.

היכן המודל המנטלי נשבר

מיפוי נקי מסוכן אם סומכים עליו באופן מילולי מדי. ארבעת המקומות שבהם האנלוגיה דולפת:

• "IAM role" משמעותו שונה בשני מקומות. ב-AWS זו identity שניתן להניח (assume); ב-GCP וב-Azure "role" הוא רק permission set, כאשר ה-identity נשמרת בנפרד. לעולם אל תתרגמו את זה מילה במילה.
• AWS מצרפת הרשאות ל-identities; GCP ו-Azure מצרפות אותן ל-resources ול-scopes. האינסטינקט שלכם "היכן אני בודק גישה?" צריך להתהפך כשאתם עוברים בין עננים.
• Account, project, ו-subscription אינם בעלי אותו blast radius. AWS account הוא קיר חזק; GCP project הוא קיר, חשבון, וקיבוץ באחד; Azure subscription הוא בעיקר גבול חיוב וקנה מידה, כאשר ה-resource group מטפל ב-lifecycle היומיומי.
• מעקות הגנה מחסירים, grants מוסיפים — למעט Azure שמפצלת את העבודות. SCPs ו-Org Policies רק מגבילים הרשאות; Azure מגבילה באמצעות Policy ומעניקה באמצעות RBAC כשתי מערכות נפרדות.

העיקרון שבבסיס כל השלושה זהה: least privilege, נאכף על ידי מבנה. הציבו guardrails גבוה (org, OU, folder, management group), העניקו באופן מצומצם והעדיפו roles על פני מפתחות סטטיים, והפרידו בין "יכול להשתמש במפתח" לבין "יכול לנהל מפתח". השמות משתנים בין העננים; המשמעת לא.

תובנות מעשיות

• תכננו את ההיררכיה לפני עומס העבודה הראשון. התאמת accounts, projects, או subscriptions מאוחר יותר כואבת בכל ענן.
• הגדירו תקרות גבוהות, העניקו נמוך. SCP/RCP, Org Policy, או Azure Policy למעלה; roles ספציפיים ב-scope הצר ביותר שעובד.
• ברירת מחדל ל-managed identities. IAM roles ב-AWS, service accounts ב-GCP, managed identities ב-Azure — ו-keyless federation לכל דבר שחוצה גבול ענן.
• התייחסו ל-key admin כבעל הרשאה. הפרידו encrypt/decrypt מ-rotate/disable/set-policy, וב-AWS תמיד בדקו את ה-key policy, לא רק IAM.
• אם אתם משתמשים ב-Terraform או OpenTofu, הפרימיטיבים הללו הם בדיוק מה שתקדדו — aws_organizations_*, google_folder, azurerm_management_group, ומשאבי ה-IAM/RBAC ו-KMS שמתחתיהם.

תרגלו כל שכבה, לכל ענן

הסמכות הארכיטקטורה והאבטחה של כל ענן בנויות ישירות על היררכיית המשאבים, IAM/RBAC, וניהול מפתחות. אם אתם רוצים לתרגל אותן עם שאלות בחינה אמיתיות, ל-CertLabPro יש מסלול לכל אחת:

• AWS — Solutions Architect Associate (SAA-C03) עבור ההיררכיה ו-IAM, ו-Security Specialty (SCS-C03) עבור SCPs, RCPs, ו-KMS. חדשים ב-AWS? התחילו עם Cloud Practitioner (CLF-C02).
• Google Cloud — Professional Cloud Architect עבור organization, folders, projects, ו-IAM, ו-Professional Cloud Security Engineer עבור IAM deny policies, Org Policy, ו-Cloud KMS.
• Azure — Solutions Architect Expert (AZ-305) עבור management groups ו-governance, ו-Security Engineer (AZ-500) עבור RBAC, Azure Policy, ו-Key Vault. חדשים ב-Azure? התחילו עם Azure Fundamentals (AZ-900).

השורה התחתונה

AWS, Google Cloud ו-Azure אינם שונים כל כך כפי שתיעודם גורם להם להרגיש. כל אחד מהם מספק לכם היררכיה לארגון חשבונות, מודל זהות הבנוי על principal-role-scope, שכבת guardrail המגבילה אילו הרשאות יכולות להתקיים, ושירות מפתחות המפריד בין שימוש במפתחות לניהולם. למדו את ארבע השכבות פעם אחת והתרגום בין העננים הוא בעיקר אוצר מילים — ולמדו את ארבעת המקומות שבהם האנלוגיה דולפת, ותתחמקו מהטעויות שאוצר המילים מסתיר. היסודות הללו הם בדיוק מה שמאגרי השאלות של CertLabPro נועדו לתרגל, בכל שלושת העננים.