מדריך

מופע EC2 שייתכן שנפרץ בקבוצת Auto Scaling דורש חקירה עם מינימום שיבוש.

→בטל רישום מקבוצת יעד של ELB, הסר מקבוצת Auto Scaling, והחל קבוצת אבטחה "פורנזית" מגבילה שמונעת את כל התעבורה למעט גישה מתחנת עבודה פורנזית.

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

הפוך זרימת עבודה מרובת שלבים לתגובה לאירועים (למשל, צילום מצב, בידוד, התראה) לאוטומטית, שתופעל על ידי ממצא של GuardDuty.

→השתמש בכלל EventBridge כדי ללכוד את הממצא הספציפי ולהפעיל מכונת מצבים של AWS Step Functions. מכונת המצבים מתזמרת את רצף הפעולות עם טיפול בשגיאות ולוגיקת ניסיונות חוזרים.

למה: Step Functions מספק תזמור חזק לזרימות עבודה מרובות שלבים, ומבטיח אמינות וניהול מצב, מה שעדיף על פונקציית Lambda מונוליתית יחידה.

זהה איומי זמן ריצה (למשל, כריית מטבעות קריפטו, הרחבת הרשאות) בתוך קונטיינרים פועלים של ECS Fargate או EC2 ללא פריסת סוכני sidecar.

→הפעל ניטור זמן ריצה של Amazon GuardDuty ECS. עבור EC2, פרוס את סוכן האבטחה של GuardDuty כ-DaemonSet. עבור Fargate, השתמש בתצורת הסוכן האוטומטית.

למה: זה מספק זיהוי איומי זמן ריצה ללא סוכן (עבור Fargate) או מנוהל מרכזית (עבור EC2), לוכד התנהגות בתוך הקונטיינר מבלי לשנות משימות יישום.

מקור↗

תקן אוטומטית ממצא ספציפי של AWS Security Hub, כגון S3 bucket נגיש לציבור.

→צור כלל EventBridge התואם את סוג הממצא הספציפי (למשל, `S3.1`) ומפעיל פונקציית Lambda או מסמך SSM Automation לביצוע התיקון.

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

מפתח גישה של IAM נחשף לציבור. הכל את האירוע והערך את רדיוס הפגיעה.

→1. בטל את מפתח הגישה שנחשף. 2. צרף מדיניות deny-all מוטבעת למשתמש/תפקיד כדי לבטל הפעלות STS פעילות. 3. סקור יומני CloudTrail עבור כל קריאות ה-API שנעשו עם המפתח. 4. מחק כל משאבים לא מורשים או ישויות IAM שנוצרו על ידי התוקף.

למה: ביטול המפתח עוצר שימוש עתידי. מדיניות ה-deny-all חיונית לביטול הפעלות פעילות שנוצרו *לפני* שהמפתח בוטל. CloudTrail מספק את מסלול הביקורת להערכת נזקים.

שפר את זיהוי האיומים של GuardDuty עם הזנות מודיעין איומים ספציפיות לחברה או לתעשייה.

→העלה קובץ טקסט רגיל של כתובות IP/CIDRs זדוניות ל-S3. צור והפעל סט מודיעין איומים חדש ב-GuardDuty, המצביע על קובץ ה-S3.

למה: זה מאפשר לך להרחיב את מודיעין האיומים המנוהל של GuardDuty עם IOCs מותאמים אישית, וליצור ממצאים כאשר המשאבים שלך מתקשרים עם כתובות ה-IP המצוינות הללו.

זהה מופעי EC2 עם נתיבי רשת פתוחים לאינטרנט ביציאות ספציפיות, תוך התחשבות בכל תצורות הרשת.

→הפעל את Amazon Inspector וסקור את ממצאי הנגישות לרשת שלו.

למה: Inspector מבצע ניתוח נתיב רשת מלא מ-IGWs למופעים, ומעריך קבוצות אבטחה, NACLs וטבלאות ניתוב כדי לקבוע נגישות בפועל. זה מדויק יותר מאשר רק בדיקת כללי קבוצת אבטחה בודדים.

חקור את מלוא היקפו של ממצא אבטחה, תוך ויזואליזציה של כל הישויות הקשורות וההתנהגות ההיסטורית.

→השתמש ב-Amazon Detective. נווט לפרופיל הישות (למשל, עבור מופע EC2 או תפקיד IAM) כדי לצפות בגרף ההתנהגות וציר הזמן של קריאות API קשורות, חיבורי רשת וממצאי GuardDuty.

