آیا رمزگذاری هنوز مفید است؟

بله — رمزگذاری هنوز در سال ۲۰۲۶ یکی از مفیدترین کارهایی است که می‌توانید برای محافظت از داده انجام دهید. آنچه عوض شده این است که دیگر نباید آن را طلسمی در برابر هر تهدیدی بدانیم. رمزگذاری مسیر و دیسک را در برابر ناظر میانی و دزد دستگاه قوی می‌کند؛ از گوشی باز، بدافزار روی همان دستگاه، یا کسی که شما را وادار به باز کردن صفحه کند، محافظت نمی‌کند.

پرسش درست این نیست که «آیا رمزگذاری مرده است»؛ پرسش این است که کدام لایه را برای کدام تهدید روشن کرده‌اید و کنارش چه کار دیگری مثل قفل صفحه، به‌روزرسانی و یک پشتیبان آزمایش‌شده مانده است. سه لایه را نباید با هم عوضی گرفت. HTTPS ارتباط تا یک وب‌سایت را رمز می‌کند. رمزگذاری سرتاسری متن را میان دستگاه‌های طرفین نگه می‌دارد تا فراهم‌کننده آن را نخواند. رمزگذاری دیسک پرونده‌ها را روی دستگاه خاموش یا قفل‌شده ناخوانا می‌کند. هر کدام یک سؤال جدا را جواب می‌دهد.

رمزگذاری مسیر چه چیزی را حل می‌کند

وقتی یک وب‌سایت از HTTPS استفاده می‌کند، کسی که در کافه به وای‌فای وصل است به‌راحتی نمی‌تواند محتوای صفحه را بخواند یا آن را در میانه راه عوض کند. قفل کنار نشانی فقط همین را می‌گوید: ارتباط تا همان دامنه رمز شده است. نمی‌گوید سایت مال چه کسی است یا صفحه فریبنده نیست. قبل از وارد کردن رمز، خود نام دامنه را بخوانید.

1. اگر مرورگر دربارهٔ گواهی هشدار می‌دهد، آن را دور نزنید مگر دلیل فنی روشنی داشته باشید که خودتان می‌فهمید.
2. HTTPS را با پیام‌رسان سرتاسری عوضی نگیرید. نامهٔ وبی که قفل دارد تا سرور رمز است؛ صندوق ارائه‌دهنده معمولاً متن را می‌بیند. شرح حساب نامه در راهنمای حساب ایمیل امن‌تر است.
3. گواهی رایگان و خودکار امروز عادی است؛ نبود قفل باید سؤال ایجاد کند. تاریخچهٔ این تغییر در صفحهٔ Let’s Encrypt جدا آمده است.

رمزگذاری سرتاسری گفت‌وگو

وقتی پیام‌رسان در همان حالت گفت‌وگو سرتاسری است، فراهم‌کننده نباید متن را ببیند. این در ۲۰۲۶ همان‌قدر معنا دارد که یک دهه پیش داشت؛ حتی بیشتر، چون بخش بزرگ‌تری از هماهنگی روی همین مسیرها می‌گذرد. انتخاب ابزار و تفاوت حالت‌ها در راهنمای پیام‌رسانی رمزشدهٔ امن‌تر است.

1. قبل از تکیه به یک گپ، ببینید همان گفت‌وگو — نه فقط تبلیغ برنامه — سرتاسری است.
2. مخاطب را از راهی بیرون از همان گپ تأیید کنید اگر موضوع حساس است.
3. پشتیبان ابری را جدا بپرسید؛ بعضی برنامه‌ها متن را سرتاسری می‌کنند و نسخهٔ ابری را نه، مگر تنظیم جداگانه‌ای روشن باشد.
4. فراداده — اینکه چه کسانی با هم حرف می‌زنند — ممکن است بماند. حد و حدود را در راهنمای ناشناسی در ارتباط بخوانید.

رمزگذاری دیسک و دستگاه قفل‌شده

وقتی دیسک با BitLocker یا Device Encryption در ویندوز، FileVault در مک، LUKS در لینوکس، یا رمزگذاری خود گوشی محافظت می‌شود، گم شدن دستگاه خاموش یا قفل به‌معنای خواندن آسان فایل‌ها نیست. این لایه دزد یا کسی که دستگاه را از کیف برمی‌دارد ضعیف می‌کند، به شرطی که صفحه قفل باشد، رمز یا اثر انگشت ضعیف نباشد، و کلید بازیابی جدا مانده باشد. دستگاه روشن و بازشده دیگر از این لایه بهره نمی‌برد.

