Security Center سازمانی برای مدیریت متمرکز امنیت، دسترسی و ممیزی در EzPortal

در پلتفرم‌های Enterprise، امنیت فقط یک گزینه در تنظیمات نیست؛ امنیت باید در لایه هویت، نقش‌ها، دسترسی‌ها، نشست‌ها، APIها، لاگ‌ها، محتوا، فایل‌ها، گردش کار و معماری استقرار حضور داشته باشد. Security Center در EzPortal برای همین هدف طراحی می‌شود: تبدیل امنیت از مجموعه‌ای از تنظیمات پراکنده به یک مرکز کنترل قابل مدیریت و قابل ممیزی.

مشاوره مشاهده راهکار پرتال امن

مسئله امنیتی

وقتی امنیت بین چندین ماژول، سامانه و تیم پخش شود، کنترل واقعی از بین می‌رود

در بسیاری از سازمان‌ها، هر سامانه مدل امنیتی مخصوص خود را دارد. یک سامانه کاربران را از Active Directory می‌گیرد، سامانه دیگر کاربران داخلی دارد، یک ماژول نقش‌های مستقل تعریف می‌کند و بخشی از دسترسی‌ها در فایل‌های تنظیمات یا دیتابیس پنهان می‌شود. نتیجه چنین وضعیتی این است که مدیر امنیت یا مدیر فناوری اطلاعات هیچ تصویر یکپارچه‌ای از دسترسی‌ها، نشست‌ها، رخدادها و ریسک‌های عملیاتی ندارد.

Security Center برای حل همین مسئله ایجاد می‌شود. هدف آن این نیست که فقط چند گزینه امنیتی را در یک صفحه نشان دهد؛ هدف آن ایجاد یک لایه مدیریتی است که بتواند هویت، نقش‌ها، مجوزها، نشست‌ها، لاگ‌ها، سیاست‌ها و رفتار امنیتی پلتفرم را از یک نقطه قابل کنترل کند. در یک پلتفرم سازمانی، چنین قابلیتی برای بانک‌ها، هلدینگ‌ها، سازمان‌های دولتی، دانشگاه‌ها، شرکت‌های پتروشیمی و هر سازمانی که داده حساس دارد حیاتی است.

نشانه‌های نیاز به Security Center

کاربران و نقش‌ها در چندین سامانه جداگانه مدیریت می‌شوند.
دسترسی‌ها قابل ردیابی، مستندسازی یا ممیزی دقیق نیستند.
لاگ‌های امنیتی پراکنده‌اند و دید مدیریتی واحدی وجود ندارد.
سازمان نیازمند کنترل دسترسی سطح‌بندی‌شده، نشست امن و Audit Trail است.
الزامات امنیتی داخلی، افتا، ISO 15408 یا Common Criteria مطرح است.
تیم فنی می‌خواهد امنیت را به جای کدنویسی‌های موردی، در سطح پلتفرم مدیریت کند.

تعریف دقیق قابلیت

Security Center چیست؟

Security Center در یک Enterprise Application Platform، مرکز مدیریت، پایش و اعمال سیاست‌های امنیتی است. این مرکز معمولاً چند حوزه را به هم متصل می‌کند: Identity، Access Control، Authentication، Session Management، Audit Logging، Security Policy، Permission Model و Monitoring. بنابراین Security Center فقط یک صفحه تنظیمات نیست؛ یک قابلیت معماری است که بر نحوه توسعه، استقرار و بهره‌برداری از کل پلتفرم اثر می‌گذارد.

در EzPortal، Security Center باید در کنار قابلیت‌هایی مثل Authentication & SSO، API Gateway، Secure Enterprise Portal و Security Architecture دیده شود. این صفحه نقش یک Feature Page را دارد؛ یعنی تمرکز آن بر قابلیت محصول، معماری امنیت و نحوه کنترل ریسک است، نه صرفاً توضیح عمومی امنیت.

EzPortal Security Center

Users / Admins

Developers / Auditors

Identity • Roles

Permissions • Policies

Sessions • Audit Logs

MFA • SSO • Alerts

Portal Pages & Modules

Workflow / API Gateway

