هزاران فروشنده درخشان در فضای امنیتی وجود دارد.
اما ماهیت پنهان شده پشته های امنیتی مانع پذیرش Zero Trust می شود.
متخصصان فناوری اطلاعات و امنیت بیش از هر زمان دیگری در مورد نحوه ایمن سازی محیط خود انتخاب دارند. در همان زمان، پیچیدگی در یکپارچگی و ارتباطات منفجر شده است. فروشندگان امنیت، حتی اگر یک مشکل خاص را به طور بی عیب و نقص حل کنند، اغلب نمی توانند اطلاعات خود را به طور موثر به سایر بخش های محیط IT منتقل کنند. این عدم ارتباط ارزش را محدود می کند، خطر امنیتی را افزایش می دهد و پذیرش Zero Trust را محدود می کند. اگر یک راه حل تشخیص نقطه پایانی متوجه مشکلی در دستگاه کاربر شود اما نتواند به راحتی آن اطلاعات را با صفحه کنترل به اشتراک بگذارد، چگونه می تواند از گسترش مشکل جلوگیری کند؟
ارتباط بلادرنگ بین راه حل های امنیتی باید آسان باشد.
یک رویکرد استاندارد برای ساده کردن ارتباطات مورد نیاز است.
به طور سنتی، اگر فروشندگان اصلاً به سیگنال های امنیتی خود دسترسی داشته باشند، این کار را از طریق یک API مخصوص راه حل انجام می دهند. برای مصرف سیگنال‌های چندین فروشنده امنیتی، متخصصان فناوری اطلاعات باید اتصالات سفارشی را با هر یک از آنها سیم‌کشی کنند. گویی برخی از فروشندگان اطلاعات خود را در واگن های باری، برخی دیگر در کشتی های کانتینری و برخی دیگر با هواپیما تحویل می دهند. این بدان معناست که سازمان ها باید یک ایستگاه قطار، یک کارخانه کشتی سازی و یک فرودگاه بسازند! مشخصات حمل و نقل استاندارد در سراسر راه حل های امنیتی، ترکیب سیگنال های جدید را آسان می کند.
با ایجاد استانداردهای باز، می‌توانیم رویدادها را به سادگی، پیوسته و مقیاس‌پذیر به اشتراک بگذاریم و امنیت را برای مشتریانمان آسان‌تر و قوی‌تر کنیم.
زمان به اشتراک گذاری سیگنال ها فرا رسیده است.
چارچوب سیگنال های مشترک
چارچوب سیگنال های مشترک (SSF) استاندارد جدیدی است که در حال حاضر توسط بنیاد OpenID در حال توسعه است. هدف آن سهولت در اشتراک گذاری رویدادهای امنیتی مربوط به کاربرانی است که از سیستم آنها استفاده می کنند. همانطور که در صفحه کارگروه آمده است:
- مدیریت دسترسی به منابع و اعمال محدودیت های کنترل دسترسی در سرویس های توزیع شده که در یک محیط پویا کار می کنند.
- از نفوذ عوامل مخرب به حساب‌ها، دستگاه‌ها، سرویس‌ها، نقاط پایانی، یا دیگر اصول یا منابع برای دسترسی غیرمجاز به سیستم‌ها یا منابع اضافی جلوگیری کنید.
- کاربران، مدیران و ارائه دهندگان خدمات را قادر می سازد تا برای شناسایی و پاسخگویی به حوادث با یکدیگر هماهنگ شوند.
مفاهیم و تعاریف
چارچوب سیگنال های مشترک بر پنج مفهوم اصلی متکی است:
موضوع
یک شخص ، دستگاه ، گروه یا سازمانی که می خواهیم رویدادهای امنیتی را برقرار کنیم. قالب یک موضوع در این مستندات منبع باز شرح داده شده است.
رویداد
یک اتفاق مرتبط با امنیت مربوط به یک موضوع. نمونه هایی از وقایع زمانی است که جلسه کاربر ابطال می شود یا دستگاه آنها از انطباق خارج می شود. این رویدادها بین طرفین به عنوان نشانه های رویداد امنیتی (SET) ارسال می شوند که نوعی Token وب JSON (JWT) است.
فرستنده
فرستنده یک فروشنده است که در حال پخش رویدادها به سایر فروشندگان است. برای اینکه فرستنده شوید ، باید مجموعه ای از نقاط پایانی API را تعریف کنید که مشخصات مدیریت جریان را که توسط این مشخصات OpenAPI شرح داده شده است ، انجام می دهد.
گیرنده
گیرنده یک فروشنده امنیتی است که در مورد رویدادها دریافت و عمل می کند. گیرنده ها می توانند با استفاده از API مدیریت جریان ارائه شده توسط فرستنده ، چه موضوعاتی را که به آنها علاقه مند هستند پیکربندی کنند.
جریان
جریان یک انتزاع برای چگونگی جریان حوادث از فرستنده به گیرنده است. یک جریان واحد بین فرستنده و گیرنده وجود دارد ، یا می توان چندین جریان داشت. فرستنده تبلیغ می کند که آیا از فشار دادن وقایع به گیرنده پشتیبانی می کند یا برای وقایع یا هر دو مورد نظرسنجی می شود. گیرنده می تواند کدام یک از روشهای پشتیبانی شده را برای برقراری ارتباط انتخاب کند.
تنظیم گیرنده
لطفاً توجه داشته باشید: چارچوب مشترک سیگنال های مشترک هنوز در حال توسعه فعال است. اطلاعات نشان داده شده در اینجا از نوامبر 2021 صحیح است ، اما ما از چندین تغییر آگاه هستیم که به زودی اضافه می شود - به طور خاص در مورد ایجاد و شناسایی جریان ها. ما این سایت را با انتشار اطلاعات جدید به روز خواهیم کرد. لطفا مرتباً بررسی کنید.
در بخش های بعدی ما شما را از طریق نحوه پیکربندی یک گیرنده رویداد پیاده روی خواهیم کرد. شما می توانید هر یک از قطعه های کد زیر را در برابر نسخه محلی در حال اجرا از فرستنده رویداد مثال ما اجرا کنید.
مشخصات توضیح نمی دهد که چگونه جریان ها باید ایجاد شوند. نحوه ایجاد یک سند جریان ما در مورد برخی از روشهای بالقوه بحث می کند ، اما برای اهداف این مثالها ، فرض کنید که یک جریان از قبل فوری شده است.
تصور کنید که شما یک توسعه دهنده در PoolarApp ، یک شرکت SaaS هستید که به امنیت کاربران خود اهمیت می دهد. شما آموخته اید که MasterSure ، یک شرکت امنیتی تثبیت شده که برای نقض و زباله های رمز عبور نظارت می کند ، یک فرستنده رویداد را تنظیم کرده است که می تواند سیگنال های امنیتی را در مورد کاربران محبوب محبوب به اشتراک بگذارد. برای مصرف این سیگنال ها و محافظت از کاربران خود ، باید یک گیرنده رویداد را تنظیم کنید.
به عنوان یک گیرنده رویداد ، PoolalApp لیستی از نقاط پایانی مدیریت جریان را از فرستنده ، بیشترین امنیت درخواست می کند. سپس از آن نقاط پایانی استفاده می کند تا به اکثر مواردی که به چه نوع رویدادهایی علاقه مند است ، چگونه می خواهد آنها را دریافت کند و به کدام موضوعات اهمیت می دهد ، استفاده کند. سرانجام ، PoolalApp می تواند یک رویداد تأیید را برای اطمینان از تنظیم صحیح جریان درخواست کند.
