امنیت، هویت، استقرار و تاب‌آوری · فصل ۴ — Linux/Windows، Container، DNS، CDN و Storage · 100
S3 Object Storage، Presigned URL و Multipart
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «S3 Object Storage, Presigned URL و Multipart». می‌تواند برای «S3 Object Storage, Presigned URL و Multipart» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
S3 Object Storage, Presigned URLs and Multipart Uploads — en-US
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «S3 Object Storage, Presigned URL و Multipart».
می‌تواند برای «S3 Object Storage, Presigned URL و Multipart» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «S3 Object Storage, Presigned URL و Multipart» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
1. مسئله: «Upload موفق» یک نتیجه واحد نیست
در یک مسیر upload معمولاً چند لایه هم‌زمان وجود دارد: هویت bucket/key، اختیار signer، URL امضاشده، مرورگر و CORS، روش انتقال، multipart state، ذخیره نهایی و پذیرش application. اگر همه این‌ها را در یک وضعیت «موفق/ناموفق» فشرده کنیم، تشخیص علت و امنیت مسیر مبهم می‌شود.
خروجی مالک این درس Object Upload Access and Multipart Evidence Record v1 است. این رکورد باید authorization، transport، transfer lifecycle و application acceptance را جدا ثبت کند.
2. Object storage و هویت شیء
در object storage، شیء معمولاً با bucket و object key شناخته می‌شود. key فقط نام فایل نمایشی نیست؛ بخشی از namespace و سیاست دسترسی است. metadata نیز می‌تواند روی رفتار application اثر بگذارد، اما هویت storage را نباید با business identity یکی دانست.
در artifact، bucket، key، metadata موردنیاز و actor مسئول هر مرحله را صریح ثبت کن. شباهت نام فایل دلیل کافی برای یکسان‌بودن target نیست.
3. Presigned URL چیست
در Amazon S3، presigned URL دسترسی موقت به یک عملیات روی object می‌دهد بدون اینکه credential اصلی به caller تحویل داده شود. اختیار URL از principalی می‌آید که آن را امضا کرده است؛ URL نمی‌تواند به‌صورت جادویی اختیاری فراتر از signer ایجاد کند.
پس presign را به‌عنوان یک capability محدود و موقت ببین: operation، bucket/key و expiry باید با job واقعی match شوند.
4. Signer authority و least scope
اگر signer مجوز بسیار گسترده دارد، presigned URL نیز داخل همان مرز گسترده تولید می‌شود. طراحی بهتر این است که signer فقط prefix، operation و منابع موردنیاز همان workflow را داشته باشد.
در رکورد، signer_principal و allowed_prefix/operation را جدا از URL ثبت کن. صرف اینکه URL کار می‌کند، least privilege را ثابت نمی‌کند.
5. Method و object key باید با capability یکی باشند
یک URL امضاشده برای PUT روی یک key خاص را نباید به‌طور ضمنی برای key یا method دیگری معتبر فرض کرد. در fixture محلی، تغییر method یا key بدون بازامضا باعث mismatch می‌شود.
این بُعد باید مستقل از expiry تحلیل شود؛ یک درخواست می‌تواند از نظر زمان معتبر باشد ولی از نظر key یا operation رد شود.
6. Expiry یک مرز authorization است
presigned URL زمان‌دار است. بعد از عبور از validity window، شکست را باید ابتدا در لایه authorization زمانی بررسی کرد، نه اینکه نبود object یا خرابی network را نتیجه بگیریم.
در Lab یک replay بعد از expiry وجود دارد. پاسخ صحیح، AUTH_EXPIRED است و نه «فایل حذف شده» یا «storage down».
7. CORS با authorization یکی نیست
CORS یک سیاست browser transport است. ممکن است درخواست از نظر storage authorization معتبر باشد اما مرورگر به‌دلیل CORS آن را مسدود کند. برعکس، CORS باز هم مجوز storage ایجاد نمی‌کند.
در artifact، cors_transport_boundary را جدا ثبت کن. اگر همان request با client غیرمرورگری از نظر signature معتبر است، مشکل را در transport/browser نگه دار.
8. Single PUT یا Multipart: تصمیم workload
Single PUT ساده‌تر است و برای workloadهای کوچک یا بدون نیاز resume معمولاً کافی است. Multipart امکان parallelism، retry مستقل partها و resume بهتر را می‌دهد، اما state و cleanup بیشتری دارد.
عددهای provider را قانون جهانی نکن. AWS و R2 guidance عددها و limits خاص خود را دارند و باید در زمان اجرا دوباره بررسی شوند.
9. Multipart lifecycle: upload-id و part ledger
Multipart با یک upload-id و مجموعه partها مدیریت می‌شود. هر part شماره و evidence انتقال خودش را دارد؛ اگر یک part fail شود، لازم نیست partهای موفق از نو فرستاده شوند.
در record، upload-id، part number، checksum/ETag یا evidence معادل و retry history را نگه دار تا recovery deterministic باشد.
10. Complete و Abort دو پایان متفاوت‌اند
تا زمانی که completion موفق نشده، مجموعه partها برابر object نهایی نیست. اگر workflow ادامه پیدا نمی‌کند، باید abort/cleanup تصمیم صریح داشته باشد؛ رهاکردن session نیمه‌کاره یک state باز است.
در Lab یک case عمداً incomplete می‌ماند تا learner مجبور شود MULTIPART_ABORT_REQUIRED را ثبت کند.
11. Storage completion با application acceptance فرق دارد
ممکن است object به‌درستی ذخیره شده باشد ولی application آن را به‌خاطر checksum، media type، schema، malware scan یا business rule رد کند. این رد شدن به معنی شکست transport نیست.
بنابراین artifact دو evidence جدا دارد: stored_object_observation و application_acceptance.
12. R2 و مفهوم S3-compatible
Cloudflare R2 از S3 API compatibility استفاده می‌کند، اما «سازگار» به معنی یکسان‌بودن همه رفتارها نیست. مستندات فعلی R2 عملیات presigned پشتیبانی‌شده، bearer-token بودن URL و محدودیت‌های upload را جدا توضیح می‌دهند.
برای هر provider-specific تصمیم، به مستندات همان provider مراجعه کن و فرض AWS را بدون بررسی منتقل نکن.
13. Object Upload Access and Multipart Evidence Record v1
رکورد شامل این ستون‌هاست: bucket/key، signer scope، requested operation، signed constraints، issued/expiry time، authorization result، browser/CORS state، transfer method، upload-id، part state، retry evidence، complete/abort evidence، final object observation، application acceptance، inference، unknowns و final decision.
این قالب synthesis آموزشی MAKNOW است، نه فرم اجباری AWS یا Cloudflare.
14. Lab و Transfer
Lab کاملاً local و deterministic است. هشت fixture شامل happy path single PUT، expiry، key mismatch، CORS-only failure، multipart retry، orphaned multipart، storage-complete-but-app-reject و transfer با prefix/size/part متفاوت هستند.
در transfer، هیچ token، key، expiry یا part decision از case اول قابل کپی نیست؛ همه چیز باید از evidence جدید محاسبه شود.
15. منابع، freshness و مرز ادعا
مستندات فعلی Amazon S3 presigned URL را دسترسی زمان‌دار با credential signer توصیف می‌کنند و multipart را upload مستقل partها با retry و completion/abort می‌دانند. Cloudflare R2 نیز presigned URL را bearer token برای عملیات مشخص می‌داند و upload methodها را با trade-offهای size، parallelism و resumability تفکیک می‌کند.
این منابع در 2026-09-19 دوباره بررسی شدند و موعد مرور بعدی 2026-10-17 است. هیچ عدد provider-specific در این درس به‌عنوان قانون جهانی object storage ارائه نمی‌شود.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
OPS-007-S1 retrieval
Explain why a presigned URL is a bounded capability rather than a public-bucket policy, naming signer scope, operation, key, and expiry.
OPS-007-S2 application
For the supplied synthetic request, determine whether method/key/expiry authorize and whether browser CORS changes that authorization result.
OPS-007-S3 diagnosis
Differentiate expired signature, wrong key binding, browser CORS failure, and a failed multipart part using discriminating evidence.
OPS-007-S4 decision
Choose single PUT or multipart for a bounded workload and define retry, completion/abort, and cleanup evidence without claiming a universal threshold.
OPS-007-S5 transfer
Rebuild the full access and multipart record for a changed key prefix, shorter expiry, larger object, and a different failed part.
ملاک‌های ارزیابی (rubric)
| Dimension | Critical | Sufficient evidence |
|---|---|---|
| Presign authority | Yes | Signer scope, operation, key binding, and expiry are evaluated independently. |
| Transport boundary | Yes | Browser CORS symptoms are kept separate from storage authorization. |
| Multipart lifecycle | Yes | Upload ID, retained successful parts, retry, complete/abort, and cleanup are explicit. |
| Application acceptance | Yes | Stored-object evidence is separated from application/business acceptance. |
| Transfer | Yes | Changed prefix, expiry, size, and failed part are recomputed from new evidence. |
Failure: treating presign as public access, using CORS as authorization proof, restarting every multipart part without evidence, leaving incomplete uploads without a cleanup decision, or treating storage completion as business acceptance.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Everything is local and synthetic. No AWS/Cloudflare account, real credential, external bucket, public endpoint, network egress, or real presigned link is used.
For each case produce eight states: storage_target_state, signer_authority_state, presign_binding_state, expiry_state, transport_boundary_state, transfer_method_state, multipart_lifecycle_state, and application_acceptance_state.
Rules:
- Evaluate signer scope, method/key binding, and expiry independently.
- CORS is a browser-transport fact, not storage authorization.
- Choose transfer method from the fixture workload; do not use one universal numeric threshold.
- For multipart, retain successful parts, retry only failed parts, and close with complete or abort/cleanup evidence.
- Storage completion is not application acceptance.
- The transfer case must be solved from its own prefix, expiry, size, and part ledger.
Run python -B run_checks.py for learner-visible structural checks. Hidden acceptance lives outside learner paths.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)