בפרק הראשון והשני בסדרה סקרנו נושאים שונים, לרבות - חלוקת משאבים, תיוג משאבים (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)
- שימוש בפתרונות Infrastructure as a Code יאפשר הקמת סביבות בצורה אוטומטית, עם מינימום טעויות אנוש ובצורה זהה על פני סביבות שונות (Prod, Dev, Test).
דוגמאות לפתרונות Infrastructure as a Code:
- Google Cloud Deployment Manager
- Oracle Cloud Resource Manager
סיכום
לסיכום:
תכננו, בדקו מה אתם צריכים וחישבו בגדול.
במידה ותיישמו את ההמלצות המופיעות בסדרת מאמרים זו, המעבר לענן והקמת סביבות חדשות יתבצעו בקלות ובצורה חכמה, וכל זאת - בפעם הראשונה.
מקורות מידע נוספים
- Microsoft Azure Well-Architected Framework
- Google Cloud's Architecture Framework
- Oracle Cloud Infrastructure Best Practices Framework
המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי
בפרק הראשון והשני בסדרה סקרנו נושאים שונים, לרבות - חלוקת משאבים, תיוג משאבים (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)
- שימוש בפתרונות Infrastructure as a Code יאפשר הקמת סביבות בצורה אוטומטית, עם מינימום טעויות אנוש ובצורה זהה על פני סביבות שונות (Prod, Dev, Test).
דוגמאות לפתרונות Infrastructure as a Code:
- Google Cloud Deployment Manager
- Oracle Cloud Resource Manager
סיכום
לסיכום:
תכננו, בדקו מה אתם צריכים וחישבו בגדול.
במידה ותיישמו את ההמלצות המופיעות בסדרת מאמרים זו, המעבר לענן והקמת סביבות חדשות יתבצעו בקלות ובצורה חכמה, וכל זאת - בפעם הראשונה.
מקורות מידע נוספים
- Microsoft Azure Well-Architected Framework
- Google Cloud's Architecture Framework
- Oracle Cloud Infrastructure Best Practices Framework
המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר