הסביבה שלכם באמזון פועלת במתכונת של shared responsibility model בתשתיות הענן שלהם. המשמעות היא שאמזון אחראיים על האבטחה של המתקנים, שרתים, אחסון ותשתיות התקשורת שהם מספקים ללקוחות הענן. בעוד שאתם אחראיים לאבטחה של מערכות ההפעלה, המידע, הגדרות התקשורת והפירוול בתוך הסביבה שלו בענן.
סוגיה זו חשובה כיון שאם לא תאבטחו את המערכות שלו כראוי, ואינכם מבינים מה תחת אחריות שלכם ומה תחת אחריות הספק, התשתית לא תהיה מאובטחת.
הבסיס לאבטחה של סביבת הענן הוא שירותי ה-iam של אמזון. המגדיר את הגישה למשאבים השונים בסביבה. בעזרת השירות אתם מייצרים חשבונות משתמשים וקבוצות ולהעניק הרשאות גישה למשתמשים. ניתן ומומלץ גם לקשר את המערכת לתשתית אימות משתמשים פנימית במידה וקיים כזו תשתית על מנת לנהל את הגישה של המשתמשים למערכת ממקום אחד. הגישה למשאבים מבוססת access key , סיסמא ואימות דו-שלבי.
הרעיון הוא לעבוד בסביבה במודל של least privliges שמאפשר גישה רק למשאבים שהמשתמש/אפליקציה/שרת צריכים. זה קצת מוזר לנו כי אנחנו רגילים להגדיר לכל האפליקציות והשרתים סיסמת מנהל מערכת ולא להתייחס לרמת ההרשאות השונות, בעיקר כיון שזה מאוד קשה לנהל בסביבה מקומית, בענן זה פשוט מאוד.
בשום פנים אל תשתמשו בחשבון ה-aws שלהם (root account) על מנת לנהל את הסביבה או להגדיר גישה למשאבים כיון שיש לחשבון זה גישה לכל המערכות שלכם בענן. כבר ראיתי לקוחות משתמשים בחשבון ה-root שלהם בקוד עם ה-access keys ואז מעלים בטעות את הקוד עם ה-keys ל-github וככה פורצים להם למערכות בענן ומקימים שרתים לכריית ביטקוין (זה יעלה להם 5,000 דולר בשעה).
במקום זה תייצרו חשבונות iam נוספים ותגדירו לכל חשבון את ההרשאות הנדרשות כדי לעבוד. החשבון יכול בשימוש של משתמש/שירות/אפליקציה שצריכים גישה למשאבים בסביבה דרך console/api/cli.
במקום להגדיר במערכת הפעלה שם משתמש וסיסמא שיש לו הרשאות לאחסון, תשתמשו ב iam role לקבוצת שרתים שמגדיר שיש להם גישה לאחסון - ללא שם משתמש וסיסמא אלא על ידי temporary security credentials שמונפקים לשרת ומוחלפים באופן תקופתי באופן אוטומטי.
כאשר כל שרת עולה ב-aws, אתם מקבלים שם משתמש וסיסמא לניהול השרת - בלינוקס מדובר ב ec2 key pairs ובוינדוס מדובר בadministrator password. במידה ויש לכם דרישות אבטחה גבוהות יותר, תבטלו את השירות ותממשקו את המערכת למנגנון authentication חיצוני.
את הגישה למידע שלהם גם תנהלו בעזרת iam. הרעיון פה הוא להגדיר איזה משתמשים/קבוצות יכולים לגשת למידע, איזה הרשאות יהיו להם והאם הם נדרשים לבצע אימות לפני או לא. כך למשל תוכלו להגדיר חשבונות שיש להם גישה למידע שלכם רק אחרי אימות.
"Effect": "Allow”,
"Action": ["s3:GetObject”,"s3:PutObject”],
"Resource": ["arn:aws:s3:::myBucket/amazon/snakegame/${cognito-identity.amazonaws.com:sub}"]
דרך טובה נוספת שאתם יכולים להשתמש בה לאבטח את המידע באמזון היא הצפנה של הנתונים. את ההצפנה ניתן לבצע בעזרת שירות הצפנה מובנה של אמזון (kms) או בעזרת התקן חיצוני (למתקדמים, אם אתם רוצים שלא תהיה לספק גישה למפתחות ההצפנה). עבור כל סוג מידע יש לכם אופציות שונות להצפנה.
שירות s3 כולל הצפנה מובנית מצד השרת ע״י מפתחות הצפנה של אמזון או שלכם. הדיסקים (ebs) יכולים להיות מוצפנים בעזרת kms או כלי הצפנה שרץ ברמת מערכת ההפעלה. בסיסי הנתונים rds מוצפנים גם הם בעזרת מפתחות הצפנה.
שכבה נוספת באבטחה של מערכות ההפעלה הוא הקשחת ועדכון השרתים. אמזון מעדכנים את תבניות השרתים שלכם (ami) באופן תקופתי. כיון שרוב או לא כל השרתים שלנו לא מכילים מידע אפשר לפרוס באופן תקופתי שרתים חדשים מתבניות מעודכנות, או לבצע עדכוני אבטחה לשרתים בסביבה. הקשחת שרתים בענן דומה להקשחה מקומית של שרתים ולכן לא אתייחס לנושא.
אבטחת התקשורת שלנו בענן מבוססת על שירות vpc שזה בעצם ענן התקשורת הפרטי שלנו עם טווחי הכתובות של השרתים, הגדרות התקשורת והאבטחה שלהן. יש שתי הגדרות אבטחה מרכזיות בענן הזו.
- קבוצות אבטחה - זה בעצם הפירוול הרגיל שאנחנו מכירים עם החוקים ל north/south.
- קבוצות רשת - זה סוג של פירוול שבדרך כלל לא בשימוש ברשת ארגונית- פה מדובר בחוקים ברמת הסגמנט east-west.
השתמשו בשני הקבוצות האלה על מנת לאבטח את הרשת, גם במודל של least privilges.
קישור מאובטח של השרת הזו למשרד שלהם יכול להתבצע ב-ispec לפירוול ארגוני, או בקו direct connect - האופציה הראשונה זולה משמעותית מהשניה.
עבור ניטור של אבטחה בענן אמזון מספקים לנו שני כלים - cloudwatch שאוסף את הלוגים מהמערכות ויכול להתריע על אירועי אבטחת מידע - אפשר לשלוח לוגים משירותים שונים וממערכות הפעלה ואפליקציות. cloudtrail שמקליט את כל קריאות ה-api שמתבצעות בחשבון שלנו. השירותים האלה משמשים אותנו לניתוח של אירועי אבטחת מידע בסביבה.
במידה ואנחנו רוצים להבין מה השתנה מבחינת אבטחת מידע בסביבה, אפשר להשתמש בשירות של aws config על מנת להקליט את התצורה הקיימת שלנו ולנתח בקלות מול תצורה קודמת ולהבין איפה בוצע השינוי.
למידע נוסף:
aws.amazon.com/iam aws.amazon.com/vpc aws.amazon.com/kms aws.amazon.com/config aws.amazon.com/cloudtrail aws.amazon.com/cloudhsm aws.amazon.com/cloudwatch aws.amazon.com/trustedadvisor
https://aws.amazon.com/whitepapers/aws-security-best-practices/