למה: Detective מתאם אוטומטית יומנים מ-CloudTrail, VPC Flow Logs ו-GuardDuty, ומספק ניתוח הקשרי המאיץ משמעותית את חקירת שורש הבעיה בהשוואה לקורלציית יומנים ידנית.

אחסן יומני ביקורת (למשל, CloudTrail, VPC Flow Logs) לשמירה ארוכת טווח באופן עמיד בפני שינויים וניתן לשאילתה כדי לעמוד בדרישות תאימות.

→ספק יומנים ל-S3 bucket עם S3 Object Lock במצב Compliance מופעל. השתמש ב-Amazon Athena לשאילתות.

למה: Object Lock במצב Compliance מונע מחיקה או שינוי על ידי כל אחד, כולל משתמש ה-root, ומבטיח אי-שינוי של היומנים. Athena מספקת יכולות שאילתת SQL אד-הוק על היומנים המאוחסנים.

מקור↗

אסוף באופן מרכזי את כל אירועי הניהול והנתונים עבור ארגון AWS שלם.

→בחשבון הניהול, צור CloudTrail Organization Trail. כדי ללכוד נתונים ברמת אובייקט, השתמש בבוררי אירועים מתקדמים כדי לרשום סוגי אירועים ספציפיים (למשל, S3 PutObject, Lambda Invoke) עבור משאבים בעלי ערך גבוה.

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

בצע ניתוח מורכב מבוסס SQL על אירועי CloudTrail מכלל הארגון במשך מספר שנים.

→הפעל את AWS CloudTrail Lake וצור מאגר נתונים של אירועים ברמת הארגון עם תקופת השמירה הנדרשת (עד 7 שנים). השתמש בעורך שאילתות ה-SQL המובנה לניתוח.

למה: CloudTrail Lake מספק מאגר נתונים ומנוע שאילתות מנוהלים ובלתי ניתנים לשינוי, שנבנו במיוחד עבור אירועי CloudTrail, ומבטלים את הצורך בניהול S3, Glue ו-Athena לניתוח יומנים.

נטר את כל שאילתות ה-DNS המבוצעות על ידי משאבים בתוך VPC לציד איומים או פתרון תקלות.

→הפעל את Route 53 Resolver DNS Query Logging וקבע את תצורתו לשליחת יומנים ל-CloudWatch Logs, S3, או Kinesis Data Firehose.

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

רכז ונרמל יומני אבטחה ממקורות AWS וצד שלישי שונים לתוך Data Lake באמצעות סכימה סטנדרטית.

→פרוס את Amazon Security Lake. הוא אוסף ומנרמל נתונים אוטומטית לתוך Open Cybersecurity Schema Framework (OCSF) ואוגר אותם בפורמט Parquet ב-S3.

למה: Security Lake ממכן את היצירה והניהול של Security Data Lake, ומפחית את העומס התפעולי של בניית צינורות ETL מותאמים אישית לנרמול.

הפוך את איסוף הראיות לאוטומטי עבור ביקורות תאימות מול מסגרות כמו SOC 2, PCI DSS, או HIPAA.

→השתמש ב-AWS Audit Manager. בחר מסגרת מובנית מראש, אשר אוספת ראיות אוטומטית משירותי AWS (CloudTrail, Config, Security Hub) וממפה אותן לבקרות תאימות ספציפיות.

למה: Audit Manager ממכן ומרכז את תהליך איסוף הראיות, ומפחית משמעותית את המאמץ הידני הנדרש כדי להתכונן ולבצע ביקורות תאימות.

גלה וסווג אוטומטית נתונים רגישים (PII, PHI, פיננסיים) בכל S3 buckets.

→הפעל את Amazon Macie וקבע תצורת עבודות גילוי נתונים רגישים אוטומטיות. השתמש במזהי נתונים מנוהלים עבור סוגי נתונים נפוצים וצור מזהי נתונים מותאמים אישית עבור פורמטים קנייניים.

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

אכוף בקרות אבטחה מרובות על S3 bucket, כגון דרישת SSE-KMS עם מפתח ספציפי ודחיית בקשות HTTP.

→השתמש במדיניות bucket עם מספר הצהרות `Deny` ומפתחות תנאי: `aws:SecureTransport: false`, `s3:x-amz-server-side-encryption: "aws:kms"`, ו-`s3:x-amz-server-side-encryption-aws-kms-key-id: "key-arn"`.

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

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

