رمزگذاری اغلب موضوعی برای امنیت است، اما برای حفظ حریم خصوصی نیز مهم است. هدف از رمزگذاری جلوگیری از خواندن اطلاعات رمزگذاری شده توسط دیگران است... اما جلوگیری از خواندن اطلاعات شما توسط دیگران یکی از راه های خصوصی نگه داشتن آن است. یک کاربر معمولاً در میزانی که می‌تواند خودش این کار را انجام دهد محدود است، اما با کمک شما به عنوان ارائه‌دهنده سرویسی که از آن استفاده می‌کند، رمزگذاری می‌تواند به حفظ داده‌های او کمک کند.
سه روش مرتبط برای اعمال رمزگذاری برای کمک به حفظ حریم خصوصی کاربر وجود دارد: رمزگذاری در حین انتقال، رمزگذاری در حالت استراحت، و رمزگذاری سرتاسر:
- رمزگذاری در حین انتقال ، رمزنگاری داده ها بین کاربر و سایت شما است: یعنی HTTPS. احتمالاً از قبل HTTPS را برای سایت های خود تنظیم کرده اید، اما آیا مطمئن هستید که تمام داده های در حال انتقال به سایت های شما رمزگذاری شده است؟ این همان چیزی است که تغییر مسیر و HSTS برای آن هستند و در زیر توضیح داده شده اند و باید بخشی از راه اندازی HTTPS شما باشند.
- رمزگذاری در حالت استراحت رمزگذاری داده های ذخیره شده در سرورهای شما است. این امر در برابر نقض داده ها محافظت می کند و بخش مهمی از موضع امنیتی شما است.
- رمزگذاری End-to-End رمزگذاری داده های روی کلاینت قبل از رسیدن به سرور شما است. این از داده های کاربر حتی از شما محافظت می کند: می توانید داده های کاربران خود را ذخیره کنید، اما نمی توانید آنها را بخوانید. پیاده‌سازی این کار دشوار است و برای همه انواع برنامه‌ها مناسب نیست، اما کمک بزرگی به حفظ حریم خصوصی کاربر است، زیرا هیچ‌کس نمی‌تواند داده‌های او را به جز خودش ببیند.
HTTPS
اولین حرکت ارائه خدمات وب شما از طریق HTTPS است. این احتمال وجود دارد که قبلاً این کار را انجام داده باشید، اما اگر نه، این یک مرحله مهم است. HTTPS HTTP است، پروتکلی که مرورگر برای درخواست صفحات وب از سرور استفاده می کند، اما با استفاده از SSL رمزگذاری می شود. این بدان معنی است که یک مهاجم خارجی نمی تواند درخواست HTTPS را بین فرستنده (کاربر شما) و گیرنده (شما) بخواند یا در آن دخالت کند، زیرا رمزگذاری شده است و بنابراین نمی توانند آن را بخوانند یا تغییر دهند. این رمزگذاری در انتقال است: در حالی که داده ها از کاربر به شما یا از شما به کاربر منتقل می شوند. رمزگذاری HTTPS در حین انتقال همچنین از ISP کاربر یا ارائه‌دهنده Wi-Fi که استفاده می‌کند، نمی‌تواند داده‌هایی را که به عنوان بخشی از رابطه با سرویس شما برای شما ارسال می‌کند، بخواند. ممکن است بر ویژگی‌های سرویس شما نیز تأثیر بگذارد: بسیاری از کاربردهای APIهای جاوا اسکریپت موجود نیازمند ارائه وب‌سایت از طریق HTTPS هستند. MDN فهرست جامع تری دارد، اما API هایی که در پشت زمینه ای امن قرار گرفته اند شامل کارکنان خدمات، اعلان های فشار، اشتراک گذاری وب و رمزنگاری وب و برخی از API های دستگاه است.
برای ارائه خدمات وب سایت خود از طریق HTTPS به گواهی SSL نیاز دارید. اینها را می توان به صورت رایگان از طریق Let's Encrypt ایجاد کرد، یا اغلب می تواند توسط سرویس میزبانی شما در صورت استفاده از یکی ارائه شود. همچنین می توان از یک سرویس شخص ثالث استفاده کرد که سرویس وب شما را "پراکسی" می کند و می تواند HTTPS و همچنین خدمات کش و CDN را ارائه دهد. نمونه‌های متعددی از چنین سرویس‌هایی مانند Cloudflare و Fastly وجود دارد که دقیقاً به زیرساخت فعلی شما بستگی دارد. در گذشته، اجرای HTTPS می‌توانست سنگین یا پرهزینه باشد، به همین دلیل است که فقط در صفحات پرداخت یا مبداهای امن استفاده می‌شود. اما گواهینامه های رایگان در دسترس، بهبود استانداردها، و گسترش بیشتر مرورگرها همه آن موانع را از بین برده است.
انجام دادن
- HTTPS را در سرورهای خود برای همه چیز (هر روشی که انتخاب کنید) فعال کنید.
- استفاده از یک پروکسی در مقابل سرورهای خود، مانند Cloudflare را در نظر بگیرید ( httpsiseasy.com/ فرآیند را توضیح می دهد).
- Let's Encrypt شما را در فرآیند ایجاد گواهینامه Let's Encrypt SSL راهنمایی می کند.
- یا به طور مستقیم از OpenSSL برای ایجاد گواهینامه خود استفاده کنید و آن را توسط مرجع صدور گواهی (CA) امضا کنید ( فعال کردن HTTPS نحوه انجام این کار را با جزئیات توضیح می دهد).
اینکه کدام رویکرد را انتخاب می کنید به مبادلات تجاری بستگی دارد. داشتن یک شخص ثالث مدیریت اتصال SSL را برای شما آسان‌ترین راه‌اندازی است و مزایای دیگری مانند تعادل بار، ذخیره‌سازی حافظه پنهان و تجزیه و تحلیل را به همراه دارد. اما همچنین با واگذاری آشکار برخی از کنترل ها به شخص ثالث و وابستگی اجتناب ناپذیر به خدمات آنها (و پرداخت احتمالی، بسته به خدماتی که استفاده می کنید و سطح ترافیک شما) همراه است.
تولید گواهی‌ها و امضای آنها توسط CA روشی است که قبلاً فرآیند SSL انجام می‌شد، اما استفاده از Let's Encrypt در صورتی که توسط ارائه‌دهنده شما پشتیبانی شود یا تیم سرور شما از نظر فنی به اندازه کافی برای آن مهارت داشته باشد و رایگان باشد، می‌تواند آسان‌تر باشد. همچنین اگر از چیزی در سطح بالاتری نسبت به میزبانی ابری استفاده می کنید، ارائه SSL به عنوان یک سرویس معمول است، بنابراین ارزش بررسی را دارد.
چرا
امنیت بخشی از داستان حریم خصوصی شماست: اینکه بتوانید نشان دهید که داده های کاربر را در برابر تداخل ایمن نگه می دارید به ایجاد اعتماد کمک می کند. اگر از HTTPS استفاده نمی کنید، سایت های شما نیز توسط مرورگرها به عنوان "ناامن" علامت گذاری می شوند (و مدتی است که وجود داشته اند). APIهای جاوا اسکریپت موجود اغلب فقط برای صفحات HTTPS ("منشاهای امن") در دسترس هستند . همچنین از کاربران شما در برابر مشاهده استفاده از وب آنها توسط ISP محافظت می کند. این مطمئنا بهترین روش است. در حال حاضر دلیلی برای عدم استفاده از HTTPS برای وب سایت ها وجود ندارد.
چگونه مرورگرها صفحه HTTP (غیر ایمن) را ارائه می دهند
به HTTPS تغییر مسیر دهید
اگر سایت شما در هر دو آدرس http: و https: موجود است، باید تمام دسترسی‌های http URL را به https هدایت کنید. این به دلایل بالا است، و همچنین تضمین می کند که در صورت محبوب شدن سایت شما در Whynohttps.com نمایش داده نمی شود. نحوه انجام این کار تا حد زیادی به زیرساخت شما بستگی دارد. اگر در AWS میزبانی می‌کنید، می‌توانید از یک متعادل کننده بار کلاسیک یا Application استفاده کنید. Google Cloud نیز مشابه است. در Azure می توانید یک Front Door ایجاد کنید. در Node با بررسی Express برای request.secure ; در Nginx همه پورت 80 را بگیرید و 301 را برگردانید . و در آپاچی از یک RewriteRule استفاده کنید . اگر از یک سرویس میزبانی استفاده می کنید، به احتمال زیاد آنها به طور خودکار به URL های HTTPS برای شما هدایت می شوند: Netlify، Firebase، و GitHub Pages و بسیاری دیگر.
HSTS
HSTS مخفف "HTTP Strict-Transport-Security" است و راهی برای قفل کردن مرورگر برای استفاده از HTTPS برای همیشه برای سرویس شما است. هنگامی که از انتقال خود به HTTPS راضی هستید، یا اگر قبلاً این کار را انجام داده اید، می توانید یک سرصفحه پاسخ HTTP با امنیت حمل و نقل دقیق به پاسخ های خروجی خود اضافه کنید. مرورگری که قبلاً به سایت شما دسترسی داشته باشد، مشاهده می‌کند که این هدر را مشاهده کرده است، و از آن پس به‌طور خودکار به این سایت به عنوان HTTPS دسترسی پیدا می‌کند، حتی اگر HTTP درخواست کنید. با این کار از تغییر مسیر شما مانند بالا جلوگیری می کنید: مثل این است که مرورگر بی سر و صدا تمام درخواست های سرویس شما را برای استفاده از HTTPS "ارتقاء" می کند.
به طور مشابه، می توانید یک هدر Upgrade-Insecure-Requests را همراه با صفحات خود ارائه دهید. این چیزی متفاوت از اما مرتبط با Strict-Transport-Security است. اگر Upgrade-Insecure-Requests: 1 را اضافه کنید، درخواست‌های این صفحه به منابع دیگر (تصاویر، اسکریپت‌ها) به عنوان https درخواست می‌شوند، حتی اگر پیوند http باشد. با این حال، مرورگر خود صفحه را مجدداً به عنوان https درخواست نمی کند و مرورگر برای دفعات بعدی به خاطر نمی آورد. در عمل، درخواست‌های Upgrade-Insecure در صورتی مفید است که یک سایت موجود با لینک‌های زیاد را به HTTPS تبدیل می‌کنید و تبدیل آدرس‌های لینک در محتوا سخت است، اما بهتر است در صورت امکان محتوا را تغییر دهید.
HSTS در درجه اول یک ویژگی امنیتی است: سایت شما را به HTTPS برای کاربرانی که قبلا آنجا بوده اند قفل می کند. با این حال، همانطور که در بالا ذکر شد، HTTPS برای حفظ حریم خصوصی و HSTS برای HTTPS خوب است. به طور مشابه، اگر تمام محتوای خود را به‌روزرسانی می‌کنید، درخواست‌های Upgrade-Insecure واقعاً مورد نیاز نیست، اما این یک رویکرد مفید «کمربند و مهاربند» برای افزودن عمق دفاع در حصول اطمینان از اینکه سایت شما همیشه HTTPS خواهد بود، است.
انجام دادن
هدر HSTS را به پاسخ های خروجی خود اضافه کنید:
Strict-Transport-Security: max-age=300; includeSubDomains
پارامتر max-age تعیین می‌کند که مرورگر چه مدت در چند ثانیه باید ارتقاء HTTPS را به خاطر بسپارد و اجرا کند. (در اینجا ما آن را روی 300 ثانیه، یعنی پنج دقیقه تنظیم می کنیم.) در نهایت می خواهید این رقم 6,3072,000 باشد که دو سال است و رقمی است که hstspreload.org توصیه می کند، اما بازیابی آن بسیار دشوار است. اگر مسائلی وجود دارد بنابراین توصیه می شود ابتدا این را با یک عدد کم (300) تنظیم کنید، تست کنید تا مطمئن شوید چیزی خراب نیست و سپس تعداد را به صورت مرحله ای افزایش دهید.
هدرهای Upgrade-Insecure-Requests به پاسخ های خروجی خود اضافه کنید:
Upgrade-Insecure-Requests: 1 Content-Security-Policy: upgrade-insecure-requests
رمزگذاری انتها به انتها
یک راه خوب برای خصوصی نگه داشتن داده‌های کاربر این است که آنها را به کسی غیر از کاربر از جمله شما نشان ندهید. این به موضع اعتماد شما کمک زیادی می کند: اگر داده های کاربر خود را ندارید، واضح است که نمی توانید کاری را با آن انجام دهید که آنها نمی خواهند. یکی از راه‌های انجام این کار این است که به هیچ وجه اجازه ندهید داده‌های کاربر از دستگاه آنها خارج شود و همه چیز را در سمت کلاینت ذخیره کنید. این رویکرد کار می‌کند، اما محدودیت‌هایی برای یک برنامه کاربردی سمت کلاینت خالص وجود دارد: ذخیره‌سازی داده‌های مرورگر می‌تواند از نظر اندازه محدود باشد، و در برخی از مرورگرها ممکن است با اخطار کم یا بدون هشدار پاک شود. همچنین دسترسی به داده های خود در دو دستگاه مانند لپ تاپ و تلفن همراه دشوار یا غیرممکن است. به همین دلیل، ارسال داده‌ها به سرور در حالت عادی می‌تواند مفید باشد، اما آنها را با کلیدی که فقط کاربر می‌داند رمزگذاری کنید تا سرور نتواند به آن دسترسی داشته باشد (چون نمی‌تواند آن را رمزگشایی کند) اما بتواند آن را ذخیره کند.
چگونه کار می کند؟
این رویکرد اغلب توسط برنامه‌های پیام‌رسانی استفاده می‌شود، جایی که از آن به عنوان «رمزگذاری انتها به انتها» یا «e2e» یاد می‌شود. به این ترتیب، دو نفر که کلیدهای یکدیگر را می شناسند می توانند پیام های خود را به صورت رفت و برگشت رمزگذاری و رمزگشایی کنند و آن پیام ها را از طریق ارائه دهنده پیام ارسال کنند، اما ارائه دهنده پیام (که آن کلیدها را ندارد) نمی تواند پیام ها را بخواند. بیشتر برنامه‌ها برنامه‌های پیام‌رسان نیستند، اما می‌توان این دو رویکرد را با هم ترکیب کرد - یک ذخیره‌سازی صرفاً در سمت مشتری، و رمزگذاری داده‌ها با یک کلید شناخته شده برای مشتری - برای ذخیره داده‌ها به صورت محلی و همچنین ارسال آنها به صورت رمزگذاری شده به سرور. درک این نکته مهم است که این رویکرد محدودیت‌هایی دارد: این برای همه سرویس‌ها امکان‌پذیر نیست، و به‌ویژه اگر شما به‌عنوان ارائه‌دهنده خدمات، نیاز به دسترسی به آنچه کاربر ذخیره می‌کند، نمی‌توان از آن استفاده کرد. همانطور که در قسمت 2 این مجموعه توضیح داده شد، بهتر است از اصل کمینه سازی داده ها تبعیت کنید. در صورت امکان از جمع آوری داده ها خودداری کنید. اگر کاربر به ذخیره سازی داده نیاز دارد، اما شما برای ارائه خدمات نیازی به دسترسی به آن داده ها ندارید، رمزگذاری انتها به انتها یک جایگزین مفید است. اگر خدماتی ارائه می دهید که نیاز به دیدن آنچه کاربر برای ارائه خدمات ذخیره می کند، دارد، رمزگذاری سرتاسر مناسب نیست. اما اگر این کار را نکنید، می توانید از جاوا اسکریپت سمت سرویس گیرنده سرویس وب خود بخواهید هر داده ای را که به سرور ارسال می کند رمزگذاری کند و هر داده ای را که دریافت می کند رمزگشایی کند.
مثال: Excalidraw
Excalidraw این کار را انجام می دهد و چگونگی آن را در یک پست وبلاگ توضیح می دهد. این یک برنامه طراحی برداری است که نقاشی ها را روی سرور ذخیره می کند که با یک کلید به طور تصادفی انتخاب شده رمزگذاری می شوند. بخشی از دلیلی که Excalidraw می‌تواند این رمزگذاری سرتاسر را با کد نسبتاً کمی پیاده‌سازی کند این است که کتابخانه‌های رمزنگاری اکنون در مرورگر با window.crypto ساخته شده‌اند که مجموعه‌ای از APIهای جاوا اسکریپت است که در همه مرورگرهای مدرن پشتیبانی می‌شوند . رمزنگاری سخت است و پیاده‌سازی الگوریتم‌ها با موارد لبه زیادی همراه است. اگر مرورگر کارهای سنگین را در اینجا انجام دهد، رمزگذاری را برای توسعه دهندگان وب در دسترس تر می کند و بنابراین اجرای حریم خصوصی از طریق داده های رمزگذاری شده را آسان تر می کند. همانطور که Excalidraw در نوشتن خود توضیح می دهد، کلید رمزگذاری در سمت سرویس گیرنده باقی می ماند، زیرا بخشی از قطعه URL است: وقتی مرورگر از یک URL بازدید می کند https://example.com/path?param=1#fraghere ، مسیر URL ( /path ) و پارامترها ( param=1 ) به سرور ارسال می شوند ( example.com )، اما قطعه ( fraghere ) چنین نیست، و بنابراین سرور هرگز آن را نمی بیند. این بدان معنی است که حتی اگر داده های رمزگذاری شده از طریق سرور عبور کند، کلید رمزگذاری انجام نمی شود و بنابراین حریم خصوصی حفظ می شود زیرا داده ها رمزگذاری شده اند.
محدودیت ها
این رویکرد برای رمزگذاری داده های کاربر، بی خطا نیست. این به موضع اعتماد شما برای کاربران شما کمک می کند اما نمی تواند به طور کامل جایگزین آن شود. کاربران شما همچنان باید به خدمات شما اعتماد کنند، زیرا هر لحظه می‌توانید جاوا اسکریپت سمت کلاینت را با جاوا اسکریپتی مشابه که به طور غیرقابل نفوذ داده‌ها را رمزگذاری نمی‌کند، تعویض کنید. و اگرچه به عنوان یک کاربر می توان تشخیص داد که آیا وب سایتی که از آن استفاده می کنید این کار را انجام داده است یا خیر، انجام این کار بسیار دشوار است. در عمل، کاربران شما همچنان باید اعتماد داشته باشند که شما عمداً داده‌های آنها را نخوانید و از آنها سوء استفاده نخواهید کرد و در عین حال قول می‌دهید که این کار را نکنید. با این حال، نشان دادن اینکه داده‌ها رمزگذاری شده‌اند و توسط شما به‌عنوان یک ارائه‌دهنده خدمات (نه مخرب) قابل خواندن نیستند، می‌تواند کمک زیادی به نشان دادن چرایی اعتماد شما کند.
همچنین مهم است که به یاد داشته باشید که یکی از اهداف رمزگذاری سرتاسر این است که شما، مالک سایت، نتوانید داده ها را بخوانید. این برای حفظ حریم خصوصی خوب است، اما همچنین به این معنی است که اگر مشکلی وجود دارد، نمی توانید کمک کنید. در اصل، سرویسی که از رمزگذاری سرتاسر استفاده می کند، کاربر را مسئول کلیدهای رمزگذاری می کند. (این ممکن است آشکار یا آشکار نباشد، اما کسی باید کلید را داشته باشد، و اگر داده ها از شما خصوصی نگه داشته شوند، پس شما نیستید.) اگر آن کلیدها گم شوند، هیچ کمکی نمی توانید انجام دهید، و احتمالاً هرگونه داده رمزگذاری شده با آن کلیدها نیز ممکن است از بین برود. در اینجا تعادل خوبی بین حریم خصوصی و قابلیت استفاده وجود دارد: داده ها را از همه افراد با استفاده از رمزگذاری خصوصی نگه دارید، اما همچنین از مجبور کردن کاربران به متخصصان رمزنگاری که کلیدهای خود را به شیوه ای امن مدیریت می کنند اجتناب کنید.
رمزگذاری در حالت استراحت
علاوه بر رمزگذاری داده های کاربران در حین انتقال، رمزگذاری داده هایی که در سرور ذخیره کرده اید نیز مهم است. این به محافظت در برابر نقض داده‌ها کمک می‌کند، زیرا هر کسی که دسترسی غیرمجاز به داده‌های ذخیره‌شده شما را به دست آورد، داده‌های رمزگذاری شده‌ای خواهد داشت که امیدواریم کلید رمزگشایی را نداشته باشند. دو رویکرد متفاوت و مکمل برای رمزگذاری داده‌ها در حالت استراحت وجود دارد: رمزگذاری که اضافه می‌کنید و رمزگذاری که ارائه‌دهنده ذخیره‌سازی ابری شما اضافه می‌کند (اگر از ارائه‌دهنده ذخیره‌سازی ابری استفاده می‌کنید). رمزگذاری ارائه‌دهنده ذخیره‌سازی محافظت زیادی در برابر نقض داده‌ها از طریق نرم‌افزار شما ارائه نمی‌کند (زیرا رمزگذاری ارائه‌دهنده ذخیره‌سازی معمولاً برای شما به عنوان کاربر سرویس آنها شفاف است)، اما در برابر نقض‌هایی که در زیرساخت ارائه‌دهنده رخ می‌دهد کمک می‌کند. روشن کردن آن اغلب ساده است و بنابراین ارزش بررسی دارد. این زمینه به سرعت تغییر می کند و تیم امنیتی شما (یا مهندسان متبحر در زمینه امنیت در تیم شما) بهترین کسانی هستند که در مورد آن مشاوره می دهند، اما همه ارائه دهندگان فضای ذخیره سازی ابری رمزگذاری را در حالت استراحت برای ذخیره سازی بلوک آمازون S3 با تنظیم، Azure Storage و Google Cloud Storage ارائه می دهند. به طور پیش فرض، و برای ذخیره سازی داده های پایگاه داده AWS RDS ، Azure SQL ، Google Cloud SQL در میان دیگران. اگر از ارائه دهنده فضای ابری خود استفاده می کنید، این را بررسی کنید. مدیریت رمزگذاری داده ها در حالت استراحت برای کمک به محافظت از داده های کاربر در برابر نقض داده ها دشوارتر است، زیرا تدارکات مدیریت ایمن کلیدهای رمزگذاری و در دسترس قرار دادن آنها برای کدگذاری بدون در دسترس قرار دادن آنها برای مهاجمان چالش برانگیز است. این بهترین مکان برای مشاوره در مورد مسائل امنیتی در آن سطح نیست. با مهندسان متبحر امنیتی یا تیم اختصاصی خود در این مورد یا آژانس های امنیتی خارجی صحبت کنید.