امنیت، هویت، استقرار و تاب‌آوری · فصل ۴ — Linux/Windows، Container، DNS، CDN و Storage · 99
Cloudflare/CDN/WAF/R2 Concepts
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Cloudflare/CDN/WAF/R2 Concepts». می‌تواند برای «Cloudflare/CDN/WAF/R2 Concepts» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خلاصهٔ درس
می‌تواند سرویس را اجرا کند اما lifecycle، health، rollout، observability و recovery را به‌صورت سیستماتیک مدیریت نمی‌کند. موضوع جاری: «Cloudflare/CDN/WAF/R2 Concepts».
می‌تواند برای «Cloudflare/CDN/WAF/R2 Concepts» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
خروجی این درس
می‌تواند برای «Cloudflare/CDN/WAF/R2 Concepts» run/release model و signals/recovery checks لازم را برای یک سرویس محدود طراحی کند.
1. مسئله: «پشت Cloudflare است» یک نتیجه فنی کامل نیست
وقتی یک hostname پشت یک edge platform قرار می‌گیرد، چند سیستم مستقل در مسیر درخواست وجود دارند: DNS proxying، ورودی شبکه edge، WAF، cache، origin routing و در برخی مسیرها R2. یک وضعیت سبز در داشبورد یا یک پاسخ 200 نمی‌تواند همه این لایه‌ها را اثبات کند.
خروجی مالک این درس Edge Delivery Policy Evidence Record v1 است. هدف این رکورد این است که برای هر لایه، مشاهده مستقیم، استنباط، مجهول و تصمیم بازیابی/تعویق جدا ثبت شود.
2. Proxied DNS فقط مسیر ورود را تعیین می‌کند
Cloudflare Rules برای بسیاری از قابلیت‌های edge نیاز دارد DNS record پروکسی‌شده باشد تا ترافیک از شبکه Cloudflare عبور کند. این شرط درباره مسیر عبور است، نه درباره درست‌بودن برنامه، مجوز origin یا سیاست cache.
در evidence record ابتدا مشخص کن درخواست وارد edge شده یا نه؛ بعد سراغ تصمیم‌های WAF و cache برو. ورود به edge پایان تشخیص نیست.
3. WAF یک rule engine با expression و action است
Cloudflare WAF درخواست‌های web/API را بر اساس rulesetها بررسی می‌کند. هر rule یک شرط و یک action دارد و برخی actionهای terminating ارزیابی بعدی را متوقف می‌کنند.
اگر یک header یا path باعث match شدن rule شود، نتیجه را در لایه WAF ثبت کن. block شدن request به‌تنهایی ثابت نمی‌کند origin خراب است یا application vulnerability حذف شده است.
4. False positive و bypass را به‌عنوان ریسک مستقل ببین
WAF می‌تواند درخواست سالم را اشتباه block کند یا یک rule بیش از حد محدود/گسترده باشد. بنابراین «WAF فعال است» معادل «امنیت حل شده» نیست.
در fixture محلی، یک header تغییر می‌کند و rule از allow به block می‌رود در حالی که origin state ثابت است. تشخیص صحیح باید تغییر را به WAF نسبت دهد، نه به origin.
5. CDN cache یک تصمیم مستقل از application correctness است
Cache درباره این تصمیم می‌گیرد که پاسخ از edge cache تامین شود یا از مسیر پایین‌تر fetch شود. HIT، MISS، STALE و BYPASS مشاهدات cache هستند؛ هیچ‌کدام به‌تنهایی correctness محتوا، suitability freshness یا authorization را ثابت نمی‌کنند.
در record، cache state را همراه cache key dimension و freshness evidence ثبت کن. نتیجه application را جدا نگه دار.
6. Cache key و freshness بخشی از علت هستند
دو درخواست که URL ظاهراً مشابه دارند ممکن است به‌دلیل header، cookie، query یا rule متفاوت cache key متفاوتی داشته باشند. همچنین یک HIT می‌تواند برای policy موردنظر بیش از حد قدیمی باشد.
در Lab یک fixture فقط metadata مربوط به key/freshness را عوض می‌کند. پاسخ صحیح این است که cache behavior تغییر کرده؛ نه اینکه بدون evidence بگوییم application defect رخ داده است.
7. Origin path را از edge observation جدا کن
Edge ممکن است درخواست را block، پاسخ را cache، یا آن را به origin route کند. مشاهده edge و مشاهده origin یک چیز نیستند.
اگر origin health fixture ثابت است ولی WAF block می‌کند، علت را در WAF نگه دار. اگر cache MISS شد، ابتدا route/fetch evidence را بررسی کن و بعد درباره origin نتیجه بگیر.
8. R2 bucket به‌صورت پیش‌فرض private است
مستندات فعلی Cloudflare R2 می‌گویند bucketها به‌صورت پیش‌فرض private هستند. برای سرو کردن objectها از طریق Cloudflare Cache می‌توان Custom Domain متصل کرد؛ این کار یک public delivery path ایجاد می‌کند.
Public delivery را با private-object authorization یکی نکن. طراحی presigned/private access به درس بعد، OPS-007، تعلق دارد.
9. Custom Domain، Cache و WAF یک pipeline قابل تفکیک‌اند
Cloudflare برای مسیر public R2 نمونه‌ای از WAF → Cache → R2 مستند کرده است. در این pipeline، WAF می‌تواند قبل از cache درخواست نامعتبر را متوقف کند و cache می‌تواند قبل از R2 پاسخ بدهد.
این ordering به ما اجازه می‌دهد failure layer را دقیق‌تر تشخیص دهیم؛ اما نباید آن را به همه محصولات و همه topologyها تعمیم دهیم.
10. «S3-compatible» یعنی سازگاری محدود و قابل بررسی
R2 یک S3-compatible API ارائه می‌دهد، اما compatibility matrix شامل قابلیت‌های implemented، experimental و unimplemented است و ممکن است تغییر کند.
قبل از انتخاب یک عملیات، requirement را با مستندات فعلی R2 مقایسه کن. familiarity با Amazon S3 دلیل کافی برای ادعای پشتیبانی R2 نیست.
11. Direct observation، inference و unknown را جدا کن
مثلاً WAF rule X matched یک observation است؛ origin is broken ممکن است inference باشد. اگر origin اصلاً hit نشده باشد، آن inference evidence کافی ندارد.
Edge Delivery Policy Evidence Record برای هر لایه سه ستون مستقل دارد: observation، inference و unknown. اگر evidence کافی نیست، state را OPEN نگه دار.
12. Recovery باید layer-specific باشد
برای WAF false positive، recovery می‌تواند اصلاح expression و replay محلی باشد. برای cache anomaly، recovery می‌تواند اصلاح key/freshness policy و مقایسه response evidence باشد. برای unsupported R2 capability، تصمیم ممکن است defer یا انتخاب capability دیگری باشد.
یک restart عمومی یا bypass بی‌دلیل recovery proof نیست؛ recovery باید به همان failure layer وصل باشد.
13. Edge Delivery Policy Evidence Record v1
رکورد شامل request facts، proxied-edge assumption، WAF match/action، cache state/key/freshness، origin route، R2 path، compatibility requirement/result، direct observation، inference، unknowns، failure layer، recovery check و final decision است.
این artifact یک synthesis آموزشی MAKNOW است و فرم اجباری Cloudflare نیست.
14. Lab و Transfer
Lab کاملاً offline است: هشت fixture synthetic با request header، WAF rule، cache ledger، origin state، R2 route و compatibility snapshot محلی. هیچ zone، credential، DNS change یا network request واقعی وجود ندارد.
Transfer یک ترکیب جدید از header، cache key، route و capability requirement می‌دهد. هیچ verdict از baseline قابل کپی نیست؛ هر لایه باید دوباره از evidence جدید محاسبه شود.
15. منابع، freshness و مرز ادعا
در 2026-09-19 مستندات رسمی Cloudflare دوباره بررسی شدند: Rules همچنان proxied DNS را برای عبور traffic از شبکه Cloudflare لازم می‌داند؛ WAF همچنان rules/rulesets را برای filtering تعریف می‌کند؛ R2 همچنان S3-compatible با تفاوت‌های صریح است؛ و R2 bucketها همچنان private-by-default با Custom Domain برای مسیر cache/public هستند.
مرور بعدی منابع volatile برای 2026-10-17 ثبت شده است. هیچ dashboard state، cache HIT، WAF presence یا S3 familiarity در این درس به‌عنوان proof کلی امنیت یا correctness استفاده نمی‌شود.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
OPS-006-S1 retrieval
Differentiate proxied edge entry, WAF evaluation, cache decision, origin route, and R2 delivery, naming one observable and one non-claim per layer.
OPS-006-S2 application
Complete the layer-by-layer evidence record for the supplied synthetic request using only direct fixture evidence.
OPS-006-S3 diagnosis
Diagnose a WAF false positive, cache anomaly, or route mutation without blaming an unchanged layer.
OPS-006-S4 decision
Choose a bounded cache/WAF/R2 delivery policy and identify the compatibility check, rejected shortcut, and explicit unknowns.
OPS-006-S5 transfer
Rebuild the record for a changed header, WAF outcome, cache key/freshness, route, and R2 capability requirement without copying baseline conclusions.
ملاک‌های ارزیابی (rubric)
| Dimension | Critical | Sufficient evidence |
|---|---|---|
| Edge-layer separation | Yes | Edge ingress, WAF, cache, origin, and R2 delivery are independently justified. |
| WAF/cache evidence discipline | Yes | Rule match/action and cache state/key/freshness are interpreted narrowly. |
| R2 compatibility judgment | Yes | Required behavior is checked against current R2 compatibility evidence. |
| Observation vs inference | Yes | Unsupported application/security/origin claims remain explicitly OPEN. |
| Changed-edge transfer | Yes | New request/rule/cache/route facts are recomputed without copying baseline conclusions. |
Failure: treating proxy/WAF/cache as one green state, using HIT as correctness proof, blaming origin for a WAF-only mutation, assuming R2 is feature-identical to S3, or using public Custom Domain delivery as private-object authorization.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Everything is local and synthetic. No Cloudflare account, DNS zone, credential, public hostname, WAF probing, R2 bucket, or network egress is used.
For each case produce eight states: edge_entry_state, waf_decision_state, cache_decision_state, origin_path_state, r2_delivery_state, compatibility_state, evidence_boundary_state, and recovery_decision_state.
Rules:
- Proxied edge entry is routing evidence, not application correctness.
- A WAF block is a WAF-layer fact unless separate origin evidence exists.
- HIT/MISS/STALE/BYPASS are cache observations; they do not prove correctness or authorization.
- Origin conclusions require route/origin evidence.
- R2 Custom Domain public delivery is separate from private-object authorization.
- R2 capability support must come from the supplied compatibility snapshot.
- Keep direct observation, inference, and unknowns separate.
- The transfer case must be solved from its own header/cache/route/capability facts.
Run python -B run_checks.py for learner-visible structural checks. Hidden acceptance lives outside learner paths.
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)