امنیت api

این مهم بدین معنی است که ارائه‌دهندگان API عموماً باید از اتخاذ وابستگی‌های پیچیده‌ی سیستمی و مدل‌های مدیریتی بیش‌ازحد سفت‌وسخت که نمونه‌ی بارز سیاست‌های نسل پیشین IT بودند، دوری کنند؛ همچنین باید تهدیدات جهان کنونی را درک کرده و سطوح حفاظتی مستحکم ارائه دهند که سد راه استفاده‌ی کاربرانشان نشود. در ادامه، براساس مشاهدات سایت Help Net Security در نتیجه‌ی همکاری با شرکت‌های لیست Fortune 500، چهار مورد از توصیه‌های امنیتی آورده شده است که می‌توانند به تیم‌های API کمک کنند تا در حفظ این تعادل موفق عمل نمایند.

APIهای بدون احراز هویت (Authentication)

APIها کلید دسترسی به دیتابیس سازمان‌ها هستند، از این رو کنترل دسترسی افراد به آن‌ها امری بسیار حیاتی است. استفاده از احراز هویت استاندارد صنعتی و مکانیزم‌های احراز هویتی همچون OAuth/OpenID Connect، در کنار Transport Layer Security یا به اختصار TLS، امری ضروری است.

بررسی Injectionها

Injectionها به‌عنوان یکی از انواع حملات مورد علاقه‌ی مجرمان پدیدار گشته‌اند. این تهدید انواع مختلفی دارد، ولی رایج‌ترین انواع آن Injectionهای SQL، RegEx و XML می‌باشند. APIها باید با آگاهی به این تهدیدات و اتخاذ اقداماتی برای مقابله با آن‌ها طراحی شوند؛ مانیتورینگ فعال و مداوم نیز باید پس از پیاده‌سازی APIها انجام شود تا اطمینان حاصل گردد که هیچ آسیب‌پذیری به کد پیاده‌سازی (Production Code) وارد نشده است.

داده‌های رمزگذاری‌نشده

با افزایش نگرانی‌ها حول موضوع امنیت، رمزگذاری داده‌ها باید برای سازمان‌ها تبدیل به اولویت اول شود. در حالت ایده‌آل، رمزگذاری اطلاعات حساس از نقطه‌ای که داده‌ها شروع به انتقال می‌کنند تا رسیدن به نقطه‌ای که داده‌ها استفاده می‌گردند، انجام می‌پذیرد. APIها به‌عنوان لایه‌ای که داده‌های ارزشمند را میان سیستم‌های Backend رکورد و سیستم‌های Frontend برقراری ارتباط (Engagement) جابه‌جا می‌کنند، نقش مهمی در این فرآیند ایفا می‌نمایند. برای اینکه بتوان از رمزگذاری‌ و حفاظت ابتدایی که توسط TLS فراهم می‌شود و همچنین از مکانیزم‌های احراز هویت فراتر قدم برداشت، ارائه‌دهندگان API باید برای Debug نمودن مشکلات ابزار Trace را به‌کار گرفته، برای Trace/Logنمودن Masking داده‌ها را پیاده‌سازی کرده و برای داده‌های PCI و PII از Tokenization استفاده‌ی بهینه ببرند.

حملات Replay

هنگامی‌که APIها در دسترس عموم قرار می‌گیرند، با چالش مورد اعتماد بودن یا نبودن درخواست‌های دریافتی مواجه می‌شوند و این سوال مطرح می‌گردد که آیا درخواست از سوی یک مشتری است یا از جانب یک مهاجم!

در برخی موارد، حتی اگر API یک درخواست نامطمئن را شناسایی و با موفقیت رد نماید، ممکن است کماکان به کاربری که احتمال دارد مخرب باشد اجازه‌ی تلاش مجدد بدهد و این امر برای بار دوم و سوم و چهارم و … تکرار شود. این بی‌توجهی امنیتی ممکن است به مهاجمان اجازه دهد که تا هنگام موفقیت در دسترسی، یک درخواست کاربری قانونی را Playback یا Replay نمایند. اقدامات امنیتی برای مقابله با چنین حملات جدی شامل Rate-Limit نمودن Policyها برای سرکوب درخواست‌ها، احراز هویت HMAC، احراز هویت Two-Factor و یا یک Token دسترسی کوتاه‌مدت می‌باشد، که توسط OAuth ایجاد شده باشد.

داده‌های موجود در URI

پیاده‌سازی کلید‌های API برای احراز هویت و صدور حق دسترسی اغلب اوقات کارآمد است. اما اگر کلیدها به‌عنوان بخشی از Uniform Resource Identifier یا به عبارتی URI منتقل شده باشند، ممکن است در معرض خطر قرارگیرند. داده‌های حساس همچون کلیدهای API و رمز‌های عبور، ممکن است هنگام پدیدار شدن جزئیات URI در مرورگر یا Logهای سیستم در دسترس مهاجمان قرار بگیرند. یکی از بهترین راه‌های مقابل با این امر ارسال کلیدهای API به‌صورت یک Header پیام‌های احراز هویت می‌باشد، چرا که انجام اینکار از ثبت Log توسط اجزای شبکه جلوگیری به‌عمل می‌آورد. می‌توان جهت انجام اینکار از روش HTTP POST همراه با Payloadهای حامل اطلاعات حساس استفاده نمود.

گسترش کسب و کار، با حفظ امنیت بالا

اغلب می‌توان با دیدگاهی انتقادی نسبت به طراحی API و تثبیت Policyهایی که بتوان در تمامیت کسب‌وکار آن‌ها را پیاده‌سازی کرد تا از تهدیدات احتمالی اجتناب نمود. اگرچه یک رویکرد سریع و مبتنی بر API، اغلب شامل کاهش تمرکز مدیریت IT و اعمال آزادی عمل بیشتر به تیم‌های مجزا در استفاده از منابع ارزشمند می‌باشد، امنیت هیچگاه نمیتواند کنار گذاشته شود. با اینکه که برخی از مشکلات بیان شده ممکن است ساده به ‌نظر برسند، اما به بارها پیش آمده‌اند. ارائه‌دهندگان API با پیروی از اقدامات امنیتی ذکر شده، می‌توانند از نقایص امنیتی دوری نموده و به کسب‌وکار خود کمک نمایند تا از APIهای خود حداکثر استفاده را ببرد.

منبع

https://www.api.ir/