حفاظت از اطلاعات سایت و امنیت اطلاعات کاربران

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

طبقه‌بندی و حداقل‌سازی داده

بدون طبقه‌بندی، هر تصمیم امنیتی دیگری بی‌مبنا است — چون نمی‌دانید کدام داده ارزش کدام سطح از محافظت را دارد. OWASP در A04:2025 خطاهای رمزنگاری نخستین توصیه‌اش همین است: داده را طبقه‌بندی کنید، سپس رمزنگاری در حال سکون و انتقال را الزامی کنید.

یک طبقه‌بندی کاربردی

حداقل‌سازی در عمل

• هر فیلد فرم را زیر سؤال ببرید: بدون آن کدام قابلیت کار نمی‌کند؟ «کد ملی» در فرم ثبت‌نام یک فروشگاه معمولاً کاربرد عملیاتی ندارد و فقط ریسک اضافه می‌کند.
• داده‌ی کامل را با داده‌ی مشتق جایگزین کنید. اگر برای بررسی سن نیاز دارید، «بالای ۱۸ سال: بله/خیر» را ذخیره کنید نه تاریخ تولد کامل.
• داده را در محیط‌های غیرتولیدی کپی نکنید. دامپ تولید در محیط توسعه یکی از رایج‌ترین راه‌های نشت است؛ داده را بی‌هویت یا ساختگی کنید.

رمزنگاری در حال انتقال و در حال سکون

در حال انتقال

• HTTPS برای همه‌ی مسیرها، بدون استثنا. یک اندپوینت HTTP کافی است تا کوکی نشست در مسیر شنود شود — سناریوی اول A04:2025 دقیقاً همین است.
• TLS 1.3 فعال؛ TLS 1.2 فقط برای سازگاری و فقط با ECDHE + AEAD. طبق RFC 10015 (جولای ۲۰۲۶) مجموعه‌سایفرهای RSA ایستا و همه‌ی FFDH/FFDHE در TLS 1.2 منسوخ شده‌اند. TLS 1.0 و 1.1 طبق RFC 8996 غیرفعال.
• ارتباطات داخلی را هم رمزنگاری کنید: اتصال به پایگاه‌داده، کش، صف پیام و بین سرویس‌ها. فرض «شبکه‌ی داخلی امن است» درست نیست.
• HSTS تا مرورگر هرگز به HTTP برنگردد، و کوکی‌ها با Secure و HttpOnly.
• هرگز راستی‌آزمایی گواهی را در کد سمت سرور غیرفعال نکنید. این کار رمزنگاری را به یک نمایش تبدیل می‌کند و در CWE-297 دسته‌بندی می‌شود.

در حال سکون

• رمزنگاری در سطح دیسک یا پایگاه‌داده پایه است، اما محدودیتش را بدانید: در برابر سرقت فیزیکی محافظت می‌کند، نه در برابر تزریق SQL — چون برنامه‌ی مجاز داده را رمزگشایی‌شده می‌بیند.
• رمزنگاری در سطح فیلد برای داده‌ی حساس‌تر (اسناد هویتی، داده‌ی سلامت). این لایه است که در برابر افشای پایگاه‌داده معنا دارد.
• مدیریت کلید جدی‌ترین بخش ماجراست: کلیدی که کنار داده‌ی رمزشده نگه داشته شود بی‌ارزش است. OWASP نگهداری کلید در HSM یا سرویس مدیریت کلید را توصیه می‌کند.
• بکاپ‌ها را رمزنگاری کنید — بکاپ رمزنشده روی فضای ذخیره‌سازی با دسترسی باز، رایج‌ترین شکل «رخنه بدون نفوذ» است.
• الگوریتم‌های منسوخ را کنار بگذارید. OWASP در A04:2025 صریحاً MD5 و SHA-1 را نام می‌برد. همچنین توصیه می‌کند سازمان‌ها برای رمزنگاری پساکوانتومی تا سال ۲۰۳۰ آماده شوند — یعنی امروز بدانید کجا از رمزنگاری نامتقارن استفاده می‌کنید و چقدر تعویضش سخت است.
• برای توکن، شناسه‌ی نشست و کد بازنشانی از مولد تصادفی رمزنگاری‌شده استفاده کنید؛ مولد معمولی زبان مناسب نیست (CWE-338).

ذخیره‌سازی درست رمز عبور

