با رشد سیستم‌های متصل و میکروسرویس‌ها، روزبه‌روز داده‌های بیشتری با استفاده از احراز هویت APIها بین سرویس‌ها جابه‌جا می‌شود. احراز هویت برای یک API تعریف می‌کند که چه کسی اجازه‌ی دسترسی به داده‌های ایمن یا Endpointها را دارد. این امر به‌خصوص برای APIهایی که اطلاعات حساس را به اشتراک می‌گذارند و برای APIهایی که به کاربران نهایی اجازه می‌دهند تغییراتی را ایجاد کنند یا برای شرکت‌هایی که هزینه‌ای را برای دسترسی از طریق API دریافت می‌کنند مهم است. بااینکه ایمن‌سازی یک API برای یک کاربر نهایی اقدام مهمی است، جهت احراز هویت سیستم‌ها برای تعداد بیشتری از نهادهای غیرانسانی ملاحظات بیشتری لازم است.
با ایمن‌تر شدن APIها، سیستم‌های مانیتورینگ پیشگیرانه نیز خود را تطبیق می‌دهند تا بتوان به‌صورت خارجی با اهدافی که در پایین به آن اشاره شده است به سیستم‌های ایمن دسترسی پیدا کرد.
- تست عملکرد و قابلیت‌های سیستم‌های احراز هویت
- تست سرعت، عملکرد و قابلیت اطمینان تراکنش‌های API در سمت دیگر احراز هویت.
دو نوع اصلی از پروتکل‌های احراز هویت API
- احراز هویت مستقیم: کاربران نهایی احراز هویت‌ها یا یک Key را مستقیماً در یک API ثبت می‌کنند تا بتوانند به Endpointها یا داده‌های ایمن دسترسی پیدا کنند.
- احراز هویت مبتنی بر Ticket: کاربران نهایی اطلاعات اعتباری را در یک سرور احراز هویت مرکزی ثبت می‌کنند که یک Ticket یا Token را فراهم می‌نماید که با استفاده از آن‌ها می‌توان به Endpointها یا داده‌های به‌خصوص دسترسی پیدا کرد.
در ادامه برخی از جزئیات سطح بالا در مورد هر نوع از احراز هویت بررسی می‌گردد و خواهیم دید که سیستم‌های مانیتورینگ فعال چطور میتوانند پیکربندی شوند تا APIهای ایمن شده توسط هر نوع از احراز هویت، مانیتور شوند.
احراز هویت مستقیم
مثال خوبی از احراز هویت مستقیم، HTTP Basic Authentication است. HTTP Basic Authentication بخشی استاندارد از HTTP می‌باشد و می‌تواند برای API Endpointها یا هر HTTP URLی مورد استفاده قرار بگیرد. صرفاً لازم است یک نام کاربری و رمز عبور که در base64 رمزگذاری می‌گردند به‌عنوان بخشی از درخواست، به API ارسال گردند. مزیت HTTP Basic Authentication این ست که به سادگی می‌توان آن را پیاده‌سازی و کرد و معمولاً در چارچوب‌های استاندارد قرار می‌گیرد. اما مشکلش این است که هیچ امکانات پیشرفته‌ای ارائه نمی‌دهد و ممکن است به سادگی رمزگشایی شود.
بیشتر بخوانید: چهار آسیب‌پذیری API و روش های پیشگیری از وقوع آن‌ها
مثال دیگری از احراز هویت مستقیم استفاده از API Keyها یا Tokenها است. API Keyها رشته‌ای طولانی از ارقام هگزادسیمال هستند، مثلاً 34d83d84f28d146aeae0e32f7803c88d که می‌توان آن را به‌جای نام کاربری یا رمز عبور ارسال کرد تا دسترسی به یک API Endpoint احراز هویت شود. API Keyها در واقع مشابه مجموعه‌ای از نام‌ها کاربری و رمزهای عبور هستند، اما لایه‌ای از جداسازی فراهم می‌کنند که مفید است. برای مثال چندین کاربر نهایی میتوانند یک API Key مشترک داشته باشند.
وقتی از هر نوعی از احراز هویت مستقیم استفاده شود، مهم است که از SSL/TLS یا https:// در ابتدای API Endpoint URL استفاده گردد. استفاده از SSL/TLS اطمینان حاصل می‌کند که اطلاعات اعتباری HTTP Basic Authentication یا API Keyها در URL در معرض خطر نیستند.
مانیتور کردن APIها با HTTP Basic Authentication
اگر فردی از Basic Authentication برای ایمن‌سازی APIهای خود استفاده کند، بهره بردن از آن احراز هویت در زمان پیکربندی یک مانیتور خارجی برای چک کردن عملکرد API بسیار ساده است. فقط کافی است نام کاربری و رمز عبور در Request Headerها قرار بگیرند.
برخی از سیستم‌ها یک نام کاربری و رمز عبور را مستقیماً در رشته‌ی URL قبول کرده و آن را به یک Authorization Request Header تبدیل می‌نمایند:
متداول‌ترین و قابل‌اطمینان‌ترین راه برای تنظیم یک درخواست مانیتورینگ از طریق HTTP Basic Authentication این است که username:password در base64 رمزگذاری شود و سپس به Authorization Header ارسال گردد:
باید توجه شود که هرچند رمزگذاری نام‌های کاربری و رمزهای عبور در base64 آسان است، برعکس کردن این فرایند یا رمزگشایی هم بسیار ساده است و اینگونه یک سیستم می‌تواند درخواستی را احراز هویت کند. هر فردی می‌تواند به‌تنهایی با یک base64 Encoder/Decoder آنلاین این کار را انجام دهد. از آن‌جایی که base64 بسیار قابل‌دسترسی است، مهم است که با SSL/TLS از این نوع احراز هویت مستقیم محافظت گردد.
مانیتور کردن APIها با API Keyها
از دیدگاه مانیتورینگ، همسان‌سازی فرایند برخورد یک API Key به یک Endpointدر URL یا Request Headerها نسبتاً ساده است. Key باید فراهم گردد و باید به یاد داشت که اگر تغییر کند، پیکربندی تست مانیتورینگ نیز باید عوض شود.
باید توجه کرد که سیستم‌های مختلف ممکن است API Keyها را به شیوه‌های مختلفی بپذیرند، مثلاً به‌عنوان بخشی از داده‌های POST به‌جای یک Request Header پس افراد باید آن API که مانیتور می‌کنند را بررسی کنند تا درک نمایند که انتقال درست API Key چگونه است.
احراز هویت براساس Ticket
بااینکه به کارگیری احراز هویت مستقیم قطعاً مزایایی دارد، ممکن است نیاز باشد که یک لایه امنیتی به APIها اضافه گردد. سیستم‌های احراز هویت براساس Ticket به سرورهای احراز هویت مرکزی تکیه می‌کنند که به‌عنوان واسطه عمل می‌نمایند و اطلاعات اعتباری را از کاربران نهایی می‌پذیرند، سپس Ticketها، Tokenها یا Keyهایی را پس می‌فرستند که به یک کاربر نهایی به‌خصوص اجازه می‌دهد فقط به داده‌های ایمن به‌خصوص دسترسی داشته باشد. احراز هویت براساس Ticket برای هر سناریویی ایده‌آل است که در آن از اطلاعات حساس حفاظت شود و به یک API این توانایی داده شود که Objectهایی را ایجاد کرده یا تغییراتی را اعمال نماید یا در سناریویی که برای استفاده از API هزینه دریافت گردد.
درک سیستم‌های بر اساس Ticket
می‌توان احراز هویت براساس Ticket را مشابه گرفتن کلید برای تست کردن وسایل نقلیه دانست. فرضاً کسی ماشین قراضه‌ی خود را برای فروش می‌گذارد. خریدار با او ملاقات می‌کند تا ماشین او را تست کند. خریدار گواهینامه‌ی خود را به فروشنده نشان می‌دهد. فروشنده می‌گوید: «سلام! به نظر می‌رسد که تو آدم خوبی هستی که من در اینترنت با او آشنا شدم. کاملاً به تو اعتماد دارم. بفرمایید این هم کلید. یک دوری با ماشین بزن و چند دقیقه‌ی دیگر برگرد.» این کار مشابه احراز هویت مستقیم است، به این صورت که فروشنده براساس نام خریدار کلید ماشین را مستقیماً به او می‌دهد.
حالا تصور می‌کنیم که فروشنده‌ی یک خودروی لوکس را از یک نمایندگی می‌فروشد. خریدار او را در نمایندگی می‌بیند و گواهینامه‌ی خود را به او می‌دهد. فروشنده کلیدی ندارد که برای تمام خودروهای نمایندگی کار کند. او باید گواهینامه‌ی خریدار را بگیرد و با استفاده از آن اطلاعات خریدار را در یک سیستم کامپیوتری ثبت کند که مشخص شود خریدار فرد محترمی است. این کار قفل جعبه‌ای را باز می‌کند که فروشنده می‌تواند کلیدی را از آن بیرون بیاورد که فقط برای خودرویی کار می‌کند که خریدار اجازه‌ی رانندگی با آن را دارد. این کار مشابه یک سیستم براساس Ticket است، زیرا فروشنده به یک سیستم متمرکز اتکا می‌کند که می‌تواند یک Key را توزیع کند که اکنون از طریق Ticket به خریدار متصل است.
OAuth، Kerberos، Single Sign On و Webformها همگی مثال‌هایی از سیستم‌های احراز هویت براساس Ticket هستند. افراد حتی میتوانند سیستم احراز هویت سفارشی خودشان را ایجاد کنند. بااینکه راه‌های زیادی برای پیاده‌سازی این نوع پروتکل وجود دارد، اکثر سیستم‌های مبتنی بر Ticket دارای ساختار مشابهی هستند، به این صورت که در ابتدا درخواستی برای یک Ticket یا Token انجام می‌شود و سپس با استفاده از آن Ticket یا Token دسترسی به Endpointها یا داده‌های ایمن حاصل می‌گردد.
Ticketها در سیستم‌های احراز هویت براساس Ticket بسیار شبیه به API Keyهایی هستند که بالاتر در موردشان صحبت شد. یکی از تفاوت‌های اصلی بین این دو مورد این است که Ticketها کوتاه‌مدت می‌باشند. این Ticketها برای مدت کوتاهی معتبر می‌باشند و به‌راحتی می‌توان آن‌ها را لغو کرد که این امر یک لایه‌ی امنیتی اضافی را فراهم می‌کند.
مانیتور کردن APIها با احراز هویت براساس Ticket
برای اینکه بتوان به‌طور کارآمدی یک API را که از احراز هویت براساس Ticket استفاده می‌کند مانیتور کرد، باید بتوان چندین مرحله را طی کرد و Ticket یا Token را در یک متغیر ذخیره نمود که در مراحل بعدی مورد استفاده قرار بگیرد.
مثالی ساده از این کار عبارت است از اینکه درخواستی با یک نام کاربری و رمز عبور انجام شود و مشخصاتی در Header وارد شود، سپس Token از سیستم بازیابی گردد، آن Token به‌عنوان یک متغیر ذخیره شود و درخواست دیگری با آن Token به‌عنوان Header به یک Endpoint انجام شود.
بسیار مهم است که نوعی احراز هویت برای API پیاده‌سازی شود تا از داده‌ها و سیستم‌ها حفاظت گردد. همراه با افزایش امنیت باید اطمینان حاصل کرد که سیستم‌های مانیتورینگ خارجی نیز دارای اجازه و قابلیت مانیتورینگ عملکرد و قابلیت اطمینان سیستم باشند. اگر عملکرد API فقط از سمت برنامه کاربردی مانیتور شود، ممکن است بسیاری از مشکلات اتصال از دید مخفی بمانند و این امر باعث شود کاربران نهایی نتوانند به داده‌ها دسترسی پیدا کنند یا از طریق API تغییراتی را اعمال کنند.
