مدل پنیر سوئیسی
این مدل یک سیستم را بهصورت یک پشته از برشهای پنیر سوئیسی نشان میدهد، که هر برش نشاندهنده یک مانع یا سپر در برابر شکست است. جیمز ریزن آن را بهعنوان یک استعاره برای اینکه چگونه سیستمهای پیچیده میتوانند شکست بخورند توسعه داد. سوراخهای پنیر نشاندهنده ضعفهایی در موانع هستند بهطوری که چیزها میتوانند از لایههای امنیتی شما عبور کنند. سوراخها بهصورت تصادفی توزیع شدهاند همانطور که باید در یک قطعه پنیر سوئیسی باشند. اما زمانی که پنیرها را در یک خط قرار میدهید، وقتی سوراخها در برشها تراز میشوند، یک خطر میتواند از تمام موانع عبور کرده و باعث شکست شود. شما به لایههای متعدد نیاز دارید تا شانس خود را در مسدودسازی تهدیدات افزایش دهید.
کاربرد مدل پنیر سوئیسی در مدیریت API
لایههای پنیر سوئیسی ما برای مدیریت API باید بسیاری از موارد را پوشش دهند. ما در برابر افراد مخرب با نیت خاص محافظت میکنیم. همچنین با ویژگیهای انسانی مانند سطح مهارت، هوش، انگیزه، انرژی و … سروکار داریم. اینجاست که این مدل شروع به برجستهکردن عوامل مختلفی میکند که باید هنگام امنیت API در نظر بگیرید. انسانها اشتباه میکنند. ما میدانیم نرمافزاری که استفاده میکنیم کامل نیست و ممکن است دارای باگهای قابل سوءاستفاده باشد. همه اینها ناشناختههایی هستند که باید با آنها مقابله کرد.
نمیتوانیم بر API بهعنوان تنها نقطهای که هر ضعفی در آن خواهد بود تمرکز کنیم. حقیقت این است که این ریسکها متفاوت ظاهر میشوند و بخشهای مختلف پشته را تحتتأثیر قرار میدهند.
در مدل پنیر سوئیسی برای امنیت API، من ۱۱ لایه قرار دادهام و یک لایه اضافی در انتها. ما از دو نوع پنیر استفاده خواهیم کرد –
۱. پنیر سوئیسی فناوری
- سیستمهای سختافزاری و نرمافزاری
- فریمورکهایی که روی این سیستمها اجرا میشوند
۲. پنیر سوئیسی انسانی
- رانندههای کسبوکار
- طرز فکر و انگیزه
ما چندین برش خواهیم داشت که هرکدام کار یا فعالیت متفاوتی انجام میدهند.
پنیر سوئیسی فناوری
لایه شبکه
این لایه بیرونی ابتدایی امنیت است. این لایه کمی بیش از حد مورد اتکا قرار میگیرد.
پیکربندی DNS / IP
فایروال برنامه وب
بالانس بار
پیکربندی محیط ویژه فضای ابری
لایه احراز
در این لایه بسیاری از موارد اتفاق میافتد. این فقط احراز هویت نیست، بلکه همچنین مجوز دسترسی به دادهها است.
این لایه بسیاری از پرسوناها را پوشش میدهد: مصرفکنندگان API، مهندسان، ادمینها و ذینفعان تجاری در برنامه API شما. این یک لایه مهم است زیرا بر دسترسی برای اجرای APIها و فراخوانی APIهای دیگر، منابع و پلتفرمها تأثیر میگذارد.
لایه پروتکل
این لایه قوانین تعامل را از طریق مواردی مانند مشخصات API تعیین میکند. همچنین میتواند به مهاجمان اطلاعاتی درباره نحوه کار سیستم شما بدهد. اما یک لایه محافظ است و از بازبودن کامل سیستمها جلوگیری میکند.
لایه درگاه (Gateway Layer)
در این لایه درخواستهای API پردازش میشوند. اغلب تصور میشود این همان لایهای است که API در آن وجود دارد، اما این درست نیست. یک API چیزی بیشتر از یک پروکسی است.
لایه نظارت
ممکن است چندین لایه نظارتی وجود داشته باشد. فناوری به تنهایی کافی نیست. شما نمیتوانید فقط یک لایه نظارت بگذارید؛ بلکه نیاز به برنامهریزی و تلاش زیاد دارید تا اطمینان حاصل کنید چیزهای درست تحت نظارت هستند و هشدارهای درست تنظیم شدهاند. شما نیاز به ابزاری دارید که کمککننده باشد نه مانع.
لایه CI/CD
یکی از حیاتیترین لایههاست. این فرصت شماست تا اطمینان حاصل کنید که سیاستهای امنیتی، دستورالعملهای طراحی و … برای هر API بهدرستی اجرا شدهاند. اینجاست که با اتوماسیون خطای انسانی را کاهش میدهید و یکپارچگی ایجاد میکنید.
لایه پلتفرم مدیریت API
یک مجموعه ابزار که امکان پیکربندی و توسعه امنیت API را میدهد. بسته به پلتفرم API یا تکنیکی که استفاده میکنید، ممکن است حتی این لایه را نداشته باشید. شاید یک محصول درگاه عمومیتر استفاده کنید. ممکن است بسیاری از قابلیتهای امنیتی موجود در این ویژگیها را از دست بدهید.
لایه سرویس
این بخش یکپارچهسازی است که چیزها را کنار هم نگه میدارد.
پنیر سوئیسی انسانی
لایه مستندسازی توسعهدهنده
هرآنچه میتوانید برای آموزش افرادی که مسئول کار روی پلتفرم API هستند انجام دهید. نیاز به دستورالعملهای عالی برای توسعهدهندگان دارید تا تیم از آنها استفاده کرده و رعایت کند. خط CI/CD باید بررسیهایی را برای هرآنچه در دستورالعملها دارید اعمال کند. اما نمیتواند مهمترین لایه باشد، زیرا ممکن است تیم را آموزش دهید، اما نمیتواند امنیت را اعمال کند.
مدل عملیاتی
این مدل اطمینان میدهد کسبوکار شرایط ایجاد امنیت مناسب API را فراهم میکند. این مربوط به این است که کسبوکار در چرخه عمر API دخیل باشد و تیم درست در اطراف آن ایجاد شود، بهجای اینکه آن را فقط یک وظیفه IT بدانند. یک مدل عملیاتی قوی برای API حیاتی است تا بهترین شیوههای امنیتی همواره رعایت شود. این همه درباره حاکمیت است.
مدل ذهنیت کسبوکار
این یک لایه ظریف ولی بسیار تأثیرگذار است. این لایه تعیین میکند کسبوکار و مدیریت چگونه امنیت API را ترویج میدهند.
لایه جامعه (لایه پاداش)
جامعه API شامل بلاگرها، هکرهای کلاهسفید، پژوهشگران و مبلغان است. این به ایجاد امنیت کمک میکند.
پنیر سوئیسی در عمل
بیایید چند نمونه که در OWASP 10 پوشش داده شده در نظر بگیریم –
یک مهاجم که سعی میکند دسترسی غیرمجاز برای اجرای APIها کسب کند
یک مهاجم که تلاش میکند الگوهای واضح در شناسهها و کدها را از طریق حمله شمارشی سوءاستفاده کند
مهاجمی که سعی میکند SQL را در API شما وارد کند تا پایگاهداده را فریب دهد (حمله تزریق SQL)
حمله ۱ – کسب دسترسی غیرمجاز
مهاجم تلاش میکند به اطلاعاتی دسترسی پیدا کند که هویت او نباید اجازه آن را بدهد. درخواست ممکن است مشروع بهنظر برسد زیرا شاید از قبل حساب کاربری داشته باشد، یا مهاجم شاید تلاش به زور برای شناسهها و رمزها جهت ورود به حسابهای دیگر کند.
مهاجم ما انواع حملات مرتبط با احراز را امتحان میکند و لایه احراز بیشتر مشکلات را برطرف میکند. لایه پروتکل سختگیریهای OAuth را برای دسترسی به سیستم تعریف کرده است. لایه درگاه دسترسی غیرمجاز را مسدود میکند. لایه نظارت الگوهای غیرعادی پارامترها، ترافیک و تلاشها را تشخیص میدهد. لایه CI/CD باید جلوی استقرار هر کد قابل سوءاستفاده در احراز را بگیرد. لایه پلتفرم API ابزارهایی برای پیادهسازی مدل احراز انتخابی فراهم کرده است. لایه سرویس امکان بررسیهای عمیقتر احراز هنگام فراخوانی سرویسها را میدهد. لایههای انسانی اطمینان میدهند توسعهدهندگان بهترین شیوهها را بدانند و کسبوکار از آنها حمایت کند.
حمله ۲ – حمله شمارشی
مهاجم به سیستم دسترسی دارد و تلاش میکند با حدس شناسهها در درخواستها، یا استخراج دادهها برای یافتن الگو در شناسهها، درخواستها را دستکاری کند.
نمیتوان انتظار داشت که WAF یا سرور احراز ابتدا از این جلوگیری کند. اما از لایه پروتکل میتوان شروع به ایمنسازی کد کرد. لایه درگاه ممکن است به این درخواستها پاسخ منفی دهد و ثبت در سطح نظارت انجام شود. امیدواریم لایه CI/CD و پلتفرم API ابزارهای توسعهدهنده لازم برای امنیت را فراهم کرده باشند.
حمله ۳ – حمله تزریق SQL
درخواستها مشروع بهنظر میرسند. اما درگاه مشکوک میشود. دستورات SQL را فیلتر کرده و احتمالاً درخواست را مسدود میکند زیرا شما توانستهاید API خود را با بررسیها و فیلترهای پایه پیادهسازی کنید. درگاه لایه نظارت را مطلع میکند و نظارت نیز کسبوکار را هشدار میدهد.
این مثالها نشان دادند چگونه روش پنیر سوئیسی بهعنوان یک راه برای فکر کردن درباره امنیت API مفید است.
آنچه میبینیم در حال رخ دادن است
این مدل از مشاهده اجرای امنیت در لایههای اشتباه یا انجام کار اشتباه در لایه اشتباه الهام گرفته است. این مشکلات حتی در سازمانهای بزرگ دیده میشود:
- تشخیص همهچیز در WAF
- تیم امنیت تلاش به تشخیص و رفع همهچیز در سطح خود
- لایه احراز دارای احراز اولیه، حسابهای مشترک، مجوزهای گسترده، رمزهای بیکیفیت و …
- ممکن است طبقهبندی API بهدرستی در لایه پروتکل تعریف نشده باشد
- لایه درگاه ممکن است برای امنیت پیکربندی نشده باشد
- لایه نظارت بعداً ساخته شده و بیشتر روی هشدارهای سیستمی تمرکز دارد تا رویدادهای امنیتی
- لایه سرویس ممکن است دارای سرویسهای شخص ثالثی باشد که خاص برنامه نیستند
- در لایههای انسانی دستورالعملهای توسعهدهنده ضعیف و سبک ناسازگار دیده میشود
- ذهنیت کسبوکار این است که امنیت فقط یک مشکل فنی IT است نه یک مشکل تجاری
آنچه باید اتفاق بیفتد
اگر با مدل پنیر سوئیسی فکر کنیم،
- به لایهها فکر کنید
- بپذیرید که نمیتوانید همهچیز را با یک ابزار تشخیص دهید
- اجازه دهید هر لایه کار خود را انجام دهد
- زمان صرف کنید تا تیمهای خود را متحد کنید و امنیت را در هر لایه نهادینه کنید
- از تمام امکاناتی که پلتفرم API و ابزارهای دیگر ارائه میدهند استفاده کنید
- مطمئن شوید مهندسان و کسبوکار زمان دارند روی هر لایه تمرکز کنند
این یک روش جدید برای تفکر درباره امنیت API است، شاید روشی که بتواند کسبوکار یا مشتریان شما را در توسعه امنیت جامعتر API متحد سازد.
