Encryption at Rest و Key Boundaries

این درس درباره‌ی «داشتن encryption» نیست؛ درباره‌ی این است که دقیقاً مشخص کنیم چه چیزی در حالت at rest محافظت می‌شود، کلید کجا قرار دارد، چه workloadی حق decrypt دارد، شکست کدام boundary باعث از بین رفتن مزیت encryption می‌شود، و rotation/recovery چگونه قابل اثبات است. خروجی نهایی درس At-Rest Encryption & Key Boundary Record v1 است و آزمایشگاه SEC012-LAB1 فقط با شناسه‌های ساختگی ciphertext و key handle کار می‌کند. هیچ کلید واقعی، secret واقعی، حساب production یا سرویس خارجی در این تمرین وجود ندارد.

1. دامنه‌ی واقعی encryption at rest

Encryption at rest یک کنترل برای داده‌ای است که در storage قرار دارد. این کنترل باید درون یک threat model تعریف شود. اگر مهاجم فقط به فایل، disk image یا database snapshot برسد و authority لازم برای decrypt را نداشته باشد، encryption می‌تواند exposure را کم کند. اما اگر همان مسیر compromise هم ciphertext و هم key/decrypt authority را در اختیار مهاجم بگذارد، فقط وجود واژه‌ی «encrypted» تضمین معناداری ایجاد نمی‌کند. به همین دلیل در این درس successful decryption به‌تنهایی security proof نیست.

یک مرز مهم دیگر این است که at-rest encryption از plaintextی که application به‌صورت مجاز decrypt کرده محافظت نمی‌کند. اگر workload مجاز compromise شود و همان workload توان decrypt داشته باشد، مسئله وارد مرز authorization، runtime isolation یا application security می‌شود. این درس آن حوزه‌ها را جذب نمی‌کند؛ فقط باید residual boundary را صریح ثبت کند.

2. Data، DEK، KEK و decrypt authority را از هم جدا کنید

برای reasoning درست چهار چیز را جدا ببینید: data/ciphertext، Data Encryption Key یا DEK، Key Encryption Key یا KEK، و decrypt authority. ممکن است encrypted DEK کنار data ذخیره شود، اما KEK authority باید تا جای ممکن در مسیر compromise مستقل‌تری قرار بگیرد. اگر data store و KEK authority عملاً همان boundary باشند، طراحی باید این ضعف را صریحاً ثبت کند و نباید separation را ادعا کند.

OWASP-CRYPTO-STORAGE روی architecture و threat model تأکید می‌کند و در guidance مربوط به key storage، separation of keys and data و DEK/KEK توضیح می‌دهد. در SEC012-LAB1 این مفهوم با نام‌های ساختگی مثل dek-primary-v1 و kek-authority-primary مدل می‌شود. این‌ها key material نیستند؛ فقط identifierهای آموزشی هستند. هدف lab اجرای cryptography واقعی نیست، بلکه verify کردن boundary logic است.

3. Key storage یک boundary است، نه یک filename

قرار دادن key در source code، repository یا ordinary configuration به معنی داشتن key boundary مستقل نیست. حتی اگر برنامه برای راحتی از یک string ثابت استفاده کند، این رفتار نباید به‌عنوان vault یا managed key boundary معرفی شود. رکورد نهایی باید key storage model را مشخص کند و نشان دهد آیا compromise مسیر application/configuration می‌تواند هم‌زمان به data و decrypt authority برسد یا نه.

در این درس محصول خاصی مثل یک KMS vendor انتخاب نمی‌شود. OWASP-KEY-MGMT برای lifecycle و storage boundary استفاده می‌شود، اما artifact داخلی MAKNOW یک format استاندارد OWASP نیست. ما از source برای constrain کردن claim استفاده می‌کنیم، نه برای وانمود کردن اینکه record ما یک استاندارد رسمی است.

4. Rotation فقط عوض کردن یک identifier نیست

Rotation زمانی قابل دفاع است که وضعیت old و new data path معلوم باشد. اگر از امروز dek-primary-v2 برای data جدید استفاده می‌شود، باید معلوم باشد داده‌های قدیمی با چه referenceای decrypt می‌شوند، چه زمانی old key retired یا revoked می‌شود، و recovery نیازمند چه metadataای است. یک طراحی که فقط «new key created=true» دارد ولی historical references را گم می‌کند، rotation کامل ندارد.

