API را نباید مثل یک صفحه وب معمولی پشت WAF گذاشت و انتظار داشت همه چیز خودکار درست شود. رفتار API قابل تکرارتر است، اما حساستر هم هست: format درخواست، headerها، token، method، rate، endpoint و پاسخ خطا همگی معنی دارند. اگر WAF بدون شناخت این رفتار فعال شود، یا حملهها را خوب نمیبیند، یا سرویس سالم را قطع میکند.
طراحی Policy برای API یعنی اول بدانیم API چه کاری میکند، چه clientهایی دارد، چه endpointهایی عمومیاند، کدام مسیرها حساساند، و چه تفاوتی بین خطای امنیتی و خطای عادی application وجود دارد. در FortiWeb، F5 ASM یا هر WAF دیگر، ابزار فقط وقتی خوب کار میکند که policy با منطق سرویس هماهنگ باشد.
اول مسیر API را از وب جدا کنید
اگر API و وبسایت روی یک host هستند، بهتر است مسیرهای API جدا دیده شوند. endpointهای API معمولاً methodهای مشخص، responseهای ساختاریافته و الگوی ترافیک متفاوت دارند. یک form وب ممکن است رفتار انسانی داشته باشد، اما API ممکن است در چند ثانیه صدها درخواست معتبر بگیرد. اگر policy این تفاوت را نبیند، rate limit یا signatureها ممکن است اشتباه عمل کنند.
- endpointهای حساس مثل login، payment، upload و admin را جدا کنید.
- methodهای مجاز برای هر endpoint را مشخص کنید.
- Content-Type و ساختار JSON را تا حد امکان محدود کنید.
- token و headerهای احراز هویت را در طراحی policy لحاظ کنید.
- برای rate limit، رفتار واقعی clientها را قبل از block کامل ببینید.
از Monitor شروع کنید، اما همانجا نمانید
در APIهای production، شروع با حالت monitor منطقی است. باید چند روز یا چند چرخه کاری رفتار واقعی دیده شود: چه درخواستهایی پرتکرارند، کدام خطاها طبیعیاند، چه bot یا clientهایی وجود دارند و چه endpointهایی بیشتر حساساند. اما monitor نباید تبدیل به وضعیت دائمی شود. بعد از جمعآوری شواهد، باید policy مرحلهای وارد حالت enforce شود.
اشتباه رایج این است که بعد از چند false positive، کل protection ضعیف میشود. روش بهتر این است که exceptionها دقیق باشند: برای یک path، یک پارامتر، یک method یا یک client مشخص. exception گسترده روی کل API، WAF را از همان جایی که باید مفید باشد کور میکند.
Rate Limit همیشه ضد حمله نیست
Rate limit اگر بدون شناخت business logic تنظیم شود، کاربر واقعی یا سیستم داخلی را قطع میکند. بعضی APIها batch دارند، بعضی mobile appها در شروع session چند درخواست پشت سر هم میفرستند، و بعضی integrationها در زمان خاصی ترافیک بالاتری دارند. پس rate limit باید با تفکیک endpoint، client، IP، token یا رفتار واقعی تنظیم شود، نه با یک عدد عمومی برای کل دامنه.
گزارش قابل استفاده از طراحی API WAF
خروجی طراحی باید بگوید کدام endpointها حساساند، چه policyهایی برای هر گروه فعال است، کدام موارد هنوز monitor هستند، چه exceptionهایی ساخته شده و چرا، چه چیزی به SIEM ارسال میشود، و در صورت خطای کاربر چطور مسیر عیبیابی انجام میشود. بدون این مستندات، WAF بعد از چند ماه تبدیل به مجموعهای از exceptionهای نامفهوم میشود.
این مطلب ادامه طبیعی حفاظت API با FortiWeb و Tuning WAF برای API است. اگر هدف شما انتخاب یا پیادهسازی WAF است، صفحه مشاوره و پیادهسازی WAF مسیر کلیتری برای شروع پروژه میدهد.
تست WAF برای API باید شبیه مصرف واقعی باشد
اگر تست فقط با چند درخواست دستی انجام شود، رفتار واقعی API دیده نمیشود. بهتر است نمونههایی از clientهای واقعی، mobile app، سیستمهای داخلی و integrationها در بازه monitor بررسی شوند. ممکن است یک endpoint در تست دستی آرام باشد اما در ابتدای هر ساعت batch بگیرد. ممکن است یک header در نسخه جدید application تغییر کند و WAF آن را غیرعادی ببیند. این جزئیات برای تنظیم امن WAF مهماند.
بهتر است قبل از enforce کامل، معیار موفقیت هم نوشته شود: چه خطاهایی پذیرفتنی است، چه rateای برای هر endpoint طبیعی است، چه signatureهایی باید فقط alert بدهند و چه چیزهایی باید block شوند. اگر این معیارها روشن نباشد، هر false positive باعث عقبنشینی زیاد میشود و هر حمله کوچک باعث سختگیری عجولانه. طراحی خوب بین این دو افراط حرکت میکند.
برای اینکه این موضوع در اجرا هم نتیجه بدهد، بهتر است بعد از هر تغییر یک شاخص ساده برای موفقیت داشته باشیم: آیا سرویس سالم مانده، آیا لاگ کافی داریم، آیا مسیر rollback روشن است، و آیا تیم فنی میتواند سه ماه بعد دلیل این تصمیم را بفهمد؟ اگر جواب این سؤالها مثبت نباشد، حتی تغییر درست هم در نگهداری روزمره دردسر میسازد.
همین نگاه ساده جلوی کارهای نمایشی را میگیرد. معیار موفقیت باید در شبکه واقعی قابل مشاهده باشد، نه فقط در متن گزارش.
در کار اجرایی، یک نکته دیگر هم مهم است: هر پیشنهاد باید صاحب، زمان بازبینی و سطح ریسک داشته باشد. اگر پیشنهادی این سه مورد را ندارد، احتمالاً هنوز برای اجرا آماده نیست. این کار متن را از توصیه عمومی جدا میکند و به برنامهای تبدیل میکند که تیم فنی میتواند آن را مرحلهبهمرحله دنبال کند.
