תאריכי המאמר: פורסם במקור באנגלית ב־23 במאי 2026. התרגום והבדיקה הטכנית בעברית נערכו ב־25 באוקטובר 2026. תאריך התרגום אינו תאריך הפרסום המקורי.
זהו המאמר המסכם בסדרה בת ארבעה חלקים על שירותים מרכזיים בענן Amazon Web Services (AWS). חלקים 1, 2 ו־3 עסקו בסביבת ההרצה, בנתונים ובחיבורים בין רכיבי המערכת. בחלק הזה נכיר ארבעה שירותים שמסייעים להפעיל מערכת מאובטחת, לנטר אותה ולשחזר את התשתית שלה: IAM לניהול זהויות והרשאות, CloudWatch לאיסוף נתוני ניטור ולהתרעות, CloudFormation וערכת הפיתוח CDK להגדרת תשתית כקוד, ו־Secrets Manager לניהול פרטי גישה סודיים. שימוש נכון בארבעתם עוזר להפוך חשבון AWS שרק עובד לסביבה שאפשר לתחזק לאורך זמן.
1. AWS IAM — ניהול זהויות וגישה
AWS IAM הוא שירות ניהול הזהויות והגישה (Identity and Access Management). במרבית בקשות הממשק לתכנות יישומים (API), AWS מזהה את הגורם המבקש ובודקת את המדיניות הרלוונטית לפני שהיא מתירה או דוחה את הפעולה. יש גם בקשות אנונימיות נתמכות ושיקולים ייחודיים לכל שירות. כדי לעבוד נכון עם IAM, חשוב להבין את כללי הערכת המדיניות ואת ההבדלים בין סוגי המדיניות. התרשים הוא מפת מושגים מפושטת, לא שרשרת שבה כל בקשה חייבת לקבל אישור נפרד מכל שורה.
סוגי הזהויות כוללים משתמשים בעלי זהות קבועה, שהשימוש בהם פחות רצוי כאשר אפשר להשתמש באישורים זמניים; תפקידים (roles) ששירותים או בני אדם מזוהים מקבלים זמנית, למשל באמצעות כניסה אחודה (SSO); ואת משתמש השורש (root) של החשבון. הגנו עליו באמצעות אימות רב־גורמי (MFA), ואל תשתמשו בו לעבודה שוטפת; יש פעולות חריגות שדורשות אותו. עבור בני אדם, נהוג לרכז את הזהויות ב־IAM Identity Center, המחליף של AWS SSO, ולהקצות דרכו גישה לחשבונות. יישומים, כגון פונקציות Lambda, משימות ECS ומופעי EC2, משתמשים בתפקידים ובמדיניות אמון המתאימה לשירות.
סוגי המדיניות המרכזיים הם מדיניות מבוססת זהות שמצורפת למשתמש, לקבוצה או לתפקיד; מדיניות מבוססת משאב שמצורפת, למשל, לדלי S3, למפתח KMS, לנושא SNS או לפונקציית Lambda; וברמת הארגון מדיניות בקרת שירותים (SCP) שמגבילה הרשאות בחשבונות חברים לפי היררכיית הארגון והיחידות הארגוניות (OU). היא אינה מעניקה הרשאות, ויש חריגים כגון חשבון הניהול ותפקידים מקושרי שירות. יש גם גבולות הרשאות (permissions boundaries) שמגבילים את ההרשאות שמדיניות זהות יכולה להעניק, למשל כשמאפשרים לצוות ליצור תפקידים; וכן מדיניות הפעלה (session policies) שמועברת בעת AssumeRole ומגבילה עוד את ההפעלה. שילוב המדיניות תלוי בזהות ובמשאב: בתוך אותו חשבון מדיניות זהות ומשאב יכולה להעניק הרשאות במשותף, ואילו מגבלות מתאימות מצמצמות אותן. איסור מפורש גובר על היתר. בארגון עשויה לחול גם מדיניות בקרת משאבים (RCP), ויש להביא אותה בחשבון לפי תחולתה.
לעבודה בטוחה עם IAM, צמצמו מדיניות לפעולות ולמשאבים מסוימים במקום להשתמש ב־* כאשר אפשר. השתמשו ב־IAM Access Analyzer לבדיקת הרשאות שאינן בשימוש וגישה חיצונית; העדיפו תפקידים ושירות אסימוני האבטחה STS על פני מפתחות גישה ארוכי חיים; השתמשו ב־IAM Identity Center עבור בני אדם; והפרידו חשבונות והרשאות בין פיתוח לייצור. בדקו את התמחור של יכולות הניתוח שבחרתם.
2. Amazon CloudWatch — מדדים, יומנים, התרעות ומעקב אחר בקשות
Amazon CloudWatch הוא שירות לניטור ולהבנת מצב המערכת. בין היכולות העיקריות שלו: מדדים (Metrics) — סדרות נתונים לאורך זמן, שמספקים שירותי AWS או היישום שלכם; יומנים (Logs) — איסוף וחיפוש מנוהלים של אירועים; התרעות (Alarms) — כללים המבוססים על מדדים או על מצבי התרעות, ויכולים להפעיל פעולות; וכן Application Signals בשילוב X-Ray למעקב מבוזר אחר בקשות ולקישורו למדדים. התרעות על יומנים דורשות, למשל, הפקת מדד מהיומן או מנגנון נתמך אחר; הן אינן זהות לכלל ישיר על כל טקסט ביומן.
מדדים נפלטים אוטומטית משירותים רבים: EC2 מפרסם CPUUtilization; Lambda מפרסם Invocations, Errors, Duration ו־Throttles; מאזן עומסים יישומי (ALB) מפרסם RequestCount ו־TargetResponseTime; ו־RDS מפרסם DatabaseConnections ו־FreeableMemory. הקוד שלכם יכול לפרסם מדדים מותאמים באמצעות PutMetricData או לכתוב אותם בפורמט JSON ביומני CloudWatch ולהשתמש בפורמט המדדים המוטמעים (EMF) כדי לחלץ אותם בצד השירות. כך אפשר להימנע מקריאות נפרדות ל־PutMetricData, אך אין פירוש הדבר שהמדדים חינמיים: עשויים לחול חיובים על קליטת יומנים, אחסונם ומדדים מותאמים.
היומנים מאורגנים בקבוצות יומנים ובזרמי יומן. קבוצה עשויה לייצג פונקציית Lambda, שירות ECS או יעד של יומני זרימת רשת VPC Flow Logs. אפשר להריץ שאילתות CloudWatch Logs Insights בתחביר של שלבי עיבוד כדי למצוא בקשות איטיות, לספור שגיאות לפי נתיב או לחקור קפיצות בעומס. משך השמירה מוגדר לכל קבוצה; בחרו משך שמתאים לצורך התפעולי ולחובות השמירה, למשל 30–180 יום כאשר זה מתאים, כדי למנוע הצטברות מיותרת של עלויות. לניתוח ארוך טווח אפשר להזרים יומנים ל־S3 דרך מסנן הרשמה ליומנים ו־Amazon Data Firehose ולנתח אותם באמצעות Athena. גם מסלול זה דורש תכנון הרשאות, פורמט ועלויות.
התרעות בודקות מדד או ביטוי נתמך מול סף לאורך חלון זמן, או משלבות מצבים של התרעות אחרות. הן יכולות לשלוח הודעה לנושא SNS, להפעיל פעולת התאמת קיבולת או להזניק Lambda, בהתאם לסוג ההתרעה. התרעות זיהוי חריגות לומדות טווח צפוי ועוזרות לזהות סטייה ממנו, למשל כשסף קבוע אינו מתאים למחזורי עומס יומיים.
3. AWS CloudFormation ו־CDK — תשתית כקוד
AWS CloudFormation הוא שירות בסיסי להגדרת תשתית כקוד (IaC). כותבים תבנית YAML או JSON שמתארת את המשאבים הרצויים, כגון דלי S3, מופע EC2, מסד RDS, פונקציית Lambda ותפקיד IAM. השירות יוצר, מעדכן או מוחק אותם כיחידה שנקראת מחסנית (stack). מצב המחסנית מנוהל בשירות עצמו, בלי קובץ מצב נפרד שעליכם לנהל כפי שנהוג ב־Terraform.
לכתיבת תשתית בקוד אפשר להשתמש גם בערכת הפיתוח לענן AWS CDK (Cloud Development Kit), שמפיקה תבניות CloudFormation מתוך שפת תכנות כגון TypeScript, Python, Java, .NET או Go. היא מספקת רכיבים עם טיפוסים, שימוש חוזר בספריות, תמיכה בשינוי מבנה קוד בסביבת הפיתוח וביטוי תמציתי של דפוסים נפוצים לעומת YAML גולמי.
כמה יכולות תפעוליות שכדאי להכיר: קבוצות שינויים (change sets) מציגות את השינויים המתוכננים לפני ההחלה. בדקו אותן לפני פריסה לייצור, אך זכרו שאינן מבטיחות שהעדכון יצליח או שכל מכסה והרשאה נבדקו; חזרה לאחור (rollback) יכולה לשחזר מצב לאחר עדכון שנכשל, בהתאם לתמיכת המשאבים ולהגדרות, ואינה תחליף לגיבוי; זיהוי סטייה (drift detection) מזהה שינויים מחוץ לתהליך המנוהל במשאבים ובמאפיינים הנתמכים; StackSets מאפשר לפרוס אותה מחסנית בחשבונות ובאזורים רבים; ומחסניות מקוננות (nested stacks) מאפשרות להרכיב מערכות גדולות מרכיבים לשימוש חוזר.
שני כלים סמוכים משלימים את התמונה. AWS SAM הוא מודל יישומים ללא ניהול שרתים (Serverless Application Model), שכולל הרחבה לתבניות CloudFormation ומאפשר לתאר בקיצור יישומים עם Lambda, API Gateway ו־DynamoDB. CodePipeline + CodeBuild + CodeDeploy הם שירותי AWS לתהליכי שילוב ומסירה רציפים (CI/CD). אפשר להשתמש גם ב־GitHub Actions עם OpenID Connect (OIDC) לקבלת אישורים זמניים ל־AWS. בחרו לפי צורכי הארגון והרשת; שירות מנוהל בענן אינו פועל בהכרח בסביבה מנותקת לחלוטין. Amazon CodeCatalyst אינו פתוח ללקוחות חדשים מאז 7 בנובמבר 2025, ולכן אין להמליץ עליו כברירת מחדל לפרויקט חדש.
4. AWS Secrets Manager — ניהול נכון של פרטי גישה סודיים
AWS Secrets Manager שומר ערכים סודיים כגון סיסמאות מסד נתונים, אסימוני API, סודות לקוח של OAuth ומפתחות חתימה. הנתונים מוצפנים במנוחה באמצעות שירות ניהול המפתחות KMS, והגישה בזמן ריצה מבוקרת באמצעות IAM. שלוש יכולות מרכזיות מבדילות אותו מפתרון ביתי:
ראשית, החלפה אוטומטית של סודות (rotation). אפשר להגדיר החלפה מתוזמנת של פרטי גישה בשירותים נתמכים או לממש פונקציית Lambda מותאמת. התהליך מבוסס Lambda כולל ארבע פעולות: createSecret, setSecret, testSecret ו־finishSecret. אלה פעולות, לא ארבע תוויות. תוויות הגרסה המרכזיות הן AWSPENDING, AWSCURRENT ו־AWSPREVIOUS. תכננו גם כיצד הלקוחות יקבלו את הערך החדש ויתמודדו עם כשל. שנית, שכפול בין אזורים ושיתוף בין חשבונות. אפשר לשכפל סוד לאזורים אחרים לצורך התאוששות מאסון (DR), ולשתף גישה בין חשבונות באמצעות מדיניות משאב והרשאות IAM ו־KMS מתאימות. שיתוף גישה אינו אותו דבר כמו שכפול. שלישית, בקרת גישה מפורטת באמצעות IAM ומדיניות מפתחות KMS, לצד תיעוד קריאות שירות ב־CloudTrail. בדקו את הגדרות התיעוד והקפידו לא לרשום ערכי סודות ביומני היישום.
בקוד לקוח אפשר להשתמש ב־AWS Workload Credentials Provider (לשעבר Secrets Manager Agent) או בהרחבת Lambda כדי לאחסן ערכים זמנית במטמון מקומי ולצמצם קריאות לשירות. הרכיב הוא שירות HTTP מקומי, לא בהכרח חלק מתהליך היישום. המטמון מתרענן לפי משך תוקף (TTL) והבקשות אליו; הוא עלול להחזיר ערך ישן עד שפג תוקפו, וסביבת הרצה חדשה מתחילה עם מטמון חדש. ערכי הסודות שבמטמון אינם מוצפנים; הגנו על הגישה לתהליך ולשירות המקומי בהתאם להנחיות האבטחה של הרכיב. ההרחבה AWS Parameters and Secrets Lambda Extension מספקת מטמון ל־Secrets Manager וגם ל־Systems Manager Parameter Store.
ואם כבר מזכירים את SSM Parameter Store: זהו רכיב של AWS Systems Manager לניהול פרמטרים ותצורה. הרמה הרגילה עשויה להספיק לתצורה, לדגלי תכונות ולמזהי תמונות, עם תמחור ומכסות שתלויים ברמה ובתפוקת הקריאות. הוא אינו מספק את אותו מנגנון החלפת פרטי הגישה של Secrets Manager. דפוס נפוץ הוא לשמור בו תצורה וב־Secrets Manager סודות הדורשים החלפה, לאחר בדיקת הדרישות והעלות.
איך השירותים מתחברים למערכת אחת
לאורך ארבעת חלקי הסדרה הכרנו קבוצה שימושית של שירותים מרכזיים, ולא דירוג מדוד של השירותים הנפוצים ביותר. ארכיטקטורה אפשרית שמשלבת אותם נראית כך: Route 53 מתרגם את שם המתחם ליעד של CloudFront, שמפנה אל מאזן עומסים יישומי (Application Load Balancer) בשתי תתי־רשתות ציבוריות. מאזן העומסים מנתב בקשות למשימות ECS על Fargate בתתי־רשתות פרטיות. הן מתחברות ל־Aurora PostgreSQL בפריסה על פני כמה אזורי זמינות (Multi-AZ) לעיבוד עסקאות מקוון (OLTP), ל־DynamoDB לגישה מהירה לפי מפתח, ל־ElastiCache Redis לניהול הפעלות ולמטמון, ול־S3 להעלאות משתמשים ולקבצים סטטיים. API Gateway HTTP API משמש חזית HTTP לפונקציות Lambda. בנוסף, פונקציות המטפלות בעבודה אסינכרונית יכולות לקבל הודעות מ־SQS ולפרסם אירועים ל־EventBridge; Step Functions מתזמר תהליכים מרובי שלבים, ו־SNS מטפל בהתראות. ברקע, תפקידי IAM מספקים הרשאות לכל עומס עבודה; Secrets Manager שומר פרטי גישה מתחלפים; CloudWatch אוסף מדדים, יומנים והתרעות; וכל התשתית מוגדרת ביישום CDK שמפיק מחסניות CloudFormation. זו דוגמה, לא דרישה להשתמש בכל השירותים בכל מערכת.
על מה אפשר לוותר בהתחלה?
קטלוג השירותים הגדול של AWS עלול להקשות על מתחילים. אין צורך ללמוד את כולו ביום הראשון. אפשר לדחות את לימוד כלי האנליטיקה, כגון Athena, Glue, EMR ו־Redshift, עד שמתעורר צורך בניתוח נתונים מתאים; את שירותי למידת המכונה והבינה המלאכותית, כגון SageMaker ו־Bedrock, עד שהמוצר דורש אותם; את שירותי האינטרנט של הדברים (IoT) עד שאתם בונים פתרון בתחום; ואת רוב שירותי הבלוקצ׳יין והמחשוב הקוונטי עד שיש להם שימוש ממשי. התחילו בשירותים הנדרשים ליישום, חברו אותם עם תשתית כקוד, הרשאות וניטור, והוסיפו שירותים ייעודיים כשעולה צורך ברור.
סיכום הסדרה
ארבעת המאמרים — מחשוב ורשתות, אחסון ומסדי נתונים, שילוב יישומים ואבטחה, ניטור ושילוב פיתוח ותפעול (DevOps) — מספקים בסיס להבנת AWS. השירותים ממשיכים להשתנות, עם אפשרויות נוספות ללא ניהול שרתים, מעבדי Graviton וכלי בינה מלאכותית. העקרונות והקשרים בין הרכיבים נותנים נקודת פתיחה שימושית, אבל בדקו תיעוד, תמיכה ותמחור עדכניים לפני החלטות יישום. שמרו את הסדרה וחזרו אליה תוך כדי בנייה.
- חלק 1: מחשוב ורשתות ←
- חלק 2: אחסון ומסדי נתונים ←
- חלק 3: שילוב יישומים ←
- ◂ חלק 4: אבטחה, ניטור ו־DevOps (המאמר שאתם קוראים)
המאמר המקורי באנגלית: https://www.sysseder.com/2026/05/aws-deep-dive-part-4-security.html
הערת עריכה: הגרסה העברית כוללת תיקוני דיוק לעומת המקור. שירותים, מכסות ועלויות נבדקו מול תיעוד AWS ב־25 באוקטובר 2026, ויש לבדוק שוב לפני פריסה. מקורות עיקריים: הערכת מדיניות IAM · החלפת סודות · מטמון בהרחבת Lambda · הודעת CodeCatalyst.