قسمت اول سریال را اینجا ببینید
درک و پیاده سازی نسخه های پشتیبان غیرقابل تغییر در ابر عمومی
پاشنه آشیل زمانی است که پشتیبان گیری و حجم کار تحت کنترل همان راه حل مدیریت هویت و دسترسی (IAM) باشد. به عبارت دیگر: هنگامی که مهاجمان راه حل IAM را به خطر می اندازند، می توانند سرورها و نسخه های پشتیبان سنتی را حذف کنند (شکل 1، سمت چپ). مهاجمان برخی از اسکریپت ها را آماده می کنند و آنها را در زیرساخت ابری شما اجرا می کنند – چند دقیقه بعد، برنامه های شما خراب می شوند یا حذف می شوند و از بین می روند. وقتی راه حل پشتیبان راه حل IAM خود را پیاده سازی می کند کمکی نمی کند. مهاجمان به سادگی تمام منابع راه حل پشتیبان را در پورتال ابری بدون ورود به راه حل پشتیبان حذف می کنند.
پشتیبان‌گیری‌های غیرقابل تغییر – چالش (سمت چپ)، الگوی ویژگی تغییرناپذیری (وسط)، و الگوی مستأجر پشتیبان قطع‌شده (راست)
این یک خطر وجودی است که نقش‌های مدیر ابری می‌توانند همه منابع، از جمله نسخه‌های پشتیبان را حذف کنند، اما دو راه‌حل بالقوه وجود دارد. گزینه اول این است که ارائه دهندگان ابری یک را پیاده سازی کنند ویژگی تغییر ناپذیری (شکل 1، وسط). وقتی فعال می شود، هیچ کس – همچنین هیچ سرپرست – نمی تواند نسخه پشتیبان را تغییر یا حذف کند. این یک راه حل ساده و کارآمد برای شرکت ها است.
شکل 2 ویژگی تغییر ناپذیری را نشان می دهد لاجوردی. مدتی است که برای داده های Object Storage وجود داشته است. Azure اکنون آن را برای همه نسخه‌های پشتیبان عرضه می‌کند. وقتی متن را می خوانید، ممکن است همچنان در حالت پیش نمایش عمومی باشد، به برخی از مناطق لاجوردی محدود شده باشد، یا به طور بالقوه قبلاً به طور کامل منتشر شده باشد. تنها با یک کلیک در ویژگی های vault تغییر ناپذیری فعال می شود (شکل 2، 1). اول، خزانه در حالت متوسط است: تمام محدودیت ها وجود دارد، به عنوان مثال، در مورد حذف نسخه های پشتیبان. مهندسان می توانند قبل از اینکه تنظیم تغییرناپذیری را غیرقابل تغییر کنند، تعامل با سایر اجزا و برنامه ها را آزمایش کنند (شکل 2، 2). دشوار نیست، اما مدیران فناوری اطلاعات و ریسک باید از استفاده مداوم از این ویژگی برای همه نسخه‌های پشتیبان اطمینان حاصل کنند.
پیکربندی یک Azure Vaults برای Immutability
AWS ویژگی‌های مشابهی با نام‌های AWS Backup Vault Lock، GCP Cloud Storage Bucket Lock را ارائه می‌کند.
بر اساس تجربه من، بررسی اینکه آیا تغییرناپذیری برای همه انواع ذخیره سازی و پایگاه داده طراحی ابر بتنی در دسترس است یا خیر – و تأیید اینکه آیا سرویس پشتیبان الزامات قانونی مانند SEC 17a-4 را در صورت وجود برآورده می کند، ضروری است. اگر یک ارائه‌دهنده ابری در دسترس بودن تغییرناپذیری یک سرویس را جشن بگیرد، اما یک شرکت با سه سرویس دیگر کار کند، کمکی نمی‌کند. به علاوه، دو جنبه اضافی وجود دارد که معماران ابر باید برای مفاهیم پشتیبان خود در نظر بگیرند:
- کلیدهای رمزگذاری وقتی پشتیبان‌ها رمزگذاری می‌شوند، کلیدهای رمزگشایی باید برای انجام بازیابی پشتیبان در دسترس باشند. آنها همچنین باید “تغییر ناپذیر” باشند.
- تنظیمات پشتیبان گیری اگر مهاجم بتواند برای هفته‌ها ایجاد پشتیبان را خاموش کند، اگر تمام ماشین‌های مجازی و پایگاه‌های داده را حذف کند، هیچ پشتیبان‌گیری وجود نخواهد داشت. مکانیسم های ثبت و هشدار – که با قفل های شکل 1 نشان داده شده اند – برای شناسایی تغییرات مهم ناخواسته بسیار مهم هستند.
جایگزین: پشتیبان‌گیری‌های ابری قطع شده
وقتی یک ارائه‌دهنده ابر ویژگی تغییرناپذیری (یا برای همه انواع ذخیره‌سازی) ارائه نمی‌کند، الگوی دوم، الگوی مستاجر پشتیبان قطع شده، می تواند جایگزین باشد. این الگو بک آپ ها را در یک مستاجر پشتیبان جداگانه در همان ابر عمومی یا متفاوت ذخیره می کند. ترفند به طور کامل است الان جدا کن. شرکت‌ها می‌توانند مستاجر پشتیبان خود را راه‌اندازی کنند، از جمله استراتژی‌های سخت‌سازی و پشتیبان‌گیری، یا به یک ارائه‌دهنده خدمات پشتیبان شخص ثالث برای سرعت بخشیدن به اجرای چنین راه‌حلی تکیه کنند. در مورد دوم، ارائه دهنده خدمات پشتیبان، مستاجر پشتیبان ابری را مدیریت می کند.
برای تاکید بر این نکته: اگر بین IAM ها برای حجم کاری و مستاجران پشتیبان ارتباطی وجود داشته باشد، مستاجر دوم هیچ سودی ندارد. به عنوان مثال، داشتن یک Azure Active Directory که یک مستاجر ابری را با حجم کاری در GCP و پشتیبان گیری در AWS مدیریت می کند، راه حلی نیست. اگر به یک ارائه دهنده خدمات پشتیبان متکی هستید، هیچ یک از کارمندان شما نباید قادر به حذف نسخه های پشتیبان «تغییر ناپذیر» در مستاجر ابری ارائه دهنده خدمات باشد.
یک پشتیبان جدا شده با طراحی خوب (!) در یک مستاجر اختصاصی ابری سخت شده و تحت نظارت با مکانیسم‌های کنترل دسترسی مجزا می‌تواند به یک نسخه پشتیبان غیرقابل تغییر (یا یک نسخه پشتیبان از مد روز فاصله هوایی) نزدیک شود. رتبه بندی دقیق ریسک به ریسک پذیری و تنظیمات فنی شرکت بستگی دارد. و مطمئنا، همانطور که در بالا بحث شد، نظارت بر پیکربندی های پشتیبان و اطمینان از در دسترس بودن کلیدهای رمزگشایی ضروری است.
پیام خود را به خانه
حملات مخرب ناشی از تنش‌های سطح دولتی و حملات باج‌افزاری علیه شرکت‌های کوچک و متوسط، تهدیدهای جدیدی هستند. بر اساس ریسک پذیری، شرکت ها باید ارزیابی کنند و تصمیم بگیرند که آیا و چگونه می خواهند ریسک مرتبط را کاهش دهند یا خیر. در فضای ابری، پشتیبان‌گیری‌های غیرقابل تغییر می‌توانند یک راه‌حل ساده یا مستأجران اختصاصی پشتیبان جداگانه باشند. برای جلوگیری از چنین سناریویی تکلیف را فراموش نکنید: سیستم‌های فایروال، سخت‌سازی، تشخیص بدافزار، تشخیص نقطه پایانی، یا سیستم‌های تشخیص نفوذ، همراه با مراکز عملیات امنیتی، باید حملات را در مراحل اولیه پیشگیری، شناسایی یا حداقل مهار کنند. بک آپ های تغییرناپذیر آخرین امید هستند. هدف همیشه باید داشتن پشتیبان‌های غیرقابل تغییر در سال‌های آینده باشد اما هرگز به آنها نیاز نداشته باشید.