سناریوی دوم OWASP در A04:2025 یک هشدار مستقیم است: پایگاه‌داده‌ی رمزهای عبور با هش بدون نمک افشا می‌شود و با جدول رنگین‌کمانی و شتاب‌دهی GPU شکسته می‌شود. تفکیک مفاهیم اینجا حیاتی است.

سه مفهوم که با هم اشتباه می‌شوند

• رمزنگاری برگشت‌پذیر است. رمز عبور نباید رمزنگاری شود، چون هر کسی که کلید را دارد آن را برمی‌گرداند.
• هش عمومی سریع است. MD5، SHA-1 و حتی SHA-256 برای سرعت طراحی شده‌اند — و همان سرعت به مهاجم اجازه می‌دهد میلیاردها حدس در ثانیه با GPU امتحان کند. هش عمومی برای رمز عبور نامناسب است.
• تابع مشتق کلید (KDF) عمداً کند و پرمصرف است. این همان چیزی است که رمز عبور لازم دارد.

توصیه‌ی درست

• Argon2 — انتخاب توصیه‌شده در A04:2025. با نمک یکتا برای هر کاربر، و پارامترهای حافظه و تکرار متناسب با توان سرور شما.
• نمک باید یکتا و تصادفی باشد و کنار هش ذخیره شود؛ نمک راز نیست، هدفش شکستن جدول‌های پیش‌محاسبه است.
• سیاست رمز هم‌راستا با NIST SP 800-63B: طول کافی مهم‌تر از قواعد پیچیدگی است، رمزهای جدید را در برابر مجموعه‌های فاش‌شده بررسی کنید، و تعویض دوره‌ای اجباری را حذف کنید.
• MFA اضافه کنید — حتی هش شکسته‌شده هم به ورود منجر نمی‌شود — و ورودهای ناموفق را نرخ‌بندی کنید.

// PHP — الگوریتم و نمک را خودتان دست‌کاری نکنید
$hash = password_hash( $password, PASSWORD_ARGON2ID );
if ( password_verify( $input, $hash ) ) { /* ورود موفق */ }

مدیریت اسرار: نه در مخزن، نه در کلاینت

اسرار — کلید API، رمز پایگاه‌داده، کلید امضا، توکن سرویس — ارزشمندترین داده‌ی سیستم شما هستند، چون هر یک دسترسی به داده‌ی بیشتری می‌دهد. OWASP این حوزه را در A06:2025 با CWE-256 (ذخیره‌سازی محافظت‌نشده‌ی اعتبارنامه) و CWE-522 (اعتبارنامه‌ی با محافظت ناکافی) و در A07:2025 با CWE-798 (اعتبارنامه‌ی سخت‌کدشده) پوشش می‌دهد.

قواعد بی‌قید و شرط

• هیچ رازی در مخزن کد نباشد. فایل‌های محیطی در .gitignore، و اسرار از متغیر محیطی یا سرویس مدیریت راز خوانده شوند.
• رازی که یک بار کامیت شده، افشاشده است. حذف در کامیت بعدی آن را از تاریخ مخزن پاک نمی‌کند. چرخش کلید تنها پاسخ درست است.
• هیچ رازی در سورس سمت کلاینت نباشد. کلید API در جاوااسکریپت، کلید عمومی است. مبهم‌سازی و base64 محافظت نیستند. اگر کلیدی باید محرمانه بماند، فراخوانی از سمت سرور انجام شود.
• اعتبارنامه‌ی سخت‌کدشده در کد ممنوع — حتی «موقت» و حتی در تست.
• هر راز باید قابل چرخش باشد. اگر چرخاندن یک کلید نیازمند تغییر کد و استقرار جدید است، در لحظه‌ی حادثه چرخش انجام نمی‌شود.
• اسکن اسرار را در CI خودکار کنید تا کامیت حاوی راز قبل از ادغام گرفته شود.

یکپارچگی و امضا

A08:2025 نقص یکپارچگی نرم‌افزار یا داده نکته‌ی مکملی اضافه می‌کند: داده‌ای که از مرز اعتماد عبور می‌کند باید راستی‌آزمایی شود. اگر وضعیتی را به کلاینت می‌سپارید و بعد پس می‌گیرید — توکن، پارامتر امضاشده، کوکی حاوی داده — یکپارچگی‌اش را با امضا یا HMAC بررسی کنید و هرگز به داده‌ی سریال‌شده‌ی تحت کنترل کاربر اعتماد نکنید. سازوکار سوءاستفاده از این حالت در Deserialization ناامن آمده است.

