امنیت رایانش ابری چیست؟ چالش‌ ها و راهکارهای حفاظت از داده‌ ها

امنیت رایانش ابری (Cloud Security) مجموعه‌ای از سیاست‌ها، فناوری‌ها و اقدامات برای حفاظت از داده‌ها، برنامه‌ها و زیرساخت‌های ابری در برابر دسترسی غیرمجاز، افشای اطلاعات و اختلال در سرویس‌هاست. این حفاظت به همکاری ارائه‌دهنده خدمات و کاربران وابسته است؛ برای مثال، حتی روی زیرساختی امن، یک تنظیم اشتباه در دسترسی‌های فضای ذخیره‌سازی می‌تواند فایل‌های خصوصی یک کسب‌ وکار را در دسترس عموم قرار دهد.

برای استفاده امن از خدمات ابری، باید بدانید چه خطرهایی اطلاعات و سرویس‌های شما را تهدید می‌کنند و کدام مسئولیت‌های امنیتی بر عهده شماست.

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

در ادامه خواهید خواند:

• امنیت رایانش ابری چیست؟
• اهمیت و مزایای امنیت رایانش ابری
• مسئولیت امنیت در رایانش ابری با چه کسی است؟
• مهم‌ترین تهدیدها و چالش‌های امنیت ابری
• راهکارهای تأمین امنیت رایانش ابری
• چک‌لیست ایمن‌سازی سرویس‌های ابری
• سؤالات متداول
• جمع‌بندی

امنیت رایانش ابری چیست؟

امنیت رایانش ابری یا امنیت ابری (Cloud Security)، بخشی از امنیت سایبری است که به حفاظت از محیط‌های ابری می‌پردازد. دامنه آن، از داده‌های ذخیره‌شده و برنامه‌های در حال اجرا تا حساب‌های کاربری، شبکه و زیرساخت هاست سرویس‌ها را در بر می‌گیرد. مدیریت دسترسی، محافظت از اطلاعات و شناسایی فعالیت‌های مشکوک، همگی در این حوزه قرار می‌گیرند.

رایانش ابری به زبان ساده | هر آنچه که باید درباره Cloud Computing بدانید!
رایانش ابری چیست؟

امنیت در این محیط‌ها، مانند دیگر سیستم‌های اطلاعاتی، سه هدف اصلی دارد:

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

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

اهمیت و مزایای امنیت رایانش ابری

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

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

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

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

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

شناسایی سریع‌ تر تهدیدها و محدودکردن خسارت

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

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

آمادگی بیشتر برای بازیابی و ادامه فعالیت

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

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

همین حالا، فایل‌های خودتون رو در فضایی سریع، پایدار و مقیاس‌پذیر ذخیره کنید.
✅ سازگار با Amazon S3 ✅ عملکرد بالا ✅۲.۵ گیگ فضای رایگان
خرید فضای ذخیره‌سازی ابری

کاهش بخشی از هزینه و بار نگهداری امنیتی

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

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

برای سنجیدن این مزایا در یک سرویس مشخص، ابتدا باید بدانیم ارائه‌دهنده دقیقاً از کدام بخش‌ها محافظت می‌کند و چه مسئولیت‌هایی بر عهده کاربر باقی می‌ماند.

مسئولیت امنیت در رایانش ابری با چه کسی است؟

مسئولیت امنیت در رایانش ابری میان ارائه‌دهنده خدمات و مشتری تقسیم می‌شود. این تقسیم وظایف را مدل مسئولیت مشترک (Shared Responsibility Model) می‌نامند. ارائه‌دهنده از زیرساخت و اجزایی که مدیریت می‌کند محافظت می‌کند و مشتری مسئول استفاده امن از سرویس، مدیریت دسترسی‌ها و تنظیمات تحت کنترل خودش است. محدوده دقیق این وظایف به نوع سرویس و خدمات ارائه‌دهنده بستگی دارد.

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

تقسیم مسئولیت در مدل‌ های IaaS، PaaS و SaaS

تفاوت اصلی این سه مدل در میزان مدیریتی است که ارائه‌دهنده انجام می‌دهد. جدول زیر تقسیم رایج وظایف را نشان می‌دهد؛ جزئیات هر سرویس باید از مستندات همان ارائه‌دهنده بررسی شود.