Content / Reports / Monitoring

لایه‌های امنیتی

Security Center باید چه حوزه‌هایی را پوشش دهد؟

Identity Management

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

Role-Based Access Control

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

Authentication Policies

مدیریت سیاست‌های ورود، SSO، MFA، رمز عبور، نشست، قفل شدن حساب، محدودیت تلاش ناموفق و کنترل‌های مربوط به احراز هویت.

Audit Logging

ثبت فعالیت‌های مهم، ورود و خروج، تغییر تنظیمات، تغییر نقش‌ها، دسترسی به بخش‌های حساس و رخدادهای امنیتی برای ممیزی و ردیابی.

Session Security

کنترل نشست‌های فعال، زمان انقضا، نشست‌های هم‌زمان، خروج امن، مدیریت توکن‌ها و کاهش ریسک سوءاستفاده از نشست کاربر.

Security Policy Center

تجمیع سیاست‌های امنیتی در یک مرکز قابل مدیریت تا تیم فناوری اطلاعات بتواند رفتار امنیتی پلتفرم را بدون تغییرات پراکنده کنترل کند.

مدل کنترل دسترسی

امنیت واقعی فقط با تعریف کاربر شروع نمی‌شود؛ با مدل مجوزدهی دقیق کامل می‌شود

در سازمان‌های بزرگ، دسترسی‌ها معمولاً چندبعدی هستند. یک کاربر ممکن است در یک پرتال نقش مدیر محتوا داشته باشد، در پرتال دیگر فقط مشاهده‌گر باشد، به اسناد یک واحد دسترسی داشته باشد اما به اسناد واحد دیگر نه، بتواند فرم ثبت کند اما نتواند آن را تأیید کند. اگر پلتفرم نتواند چنین مدل‌هایی را به‌صورت شفاف و قابل مدیریت پیاده کند، تیم فنی مجبور به نوشتن منطق‌های موردی می‌شود؛ و همین منطق‌های موردی معمولاً در بلندمدت به ریسک امنیتی تبدیل می‌شوند.

Security Center باید این پیچیدگی را در سطح پلتفرم مدیریت کند. یعنی نقش‌ها، گروه‌ها، مجوزها، سطوح دسترسی، عملیات حساس و دسترسی به داده‌ها باید قابل تعریف، مشاهده، اصلاح و ممیزی باشند. این موضوع برای معماری‌های چندسایتی و چندپورتالی EzPortal اهمیت بیشتری دارد، چون هر سایت یا پرتال می‌تواند مخاطب، مالک، محتوا و سیاست امنیتی متفاوتی داشته باشد.

نمونه سطوح کنترل دسترسی

دسترسی در سطح پرتال یا سایت
دسترسی در سطح صفحه و ماژول
دسترسی به عملیات مانند مشاهده، ایجاد، ویرایش، حذف و تأیید
دسترسی بر اساس واحد سازمانی، نقش شغلی یا گروه کاربری
دسترسی به اسناد، فرم‌ها، فرآیندها و گزارش‌ها
دسترسی مدیریتی برای تنظیمات حساس و پیکربندی پلتفرم

Security by Design

امنیت باید در معماری پلتفرم طراحی شود، نه بعداً به آن اضافه شود

در پروژه‌های سازمانی، اضافه کردن امنیت در انتهای کار معمولاً پرهزینه و پرریسک است. وقتی فرم‌ها، گردش کارها، ماژول‌ها، APIها، صفحات و دسترسی‌ها بدون مدل امنیتی یکپارچه طراحی شوند، هر اصلاح امنیتی در آینده نیازمند تغییرات گسترده خواهد بود. رویکرد درست این است که امنیت از ابتدا در هسته پلتفرم، مدل توسعه، مدل مجوزدهی و الگوی استقرار دیده شود.

EzPortal با توجه به جهت‌گیری Enterprise و الزامات امنیتی مانند ISO 15408 و Common Criteria، باید Security Center را به‌عنوان یکی از ستون‌های اصلی معماری محصول نمایش دهد. این مزیت برای سازمان‌هایی که مسیر ارزیابی امنیتی، گواهی افتا، یا الزامات داخلی سخت‌گیرانه دارند، بسیار مهم است؛ چون نشان می‌دهد امنیت صرفاً یک ادعای بازاریابی نیست، بلکه بخشی از طراحی پلتفرم است.

