معرفی معماری نئو امنیت

معماری Neo-Security یک معماری امنیتی ماژولار و مبتنی بر استاندارد است. این هدف برای تأمین امنیت ، محافظت و ادعای دسترسی قانونی به API ها و خدمات و همچنین برنامه های کاربردی هم در وب و هم از طریق تلفن همراه است. یک سیستم متمرکز برای مدیریت هویت ، صدور توکن ، فدراسیون و غیره برای ساختن یک پلت فرم API ایمن و مقیاس پذیر بسیار مهم است.

هدف اصلی معماری NEO-Security ارائه یک معماری با چاپ آبی است که می تواند برای نقشه برداری سیستم های جدید و موجود در برابر توابع مورد نیاز برای مقیاس ایمن استفاده شود. در نظر گرفته نشده است که به عنوان یک کل پیاده سازی شود بلکه به عنوان نقشه جاده ای مورد استفاده قرار می گیرد که در صورت بروز نیازهای جدید آماده می شود.

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

مثال خوب این سرویس فدراسیون است که بیشتر در مورد جزئیات بیشتر توضیح داده خواهد شد. IT استانداردهای فدراسیون قدیمی تر مانند SAML و WS-Federation را ارائه می دهد ، اما هنگامی که به طور جداگانه با فدراسیون به عنوان عملکرد مفرد قرار می گیرد ، می تواند همراه با سرویس نشانه ای باشد که به نشانه های OAuth اجازه می دهد تا با استفاده از هویت های فدرال به برنامه هایی صادر شود.

اصل دوم این است که معماری براساس استانداردها بنا شده است. هر عملکرد باید از استانداردهای مناسب در دسترس برای ادغام با برنامه های Edge یا داخلی استفاده کند. این امر باعث می شود که جایگزینی آسانتر از مؤلفه ها باشد و به ادعای حفظ امنیت کمک می کند.

سه ستون اصلی معماری نئو امنیت وجود دارد:

• یک سیستم مدیریت هویت
• یک سیستم مدیریت API
• یک سیستم مدیریت حق

هر یک از این عملکردهای سیستم را که با دیگران همراه است ، محاصره می کنند. در قلب معماری ، سیستم مدیریت هویت است که مسئولیت ادعای هویت سایر سیستم ها با استفاده از نشانه های امنیتی را بر عهده دارد.

پشته نئو امنیت استانداردهای باز

در زیر یک لیست غیر اکسپرس از استانداردهای باز استفاده شده در معماری است. هدف این نیست که معماری را به مجموعه خاصی از استاندارد محدود کنیم ، بلکه فراهم کردن صفحه پایه برای ساختن آن است.

بسیاری از استانداردهای ذکر شده مجموعه های بزرگی از مشخصات هستند ، گاهی اوقات یک استاندارد کامل لازم است اما اغلب برای حل نیازهای عملکردی فقط به قسمت هایی از استاندارد مورد نیاز است.

سیستم مدیریت هویت

مسئولیت اصلی سیستم مدیریت هویت (IMS) مسئولیت رسیدگی به هویت های موجود در سیستم است. این بدان معنی است که باید بتواند مستقیماً کاربران را به عنوان ارائه دهنده هویت (IDP) یا با استفاده از هویت فدرال از طریق IDP دیگر تأیید کند.

هیچ تمایزی از نوع کاربر در سیستم وجود ندارد. IMS باید بتواند به طور مستقیم یا از طریق فدراسیون هم مشتری ، کارمندان و هم کاربران شریک (یا هر نوع ممکن است داشته باشید) تأیید کنند. این به هیچ وجه نشان نمی دهد که آنها همان نوع دسترسی را به دست می آورند ، اما روند اثبات هویت بدون توجه به نوع کاربر ، یکسان است.

هر ادعای هویت حاصل به عنوان یک نشانه امنیتی در استاندارد مناسب ارائه می شود. برای دسترسی به API این با استفاده از نشانه های دسترسی OAuth ، برای برنامه های وب ، این نشانه های OpenID Coect ID است و برای ارائه دهندگان خدمات فدرال شده می تواند از بلیط SAML استفاده کند.

نشانه های امنیتی حاصل باید شامل ادعاهای کافی باشد تا گیرنده بتواند دامنه دسترسی به درخواست خاص را تعیین کند. از این منظر ، IMS از طرف خود دسترسی از کاربر را به برنامه واگذار می کند. این یک اصل پایه در مشخصات OAUTH است.

پس از اصل جدایی نگرانی ، IMS به زیر سیستم های زیر تقسیم می شود.

سیستم مدیریت API

حرکت به یک معماری مبتنی بر API محور و/یا میکروسرویس نیاز به سیستم های بیشتری برای همکاری با یکدیگر دارد. اولین قدم ، همانطور که در بالا توضیح داده شد ، داشتن یک سیستم مدیریت هویت در محل است. این به API ها (میکروسرویس) اجازه می دهد تا هویت را از API ها بیرون بیاورند و آن را به صورت مرکزی مدیریت کنند.

