مدل مسوولیت مشترک در CDN
مدل مسوولیت مشترک (Shared Responsibility Model) مشخص میکند کدام بخش از امنیت سرویس CDN برعهدهی آروانکلاد است و کدام بخش بر عهدهی کاربر. آروانکلاد امنیت زیرساخت، یعنی سرورها، شبکه و پلتفرم را تامین میکند و کاربر امنیت تنظیماتی را که روی این زیرساخت انجام میدهد، مانند قوانین فایروال، سیاستهای Cache و دسترسی به سرور مبدا، مدیریت میکند.
| حوزه | مسوولیت آروانکلاد | مسوولیت کاربر |
|---|---|---|
| زیرساخت و سرورهای لبه | امنیت فیزیکی مراکز داده، بهروزرسانی سیستمعامل و Patch آسیبپذیریهای سرورهای لبه | — |
| DDoS لایهی ۳ و ۴ | شناسایی و دفع خودکار حملهها تا ۲ ترابیت بر ثانیه | — |
| DNS | پایداری Nameserverها، اجرای DNSSEC و Key Rotation | مدیریت رکوردها و وضعیت نماد ابر (عبور ترافیک از CDN) |
| فایروال و Rate Limit | فراهم کردن موتور فایروال و محدودیت نرخ درخواست | تعریف قوانین، فهرستهای IP و مسیرهای محدودشده |
| WAF | بهروزرسانی امضاهای حمله در هستهی WAF | تنظیم حساسیت، بررسی لاگها و مدیریت خطاهای مثبت کاذب |
| DDoS لایهی ۷ | فراهم کردن چالشهای Cookie ،JavaScript و Captcha | انتخاب نوع چالش، تنظیم TTL و طراحی صفحههای سفارشی |
| سرور مبدا | — | پنهان نگه داشتن IP، قرار دادن IPهای آروانکلاد در لیست سفید، تنظیم توازن بار و Health Check |
| Cache | ذخیره و ارایهی محتوا بر اساس سیاستهایی که تعیین میکنید | تعیین محتوای قابل Cache و پاکسازی Cache در مواقع نیاز |
| SSL/TLS | صدور و تمدید خودکار گواهی رایگان، بهروزرسانی Cipher Suiteها | فعالسازی HTTPS و HSTS، تعیین حداقل نسخهی TLS، مدیریت گواهی اختصاصی |
| Edge Computing | ایزولهسازی محیط اجرای کد میان مشتریان | امنیت کد، مدیریت اطلاعات حساس و سطح دسترسیها |
| کلیدهای API | ذخیرهی هششدهی کلیدها | نگهداری امن، دسترسی حداقلی و ابطال کلیدهای افشاشده |
| لاگ و متریک | تولید و ارسال لاگها، متریکها و هش JA3 | تحلیل دادهها و واکنش به حملهها |
این دو بخش به هم وابستهاند و ضعف در یکی، دیگری را بیاثر میکند. برای نمونه، آروانکلاد حملههای DDoS را تا ظرفیت ۲ ترابیت بر ثانیه دفع میکند، اما اگر IP سرور مبدا شما آشکار باشد، مهاجم میتواند CDN را دور بزند و مستقیم به سرور حمله کند.
مسوولیتهای آروانکلاد
زیرساخت و سرورهای لبه
آروانکلاد بیش از ۴۰ پاپ سایت با معماری Anycast و توزیع بار جغرافیایی (GSLB) دارد و هر درخواست را از نزدیکترین Node پاسخ میدهد. امنیت فیزیکی مراکز داده، از برق اضطراری، کنترل بیومتریک، دوربین مداربسته و امنیت سیستمهای خنککننده تا جلوگیری از دسترسی غیرمجاز به سختافزار، برعهدهی آروانکلاد و شرکای زیرساختی آن است.
تیمهای مهندسی آروانکلاد سیستمعامل سرورهای لبه را بهروز نگه میدارند، آسیبپذیریهای کرنل را Patch میکنند و نرمافزارهای مسیریابی ترافیک HTTP/HTTPS و پروکسی لایهی ۴ را ایمن میکنند. کاربر به این لایهها دسترسی Root ندارد و در برابر آسیبپذیریهای آنها مسوولیتی ندارد.
دفع حملههای DDoS در لایهی ۳ و ۴
شبکهی آروانکلاد حملههای حجمی و پروتکلی مثل SYN Flood ،UDP Flood و ICMP Flood را تا ظرفیت ۲ ترابیت بر ثانیه بهشکل خودکار و لحظهای شناسایی و مسدود میکند. این محافظت روی سرویسهای CDN و DNS بهطور پیشفرض و رایگان فعال است و به نصب سختافزار یا نرمافزار در شبکهی شما نیازی ندارد. آروانکلاد بستههای مخرب را پیش از رسیدن به سرور شما در لبهی شبکه Drop میکند و ترافیک مشروع را بدون تاخیر محسوس به مقصد میرساند.
DNS و DNSSEC
آروانکلاد زیرساخت Cloud DNS را در برابر حملههایی مثل DNS Amplification و حملهی مستقیم به Nameserverها محافظت میکند و ب ا معماری Anycast از چند نقطهی جغرافیایی به درخواستها پاسخ میدهد. DNSSEC با امضای رمزنگاریشدهی رکوردها جلوی جعل آنها (DNS Spoofing و Cache Poisoning) را میگیرد و مدیریت کلیدها، چرخش کلیدها (Key Rotation) و اجرای درست این پروتکل در سرورهای آروانکلاد بر عهدهی آروانکلاد است. همچنین میتوانید رکوردهای قبلیتان را با Zone File در فرمت BIND منتقل کنید و از سرورهای نام سفارشی (Custom NS) استفاده کنید. آروانکلاد در هر دو حالت دادههای هر مشتری را از مشتریان دیگر ایزوله نگه میدارد.
زیرساخت SSL/TLS
آروانکلاد میتواند برای تمامی دامنههای ثبتشده، گواهی SSL/TLS را بهشکل رایگان و خودکار با اعتبارسنجی DNS صادر و تمدید کند. امنیت تبادل کلید در لبهی شبکه، پشتیبانی از HTTP/2 و بهروزرسانی Cipher Suiteها بر اساس آخرین توصیههای امنیتی و حذف الگوریتمهای آسیبپذیر نیز برعهدهی آروانکلاد است.
محیط اجرای Edge Computing
با Edge Computing میتوانید کدهایتان را بهشکل Serverless در بیش از ۴۰ سایت PoP آروانکلاد اجرا کنید. در این سرویس، کد مشتریان مختلف روی زیرساخت فیزیکی مشترک اجرا میشود. آروانکلاد با Sandboxing و ایزولهسازی فرآیندها جلوی دسترسی یک مشتری به دادهها، متغیرهای محیطی یا منابع مشتری دیگر را میگیرد. تخصیص منابع و حافظه، جلوگیری از حملههای Side-Channel در سطح پردازنده و پایش سلامت محیط اجرای توابع نیز بخشی از همین مسوولیت است.
مسوولیتهای کاربر
بیشتر رخنههای امنیتی در محیطهای ابری از پیکربندی نادرست و مدیریت ضعیف دسترسیها ناشی میشود، نه از ضعف زیرساخت. بخشهای زیر تنظیماتی را توضیح میدهد که مدیریت آنها با کاربر است.
فایروال و محدودسازی نرخ درخواست
آروانکلاد موتور فایروال را فراهم میکند و کاربر منطق مسدودسازی ترافیک را طراحی میکند. بسته به پلن، میتوانید از ۵ تا ۱۰۰۰ قانون فایروال تعریف کنید.
| بخش | مسوولیت کاربر |
|---|---|
| شرطها (Filter Expressions) | ترکیب متغیرهایی مثل آدرس IP، موقعیت جغرافیایی، HTTP Host و متد درخواست برای ساخت قانون |
| اقدام (Action) | انتخاب میان Block ،Allow ،Bypass و Challenge |
| فهرستهای IP | ساخت و بهروزرسانی فهرست آدرسهای مجاز یا مهاجم در پیشخان و استفاده از آنها در قوانین فایروال |
| Rate Limit | تعیین تعداد درخواست مجاز در بازهی زمانی مشخص برای مسیرهای حساس مثل صفحهی ورود یا درگاه پرداخت |
Rate Limit از حملههای Brute-Force، استخراج محتوا (Web Scraping) و سرریز شدن APIها جلوگیری میکند. توجه داشته باشید که Rate Limit فقط درخواستهایی را بررسی میکند که سرور لبه از Cache پاسخ نمیدهد (Miss یا Bypass). ماژولهای امنیتی آروانکلاد نیز با اولویت ثابتی روی هر درخواست اجرا میشوند: ابتدا فایروال، سپس DDoS Protection، پس از آن Rate Limit و در آخر WAF. قوانینتان را با در نظر گرفتن همین ترتیب طراحی کنید.
WAF
موتور WAF آروانکلاد با روش Anomaly Scoring کار میکند. WAF به هر الگوی مشکوک در درخواست امتیازی میدهد و اگر مجموع امتیازها از آستانه (Threshold) بگذرد، درخواست را مسدود میکند. بهروزرسانی امضاهای حمله (Signatures) بر عهدهی آروانکلاد است و پیکربندی، تنظیم دقیق و پایش WAF بر عهدهی کاربر.
جدول زیر مهمترین کدهای حملهای را نشان میدهد که باید لاگهای آنها را بررسی کنید:
| کد | نوع حمله | پیامد تنظیم نادرست |
|---|---|---|
| 41xxx | SQL Injection | افشای دادهها، دسترسی مدیریتی به پایگاه داده و تغییر رکوردها |
| 42xxx | XSS | سرقت نشست کاربر (Session Hijacking) و هدایت کاربران به سایتهای فیشینگ |
| 40xxx | حملههای عمومی مثل LFI و RFI | اجرای فایل مخرب روی سرور مبدا و دسترسی غیرمجاز به فایلهای سیستمی |
| 35xxx | باتهای مخرب | سواستفاده از فرمها، اختلال در آمار سایت و دور زدن قوانین فایروال |
| 20xxx و 21xxx | درخواستهای نامتعارف HTTP | بهرهبرداری از باگهای وبسرور مبدا با هدرهای دستکاریشده |
برای تنظیم حساسیت، یکی از بستههای قوانین مثل CRS (Core Rule Set) یا بستههای مدیریتشدهی آروانکلاد را فعال کنید و سطح حساسیت را تعیین کنید.
توجه داشته باشید که در WAF آروانکلاد هرچه عدد حساسیت کمتر باشد، WAF سختگیرتر عمل میکند و احتمال مسدود شدن درخواستهای کاربران واقعی (False Positive) بیشتر میشود.
پیش از فعال کردن حالت مسدودسازی، WAF را مدتی در حالت شناسایی نگه دارید و لاگها را بررسی کنید تا درخواستهای مشروعی را پیدا کنید که WAF بهاشتباه مخرب تشخیص داده است. سپس قوانین خطادار را با شناسهی (ID) آنها غیرفعال کنید و پس از آن WAF را فعال کنید. بدون این فرآیند، ممکن است WAF تراکنشهای درست کاربران را مسدود کند و نرخ تبدیل کسبوکارتان افت کند.
اگر APIهای شما ساختار دادهی پیچیدهای دارند، با قوانین سفارشی، WAF را برای مسیرهای مشخص یا محدودههای IP مورد اعتماد فعال یا غیرفعال کنید.
توجه داشته باشید که با فعال بودن WAF، حداکثر حجم بدنهی درخواست (Request Body) ۵۲۴٬۲۸۸ بایت است و فرمهای آپلود فایل را باید با در نظر گرفتن این محدودیت طراحی کنید.
DDoS لایهی ۷
حملههای لایهی ۷ رفتار کاربر واقعی را تقلید میکنند و محافظت خودکار لایهی ۳ و ۴ آنها را تشخیص نمیدهد. آروانکلاد چالشهای Cookie ،JavaScript و Captcha را فراهم میکند و کاربر بر اساس شدت حمله، نوع چالش را در پیشخان انتخاب و فعال میکند، از چالش نامحسوس Cookie تا Captcha تعاملی.
زمان اعتبار چالش (TTL) مشخص میکند بازدیدکننده پس از حل چالش تا چه مدت دوباره با آن روبهرو نمیشود. مقدار نامناسب این زمان تجربهی کاربری را مختل میکند.
برای حفظ هویت بصری برندتان، میتوانید HTML صفحههای خطای ۵۰۰ یا صفحهی چالش DDoS را در پنل بارگذاری کنید.
توجه داشته باشید که استفاده از متغیر %Challenge% در این صفحهها الزامی است و آزمایش درستی عملکرد آن برعهدهی تیم شماست.
ایمنسازی سرور مبدا
همهی لایههای دفاعی CDN، از WAF تا Rate Limit و محافظت DDoS، فقط زمانی موثرند که ترافیک از مسیر CDN عبور کند. اگر مهاجم IP سرور مبدا شما را پیدا کند، میتواند آروانکلاد را دور بزند و ترافیک مخرب را مستقیم به سرور بفرستد. به همین دلیل، پنهان نگه داشتن IP سرور مبدا مهمترین مسوولیت شماست.
نماد ابر را برای رکوردهای A و CNAME، بهویژه رکوردهای @ و www، روشن نگه دارید تا ترافیک از لبهی شبکه عبور کند و IP سرور مبدا پنهان بماند.
توجه داشته باشید که روشن کردن نماد ابر برای سرویسهای غیر HTTP/HTTPS مثل ایمیل یا FTP باعث اختلال میشود، پس رکوردهای این سرویسها را جدا مدیریت کنید.
پس از فعالسازی CDN، همهی درخواستها از IPهای آروانکلاد به سرور مبدا میرسند و فایروال محلی سرور ممکن است این ترافیک متمرکز را حمله تشخیص دهد و مسدود کند. برای جلوگیری از این مشکل، IPهای آروانکلاد را در فایروال سرور مبدا در لیست سفید (Whitelist) قرار دهید. همزمان، دسترسی به پورتهای ۸۰ و ۴۴۳ را برای تمامی IPهای دیگر ببندید تا اتصال مستقیم به سرور ممکن نباشد.
اگر چند سرور مبدا دارید، الگوریتم توازن بار را متناسب با معماری نرمافزارتان انتخاب کنید. Round Robin ترافیک را بهنوبت و بهتساوی میان سرورها توزیع میکند و Client IP Hash هر کاربر را بر اساس هش IP او به سرور ثابتی میفرستد که برای حفظ Session کاربر مناسب است.
Active Health Check با User Agent با مقدار Arvancloud-AHC به سرورهای مبدا درخواست میفرستد. کدهای وضعیت (Status Code) و پاسخهای مورد انتظار را دقیق تنظیم کنید تا سرورهای سالم بهاشتباه از مدار خارج نشوند. همچنین با فعال کردن Next Upstream، هنگام بروز خطا، درخواست کاربر به سرور بعدی میرود.
سیاستهای Cache و حریم خصوصی
تصمیم دربارهی اینکه چه محتوایی Cache شود تنها با شماست. یک اشتباه در پیکربندی Cache میتواند اطلاعات هویتی یا مالی یک کاربر را به کاربران دیگر نشان دهد. سیاستهای Cache را از بخش Page Rules در پیشخان یا با هدر Cache-Control در پاسخ سرور مبدا تعیین کنید.
| هدر Cache-Control | رفتار سرور لبه | ملاحظهی امنیتی |
|---|---|---|
| public | محتوا را صرفنظر از سایر دستورها برای همهی کاربران Cache میکند. | برای صفحههای دارای اطلاعات هویتی یا مالی (PII) و محتوای پویا از آن استفاده نکنید. |
| private | محتوا را Cache نمیکند و ذخیرهی آن را فقط به مرورگر کاربر میسپارد. | منا سب صفحهی پروفایل، سبد خرید و داشبوردهای شخصی |
| no-store | محتوا را در هیچ نقطهای از مسیر Cache نمیکند و هر درخواست را از سرور مبدا میگیرد. | مناسب تراکنشهای بانکی و دادههای بسیار محرمانه |
| max-age | زمان انقضای محتوای Cacheشده را تعیین میکند. | مقدار آن را بر اساس سرعت تغییر محتوا تنظیم کنید تا کاربران محتوای قدیمی نبینند. |
| min-uses | محتوا را پس از تعداد مشخصی درخواست Cache میکند. | برای مدیریت منابع لبه در محتوای پربازدید |
اگر محتوایی بهاشتباه Cache و منتشر شد، بلافاصله آن را با Purge Cache برای آدرسهای مشخص یا کل دامنه، از پنل یا از طریق API پاک کنید.
حداکثر حجم قابل Cache برای هر فایل بسته به پلن از ۱۲۸ تا ۲۰۴۸ مگابایت است و بهتر است روش توزیع فایلهای حجیم را با در نظر گرفتن این محدودیت انتخاب کنید.
HTTPS و سیاستهای TLS
آروانکلاد زیرساخت ارتباط امن را فراهم میکند و اعمال س یاستهای سختگیرانهتر با شماست. هدایت خودکار ترافیک HTTP به HTTPS را فعال کنید. همچنین میتوانید HSTS (HTTP Strict Transport Security) را فعال کنید که جلوی حملههای Downgrade و Man-in-the-Middle را میگیرد.
توجه داشته باشید که اگر زمان انقضای HSTS را طولانی تعیین کنید و گواهی سایت دچار مشکل شود، کاربران تا مدت طولانی به سایت دسترسی نخواهند داشت.
اگر در HTML سایتتان لینکهای HTTP وجود دارد، ارتباط امن دچار مشکل Mixed Content میشود. برای رفع آن، قابلیت جایگزینی خودکار لینکها را فعال کنید.
برای تطابق با استانداردهایی مثل PCI-DSS در درگاههای پرداخت، حداقل نسخهی TLS را طوری تنظیم کنید که کلاینتهای قدیمی با پروتکلهای ناامن نتوانند متصل شوند.
اگر بهجای گواهی رایگان آروانکلاد از گواهی اختصاصی استفاده میکنید، میتوانید آن را در قالب فایل PEM بارگذاری کنید. در این حالت، نگهداری امن کلید خصوصی (Private Key) و تمدید بهموقع گواهی پیش از انقضا بر عهدهی شماست.
امنیت کد در Edge Computing
آروانکلاد امنیت محیط اجرای کدهای JavaScript در لبه را تضمین میکند، اما امنیت منطق کدی که شما مینویسید با خود شماست. با اسکریپتهای لبه میتوانید ترافیک را بر اساس موقعیت جغرافیایی کاربر (GeoIP) یا هدرهای درخواست مسیریابی کنید یا دادهها را مستقیم از لبهی شبکه در فضای ابری آروانکلاد بارگذاری کنید. مثلن اگر در اسکریپت لبه از HTTP Basic Authentication استفاده کنید، اسکریپت نام کاربری و رمز عبور را بدون رمزنگاری ارسال میکند. در این حالت مطمین شوید که ارتباط فقط روی HTTPS برقرار میشود و اطلاعات حساس را در کد Hardcode نکنید. هر نفوذی که از باگ منطقی، استفادهی ناامن از متغیرها یا ثبت اطلاعات حساس در لاگهای لبه ناشی شود، بر عهدهی شماست.
اگر کد لبه به فضای ابری آروانکلاد متصل است، تعیین سطح دسترسی باکتها (Bucket Policy) نیز با شماست. توجه داشته باشید که عمومی کردن یک باکت، فهرست آبجکتهای درون آن را برای همه آشکار میکند.
کلیدهای API و اپلیکیشنهای جانبی
برای کار با API ،CLI یا Terraform باید کلید دسترسی (Access Key) بسازید. این کلیدها عملن مثل رمز عبور مدیریت زیرساخت هستند. کلیدها را امن نگه دارید، آنها را در کدهای عمومی مثل مخازن GitHub قرار ندهید و برای Machine Userها از اصل حداقل دسترسی (Least Privilege) پیروی کنید.
آروانکلاد کلیدها را بهشکل هششده ذخیره میکند و پس از اولین نمایش، امکان بازیابی آنها وجود ندارد. اگر احتمال میدهید کلیدی افشا شده است، بلافاصله آن را از پیشخان ابطال و حذف کنید.
حوزههای مشترک: لاگ، متریک و تحلیل ترافیک
در این حوزه آروانکلاد دادههای امنیتی را تولید و ارسال میکند و شما آنها را تحلیل میکنید و بر اساس آنها اقدام میکنید.
آروانکلاد لاگها را با Log Forwarding و متریکهای سری زمانی را با Metric Exporter ارسال میکند. متریکها سبک و ساختارمندند و برای پایش لحظهای و ساخت هشدار در ابزارهایی مثل Grafana ،Prometheus و Splunk مناسباند. سرورهای لبه همچنین هدرهای X-Real-IP (آدرس IP واقعی کاربر)، X-Country-Code (کد کشور)، X-Forwarded-Proto (پروتکل اولیهی ارتباط) و X-Request-Id (شناسهی یکتای درخواست) را به درخواستها اضافه میکنند. تحلی ل این دادهها بر عهدهی تیم امنیت شماست و متریکهای زیر را باید بهطور مستمر پایش کنید:
| متریک | کاربرد |
|---|---|
| firewall_rule_matched_count | تعداد درخواستهای منطبق با قوانین فایروال، برای شناسایی موج جدید حمله یا اشکال در قوانین |
| rate_limit_action_count | تعداد دفعات اعمال Rate Limit. افزایش ناگهانی آن نشانهی حملهی Brute-Force یا Scraping است. |
| ddos_challenge_action_count | تعداد نمایش چالشهای DDoS، برای اطمینان از عملکرد درست دفاع لایهی ۷ بدون اختلال در تجربهی کاربری |
| top_request_tlsfingerprint | ۱۰ اثرانگشت TLS با بیشترین ترافیک، برای شناسایی باتنتهایی با رفتار یکسان |
آروانکلاد در زمان TLS Handshake پارامترهایی مثل نسخهی TLS، فهرست Cipher Suiteها، افزونهها و منحنیهای بیضوی کلاینت را تحلیل میکند و از آنها هش یکتای JA3 میسازد و در لاگها قرار میدهد. مهاجمان میتوانند IP، User-Agent و هدرهای HTTP را بهسادگی تغییر دهند، اما هش JA3 باتنت معمولن ثابت میماند. اگر در لاگها ببینید یک هش JA3 از IPهای متفاوت حجم زیادی درخواست مخرب میفرستد، با یک قانون فایروال در پ یشخان همان هش را مسدود کنید تا کل باتنت بدون آسیب به کاربران واقعی متوقف شود.