نکته: در متن صفحه از عبارت «آمادگی برای الزامات ISO 15408 / Common Criteria» استفاده شده است، نه ادعای دریافت گواهی. این دقت برای اعتبار حقوقی و بازاریابی محصول ضروری است.

ممیزی و ردیابی

Audit Log فقط برای خطاها نیست؛ برای اعتماد، پاسخ‌گویی و انطباق لازم است

در سازمان‌های حساس، این سؤال همیشه مطرح است: چه کسی، چه زمانی، به چه چیزی دسترسی داشته و چه تغییری ایجاد کرده است؟ اگر پاسخ این سؤال در لاگ‌های پراکنده، فایل‌های متنی یا چند جدول نامشخص پنهان باشد، ممیزی واقعی انجام نمی‌شود. Security Center باید رخدادهای مهم را قابل مشاهده، جستجو، تحلیل و گزارش‌گیری کند.

Audit Log برای تحلیل رخداد امنیتی، پیگیری خطا، بررسی تغییرات مدیریتی، اثبات انطباق، کنترل دسترسی‌های حساس و پاسخ به الزامات واحد امنیت اطلاعات کاربرد دارد. این بخش باید در کنار Reporting & Analytics، API Gateway و Identity Management دیده شود تا تصویر کاملی از رفتار امنیتی پلتفرم شکل بگیرد.

رخدادهای قابل ثبت

ورود، خروج و تلاش ناموفق برای ورود
تغییر نقش‌ها و مجوزها
تغییر تنظیمات امنیتی و مدیریتی
دسترسی به محتوای حساس یا اسناد مهم
فراخوانی APIهای حساس
تغییر در فرم‌ها، گردش کارها و پیکربندی ماژول‌ها

مقایسه معماری

Security Center در برابر مدیریت امنیت پراکنده

موضوع	مدل پراکنده	مدل Security Center
مدیریت کاربران	در هر سامانه جداگانه	با مدل متمرکز هویت، نقش و گروه
کنترل دسترسی	کدنویسی موردی و غیرشفاف	تعریف نقش، مجوز و سیاست در سطح پلتفرم
Audit	لاگ‌های پراکنده و دشوار برای تحلیل	ثبت رخدادهای امنیتی در مدل قابل ممیزی
نشست کاربر	رفتار متفاوت در سامانه‌های مختلف	کنترل متمرکز نشست، انقضا و خروج امن
انطباق امنیتی	مستندسازی دشوار و پرهزینه	آماده‌تر برای ممیزی، سیاست‌گذاری و مستندسازی
توسعه آینده	افزایش ریسک با هر ماژول جدید	استفاده از سیاست‌های امنیتی مشترک در ماژول‌ها و سرویس‌ها

سناریوهای کاربردی

Security Center در چه سناریوهایی ارزش عملی ایجاد می‌کند؟

۰۱

سازمان دولتی

مدیریت نقش‌های متعدد، سطوح دسترسی، پرتال‌های زیرمجموعه، کاربران داخلی و خدمات دیجیتال با نیاز جدی به Audit و کنترل امنیتی.

۰۲

بانک و مالی

کنترل دقیق دسترسی به داشبوردها، درخواست‌ها، گزارش‌ها، APIها و داده‌های حساس در کنار احراز هویت و ثبت رویدادهای امنیتی.

۰۳

هلدینگ

تعریف مدل امنیتی برای شرکت‌های زیرمجموعه، پرتال‌های مستقل، کاربران مشترک، داشبورد مدیریتی و تفکیک دسترسی بین شرکت‌ها.

۰۴

پتروشیمی و صنعت

کنترل دسترسی کارکنان، پیمانکاران، واحدها و سایت‌های عملیاتی به اسناد، درخواست‌ها، فرآیندها و سامانه‌های حساس.

۰۵

دانشگاه

مدیریت هویت و دسترسی دانشجویان، اعضای هیئت علمی، کارکنان، مدیران دانشکده و سامانه‌های آموزشی و اداری.