هیچ universal cryptoperiod در این درس تجویز نمی‌شود. زمان rotation به threat model، sensitivity، compromise event، operational needs و policy واقعی وابسته است. اینجا فقط invariantها بررسی می‌شوند: current key مشخص است، historical encrypted objects قابل accounting هستند، old/new references مبهم نیستند، و recovery metadata قبل از incident تعریف شده است.

5. Recovery را قبل از incident تعریف کنید

اگر key از دست برود، encrypted data ممکن است برای همیشه غیرقابل بازیابی شود. بنابراین recovery یک afterthought نیست. اما recovery path خودش یک trust boundary است؛ اگر recovery authority خیلی گسترده یا کنار data store قرار گرفته باشد، می‌تواند جداسازی اصلی را خنثی کند. At-Rest Encryption & Key Boundary Record v1 باید recovery owner، recovery metadata و residual risk را ثبت کند، بدون اینکه real secret یا key material وارد evidence شود.

در lab، یک mutation عمداً recovery metadata را حذف می‌کند. نتیجه نباید «recoverable» باقی بماند. این Negative Evidence مهم است، چون نشان می‌دهد سیستم آموزشی فقط happy path را چک نمی‌کند.

6. Decrypt authority را محدود و قابل مشاهده نگه دارید

داشتن access به ciphertext با داشتن decrypt authority یکی نیست. یک storage reader ممکن است فقط ciphertext و key handle را ببیند، درحالی‌که workload مجاز اجازه‌ی استفاده از key authority دارد. در fixture محلی، service:primary-api برای primary database و service:backup-recovery برای backup archive نقش‌های متفاوتی دارند. اگر workload دیگری درخواست decrypt بدهد، expected behavior باید denial باشد.

این مدل production IAM نیست. فقط یک synthetic oracle است که learner را مجبور می‌کند distinction بین possession of encrypted data و authority to decrypt را حفظ کند.

7. Evidence table چگونه پر می‌شود

هر ردیف در At-Rest Encryption & Key Boundary Record v1 این فیلدها را دارد: data_class, storage_boundary, ciphertext_location, key_handle, kek_authority, decrypting_workload, rotation_state, recovery_evidence, observed_evidence, residual_risk. فیلدها باید از observation پر شوند، نه از حدس. starter عمداً rows, positive_evidence, negative_evidence, owner_acceptance و decision نهایی transfer را خالی می‌گذارد.

Positive Evidence شامل مشاهده‌ی یک boundary سالم است: data store فقط ciphertext/key reference دارد، KEK authority جدا تعریف شده، workload مجاز decrypt path را طی می‌کند و current key reference معلوم است.

Negative Evidence باید حداقل یک failure واقعی local را نگه دارد: collapse شدن key authority داخل data store، workload غیرمجاز، missing recovery metadata، hard-coded key location یا evidence row ناقص. پاک کردن failure output برای «تمیزتر شدن گزارش» خلاف هدف درس است.

8. Lab: SEC012-LAB1

آزمایشگاه با Python standard library اجرا می‌شود و هیچ crypto library واقعی لازم ندارد. فایل golden-policy.json دو context دارد: primary_database و backup_archive. هر context storage boundary، key handle، KEK authority، decrypt workload، current key id، historical key references و recovery requirement مستقل دارد. baseline-data.json نیز fake ciphertext identifiers را نگه می‌دارد.

ابتدا static_preflight.py را اجرا کنید تا local-only بودن toolchain و ممنوعیت network/real key material بررسی شود. سپس public-contract.test.py را اجرا کنید. بعد run_local_lab.py یک نمونه‌ی evidence row می‌سازد. هدف این نیست که «رمزنگاری انجام شد»؛ هدف این است که boundary تصمیم‌گیری قابل مشاهده و قابل تکرار باشد.

9. Failure probes

Probe A — collapse boundary

اگر kek_authority عملاً با storage_boundary یکی شود، نتیجه باید BOUNDARY_WEAKENED_KEY_AUTHORITY_COLLAPSED باشد. این نشان می‌دهد separation فقط نام‌گذاری نیست.

