کدام اطلاعات شرکت را میتوان در فضای ابری ذخیره کرد؟
کدام اطلاعات شرکت را میتوان در فضای ابری ذخیره کرد؟ شرایط انتقال دادههای حساس، کنترل دسترسی، MFA، Audit Log و روشهای جلوگیری از نشت داده را بررسی کنید.
گزارش آگهی/ فایلهای کاری روزمره، مستندات تیمی و نسخههای در حال ویرایش معمولاً اولین گزینههایی هستند که به فضای ابری منتقل میشوند. اما همین تصمیم وقتی پای اطلاعات مشتریان، اسناد مالی، قراردادها، پروندههای منابع انسانی یا دادههای دارای مالکیت فکری در میان باشد، دیگر ساده نیست.
برای ذخیره اطلاعات شرکت در فضای ابری باید سه موضوع از ابتدا روشن باشد: داده چقدر حساس است؟، چه کسانی باید به آن دسترسی داشته باشند؟ و سرویس ابری چه سطحی از کنترل را در اختیار سازمان میگذارد؟ فایلهای کمحساسیت و همکاری تیمی معمولاً با حساب سازمانی و کنترل دسترسی مناسب قابل انتقالاند. دادههای هویتی، مالی و محرمانه اما فقط زمانی باید وارد Cloud شوند که امکاناتی مثل MFA، رمزنگاری، Audit Log و کنترل Sharing بهدرستی در دسترس باشند.
کدام فایلهای شرکت را با چه شرایطی به فضای ابری منتقل کنیم؟
قبل از انتقال، بهتر است اطلاعات شرکت بر اساس حساسیت دستهبندی شوند؛ اما این طبقهبندی لازم نیست پیچیده باشد. یک فایل ارائه، مستندات یک پروژه داخلی یا گزارشی که چند تیم روی آن کار میکنند، معمولاً ریسک پایینتری دارد. در مقابل، اطلاعات مشتریان، پروندههای منابع انسانی، اسناد مالی و حقوقی یا فایلهای دارای مالکیت فکری به کنترل بیشتری نیاز دارند.
برای این دسته دوم، انتخاب یک سرویس شناختهشده بهتنهایی کافی نیست. باید مشخص باشد چه کسی اجازه مشاهده یا ویرایش دارد، فعالیت کاربران ثبت میشود یا نه، فایل در زمان انتقال و ذخیرهسازی چگونه محافظت میشود و اشتراکگذاری خارج از سازمان تا چه حد قابل محدود کردن است.
چه نوع دادهای را با چه سطح کنترلی منتقل کنیم؟
| وضعیت پیشنهادی | نوع داده |
|---|---|
| قابل انتقال با حساب سازمانی و کنترل دسترسی پایه | مستندات داخلی کمحساسیت و فایلهای همکاری تیمی |
| فقط با MFA، کنترل دسترسی و ثبت فعالیت کاربران | اطلاعات مشتریان و دادههای هویتی |
| با رمزنگاری، Audit Log و محدودیت Sharing | اسناد مالی، حقوقی و منابع انسانی |
| نیازمند کنترل دقیق دسترسی و محدودیت Download | دادههای دارای مالکیت فکری یا پروژههای محرمانه |
| فقط پس از بررسی الزامات فنی، قراردادی و قانونی | دادههای بسیار حساس یا دارای محدودیت قانونی |
این جدول برای تصمیم اولیه است. سطح واقعی کنترل باید با حساسیت همان داده، تعهدات قراردادی و سیاستهای داخلی سازمان هماهنگ شود.
حساب شخصی یا فضای ابری سازمانی؛ چه تفاوتی دارند؟
فرض کنید یکی از کارکنان واحد فروش برای اینکه سریعتر به فایل مشتریان دسترسی داشته باشد، آن را در حساب شخصی خودش ذخیره کرده است. تا زمانی که آن فرد در شرکت کار میکند شاید مسئلهای دیده نشود. مشکل زمانی آشکار میشود که نقش او تغییر کند یا شرکت را ترک کند.
در چنین وضعیتی، سازمان ممکن است نداند چه نسخههایی از فایل باقی مانده، چه کسانی به آن دسترسی دارند یا آیا فایل هنوز روی دستگاههای شخصی کاربر Sync میشود یا نه. فضای ابری سازمانی باید این کنترل را از فرد به سازمان برگرداند. مدیر IT باید بتواند حساب کاربری را غیرفعال کند، سطح دسترسی را تغییر دهد، مالکیت فایلها را حفظ کند و فعالیت کاربران را بررسی کند. برای فایلهای سازمانی، همین تفاوت تعیینکننده است: داده نباید به حساب شخصی یک کارمند وابسته بماند.
سرویس ابری برای نگهداری اطلاعات محرمانه چه امکاناتی باید داشته باشد؟

