מכרזים

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

נכתב על ידי

03
08.2020

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

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

המלצות לשימוש ב-Object Storage

בעת שימוש ב-Object Storage, חשוב להקפיד על הכללים הבאים:

  • לא לאפשר גישה ציבורית (Public access) לשירותים דוגמת Amazon S3, Azure Blob Storage, Google Cloud Storage או Oracle Cloud Object Storage
  • חשוב להפעיל ניטור על הגישה ל-Object storage ולאחסן את הלוגים בחשבון ענן מרכזי (אשר יהיה נגיש למורשי גישה בלבד)
  • מומלץ להצפין מידע בעת אחסון על גבי Object Storage, ובמידת הצורך (או צרכים עסקיים) להשתמש בהצפנה מבוססת Customer Managed Keys
  • מומלץ לאכוף גישת HTTPS/TLS בחיבור משתמשים, שרתים ואפליקציות ל-Object Storage
  • מומלץ לוודא כי שם ה-Object Storage (אשר נרשם כשם DNS) אינו מכיל מידע רגיש אודות המידע המאוחסן ב-Object Storage (מכיוון שהשירות חשוף לגישת DNS מהעולם)

המלצות לנושא תקשורת

  • מומלץ לוודא כי כל משאב בחשבון הענן מוגן מאחורי חוקי תקשורת (דוגמת AWS Security Groups, Azure Network Security Groups, GCP Firewall Rules או Oracle Cloud Network Security Groups)
  • מומלץ שלא לאפשר גישה מכיוון האינטרנט לחיבור לשרתים בפרוטוקולים דוגמת SSH, RDP (במידה ונדרשת גישה מרחוק, מומלץ להשתמש ב-Bastion Host או בחיבור VPN)
  • ככל הניתן, מומלץ לחסום גישת תקשורת יוצאת (Outbound traffic) מכיוון סביבת הענן לכיוון האינטרנט. במידת הצורך ניתן להשתמש בשירות NAT (דוגמת Amazon NAT Gateway, Azure NAT Gateway, GCP Cloud NAT או Oracle Cloud NAT Gateway)
  • ככל הניתן, בגישה לשירותים, מומלץ להשתמש ב-DNS Names ולא בכתובות IP אשר עשויות להשתנות
  • כאשר מתכננים חשבון חדש בענן ובתוכו Subnets, יש לוודא כי לא תיהיה חפיפה בין רשתות (IP Overlapping) על-מנת לאפשר בהמשך חיבור בין רשתות (Peering)

שימושים מתקדמים בתשתיות ענן

  • ככל הניתן, מומלץ להשתמש בשירותים מנוהלים במקום ניהול שרתים וירטואליים (שירותים דוגמת Amazon RDS, Azure SQL Database, Google Cloud SQL ועוד).
    הדבר מאפשר ללקוח לצרוך שירות, מבלי לעסוק בתחזוקת שרתים, מערכות הפעלה, עדכונים, גיבויים ושרידות (במידה והגדרנו את השירות המנוהל בתצורת Cluster או Replica)

סיכום

לסיכום:

תכננו, בדקו מה את צריכים וחישבו בגדול.

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

מקורות מידע נוספים