1. در ویندوز مسیر Settings > Privacy & security را باز کنید و Device encryption یا BitLocker را ببینید. کلید بازیابی را در حساب مایکروسافت تنها محل نگهداری نگذارید اگر همان حساب تنها راه ورود شماست؛ یک رونوشت جدا هم داشته باشید.
2. در مک مسیر System Settings > Privacy & Security > FileVault را روشن کنید و کلید بازیابی را بیرون از همان مک بنویسید.
3. روی گوشی، رمزگذاری معمولاً با گذاشتن قفل صفحه فعال است. قفل ضعیف یا بدون قفل، این لایه را بی‌اثر می‌کند.
4. قبل از فروش دستگاه، رمزگذاری به‌تنهایی کافی نیست؛ پاک‌سازی را جدا انجام دهید.

چرا هنوز بر سر رمزگذاری دعوا هست

بحث‌های مربوط به دسترسی قانونی، اسکن روی خود دستگاه، یا درهای پشتی پیشنهادی برای پیام‌رسان‌ها نشان می‌دهد رمزگذاری هنوز آن‌قدر مؤثر هست که محل نزاع باشد. تا وقتی آن درها در ابزار شما باز نشده، لایهٔ رمزگذاری به کارش ادامه می‌دهد.

این صفحه طرف یک لایحهٔ خاص نیست. نکتهٔ عملی برای شما این است: ابزاری را که می‌گوید «پشت در ما کلید طلایی هست» با ابزاری که متن را فقط روی دستگاه طرفین باز می‌کند یکی ندانید. اگر قانون یا سیاست یک خدمت عوض شد، فرض‌هایتان را همان موقع بازبینی کنید، نه اینکه از همین حالا رمزگذاری را بی‌فایده اعلام کنید.

1. ببینید خدمت مورد استفاده‌تان اعلام کرده متن را می‌خواند، برای ایمنی روی دستگاه اسکن می‌کند، یا کلید را نزد خود نگه می‌دارد.
2. اگر این فرض‌ها با کار حساس‌تان نمی‌خواند، کانال را عوض کنید؛ ناامید شدن از کل رمزگذاری لازم نیست.

چه چیزی را حل نمی‌کند

اگر کسی به جلسهٔ باز شدهٔ شما دسترسی داشته باشد — گوشی بدون قفل روی میز، رایانهٔ روشن، یا نمایهٔ مرورگر باز — رمزگذاری مسیر دیگر کمکی نمی‌کند. داده همان‌جا به زبان روشن دیده می‌شود.

اگر مخاطب پیام را اسکرین‌شات بگیرد یا دستگاهش آلوده باشد، سرتاسری بودن مسیر متن را نجات نمی‌دهد. رمزگذاری قول رفتار انسان مقابل را نمی‌دهد.

بدافزار روی همان دستگاه می‌تواند قبل یا بعد از رمز شدن، صفحه را بخواند، صفحه را ضبط کند یا کلید را از حافظه بردارد. برای تهدید غیرهدفمند راهنمای پاسخ به بدافزار و فیشینگ را ببینید. اسکن خانگی هم برای جاسوس‌افزار خیلی پیشرفته کافی نیست.

اگر کسی بتواند شما را وادار کند صفحه را باز کنید، یا قفل ضعیف را حدس بزند، لایهٔ دیسک در همان لحظه کنار می‌رود. رمزگذاری جایگزین تصمیم دربارهٔ اینکه چه داده‌ای را همراه داشته باشید نیست.

1. قفل صفحه را طوری بگذارید که واقعاً از آن استفاده کنید.
2. دستگاه را در جمع بی‌قفل نگذارید و پیش‌نمایش اعلان روی صفحهٔ قفل را برای برنامه‌های حساس محدود کنید.
3. اگر خطر بازرسی جسمی برایتان واقعی است، دادهٔ همراه را کم کنید؛ رمزگذاری معجزه نمی‌کند.

از دست دادن کلید، داده را برای خودتان هم می‌بندد

اگر کلید بازیابی را گم کنید، همان حفاظ می‌تواند پرونده را برای شما هم ناخوانا کند. این شکست رمزگذاری نیست؛ همان کاری است که برای آن ساخته شده. پس رمزگذاری را همراه قفل صفحه، به‌روزرسانی و پشتیبان قابل بازیابی ببینید، نه به‌جای آن‌ها.

1. کلید بازیابی دیسک، عبارت بازیابی پیام‌رسان یا رمز ظرف را بیرون از همان دستگاه بنویسید.
2. یک‌بار در شرایط آرام باز کردن پشتیبان یا ظرف را آزمایش کنید.
3. کلید را در همان پوشه‌ای که فایل رمزشده است نگذارید.

