نسخه‌بندی S3 بکاپ را مصون نمی‌کند؛ Object Lock را درست فعال کنید

برای محافظت از بکاپ‌های S3 در برابر حذف مخرب، Versioning را فعال کنید و با Object Lock برای نسخه‌های بکاپ دورهٔ نگه‌داری تعیین کنید؛ راهنمای امنیت Amazon S3 نسخه‌بندی را ابزار نگه‌داری و بازیابی نسخه‌ها و Object Lock را سازوکار WORM برای جلوگیری از حذف معرفی می‌کند. داشتن چند نسخه به‌تنهایی مانع حذف عمدی همان نسخه‌ها نمی‌شود.

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

Versioning چه کمکی می‌کند و قفل چه چیزی را حفظ می‌کند؟

Versioning تغییرات یک شیء را به‌صورت نسخه‌های جداگانه نگه می‌دارد. اگر برنامهٔ بکاپ فایلی را با همان نام بازنویسی کند یا کاربری آن را به‌اشتباه حذف کند، نسخهٔ قبلی می‌تواند برای بازیابی در دسترس باشد. اما کسی که اختیار حذف دائمی نسخه‌های مشخص را دارد، می‌تواند تاریخچهٔ موردنیاز بازیابی را از بین ببرد. بنابراین وجود نسخه‌های قدیمی را با تغییرناپذیری آن‌ها یکی نگیرید.

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

Bucket و نگه‌داری پیش‌فرض را به ترتیب تنظیم کنید

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

راهنمای پیکربندی Object Lock در AWS فعال‌سازی Versioning و Object Lock روی bucket از نوع general purpose و سپس تعیین نگه‌داری پیش‌فرض را شرح می‌دهد؛ پس از فعال‌سازی Object Lock، غیرفعال‌کردن آن یا تعلیق Versioning همان bucket ممکن نیست. روشن‌کردن Object Lock به‌تنهایی برای نسخه‌های تازه دورهٔ نگه‌داری تعیین نمی‌کند. پیش‌فرض bucket را جداگانه تنظیم کنید، مگر اینکه برنامهٔ بکاپ برای هر نسخه تنظیم نگه‌داری صریح بفرستد.

1. در زمان ساخت bucket، گزینهٔ Bucket Versioning را روی Enabled و Object Lock را در تنظیمات پیشرفته روی Enable بگذارید و دسترسی عمومی را مسدود نگه دارید. برای bucket موجود، ابتدا فعال‌بودن Versioning را بررسی کنید و سپس Object Lock را در بخش Properties فعال کنید.
2. در بخش Object Lock، گزینهٔ Default retention را فعال کنید؛ حالت Governance یا Compliance و مدت نگه‌داری را مطابق سیاست بکاپ برگزینید. این پیش‌فرض برای نسخه‌هایی است که پس از تنظیم آن در bucket قرار می‌گیرند. نسخه‌های موجود را، اگر باید محافظت شوند، جداگانه بررسی کنید و برای آن‌ها نگه‌داری تعیین کنید.
3. یک بکاپ آزمایشی را از همان مسیر نرم‌افزار بکاپ بارگذاری کنید. برای نسخهٔ تولیدشده، شناسهٔ نسخه، حالت قفل و زمان پایان نگه‌داری را بخوانید. تنظیم صریحی که برنامه هنگام بارگذاری برای یک نسخه می‌فرستد می‌تواند بر پیش‌فرض bucket مقدم شود؛ صفحهٔ تنظیمات bucket به‌تنهایی وضعیت نسخه‌های واقعی را نشان نمی‌دهد.

نگه‌داری پیش‌فرضِ آینده را می‌توان تغییر داد یا برداشت، اما این کار دورهٔ نگه‌داری نسخه‌ای را که پیش‌تر قفل شده کوتاه نمی‌کند. به همین دلیل، اختیار تغییر تنظیمات bucket نیز باید محدود باشد: یک تغییر در پیش‌فرض می‌تواند بکاپ‌های بعدی را بدون حفاظت مورد انتظار وارد bucket کند، حتی اگر نسخه‌های قدیمی همچنان قفل باشند.

Governance و Compliance کدام اختیار حذف را باقی می‌گذارند؟

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

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

مجوز دورزدن را از نقش‌های روزمره جدا کنید

مجوز حساس در Governance، s3:BypassGovernanceRetention است. درخواست API برای دورزدن باید این قصد را صریح اعلام کند، اما کنسول S3 برای کاربری که مجوز را دارد سرآیند دورزدن را هنگام درخواست مربوط به‌طور خودکار می‌فرستد. بنابراین دادن این مجوز به نقش نوشتن بکاپ یا مدیرانی که به‌طور معمول با bucket کار می‌کنند، راهی عملی برای حذف زودهنگام نسخه‌ها باز می‌کند.

برای برنامهٔ بکاپ، نقش نوشتن را به کارهای لازم برای بارگذاری محدود کنید. نقش بازیابی باید بتواند نسخهٔ موردنیاز را پیدا و بخواند، بی‌آنکه اختیار دورزدن نگه‌داری را به ارث ببرد. اگر استثنای Governance لازم است، آن اختیار را به نقش جداگانه و با دسترسی محدود بدهید و استفاده از آن را در فرایند مدیریت دسترسی قابل پیگیری نگه دارید. مجوز حذف نسخه و مجوز تغییر تنظیمات نگه‌داری bucket را نیز جداگانه بازبینی کنید؛ حذف نسخهٔ موجود و بی‌حفاظت گذاشتن نسخه‌های آینده دو مسیر متفاوت آسیب‌اند.

حذف و بازیابی را با نسخهٔ آزمایشی امتحان کنید

یک شیء آزمایشیِ قابل حذف را از مسیر معمول بکاپ بارگذاری کنید و شناسهٔ نسخه و زمان پایان نگه‌داری آن را ثبت کنید. با همان نقش روزمره‌ای که برنامه یا مدیران استفاده می‌کنند، حذف دائمی همان شناسهٔ نسخه را در دورهٔ نگه‌داری امتحان کنید؛ درخواست باید رد شود. این آزمون را با حذف معمولیِ بدون شناسهٔ نسخه اشتباه نگیرید: چنین حذفی می‌تواند پذیرفته شود و یک delete marker را به نسخهٔ جاری تبدیل کند، در حالی که نسخهٔ قفل‌شدهٔ قبلی باقی می‌ماند.

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

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

بیشتر بخوانید:

• RAG را درست ارزیابی کنید؛ یک امتیاز خوب می‌تواند خطای بازیابی را پنهان کند
• USDT یا USDC برای ایرانیان؛ شفافیت بیشتر ریسک مسدودی را حذف نمی‌کند
• کپی ویدئوی YouTube را آرشیو نکنید؛ Archive چیزی را حذف نمی‌کند