وضعیت فعلی
بر اساس گزارش تحقیقاتی امنیت سایبری CDW در سال ۲۰۲۴، حدود ۶۹٪ از شرکتهای فعال در حوزه خدمات مالی طی پنج سال گذشته حداقل یک رخداد نشت داده را تجربه کردهاند. این رقم در مقایسه با حدود دو سوم کل سازمانها، نشاندهنده ریسک بالاتر نقض امنیت در بخش مالی است.
با حرکت روزافزون کسبوکارها – بهویژه در صنعت خدمات مالی – به سمت APIهای مبتنی بر رویداد (Event-driven APIs)، نیاز به راهکارهای امن بیش از هر زمان دیگری اهمیت پیدا میکند.
سادهسازی امنیت
ایمنسازی معماریهای مبتنی بر رویداد میتواند با تکیه بر اصول شناختهشده مدیریت API سادهتر شود. چنین رویکردی به شما امکان میدهد مدیریت رویدادها و یکپارچهسازی رویدادهای بلادرنگ را بدون پیچیدگیهای مرسوم انجام دهید. این موضوع فرصتهای جذابی را برای شناسایی و جلوگیری از فعالیتهای متقلبانه در تراکنشهای مالی، آن هم بهصورت لحظهای، فراهم میکند.
فعالیتهای متقلبانه میتوانند شامل استفاده از اطلاعات کارتهای اعتباری سرقتشده، تراکنشهای غیرمجاز، سرقت هویت، تقلب در چکها، پولشویی و موارد دیگر باشند. این موارد نهتنها باعث زیان مالی برای قربانیان و مؤسسات مالی میشوند، بلکه اعتماد مشتریان را نیز تضعیف کرده و به اعتبار سازمان آسیب میزنند. علاوه بر این، سازمانها ممکن است با جریمههای قانونی و نظارتی، دعاوی حقوقی و هزینههای جانبی مواجه شوند؛ مسائلی که زمان و منابع ارزشمند را از فعالیتهای روزمره منحرف میکند.
محیطهای خدمات مالی میتوانند بسیار متنوع باشند؛ از سیستمهای قدیمی و مبتنی بر mainframe گرفته تا سرویسهایی که در ابرهای عمومی و خصوصی اجرا میشوند و توسط خود سازمان یا شرکای خارجی مدیریت میگردند. این محیطهای خارجی ممکن است شامل سرویسهایی باشند که دادههای تقلب را از منابع مختلف جمعآوری کرده و اطلاعات بهروز درباره روشهای شناختهشده تقلب و اعتبارنامههای بهخطرافتاده ارائه میدهند.
در ادامه، سه چالش واقعی که APIهای مبتنی بر رویداد ایجاد میکنند را بررسی میکنیم و راهکارهای غلبه بر آنها را توضیح میدهیم.
چالش اول: ایجاد endpointهای HTTP اختصاصی برای رویدادها
ایجاد endpointهای HTTP اختصاصی برای دریافت رویدادها میتواند زمانبر باشد. مشکل اصلی اینجاست که واکنش بلادرنگ به رویدادهای ورودی از سیستمهای خارجی همیشه ممکن نیست. بسیاری از سیستمهای خارجی قادر نیستند رویدادها را مستقیماً در صفهای پیام (Message Queue) قرار دهند و تنها میتوانند رویدادهای HTTP (مانند webhookها) تولید کنند. این موضوع شما را مجبور میکند برای هر نوع رویداد HTTP، یک microservice جداگانه ایجاد کنید که دادهها را دریافت کرده و برای پردازش در صف قرار دهد.
امروزه میتوان با استفاده از پلتفرمهای مدرن پردازش رویداد، این فرایند را بسیار سادهتر کرد. بهجای ساخت سرویسهای متعدد، میتوان endpointهایی را پیکربندی کرد که مستقیماً رویدادهای HTTP را دریافت کرده و آنها را به صفهای پردازشی یا لاگهای رویداد ارسال کنند. این کار راهاندازی سریع endpointهای هدفمند را ممکن میسازد و انتشار رویدادها به brokerها را به شکلی کارآمد انجام میدهد، آن هم در حالی که الزامات امنیتی از ابتدا در نظر گرفته شدهاند.
چالش دوم: ایمنسازی تعامل با brokerهای رویداد در مقیاس بزرگ
با رشد معماریهای مبتنی بر رویداد، مدیریت امن APIهای غیرهمزمان و brokerهای رویداد پیچیدهتر میشود. شما باید اطمینان حاصل کنید که دسترسی سیستمها، برنامهها و سرویسهای مختلف به رویدادها بهشکلی کنترلشده و امن انجام میشود.
پیچیدگی دیگر این است که تعامل مستقیم با brokerها معمولاً نیازمند کتابخانههای کلاینت تخصصی و پروتکلهای خاص است؛ در حالی که بسیاری از مصرفکنندگان این زیرساختها را در اختیار ندارند و نمیتوانند مستقیماً با broker ارتباط برقرار کنند.
در چنین شرایطی، راهکارهای سنتی مستلزم ایجاد SDKهای وابسته به زبان برنامهنویسی، لایههای انتزاعی سفارشی، middlewareها و کتابخانههای wrapper هستند؛ مجموعهای از کارهای پرهزینه و زمانبر.
پلتفرمهای مدرن مدیریت رویداد این چالش را با سادهسازی امنیت و اعمال سیاستهای یکپارچه حل میکنند، بهطوری که فقط منابع مورد اعتماد بتوانند با رویدادهای بلادرنگ تعامل داشته باشند. علاوه بر این، امکان واسطهگری پروتکلی (برای مثال تبدیل Avro به JSON) فراهم میشود تا مصرفکنندگان بدون نیاز به پیادهسازی پردازشگرهای سفارشی، بهراحتی از دادهها استفاده کنند.
پس از اعمال امنیت و سادهسازی مصرف رویدادها، میتوان از قابلیتهای کشفپذیری و محصولسازی API استفاده کرد؛ بهطوری که پیامهای چندین broker مختلف بهصورت یک API یکپارچه در اختیار مصرفکنندگان قرار گیرد. این یعنی مقیاسپذیری روان و بدون دردسر.
چالش سوم: یکپارچهسازی جریانهای رویداد از منابع مختلف
مدیریت منابع مختلف رویداد میتواند دشوار باشد. ممکن است برخی رویدادها از یک broker مانند Kafka بیایند و برخی دیگر از طریق endpointهای HTTP ارسال شوند، در حالی که سیستم داخلی شما باید همه آنها را از طریق WS یا SSE دریافت کند، بدون توجه به منبع اصلی.
یک راهحل سنتی میتواند ایجاد یک سرویس تجمیع سفارشی، پیادهسازی لایه تبدیل با middleware یا ESB و سپس انجام تجمیع در سمت مصرفکننده باشد. اما این رویکرد به زمان، منابع و پیچیدگی زیادی نیاز دارد.
در عوض، میتوان با استفاده از ابزارهای یکپارچهسازی رویداد، همه این منابع را دریافت کرده و آنها را بهصورت یک جریان یکپارچه از رویدادهای JSON از طریق WS/SSE در اختیار مصرفکننده قرار داد. همچنین میتوان جزئیات دسترسی به این جریانها را از طریق پورتالهای توسعهدهندگان منتشر کرد تا دسترسی سلفسرویس برای تیمهای داخلی یا مصرفکنندگان خارجی فراهم شود، در حالی که بالاترین سطح امنیت همچنان حفظ میشود.
