מדריך

קישוריות Full mesh עבור VPCs רבים, חלקם עם CIDRs חופפים.

→פרוס Transit Gateway. תקן CIDRs חופפים על ידי הוספת בלוקי CIDR משניים וייחודיים ל-VPCs המושפעים.

למה: Transit Gateway מספק ניתוב סקלבילי וטרנזיטיבי אך אינו יכול לנתב בין טווחי IP חופפים. תיקון IP נדרש.

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

→ספק שני חיבורי Direct Connect ייעודיים בשני מיקומי Direct Connect שונים.

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

פתרון DNS דו-כיווני בין private hosted zones מקומיים (on-premises) לבין AWS.

→השתמש ב-Route 53 Resolver. צור Inbound Endpoints עבור on-prem לשאילתות AWS. צור Outbound Endpoints עם כללי העברה עבור AWS לשאילתות on-prem.

למה: Inbound endpoints מספקים כתובות IP נגישות עבור DNS forwarders מקומיים. Outbound endpoints מאפשרים העברה מותנית מתוך ה-VPC. ה-resolver ברירת המחדל של ה-VPC (VPC+2) אינו נגיש מ-on-prem.

ספק גישה ברמת שירות בין שני VPCs מבלי ליצור נתיבים ברמת הרשת.

→השתמש ב-AWS PrivateLink. צור VPC Endpoint Service (מגובה על ידי NLB) ב-VPC הספק (provider) ו-Interface VPC Endpoint ב-VPC הצרכן (consumer).

למה: PrivateLink מספק קישוריות חד-כיוונית, ספציפית לשירות, באמצעות ENIs ב-VPC של הצרכן, ונמנע לחלוטין מניתוב ברמת הרשת ומבעיות חפיפת CIDR.

ספק גישת אינטרנט יוצאת בלבד עבור מופעי IPv6-enabled ב-subnets פרטיים.

→צור Egress-Only Internet Gateway (EIGW) והוסף נתיב עבור `::/0` לטבלת הניתוב של ה-subnet הפרטי המצביע על ה-EIGW.

למה: EIGW שומר מצב עבור חיבורי IPv6 יוצאים, מאפשר תעבורה חוזרת אך מונע חיבורים נכנסים בלתי יזומים, בדומה ל-NAT Gateway אך עבור IPv6.

בדוק את כל התעבורה בין VPCs באמצעות AWS Network Firewall במודל מרכזי עם Transit Gateway.

→צור VPC בדיקה ייעודי עם Network Firewall. הגדר טבלאות ניתוב של TGW לשליחת כל התעבורה בין VPCs ל-VPC הבדיקה. בתוך VPC הבדיקה, טבלאות הניתוב חייבות לנתב תעבורה דרך נקודות הקצה של NFW עבור ניתוב סימטרי.

למה: ארכיטקטורה זו דורשת ניתוב קפדני: TGW שולח תעבורה ל-VPC הבדיקה; טבלאות ניתוב של VPC שולחות אותה לנקודת הקצה של חומת האש; חומת האש שולחת אותה בחזרה ל-ENI של חיבור ה-TGW; TGW מנתב אותה ליעד הסופי.

פילוח VPCs (לדוגמה, prod לעומת dev) באמצעות Transit Gateway, תוך מתן אפשרות לשניהם לגשת ל-VPC של שירותים משותפים.

→השתמש בטבלאות ניתוב מרובות של Transit Gateway. צור טבלת ניתוב עבור כל קטע (prod, dev, shared). קשר VPCs לטבלאות המתאימות להם. הפץ נתיבים כדי ליצור טופולוגיית hub-spoke שבה ה-spokes יכולים לראות רק את ה-hub.

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

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

→השתמש ב-AWS Global Accelerator. הוא מספק כתובות IP מסוג anycast שמנתבות משתמשים למיקום הקצה הקרוב ביותר של AWS, ואז התעבורה עוברת דרך עמוד השדרה הממוטב של AWS למקור.

למה: Global Accelerator מייעל את ה-"first mile" ואת ה-"middle mile" על גבי רשת AWS, מפחית זמן אחזור ורעידות (jitter) עבור תעבורת TCP/UDP. CloudFront עדיף עבור תוכן ניתן לשמירה במטמון.