رمزگذاری خدمت ابری با رمزگذاری روی دستگاه فرق دارد

بسیاری از پوشه‌های ابری می‌گویند داده «رمز شده» است. اغلب یعنی ارتباط تا سرور و ذخیره روی دیسک‌های خودِ خدمت رمز است. آن خدمت در حالت عادی می‌تواند فایل را برای همگام‌سازی و پیش‌نمایش برایتان باز کند. این با ظرفی که کلیدش فقط نزد شماست فرق دارد.

1. قبل از گذاشتن سند حساس در ابر بپرسید آیا کلید فقط نزد شماست یا خدمت هم می‌تواند محتوا را ببیند.
2. اگر کلید نزد شماست، از دست دادنش یعنی خدمت هم نمی‌تواند کمکتان کند. پشتیبان و کلید را جدا آزمایش کنید.
3. اشتراک «هر کسی که پیوند دارد» را با رمزگذاری عوضی نگیرید؛ پیوند خودش یک کلید ضعیف است.

وقتی می‌گویند رمزگذاری شکسته شد

خبر شکستن یک الگوریتم قدیمی یا پیدا شدن ضعف در یک پیاده‌سازی خاص را با بی‌فایده شدن کل رمزگذاری یکی نکنید. بیشتر حادثه‌هایی که مردم با آن روبه‌رو می‌شوند از حدس رمز ضعیف، فیشینگ، دستگاه باز یا پشتیبان بدون رمز می‌آید، نه از شکستن ریاضی AES در خانه.

1. ببینید خبر دربارهٔ کدام لایه است: گواهی یک سایت، پیاده‌سازی یک برنامه، یا خود الگوریتم.
2. اگر برنامهٔ مشخصی باید به‌روز شود، همان را از مسیر رسمی به‌روز کنید؛ همهٔ ابزارها را یک‌شبه رها نکنید.
3. رمز کوتاه و تکراری را عوض کنید. این کار بیشتر از دنبال کردن هر تیتر امنیتی به شما کمک می‌کند.

با مخاطب و با خودتان دربارهٔ حد انتظار حرف بزنید

رمزگذاری وقتی در عمل می‌ماند که هر دو طرف بفهمند چه چیزی پنهان است و چه چیزی نه. اگر یکی گپ را به نامهٔ معمولی رونویسی کند یا روی دستگاه مشترک باز بگذارد، لایه از همان‌جا تمام می‌شود.

1. با مخاطب اصلی یک‌بار بگویید برای مطلب حساس از کدام کانال استفاده می‌کنید.
2. بگویید اسکرین‌شات و دستگاه باز جزء تهدید است تا کسی گمان نکند «چون سرتاسری است پس هر کاری مجاز است».
3. اگر کسی نمی‌تواند همان ابزار را نصب کند، از پیش کانال جایگزین داشته باشید، نه در وسط حادثه.

اشتباه‌های رایج

• گمان اینکه قفل HTTPS یعنی سایت قابل اعتماد است.
• گمان اینکه هر برنامه‌ای که کلمهٔ رمزگذاری را در تبلیغ دارد متن را از فراهم‌کننده پنهان می‌کند.
• روشن کردن رمزگذاری دیسک بدون نگهداری کلید بازیابی.
• رها کردن گوشی باز و تکیه به اینکه «پیام‌ها سرتاسری‌اند».
• اعلام اینکه رمزگذاری دیگر هیچ فایده‌ای ندارد فقط چون بدافزار یا اسکرین‌شات وجود دارد. آن تهدیدها مربوط به لایه‌های کاملاً دیگری هستند و هرگز جای خاموش کردن رمزگذاری نیستند.

از همین امروز چه کار کنید

1. رمزگذاری دیسک دستگاه‌های اصلی را روشن و کلید بازیابی را جدا نگه دارید.
2. برای گفت‌وگوی حساس از پیام‌رسانی استفاده کنید که همان حالتش سرتاسری است و مخاطب را تأیید کنید.
3. قبل از وارد کردن رمز، دامنهٔ HTTPS را بخوانید؛ قفل به‌معنای قابل‌اعتماد بودن سایت نیست.
4. لایه‌های دیگر — قفل صفحه، به‌روزرسانی و تأیید دومرحله‌ای — را کنار رمزگذاری نگه دارید.
5. یک‌بار بازیابی کلید یا پشتیبان رمزشده را در شرایط آرام آزمایش کنید تا خودتان در روز حادثه از دادهٔ خودتان بیرون نمانید.