→הפעל הצפנת EBS כברירת מחדל בהגדרות החשבון עבור כל Region, תוך ציון CMK. החל SCP המונע `ec2:CreateVolume` אם הפרמטר `encrypted` הוא `false` כמעקה בטיחות מונע.

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

הצפן אובייקטי נתונים גדולים (מעל 4KB) באמצעות AWS KMS.

→השתמש בהצפנת מעטפה (envelope encryption). קרא ל-`KMS:GenerateDataKey` כדי לקבל מפתח נתונים בטקסט רגיל ומפתח נתונים מוצפן. השתמש במפתח הטקסט הרגיל כדי להצפין את האובייקט הגדול באופן מקומי. אחסן את האובייקט המוצפן ואת מפתח הנתונים המוצפן יחד. זרוק את מפתח הטקסט הרגיל.

למה: ל-KMS Encrypt API מגבלת 4KB. הצפנת מעטפה מאפשרת הצפנת נתונים בכל גודל בעוד שמפתח הנתונים הקטן מוגן על ידי KMS, ומפחיתה עלות וזמן אחזור בהשוואה להזרמת נתונים דרך KMS.

מקור↗

השתמש באותו מפתח הצפנה במספר AWS Regions עבור DR או עקביות יישומים גלובלית.

→צור מפתח ראשי של KMS מרובה-Region ב-Region אחד וצור מפתחות רפליקה ב-Regions אחרים. נתונים מוצפנים עם מפתח ב-Region אחד ניתנים לפענוח עם הרפליקה ב-Region אחר.

למה: מפתחות מרובי-Region חולקים את אותו חומר מפתח ומזהה מפתח, ומאפשרים ניידות נתונים בין Region-ים ללא קריאות API בין Region-ים לפענוח.

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

→אחסן אישורי גישה ב-AWS Secrets Manager. קבע תצורת סיבוב אוטומטי באמצעות פונקציית סיבוב Lambda מותאמת אישית או מסופקת על ידי AWS. יישומים מאחזרים סודות בזמן ריצה באמצעות תפקיד IAM.

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

נהל גם אישורי TLS ציבוריים לאתרי אינטרנט וגם אישורים פרטיים לתקשורת פנימית של מיקרו-שירותים (mTLS).

→השתמש ב-AWS Certificate Manager (ACM) לאישורי ציבוריים בחינם המשולבים עם ELB/CloudFront. צור רשות אישורים פרטית באמצעות ACM Private CA להנפקה וניהול אישורים פרטיים לשירותים פנימיים.

למה: זה מפריד PKI ציבורי ופרטי, ומשתמש בכלי המתאים לכל מקרה שימוש. ACM מטפל במחזור החיים של אישורים ציבוריים, בעוד ש-ACM Private CA מספק היררכיית PKI פרטית מנוהלת במלואה.

אחסן נתונים באופן בלתי ניתן לשינוי לתקופת שמירה קבועה, כך שאף משתמש root לא יוכל למחוק אותם.

→הפעל S3 Object Lock על ה-bucket. הצב אובייקטים תחת תקופת שמירה עם מצב Compliance.

למה: מצב Compliance הוא בקרת ה-WORM (Write-Once-Read-Many) החזקה ביותר, המונעת מחיקה על ידי כל משתמש. מצב Governance יכול להיעקף על ידי principals מורשים.

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

→הפעל AWS Backup Vault Lock במצב Compliance עם תקופת שמירה מינימלית.

למה: Vault Lock במצב Compliance הופך את כספת הגיבוי לתואמת WORM, ומונע מכל משתמש, כולל root, למחוק נקודות שחזור לפני שתקופת השמירה תפוג.

עבד נתונים רגישים ביותר שבהם הנתונים אסור שייחשפו למערכת ההפעלה, ל-hypervisor או למפעילי AWS.

→השתמש ב-AWS Nitro Enclaves כדי ליצור סביבת חישוב מבודדת קריפטוגרפית. השתמש באימות KMS כדי להבטיח שרק מובלעות מאומתות יכולות לפענח נתונים.

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

השתמש בשירותי AWS עם מפתחות הצפנה המאוחסנים ומנוהלים פיזית ב-HSM מקומי, מחוץ ל-AWS.

→קבע תצורת KMS External Key Store (XKS) המתווך פעולות קריפטוגרפיות מ-KMS למנהל מפתחות חיצוני.

