אבטחת תשתית כקוד (IaC)

בקצרה: אבטחת תשתית כקוד (IaC)

אבטחת תשתית כקוד (IaC) היא תהליך של אבטחת תשתית הענן שלך על ידי סריקת קבצי התצורה או הסקריפטים שנכתבו בשפות ספציפיות כמו Terraform, CloudFormation, Kubernetes YAML וכו’, לפני הפריסה.

תהליך זה יעזור לך.

• לתפוס תצורות שגויות מוקדם, כגון פתיחת פורטים מיותרים בטעות או הענקת גישה מוגזמת למשתמשים.
• לאכוף מדיניות אבטחה כקוד בצינורות CI/CD.
• להפחית את הסיכון לפריצות ענן, חשיפת נתונים, ובעיות תאימות הנגרמות על ידי תצורות לא בטוחות בסקריפטים.

המטרה של אבטחת IaC היא לוודא שהדרך שבה אתה בונה את תשתית הענן שלך היא בטוחה.

מהי אבטחת תשתית כקוד (IaC)

אבטחת תשתית כקוד (IaC) היא תהליך של אבטחת תשתית ענן המוגדרת ומנוהלת באמצעות קוד מסוים, כמו Terraform, AWS CloudFormation, Pulumi, או קבצי Kubernetes YAML.

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

במילים פשוטות :

אבטחת IaC בודקת “איך הענן שלך מוגדר ונבנה” כדי שלא תשלח תשתית לא בטוחה לייצור

למה אבטחת IaC חשובה

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

אז מדוע אבטחת IaC חשובה:

הגדרות שגויות הן סיבה עיקרית לפריצות בענן.

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

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

אם מודול Terraform מגדיר 0.0.0.0/0 (פתוח לכולם) לגישה, כל סביבה שמשתמשת בו הופכת לחשופה.

IaC הוא חלק משרשרת האספקה של התוכנה.

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

ציות תלוי בהגדרה נכונה.

מסגרות כמו SOC 2, ISO 27001 ו-PCI DSS מסתמכות על הגדרות מאובטחות, בקרת גישה ורישום. IaC לא מאובטח יכול לשבור את הציות.

כיצד אבטחת IaC עובדת

אבטחת IaC תופסת פגיעויות בתשתית לפני שהיא נפרסת.

1. סרוק קבצי IaC לאיתור הגדרות שגויות

כלים מנתחים את ה-Terraform, CloudFormation או מניפסט Kubernetes שלך כדי למצוא הגדרות מסוכנות כגון:

• דליים S3 ציבוריים
• מסד נתונים חשוף לציבור.
• קבוצות אבטחה עם 0.0.0.0/0 (פתוח לציבור)
• קונטיינרים שרצים כ-root
• אחסון או לוגים לא מוצפנים

מטרה: לתפוס בעיות אבטחה לפני שהן מגיעות לענן

2. אכוף מדיניות אבטחה כקוד

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

• אין לאפשר מסד נתונים ציבורי של Amazon RDS (Relational Database Service)
• כל דליי S3 חייבים להשתמש בהצפנה.
• קונטיינרים של Kubernetes לא יכולים לרוץ עם הרשאות יתר.

מדיניות זו נאכפת אוטומטית בצינורות CI/CD.

מטרה: להפוך את כללי האבטחה לחלק מתהליך הפיתוח שלך, ולא למחשבה מאוחרת.

3. אינטגרציה עם צינורות CI/CD

כלי אבטחת IaC משתלבים ב-CI/CD כדי לחסום או להזהיר אוטומטית על שינויים מסוכנים.

תהליך טיפוסי:

1. המפתח מבצע את קוד התשתית.
2. צינור CI/CD מריץ סריקות אבטחת IaC.
3. אם נמצאה בעיה קריטית (למשל, מסד נתונים ציבורי), הבנייה נכשלת.
4. המפתח מתקן את הבעיה לפני הפריסה.

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

4. מיפוי לתנוחת אבטחת ענן

אבטחת IaC משולבת לעיתים קרובות עם CSPM (ניהול תנוחת אבטחת ענן)

• CSPM בודק מה באמת רץ בענן, כמו בדיקה שהמסד נתונים לא חשוף לאינטרנט. האם דלי האחסון מוצפן? וכך הלאה.
• אבטחת IaC בודקת מה עומד להיות מופעל.

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

סיכוני אבטחת IaC נפוצים

דוגמאות לבעיות שאבטחת IaC יכולה לזהות:

• אחסון חשוף לציבור (למשל, דליי S3 עם קריאה/כתיבה ציבורית)
• מסדי נתונים, נפחים או לוגים לא מוצפנים
• תפקידי IAM עם הרשאות יתר
• קבוצות אבטחה פתוחות (0.0.0.0/0 עבור SSH/RDP).
• קונטיינרים של Kubernetes שרצים עם גישה מורשית.
• סודות מקודדים בקבצי Terraform או YAML.

דוגמה בפועל

צוות משתמש ב-Terraform לניהול תשתית AWS.

סריקת אבטחת IaC מסמנת :

• מסד נתונים RDS עם גישה ציבורית מופעלת
• דלי S3 ללא הצפנה ועם גישה לקריאה ציבורית

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

אז המפתח צריך :

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

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

מי משתמש באבטחת IaC

• DevOps - כותבים ומתחזקים תבניות IaC
• מהנדסי אבטחת ענן - מגדירים מדיניות ובודקים תצורות.
• צוותי AppSec / DevSecOps - משלבים IaC בצינורות
• צוותי אבטחה וציות - משתמשים בדוחות לביקורות וממשל.

מתי ליישם אבטחת IaC

אבטחת IaC צריכה להיות מיושמת לאורך מחזור החיים:

• במהלך הפיתוח - ווים לפני התחייבות ותוספים ל-IDE.
• במהלך בניות CI/CD - סריקות אוטומטיות יכולות לחסום שינויים מסוכנים.
• לפני הפריסה - בדיקות מדיניות לסביבות ייצור.
• באופן רציף - סריקה מחדש של תבניות כאשר מופיעים כללים או איומים חדשים.

יכולות מפתח של כלי אבטחת IaC

רוב פתרונות אבטחת IaC מספקים:

• מדיניות כקוד: הגדרת ושליטה בגרסאות של כללי אבטחה
• ניתוח סטטי של IaC: סריקת Terraform, CloudFormation, Kubernetes config, וכו’
• אינטגרציה CI/CD: Github Actions, GitLab CI, Jenkins, וכו’
• זיהוי תצורה שגויה: זיהוי תצורות לא בטוחות
• זיהוי סטייה (עם CSPM): זיהוי הבדלים בין הגדרת IaC לבין ענן חי.
• דיווח ומיפוי תאימות: מיפוי בעיות לבקרות ותקנות.

דוגמאות לכלים: Checkov, Tfsec, Terrascan, או פלטפורמות מתקדמות כמו Plexicus ASPM כאשר הם סורקים IaC כחלק מיציבת אפליקציה/ענן.

שיטות עבודה מומלצות לאבטחת IaC

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

מונחים קשורים

• CSPM (ניהול יציבת אבטחת ענן)
• DevSecOps
• Zero Trust
• זיהוי סודות