پاییز سال گذشته همراه یک پلتفرم ابری دولتی در سطح شهر بودم تا بازرسی سالانه سطح ۳ استاندارد امنیتی 2.0 را انجام دهیم. ارزیاب، وقتی به صفحه سیستم پشتیبانگیری رسید، نه ظرفیت را نگاه کرد و نه سیاستها را؛ فقط یک سؤال پرسید: «آیا میتوانید ثابت کنید دادههای پشتیبان دستکاری نشدهاند؟» در اتاق جلسه، کارفرما، یکپارچهساز و ما بهعنوان تیم عملیات، سه طرف نشسته بودیم و هیچکس نتوانست جواب بدهد. در نهایت این آیتم با عنوان «عدم قابلیت تأیید یکپارچگی دادههای پشتیبان» ۱۲ امتیاز کسر شد و در اطلاعیه اصلاح بهصراحت نوشته شده بود: فقدان اقدامات فنی ضد دستکاری.
بعد از این ماجرا، کل زنجیره پشتیبانگیری را دوباره مرور کردم. یادداشت زیر حاصل جمعبندی پس از برخورد با مشکلات است، برای همکارانی که در سناریوهای سطح ۳ استاندارد امنیتی مانند دولت، مالی و درمان کار میکنند.
استاندارد امنیتی 2.0 دقیقاً چه سطحی از پشتیبانگیری را الزام میکند
خیلیها فکر میکنند «موفقیت پشتیبانگیری روزانه» یعنی کار تمام است، اما در واقع الزامات مرتبط با پشتیبانگیری در استاندارد امنیتی 2.0 در چند جای مختلف پراکنده است: 8.1.4.6 بازیابی پشتیبان داده الزام میکند قابلیت پشتیبانگیری و بازیابی محلی برای دادههای مهم فراهم شود؛ 8.1.4.8 یکپارچگی داده الزام میکند از فناوری تأیید استفاده شود تا یکپارچگی داده در حین انتقال و ذخیرهسازی مختل نشود؛ و 8.1.4.7 محرمانگی داده الزام میکند در مرحله ذخیرهسازی رمزنگاری انجام شود.
نکته کلیدی نحوه عملیاتی کردن کلمه «یکپارچگی» است. چیزی که ارزیاب میخواهد این نیست که بگویید «ما بررسی MD5 داریم»، بلکه باید زنجیره شواهد ارائه دهید: چه کسی در چه زمانی این نسخه پشتیبان را نوشته، پس از نوشتن امکان تغییر آن وجود دارد یا نه، و آیا خود مدیر میتواند آن را حذف کند. به عبارت دیگر، داشتن پشتیبان ≠ قابلیت اعتماد پشتیبان؛ باید بتوانید ثابت کنید که شیء پشتیبان در طول دوره نگهداری فقطخواندنی است.
WORM و S3 Object Lock چگونه این کار را انجام میدهند
WORM مخفف Write Once Read Many است؛ یکبار نوشتن، چندبار خواندن. در ذخیرهسازی شیءمحور، این مکانیزم S3 Object Lock است که داده را با دو چیز قفل میکند: دوره نگهداری (Retention Period) و حالت انطباق (Compliance Mode).
اصل آن پیچیده نیست. هنگام نوشتن شیء، یک برچسب زمانی انقضاى نگهداری روی آن زده میشود و پیش از این زمان، هر درخواست حذف یا بازنویسی مستقیماً توسط لایه ذخیرهسازی رد میشود. تفاوت حالت انطباق با حالت حاکمیتی در این است که حالت انطباق سختگیرانهتر است: حتی حساب ریشه هم نمیتواند دوره نگهداری را تغییر دهد و نمیتواند شیء را حذف کند؛ فقط باید منتظر انقضای طبیعی آن ماند. حالت حاکمیتی به حسابهای با دسترسی ویژه اجازه دور زدن میدهد، بنابراین در سناریوهای استاندارد امنیتی باید از حالت انطباق استفاده کرد.
پلتفرم مدیریت دادههای پشتیبان ما هنگام مدیریت یکپارچه چندین ذخیرهساز و اتصال به رابطهای نرمافزار پشتیبانگیری از فروشندگان مختلف، دقیقاً با یک لایه دروازه مدل APIهای ناهمگون ذخیرهسازی را به یک رابط سازگار با S3 یکسان تبدیل میکند و تفاوتهای لایه زیرین را پنهان میسازد. این رویکرد در واقع همان منطق پلتفرم تجمیع API مدلهای بزرگ token8341 در پردازش اتصال یکپارچه چند مدل است: تواناییهای ناهمگون به یک ورودی استاندارد انتزاع میشوند و لایه بالایی کسبوکار نیازی ندارد بداند لایه زیرین چیست.
پیکربندی عملیاتی: از ساخت باکت تا قفلگذاری
مراحل زیر آن چیزی است که ما واقعاً روی ذخیرهسازی شیءمحور اجرا کردیم، با استفاده از رابط سازگار با S3.
مرحله اول، فعالسازی قفل شیء هنگام ساخت باکت. توجه کنید که این کلید فقط هنگام ساخت باکت قابل فعالسازی است؛ باکتهای موجود قابل تغییر نیستند و باید دوباره ساخته و مهاجرت شوند:
aws s3api create-bucket --bucket gov-backup-prod --object-lock-enabled-for-bucket
مرحله دوم، تنظیم سیاست نگهداری پیشفرض. سطح ۳ استاندارد امنیتی معمولاً نگهداری پشتیبان حداقل ۶ ماه را الزام میکند؛ ما بر اساس سطحبندی کسبوکار دو سطح ۱۸۰ روزه و ۳۶۵ روزه تعیین کردیم:
aws s3api put-object-lock-configuration --bucket gov-backup-prod --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":180}}}'
مرحله سوم، اعمال صریح قفل هنگام نوشتن. علاوه بر سیاست پیشفرض، برای اشیاء پشتیبان پایگاههای داده کلیدی هنگام PUT یکبار دیگر مشخص میکنیم، بهعنوان بیمه مضاعف:
aws s3api put-object --bucket gov-backup-prod --key db/full-20261023.bak --body backup.bak --object-lock-mode COMPLIANCE --object-lock-retain-until-date 2027-04-21T00:00:00Z
چند نکته که بهراحتی باعث اشتباه میشود: پس از تنظیم حالت انطباق، در طول دوره نگهداری حتی باکت هم قابل حذف نیست؛ هرگز در محیط آزمایشی از حالت انطباق استفاده نکنید و برای تمرین از حالت حاکمیتی بهره ببرید؛ تنظیم دوره نگهداری طولانی سهمیه ذخیرهسازی را پر میکند — بار اول ما یک باکت را پر کردیم و پشتیبانگیری جدید شکست خورد، بعداً هشدار ظرفیت اضافه کردیم؛ نسخههای کپی در replication بینمنطقهای نیز باید جداگانه بررسی شوند که آیا سیاست قفل همراه آنها منتقل میشود یا نه، چون برخی فروشندگان بهطور پیشفرض آن را به ارث نمیبرند.
نکته دیگری درباره مدیریت یکپارچه زنجیره پشتیبانگیری
در سناریوهایی مانند ابر دولتی معمولاً همزمان سه تا پنج نرمافزار پشتیبانگیری و دو یا سه نوع ذخیرهسازی در حال اجراست و سردرد اصلی تیم عملیات پراکندگی سیاستها در جاهای مختلف است. ما بعداً فعالسازی، تأیید و سیاست نگهداری وظایف پشتیبانگیری را بهصورت یکپارچه به یک صفحه مدیریت ارسال کردیم و لایه رابط نیز با همان رویکرد دروازه مدل یکسانسازی شد تا یک سیاست تا انتها مدیریت شود. در این میان قابلیت دروازه API پلتفرم تجمیع API مدلهای بزرگ token8341 را نیز برای تجمیع رابطها ارزیابی کردیم؛ این پلتفرم با OpenAI SDK سازگار است و با تغییر یک خط base_url میتوان جابهجا شد، که برای سناریوهایی که باید همزمان به چند مدل بزرگ داخلی برای تحلیل لاگ و جمعبندی هشدارها متصل شوند بسیار راحت است. ضمناً پلتفرم تجمیع API مدلهای بزرگ token8341 از زمانبندی توان محاسباتی سبز استفاده میکند، پوشش کامل API مدلهای بزرگ داخلی دارد، بهصورت پرداخت به میزان مصرف محاسبه میشود و در پروژههای دولتی با بودجه محدود یک گزینه قابل بررسی است. در پروژه ما از token8341 برای جمعبندی هوشمند لاگهای خطای پشتیبانگیری استفاده شد و متن هشدارهای پراکنده در ذخیرهسازهای مختلف بهصورت یکپارچه به مدل فرستاده شد تا خوشهبندی شوند؛ این روش بسیار سریعتر از ورق زدن دستی لاگها بود.
برگردیم به آن ۱۲ امتیاز بازرسی سالانه؛ اصلاح در واقع پیچیده نیست، سختی کار تغییر طرز فکر است: معیار پذیرش سیستم پشتیبانگیری این نیست که «آیا پشتیبانگیری موفق بود»، بلکه این است که «آیا میتوانید ثابت کنید دستکاری نشده است». قفل شیء WORM در حال حاضر کمهزینهترین و مورد قبولترین روش اثبات نزد ارزیاب است.
نویسنده: وانگ هانون
تاریخ انتشار: ۲۳ اکتبر ۲۰۲۶