مدل خدمات ابری	مسئولیت معمول ارائه‌دهنده	مسئولیت معمول مشتری
IaaS؛ زیرساخت به‌عنوان سرویس	امنیت دیتاسنتر، سخت‌افزار، شبکه فیزیکی و لایه مجازی‌سازی	به‌روزرسانی و ایمن‌سازی سیستم‌عامل ماشین مجازی، نرم‌افزارهای نصب‌شده، تنظیمات شبکه مجازی، داده‌ها و دسترسی کاربران
PaaS؛ پلتفرم به‌عنوان سرویس	امنیت زیرساخت، سیستم‌عامل میزبان و اجزای مدیریت‌شده پلتفرم	امنیت کد و وابستگی‌های برنامه، حفاظت از اطلاعات محرمانه، مدیریت داده‌ها و کاربران و تنظیمات برنامه و شبکه‌ای که در اختیار مشتری است
SaaS؛ نرم‌افزار به‌عنوان سرویس	امنیت و به‌روزرسانی نرم‌افزار ارائه‌شده، پلتفرم و زیرساخت میزبان	مدیریت حساب‌ها و مجوزها، تنظیمات امنیتی قابل‌کنترل، نحوه اشتراک‌گذاری اطلاعات و دسترسی سرویس‌های متصل

این تقسیم‌بندی نشان می‌دهد که با تغییر مدل سرویس، بخشی از وظایف فنی جابه‌جا می‌شوند؛ برای نمونه، مدیریت سیستم‌عامل ماشین مجازی در IaaS معمولاً با مشتری است، اما در PaaS مدیریت سیستم‌عامل زیرساخت بر عهده ارائه‌دهنده قرار می‌گیرد.

سرویس ابری چیست؟ بررسی انواع Cloud Services و کاربرد آن‌ها
cloud-as-a-service-چیست؟

یک مثال از مسئولیت مشترک در PaaS

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

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

چگونه مرز مسئولیت‌ ها را مشخص کنیم؟

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

• به‌روزرسانی کدام سیستم‌عامل‌ها و اجزای نرم‌افزاری با ارائه‌دهنده است؟
• پشتیبان‌گیری شامل چه داده‌هایی می‌شود و مسئول درخواست و بررسی بازیابی چه کسی است؟
• چه رویدادهایی ثبت می‌شوند و بررسی هشدارهای امنیتی بر عهده کدام تیم است؟

این بررسی، تقسیم کلی مسئولیت‌ها را به وظایف مشخص برای سرویس شما تبدیل می‌کند. برای مثال، ممکن است تهیه نسخه پشتیبان در خدمات ارائه‌دهنده باشد، اما انتخاب مدت نگهداری یا بررسی کفایت آن برای نیازهای کسب‌وکار همچنان به تصمیم شما نیاز داشته باشد.

مهم‌ ترین تهدیدها و چالش‌ های امنیت ابری

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

پیکربندی نادرست سرویس‌ های ابری

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

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

سرقت حساب‌ ها و دسترسی‌ های بیش‌ ازحد

فیشینگ، افشای رمز عبور یا انتشار کلیدهای دسترسی می‌تواند کنترل یک حساب یا سرویس را در اختیار فرد غیرمجاز قرار دهد. میزان خسارت احتمالی به مجوزهای همان حساب وابسته است؛ هرچه دسترسی گسترده‌تر باشد، منابع بیشتری در معرض سوءاستفاده قرار می‌گیرند.

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

آسیب‌ پذیری برنامه‌ ها و APIها

امنیت برنامه‌ای که روی ابر اجرا می‌شود، به کیفیت کد، وابستگی‌های نرم‌افزاری و نحوه بررسی مجوز درخواست‌ها وابسته است. کتابخانه‌های آسیب‌پذیر یا رابط‌های برنامه‌نویسی ناامن می‌توانند راه دسترسی به اطلاعات را باز کنند؛ حتی زمانی که زیرساخت میزبان به‌درستی نگهداری می‌شود. توسعه ناامن نرم‌افزار و APIهای ناامن نیز از موضوعات مطرح‌شده در گزارش تهدیدهای CSA هستند.

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

محدودیت دید و نظارت بر منابع

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

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

ضعف در جداسازی مشتریان در محیط‌ های چند مستاجری

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

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

