رمزگذاری در حالت استراحت

رمزگذاری در حالت استراحت

1) چرا مورد نیاز است و دقیقا چه چیزی ما را محافظت می کند

تعریف. رمزگذاری در حالت استراحت حفاظت از داده های نوشته شده به رسانه ها (دیسک ها، عکس های فوری، پشتیبان گیری، اشیاء، سیاهههای مربوط، تخلیه حافظه) است به طوری که دسترسی غیر مجاز به رسانه های فیزیکی و یا ذخیره سازی «خام» محتوا را نشان نمی دهد.

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

آنچه ما به طور کامل پوشش نمی دهیم: سرقت جلسات در حافظه، حملات به یک فرآیند زنده، آسیب پذیری های برنامه، سازش اعتبار. این امر نیاز به رمزگذاری در پرواز، تأیید اعتبار/مجوز قوی، به حداقل رساندن حقوق و نظارت دارد (به مقالات مرتبط مراجعه کنید: «تأیید اعتبار و مجوز»، «امضا و تأیید درخواست ها»).

2) مدل تهدید و اهداف کنترل

• از دست دادن/سرقت رسانه ها (دیسک، نوار، USB، دستگاه توسعه دهنده).
• دسترسی غیر مجاز به پشتیبان گیری/عکس های فوری/سیاهههای مربوط.
• سوء استفاده از امتیازات در سطح گره پلت فرم/hypervisor/ذخیره سازی.
• عبور از مستاجران برای خطاهای پیکربندی.
• «آشغال» فایل های موقت و زباله که به مصنوعات و تصاویر قرار می گیرند.

1. محرمانه بودن اطلاعات در رسانه.

2. جداسازی رمزنگاری مستاجران/محیط ها.

3. مدیریت کلید (ایجاد، ذخیره سازی، چرخش، لغو).

4. قابلیت رسیدگی (چه کسی و چه زمانی از کلید استفاده کرده است).

5. به حداقل رساندن خطرات عملیاتی در صورت وقوع حوادث.

3) اصول معماری

ما همه چیز را به طور پیش فرض رمزگذاری می کنیم. امتناع از بدون استثنا در سطح خطر مجاز نیست.
سلسله مراتب کلید (رمزگذاری پاکت). Root/KEK → DEK (کلیدهای رمزگذاری داده) → اشیاء/فایلها/صفحات پایگاه داده.
KMS/HSM به عنوان منبع اعتماد تولید و ذخیره سازی KEK در KMS/HSM، عملیات بسته بندی/استقرار کلیدی در آنجا انجام می شود.
کلید های Per-Tenant/Per-Dataset دانه دانه برای نیازهای انزوا و چرخش.

جدایی از وظایف دستورات پلت فرم ≠ صاحبان کلید مستاجر ؛ حداقل امتیازات (PoLP)

چابکی کریپتو قابلیت مهاجرت امن الگوریتم/طول کلید.
چرخش به عنوان یک فرآیند، نه یک رویداد. کلید ها و داده ها باید از جایگزینی «نورد» پشتیبانی کنند.

4) الگوریتم های رمزگذاری و حالت ها

برای اشیاء/فایل ها/پرونده ها: AES-256-GCM یا AES-256-SIV (AEAD با احراز هویت).
برای دستگاه های بلوک/حجم: AES-XTS-256/512 (حفاظت در برابر جایگزینی بلوک ؛ نه AEAD - استفاده بیش از فرمت های فایل با MAC که در آن یکپارچگی مهم است).

• TDE (رمزگذاری داده شفاف) движка: Oracle TDE، SQL Server TDE، MySQL/InnoDB TDE и пр.
• رمزنگاری فیلد/خط (رمزگذاری FPE/قطعی) - برای قابلیت های جستجو/شادی در زمینه های رمزگذاری شده ؛ محتاطانه استفاده کنید.
• تولید کلید و ذخیره سازی: KEK - در KMS/HSM ؛ DEK - در حافظه برنامه های کاربردی کوتاه مدت، در طول ذخیره سازی - فقط پیچیده شده است.

5) سلسله مراتب کلیدی و KMS/HSM

1. کلید ریشه (قانونی، در HSM/KMS). محیط HSM/KMS را ترک نمی کند.

2. KEK (کلید رمزگذاری کلید). برای پروژه/محیط زیست/مستاجر. چرخه عمر DEK را مدیریت می کند.

3. DEK (کلید رمزگذاری داده ها). در هر شی/فایل/جدول/بخش. کوتاه مدت، چرخش بدون توقف.

• تمام عملیات بسته بندی/استقرار از طریق KMS API با حسابرسی است.
• سیاستمداران: چه کسی می تواند از کلید استفاده کند ≠ چه کسی می تواند کلید را کنترل کند.
• توزیع جغرافیایی کلیدی: پین به منطقه + کنترل دوگانه برای بین منطقه ای.
• یک مدل «دو چک» (دو اپراتور) برای عملیات با خطر بالا امکان پذیر است.
• برای جداسازی یک سطح قوی - کلید های جداگانه برای هر مستاجر.

6) چرخش، یادآوری و انطباق

چرخش DEK: شفاف و ثابت (نورد دوباره رمزگذاری در سطح شی/صفحه).
چرخش KEK: دوره ای (به عنوان مثال، هر 6-12 ماه) + فراخوان فوری اگر مشکوک به سازش باشد.
لغو دسترسی: از طریق سیاست های KMS ؛ مسدود کردن عملیات باز = فوری «رمزنگاری از بین بردن» داده ها.
سیاهههای مربوط به حسابرسی: چه کسی، چه زمانی، با چه حقوقی از کلیدها استفاده کرد ؛ به طور جداگانه ذخیره کنید و همچنین رمزگذاری کنید.
مقررات و استانداردها: ما بر روی الزامات صنعت تمرکز می کنیم (به عنوان مثال، مجوز GDPR/PCI/تنظیم کننده های محلی)، ما از ماژول های رمزنگاری گواهی استفاده می کنیم (به عنوان مثال، مطابق با سطح صدور گواهینامه).

7) الگوهای نوع ذخیره سازی

7. 1 حجم بلوک/فایل و VM/ظروف

رمزگذاری کامل دیسک (XTS) + مدیریت کلید از طریق KMS (مقدار اولیه حجم در هنگام سوار شدن).
حفاظت از مبادله، سقوط سقوط، دایرکتوری tmp، لایه های پوشش ظرف ،/تصاویر AMI.
عکس های فوری/عکس های فوری - همیشه با DEK های جداگانه رمزگذاری شده است.

7. 2 ذخیره سازی شی

رمزگذاری پاکت: DEK منحصر به فرد در هر شی ؛ هدر/ابرداده - بدون نشت PII.
کنترل دسترسی به کلید KMS توسط مستاجران و محیط.
رمزگذاری سمت سرور (SSE با KMS خاص خود) یا سمت سرویس گیرنده (CSE) - با توجه به مدل اعتماد انتخاب کنید.

7. 3 پایگاه داده ها

فعال کردن TDE در جایی که در دسترس است ؛ اتصال کلید پایگاه داده به KMS از طریق پلاگین/پسوند.
برای زمینه های بسیار حساس - رمزگذاری برنامه (AEAD) قبل از ورود به پایگاه داده.
ردو سیاهههای مربوط/معاملات سیاهههای مربوط، سیاهههای مربوط آرشیو، دامپ - رمزگذاری به طور جداگانه، کلید - جداگانه.

7. 4 سیاهههای مربوط/مسیرهای پیاده روی/متریک

فرمت ورود - بدون داده های حساس به طور پیش فرض (بهداشت).
بایگانی ورود - کلید های جداگانه و ذخیره سازی کوتاه TTL.
دسترسی به سیاهههای مربوط به خواندن - از طریق یک سرویس پروکسی با A&A و حسابرسی.

7. 5 پشتیبان گیری و رسانه های آفلاین

همیشه قبل از نوشتن در نوار/ابر، مشتری را رمزگذاری کنید.
ذخیره کلید به طور جداگانه (خارج از باند)، سپردن با کنترل جداگانه.
برای موارد اضطراری، تقسیم راز (به عنوان مثال، m-of-n) برای بازگرداندن دسترسی اصلی.

8) چند مستاجر

کلید مستاجر: KEK-per-tenant + DEK-per-dataset.
جداسازی سیاست: فضاهای نام KMS، مرزهای IAM، نقش های IDP فردی.
حذف به درخواست مشتری: «crypto-erase» - KEK مستاجر را بردارید و DEK را نابود کنید.
گزارش مشتری: مصنوعات انطباق، سیاهههای مربوط به دسترسی کلیدی، تایید چرخش.

9) عملکرد و بهره برداری

شتاب سخت افزاری (AES-NI/x86، ARMv8 Extensions Crypto).
پروفایل مسیر داغ: رمزگذاری در مرزهای I/O، اجتناب از رمزگذاری دوگانه غیر ضروری است.
استخرهای جلسه KMS، ذخیره DEK های پیچیده شده در حافظه (با محافظت از TTL و dump).
SLO/metrics: تاخیر باز کردن، نسبت اشیاء «دوباره رمزگذاری شده»، خطاهای KMS، سرعت رمزگذاری پشتیبان.

10) کتاب مرجع مرجع

مرحله 0 - موجودی داده. کاتالوگ تمام مخازن و مسیرهای نشت (tmp، dump، export، analytics buckets).
مرحله 1 - طراحی سلسله مراتب کلیدی. ما سطوح KEK/DEK، دانه بندی، مناطق، نقش ها را تعیین می کنیم.
مرحله 2 - حالت ها/کتابخانه ها را انتخاب کنید. الگوریتم های تایید شده، کتابخانه های رمزنگاری، سیاست های نسخه.
مرحله 3 - ادغام با KMS/HSM. تولید/بسته بندی/حسابرسی، سیاست های IAM، جغرافیایی.
مرحله 4 - رمزگذاری در هر نوشتن. به طور پیش فرض، مهاجرت داده های موجود را از طریق رمزگذاری مجدد پس زمینه فعال کنید.
مرحله 5 - چرخش و سناریوهای اضطراری. مقررات، آزمون «سازش کلیدی»، «KMS در دسترس نیست».
مرحله 6 - نظارت و حسابرسی. داشبورد، هشدارها، گزارش های انطباق منظم.
مرحله 7 - آموزش و «برنامه نویسی امن». "راهنمای مهندسان، ممنوعیت نمایش اسرار در سیاهههای مربوط/تخلیه.