۰۶

پلتفرم چندپورتالی

اعمال سیاست‌های امنیتی مشترک یا اختصاصی برای چند سایت، چند سازمان، چند واحد یا چند پرتال بر پایه یک هسته واحد.

یکپارچگی با قابلیت‌های دیگر

Security Center به‌تنهایی کار نمی‌کند؛ ستون مشترک سایر قابلیت‌هاست

ارزش Security Center زمانی کامل می‌شود که با سایر بخش‌های پلتفرم یکپارچه باشد. فرم‌ساز باید از همان نقش‌ها و مجوزها استفاده کند. موتور گردش کار باید بداند چه کسی مجاز به تأیید، رد یا ارجاع یک درخواست است. API Gateway باید سیاست‌های دسترسی و لاگ را رعایت کند. Document Management باید سطح دسترسی اسناد را از مدل امنیتی واحد بگیرد. Dashboard Builder باید داده‌ها را بر اساس سطح دسترسی کاربر نمایش دهد.

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

ارتباط با Featureهای دیگر

این ارتباط‌ها باید در طراحی لینک‌سازی داخلی صفحه نیز حفظ شوند تا هم کاربر و هم گوگل رابطه میان قابلیت‌های امنیتی و سایر اجزای پلتفرم را درک کنند.

Authentication & SSO
API Gateway
Workflow Engine
Form Builder
Document Management
Reporting & Analytics
Notification Center
Dashboard Builder

ملاحظات افتا و Common Criteria

جایگاه Security Center در مسیر الزامات امنیتی Enterprise

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

Security Center می‌تواند نقش مهمی در مستندسازی و نمایش این کنترل‌ها داشته باشد. برای EzPortal، اشاره به توسعه محصول بر اساس الزامات ISO 15408 و Common Criteria و هدف‌گذاری برای آمادگی دریافت گواهی افتا، یک مزیت رقابتی مهم است؛ اما این مزیت باید با دقت بیان شود. صفحه Security Center جای مناسبی است تا نشان دهد محصول فقط از نظر ظاهری امن نیست، بلکه کنترل‌های امنیتی قابل مدیریت و قابل ممیزی دارد.

دقت در پیام بازاریابی: در این صفحه بهتر است از ادعاهای قطعی بدون مدرک مانند «دارای گواهی» استفاده نشود، مگر زمانی که گواهی رسمی دریافت شده باشد. عبارت‌های دقیق‌تر مانند «طراحی‌شده با توجه به الزامات»، «آماده‌سازی برای مسیر ارزیابی» و «همسو با کنترل‌های امنیتی Enterprise» قابل اتکاتر هستند.

CTA

امنیت پلتفرم را از ابتدا درست طراحی کنید

اگر قرار است پرتال سازمانی شما به سامانه‌های حساس، کاربران زیاد، سرویس‌های داخلی، اسناد سازمانی، APIها و فرآیندهای عملیاتی متصل شود، امنیت نباید بعداً به آن اضافه شود. EzPortal با نگاه Security by Design، امکان طراحی یک مدل امنیتی متمرکز و قابل توسعه را فراهم می‌کند.

Secure Enterprise Portal

راهکار پرتال سازمانی امن برای مدیریت خدمات، کاربران، محتوا و دسترسی‌های سازمانی.

Authentication & SSO

مدیریت احراز هویت، ورود یکپارچه، نشست کاربران و دسترسی امن به خدمات سازمانی.

API Gateway

کنترل و مدیریت ارتباط امن میان پرتال، سرویس‌ها و سامانه‌های سازمانی از طریق API.

Identity & Access Management

مدیریت متمرکز هویت، نقش‌ها، مجوزها و سیاست‌های دسترسی در سطح سازمان.

Security Center را به بخشی از معماری اصلی پلتفرم خود تبدیل کنید

برای سازمان‌هایی که امنیت، ممیزی، کنترل دسترسی و انطباق اهمیت دارد، EzPortal فقط یک پرتال نیست؛ یک پلتفرم Enterprise با رویکرد امنیت‌محور است.

مشاوره