کنترل دسترسی و حداقل دسترسی روی پایگاه‌داده

رمزنگاری از داده در برابر مهاجم بیرونی محافظت می‌کند؛ کنترل دسترسی از داده در برابر دسترسی مجاز اما بی‌ضرورت محافظت می‌کند. دومی در عمل شایع‌تر است.

در سطح برنامه

• رد پیش‌فرض و بررسی مجوز در سمت سرور برای هر درخواست. A01:2025 کنترل دسترسی شکسته رتبه‌ی یک است و OWASP گزارش می‌کند در ۱۰۰٪ برنامه‌های آزموده‌شده نوعی از آن وجود داشته.
• مالکیت را در لایه‌ی داده اعمال کنید (WHERE id = ? AND owner_id = ?) نه با یک بررسی جداگانه‌ی بعدی. این کار IDOR را ساختاراً حذف می‌کند.
• در پاسخ API فقط فیلدهای لازم را برگردانید؛ پنهان کردن فیلدها در رابط کاربری افشای داده را رفع نمی‌کند، چون پاسخ خام قابل مشاهده است.
• دسترسی کارمندان را با نقش و بر پایه‌ی ضرورت شغلی تعریف کنید و دسترسی به داده‌ی شخصی را لاگ کنید. Honeytoken — یک رکورد ساختگی که هیچ استفاده‌ی مشروعی ندارد — روش مؤثری برای تشخیص دسترسی غیرمجاز است و OWASP آن را در A09:2025 توصیه می‌کند.

در سطح پایگاه‌داده

• کاربر برنامه نباید سطح ریشه داشته باشد. بدون دسترسی DDL در تولید، بدون دسترسی خواندن/نوشتن فایل، بدون قابلیت اجرای دستور سیستم. این تنها چیزی است که یک تزریق SQL را از تبدیل شدن به اجرای کد روی سرور بازمی‌دارد.
• کاربران مجزا برای وظایف مجزا (گزارش‌گیری فقط خواندن) و پایگاه‌داده نباید از اینترنت قابل دسترسی باشد — این را دوره‌ای بازبینی کنید.
• فضای ذخیره‌سازی ابری و باکت‌ها را بازبینی کنید. باکت با دسترسی عمومی یکی از سناریوهای صریح A02:2025 است و بسیاری از افشاهای بزرگ داده از همین‌جا آمده‌اند.

بهداشت لاگ: CWE-532 و CWE-117

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

CWE-532 — درج اطلاعات حساس در فایل لاگ

لاگ‌ها معمولاً کنترل دسترسی ضعیف‌تری از پایگاه‌داده دارند: به سرویس پایش ارسال می‌شوند، در بکاپ کپی می‌شوند، توسعه‌دهندگان به آن‌ها دسترسی دارند، و مدت‌ها نگه داشته می‌شوند. آنچه هرگز نباید در لاگ باشد:

• رمز عبور، حتی در لاگ خطای فرم ورود.
• توکن نشست، توکن API، کلید، و کد یک‌بارمصرف.
• داده‌ی کارت بانکی، به‌هیچ شکل.
• بدنه‌ی کامل درخواست‌های حاوی داده‌ی شخصی — لاگ کامل بدنه در محیط تولید یکی از رایج‌ترین اشتباهات است.
• پارامترهای URL که ممکن است توکن داشته باشند — به همین دلیل توکن هرگز نباید در query string باشد.

CWE-117 — تزریق به لاگ

اگر ورودی کاربر خام در لاگ نوشته شود، مهاجم می‌تواند با درج کاراکترهای خط جدید، رکورد لاگ جعلی بسازد. نتیجه: تحلیل حادثه گمراه می‌شود، و اگر لاگ در یک داشبورد HTML نمایش داده شود، می‌تواند به اجرای اسکریپت در مرورگر تحلیل‌گر منجر شود. توصیه‌ی OWASP صریح است: خروجی لاگ را کدگذاری کنید. استفاده از لاگ ساختاریافته (مثلاً JSON) با فیلدهای مقداردهی‌شده به‌جای رشته‌ی الحاقی، این مسئله را در ریشه حل می‌کند.

سایر اصول

• مسیر ممیزی فقط-افزودنی با حفاظت یکپارچگی، تا مهاجم نتواند رد خود را پاک کند.
• لاگ‌ها را به یک مقصد مستقل هم ارسال کنید، چون اولین کار مهاجم پاک کردن لاگ محلی است. عمق نگهداری کافی داشته باشید — و در مقابل، سیاست حذف، چون لاگِ حاوی داده‌ی شخصی هم مشمول قواعد نگهداری است.