11) تست و تأیید

تست واحد رمزنگاری: صحت AEAD (بررسی برچسب)، اعتبار سنجی شکست زمانی که یک بایت تغییر می کند.
تست شکست: غیرفعال کردن KMS، نسخه های کلیدی قدیمی، لغو KEK اجباری.
تست قرمز/آبی: تلاش برای خواندن دیسک خام/عکس فوری/پشتیبان.
بررسی سازگاری: مهاجرت الگوریتم/طول کلید (رمزنگاری چابکی).

گواهی کتابخانه: فقط از ماژول های رمزنگاری تأیید شده استفاده کنید. نسخه های commit

12) اشتباهات مکرر و چگونگی اجتناب از آنها

رمزگذاری دوگانه بدون معنی تاخیر و پیچیدگی اضافی نگه داشتن یک لایه است که می دهد دانه دانه مورد نظر و انزوا.
ذخیره کلید در کنار داده ها. کلیدها همیشه تحت یک مدل دسترسی متفاوت جدا هستند.
مصنوعات فراموش شده فایل های موقت رمزگذاری نشده، صادرات CSV، پشتیبانی از تخلیه. فعال کردن نظارت در CI/CD و پیشگیری از دست دادن داده ها.
عدم وجود چرخش چرخش بخشی از خط لوله/cron را انجام دهید، نه یک روش دستی.
Logs با اطلاعات حساس یک قرارداد برای قالب لاگ و ضدعفونیکنندههای خودکار وارد کنید.

13) دستور العمل های کوچک (شبه کد)

1) Request unwrap DEK from KMS by tenant KEK id dek = kms. unwrap(kek_id, wrapped_dek)

2) Generate fresh nonce/iv, encrypt payload (AEAD)
ciphertext, tag = aead_encrypt(dek, iv=random(), aad=metadata, plaintext=data)

3) Delete DEK from memory (zeroize), save {ciphertext, iv, tag, wrapped_dek}

For each object:
new_wrapped_dek = kms. rewrap(old_wrapped_dek, old_kek_id -> new_kek_id)
store(new_wrapped_dek)
We do not touch the data: we turn over only DEK

kms. disable_key (tenant_kek_id) # Deny unwrap kms. schedule_destroy (tenant_kek_id, hold_period_days=7) # Optional hold

14) چک لیست

• رمزگذاری پیش فرض در تمام انواع ذخیره سازی فعال است.
• سلسله مراتب کلیدی توصیف و اجرا شده است ؛ نقش ها و سیاست های IAM پیکربندی شده اند.
• KMS/HSM یکپارچه، حسابرسی عملیات کلیدی را فعال کنید.
• چرخش DEK/KEK خودکار است. سناریوهای توافقی حل شد.
• پشتیبان گیری، عکس های فوری، سیاهههای مربوط و تخلیه - رمزگذاری شده ؛ کلیدها جداگانه نگهداری می شوند.
• هشدارهای پیکربندی شده برای خطاهای KMS، انحراف برچسب AEAD، نسبت مصنوعات رمزگذاری نشده.
• آزمون عدم دسترسی KMS و لغو کلید گذشت.

• گزارش ماهانه در مورد تلاش های کلیدی استفاده و دسترسی.
• طرح رمزنگاری چابکی و پنجره برای مهاجرت الگوریتم بدون درد.
• دوره ای قرمز تیم برای استخراج داده ها از رسانه های خام.

15) پرسش و پاسخ (پرسش و پاسخ)

س: آیا رمزگذاری کامل دیسک کافی است ؟

A: برای خطرات فیزیکی - بله، اما برای جداسازی مستاجران و چرخش انعطاف پذیر پاکت بهتر با DEK-on-object/set.

س: چه کاری باید انجام دهید زمانی که KEK به خطر افتاده است ؟

A: بلافاصله KEK را به KMS فراخوانی کنید، دوباره منتشر کنید، تمام DEK ها را بازنویسی کنید، سیاهههای مربوط را بررسی کنید و RCA را اجرا کنید.

س: چگونه فیلدهای مورد نظر خود را رمزگذاری کنیم ؟

A: استفاده از طرح های قطعی یا FPE فقط در ارزیابی ریسک دقیق (الگوی leks). بهتر است پرس و جوها را طراحی کنید تا زمینه های حساس نیازی به نمایش باز نمایه نداشته باشند.

س: آیا من نیاز به یک دستور جداگانه برای کلید ؟

پاسخ: اپراتور Crypto/KMS به عنوان یک نقش با حقوق و رویه های جداگانه توصیه می شود.

• «مدیریت کلید و چرخش»
• «احراز هویت S2S»
• «ثبت و بررسی درخواستها»
• «اتصال OAuth2/OpenID در هسته»
• «Webhook گارانتی تحویل»