سیستم مدیریت API (AMS) ساختار منطقی استقرار API است. هدف آن ارائه داده ها و توابع خدمات از طریق API و سایر انواع خدمات است. این بستگی به سیستم مدیریت هویت برای کلیه عملیات مربوط به هویت دارد که از سیستم مدیریت API خارج می شوند و در IMS موجود است. AMS به سادگی به عنوان پلیس عمل می کند و بر اساس اطلاعات هویت موجود در نشانه های صادر شده توسط IMS ، سیاست های دسترسی را اجرا می کند.

سه عملکرد مجزا از AMS وجود دارد که در صورت نیاز در این معماری نشان داده می شود. تأمین دسترسی به API ها ، ادغام API ها در خدمات و دسترسی به توسعه دهنده به API.

غالباً سازمان هایی که دارای استقرار گرینفیلد هستند ، خود را فقط به مکانیسم امنیتی API نیاز دارند. با این حال ، معماری Neo-Security قصد دارد به معماران کمک کند تا منظره فعلی محصولات خود را در عملکردهای مجزا ترسیم کنند ، بنابراین می توان از عملکردهای کمتر متداول نیز استفاده کرد.

سیستم مدیریت حق

سیستم مدیریت حق (EMS) آخرین ستون در معماری NEO-Security است. این کنترل دسترسی مبتنی بر ویژگی (ABAC) را فراهم می کند که یک مکانیسم قدرتمندتر از کنترل دسترسی مبتنی بر نقش سنتی (RBAC) است. ABAC با ارائه یک چارچوب سیاست که در آن مدیران می توانند سیاست های امنیتی را که در کل معماری اجرا می شود ، انعطاف پذیری و دقت را فراهم می کند.

ABAC موارد زیر را برای تصمیم مجوز در نظر می گیرد:

• ویژگی های موضوع (کاربر)
• زمینه ای که در آن تصمیم گرفته می شود
• عملی که انجام می شود
• منبعی که درخواست می شود

سپس این سیاست های پیکربندی شده را برای تصمیم گیری در مورد اجازه یا انکار اعمال می کند. سیستم مدیریت حق مسئولیت مدیریت و اجرای سیاست ها و همچنین توزیع این موارد در هر سیستم فرعی که به اجرای آن نیاز دارد ، وظیفه دارد.

فواید این رویکرد این است که نیازی به سیاست های مجوز در زمان طراحی یک سیستم نیست ، اما با تکامل نیازهای تجاری می تواند اضافه و به روز شود.

برای اطمینان از دسترسی مجاز به داده های بسیار تنظیم شده و با ارزش ، سیاست های ریز دانه معمولاً با کنترل دسترسی مبتنی بر ویژگی ایجاد می شوند. در نتیجه ، سرویس امنیتی API کاربران را با زمینه فعلی ، برنامه های مشتری و اقدامات درخواست شده آنها علاوه بر نقش خود ، تأیید می کند.

نتیجه

معماری Neo-Security به عنوان طرح برای سازمانهایی طراحی شده است که از نظر هویت و امنیت به عنوان سیستم عامل های خدمات با نیازهای رو به رشد عمل می کنند. این می تواند به عنوان یک نقشه راه برای تعیین جهت برای پروژه های جدید ، بلکه به عنوان راهنمایی برای درک اینکه چه کارکردهایی در زیرساخت های سازمان وجود دارد ، باشد. بسیاری اوقات عملکردی وجود دارد اما در مکان اشتباهی برای کار با تمام توان خود قرار دارد.

معماری NEO-Security با استانداردهای باز ساخته شده است که توسط بازار پذیرفته و تصویب می شود. در معماری ، خدمات اختصاصی در ماژول های مربوطه از هم جدا شده و از طریق API ها در تعامل هستند ، که ادغام آسان و مقیاس پذیری آینده و همچنین دسترسی ایمن به داده ها را فراهم می کند.

از آنجا که هر سرویس به عملکرد خود اختصاص داده شده و کاملاً با سایرین همراه است ، می توانید یک سرویس مستقل از سرویس دیگر را به روز کنید و سیستم را با گذشت زمان آسانتر می کند.

در بخش بعدی با جزئیات بیشتر و استانداردهای باز برای اجرای آنها ، هر یک از زیر سیستم ها را طی خواهیم کرد.

به خبرنامه ما بپیوندید

آخرین مورد در مورد مدیریت هویت ، امنیت API و احراز هویت را مستقیماً به صندوق ورودی خود دریافت کنید.

آزمایش رایگان را شروع کنید

سرور هویت Curity را به صورت رایگان امتحان کنید. در 10 دقیقه بلند شوید و دویدید.