سیاست نگهداری، حذف و ریسک شخص ثالث

نگهداری و حذف

داده‌ای که برای همیشه نگه داشته می‌شود، ریسکی است که هرگز تمام نمی‌شود. یک سیاست کاربردی سه چیز را برای هر دسته‌ی داده مشخص می‌کند: چه مدت نگه داشته می‌شود، بر چه مبنایی (نیاز عملیاتی یا الزام قانونی)، و چگونه حذف می‌شود.

• حذف واقعی در برابر حذف نرم: پرچم deleted=1 حذف نیست؛ برای داده‌ی شخصی باید مسیر حذف واقعی وجود داشته باشد.
• حذف را در همه‌ی نسخه‌ها اعمال کنید: پایگاه‌داده، کش، فایل‌های آپلودی، ایندکس جست‌وجو، سرویس‌های تحلیلی، بکاپ‌ها، و لاگ‌ها — اگر داده‌ی شخصی در لاگ است، سیاست نگهداری لاگ هم بخشی از سیاست داده است.

ریسک شخص ثالث و پردازنده‌ها

هر سرویسی که داده‌ی شما را می‌بیند، بخشی از سطح حمله‌ی شماست. OWASP در A08:2025 مثال روشنی می‌آورد: سازش زیرساخت DNS یا CDN یک تأمین‌کننده‌ی پشتیبانی، به مهاجم اجازه‌ی خواندن کوکی‌های احراز هویت را داد.

• فهرست پردازنده‌های خود را بسازید: چه سرویسی، چه داده‌ای، چه سطحی از دسترسی، و در کجا میزبانی می‌شود.
• اسکریپت‌های شخص ثالث را از صفحات حساس حذف کنید. ابزار تحلیلی، چت آنلاین و پیکسل تبلیغاتی روی صفحه‌ی پرداخت یا ورود، امکان خواندن ورودی کاربر را دارند.
• CSP و CORS را درست پیکربندی کنید. در CORS، الگوی خطرناک بازتاب Origin همراه با Access-Control-Allow-Credentials: true است — این یعنی هر سایتی می‌تواند داده‌ی احراز هویت‌شده‌ی کاربر شما را بخواند.
• وابستگی‌های نرم‌افزاری را هم پردازنده بدانید؛ کتابخانه‌ای که در کلاینت اجرا می‌شود به تمام داده‌ی فرم دسترسی دارد (A03:2025).

آمادگی برای رخنه و اطلاع‌رسانی

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

1. نقشه‌ی داده. چه داده‌ای دارید، در کدام سیستم‌ها، و در چه بکاپ‌هایی. بدون این، پاسخ «چه چیزی افشا شد» غیرممکن است — و همین سؤال است که همه از شما می‌پرسند.
2. لاگ با عمق کافی و در مکان مستقل. بدون لاگ نمی‌توانید دامنه‌ی دسترسی را تعیین کنید، و در آن حالت باید بدترین حالت را فرض کنید.
3. فهرست تماس و نقش‌ها: چه کسی تصمیم می‌گیرد، با میزبان و درگاه تماس می‌گیرد، و با کاربران صحبت می‌کند.
4. روش ابطال سریع: باطل کردن همه‌ی نشست‌ها، چرخش همه‌ی کلیدها، بازنشانی اجباری رمزها. اگر این کارها نیازمند تغییر کد باشند، در لحظه انجام نمی‌شوند.
5. سیاست اطلاع‌رسانی. GDPR برای سازمان‌هایی که داده‌ی کاربران اروپایی را پردازش می‌کنند تعهد اطلاع‌رسانی رخنه دارد و PCI DSS الزامات خودش را دارد. مستقل از الزام قانونی، اطلاع‌رسانی صادقانه و سریع تقریباً همیشه کم‌هزینه‌تر از پنهان‌کاری است.
6. سناریوهای پایش با کتابچه‌ی پاسخ متناظر — OWASP در A09:2025 همین را توصیه می‌کند؛ هشدار بدون کتابچه‌ی پاسخ فقط یک اعلان است.

در لحظه‌ی حادثه

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

پرسش‌های متداول

WRITTEN BY

علیرضا کیا

کارشناس وب و موبایل

متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.

LinkedIn ↗درباره تیم ←