امنیت در فضای ابری چگونه تامین می‌شود؟ | امنیت فضای ابری

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

مدل مسئولیت مشترک، پایه همه بحث‌ها

قبل از هر ابزار، مدل مسئولیت مشترک (Shared Responsibility Model) را باید فهمید. در این مدل، مسئولیت‌ها بین سرویس‌دهنده و مشتری تقسیم می‌شود، اما مرز تقسیم بسته به نوع سرویس تغییر می‌کند:

نوع سرویس	مسئولیت سرویس‌دهنده	مسئولیت شما
IaaS (زیرساخت به‌عنوان سرویس)	سخت‌افزار، شبکه، مجازی‌ساز	سیستم‌عامل، پیکربندی، داده، دسترسی
PaaS (پلتفرم به‌عنوان سرویس)	سیستم‌عامل، پلتفرم، میان‌افزار	کد، داده، دسترسی کاربران
SaaS (نرم‌افزار به‌عنوان سرویس)	همه‌چیز در سرویس	دسترسی کاربران، داده ورودی

هرچه از IaaS به سمت SaaS می‌رویم، مسئولیت کم می‌شود اما کنترل هم کم می‌شود. مسئله کلیدی این است که حتی در SaaS، سه چیز مسئولیت شماست: مدیریت دسترسی کاربران، انتخاب داده‌ای که وارد می‌کنید و بررسی لاگ‌های سرویس. اگر با مفاهیم کلی ابری آشنایی ندارید، ابتدا رایانش ابری چیست و تفاوت IaaS، PaaS و SaaS را بخوانید تا چارچوب ذهنی روشن شود.

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

لایه اول: مدیریت هویت و دسترسی (IAM)

IAM (Identity and Access Management) مهم‌ترین لایه امنیتی در فضای ابری است. تجربه‌ام می‌گوید بیشتر رخدادهای امنیتی در محیط‌های ابری، از ضعف در همین لایه شروع می‌شود نه از آسیب‌پذیری زیرساخت. شش کار در این لایه:

اصل کم‌ترین دسترسی (Least Privilege): هر کاربر و سرویس، فقط همان دسترسی‌ای را داشته باشد که برای کارش ضروری است. نه بیشتر. این اصل را باید مستمر بازبینی کنید، نه یک بار.
احراز هویت چندعاملی (MFA): روی همه حساب‌های انسانی فعال باشد، به‌خصوص حساب ریشه یا مدیر کل. تحلیل کامل در تأثیر 2FA بر امنیت.
استفاده از نقش (Role) به‌جای کلید ثابت: برای سرویس‌ها از IAM Role یا Service Account استفاده کنید، نه از کلیدهای دسترسی ثابت که در کد یا فایل ذخیره می‌شوند.
چرخه‌بندی منظم کلیدها: اگر مجبور به استفاده از کلید دسترسی هستید، حداکثر هر ۹۰ روز آن را چرخه‌بندی کنید.
بازبینی دوره‌ای: هر سه ماه، فهرست کاربران، نقش‌ها و کلیدها را مرور کنید و موارد بی‌استفاده را حذف کنید. در پروژه‌ها بارها دیده‌ام که دسترسی یک کارمند که ماه‌ها پیش از تیم جدا شده، همچنان باز بود.
ثبت رخدادهای IAM: هر تغییر در نقش‌ها و دسترسی‌ها باید در لاگ ثبت شود و به‌صورت دوره‌ای مرور شود.

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

لایه دوم: ایزوله‌سازی شبکه و VPC

VPC (Virtual Private Cloud) یا معادل‌های آن در سرویس‌های مختلف، محیط شبکه اختصاصی شما در فضای ابری است. سه کار پایه در این لایه:

جدا کردن محیط‌ها در subnetهای متفاوت: محیط production، staging و development هرکدام subnet جدا داشته باشند. اگر یکی از آن‌ها آلوده شود، دیگران تحت تأثیر نباشند.
استفاده از subnet خصوصی برای پایگاه داده و سرویس‌های حساس: پایگاه داده هرگز نباید در subnet عمومی قرار بگیرد. در پروژه‌های واقعی، پایگاه داده‌های ابری که به‌اشتباه در subnet عمومی قرار گرفته‌اند، یکی از شایع‌ترین ریسک‌هاست.
گروه‌های امنیتی هدفمند: در Security Group (یا معادل آن در هر سرویس‌دهنده)، فقط پورت‌ها و IPهای ضروری مجاز باشند. قاعده “Allow all” را حذف کنید.

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

لایه سوم: امنیت ذخیره‌سازی و پایگاه داده

این همان لایه‌ای است که بیشتر نشتی داده‌های ابری از آن شروع می‌شود. سه نکته کلیدی:

باکت‌های ذخیره‌سازی به‌صورت پیش‌فرض خصوصی: باکت‌های ابری (S3 یا معادل‌هایش) باید پیش‌فرض خصوصی باشند. اگر برای محتوای عمومی مثل تصاویر سایت از باکت استفاده می‌کنید، فقط همان مسیرهای مشخص را عمومی کنید، نه کل باکت.
فعال‌سازی ثبت دسترسی به باکت: هر دسترسی به محتوای باکت باید لاگ شود تا اگر مشکلی پیش آمد، مسیر رخداد قابل بازسازی باشد.
پایگاه داده ابری مدیریت‌شده: سرویس‌های پایگاه داده ابری مثل RDS یا Cloud SQL، بخشی از لایه امنیتی را خودشان مدیریت می‌کنند. اما انتخاب پسورد ضعیف، دسترسی عمومی، یا نبود رمزنگاری در حالت سکون همچنان مسئولیت شماست.

