שיטות מומלצות לאבטחת אתרים

שיטות מומלצות לאבטחת אתרים

בעזרת Cloud CDN ו-Cloud Load Balancing תוכלו לעמוד בשיטות המומלצות לאבטחת אתרים, בין אם אתם מציגים תוכן ממכונות של Compute Engine, מקטגוריה של Cloud Storage או ממקור חיצוני שנמצא מחוץ ל- Google Cloud.

הגדרת כותרות אבטחה

במפרט HTTP יש מספר כותרות ששולטות בפעולות הבאות:

  • התנהגות הלקוחות
  • איך מטמיעים תוכן
  • איך התוכן מוצג בדומיינים שונים
  • האם להשתמש תמיד ב-TLS ‏ (HTTPS) כשמתחברים לדומיין הזה

אמצעי הבקרה האלה מיוצגים בדרך כלל ככותרות תגובת HTTP, שאפשר להגדיר לכל קצה עורפי (מקור, במונחי CDN) ככותרות תגובה מותאמות אישית לפריסה של מאזן עומסים של אפליקציות (ALB) חיצוני ושל Cloud CDN.

אם אתם משתמשים ב-Cloud Storage ומציגים תוכן אינטרנטי מהמאגר שלכם, אתם יכולים להשתמש ב-Cloud CDN לפני מאגר האחסון כדי להגדיר כותרות אבטחה לאינטרנט ולשמור במטמון תוכן פופולרי.

בטבלה הבאה מפורטות כותרות האבטחה הכי שימושיות לאתרים.

שם הכותרת תיאור דוגמאות לשימוש
‫Strict-Transport-Security (HSTS) מוודא שלדומיינים שלכם יש אישורי SSL (TLS) תקפים לפני שאתם מגדירים את הכותרת הזו.

מודיע ללקוחות שהם צריכים להתחבר לדומיין שלכם ישירות דרך HTTPS ‏ (SSL/TLS), וכך נמנע הצורך בהפניה מ-HTTP ל-HTTPS, שהיא איטית יותר ויוצרת סיכון להתקפת אדם בתווך.

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

כשמציגים את הכותרת Strict-Transport-Security, צריך להיזהר כשמוסיפים את ההוראות includeSubdomains או preload. ההוראות האלה מחייבות שימוש ב-HTTPS בכל סאבדומיין, כולל אתרים פנימיים באותו דומיין. לדוגמה, support.example.com כשמציגים מודעה מ-example.com.

הנחיית הלקוחות להתחבר ישירות באמצעות HTTPS לכל החיבורים העתידיים, תוך שמירת ההנחיה הזו במטמון למשך עד שנתיים:

Strict-Transport-Security: max-age=3104000

X-Frame-Options מציינת אם דפדפן יכול להציג דף בתג <frame>,‏ <iframe>,‏ <embed> או <object>. כך אפשר למנוע מתקפות חטיפת-קליקים, כי התוכן לא מוטמע באתרים אחרים. חסימת כל ההטמעות של האתר ב-iframe: X-Frame-Options: DENY

לאפשר רק לאתר שלכם להטמיע את עצמו ב-iframe: X-Frame-Options: SAMEORIGIN

Content-Security-Policy כדי להעריך את מדיניות אבטחת התוכן של האתר, אפשר להשתמש בכלי CSP Evaluator של Google. לא לאפשר סקריפטים מוטבעים, ולטעון סקריפטים רק דרך HTTPS: Content-Security-Policy: default-src https:

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

מידע נוסף על כותרות אבטחה לאינטרנט ושיטות מומלצות אפשר למצוא ב-web.dev וב-infosec site של Mozilla.

ניהול אישורים ו-TLS

לניהול אישורים יש את המאפיינים הבאים:

  • מסופקים ללא עלות
  • אפשר לפרוס בקלות במאזני העומסים
  • חידוש אוטומטי
  • מופצים באופן גלובלי לכל מיקומי הקצה של Google

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

באמצעות אישורי SSL, תוכלו ליהנות מפרוטוקולי תעבורה מודרניים, כמו HTTP/2 ופרוטוקול QUIC של Google, ששניהם דורשים SSL ‏ (TLS). הפרוטוקולים האלה משפרים באופן ישיר את הביצועים של תוכן אינטרנטי, של העברת מדיה (כמו סטרימינג של סרטונים) ושל האמינות ברשתות עמוסות.

Google Cloud תומך בפרוטוקולי TLS מודרניים (כמו TLS 1.3) בשירותי Cloud Load Balancing ו-Cloud CDN.

אתם יכולים להשתמש במדיניות SSL כדי להעלות את הגרסה המינימלית של TLS. מומלץ לשדרג לגרסה TLS v1.2, אם אתם לא צריכים לתמוך בלקוחות ישנים יותר, כמו מכשירים מוטמעים או לקוחות ישנים יותר (בני יותר מ-10 שנים) שאינם דפדפנים. ברחבי העולם, TLS v1.0 ו-TLS v1.1 מייצגים פחות מ-0.5% מהחיבורים ב- Google Cloud. אם אתם צריכים לזהות לקוחות ספציפיים או לשייך אותם לגרסאות לא עדכניות של TLS, אתם יכולים להשתמש ב{tls_version} משתנה בכותרת של בקשה. אחר כך תוכלו לרשום את המידע הזה.

המאמרים הבאים