حملات منع سرویس توزیع‌ شده یا DDoS

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

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

از دست رفتن داده‌ ها و دشواری بازیابی

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

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

راهکارهای تأمین امنیت رایانش ابری

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

مدیریت هویت و دسترسی با اصل حداقل دسترسی

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

برای اعضای تیم حساب‌های جداگانه تعریف کنید، دسترسی‌های بلااستفاده را بازبینی و حذف کنید و استفاده از حساب مدیریتی را به کارهای نیازمند همان سطح دسترسی محدود کنید. در سرویس‌های پشتیبانی‌کننده، احراز هویت چندعاملی یا MFA را فعال کنید؛ به‌ویژه برای حساب‌هایی که امکان تغییر تنظیمات و مجوزها را دارند.

اگر تیم از چند برنامه استفاده می‌کند، ورود یکپارچه یا SSO می‌تواند مدیریت ورود کاربران را متمرکز کند. در این روش، کاربر با یک بار ورود به برنامه‌های مجاز دسترسی پیدا می‌کند. SSO درباره یکپارچه‌کردن ورود است و تعداد عوامل احراز هویت را تعیین نمی‌کند؛ می‌توان آن را همراه با MFA به کار گرفت.

در لیارا، قابلیت تیم‌ها و دسترسی‌ها امکان دعوت اعضا و تخصیص نقش‌های متفاوت را فراهم می‌کند. با استفاده از این ساختار می‌توانید دسترسی اعضا به پروژه‌ها و سرویس‌ها را متناسب با مسئولیت آن‌ها تنظیم کنید.

اصلاح پیکربندی و محدود کردن دسترسی شبکه

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

در انتخاب ابزار محافظتی، دامنه عملکرد هر ابزار را در نظر بگیرید:

ابزار یا کنترل	کاربرد اصلی
فایروال شبکه و قواعد دسترسی	مجاز یا مسدودکردن ارتباطات بر اساس قواعدی مانند آدرس مبدأ، مقصد، پورت و پروتکل
فایروال برنامه‌های وب یا WAF	بررسی درخواست‌های HTTP و HTTPS و اعمال قواعد برای شناسایی یا مسدودکردن درخواست‌های مخرب
حفاظت در برابر DDoS	کاهش اثر حملاتی که ظرفیت شبکه یا پردازش سرویس را هدف می‌گیرند

این کنترل‌ها می‌توانند مکمل هم باشند. هنگام انتخاب سرویس، بررسی کنید حفاظت ارائه‌شده کدام منابع و چه نوع حملاتی را پوشش می‌دهد؛ صرف وجود عنوان “فایروال” دامنه این حفاظت را مشخص نمی‌کند.

رمزنگاری داده‌ ها و حفاظت از کلیدها

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

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

ایمن‌ سازی برنامه، APIها و اطلاعات محرمانه

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

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

شناسایی اطلاعات حساس و پیشگیری از نشت داده‌ ها

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

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

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

پایش رویدادها و تعیین فرایند پاسخ به حادثه

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

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

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

پشتیبان‌ گیری و آزمایش بازیابی سرویس

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

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

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

آموزش اعضای تیم و بازبینی تغییرات

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

همچنین، تغییرات مهم مانند عمومی‌کردن یک منبع، اعطای نقش مدیریتی یا تغییر قواعد شبکه را ثبت و بررسی کنید. با تغییر اعضای تیم، سرویس‌ها و نیازهای پروژه، مجوزها و تنظیمات امنیتی هم به بازبینی نیاز دارند.

چک‌لیست ایمن‌ سازی سرویس‌ های ابری

پس از اجرای راهکارهای امنیتی، باید بررسی کنید که تنظیمات و فرایندها در عمل هم درست کار می‌کنند. این چک‌لیست برای بررسی پیش از انتشار برنامه و بازبینی پس از تغییرات مهم کاربرد دارد. مقابل هر مورد، وضعیت “تأییدشده”، “نیازمند اصلاح” یا “بررسی‌نشده” را ثبت کنید؛ تأیید هر مورد باید بر اساس مشاهده تنظیمات، گزارش یا نتیجه آزمایش باشد.

