סריקת IaC: הזדמנות למידה פנטסטית שמתעלמת ממנה

כל מה שאתה קורא על תשתית כקוד (IaC) מתמקד באופן שבו זה עובד או למה אתה רוצה לוודא שהוא באמת בנוי כמו שאתה רוצה שהוא יבנה.

אלו תחומים קריטיים. אך האם אנו חושבים מספיק על האופן שבו אנו משתמשים בגישה זו בארגון שלנו?

As מלינדה מרקס מ-ESG קובע בדו"ח החברה, "83% מהארגונים חוו עלייה בתצורות שגויות של תבניות IaC" כשהם ממשיכים לאמץ את הטכנולוגיה.

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

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

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

זו הסיבה שאנו רואים הפשטות ברמה גבוהה אפילו יותר מכלים כמו Terraform או AWS CloudFormation ב- AWS CDK ופרויקטים כמו cdk8s. ההפשטות ברמה גבוהה נוחות יותר למפתחים.

פרספקטיבה של הפעלה/SRE/פלטפורמה של שירות ענן תהיה שונה בתכלית מנקודת מבט של מפתחים של אותו שירות. מפתח יסתכל על שירות תור ויצלול לתוך הממשק שלו - נקודת קצה פשוטה להוספה ואחת לקריאה? נמכר. זו שילוב קל.

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

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

כתוצאה מכך, זה המקום שבו חששות האבטחה מסלימים לעתים קרובות.

רוב הכלים - מסחרי או קוד פתוח - מתמקדים בזיהוי דברים שגויים בתבניות התשתית. זֶה
הוא מבנה טוב. הֲכָנָה זֶה
יהיה רע. כלים אלו שואפים לייצר תוצאות אלו כחלק מצינור האינטגרציה/הספקה המתמשכת (CI/CD).

זו התחלה מצוינת. אבל זה מהדהד את אותה סוגיית שפה.

מי מדבר ומי מקשיב?

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

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

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

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

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

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

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

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

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

על המחבר

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