ספק גישה פרטית מ-VPC ל-S3 ול-DynamoDB מבלי לעבור דרך האינטרנט.

→צור Gateway VPC Endpoints עבור S3 ו-DynamoDB. זה מוסיף ערכי prefix list לטבלאות הניתוב של ה-subnets שצוינו.

למה: Gateway endpoints הם המנגנון הספציפי, בעל ביצועים גבוהים וללא עלות, לגישה פרטית ל-S3 ול-DynamoDB. שירותים אחרים משתמשים ב-Interface Endpoints (PrivateLink).

גש ל-VPCs במספר אזורי AWS מחיבור Direct Connect מקומי יחיד.

→השתמש ב-Direct Connect Gateway עם Transit Virtual Interface (T-VIF). קשר את ה-DX Gateway ל-Transit Gateways בכל אזור נדרש.

למה: Transit VIF עם DX Gateway הוא הפתרון הסקלבילי לחיבור ל-Transit Gateways מרובים על פני אזורים. ל-Private VIF עם DX Gateway יש מגבלות נמוכות יותר.

שלב מכשיר חומת אש וירטואלי של צד שלישי לבדיקת תעבורה שקופה.

→השתמש ב-Gateway Load Balancer (GWLB). הוא פועל בשכבה 3 ומשתמש בפרוטוקול GENEVE כדי לעטוף (encapsulate) תעבורה, ומשמר את כתובת ה-IP המקור/יעד המקורית.

למה: עטיפת GENEVE של GWLB הופכת אותו ל-"bump-in-the-wire", מכניסה התקנים באופן שקוף לנתיב הרשת מבלי לדרוש source NAT, וזה קריטי עבור התקני אבטחה.

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

→השתמש ב-Amazon VPC IP Address Manager (IPAM). צור pool ברמה העליונה והאצל poolים אזוריים כדי להפוך את הקצאת CIDR ל-VPC לאוטומטית.

למה: VPC IPAM הוא שירות AWS ייעודי וסקלבילי לניהול כתובות IP מרכזי, המחליף שיטות ידניות הנוטות לשגיאות.

שלב מכשיר SD-WAN של צד שלישי עם Transit Gateway באמצעות מנהרות GRE וניתוב BGP דינמי.

→השתמש בחיבור Transit Gateway Connect.

למה: TGW Connect תוכנן במיוחד לשילוב SD-WAN. הוא תומך ב-GRE עבור רוחב פס גבוה יותר (עד 5 Gbps ל-peer) וב-BGP עבור ניתוב דינמי.

VPC המבוסס על IPv6 בלבד צריך לתקשר עם משאבים המבוססים על IPv4 בלבד באינטרנט.

→אפשר DNS64 בהגדרות Route 53 Resolver של ה-VPC והגדר NAT Gateway ב-subnet ציבורי. נתב `64:ff9b::/96` אל ה-NAT Gateway.

למה: DNS64 מסנתז רשומות AAAA עבור יעדי IPv4. ה-NAT Gateway מבצע את תרגום פרוטוקול NAT64 מכתובת ה-IPv6 המסונתזת לכתובת ה-IPv4 האמיתית.

חבר מאות VPCs על פני אזורים רבים עם דרישות פילוח קפדניות (prod, dev, shared services).

→השתמש ב-AWS Cloud WAN. הגדר segments ו-segment actions במדיניות רשת ליבה יחידה כדי לשלוט בניתוב בין segments באופן גלובלי.

למה: Cloud WAN מספק מדיניות רשת גלובלית מרכזית ודקלרטיבית, שהיא סקלבילית יותר ופחות מורכבת מניהול רשת מלאה של חיבורי Transit Gateway וטבלאות ניתוב בכל אזור.

צבירת חיבורי Direct Connect מרובים במיקום יחיד עבור רוחב פס מוגדל ועמידות קישור.

→הגדר Link Aggregation Group (LAG). כל החיבורים חייבים להיות בעלי אותו רוחב פס ולהסתיים באותו התקן AWS.