למה: XKS מאפשר ללקוחות לשמור על שליטה בחומר המפתח שלהם מחוץ ל-AWS כדי לעמוד בדרישות ריבונות או תאימות, תוך שילוב עם שירותי AWS התומכים ב-KMS.

אכוף מדיניות מחמירה של "אין S3 buckets ציבוריים" בכל הארגון עם בקרות מונעות ובלשיות.

→הפעל S3 Block Public Access ברמת הארגון מחשבון הניהול. השלם עם SCP המונע פעולות כמו `s3:PutBucketPolicy` אם המדיניות מאפשרת גישה ציבורית. השתמש ב-AWS Config כדי לזהות סטייה.

למה: גישה שכבתית זו מספקת חסימה כברירת מחדל (הגדרת ארגון), מעקה בטיחות מונע שעוצר תצורות שגויות (SCP), ובקרת גילוי לניטור מתמשך (Config).

בדוק את כל תעבורת ה-inter-VPC ותעבורה יוצאת לאינטרנט באמצעות מכשיר אבטחה מרכזי (לדוגמה, AWS Network Firewall).

→צור VPC ייעודי לבדיקה. השתמש ב-Transit Gateway כדי לחבר את כל ה-VPCs. קבע את תצורת טבלאות הניתוב של TGW לשלוח את כל התעבורה דרך VPC הבדיקה. אפשר מצב Appliance בחיבור ה-TGW לניתוב סימטרי.

למה: זהו מודל ה-hub-and-spoke הסטנדרטי לבדיקת תעבורה מרכזית, המספק סילומיות ואכיפת מדיניות עקבית ללא רשתות VPC peering מורכבות.

הגן על יישום ווב (ב-CloudFront/ALB) מפני OWASP Top 10, בוטים, והתקפות השתלטות על חשבונות.

→צרף את AWS WAF עם AWS Managed Rules (לדוגמה, `AWSManagedRulesCommonRuleSet`), קבוצת הכללים המנוהלת Bot Control, וקבוצת הכללים המנוהלת Account Takeover Prevention (ATP).

למה: גישה שכבתית זו משתמשת במספר קבוצות כללים מנוהלות להגנה רחבה (Common), זיהוי תעבורה אוטומטי (Bot Control), ואבטחת נקודות קצה ייעודיות להתחברות (ATP).

ספק גישה מאובטחת ופרטית לשירות SaaS API מ-VPCs של לקוחות מבלי לחשוף את השירות לאינטרנט.

→צור שירות נקודת קצה של AWS PrivateLink המגובה על ידי Network Load Balancer (NLB). לקוחות יוצרים נקודות קצה של ממשק VPC ב-VPCs שלהם כדי לגשת לשירות.

למה: PrivateLink שומר את התעבורה על עמוד השדרה הפרטי של AWS, מונע את האינטרנט הציבורי ומבטל את הצורך ב-VPC peering מורכב, VPNs, או רשימת IP לבנים. זוהי התבנית הסטנדרטית והסקלאבילית לקישוריות SaaS פרטית.

הגבל את הגישה ל-S3 bucket כך שהתוכן יהיה נגיש רק דרך הפצת CloudFront.

→השתמש ב-CloudFront Origin Access Control (OAC). עדכן את מדיניות ה-S3 bucket כדי לאפשר גישה רק מה-service principal של הפצת CloudFront, מותנה ב-ARN הספציפי של ההפצה.

למה: OAC היא השיטה המומלצת הנוכחית, עדיפה על פני Origin Access Identity (OAI) המיושנת. היא תומכת בכל תכונות S3, כולל SSE-KMS, ועוקבת אחר שיטות אבטחה מומלצות.

ספק גישת מעטפת מאובטחת וניתנת לביקורת למופעי EC2 בתתי-רשת פרטיים מבלי לפתוח יציאות SSH/RDP או לנהל מארחי bastion.

→התקן את סוכן SSM על מופעי EC2. השתמש ב-AWS Systems Manager Session Manager לגישה. מדיניות IAM שולטת מי יכול להתחיל הפעלות. פעילות ההפעלה ניתנת לרישום ל-CloudWatch Logs ו-S3.

למה: Session Manager מספק גישה מאובטחת, מבוססת דפדפן או CLI דרך מנהרה מוצפנת, מבטל את הצורך ביציאות נכנסות, מארחי bastion, ומפתחות SSH, תוך מתן יכולת ביקורת מלאה.

הטמע סינון ברמת ה-DNS כדי למנוע ממשאבי VPC לפתור דומיינים זדוניים ידועים.

