הצפנה היא בדרך כלל נושא של אבטחה, אבל היא חשובה גם לפרטיות. מטרת ההצפנה היא למנוע מאחרים לקרוא את המידע המוצפן... אבל אחת הדרכים לשמור על פרטיות המידע שלכם היא למנוע מאחרים לקרוא אותו. משתמש מוגבל בדרך כלל במספר שבו הוא יכול לעשות את זה בעצמו, אבל בעזרת ההצפנה אפשר לשמור את הנתונים שלו אצל ספק השירות שהוא משתמש בו.
יש שלוש דרכים רלוונטיות להחיל הצפנה כדי לעזור בפרטיות המשתמשים: הצפנה בזמן ההעברה, הצפנה במנוחה והצפנה מקצה לקצה:
- הצפנה במעבר שומרת על הצפנה של הנתונים בין המשתמש לאתר שלכם, כלומר, HTTPS. סביר להניח שכבר הגדרתם HTTPS באתרים שלכם, אבל האם אתם בטוחים שכל הנתונים במעבר לאתרים שלכם מוצפנים? אלה המטרה של ההפניה האוטומטית וה-HSTS, והם מתוארים בהמשך והם צריכים להיות חלק מהגדרת ה-HTTPS.
- הצפנה במנוחה היא הצפנה של הנתונים שמאוחסנים בשרתים שלכם. התהליך הזה מגן מפני פרצות באבטחת מידע, והוא חלק חשוב במאמצי האבטחה שלכם.
- הצפנה מקצה לקצה היא ההצפנה של הנתונים בצד הלקוח לפני שהם מגיעים לשרת. הפעולה הזו מגינה על נתוני המשתמשים אפילו מפניכם: אפשר לאחסן את נתוני המשתמשים אבל לא לקרוא אותם. קשה ליישם את השיטה הזו והוא לא מתאים לכל סוגי האפליקציות, אבל הוא עוזר מאוד לשמירה על פרטיות המשתמשים, כי אף אחד לא יכול לראות את הנתונים שלו חוץ מעצמו.
HTTPS
השלב הראשון הוא הצגת שירות האינטרנט שלכם על גבי HTTPS. סביר מאוד להניח שכבר עשיתם זאת, אבל אם לא, זה שלב חשוב. HTTPS הוא פרוטוקול HTTP, שבו הדפדפן משתמש כדי לבקש דפי אינטרנט משרת, אך מוצפן באמצעות SSL. כלומר, תוקף חיצוני לא יכול לקרוא או להפריע לבקשת HTTPS בין השולח (המשתמש) למקבל (אתם), כי היא מוצפנת, ולכן הוא לא יכול לקרוא או לשנות אותה. מדובר בהצפנה במעבר: בזמן שהנתונים עוברים ממשתמש אליכם, או מכם למשתמש. הצפנת HTTPS במעבר גם מונעת מספק ה-ISP של המשתמש או מספק ה-Wi-Fi שהוא משתמש בו לקרוא את הנתונים שהוא שולח לכם, כחלק מהקשר שלו עם השירות שלכם. הדבר עשוי להשפיע גם על התכונות של השירות שלכם: לשימושים רבים בממשקי ה-API הקיימים של JavaScript, עליכם להציג את האתר באמצעות HTTPS. ל-MDN יש רשימה מקיפה יותר, אבל ממשקי API שמוגדרים בשער מאחורי הקשר מאובטח כוללים Service Worker, התראות דחיפה, שיתוף אינטרנט וקריפטו באינטרנט, וחלק מממשקי ה-API של המכשיר.
כדי להציג את האתר שלכם ב-HTTPS, תצטרכו אישור SSL. אפשר ליצור אותם בחינם דרך Let's Encrypt, או לספק אותם בדרך כלל על ידי שירות האירוח אם אתם משתמשים בו. אפשר גם להשתמש בשירות של צד שלישי ש "משרת proxy" את שירות האינטרנט ויכול לספק HTTPS, כמו גם שירותי שמירה במטמון ו-CDN. יש אינספור דוגמאות לשירותים כאלה, כמו Cloudflare ו-Fastly – בחירת השירותים שמותאמת במיוחד לתשתית הקיימת. בעבר, השימוש ב-HTTPS היה מעמס או יקר, ולכן נהגו להשתמש בו רק בדפי תשלומים או במקורות מאובטחים במיוחד. אבל אישורים, שיפורי סטנדרטים ושפע גדול יותר של דפדפנים הסירו את כל המכשולים האלה.
מה מותר לעשות
- הפעילו HTTPS בשרתים שלכם לכל פעולה (באיזו שיטה שתבחרו).
- כדאי להשתמש בשרת proxy מול השרתים, כמו Cloudflare (httpsiseasy.com/ מסביר את התהליך).
- Let's Encrypt ינחה אותך בתהליך היצירה של אישור SSL משלך Let's Encrypt.
- לחלופין, ניתן להשתמש ב-OpenSSL ישירות כדי ליצור אישור משלך ולחתום עליו ברשות האישורים (CA) שבחרת (בהפעלת HTTPS מוסבר איך לעשות זאת בפירוט).
הגישה שבה תבחרו תלויה בהשפעות העסקיות שלכם. הכי קל להגדיר את החיבור של צד שלישי ל-SSL, והיא כוללת יתרונות נוספים כמו איזון עומסים, שמירה במטמון וניתוח נתונים. אבל יש גם שליטה ברורה לצד השלישי הזה ותלות בלתי נמנעת בשירותים שלו (והתשלום האפשרי, בהתאם לשירותים שבהם אתם משתמשים ולרמות התנועה).
בעבר היה תהליך ה-SSL התנהל בעבר, עם הנפקת אישורים וחתימה שלהם על ידי רשות אישורים, אבל קל יותר להשתמש ב-Let's Encrypt אם הספק שלכם תומך בכך או אם צוות השרת מנוסה מספיק מבחינה טכנית. בנוסף, הספק שלכם מציע SSL בתור שירות אם משתמשים במשהו ברמה גבוהה יותר מאשר באירוח בענן, לכן כדאי לבדוק זאת.
סיבה
אבטחה היא חלק מסיפור הפרטיות שלכם: היכולת להוכיח שאתם שומרים על נתוני המשתמשים מאובטחים מפני הפרעה עוזרת לבנות אמון. אם אינך משתמש ב-HTTPS, האתרים שלך מסומנים גם כ"לא מאובטחים" על ידי דפדפנים (ומסומנים כבר במשך זמן מה). לרוב, ממשקי API קיימים של JavaScript זמינים רק לדפי HTTPS ("מקורות מאובטחים"). השירות גם מגן על המשתמשים מפני כשספק האינטרנט שלהם רואה את השימוש שלהם באינטרנט. זו בהחלט שיטה מומלצת. אין הרבה סיבה לא להשתמש ב-HTTPS לאתרים עכשיו, אם בכלל.
איך דפדפנים מציגים דף HTTP (לא מאובטח)
הפניה אוטומטית ל-HTTPS
אם האתר זמין גם בכתובות URL מסוג http: וגם https: , צריך להפנות את כל הגישות לכתובות URL מסוג http אל https. הסיבה לכך היא אחת מהסיבות שמפורטות למעלה, והיא גם מבטיחה שהאתר שלכם לא יופיע ב-whynohttps.com אם הוא יהפוך לפופולרי. הדרך לעשות זאת תלויה מאוד בתשתית שלכם. אם אתם מתארחים ב-AWS, תוכלו להשתמש במאזן עומסים קלאסי או Application. Google Cloud דומה. ב-Azure אפשר ליצור Front Door, ב-Node עם Express לבדוק את request.secure, ב-Nginx לקבל את כל היציאה 80 ולהחזיר 301; וב-Apache, להשתמש ב-RewriteRule. אם אתם משתמשים בשירות אירוח, סביר מאוד להניח שהוא יטפל עבורכם באופן אוטומטי בהפניה אוטומטית לכתובות URL מסוג HTTPS: בין היתר, Netlify, Firebase ו-GitHub Pages.
HSTS
HSTS הוא קיצור של HTTP Strict-Transport-Security, והוא משמש להגדרת נעילה סופית של הדפדפן לשימוש ב-HTTPS בשירות שלכם. כשתהיו מרוצים מההעברה ל-HTTPS, או אם כבר עשיתם זאת, תוכלו להוסיף כותרת תגובת HTTP של Strict-Transport-Security לתגובות היוצאות. דפדפן שניגש לאתר בעבר יקליט לאחר שראה את הכותרת הזו, ולאחר מכן ייגש לאתר באופן אוטומטי כ-HTTPS, גם אם תבקש HTTP. כך המערכת לא תעבור את ההפניה האוטומטית הזו, כאילו הדפדפן "משדרג" בחשאי את כל הבקשות לשימוש ב-HTTPS לשירות שלכם.
באופן דומה, ניתן להציג את הכותרת Upgrade-Insecure-Requests ביחד עם הדפים שלכם. הפעולה הזו שונה מ-Strict-Transport-Security, אבל קשורה אליה. אם מוסיפים את Upgrade-Insecure-Requests: 1, בקשות מהדף הזה למשאבים אחרים (תמונות, סקריפטים) יישלחו כ-https, גם אם הקישור הוא http. עם זאת, הדפדפן לא יבקש שוב את הדף עצמו כ-https, והדפדפן לא יזכור לפעם הבאה. בפועל, Upgrade-Insecure-Requests הוא שימושי אם ממירים אתר קיים עם קישורים רבים ל-HTTPS, וקשה להמיר את כתובות ה-URL של הקישורים בתוכן, אבל עדיף לשנות את התוכן ככל האפשר.
HSTS הוא בעיקר אמצעי אבטחה: הוא 'נועל' את האתר ל-HTTPS עבור משתמשים שכבר ביקרו בו. עם זאת, כפי שצוין למעלה, HTTPS טוב לפרטיות ו-HSTS טוב ל-HTTPS. באותו אופן, גם אין צורך בשדרוג-לא בטוח של בקשות כשמעדכנים את כל התוכן, אבל זו גישה שימושית של "חגורה וסוגריים" כדי להוסיף הגנה לעומק כדי להבטיח שהאתר תמיד יהיה ב-HTTPS.
מה מותר לעשות
הוספת כותרת ה-HSTS לתשובות היוצאות:
Strict-Transport-Security: max-age=300; includeSubDomains
הפרמטר 'גיל מקסימלי' קובע כמה זמן בשניות, הדפדפן צריך לזכור ולאכוף את שדרוג ה-HTTPS. (כאן אנו מגדירים את הקצב ל-300 שניות, כלומר, חמש דקות.) בסופו של דבר תרצו שהוא יהיה 6,3072,000, כלומר שנתיים, שהוא הסכום המומלץ על ידי hstspreload.org, אבל די קשה לשחזר אותו במקרה של בעיות. לכן מומלץ להגדיר בהתחלה מספר נמוך (300), לבדוק ששום דבר לא השתבש, ולאחר מכן להגדיל את המספר בשלבים.
מוסיפים את הכותרות של Upgrade-Insecure-Requests לתשובות היוצאות:
Upgrade-Insecure-Requests: 1
Content-Security-Policy: upgrade-insecure-requests
הצפנה מקצה לקצה
דרך טובה לשמור על הפרטיות של נתוני משתמש היא לא להציג אותם לאף אחד מלבד המשתמש, כולל לכם. זה עוזר מאוד לעמדת האמון שלכם: אם אין לכם את הנתונים של המשתמש, ברור שלא תוכלו לעשות איתם שום דבר שהוא לא רוצה. דרך אחת לעשות זאת היא לא לאפשר לנתוני המשתמש לצאת בכלל מהמכשיר, על ידי אחסון כל הנתונים בצד הלקוח. הדרך הזו עובדת, אבל יש מגבלות לאפליקציה בלבד בצד הלקוח: נפח האחסון של נתוני הדפדפן יכול להיות מוגבל, ובדפדפנים מסוימים הוא יכול להימחק עם מעט אזהרה או ללא אזהרה בכלל. כמו כן, קשה או בלתי אפשרי לגשת לנתונים בשני מכשירים, כמו מחשב נייד וטלפון נייד. לכן כדאי לשלוח נתונים לשרת כרגיל, אבל להצפין אותם עם מפתח שידוע רק למשתמש, כדי שהשרת לא יוכל לגשת אליו (כי הוא לא יוכל לפענח אותו) אבל יוכל לאחסן אותם.
איך זה עובד?
באפליקציות של העברת הודעות הרבה אנשים משתמשים בגישה הזו, שמכונה 'הצפנה מקצה לקצה' או e2e. כך, שני אנשים שמכירים את המפתחות של אחרים יכולים להצפין ולפענח את ההודעות שלהם הלוך ושוב, ולשלוח את ההודעות דרך ספק ההודעות, אבל ספק ההודעות (שאין לו את המפתחות האלה) לא יוכל לקרוא את ההודעות. רוב האפליקציות הן לא אפליקציות להעברת הודעות, אבל אפשר לשלב בין שתי הגישות – מאגר נתונים בצד הלקוח בלבד והצפנת נתונים עם מפתח שידוע ללקוח – כדי לאחסן נתונים באופן מקומי וגם לשלוח אותם לשרת. חשוב להבין שיש מגבלות לגישה הזו: זה לא אפשרי בכל השירותים, ובמיוחד לא ניתן להשתמש בו אם אתם, כספקי השירות, צריכים גישה למה שהמשתמש מאחסן. כפי שמתואר בחלק 2 בסדרה הזו, עדיף לציית לעקרון של צמצום הנתונים – כדאי להימנע מאיסוף נתונים ככל האפשר. אם המשתמש צריך אחסון נתונים אבל אין לכם צורך בגישה לנתונים האלה כדי לספק את השירות, תוכלו להשתמש בהצפנה מקצה לקצה. אם אתם מספקים שירותים שדורשים הרשאה לראות מה המשתמש מאחסן כדי לספק את השירות, ההצפנה מקצה לקצה לא מתאימה. אבל אם לא, תוכלו לבקש ש-JavaScript בצד הלקוח של שירות האינטרנט יצפין את הנתונים שהוא שולח לשרת ויפענח את הנתונים שהוא מקבל.
דוגמה: החרגה
exalidraw מבצעת את הפעולה הזו ומסבירה איך לעשות זאת בפוסט בבלוג. זוהי אפליקציה לשרטוט וקטורי שמאחסנת שרטוטים בשרת, שהוצפנו באמצעות מפתח שנבחר באופן אקראי. חלק מהסיבה לכך ש-exalidraw יכולה להטמיע את ההצפנה מקצה לקצה עם קוד קטן יחסית היא שהספריות הקריפטוגרפיות בנויות עכשיו בדפדפן באמצעות window.crypto, שהיא קבוצה של ממשקי JavaScript API נתמכים בכל הדפדפנים המודרניים. הקריפטוגרפיה קשה, והטמעת האלגוריתמים כוללת מקרים רבים של קצה. העבודה הקשה בדפדפן הופכת את ההצפנה לנגישה יותר למפתחי אתרים, ולכן קל יותר להטמיע את הפרטיות באמצעות נתונים מוצפנים. כפי שמתואר ב-exalidraw, מפתח ההצפנה נשאר בצד הלקוח, כי הוא חלק מקטע כתובת ה-URL: כאשר דפדפן נכנס לכתובת URL https://example.com/path?param=1#fraghere, הנתיב של כתובת ה-URL (/path) והפרמטרים (param=1) מועברים לשרת (example.com), אבל המקטע (fraghere) לא, ולכן השרת אף פעם לא רואה אותו. כלומר, גם אם הנתונים המוצפנים עוברים בשרת, מפתח ההצפנה לא נשמר, ולכן הפרטיות נשמרת כי הנתונים מוצפנים מקצה לקצה.
מגבלות
הגישה הזו להצפנת נתוני משתמשים אינה מובטחת. הוא תורם לעמדת האמון של המשתמשים, אבל לא יכול להחליף אותה לגמרי. המשתמשים שלכם עדיין יצטרכו לסמוך על השירות שלכם, מכיוון שאתם יכולים בכל רגע להחליף את ה-JavaScript בצד הלקוח ב-JavaScript דומה באופן עדין שאינו מצפין נתונים באופן בלתי הפיך. למרות זאת, משתמשים יכולים לזהות אם האתר שבו אתם משתמשים עשה זאת, אבל קשה מאוד לעשות זאת. בפועל, המשתמשים שלכם עדיין יצטרכו לסמוך על נתונים שהם לא קריאים ותראו שהם לא קריאים יותר, בעוד שהם לא יוכיחו שאתם לא נותנים אמון בנתונים שלכם בכוונה.
חשוב גם לזכור שאחת המטרות של הצפנה מקצה לקצה היא למנוע מבעלי האתר לקרוא את הנתונים. הפעולה הזו מועילה לשמירה על הפרטיות, אבל המשמעות היא גם שאם יש בעיות, לא תוכלו לעזור. באופן כללי, בשירות עם הצפנה מקצה לקצה המשתמש הוא זה שאחראי על מפתחות ההצפנה. (זה אולי לא מובן מאליו או גלוי, אבל מישהו צריך את המפתח. אם הנתונים לא גלויים לכולם, זה לא המקרה שלך). אם המפתחות האלה יאבדו, לא תוכלו לעזור יותר, וסביר להניח שגם הנתונים שהוצפנו באמצעות המפתחות האלה יאבדו. יש כאן איזון עדין בין פרטיות לנוחות השימוש: שמרו על פרטיות הנתונים מכולם, אבל רצוי להימנע מאילוץ המשתמשים להיות מומחי קריפטולוגיה שמנהלים את המפתחות שלהם בצורה מאובטחת.
הצפנה במנוחה
בנוסף להצפנת נתוני המשתמשים בזמן ההעברה, חשוב גם לשקול להצפין את הנתונים שאחסנת בשרת. הפעולה הזו עוזרת להתגונן מפני פרצות באבטחת המידע, כי לכל מי שישיג גישה לא מורשית לנתונים השמורים שלכם יוצפנו נתונים מוצפנים, שבתקווה לא יהיו להם המפתחות לפענוח. יש שתי גישות שונות ומשלימות להצפנת נתונים במנוחה: הצפנה שמוסיפים והצפנה שספק האחסון בענן מוסיף (אם אתם משתמשים בספק של אחסון בענן). ההצפנה של ספק האחסון לא מספקת הגנה רבה מפני פרצות באבטחת מידע (כי ההצפנה של ספק האחסון בדרך כלל שקופה לכם כמשתמש בשירות שלו), אבל היא עוזרת מפני פרצות בתשתית של הספק. בדרך כלל קל להפעיל אותה, לכן כדאי לשקול. השדה הזה משתנה במהירות, וצוות האבטחה שלכם (או מהנדסי אבטחה בצוות שלכם) הוא הגורם הכי מתאים לייעוץ בנושא, אבל כל ספקי האחסון בענן מציעים הצפנה במנוחה לאחסון בלוקים (block storage) ל-Amazon S3 באמצעות הגדרה, Azure Storage ו-Google Cloud Storage כברירת מחדל, ולאחסון נתונים של מסדי נתונים AWS RDS ו-Azure SQL, Google Cloud, תוכלו לבדוק את זה עם ספק האחסון בענן, אם אתם משתמשים בו. קשה יותר לטפל בהצפנה של נתונים במנוחה כדי להגן על נתוני המשתמשים מפני פרצות באבטחת מידע, כי הלוגיסטיקה של ניהול מאובטח של מפתחות הצפנה והפיכתם לזמינים לקוד בלי להנגיש אותם לתוקפים גם הם. זה לא המקום הכי טוב לייעץ לגבי בעיות אבטחה ברמה הזו. כדאי להתייעץ עם מהנדסי התוכנה או עם הצוות הייעודי שלכם בנושא אבטחה או עם סוכנויות אבטחה חיצוניות.