برای دادههای حساس، نام سرویسدهنده بهتنهایی چیزی درباره سطح کنترل سازمان نمیگوید. مهمتر این است که چه امکاناتی برای مدیریت هویت، رمزنگاری و بررسی رخداد در دسترس است.
رمزنگاری و مدیریت کلید
برای دادههای محرمانه، Encryption at Rest و Encryption in Transit باید جزو حداقلها باشد. در محیطهایی با الزامات سختگیرانهتر، نوع Key Management هم وارد تصمیم میشود. صرف دیدن عبارت «Encrypted» در مشخصات سرویس کافی نیست. باید مشخص باشد کلیدها چگونه مدیریت میشوند و سازمان چه سطحی از کنترل روی آنها دارد.
احراز هویت چندمرحلهای
MFA یکی از کنترلهایی است که میتواند اثر سرقت Credential را محدود کند. اگر رمز عبور یک کاربر در حمله فیشینگ افشا شود، دسترسی به فایلهای حساس نباید فقط به همان رمز وابسته باشد. برای حسابهایی که به دادههای مهم دسترسی دارند، MFA بهتر است از ابتدا بهعنوان Policy سازمانی اعمال شود، نه یک گزینه اختیاری برای کاربر.
Audit Log
ارزش Audit Log معمولاً زمانی مشخص میشود که رخدادی اتفاق افتاده باشد. فرض کنید یک فایل محرمانه از پوشهای Shared شده و تیم IT میخواهد بداند چه کسی لینک را ساخته، فایل چه زمانی Download شده و آیا سطح دسترسی تغییر کرده است. بدون Audit Log، پاسخ به این سؤالها دشوار میشود. برای امنیت اطلاعات در فضای ابری، امکان ثبت و بررسی فعالیت کاربران یکی از پایههای Incident Review است.
کنترل Sharing و Policy
بخشی از نشت اطلاعات نه از یک حمله پیچیده، بلکه از یک اشتباه ساده شروع میشود؛ لینک عمومی ساخته میشود، فایل برای حساب اشتباه ارسال میشود یا دسترسی خارجی بدون تاریخ انقضا باقی میماند. سرویس ابری سازمانی باید به مدیر IT اجازه دهد Sharing خارجی، Download، سطح دسترسی و مدت اعتبار لینکها را محدود کند. این بخش مستقیماً با جلوگیری از نشت داده در فضای ابری ارتباط دارد.
دسترسی کاربران و اشتراکگذاری فایلها را چگونه تنظیم کنیم؟
مشکل معمولاً از جایی شروع میشود که یک پوشه برای پروژهای Share میشود و همان دسترسی ماهها بعد هم باقی میماند. مدیریت دسترسی فقط به این نیست که چه کسی امروز یک فایل را میبیند؛ باید مشخص باشد اگر کاربر تیمش را عوض کرد، پروژه تمام شد یا از سازمان خارج شد، چه اتفاقی برای دسترسی او میافتد.
بهتر است دسترسیها بر اساس Role تعریف شوند. کارمند فروش ممکن است به اطلاعات مشتریان واحد خودش نیاز داشته باشد، اما دلیلی ندارد پوشه قراردادهای منابع انسانی یا حقوق و دستمزد را ببیند. برای Sharing خارجی هم میتوان چند قاعده مشخص داشت: لینک عمومی فقط در صورت نیاز فعال شود، دسترسی خارجی تاریخ انقضا داشته باشد، Edit فقط به افراد لازم داده شود و دسترسیهای قدیمی بهصورت دورهای بازبینی شوند. همین بازبینی دورهای معمولاً یکی از نقاطی است که در عمل فراموش میشود و باعث نشت اطلاعات می شود.
چه زمانی اطلاعات را به فضای ابری منتقل نکنیم؟