למה: LAGs מאגדות קישורים פיזיים לקישור לוגי אחד. זה מספק failover ברמת הקישור אך אינו מגן מפני כשל של התקן או מיקום. השתמש ב-`minimum links` כדי להגדיר את סף ה-failover.

השגת failover של DNS בפחות מ-60 שניות עבור יישום רב-אזורי.

→השתמש בניתוב failover של Route 53 עם בדיקות תקינות. הגדר בדיקות תקינות במרווח מהיר (10 שניות) עם סף כשל נמוך (1). השתמש ברשומות Alias או ב-TTLs נמוכים מאוד (לדוגמה, 10-60 שניות).

למה: failover מהיר דורש זיהוי מהיר (בדיקות תקינות מהירות) ועדכונים מהירים בצד הלקוח (TTLs נמוכים או רשומות Alias שיש להן TTLs דינמיים).

הגדל את תפוקת ה-VPN הכוללת על ידי שימוש בשתי המנהרות של חיבור Site-to-Site VPN בו-זמנית.

→צרף את ה-VPN ל-Transit Gateway. אפשר תמיכת ECMP בחיבור ה-VPN של Transit Gateway.

למה: כברירת מחדל, VPN ל-TGW עשוי להשתמש במנהרה אחת בלבד. הפעלת ECMP על חיבור ה-TGW מפיצה תעבורה על פני שתי המנהרות אם נתיבי BGP הם בעלי עלות שווה.

ודא ששירותי TCP ב-backend מאחורי Network Load Balancer רואים את כתובת ה-IP המקורית של הלקוח.

→רשום יעדים לפי מזהה מופע (instance ID). אם יעדים רשומים לפי IP, אפשר Proxy Protocol v2 בקבוצת היעד.

למה: כאשר יעדים רשומים לפי instance ID, ה-NLB משמר את IP הלקוח כברירת מחדל. אם רשומים לפי IP, ה-IP של ה-NLB הופך למקור, ו-Proxy Protocol v2 נדרש כדי להעביר את ה-IP המקורי.

השפיע על אופן ניתוב התעבורה של AWS חזרה לרשת מקומית כאשר קיימים נתיבי Direct Connect מרובים.

→השתמש ב-BGP AS path prepending על הנתיב המועדף פחות מהנתב המקומי.

למה: עבור תעבורה יוצאת מ-AWS, המנגנון העיקרי הנשלט על ידי הלקוח הוא אורך נתיב ה-AS. AWS מעדיף את הנתיב עם נתיב ה-AS הקצר ביותר. לא ניתן להגדיר העדפה מקומית בצד AWS.

אפשר לחשבונות spoke בארגון AWS לצרף את ה-VPCs שלהם ל-Transit Gateway בבעלות חשבון רשת מרכזי.

→השתמש ב-AWS Resource Access Manager (RAM). חשבון הרשת משתף את ה-Transit Gateway עם הארגון או עם יחידות ארגוניות (OUs) ספציפיות.

למה: RAM הוא שירות AWS הספציפי שתוכנן לשיתוף משאבים כמו Transit Gateways בין חשבונות. זה מאפשר ניהול מרכזי תוך מתן אפשרות לחיבור בשירות עצמי עבור חשבונות spoke.

צבור תפוקה מעבר למגבלת 1.25 Gbps של מנהרת VPN יחידה.

→צור חיבורי Site-to-Site VPN מרובים ל-Transit Gateway עם ECMP מופעל.

למה: כל מנהרת VPN מוגבלת לכ-1.25 Gbps. כדי להגדיל קנה מידה, עליך להשתמש במספר מנהרות/חיבורים ולמנף ECMP ב-Transit Gateway כדי לאזן עומסים של תעבורה ביניהם.

הגדר בדיקות תקינות של Route 53 עבור משאב פנימי, שאינו פונה לאינטרנט, כמו ALB פנימי.

→צור אזעקת CloudWatch המנטרת מדד עבור המשאב הפנימי (לדוגמה, `HealthyHostCount` עבור ALB). הגדר את בדיקת התקינות של Route 53 לנטר את מצב אזעקת CloudWatch.