→קבע את תצורת Route 53 Resolver DNS Firewall עם רשימות דומיינים מנוהלות (עבור תוכנות זדוניות, C2) ורשימות חסימה מותאמות אישית. קשר את קבוצת כללי חומת האש ל-VPCs.

למה: זה מספק שירות סינון DNS מרכזי ומנוהל ברמת ה-VPC, החוסם פעילות זדונית בנקודה המוקדמת ביותר (פתרון DNS) מבלי לדרוש סוכנים מבוססי מארח.

הטמע בקרות רשת של הרשאות מינימליות עבור יישום ווב בעל שלוש שכבות.

→צור קבוצות אבטחה נפרדות לכל שכבה. קבוצת האבטחה של ALB מאפשרת תעבורה נכנסת ביציאה 443 מ-`0.0.0.0/0`. קבוצת האבטחה של היישום מאפשרת תעבורה נכנסת רק מקבוצת האבטחה של ALB. קבוצת האבטחה של DB מאפשרת תעבורה נכנסת רק מקבוצת האבטחה של היישום ביציאת מסד הנתונים.

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

הענק הרשאות AWS מדויקות ברמת ה-pod ליישומים הפועלים על EKS, תוך הימנעות משימוש בתפקידי IAM משותפים של צמתים.

→הפעל IAM Roles for Service Accounts (IRSA) באשכול EKS. צור תפקיד IAM עם הרשאות ספציפיות ליישום. סמן את חשבון השירות של Kubernetes של היישום עם ה-ARN של תפקיד ה-IAM.

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

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

→פרוס את AWS Verified Access. שלב עם IdP ארגוני כספק אמון משתמשים ופתרון ניהול מכשירים כספק אמון מכשירים. צור מדיניות גישה פר-יישום.

למה: Verified Access בנוי במיוחד לגישת zero-trust, ומעריך כל בקשה מול מדיניות המתחשבת בהקשר של המשתמש והמכשיר, ומבטל את ההסתמכות על אבטחת היקף הרשת.

אפשר למפתחים ליצור תפקידי IAM אך מנע מהם ליצור תפקידים שיכולים להגדיל את הרשאותיהם.

→צור מדיניות גבול הרשאות המגדירה את הרשאות המקסימום המותרות. במדיניות ה-IAM של המפתחים, הגדר תנאי להרשאת `iam:CreateRole` שידרוש צירוף של גבול ספציפי זה באמצעות מפתח התנאי `iam:PermissionsBoundary`.

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

מקור↗

מנע מכל משתמש בכל חשבון חבר (כולל מנהלי מערכת) לבצע פעולות בסיכון גבוה, כגון השבתת CloudTrail או מחיקת S3 bucket נפוץ.

→החל Service Control Policy (SCP) על ה-root או ה-OU הרלוונטי שיש לו הצהרת `Deny` עבור הפעולות המוגבלות (לדוגמה, `cloudtrail:StopLogging`, `s3:DeleteBucket`).

למה: SCPs הם מעקה הבטיחות האולטימטיבי ב-AWS Organizations. הם קובעים את הרשאות המקסימום לכל ה-principals בחשבון, והצהרת Deny מפורשת ב-SCP אינה ניתנת לעקיפה על ידי שום מדיניות IAM בתוך החשבון.

ספק גישת cross-account מאובטחת וניתנת לביקורת עבור יישום או משתמש.

→בחשבון היעד, צור תפקיד IAM עם מדיניות אמון המציינת את ה-ARN של ה-principal בחשבון המקור. בחשבון המקור, הענק ל-principal הרשאת `sts:AssumeRole` על תפקיד היעד. היישום משתמש ב-STS AssumeRole כדי לקבל אישורי גישה זמניים.

למה: זוהי התבנית הסטנדרטית לגישת cross-account. היא משתמשת באישור גישה זמני וקצר-חיים וניתנת לביקורת מלאה בשני החשבונות באמצעות CloudTrail.

שלב את IAM Identity Center עם IdP חיצוני (לדוגמה, Okta, Azure AD) והפוך את הקצאת משתמשים/קבוצות לאוטומטית.

→קבע את תצורת ה-IdP החיצוני כמקור הזהות ב-IAM Identity Center. הפעל הקצאה אוטומטית באמצעות SCIM כדי לסנכרן משתמשים וקבוצות. הקצה ערכות הרשאות לקבוצות המסונכרנות.

למה: SCIM (System for Cross-domain Identity Management) מספק סנכרון אוטומטי, כמעט בזמן אמת, של זהויות, מבטל ניהול משתמשים ידני ומבטיח שגישת AWS מונעת על ידי ה-IdP.

הענק גישה למשאבים (לדוגמה, EC2) בהתבסס על תגים, כאשר principals יכולים לנהל רק משאבים מתויגים בשם הצוות/המחלקה שלהם.

→תייג גם את ה-principals של IAM (משתמשים/תפקידים) וגם את המשאבים (מופעי EC2) עם מפתח משותף (לדוגמה, `Team`). צור מדיניות IAM יחידה המאפשרת פעולות עם תנאי המשווה את `aws:PrincipalTag/Team` ל-`aws:ResourceTag/Team`.

למה: Attribute-Based Access Control (ABAC) מספק מודל הרשאות סקלאבילי שאינו דורש עדכוני מדיניות כאשר מתווספים משאבים או צוותים חדשים. ההרשאות נקבעות באופן דינמי בהתבסס על תגים.

principal בחשבון B צריך לקרוא אובייקט S3 בחשבון A שמוצפן עם מפתח KMS הנמצא גם הוא בחשבון A.

→נדרשות שלוש הרשאות: 1) מדיניות ה-S3 bucket בחשבון A חייבת לאפשר את ה-principal מחשבון B. 2) מדיניות מפתח ה-KMS בחשבון A חייבת לאפשר את ה-principal מחשבון B עבור `kms:Decrypt`. 3) ל-principal בחשבון B נדרשת מדיניות IAM המאפשרת `s3:GetObject` ו-`kms:Decrypt`.

למה: גישה לנתונים מוצפנים באמצעות KMS דורשת הרשאות הן משירות הנתונים (S3) והן משירות ההצפנה (KMS). מדיניות מפתח ה-KMS היא מדיניות משאב וחיונית להענקת גישת cross-account.

הבן את תוצאת ההרשאה הסופית כאשר מיושמות מספר מדיניות (IAM, משאב, SCP, גבול).

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

למה: זהו מושג יסוד ב-IAM. Deny מפורש הוא ההצהרה החזקה ביותר ומשמש כ-'לא' קשיח. הבנה זו חיונית לפתרון בעיות גישה.

מנע ממשתמש או תפקיד IAM להעביר תפקיד בעל הרשאות גבוהות לשירות AWS (לדוגמה, EC2), דבר שיגדיל את הרשאותיו.

→הגבל את הרשאת `iam:PassRole` במדיניות ה-IAM של המשתמש/תפקיד. הגבל את רכיב ה-`Resource` רק ל-ARNs של תפקידים ספציפיים בעלי הרשאות מינימליות שהישות מורשית להעביר.

למה: `iam:PassRole` עם wildcard (`"Resource": "*"`) הוא סיכון משמעותי להרחבת הרשאות. הגבלתו לתפקידים ספציפיים בעלי פחות הרשאות היא בקרת אבטחה קריטית.

אתגר משתמשים עם MFA רק כאשר ניסיון כניסה נחשב מסוכן (לדוגמה, מכשיר חדש, מיקום לא רגיל).

→הפעל תכונות אבטחה מתקדמות ב-Cognito User Pool וקבע תצורת אימות אדפטיבי עם אכיפת MFA מבוססת סיכונים.

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

אפשר לשרתים מקומיים המשתמשים ב-PKI פרטי לגשת לשירותי AWS ללא אישורי AWS לטווח ארוך.

→קבע תצורת IAM Roles Anywhere. צור עוגן אמון באמצעות אישור CA פרטי. צור פרופילים הממפים אישורים לתפקידי IAM. שרתים משתמשים באישורם כדי לקבל אישורי AWS זמניים.

למה: זה מרחיב את תפקידי IAM לעומסי עבודה חיצוניים על ידי מינוף PKI קיים, ומבטל את הצורך בניהול מפתחות גישה של AWS בסביבה המקומית.

מנע פריסה של משאבים שאינם תואמים המוגדרים בתבניות CloudFormation *לפני* שהם מסופקים.

→הפעל בקרות פרואקטיביות של AWS Control Tower. אלה משתמשים ב-CloudFormation hooks כדי לאמת תצורות משאבים מול מדיניות (כתובות ב-cfn-guard) לפני האספקה.

למה: זוהי בקרת "shift-left" המונעת תצורות שגויות במקור, יעילה יותר מאשר זיהוי ותיקון שלהן לאחר פריסתן.