اولین مانع میتواند الزام قانونی یا قراردادی باشد. اگر قرارداد مشتری محل نگهداری داده را محدود کرده یا سازمان ملزم به رعایت Data Residency مشخصی است، انتخاب سرویس باید از همین نقطه شروع شود. در بعضی شرایط دیگر هم بهتر است انتقال متوقف شود یا تا رفع ابهام به تعویق بیفتد:
-
مدل Encryption یا Key Management با حساسیت داده همخوان نیست
-
سازمان کنترل کافی روی سطح دسترسی ندارد
-
سرویس حیاتی به اینترنت وابسته میشود اما اتصال پایدار تضمین نشده
-
Recovery Plan مشخصی وجود ندارد
-
خروج داده از سرویس یا تغییر Cloud Provider از قبل طراحی نشده است
Recovery و Exit Strategy دو موضوع متفاوتاند. Recovery برای زمانی است که فایل حذف، خراب یا غیرقابل دسترس شده؛ Exit Strategy برای زمانی است که سازمان بخواهد سرویسدهنده را عوض کند یا داده را به محیط دیگری منتقل کند. اگر هیچکدام از این دو از قبل مشخص نباشند، ریسک اصلی ممکن است نه در زمان ورود به Cloud، بلکه هنگام بحران یا خروج از آن ظاهر شود.
جمعبندی؛ چکلیست تصمیمگیری پیش از انتقال اطلاعات
قبل از انتقال اطلاعات، این پرسشها میتوانند به مشخص شدن ریسکها و کنترلهای موردنیاز کمک کنند:
| اگر پاسخ «خیر» است | سؤال |
|---|---|
| ابتدا اطلاعات را طبقهبندی کنید | آیا سطح حساسیت داده مشخص شده است؟ |
| از حساب شخصی برای فایلهای شرکت استفاده نکنید | آیا فایل در حساب سازمانی نگهداری میشود؟ |
| قبل از انتقال داده حساس آن را فعال کنید | آیا MFA فعال است؟ |
| سطح دسترسی را بازبینی کنید | آیا دسترسی کاربران بر اساس نقش تعریف شده است؟ |
| Policy مشخص برای اشتراکگذاری تعریف کنید | آیا Sharing خارجی قابل کنترل است؟ |
| امکان بررسی فعالیت کاربران را ارزیابی کنید | آیا Audit Log در دسترس است؟ |
| برای بازیابی داده برنامه مشخص داشته باشید | آیا Recovery Plan وجود دارد؟ |
| روش خروج و انتقال داده را قبل از مهاجرت مشخص کنید | آیا Exit Strategy تعریف شده است؟ |
| انتقال را تا تعیین تکلیف متوقف کنید | آیا الزامات قانونی و قراردادی بررسی شدهاند؟ |
تصمیم درست درباره Cloud معمولاً از خود سرویس شروع نمیشود؛ از نوع داده و سطح کنترلی شروع میشود که سازمان واقعاً میتواند روی آن اعمال کند. اگر این دو با هم همخوان باشند، بخش زیادی از اطلاعات شرکت را میتوان با ریسک قابل مدیریت در فضای ابری نگهداری کرد.
اگر سازمان در حال انتقال اطلاعات به فضای ابری است یا میخواهد سیاستهای دسترسی، اشتراکگذاری و حفاظت از داده را بازبینی کند، بهتر است این کنترلها پیش از مهاجرت ارزیابی شوند؛ نه بعد از وقوع یک نشت اطلاعاتی. رادسکیور در حوزه امنیت اطلاعات و حفاظت از دادههای سازمانی میتواند در ارزیابی این کنترلها و انتخاب راهکار متناسب با زیرساخت و سطح ریسک سازمان همراه شما باشد.
انتهای پیام
افزودن دیدگاه جدید