לקוח משלם ראשון זה רגע מרגש. זה גם הרגע שבו חשבון הענן שלכם הופך ממגרש משחקים למערכת ייצור אמיתית — שאנשים אמיתיים מסתמכים עליה, ושתוקפים יגששו בה.
רוב הפריצות לחשבונות ענן בסטארטאפים אינן מתוחכמות. הן פשוטות בצורה מביכה: מפתח IAM שהודלף לתוך ריפו ציבורי ב-GitHub, דלי S3 ללא הגדרות גישה, חשבון root ללא MFA. החדשות הטובות: 10 הבקרות שלהלן כמעט לא עולות כסף ליישום, ומבטלות את עיקר הסיכון עוד לפני שהלקוח הראשון נוגע במוצר שלכם.
זו אינה מדריך הקשחה מקיף. זהו הבייסליין הביטחוני המינימלי — הדברים שבהיעדרם, במרבית המקרים, תהיה אירוע חומרה תוך 12 חודש מהפעלה.
צ'קליסט 10 בסיסי אבטחת ענן
| # | בקרה | מאמץ | סיכון אם לא מוטמעת |
|---|---|---|---|
| 1 | IAM עם הרשאות מינימליות | בינוני | תנועה רוחבית בכל דלף קרדנשיאל |
| 2 | MFA על חשבון root | נמוך | השתלטות מוחלטת על החשבון |
| 3 | CloudTrail / לוג ביקורת פעיל | נמוך | אין שרשרת ראיות אחרי אירוע |
| 4 | חסימת גישה ציבורית ל-S3 ברמת החשבון | נמוך | חשיפת נתונים בטעות |
| 5 | Subnets פרטיות לבסיסי נתונים | בינוני | חשיפת DB ישירה לאינטרנט |
| 6 | WAF על נקודות קצה ציבוריות | בינוני | מתקפות שכבת אפליקציה (SQLi, OWASP Top 10) |
| 7 | Secrets Manager במקום משתני סביבה | בינוני | סודות בלוגים, בקוד מקור ובקריסות |
| 8 | לוח זמנים לעדכוני אבטחה | נמוך | ניצול CVE ידועות על Runtime לא מעודכן |
| 9 | התראה על פעילות root | נמוך | הסלמת הרשאות לא מזוהה |
| 10 | מחזור בדיקות חדירה | בינוני | פגיעויות לא ידועות שמצטברות בשקט |
1. IAM עם הרשאות מינימליות (Least-Privilege)
לכל שירות, פונקציה ו-pipeline של CI/CD צריכה להיות תפקיד IAM משלה עם ההרשאות שהיא באמת משתמשת בהן. "גישת Admin לכל דבר" היא נוחות לטווח קצר שהופכת לחבות ברגע שכלשהו מהאישורים דולף.
מה לעשות: בצעו ביקורת על מדיניות IAM קיימת. הסירו wildcards מסוג *. צרו תפקידים נפרדים לכל שירות. השתמשו ב-aws iam generate-service-last-accessed-details כדי למצוא הרשאות שלא נוצלו ב-90 יום ולהסיר אותן.
ב-GCP: השתמשו ב-IAM Conditions וב-Workload Identity Federation במקום קבצי מפתח של Service Account. מחקו כל מפתח SA קיים ועברו לטוקנים קצרי-מועד.
2. MFA על חשבון Root / Owner
חשבון ה-root בענן (AWS root / GCP project owner) עוקף את כל מדיניות IAM. הוא המפתח הראשי. סיסמה אחת שנפרצת ללא MFA = השתלטות מלאה על החשבון, כל המשאבים עשויים להימחק או להיתפס לכופר.
מה לעשות: הפעילו MFA חומרה (YubiKey או Google Titan) או לכל הפחות אפליקציית TOTP על חשבון ה-root. לאחר מכן נעלו את פרטי ה-root בצד — הוא צריך לשמש רק למשימות שדורשות זאת באמת (שינוי פרטי חיוב, שחזור חשבון). הגדירו התראה (ראו בקרה #9) על כל כניסה של root.
3. CloudTrail / Cloud Audit Logging פעיל בכל האזורים
ללא לוג ביקורת, לא תוכלו לענות על "מה קרה?" אחרי אירוע. אתם טסים עיוורים.
מה לעשות (AWS): הפעילו CloudTrail בכל האזורים והפנו את הלוגים לדלי S3 עם גרסאות ו-MFA Delete. הפעילו CloudTrail Insights לזיהוי פעילות API חריגה.
מה לעשות (GCP): ודאו שלוגי Admin Activity ו-Data Access פעילים לכל השירותים. ייצאו לוגים ל-Cloud Storage עם מדיניות שמירה של 365 יום.
העלות זניחה — בדרך כלל כמה דולרים בחודש לחשבון בגודל סטארטאפ.
4. חסימת גישה ציבורית ל-S3 ברמת החשבון
דליי S3 של AWS ברירת מחדל הם פרטיים, אך לחיצה שגויה אחת בקונסולה או CDN origin שהוגדר שלא כהלכה יכולים להפוך דלי לציבורי — ויש סורקים אוטומטיים שמוצאים אלה תוך דקות.
מה לעשות: הפעילו "Block all public access" ברמת החשבון ב-S3, לא רק לכל דלי בנפרד. זה מונע מכל דלי בחשבון להפוך ציבורי בטעות, בלי קשר למדיניות הדלי הספציפית. ב-GCP: הגדירו Uniform bucket-level access והשתמשו רק ב-IAM — ללא ACLs.
5. Subnets פרטיות לבסיסי נתונים
בסיס הנתונים של האפליקציה לעולם לא אמור להיות נגיש ישירות מהאינטרנט. מסד נתונים על Subnet ציבורית עם סיסמה חלשה נפרץ תוך שעות במתקפות Credential-stuffing אוטומטיות.
מה לעשות: הציבו את כל בסיסי הנתונים המנוהלים (RDS, Cloud SQL) ב-Subnets פרטיות ללא נתיב Internet Gateway. גישה משרתי האפליקציה תהיה דרך רשת פנימית בלבד. גישת Bastion לצורכי תחזוקה תיעשה דרך AWS Systems Manager Session Manager (ללא פורט SSH פתוח) או Cloud IAP ב-GCP.
6. WAF על נקודות קצה ציבוריות
WAF לאפליקציות חוסם דפוסי מתקפה נפוצים — הזרקת SQL, XSS, Path traversal — לפני שהם מגיעים לקוד שלכם. זה לא תחליף לקוד מאובטח, אך מספק שכבת הגנה לפגיעויות שעוד לא גיליתם.
מה לעשות: חברו AWS WAF ל-Application Load Balancer או ל-CloudFront Distribution שלכם. הפעילו את AWS Managed Rules (Core rule set + Known bad inputs). ב-GCP: Cloud Armor מספק כיסוי שקול ל-Cloud Run ו-GKE Ingress.
עלות: כ-$5–$30 בחודש לרמות תנועה של סטארטאפ — ביטוח זול.
7. Secrets Manager במקום משתני סביבה
סודות שמקוּדָּים בקוד או מאוחסנים בקבצי .env מדליפים: הם מגיעים ל-Commits ב-Git, לשכבות של Docker Image, לקבצי קריסה ולקבצי לוגים. סודות שמתחלפים אוטומטית לא יכולים להיות מקוּדָּדים קשיח.
מה לעשות: אחסנו סיסמאות DB, מפתחות API ותעודות TLS ב-AWS Secrets Manager או ב-GCP Secret Manager. טענו אותם בזמן ריצה דרך ה-SDK, לא בזמן Deploy דרך משתני סביבה. אכפו Git pre-commit hook (למשל detect-secrets) שחוסם סודות מ-Commit. סובבו את כל הסודות שקדמו לבקרה זו.
8. לוח זמנים לעדכוני Runtime מנוהלים
שירותים מנוהלים לא מתעדכנים לבדם כברירת מחדל. משימת ECS שרצה על Node 18 מ-Docker Image בן 18 חודשים מכילה עשרות CVE ידועות שמנוצלות באופן פעיל.
מה לעשות: נעלו גרסאות תלויות ב-Lock Files. הגדירו תזכורת לוּחַ לכל חודש להרצת npm audit / pip audit / go mod tidy + בנייה מחדש של Image בסיס. הפעילו שדרוגי minor-version אוטומטיים על בסיסי נתונים ו-Cache מנוהלים (RDS auto minor version upgrade, חלונות תחזוקה ב-ElastiCache). הירשמו לביטאוני אבטחה של AWS או GCP.
9. התראה על פעילות חשבון Root
נעלתם את ה-root בשלב 2. עכשיו ודאו שתדעו מיד אם הוא משמש בכל זאת.
מה לעשות (AWS): צרו Metric Filter ב-CloudWatch על אירועי CloudTrail עם userIdentity.type = Root, מחובר לאזעקת SNS שמדוא"ל (ורצוי PagerDuty/Slack) את צוות ההנדסה. בקרת "root account usage" ב-AWS Security Hub מאטמת את זה. ב-GCP: הגדירו Log-based alert על principalEmail המכיל את כתובת הדוא"ל של חשבון ה-Owner.
כניסה של Root שאתם לא יזמתם היא אות לאירוע חמור — אתם רוצים לדעת בשניות, לא בסקירת הלוגים של השבוע הבא.
10. מחזור בדיקות חדירה (Pen-Test)
תשע הבקרות הקודמות מבטלות טעויות ברורות. בדיקת חדירה מגלה את הלא-ברורות: פגמים לוגיים במודל ההרשאות שלכם, פגיעויות משורשרות שאף סורק בודד לא תופס, הנחות שעשיתם לגבי אופן השימוש במערכת שלא עומדות בפני מתקיף.
מה לעשות: תזמנו Pen-Test חיצוני לפני העסקת הארגוני הראשונה שלכם או ביקורת SOC 2 — ואחר כך מדי שנה. אם התקציב מוגבל, התחילו בסריקת DAST אוטומטית (Burp Suite Pro, AWS Inspector ל-EC2) ובסקירה ידנית של המשטח הסיכוני ביותר שלכם (זרמי אימות, פאנלים אדמיניסטרטיביים, אינטגרציות תשלום). התייחסו לממצאים כמפת דרכים, לא כציון בחינה.
התחילו עם הנמוך-מאמץ עוד היום
פריטים 2, 3, 4 ו-9 ניתן להשלים תוך פחות משעה. אם החשבון שלכם לא כולל אותם כרגע — זה העבודה להיום אחר הצהריים.
הפריטים בינוני-מאמץ (ארגון מחדש של IAM, עיצוב מחדש של VPC, הגדרת WAF) שייכים לספרינט הבא. אל תתנו ל"נעשה את זה כמו שצריך מאוחר יותר" להתמשך מעבר לכניסת הלקוח הראשון לחיים.
אם אתם לא בטוחים היכן החשבון שלכם עומד על הצ'קליסט הזה, DMSE מבצע סקירות אבטחת ענן כחלק משירותי הענן שלנו. נגיד לכם בדיוק מה חסר ואיך לתקן — בלי למכור לכם התקשרות של חצי שנה לביצוע זה. צרו קשר.
כבר על AWS ושוקלים להישאר או לעבור ל-GCP? סיקרנו את ההחלטה הזו לעומק במאמר AWS מול GCP לסטארטאפים.