אבטחת ענן AWS ו Azure: טעויות נפוצות ואיך להימנע מהן

אבטחת ענן AWS ו Azure: טעויות נפוצות ואיך להימנע מהן

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

החדשות הטובות: רוב הבעיות חוזרות על עצמן.

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

לפני הכול: מי אחראי על מה, ולמה זה חשוב?

בענן יש כלל אחד שחוזר בכל תחקיר: ״חשבנו שזה באחריות הספק״.

אז בוא נסגור את זה עכשיו.

AWS ו-Azure עובדים במודל אחריות משותפת.

הם אחראים על התשתית הפיזית ושכבות מסוימות של השירותים.

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

כלומר, הענן יכול להיות מאובטח מאוד.

אבל רק אם אתה לא משאיר לו את ההגה בלי ידיים.

טעות 1: ״פשוט תן Admin וזהו״ – ואז שואלים למה הכול בוער

הרבה מערכות ענן מתחילות מהלחץ של ״רק שיעבוד״.

מישהו צריך לפתוח שירות.

מישהו צריך דיבאגר.

ואז הכי קל: הרשאת Admin, או Role רחב, או מדיניות עם כוכבית אחת יותר מדי.

הבעיה: הרשאות בענן מתנהגות כמו מים.

הן זולגות לכל מקום.

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

מה עושים במקום?

מיישמים Least Privilege, אבל לא בקטע דתי.

בקטע פרקטי.

• מתחילים קטן – הרשאות מינימליות, ואז מרחיבים לפי צורך אמיתי.
• מפרידים תפקידים – Dev, Ops, Security, Finance. שלא כולם יהיו ״הכול מהכול״.
• משתמשים ב-Role זמני – עדיף גישה זמנית מאשר מפתח שיישאר לנצח.
• בודקים בפועל – מי באמת משתמש בהרשאות האלה, ומתי.

ב-AWS זה מתחבר יפה ל-IAM Access Analyzer, IAM Access Advisor, ולגישה דרך STS.

ב-Azure זה יושב על Entra ID, PIM, ו-RBAC מסודר עם עקרון ״Just in time״.

טעות 2: MFA? ״אחר כך״. ואז ה״אחר כך״ מגיע

אם יש משהו שמדהים אותי כל פעם מחדש, זה כמה ארגונים עדיין חושבים ש-MFA זה ״שדרוג״ ולא ״חגורת בטיחות״.

ובדיוק כמו חגורת בטיחות, אתה לא שם אותה אחרי התאונה.

מה עושים במקום?

• מחייבים MFA לכל משתמש עם גישה לקונסולה, ובטח לחשבונות פריבילגיים.
• חוסמים כניסה בסיסמא בלבד היכן שאפשר, ועוברים ל-SSO.
• מקשיחים Reset – תהליך איפוס סיסמה הוא לעיתים נקודת התורפה הכי ״אנושית״.

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

טעות 3: סודות בקוד – כי למה לא לשים מפתח בפרונט?

מפתחות API, חיבורי DB, טוקנים, מפתחות חתימה.

כל ה״דברים שאסור שיראו״.

ואיכשהו הם מוצאים את עצמם ב-repo, ב-Container image, ב-ENV של CI, או בקובץ בשם secret-final-really.json.

כן, גם זה קרה.

מה עושים במקום?

• מנהל סודות אמיתי – AWS Secrets Manager או Azure Key Vault.
• הרשאות גישה לסוד בנפרד מהרשאות לשירות עצמו. אחרת זה ״מפתח מתחת לשטיח״.
• סריקה אוטומטית ל-Secrets ב-CI וב-Git, עם חסימה של Merge כשצריך.
• רוטציה – לא דרמה, פשוט תהליך.

בונוס חשוב: אל תסתפק ב״הסתרה״.

סוד חייב להיות מנוהל, מוגן, ומנוטר.

טעות 4: Storage ציבורי – הפיצ׳ר שכולם מפעילים בלי לשים לב

בין אם זה S3 ב-AWS או Blob Storage ב-Azure, הסיפור דומה:

רוצים לשתף קובץ.

עושים ״Public״.

ואז זה נשאר public גם אחרי שכולם שכחו מזה.

מה עושים במקום?

• חוסמים Public כברירת מחדל – Account level controls הם חברים טובים.
• משתמשים ב-URL חתום או SAS מוגבל בזמן במקום פתיחה קבועה.
• בודקים הרשאות בפועל – לא רק מה כתוב במדיניות, אלא מה באמת נגיש מבחוץ.
• מתייגים נתונים – ציבורי, פנימי, רגיש. ואז משליכים על מדיניות גישה.

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

וזה מביא אותנו לטעויות רשת.

טעות 5: ״זה רק VPC/VNet״ – ואז מגלים שהרשת מדברת יותר מדי

ענן אוהב חיבורים.

Peering, VPN, ExpressRoute, Transit Gateway, PrivateLink.

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

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

מה עושים במקום?