مورد بررسی	معیار تأیید
شناخت منابع و مسئولیت‌ها	منابع فعال، داده‌های حساس و مسئول رسیدگی به امنیت هر سرویس مشخص‌اند؛ وظایف مشتری و ارائه‌دهنده نیز بررسی شده‌اند.
حساب‌ها و مجوزهای کاربران	اعضای تیم حساب‌های جداگانه دارند، مجوزها متناسب با وظایف آن‌هاست و حساب‌ها و دسترسی‌های بلااستفاده حذف شده‌اند.
حفاظت از حساب‌های مدیریتی	احراز هویت چندعاملی در سرویس‌های پشتیبانی‌کننده فعال است و استفاده از دسترسی مدیریتی به کارهای نیازمند آن محدود شده است.
دسترسی عمومی و شبکه	منابع قابل‌دسترسی از اینترنت شناسایی شده‌اند و برای عمومی‌بودن هرکدام دلیل مشخصی وجود دارد؛ دسترسی غیرضروری به دیتابیس و پنل‌های مدیریتی بسته است.
امنیت ارتباطات	ارتباطات حساس با TLS برقرار می‌شوند، گواهی‌ها معتبرند و مسئول یا سازوکار تمدید آن‌ها مشخص است.
حفاظت از داده‌های ذخیره‌شده	وضعیت رمزنگاری داده‌های حساس مشخص است و دسترسی به کلیدها و مجوز رمزگشایی بررسی شده است.
رمزها و کلیدهای دسترسی	اطلاعات محرمانه در کد، مخزن و لاگ‌ها قرار ندارند؛ کلیدهای افشاشده یا بلااستفاده لغو شده‌اند.
امنیت برنامه و وابستگی‌ها	نسخه اجزای نرم‌افزاری و آسیب‌پذیری‌های شناخته‌شده مرتبط بررسی شده‌اند و برای اصلاح موارد باقی‌مانده، مسئول و مهلت تعیین شده است.
مجوزهای دسترسی در APIها	آزمون‌ها نشان می‌دهند کاربران فقط به داده‌ها و عملیات مجاز خود دسترسی دارند؛ سناریوهای دسترسی به اطلاعات کاربران دیگر هم بررسی شده‌اند.
اشتراک‌گذاری اطلاعات حساس	افراد مجاز و مقصدهای قابل‌قبول برای انتقال اطلاعات مشخص‌اند و اعضای تیم از این محدودیت‌ها آگاه‌اند.
ثبت رویداد و دریافت هشدار	رویدادهای مهم ثبت می‌شوند، هشدارهای تعریف‌شده آزمایش شده‌اند و فرد مسئول واقعاً آن‌ها را دریافت می‌کند.
پاسخ به حادثه	مسئول بررسی حادثه، مسیر اطلاع‌رسانی و اختیار لازم برای محدودکردن دسترسی یا لغو کلید مشخص است.
حفاظت از نسخه‌های پشتیبان	دامنه داده‌های پشتیبان‌گیری‌شده، تناوب تهیه، مدت نگهداری و مجوزهای مشاهده و حذف نسخه‌ها مشخص و بررسی شده‌اند.
بازیابی عملی سرویس	بازیابی در محیطی جداگانه آزمایش شده و زمان بازگشت سرویس و وضعیت داده‌های بازیابی‌شده ثبت شده است.

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

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

سؤالات متداول

آیا فضای ابری از سرورهای داخل شرکت امن‌ تر است؟

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

آیا امنیت داده‌ها کاملا بر عهده ارائه‌ دهنده خدمات ابری است؟

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

آیا رمزنگاری به‌تنهایی برای حفاظت از داده‌ های ابری کافی است؟

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

تفاوت بک‌ آپ با بازیابی پس از بحران چیست؟

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

کسب‌ و کارهای کوچک برای افزایش امنیت ابری از کجا شروع کنند؟

ابتدا منابع و اطلاعات حساس را شناسایی کنید؛ سپس دسترسی‌های اضافی را حذف کنید، احراز هویت چندعاملی را در سرویس‌های پشتیبانی‌کننده فعال کنید و عمومی‌بودن منابع را بررسی کنید. در کنار این اقدامات، از وجود نسخه پشتیبان قابل‌بازیابی مطمئن شوید. انتخاب ابزارهای پیشرفته‌تر باید متناسب با ریسک پروژه و توان تیم برای مدیریت آن‌ها باشد.

جمع‌ بندی

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

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