מכרזים

המלצות להקמת סביבות ענן נכון ופעם הראשונה – חלק שני

נכתב על ידי

27
07.2020

בפרק הראשון בסדרה, סקרנו את הנושאים חלוקת משאבים, תיוג משאבים (Tagging), הזדהות, הרשאות ומדיניות סיסמאות וניטור גישה למשאבים ופעולות שבוצעו בחשבון (Audit trail).

בפרק השני בסדרה נמשיך לסקור נושאים נוספים והמלצות מבוססות best practices לבניית סביבות חדשות בענן.

בקרת תקציב

חשוב להגדיר עבור כל חשבון ענן תקציב (budget) והתראות לפני חריגה מהתקציב, כבר בשלבים הראשוניים של עבודה עם סביבת הענן, על-מנת להימנע מתרחיש בו בוצעה צריכת משאבים חריגה בשל טעות אנוש (רכישת שרתים או שירותים יקרים) או ממצב של Denial of Wallet בו מישהו חיצוני פרץ לחשבון הענן ומקים שרתים לטובת Bitcoin mining.

דוגמאות להגדרת תקציב בחשבונות ענן:

  • AWS Consolidated Billing – הגדרת חשבון מרכזי בין כלל חשבונות ה-AWS בארגון, אליו ישלחו כלל נתוני ה-Billing (ויהיה נגיש למורשי גישה בלבד)
  • GCP Cloud Billing Account – מקום מרכזי אליו משייכים את כלל ה-GCP Projects ובו מאוחסנים כלל נתוני ה-Billing של הארגון
  • Azure Cost Management – ממשק בו ניתן להגדיר תקציב והתראות עבור ה-Subscriptions בארגון. ניתן לאחד מספר Subscriptions ל-Management groups לצורך שליטה על מספר Subscriptions ממקום מרכזי.
  • Budget on Oracle Cloud Infrastructure – ממשק בו ניתן להגדיר תקציב והתראות עבור Compartments

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

על-מנת להימנע מגישה מכלל העולם לכיוון משאבים בחשבון הענן (שרתים וירטואליים, בסיסי נתונים, storage ועוד), מומלץ להקים שרת מוקשח (Bastion host), אשר יהיה נגיש מהעולם (תעבורת SSH או RDP) ודרכו נוכל להתחבר ולנהל משאבים בתוך חשבון הענן שהקמנו.

להלן מספר מדריכים כיצד להקים Bastion host:

בהמשך, ככל שהשימוש בסביבת הענן הולך ומתרחב, ניתן לשקול הקמת VPN Tunnel מהרשת המשרדית (Site-to-site VPN) או להשתמש בחיבור VPN של לקוחות מכיוון האינטרנט לסביבת הענן (דוגמת AWS Client VPN endpoint, Azure Point-to-Site VPN או Oracle Cloud SSL VPN).

Azure Point-to-Site VPN, Oracle Cloud SSL VPN).

המלצות לניהול משאבי מחשוב (Virtual Machines, Containers)

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

  • בחירת Image מתוך רשימה קיימת בצד ספק הענן (מערכת הפעלה, גרסת מערכת הפעלה ולעיתים שימוש ב-image המכיל תוכנות נוספות בתוך ה-image הבסיסי)
  • הגדרת ה-image בהתאם לדרישות הארגון/אפליקציה
  • עדכון כלל גרסאות התוכנה המותקנות בתוך ה-image
  • שמירת גרסא עדכנית של ה-image בתוך image repository בענן (לצורך שימוש חוזר)
  • היה והמידע בתוך השרתים חשוב, כדאי לשקול שימוש בשירותי גיבוי מנוהלים דוגמת AWS Backup או Azure Backup
  • בעת הקמת שרתי Windows יש לבחור סיסמא מורכבת לחשבון ה-Administrator ובמידת האפשר לשייך את השרת ל-Domain הארגוני
  • בעת הקמת שרתי Linux יש לבחור הזדהות מבוססת SSH Key Authentication ולאחסן את ה-Private key במקום מאובטח
  • ככל הניתן מומלץ להצפין (Encryption at Rest) מידע על גבי Block volumes (דיסקים של שרתים)
  • מומלץ לחבר שרתים לשירות Vulnerability Assessment לצורך איתור חולשות אבטחה (שירותים דוגמת Amazon Inspector או Azure Security Center)
  • מומלץ לחבר שרתים לשירות Patch Management לצורך תיקון חולשות אבטחה (שירותים דוגמת AWS Systems Manager Patch Manager, Azure Automation Update Management או Google OS Patch Management)

במידה ובוחרים להשתמש בתשתית Containers, חשוב להקפיד על הכללים הבאים:

  • מומלץ להשתמש ב-Container image מתוך Repository מוכר ומעודכן
  • מומלץ לעדכן את כלל ה-binaries וכלל ה-dependencies בתוך ה-Container image
  • בסיום תהליך עדכון ה-Container image יש לאחסן אותו בשירות Repository מנוהל בצד ספק הענן (דוגמת Amazon ECR, Azure Container Registry, GCP Container Registry או Oracle Cloud Container Registry)
  • ככל הניתן יש להימנע משימוש ב-Root account בתוך ה-Container
  • כאשר עובדים עם Containers צריך לוודא כי לא מאוחסן מידע (דוגמת Session ID’s) בתוך ה-Container וה-Container הינו Stateless
  • מומלץ לחבר את תהליך הפיתוח והעדכון של ה-Container לשירות Vulnerability Assessment לצורך איתור חולשות אבטחה (דוגמת Amazon ECR Image scanning, Azure Container Registry או GCP Container Analysis)

המלצות לאחסון מידע רגיש

מומלץ שלא לאחסן מידע רגיש (דוגמת נתוני הזדהות, מפתחות הצפנה, API Keys, Secrets) בצורה גלויה בתוך שרתים וירטואליים, Containers, קבצי טקסט או על תחנת העבודה.

את המידע הרגיש יש לאחסן בשירותי Vault מנוהלים, דוגמת: