כיצד להמנע מהטעויות הנפוצות ביותר בעת בניית סביבת הענן? חלק 1

‍

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

ההמלצה שלי – חשבו בגדול!

‍

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

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

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

תכנון מראש של חלוקת משאבים

השלב הראשון הוא תכנון של חלוקת המשאבים בהתאם לצורך הארגוני – חלוקה לפי מחלקות (מכירות, משאבי אנוש, תשתיות וכו') או חלוקה לפי סביבות (Production, Dev, Test).

על-מנת להימנע מערבוב משאבים (או הרשאות גישה) בין הסביבות השונות, מומלץ לחלק את המשאבים באופן הבא:

  -  חשבון עבור משאבים משותפים (רכיבי אבטחת מידע, auditing, ניהול billing וכו')

  -  חשבון עבור סביבת פיתוח (ניתן לשקול לייצר חשבון נפרד עבור סביבת בדיקות)

  -  חשבון עבור סביבת Production

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

  -    Azure Subscriptions או Azure Resource Groups

  -     AWS Accounts

  -     GCP Projects

  -     Oracle Cloud Infrastructure Compartments

תיוג משאבים (Tagging)

גם כאשר מקימים שרת בודד בתוך סביבה רשתית (AWS VPC, Azure Resource Group, GCP VPC), חשוב להקפיד לתייג משאבים, על-מנת שבהמשך נוכל לדעת אילו משאבים שייכים לאלו פרוייקטים / מחלקות / סביבות לצורכי billing.

דוגמאות ל-tagging נפוצים:

  -  Project

  -  Department

  -  Environment (Prod, Dev, Test)

מעבר להגדרת tagging, מומלץ להוסיף description למשאבים התומכים ב-Meta data מסוג זה, לצורך איתור משאבים בהתאם לייעוד שלהם.

הזדהות, הרשאות ומדיניות סיסמאות

על-מנת להקל על העבודה בחשבון הענן (ובהמשך במספר חשבונות ענן בהתאם לסביבות השונות), מומלץ להקפיד על מספר כללים:

  -  הזדהות מרכזית – במידה ובארגון אין Directory Service מרכזי לניהול חשבונות משתמש והרשאות גישה, ניתן להשתמש בשירותים מנוהלים דוגמת AWS IAM, Google Cloud IAM, Azure AD ו-Oracle Cloud IAM.

  -  במידה וקיים Directory Service מרכזי בארגון, מומלץ לחבר את שירות ה-IAM בחשבונות הענן לשירות ה-Directory Service המרכזי בארגון (Federated Authentication)

  -  היה ובוחרים להשתמש בשירות Directory Service מנוהל בענן, חובה להגדיר מדיניות סיסמאות, בהתאם למדיניות הנהוגה בארגון (אורך סיסמא מינימלי, מורכבות סיסמא, היסטוריית סיסמאות וכו')

  -   חובה להגן על החשבונות בעלי ההרשאות בענן (AWS Root Account, Azure Global Admin, Azure Subscription Owner, GCP Project Owner ו-Oracle Cloud Service Administrator Role), בין הייתר ע"י צמצום השימוש בחשבונות אלו למינימום ההכרחי, הגדרת סיסמת גישה מורכבת והחלפתה כל מספר חודשים, הפעלת Multi Factor Authentication והגדרת ניטור (auditing) על פעולות חשבונות אלו.

  - הרשאות גישה למשאבים יש להגדיר על-בסיס עקרון Least Privilege.

  - הרשאות גישה יש להעניק לקבוצות ולא למשתמשים ספציפיים.

  -  ב-AWS, ב-Azure, ב-GCP וב-Oracle Cloud יש להעדיף הענקת הרשאות גישה מבוססות Roles.

ניטור גישה למשאבים ופעולות שבוצעו בחשבון (Audit trail)

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

דוגמאות לשירותי Audit trail מנוהלים:

  -   AWS CloudTrail – מומלץ להפעיל ניטור על ככל ה-Regions ולהפנות את כלל הלוגים ל-S3 bucket מרכזי אשר יוגדר בחשבון AWS נפרד בסביבת הניהול (אשר יהיה נגיש למורשי גישה בלבד)

  - בשלב הראשון מומלץ לשקול להפעיל את שירות Azure Monitor לטובת ניטור גישה ופעולות שבוצעו ב-Subscription. בהמשך ניתן לשקול שימוש בשירותים דוגמת Azure Security Center ו-Azure Sentinel.

  -  Google Cloud Logging – מומלץ להפעיל ניטור על כלל ה-Projects ולהפנות את כלל הלוגים לתוך חשבון אחד (אשר יהיה נגיש למורשי גישה בלבד)

  -  Oracle Cloud Infrastructure Audit service – מומלץ להפעיל ניטור על כלל ה-Compartments ולשמור את כל הלוגים בחשבון ה-Root Compartment (אשר יהיה נגיש למורשי גישה בלבד)

‍

המאמר נכתב ע"י אייל אסטרין, ארכיטקט ענן במרכז החישובים הבינאוניברסיטאי

‍

‍

‍

‍