مسیر مشابه در محیط‌های وردپرسی با جزئیات در امن‌سازی دیتابیس وردپرس و بهترین روش‌های امنیت MySQL آمده است؛ همان اصول در محیط ابری هم صادق است.

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

رمزنگاری ابری دو بخش دارد و هر دو لازم است:

در حالت سکون (Encryption at Rest): داده‌های ذخیره‌شده روی دیسک و در پایگاه داده، رمزنگاری‌شده باشند. بیشتر سرویس‌های ابری این را به‌عنوان گزینه پیش‌فرض دارند، اما مطمئن شوید فعال است. برای داده‌های بسیار حساس، می‌توانید کلید خودتان را مدیریت کنید (BYOK — Bring Your Own Key).
در حال انتقال (Encryption in Transit): ارتباط بین سرویس‌ها باید با TLS (Transport Layer Security) انجام شود. نه فقط ارتباط کاربر به سایت، بلکه ارتباط سرویس داخلی هم.

مسیر عملی پیاده‌سازی TLS و گواهی در پروژه‌های وردپرسی در نصب SSL و برای API در امن‌سازی API وب آمده است. در محیط ابری، این کار به‌سادگی در سطح load balancer یا API Gateway قابل تنظیم است.

لایه پنجم: مدیریت اسرار و کلیدها

Secrets (اطلاعات حساس مانند رمزها، توکن‌ها و کلیدهای API) یکی از پرخطرترین نقاط در پروژه‌های ابری است. سه قاعده در این لایه:

هیچ رمزی در کد نباشد: نه در کد اپلیکیشن و نه در محیط DevOps. همه اطلاعات حساس در سرویس‌های مدیریت اسرار مثل AWS Secrets Manager، GCP Secret Manager یا HashiCorp Vault نگهداری شوند.
دسترسی به اسرار با نقش محدود: فقط سرویس یا کاربری که به آن اطلاعات نیاز دارد، دسترسی داشته باشد.
گردش خودکار اسرار: سرویس‌های مدیریت اسرار امکان چرخه‌بندی خودکار را می‌دهند؛ استفاده کنید. رمز عبور دیتابیس که سالی یک بار عوض شود، برای سایت حساس کافی نیست.

مفاهیمی که این لایه را در سطح اپلیکیشن هم پوشش می‌دهد در JWT چیست و نوشتن کد PHP امن آمده است.

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

لایه ششم: لاگ، پایش و شناسایی تهدید

بدون لاگ و پایش، نمی‌دانید در محیط ابری شما چه می‌گذرد. سه سطح پایش در محیط ابری:

لاگ فعالیت حساب: هر فراخوانی API، هر تغییر در نقش، هر ورود به کنسول. سرویس‌هایی مثل CloudTrail در AWS یا Cloud Audit Logs در GCP این لایه را پوشش می‌دهند.
لاگ شبکه: ارتباطات بین سرویس‌ها و به بیرون. اگر مهاجمی وارد شود، معمولاً اولین ردپا در همین لاگ‌ها دیده می‌شود.
هشدارهای هوشمند: سرویس‌های SIEM (Security Information and Event Management) یا سرویس‌های ابری اختصاصی مثل GuardDuty یا Security Command Center، الگوهای مشکوک را به‌طور خودکار شناسایی می‌کنند.

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

لایه هفتم: کنترل هزینه به‌عنوان مکانیزم امنیتی

این لایه کمتر شناخته‌شده اما بسیار مؤثر است: افزایش ناگهانی هزینه ابری، یکی از اولین نشانه‌های حمله است. مهاجمان معمولاً منابع را برای استخراج رمزارز (Cryptomining) یا ارسال ایمیل انبوه استفاده می‌کنند که در هزینه ماهانه ظاهر می‌شود. سه کار در این لایه:

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

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

پرسش‌های پرتکرار درباره امنیت فضای ابری

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

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

آیا استفاده از چند سرویس ابری (Multi-Cloud) امنیت را بالا می‌برد؟ نه به‌تنهایی. Multi-Cloud می‌تواند پایداری را بالا ببرد، اما پیچیدگی مدیریت IAM و لاگ را چند برابر می‌کند. برای بیشتر پروژه‌ها، تمرکز روی یک ابر با پیکربندی امن، از پخش شدن روی چند ابر بهتر است.

آیا استفاده از سرویس‌های سرورلس امن‌تر است؟ نه ذاتاً. Serverless بخشی از مسئولیت سیستم‌عامل را از دوش شما برمی‌دارد، اما لایه کد، دسترسی و IAM کاملاً روی دوش شماست. اگر کد شما آسیب‌پذیر باشد، سرورلس هم نجات‌بخش نیست.

چگونه مطمئن شوم پیکربندی امن است؟ از ابزارهای CSPM (Cloud Security Posture Management) استفاده کنید. این ابزارها پیکربندی حساب ابری شما را با استانداردهای امنیتی مقایسه می‌کنند و نقاط ضعف را نشان می‌دهند. اکثر سرویس‌دهندگان نسخه اولیه این ابزار را در کنسول خود دارند.

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

امنیت ابری به‌اندازه پیکربندی شما امن است

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