Infrastructure Drift כמעט אף פעם לא מתחיל בהחלטה גדולה. הוא מתחיל בשינוי קטן: Security Group שנפתח לזמן קצר ונשאר פתוח, סביבת Dev שלא נסגרה, IAM Role שקיבל הרשאה רחבה מדי, או שינוי ידני ב-Portal שלא נכנס לשום תיעוד.
כל אחד מהשינויים האלה יכול להיות הגיוני ברגע שבו הוא נעשה. הבעיה מתחילה אחרי כמה חודשים, כשמה שקיים בפועל כבר לא דומה למה שתוכנן, למה שמתועד או למה שה-Policy הארגוני מאפשר.
מנקודת מבט של Security Architecture, זה סיכון מאוד פרקטי. לא תמיד יש אירוע ברור. אין בהכרח Alert שמכריז שהתשתית יצאה משליטה. פשוט נוצרים פערים בין Cloud, On Prem, Kubernetes, Networking, IAM, Storage ו-Production.
HashiCorp Terraform an IBM Company, מטפל בדיוק בשכבה הזו באמצעות Infrastructure as Code (IaC). במקום להקים ולשנות תשתית ידנית, רכיבי התשתית מוגדרים בקבצי קונפיגורציה שאפשר לקרוא, לבדוק, להריץ, לשחזר ולנהל ב-Version Control.
הערך של Terraform אינו רק אוטומציה כי אוטומציה יכולה גם להריץ טעות מהר יותר. הערך מתחיל כששינוי תשתיתי נכנס לתהליך מסודר של Pull Request, Review, Testing, Policy Checks ו-Audit Trail.
ברגע שהתשתית כתובה כקוד, אפשר לבדוק אותה לפני שהיא מגיעה ל-Runtime .Production פתוח לאינטרנט, Bucket ללא הצפנה, Resource בלי Tags, הרשאת Admin רחבה מדי או שינוי ב-Production ללא אישור יכולים להיתפס מוקדם יותר בתהליך.
זה לא מבטל Runtime Monitoring, אבל הוא מוריד את כמות הבעיות שמגיעות לשם מלכתחילה. עבור צוותי אבטחה, זו נקודת פתיחה טובה בהרבה מאשר לחפש חריגות אחרי שהסביבה כבר פעילה.
בארגונים גדולים הבעיה חוזרת על עצמה: צוות אחד עובד עם Modules מסודרים, צוות אחר דרך Portal, צוות שלישי עם Scripts מקומיים. בענן אחד יש סטנדרט מסוים, בענן אחר סטנדרט אחר. Production מוקשחת, Dev פתוחה מדי. ואז מגיע Audit או אירוע אבטחה, וקשה להבין מה באמת קיים.
Terraform יוצר שפה משותפת לניהול תשתית. לא רק כלי טכני, אלא Operating Model: איך מבקשים Resource, איך מאשרים שינוי, איך מגדירים סטנדרטים, ואיך מאפשרים Self Service בלי לוותר על Guardrails.
Modules הם אחד המקומות שבהם זה מורגש. מודול טוב לא רק חוסך זמן. הוא אורז החלטות ארכיטקטורה ואבטחתיות לתבנית שימושית. VPC, Cluster, Database, Load Balancer או Storage לא צריכים להיבנות מחדש בכל צוות. הם יכולים להגיע עם Defaults נכונים, הצפנה, Logging, Tags, Network Controls ו-IAM Boundaries.
אבל Terraform דורש משמעת. מודול גרוע יריץ בעיה בצורה עקבית. לכן צריך Review אמיתי, הפרדת סביבות, ניהול State, בקרת שינויים ומדיניות ברורה סביב מי רשאי להריץ מה ובאיזו סביבה.
State הוא דוגמה טובה למקום שבו IaC הופך לנושא אבטחתי. Terraform State משקף את מצב התשתית ולעיתים כולל מידע רגיש. צריך לנהל אותו עם הרשאות מדויקות, הצפנה, נעילה, הפרדה בין סביבות ו-Audit.
גם Credentials חשובים. Terraform צריך לבצע פעולות מול ספקי ענן ופלטפורמות תשתית, ולכן אסור להתייחס לזה כפרט טכני שולי. מפתחות סטטיים ב-Pipelines או משתני סביבה הם סיכון. במידת האפשר, עדיף לעבוד עם Workload Identity, OIDC או Dynamic Provider Credentials ולהגביל הרשאות לפי הפעולה הנדרשת.
כאן יש חיבור טבעי ל-Vault, אבל התפקידים שונים. Terraform מנהל את מחזור החיים של התשתית. Vault מנהל Secrets וגישה רגישה. השילוב נכון כאשר Terraform Runs צריכים Credentials זמניים, אבל הוא צריך להיות חלק מארכיטקטורה מסודרת ולא פתרון נקודתי.
החלק המשמעותי ביותר מבחינת אבטחה הוא Policy as Code. לא מספיק להקים תשתית מהר. צריך לוודא שהיא עומדת בסטנדרטים: אין חשיפה ישירה לאינטרנט בלי הצדקה, Storage מוצפן, Tags קיימים, הרשאות Admin לא ניתנות כברירת מחדל, ושינוי ב-Production עובר Approval.
לא כל הארגון צריך להפוך ל-100% IaC ביום אחד. כדאי להתחיל במקום שבו יש הרבה שינוי, סיכון או חזרתיות: Cloud Networking, IAM, Kubernetes, סביבות פיתוח או Resources שחוזרים על עצמם בין פרויקטים.
Terraform חשוב גם ב-Day 2 Operations. הקמה ראשונית היא החלק הקל יחסית. אחרי כמה חודשים מגיעים תיקונים, חריגים, הרחבות ושינויים דחופים. בלי דרך עקבית לנהל אותם, הסביבה מתרחקת מהארכיטקטורה המקורית.
כאשר IaC מנוהל נכון, יש מקור אמת טוב יותר. יש היסטוריה של שינויים. יש קוד שאפשר לבדוק. יש דרך להבין מה השתנה ולמה. זה לא קסם, אבל זה בסיס הרבה יותר טוב לניהול תשתית מודרנית.
זה מה ש-Terraform מאפשרת, שכבת עבודה שמחברת בין מהירות, Policy ו-Governance. תשתית בקצב שהעסק דורש, בלי להפוך כל שינוי לעוד חריגה בלתי מתועדת.