Probe B — unauthorized decrypt workload

اگر workload غیرمجاز تلاش به decrypt داشته باشد، نتیجه باید DENY_DECRYPT_AUTHORITY باشد. داشتن ciphertext یا key handle حق decrypt ایجاد نمی‌کند.

Probe C — missing recovery metadata

اگر context recovery را required کرده ولی metadata خالی باشد، نتیجه باید DENY_RECOVERY_METADATA_MISSING باشد.

Probe D — rotation accounting

اگر current key تغییر کند اما historical objectها هنوز به key reference قدیمی متصل باشند و mapping old/new ثبت نشود، نتیجه باید DENY_ROTATION_HISTORICAL_PATH_UNACCOUNTED باشد. در repair، new data از key جدید استفاده می‌کند و historical path به‌صورت explicit نگه داشته می‌شود.

Probe E — hard-coded key location

اگر fixture بگوید key storage=application_source یا ordinary_config, نتیجه باید DENY_KEY_STORAGE_BOUNDARY باشد. این probe هیچ secret واقعی افشا نمی‌کند.

10. Threat model و residual risk

یک boundary سالم هم guarantee مطلق نیست. اگر decrypting workload کاملاً compromise شود، attacker ممکن است از همان مجوز قانونی workload سوءاستفاده کند. اگر recovery authority compromise شود، recovery می‌تواند به مسیر bypass تبدیل شود. اگر operational process historical keys را زود حذف کند، availability/recovery آسیب می‌بیند. اگر old keyها بی‌دلیل برای همیشه نگه داشته شوند، exposure window بزرگ می‌شود. رکورد باید دقیقاً بگوید چه چیزی آزمایش شده و چه چیزی اثبات نشده است.

در این درس ادعا نمی‌کنیم encryption authorization را حل می‌کند؛ ادعا نمی‌کنیم یک cryptoperiod برای همه درست است؛ custom cryptography را توصیه نمی‌کنیم؛ و successful decrypt را certification امنیتی نمی‌دانیم.

11. Changed-context transfer

Transfer مستقل این درس بین primary_database و backup_archive است. این دو context recovery need یکسان ندارند. learner نباید baseline design را copy کند. باید جداگانه مشخص کند data store، key authority، decrypt workload، rotation state و recovery evidence هر کدام چیست. اگر backup retention/recovery طولانی‌تر است، این فقط یک نیاز عملیاتی در fixture است؛ به‌تنهایی دلیل برای reuse همان key boundary نیست.

در فایل changed-context.template.json تصمیم نهایی عمداً خالی است. AI می‌تواند بعد از اینکه learner هدف bounded را نوشته، test case پیشنهاد کند یا observed output را مرتب کند؛ اما اجازه ندارد final security conclusion یا owner acceptance را پر کند.

12. Assessment و blocking conditions

سؤال retrieval باید scope و یک non-goal را بیان کند. Application باید evidence record را از اجرای local بسازد. Diagnosis باید failure probe را با observation توضیح دهد. Decision باید shortcut «کلید را کنار database نگه می‌داریم چون data encrypted است» را نقد کند. Transfer باید context دوم را بدون copy کردن baseline حل کند.

سه failure condition blocking هستند: unsupported security claim، happy-path-only proof، و missing negative/transfer evidence. Evidence واقعی باید distinction بین observation و inference را نگه دارد.

13. منابع و freshness

OWASP-CRYPTO-STORAGE فقط برای architecture at-rest، threat model، separation of keys/data و DEK/KEK boundary استفاده می‌شود. OWASP-KEY-MGMT فقط برای key lifecycle، storage، compromise/recovery boundary استفاده می‌شود. Source boundary دقیقاً همین دو منبع است و در Authoring گسترش داده نشده است. Current-source check در 2026-09-16 داخل همین boundary انجام شد و review بعدی 2026-10-02 است.

14. خروجی نهایی learner

برای قبولی، learner باید At-Rest Encryption & Key Boundary Record v1 را با evidence traceable تکمیل کند، Positive Evidence و Negative Evidence را نگه دارد، changed-context transfer را مستقل حل کند و Residual Risk را صریح بنویسد. owner_acceptance در starter خالی می‌ماند و production proof همیشه false است.