למה: בודקי התקינות של Route 53 הם חיצוניים. כדי לנטר משאבים פנימיים, עליהם לנטר אות proxy כמו מצב אזעקת CloudWatch, אשר יכול להידלק על ידי מדדים פנימיים.

בצע failover אוטומטי של תעבורת CloudFront למקור משני (לדוגמה, אתר S3 סטטי) כאשר המקור הראשי (לדוגמה, ALB) מחזיר שגיאות 5xx.

→צור CloudFront Origin Group עם ה-ALB כראשי ו-S3 כמשני. הגדר אותו לבצע failover על קודי סטטוס ספציפיים (לדוגמה, 500, 502, 503, 504).

למה: Origin Groups הם מנגנון CloudFront המובנה עבור זמינות גבוהה, המספקים failover חלק בקצה ללא צורך בשינויי DNS.

השגת failover בפחות משנייה עבור חיבור Direct Connect ל-VPN גיבוי או נתיב DX משני.

→אפשר Bidirectional Forwarding Detection (BFD) על ממשק ה-Direct Connect הוירטואלי. הגדר BFD על הנתב המקומי (on-premise).

למה: BFD מספק זיהוי כשל קישור מהיר בהרבה (עד 300 אלפיות השנייה) בהשוואה לטיימרי keepalive של BGP (ברירת מחדל 90 שניות), ומאפשר התכנסות תעבורה מהירה.

אפשר קישוריות בין Transit Gateways בשני אזורים שונים.

→צור חיבור Transit Gateway peering. הוסף ידנית נתיבים סטטיים בכל טבלת ניתוב של TGW המצביעים על CIDRs של האזור המרוחק דרך חיבור ה-peering.

למה: באופן מכריע, Transit Gateway inter-region peering אינו תומך בהפצת נתיבים דינמית. כל הנתיבים בין אזורים חייבים להיות מוגדרים באופן סטטי.

פתור בעיות קישוריות בתוך AWS על ידי זיהוי הרכיב החוסם הספציפי (לדוגמה, route, NACL, SG).

→השתמש ב-VPC Reachability Analyzer. ציין מקור ויעד, והוא יבצע ניתוח סטטי של תצורת נתיב הרשת.

למה: Reachability Analyzer מספק ניתוח חד-משמעי, hop-by-hop של מבני רשת AWS, שהוא יעיל יותר מ-traceroute (שעלול לא לעבוד) או בדיקה ידנית של כל רכיב.

אחסון לטווח ארוך ושאילתות ad-hoc של VPC Flow Logs מפורטים לצורך תאימות.

→פרסם flow logs ישירות ל-S3 בפורמט Parquet עם פריסת שדות מותאמת אישית. השתמש ב-Amazon Athena עבור שאילתות ad-hoc מבוססות SQL.

למה: S3 הוא האחסון היעיל ביותר מבחינת עלות. פורמט Parquet יעיל מאוד עבור שאילתות Athena, מפחית עלויות סריקה ומשפר ביצועים. זהו דפוס ה-serverless, הסקלבילי לניתוח flow logs.

אכוף מרכזית כללי קבוצת אבטחה (security group) חובה על פני כל ה-VPCs בארגון AWS ובצע תיקון אוטומטי של אי-ציות.

→השתמש ב-AWS Firewall Manager עם מדיניות ביקורת של קבוצת אבטחה. הגדר את הכללים הנדרשים והגדר את המדיניות לתיקון אוטומטי של קבוצות שאינן תואמות.

למה: Firewall Manager הוא כלי הממשל המרכזי עבור מדיניות אבטחה (WAF, SG, NFW) על פני ארגון. מדיניות הביקורת שלו עם תיקון אוטומטי מספקת אכיפה.

הצג ונטר טופולוגיית רשת גלובלית הכוללת Transit Gateways, VPNs ו-Direct Connect על פני אזורים וחשבונות.

→השתמש ב-AWS Network Manager. רשום Transit Gateways לרשת גלובלית אחת כדי לקבל לוח מחוונים מרכזי, מפת טופולוגיה וניטור תקינות.

למה: Network Manager נבנה במיוחד כדי לספק ממשק אחיד לרשתות AWS גלובליות מורכבות, מאחד ניטור וניהול.

