کنترل امنیت شماره ۱۳: حفاظت از داده‌ها؛ وقتی فایل مهم‌تر از سرور است

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

مبنای این مطلب: SANS Critical Security Control 13: Data Protection، یعنی «حفاظت از داده‌ها» در فهرست ۲۰ کنترل امنیتی SANS/CIS. متن زیر ترجمه خشک کنترل نیست؛ برداشت عملی از همان کنترل برای شبکه و زیرساخت سازمانی است.

کنترل شماره ۱۳ در SANS/CIS درباره حفاظت از داده‌هاست. یعنی قبل از هر چیز بدانیم چه داده‌ای داریم، کجا نگهداری می‌شود، چه کسی به آن دسترسی دارد، چطور منتقل می‌شود و اگر کپی یا حذف شد از کجا می‌فهمیم.

اول باید داده را پیدا کرد

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

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

دسترسی کمتر، خطر کمتر

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

• دسترسی Read و Write جدا بررسی شود.
• دسترسی‌های قدیمی و ارثی روی Shareها تمیز شوند.
• اکانت‌های سرویس فقط همان مسیر لازم را ببینند.
• دسترسی ادمین به فایل‌های حساس دائمی و بی‌دلیل نباشد.

رمزنگاری فقط برای لپ‌تاپ نیست

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

برای سرویس‌ها هم TLS باید درست پیاده‌سازی شود؛ نه فقط اینکه گواهی داشته باشیم. نسخه‌های قدیمی پروتکل، cipher ضعیف و گواهی‌های تاریخ‌گذشته باید مرتب بررسی شوند.

DLP را با انتظار واقعی اجرا کنیم

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

لاگ و هشدار

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

جمع‌بندی عملی

برای شروع لازم نیست پروژه سنگین تعریف شود. یک لیست از داده‌های حساس، بازبینی دسترسی همان مسیرها، رمزنگاری بکاپ، بستن انتقال‌های ناامن و مانیتور کردن تغییرات مهم می‌تواند ریسک واقعی را خیلی کم کند. حفاظت از داده یعنی قبل از حادثه بدانیم چه چیزی برایمان ارزش دارد.