در محیط‌های ابری، یک تغییر کوچک در Permission، تنظیمات شبکه یا Policy یک سرویس می‌تواند سطح دسترسی منابع را تغییر دهد. بنابراین امنیت Cloud فقط به به‌روز بودن نرم‌افزارها یا استفاده از ابزارهای امنیتی وابسته نیست؛ پیکربندی صحیح منابع و کنترل مداوم تغییرات نیز بخش مهمی از امنیت زیرساخت ابری است.
این مسئله زمانی جدی‌تر می‌شود که منابع Cloud دائماً ایجاد و تغییر کنند. در چنین شرایطی، تنظیمی که هنگام استقرار صحیح بوده، ممکن است بعداً تغییر کند و Resource را از وضعیت امنیتی مورد انتظار خارج کند.
پیکربندی نادرست فضای ابری چیست؟
پیکربندی نادرست فضای ابری یا Cloud Misconfiguration زمانی رخ می‌دهد که تنظیمات یک منبع یا سرویس ابری با الزامات امنیتی یا سطح دسترسی موردنیاز سازمان مطابقت نداشته باشد. این خطا الزاماً یک آسیب‌پذیری نرم‌افزاری نیست. برای مثال، یک سرویس کاملاً به‌روز ممکن است به دلیل Permission اشتباه، بیش از حد موردنیاز در دسترس قرار گرفته باشد. مهم‌ترین حوزه‌های بروز Misconfiguration عبارت‌اند از:
- هویت و دسترسی
- Storage و پایگاه‌های داده
- شبکه و دسترسی اینترنتی
- Key و Secret
- Logging
- تنظیمات سرویس‌ها و Infrastructure as Code
یکی از چالش‌های مهم نیز Configuration Drift است؛ یعنی وضعیت واقعی یک Resource به‌مرور از تنظیمات استاندارد و مورد انتظار سازمان فاصله بگیرد.
مهم‌ترین خطاهای پیکربندی در محیط‌های ابری
عمومی‌کردن ناخواسته مخازن ذخیره‌سازی ابری
قرار گرفتن یک Storage در معرض دسترسی عمومی، یکی از شناخته‌شده‌ترین نمونه‌های Misconfiguration است. اما بررسی آن نباید فقط به یک گزینه Public محدود شود. برای مثال، در Amazon S3، تنظیمات دسترسی عمومی می‌تواند تحت تأثیر Bucket Policy، Access Point و تنظیمات سطوح بالاتر قرار گیرد. بنابراین باید مشخص شود آیا دسترسی عمومی واقعاً ضروری است یا می‌توان دسترسی را به کاربران، سرویس‌ها یا شبکه‌های مشخص محدود کرد.
تعریف نقش‌ها و مجوزهای گسترده‌تر از نیاز کاربران
Role، Group، Service Account و Managed Identity می‌توانند سطح دسترسی کاربران و سرویس‌ها را تعیین کنند. یکی از خطاهای رایج، اعطای مجوزی بیشتر از نیاز واقعی است؛ برای مثال دسترسی کامل به یک Storage برای سرویسی که فقط باید چند فایل را بخواند. اصل Least Privilege باید برای کاربران و سرویس‌ها اعمال شود. همچنین دسترسی‌های مستقیم و غیرمستقیم باید بررسی شوند؛ زیرا ممکن است یک کاربر از طریق Group یا Role دیگری همچنان همان مجوز را داشته باشد.
باز بودن یک پورت به‌تنهایی به معنای وجود آسیب‌پذیری نیست؛ مسئله زمانی جدی‌تر می‌شود که سرویسی بدون نیاز واقعی از اینترنت قابل دسترسی باشد یا Rule شبکه محدوده‌ای بزرگ‌تر از نیاز واقعی را مجاز کند. در بررسی تنظیمات شبکه باید مشخص شود:
- کدام سرویس‌ها واقعاً به دسترسی اینترنتی نیاز دارند؟
- دسترسی مدیریتی از چه مبدأهایی مجاز است؟
- آیا پورت‌های غیرضروری باز هستند؟
- آیا Ruleها به محدوده مشخصی از IP یا Network محدود شده‌اند؟
مدیریت نادرست کلیدهای رمزنگاری و اطلاعات محرمانه
Key، API Token، Password و سایر Secretها باید در محل مناسب نگهداری و چرخه عمر آن‌ها مدیریت شود. قرار دادن Secret در Source Code، Repository یا فایل‌های Configuration می‌تواند دسترسی به آن را فراتر از افراد یا سرویس‌های موردنیاز گسترش دهد. برای ارزیابی این بخش باید مشخص شود:
- Secretها کجا نگهداری می‌شوند؟
- چه هویت‌هایی به آن‌ها دسترسی دارند؟
- آیا امکان Rotation وجود دارد؟
- آیا استفاده از آن‌ها قابل ردیابی است؟
باقی‌گذاشتن تنظیمات پیش‌فرض و سرویس‌های غیرضروری
تنظیمات اولیه یک سرویس Cloud لزوماً با نیاز امنیتی سازمان مطابقت ندارد. همچنین سرویس‌هایی که برای آزمایش یا مهاجرت فعال شده‌اند ممکن است بدون نیاز واقعی در محیط عملیاتی باقی بمانند. پیش از استقرار باید تنظیمات سرویس با یک Baseline امنیتی مقایسه شود و قابلیت‌ها یا سرویس‌های غیرضروری حذف یا غیرفعال شوند. CIS Benchmarks می‌توانند یکی از منابع ایجاد این Baseline برای سرویس‌ها و پلتفرم‌های مختلف باشند.
غیرفعال‌کردن یا پیکربندی ناقص لاگ‌های ابری
اگر تغییرات مهم Cloud ثبت نشوند، مشخص‌کردن اینکه چه کسی و چه زمانی یک Configuration را تغییر داده دشوار خواهد بود. باید رویدادهای مهم، به‌خصوص تغییرات مربوط به Permission، Network Rule و تنظیمات حساس، ثبت شوند. علاوه بر فعال‌بودن Logging، محل نگهداری، مدت نگهداری و سطح دسترسی به لاگ‌ها نیز باید مشخص باشد.
چگونه خطاهای پیکربندی ابری را پیش از وقوع حادثه شناسایی کنیم؟
بررسی دستی Configuration در محیط‌های کوچک ممکن است کافی باشد، اما با افزایش تعداد منابع و سرویس‌ها، کنترل مداوم آن‌ها دشوارتر می‌شود. راهکار مؤثر، تعریف یک Baseline قابل‌اندازه‌گیری و مقایسه مداوم وضعیت واقعی Cloud با آن است:
تعریف Baseline → بررسی Configuration واقعی → شناسایی انحراف → اصلاح
برای مثال، می‌توان مشخص کرد که Storageهای مشخص نباید Public باشند، دسترسی مدیریتی باید محدود شود و منابع خاصی باید Encryption داشته باشند. در محیط‌های بزرگ‌تر، ابزارهای CSPM می‌توانند این بررسی‌ها را به‌صورت خودکار انجام دهند و Configurationهایی را که با Policyهای تعریف‌شده مطابقت ندارند، شناسایی کنند. نکته مهم این است که هدف فقط پیدا کردن خطای فعلی نیست. باید مشخص شود چه تغییری باعث ایجاد آن شده و آیا احتمال تکرار آن وجود دارد یا نه.
چگونه از تغییرات ناخواسته در پیکربندی فضای ابری جلوگیری کنیم؟
شناسایی خطا کافی نیست. اگر همان Configuration اشتباه دوباره از طریق یک Template یا تغییر دستی ایجاد شود، مشکل تکرار خواهد شد.
استفاده از Infrastructure as Code
در Infrastructure as Code یا IaC، تنظیمات زیرساخت در قالب کد یا Template تعریف می‌شوند. در نتیجه می‌توان Configuration را قبل از استقرار بررسی کرد. مزیت مهم این روش این است که اگر یک تنظیم ناامن در Template وجود داشته باشد، می‌توان آن را در منبع اصلی اصلاح کرد تا Resourceهای بعدی نیز با همان خطا ایجاد نشوند.
استفاده از Policy-as-Code
در Policy-as-Code، الزامات امنیتی به شکل Policy قابل‌اجرا تعریف می‌شوند. برای مثال می‌توان ایجاد Resource بدون Encryption مشخص یا دسترسی عمومی غیرمجاز را شناسایی یا محدود کرد. قرار دادن این Policyها در فرایند CI/CD باعث می‌شود بخشی از خطاها پیش از ورود Resource به محیط Production شناسایی شوند.
محدودکردن تغییرات مستقیم در Production
تغییرات حساس بهتر است از مسیر مشخصی مانند Repository، Review و Pipeline عبور کنند. این روش باعث می‌شود تغییرات قابل ردیابی باشند و در صورت ایجاد Configuration ناامن، بتوان منبع تغییر را مشخص کرد. در عمل، یک رویکرد مؤثر برای جلوگیری از تکرار خطا این است:
Configuration در IaC تعریف شود → Policy پیش از استقرار بررسی شود → تغییرات Production کنترل شوند → وضعیت واقعی Cloud به‌صورت مستمر پایش شود.
چک‌لیست امنیتی پیکربندی منابع ابری پیش از استقرار
هویت و دسترسی
- آیا Role و Permission فقط سطح دسترسی موردنیاز را ارائه می‌کنند؟
- آیا دسترسی‌های مستقیم و غیرمستقیم بررسی شده‌اند؟
- آیا دسترسی مدیریتی محدود شده است؟
Storage و داده
- آیا Resource به‌صورت ناخواسته Public نیست؟
- آیا دسترسی خارجی فقط در موارد ضروری فعال شده است؟
- آیا داده‌های حساس تحت کنترل‌های امنیتی موردنیاز قرار دارند؟
شبکه
- آیا پورت‌های غیرضروری بسته هستند؟
- آیا Ruleهای ورودی و خروجی محدود به محدوده موردنیازند؟
- آیا سرویس‌های مدیریتی مستقیماً در معرض اینترنت نیستند؟
Key و Secret
- آیا Secretها خارج از Source Code نگهداری می‌شوند؟
- آیا دسترسی به Key و Secret محدود شده است؟
- آیا Rotation برای اعتبارنامه‌های حساس پیش‌بینی شده است؟
Logging و استقرار
- آیا تغییرات مهم Configuration ثبت می‌شوند؟
- آیا Templateها پیش از استقرار بررسی می‌شوند؟
- آیا Configuration Drift قابل شناسایی است؟
از کجا شروع کنیم؟
اگر سازمان شما منابع Cloud متعددی دارد، لازم نیست تمام تنظیمات را هم‌زمان بررسی کنید. می‌توان کار را با منابعی شروع کرد که داده حساس، دسترسی اینترنتی یا سطح دسترسی بالا دارند. یک مسیر اجرایی ساده می‌تواند این باشد:
- منابع حساس را مشخص کنید.
- برای هر دسته، Baseline امنیتی تعریف کنید.
- Configuration فعلی را با Baseline مقایسه کنید.
- خطاهای با ریسک بالاتر را اصلاح کنید.
- Policyهای امنیتی را وارد فرایند استقرار کنید.
- Configuration Drift را به‌صورت مستمر پایش کنید.
این رویکرد باعث می‌شود امنیت Cloud از یک بررسی مقطعی به یک فرایند قابل‌کنترل تبدیل شود.
جمع‌بندی؛ ضرورت پایش مستمر تنظیمات فضای ابری
امنیت پیکربندی Cloud یک اقدام یک‌باره نیست. منابع، Permissionها و سرویس‌ها در طول زمان تغییر می‌کنند و همین تغییرات می‌توانند Configuration را از وضعیت استاندارد خارج کنند. به همین دلیل، سازمان باید در کنار Baseline امنیتی و پایش مداوم Configuration از روش‌هایی مانند CSPM، Infrastructure as Code و Policy-as-Code استفاده کند.
هدف فقط پیدا کردن یک Storage عمومی یا یک پورت باز نیست؛ بلکه باید فرایندی وجود داشته باشد که پیکربندی ناامن را پیش از استقرار شناسایی کند، تغییرات ناخواسته را تشخیص دهد و از بازتولید همان خطا جلوگیری کند.
در چنین رویکردی، امنیت Cloud از یک بررسی مقطعی به فرایندی مستمر تبدیل می‌شود؛ فرایندی که از طراحی و استقرار آغاز شده و تا پایش وضعیت واقعی منابع ادامه دارد.