אבחן אובדן מנות או שגיאות לסירוגין בחיבור Direct Connect.

→בדוק מדדי CloudWatch של Direct Connect (`ConnectionErrorCount`). בנתב הלקוח, בדוק רמות אות אופטי (רמות אור Tx/Rx) ומוני שגיאות ממשק (שגיאות CRC, שגיאות קלט).

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

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

→השתמש ב-AWS Config עם כלל מנוהל (לדוגמה, `restricted-ssh`) והגדר פעולת תיקון אוטומטית באמצעות מסמך SSM Automation.

למה: זה מספק מערכת תאימות בלולאה סגורה. AWS Config מזהה את ההפרה, ופעולת התיקון שלו מפעילה מסמך SSM לתיקון אוטומטי של התצורה.

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

→השתמש ב-VPC Network Access Analyzer. הגדר היקף גישה והפעל ניתוח כדי לקבל רשימה של כל נתיבי הרשת האפשריים התואמים.

למה: כלי זה מבצע אימות רשת פורמלי, מנתח את כל הרכיבים (SGs, NACLs, TGW, IGW) כדי למצוא נתיבים פוטנציאליים, וזה מקיף יותר מבדיקות ידניות או ניטור תגובתי.

אסוף VPC Flow Logs, DNS Query Logs ו-Network Firewall logs מחשבונות חברים רבים לחשבון רישום מרכזי.

→הגדר שירותים בחשבונות חברים לפרסם יומנים ישירות לדלי S3 מרכזי (עבור Flow Logs/NFW) או לקבוצת יומנים של CloudWatch (עבור יומני DNS) בחשבון הרישום, באמצעות מדיניות דלי וחשבונות IAM חוצי חשבונות.

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

מטב עלויות רשת עבור תעבורה בנפח גבוה בין זוגות ספציפיים של VPCs בארכיטקטורת Transit Gateway hub-and-spoke.

→עבור זוגות VPCs עם תעבורה גבוהה, צור חיבור VPC peering ישיר כדי לעקוף את ה-Transit Gateway. שמור את ה-TGW עבור כל שאר תעבורת ה-hub-spoke.

למה: ל-VPC peering אין חיוב עיבוד נתונים לכל GB (רק העברת נתונים סטנדרטית), בעוד של-Transit Gateway יש. העברת תעבורת point-to-point בנפח גבוה ל-peering מפחיתה משמעותית עלויות.

הצפן תעבורת Direct Connect בשכבה 2 עבור ביצועים בקצב קו.

→אפשר MACsec (IEEE 802.1AE). דורש חיבור ייעודי של 10Gbps או 100Gbps במיקום תומך MACsec.

למה: MACsec מספק הצפנה מקצה לקצה (hop-by-hop) בין נתב הלקוח והתקן AWS, ומאבטח את הקישור הפיזי עם עומס ביצועים מינימלי.

הגן על יישום ווב מפני התקפות נפוצות (SQLi, XSS) והגבל גישה לפי מדינה.

→השתמש ב-AWS WAF. צרף web ACL ל-ALB/CloudFront. השתמש בקבוצות כללים מנוהלות של AWS (לדוגמה, `AWSManagedRulesSQLiRuleSet`, `AWSManagedRulesCommonRuleSet`) וצור כלל התאמה גיאוגרפית (geo-match).

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

יישם בידוד יישומים מרובי שכבות (לדוגמה, web -> app -> db) בתוך VPC.

→צור קבוצת אבטחה עבור כל שכבה. השתמש בהפניות למזהי קבוצת אבטחה בכללים (לדוגמה, ה-app-sg מאפשר תעבורה נכנסת מה-web-sg).

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

נטר וזהה איומים מבוססי DNS כמו DNS tunneling ותקשורת עם שרתי C2.

→אפשר רישום שאילתות של Route 53 Resolver. אפשר Amazon GuardDuty, המנתח את יומני שאילתות ה-DNS כמקור נתונים.

למה: ל-GuardDuty יש מודיעין איומים מובנה המנתח יומני DNS כדי לזהות דומיינים זדוניים ידועים, DGAs ודפוסי שאילתות חריגים המעידים על חילוץ נתונים.

