במסגרת מודל האחריות המשותפת של AWS (Shared Responsibility Model), בעוד ש-AWS מנהלת את "האבטחה של הענן" (Security OF the Cloud) — מרכזי נתונים פיזיים, חומרת שרתים, hypervisors — הלקוח נושא באחריות בלעדית ל"אבטחה בתוך הענן" (Security IN the Cloud), ובפרט משילות זהויות, היגיינת אישורים ובקרת גישה. פשרה של חשבון AWS Root בלתי מוגבל או של אישורי IAM מיוחסים מאפשרת לתוקפים להקצות שרתי GPU יקרים באלפי דולרים לכריית מטבעות קריפטוגרפיים בלתי חוקית, להוציא מאגרי מידע פרטיים מ-S3, או לבצע מחיקות כופר קטסטרופליות.
MFA הוא חובה לכל משתמשי קונסולת הניהול ואינו נתון למשא ומתן עבור חשבון ה-AWS Root.
AWS מאפשרת רישום של עד 8 התקני FIDO2 ואסימוני TOTP וירטואליים נפרדים לכל חשבון, ובכך מבטלת נקודות כשל בודדות.
מדיניות חסימה מותנית גלובלית ב-IAM החוסמת את כל קריאות ה-API הבלתי מורשות עד להשלמת אימות MFA פעיל.
קווי בסיס לתאימות ענן: CIS Benchmark ומסגרות רגולטוריות
בין אם הארגון ההנדסי שלכם שואף להסמכת SOC 2 Type II, תקן ISO 27001, אימות PCI DSS 4.0, או התאמה לעמוד התווך של אבטחה ב-AWS Well-Architected, יישום MFA בכל זהויות IAM הוא דרישת סף יסודית:
| תקן / מסגרת תאימות | מפרט בקרה | חומרה / חובה | מנגנון אימות ביקורת |
|---|---|---|---|
| CIS AWS Foundations Benchmark v3.0 | 1.5 / 1.6 / 1.10 | Level 1 (חובה) | הערכה אוטומטית באמצעות AWS Security Hub / Prowler |
| PCI DSS 4.0 | דרישה 8.4.2 | חובה | ביקורת קונסולה ו-API של סביבת נתוני כרטיסי אשראי (CDE) |
| SOC 2 Type II (קריטריוני אמון) | CC6.1 / CC6.2 | בקרת מפתח | בדיקה של רואה חשבון עצמאי לדוחות אישורי IAM Credential Reports |
| פריסת חובת MFA ב-AWS | מדיניות AWS 2024–2026 | אכיפה ברמת הפלטפורמה | חסימת שער הכניסה של Root עד להשלמת רישום MFA |
הציווי המוחלט של אבטחת חשבון ה-AWS Root
בגבולות חשבון AWS, חשבון ה-Root מייצג את הזהות הכל-יכולה שנוצרה עם פתיחת החשבון. בניגוד לתפקידי (roles) או משתמשי IAM, לא ניתן להגביל את פעולות חשבון ה-Root באמצעות מדיניות מבוססת-זהות של IAM או Service Control Policies בתוך חשבונות עצמאיים.
רדיוס הפגיעה הקטסטרופלי של חשבון Root שנפרץ:
- סגירת חשבון בלתי הפיכה: תוקפים יכולים ללחוץ על "Close Account", ולתזמן השמדה קבועה של התשתיות.
- חטיפת חיובים וכספים: ניתוב מחדש של חשבוניות, החלפת כרטיסי תשלום עסקיים ופריסת מאות שרתי GPU מסוג spot על פני יותר מ-30 אזורי AWS לצורך כריית מטבעות קריפטוגרפיים בלתי חוקית.
- ניתוק מבנה ה-AWS Organizations: הוצאת חשבונות חברים מעצי הניהול, ופירוק מערך ניטור התאימות הארגוני.
- שינוי אנשי קשר ראשיים לאבטחה: שינוי כתובת הדוא"ל ומספרי הטלפון של Root מנתק לצמיתות את ערוצי ההתערבות הרשמיים של התמיכה ב-AWS.
- אפס מפתחות גישה ל-Root (Zero Root Access Keys): בצעו ביקורת על דוחות אישורי ה-IAM כדי לוודא שאין מפתחות גישה עבור חשבון ה-Root. אם קיימים, מחקו אותם מיד.
- נעילת סיסמה במשמורת כפולה (Dual-Custody Password Vaulting): צרו סיסמה אקראית של 32+ תווים, פצלו את הסיסמה בין ה-CISO לבין היועץ המשפטי הראשי, ונעלו את החלקים בכספות פיזיות חסינות אש.
- יתירות רב-התקנית (עד 8 התקנים): רשמו לפחות שני מפתחות חומרה פיזיים של FIDO2 (YubiKeys) ובנוסף התקן גיבוי וירטואלי (TOTP) המאוחסן אופליין באחסון קר.
מטריצת בחירת MFA: TOTP וירטואלי מול FIDO2 חומרתי (YubiKey)
AWS תומכת בשלוש מחלקות עיקריות של התקני MFA. ארכיטקטי ענן צריכים להתאים את הבחירה בהתאם למודלי איומים ולרמות הרשאות הניהול:
יישומי TOTP וירטואליים
אסימוני RFC 6238 סטנדרטיים (Google Authenticator, 1Password, 2FA-Tool). הטמעה מהירה, אפס חיכוך ברכש. אידיאלי עבור מפתחים סטנדרטיים.
סדרת YubiKey 5
קריפטוגרפיה עמידה לפישינג (Phishing-Resistant). טענות מפתח ציבורי הצמודות למקור (Origin-bound) מסכלות ערכות פישינג מבוססות Reverse-Proxy. חובה עבור Root ומנהלי מערכת.
כרטיסי Gemalto / Thales
כרטיס TOTP מבודד (air-gapped) הפועל על סוללה עצמאית עם מסך LCD. חיוני למתקנים מאובטחים ומבודדים (SCIF) שבהם חל איסור מוחלט על סמארטפונים והתקני USB.
פרוטוקולי FIPS 140-2 רמה 3 וכספת במשמורת כפולה ב-MFA חומרתי ארגוני:
עבור ארגוני Fortune 500 וקבלני ביטחון, אבטחת חשבון Root מחייבת אסימוני חומרה ייעודיים (כגון מפתחות SafeNet/Gemalto IDPrime) המאושרים לפי תקן FIPS 140-2 Level 3. בניגוד לאפליקציות בסמארטפון, אסימונים פיזיים אלה אינם כוללים ממשקים אלחוטיים, ללא רכיבי Bluetooth, ולא ניתן ליירט אותם באמצעות רוגלות במובייל.
משילות משמורת כפולה פיזית: בפרוטוקולים של מרכזי נתונים ארגוניים, גישת Root דורשת שני גורמים שונים: נאמן אחד מחזיק באישורי הדוא"ל הראשיים, בעוד שקצין אבטחה עצמאי מחזיק במפתח הפיזי לכספת מאובטחת המכילה את אסימון החומרה של ה-Root. אף צד אינו יכול לגשת לחשבון ה-AWS Root באופן חד-צדדי.
אכיפת MFA באמצעות מדיניות IAM (יישום בקובץ JSON)
קווי בסיס לאבטחה אינם יכולים להסתמך על פעולה וולונטרית של עובדים. משילות ענן מחייבת אכיפה ברמת המדיניות: למשתמשים ללא אימות MFA פעיל תיחסם באופן שיטתי כל פעולת API וקונסולה ב-AWS, למעט היכולת לרשום בעצמם את התקן ה-MFA שלהם.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowViewAccountInfo",
"Effect": "Allow",
"Action": [
"iam:GetAccountPasswordPolicy",
"iam:ListVirtualMFADevices"
],
"Resource": "*"
},
{
"Sid": "AllowManageOwnVirtualMFADevice",
"Effect": "Allow",
"Action": [
"iam:CreateVirtualMFADevice",
"iam:DeleteVirtualMFADevice"
],
"Resource": "arn:aws:iam::*:mfa/${aws:username}"
},
{
"Sid": "AllowManageOwnUserMFA",
"Effect": "Allow",
"Action": [
"iam:DeactivateMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ResyncMFADevice"
],
"Resource": "arn:aws:iam::*:user/${aws:username}"
},
{
"Sid": "BlockAllAccessUnlessMFAAuthenticated",
"Effect": "Deny",
"NotAction": [
"iam:CreateVirtualMFADevice",
"iam:EnableMFADevice",
"iam:ListMFADevices",
"iam:ListVirtualMFADevices",
"iam:ResyncMFADevice",
"iam:GetUser"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
סעיף 4 (Statement 4) מעריך את מפתח התנאי הגלובלי "aws:MultiFactorAuthPresent": "false" באמצעות הוראת Deny מפורשת. מכיוון שהוראת Deny מפורשת גוברת על כל הוראות ה-Allow, הפעלות ללא MFA נחסמות מיידית בכל ממשקי ה-API של AWS, ומנתבות את המשתמש ישירות למסך הרישום העצמי.
אימות MFA ב-AWS CLI ו-SDK: אסימוני הפעלה זמניים של STS
כאשר מדיניות IAM אוכפת MFA, מפתחים שיריצו פקודות כמו aws s3 ls או יריצו קוד Terraform יקבלו שגיאות מסוג AccessDenied. מפתחות גישה לטווח ארוך (long-term access keys) אינם מסוגלים לבקש קודי OTP באופן אינטראקטיבי.
מהנדסים חייבים להשתמש ב-AWS STS (Security Token Service) כדי להחליף מפתחות לטווח ארוך + קוד TOTP בן 6 ספרות באישורים זמניים:
סקריפט אוטומציה (aws-mfa-session.sh):
מקמו סקריפט עזר זה בסביבה המקומית שלכם (~/.aws/aws-mfa-session.sh) כדי להפוך את קבלת האסימון לאוטומטית:
# Exchange AWS Long-Term Keys + MFA Code for STS Session Token
MFA_ARN="arn:aws:iam::123456789012:mfa/alex-dev"
echo -n "Enter 6-digit 2FA OTP Code: "
read -r TOKEN_CODE
SESSION_JSON=$(aws sts get-session-token \
--serial-number "$MFA_ARN" \
--token-code "$TOKEN_CODE" \
--duration-seconds 43200 \
--output json)
if [ $? -eq 0 ]; then
export AWS_ACCESS_KEY_ID=$(echo "$SESSION_JSON" | jq -r '.Credentials.AccessKeyId')
export AWS_SECRET_ACCESS_KEY=$(echo "$SESSION_JSON" | jq -r '.Credentials.SecretAccessKey')
export AWS_SESSION_TOKEN=$(echo "$SESSION_JSON" | jq -r '.Credentials.SessionToken')
echo "✅ Authenticated! Temporary session exported (Valid for 12 hours)."
else
echo "❌ Authentication failed. Check token code or device time drift."
fi
AssumeRole חוצה-חשבונות עם מגבלות MFA
בארכיטקטורות מרובות חשבונות ארגוניות, מהנדסים בעלי הרשאות מתאמתים בדרך כלל מול חשבון Identity מרכזי ועוברים לחשבונות יעד (Production, Staging) באמצעות sts:AssumeRole. כדי להבטיח שלא ניתן לחטוף הרשאות ייצור מוגברות באמצעות אישורים שדלפו, יחסי האמון (trust relationship) של תפקיד הייצור חייבים לאכוף תנאי MFA:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"Bool": {
"aws:MultiFactorAuthPresent": "true"
}
}
}
]
}
דפוס ארכיטקטוני זה מבטיח שגם אם תוקף משיג אישורים בחשבון ה-Identity המרכזי, ניסיון ליטול את תפקיד היעד מבלי לספק אימות MFA יוביל מיד לשגיאת AccessDenied בגבול אסימון האבטחה.
ביקורת ב-CloudTrail והתראות בזמן אמת ב-EventBridge
אימות תאימות אוטומטי דורש זיהוי מיידי כאשר משתמש כלשהו ניגש לקונסולת הניהול של AWS (Management Console) ללא אימות רב-שלבי. על ידי לכידת אירועי AWS CloudTrail וניתובם דרך Amazon EventBridge, צוותי SecOps משיגים התראות בזמן אמת:
{
"source": ["aws.signin"],
"detail-type": ["AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin"],
"additionalEventData": {
"MFAUsed": ["No"]
}
}
}
עם קבלת האירוע, EventBridge מפעיל הודעת Amazon SNS לזימונית הכונן של מרכז תפעול האבטחה (SOC) או מפעיל פונקציית AWS Lambda שמבטלת מיד את הפעלת משתמש ה-IAM הפעילה.
משילות מרובת חשבונות: AWS Organizations ו-IAM Identity Center
בסביבות ארגוניות המנהלות עשרות או מאות חשבונות AWS על פני Landing Zones, הקצאת משתמשי IAM נפרדים בכל חשבון מהווה דפוס אנטי-תבניתי (anti-pattern).
פדרציית זהויות מרכזית:
פרסו את AWS IAM Identity Center (לשעבר AWS SSO) בחשבון הניהול (Management Account) המיועד שלכם. בצעו פדרציה של זהויות מול ספקי זהות ארגוניים (IdP - כגון Okta, Microsoft Entra ID, PingFederate). אכפו MFA ארגוני בשכבת ה-IdP, תוך החלת Service Control Policies (SCPs) בשורש הארגון כדי לחסום פעולות Root בחשבונות החברים:
"Condition": { "StringLike": { "aws:PrincipalArn": ["arn:aws:iam::*:root"] } }
SCP לרמת ייצור: אכיפת מגבלות MFA בכל החשבונות החברים
בארגונים גדולים, מנהלי חשבונות בודדים עלולים להעניק בטעות הרשאות יתר. על ידי החלת Service Control Policy (SCP) ברמת ה-Organization Root או ברמת יחידה ארגונית (OU), צוות משילות הענן מקים מעקה בטיחות בלתי ניתן לשינוי: קריאות API בעלות השפעה קריטית נחסמות ללא תנאי, אלא אם כן הן אושרו באמצעות הפעלת MFA פעילה:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCriticalActionsWithoutMFA",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey",
"iam:CreateLoginProfile",
"s3:DeleteBucket",
"kms:ScheduleKeyDeletion",
"ec2:TerminateInstances"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "false"
}
}
}
]
}
שרשור תפקידים (Role Chaining) ומגבלות זמן חיים של אסימוני STS:
כאשר זהויות IAM נוטלות תפקידי ביניים שנוטלים לאחר מכן תפקידים משניים ("שרשור תפקידים" / role chaining), AWS STS מסיר את הקשר aws:MultiFactorAuthPresent המקורי מאסימון ההפעלה שנוצר במורד הזרם! כדי לשמור על תאימות קפדנית מקצה לקצה בצנרות חוצות-חשבונות, בנו גרפי נטילת תפקידים ישירות מהפעלת ה-IAM Identity Center המאומתת ולא על ידי שרשור מספר תפקידי IAM ביניים.
שחזור מאסון: פרוטוקול אובדן התקן Root MFA
מה קורה אם כל מפתחות החומרה וההתקנים הווירטואליים הרשומים של Root MFA מושמדים באסון?
רצף שחזור רשמי מחוץ לרשת (Out-of-Band):
- התחלת כניסה כ-Root: הזינו את כתובת הדוא"ל והסיסמה הראשית של חשבון ה-Root בקונסולת AWS.
- פתרון בעיות ב-MFA: בחלונית ה-MFA, לחצו על "Troubleshoot MFA".
- אימות דוא"ל ראשי: AWS שולחת קישור אימות מוגבל בזמן לכתובת הדוא"ל הראשית של ה-Root. השלימו את אימות הדוא"ל.
- אימות קולי אוטומטי: לחצו על "Call me now". מערכת האימות האוטומטית של AWS מתקשרת למספר הטלפון הראשי הרשום בחשבון ומקריאה קוד PIN בן 6 ספרות.
אם הארגון שלכם שינה מספרי טלפון או שאיש הקשר עזב מבלי לעדכן את הגדרות חשבון ה-AWS, השחזור האוטומטי ייכשל. פתרון ידני דורש הגשת מסמכי רישום חברה מאומתים ונוטריוניים לצוות Trust & Safety של AWS, עם זמני טיפול ובדיקה של 3–7 ימי עסקים.
שאלות נפוצות של ארכיטקטי ענן ארגוניים
האם ניתן לשתף אסימוני AWS Root MFA בין חברי צוות DevOps? ▼
איסור מוחלט. שיתוף אישורי Root MFA מכשיל את כל ביקורות התאימות (SOC 2, ISO 27001). ניהול שוטף חייב להתבצע דרך תפקידי IAM Identity Center עם אחריות אישית מוגדרת. אישורי Root חייבים להישאר נעולים בכספות פיזיות במשמורת כפולה למקרי חירום קטסטרופליים בלבד.
כיצד מפתח התנאי aws:MultiFactorAuthAge משפר את האבטחה? ▼
מפתח זה אוכף את רעננות ההפעלה (session freshness). הגדרת "NumericLessThan": {"aws:MultiFactorAuthAge": "3600"} מחייבת שאסימון ה-MFA הוזן בתוך 3,600 השניות האחרונות (שעה אחת). פעולות בסיכון גבוה (כגון מחיקת אשכולות RDS) ייחסמו אם ההפעלה ישנה יותר, מה שמגן מפני חטיפת הפעלות ארוכות טווח.
האם ניתן להשתמש במאמת המקוון של 2FA-Tool להגדרת AWS Virtual MFA? ▼
כן. AWS Virtual MFA תואם באופן מלא למפרט RFC 6238 TOTP (אלגוריתם HMAC-SHA1, מרווח זמן של 30 שניות, 6 ספרות). ניתן להזין את מחרוזת הסוד ב-Base32 אל 2FA-Tool.com כדי לייצר את שני קודי האימות העוקבים הנדרשים לרישום, ב-100% מקומי בדפדפן שלכם.
בדיקת אסימוני TOTP ארגוניים בצורה מאובטחת
צרו קודי אימות TOTP סטנדרטיים לפי RFC 6238 באופן מיידי באמצעות W3C Web Crypto API. ללא קריאות שרת, בידוד מלא בזיכרון, אפס דליפות.