• סגמנטציה אמיתית – הפרדה בין שכבות: Web, App, Data, Management.
• Inbound מינימלי – אם לא חייבים פתוח, זה סגור.
• Egress בשליטה – כן, גם יציאה החוצה היא סיכון.
• Private endpoints לשירותים קריטיים במקום לצאת לאינטרנט ולהתפלל.

ומילה על Security Groups ו-NSG:

הם לא אמורים להיות ״רשימת קניות״ של פורטים.

הם אמורים להיות תיעוד של כוונה.

טעות 6: לוגים? ״נפעיל כשנצטרך״ – אבל אז אין מה לחפש

כשמשהו לא ברור, אתה רוצה היסטוריה.

ללא לוגים, אתה מנחש.

ולנחש בענן זה יקר, מעייף, ולרוב גם לא מדויק.

מה עושים במקום?

• אוספים לוגים מרכזית – CloudTrail ו-CloudWatch ב-AWS, ו-Azure Monitor ו-Activity Logs ב-Azure.
• מגנים על הלוגים – Write once, גישה מוגבלת, שמירה לזמן מספיק.
• מגדירים התרעות חכמות – לא 500 התראות ביום, אלא כמה קריטיות שאפשר לסמוך עליהן.
• מנטרים זהויות – כניסות חריגות, שינויי הרשאות, יצירת מפתחות.

מטרה אמיתית: לא רק לדעת שהיה אירוע.

אלא להבין מה קרה תוך דקות, לא תוך שבוע.

טעות 7: הצפנה – ״בטח יש כבר״ (לפעמים כן, לפעמים בערך)

הצפנה בענן יכולה להיות מצוינת.

אבל יש הבדל בין:

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

מה עושים במקום?

• מחליטים על מדיניות מפתחות – מי יוצר, מי מאשר, מי מסובב, מי מבטל.
• מגדירים CMK כשצריך – AWS KMS או Azure Key Vault Keys.
• מצפינים תעבורה – TLS בכל מקום אפשרי, כולל פנימה בין שירותים.
• בודקים חריגים – שירות אחד לא מוצפן יכול להפיל סיפור שלם.

ואם יש ספק: תמדוד.

אל תסמוך על ״נראה לי״.

טעויות CI/CD: כשדיפלוי מהיר נהיה דיפלוי מסוכן

פייפליין הוא כוח על.

אבל כוח על בלי בלמים זה קצת כמו לתת לילד קטן מפתח למטוס.

מה עושים כדי שפייפליין יהיה חבר ולא הפתעה?

• Build נפרד מ-Deploy – הרשאות שונות, חשבונות שונים אם אפשר.
• חתימה על ארטיפקטים – לדעת מה רץ בפועל.
• סורקים קונטיינרים – פגיעויות, חבילות ישנות, הרשאות מיותרות.
• Infrastructure as Code עם ביקורת – לא ״שיניתי בקונסולה כי היה דחוף״.

בענן, שינויים הם קליק.

וזה בדיוק למה צריך שהם יהיו גם תהליך.

---

שאלות ותשובות קצרות, כי מגיע לך בהירות

ש: מה ההבדל הכי חשוב בין אבטחה ב-AWS לאבטחה ב-Azure?
ת: העקרונות כמעט זהים, אבל הממשקים והמבנים שונים. ב-AWS תראה הרבה סביב IAM וחשבונות, וב-Azure סביב Entra ID, Subscriptions ו-Management Groups. אם תבין זהויות, הרשאות ורשת – תסתדר מצוין בשניהם.

ש: איפה הכי קל לפספס סיכון גדול?
ת: בהרשאות רחבות ובמשאבי Storage. אלה שני מקומות שבהם ״רק שיפעל״ הופך מהר מאוד ל״למה זה נגיש מבחוץ״.

ש: מה עדיף – Key Vault או Secrets Manager?
ת: שניהם מצוינים. תבחר לפי פלטפורמה, אינטגרציות קיימות, והרגלי עבודה. העיקר: סודות מנוהלים, הרשאות מדויקות, ורוטציה.

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

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

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

---

שני קישורים ששווה להכיר (ולא, זה לא ״עוד רעש״)

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

ואם מתאים לך משהו יותר יומיומי, מאחורי הקלעים, עם וייב קליל יותר: איילון אוריאל.

הצ׳ק ליסט הקצר שמנצח את רוב הטעויות

רוצה לקחת את כל המאמר הזה ולהפוך אותו לפעולות?

הנה סט קצר, אפקטיבי, וממש לא דרמטי:

• זהויות והרשאות – Least Privilege, Role זמני, MFA חובה.
• סודות – רק במנהל סודות, עם רוטציה וניטור גישה.
• אחסון – חסימת Public כברירת מחדל, שיתוף זמני בלבד.
• רשת – סגמנטציה, egress בשליטה, private endpoints כשאפשר.
• לוגים וניטור – איסוף מרכזי, הגנה על לוגים, התרעות קריטיות.
• CI/CD – הפרדת הרשאות, סריקות, ו-IaC עם ביקורת.

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

כשעובדים נכון, זה בעיקר סדר.

קצת משמעת.

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

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