ודא שתוכן S3 נגיש רק דרך CloudFront, לא ישירות דרך כתובת ה-URL של S3, תוך מתן אפשרות ל-IAM principals אחרים לגשת.

→השתמש ב-Origin Access Control (OAC). עדכן את מדיניות דלי ה-S3 כדי לאפשר גישה מ-service principal של OAC ומכל תפקידי/משתמשי IAM נדרשים אחרים.

למה: OAC הוא התחליף המודרני ל-OAI. הוא יוצר service principal שניתן להפנות אליו במדיניות דלי, ומספק בקרת גישה מדויקת וגמישה יותר.

מנע ממשתמשים לעקוף את CloudFront ולגשת ישירות למקור ALB.

→הגדר את CloudFront להוסיף כותרת HTTP מותאמת אישית עם ערך סודי לבקשות מקור. צור כלל listener של ALB שבודק את הכותרת והערך הזה, וחוסם בקשות שאין להן אותם.

למה: זה מספק הגנה חזקה יותר מהגבלות מבוססות IP (באמצעות managed prefix list), מכיוון שהוא מאמת שהבקשה הגיעה מההפצה הספציפית שלך. השתמש בשניהם עבור הגנה רב-שכבתית (defense-in-depth).

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

→השתמש ב-VPC Traffic Mirroring. הגדר סשן mirror על ה-ENI של המופע כדי להעתיק תעבורה ליעד (לדוגמה, NLB העומד בראש כלי ניתוח).

למה: Traffic Mirroring מספק לכידת חבילות מלאה וללא סוכנים, וזה חיוני לניתוח פורנזי מעמיק. Flow logs מספקים רק מטא-נתונים.

ספק הגנת DDoS מקיפה ליישומים הפונים לציבור.

→הירשם ל-AWS Shield Advanced. קשר הגנה למשאבים קריטיים (CloudFront, ALB, EIPs, Route 53). השתמש ב-AWS WAF להפחתת איומי שכבה 7. הפעל את צוות התגובה של Shield (SRT) במהלך התקפות.

למה: Shield Advanced מספק זיהוי משופר, הגנת עלויות מפני הגדלת קנה מידה הנגרמת על ידי DDoS, וגישה ל-SRT לסיוע מומחה, וזה קריטי עבור יישומים קריטיים לעסק.

הנפק וסובב אוטומטית אישורי TLS עבור מיקרו-שירותים פנימיים מ-Certificate Authority פרטי.

→השתמש ב-AWS Private Certificate Authority (Private CA) כדי ליצור את ה-CA. השתמש ב-AWS Certificate Manager (ACM) כדי להנפיק ולנהל את מחזור החיים (כולל חידוש אוטומטי) של אישורים פרטיים מאותו CA.

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

מנע מכל משתמש בכל חשבון חבר בארגון AWS ליצור או לצרף Internet Gateway.

→החל Service Control Policy (SCP) בשורש הארגון ששולל את הפעולות `ec2:CreateInternetGateway` ו-`ec2:AttachInternetGateway`.

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

פענוח ובדיקת תעבורת HTTPS לאיתור איומים באמצעות AWS Network Firewall, ולאחר מכן הצפנה מחדש שלה.

→צור או ייבא אישור CA ב-ACM. צור תצורת בדיקת TLS במדיניות חומת האש המפנה ל-CA זה. הפץ את אישור ה-CA למערכות הלקוח כ-CA שורש מהימן.

למה: Network Firewall מבצע בדיקת TLS באמצעות גישת man-in-the-middle, ומשתמש ב-CA שאתה מספק כדי לחתום מחדש על אישורים תוך כדי תנועה. לקוחות חייבים לסמוך על CA זה כדי למנוע שגיאות אישור.

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

→צור קבוצות כללים של DNS Firewall בחשבון מרכזי באמצעות רשימות דומיינים מנוהלות של AWS. שתף את קבוצות הכללים באמצעות RAM וקשר אותן ל-VPCs בחשבונות חברים.

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

הצפן את כל תעבורת הרשת בין מופעי EC2 באותו VPC ללא שינויים ביישום.

→השתמש בסוגי מופעים מבוססי AWS Nitro System.

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