בבלוג הקודם שלנו חקרנו את ההיסטוריה של רשימות בדיקה לפני טרום-הפלגה כדי למנוע כשלים קטסטרופליים כתוצאה מטעויות אנוש ותצורה שגויה. בבלוג זה נעמיק בבדיקת אבטחה קריטית של אחסון ענן ציבורי.
שגיאת תצורה משמעותית ב-AWS S3 היא הזנחה של אכיפת HTTPS (TLS) לגישה לנתוני דלי, מכיוון שתעבורה לא מוצפנת פגיעה להתקפות man-in-the-middle שיכולות לגנוב או לשנות נתונים תוך כדי העברה. התקפות מסוג זה עלולות להוביל לאובדן נתונים ארגוניים יקרי ערך ולהפרות תאימות לתקנות כגון PCI DSS ו-NIST 800-53 (rev 4).
אמזון הפיקה את מסגרת העבודה המעוצבת היטב של AWS כדי לסייע לארגונים להשיג שיטות עבודה מומלצות הקשורות למצוינות תפעולית, אבטחה, אמינות, יעילות ביצועים ואופטימיזציה של עלויות. עמוד האבטחה מספק הנחיות ליישום שיטות עבודה מומלצות בתכנון, אספקה ותחזוקה של עומסי עבודה מאובטחים של AWS.
אחריות משותפת
הקונספט של "אחריות משותפת" הוא אחד מיסודות עמוד התווך של האבטחה. על פי אמזון, AWS אחראית על "אבטחת הענן" בעוד שלקוחותיה אחראים על "אבטחה בענן". אחריות זו של הלקוח כוללת ניהול זהויות וגישה, זיהוי איומים, הגנה על תשתיות, הגנה על נתונים ותגובה לאירועים.
הגנת נתונים
הגנת מידע כוללת סיווג נתונים, כמו גם הגנה על נתונים במנוחה ועל נתונים במעבר. לפי אמזון:
נתונים במעבר הם כל נתונים הנשלחים ממערכת אחת לאחרת. זה כולל תקשורת בין משאבים בתוך עומס העבודה שלך, כמו גם תקשורת בין שירותים אחרים למשתמשי הקצה שלך. על ידי מתן רמת ההגנה המתאימה לנתונים שלך במעבר, אתה מגן על הסודיות והשלמות של נתוני עומס העבודה שלך.
אמזון מדגישה ארבע שיטות עבודה מומלצות להגנה על נתונים במעבר :
- הטמע ניהול מאובטח של מפתחות ותעודות
- אכיפת הצפנה במהלך העברה
- אימות תקשורת רשת
- זיהוי אוטומטי של גישה לא מכוונת לנתונים
אבטחת שכבת התעבורה
על מנת לאכוף הצפנה במעבר, שירותי AWS מספקים נקודות קצה של HTTPS באמצעות TLS לתקשורת. AWS Config מציעה כללים מנוהלים רבים המוגדרים מראש וניתנים להתאמה אישית, אשר ניתנים להגדרה בקלות לאכיפת שיטות עבודה מומלצות. בין הכללים הללו נמצא s3-bucket-ssl-requests-only , אשר בודק אם ל-buckets של Amazon S3 יש מדיניות שמונעת במפורש גישה לבקשות HTTP. מדיניות Bucket המאפשרת HTTPS מבלי לחסום HTTP נחשבת ללא תואמת.
ארגונים יכולים לאכוף כלל זה באמצעות מפתח התנאי "aws:SecureTransport" . כאשר מפתח זה הוא true (אמת), הבקשה נשלחה דרך HTTPS, אך כאשר הוא false (שקר), ארגונים זקוקים למדיניות bucket (דלי) אשר מונעת במפורש גישה לבקשות HTTP.
אמזון מספקת דוגמה זו למדיניות דלי (bucket policy) שמונעת גישה כאשר "aws:SecureTransport": "false":
{
"Id": "ExamplePolicy",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSSLRequestsOnly",
"Action": "s3:*",
"Effect": "Deny",
"Resource": [
"arn:aws:s3:::DOC-EXAMPLE-BUCKET",
"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
},
"Principal": "*"
}
]
}
הימנע משגיאות תצורה נפוצות עם OPSWAT
כשמדובר בשגיאות תצורה נפוצות, כגון HTTPS (TLS), ארגונים צריכים להשתמש ברשימות תיוג כדי לוודא שהם מיישמים שיטות עבודה מומלצות . אוטומציה של תהליך זה באמצעות טכנולוגיה יכולה לסייע במניעת שגיאות ידניות גוזלות זמן ויקרות.
MetaDefender Storage Security משפרת את פתרון אבטחת אחסון הענן שלה עם רשימת בדיקה משולבת לאבטחה, כך שאנשי אבטחת סייבר יכולים להבטיח שאחסון הענן של הארגון שלהם לא מוגדר בצורה שגויה בעת הקצאתו, כולל שלבי הפיתוח והייצור של אחסון הענן.
אכיפת HTTPS (TLS) לגישה לנתוני דלי היא פריט קריטי ברשימת בדיקה ב MetaDefender Storage Security , אבל זה לא היחיד. בבלוגים עתידיים, נחקור שגיאות תצורה עיקריות אחרות להגנה על נתונים במנוחה, כולל ניהול גרסאות של דליים, הצפנה בצד השרת ורישום גישה לדליים.
צור קשר עם OPSWAT מומחה אבטחת סייבר כדי ללמוד עוד.
