راهنمای آناما
دسته‌ها

رسیدگی به ریسک و بازبینی دسترسی کارکنان

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

میزکار «کنترل دسترسی» در /panel/erp/governance ریسک‌های باز، نتیجهٔ آزمون کنترل‌ها، تعارض وظایف (SoD) و بازبینی دوره‌ای دسترسی کارکنان را در چهار تب کنار هم می‌گذارد. این صفحه برای پیدا کردن شکاف کنترل و ثبت تصمیم مستند است. کم‌کردن یک شمارنده به‌تنهایی ریسک را رفع نمی‌کند؛ دسترسی، شواهد، کنترل جبرانی و مسئول اقدام باید در پروندهٔ منبع و با توضیح قابل ممیزی ثبت شوند.

ماژول Governance در وضعیت Beta است و کنترل‌های پایهٔ ریسک و SoD عملیاتی‌اند؛ این بخش را معادل یک سامانهٔ کامل GRC سازمانی نگیرید. اقدام‌های «رفع تعارض» و «پذیرش ریسک» اثر واقعی روی دسترسی و سابقهٔ کاربر دارند. پیش از ثبت، فرد، نقش، دامنه، شواهد و پیامد کار را به دقت بررسی کنید و فقط در حدود اختیار سازمان اقدام کنید.

داشبورد و اولویت رسیدگی

کارت‌های بالای صفحه تعداد ریسک‌های بالا/بحرانی، بازبینی ریسک عقب‌افتاده، آزمون ضعیف یا نامؤثر ۳۰ روز اخیر، تعارض دسترسی باز، تصمیم‌های دسترسی منتظر و موعدهای اصلاح گذشته را نشان می‌دهند. این شاخص‌ها وضعیت پرونده‌های ثبت‌شده‌اند؛ شمارندهٔ صفر تضمین نمی‌کند کنترل‌های خارج از سامانه یا رخدادهای ثبت‌نشده وجود ندارند.

اگر تعارض بحرانی باز هست، پیام هشدار نشان می‌دهد پذیرش ریسک بدون ثبت دلیل ممکن نیست و مسیر کاهش دسترسی از بازبینی دسترسی می‌گذرد. این محدودیت را دور نزنید؛ ابتدا دامنهٔ تعارض و مالک کسب‌وکار را روشن کنید.

تب «ریسک و بازبینی»

هر ریسک کد و عنوان، دسته و ماژول، مالک، شدت، امتیاز ذاتی، امتیاز باقی‌مانده، متن اقدام کاهشی و موعد بازبینی دارد. امتیاز ذاتی وضعیت قبل از کنترل‌هاست؛ امتیاز باقی‌مانده باید پس از درنظرگرفتن کنترل‌ها و شواهد معنی پیدا کند. اگر امتیاز بالا است و mitigation خالی مانده، مالک و اقدام کاهشی را در دفتر ریسک ثبت کنید.

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

تب «اثربخشی کنترل»

کارت هر آزمون، کد و نام کنترل، ریسک مرتبط، نتیجهٔ آخرین آزمون، تاریخ، اندازهٔ نمونه، تعداد استثنا و موعد اصلاح را نشان می‌دهد. نتیجه از آخرین ارزیابی ثبت‌شده می‌آید؛ برای دیدن جزئیات و شواهد، ردیف را باز کنید.

اگر نتیجه failed یا ضعیف است، ابتدا آزمون و نمونه را با طراحی کنترل مقایسه کنید: چه چیزی نمونه‌گیری شده، چه شاهدی لازم بوده و چند استثنا پیدا شده است؟ سپس برای هر استثنا مالک و موعد اصلاح تعیین کنید. عبارت «موعد اقدام اصلاحی گذشته» تنها از تاریخ ثبت‌شده می‌آید و به‌تنهایی وضعیت کامل اقدام را روشن نمی‌کند؛ پروندهٔ اقدام را بررسی کنید. آزمون بعدی باید نشان دهد کنترل پس از اصلاح واقعاً کار می‌کند، نه اینکه فقط شرح کنترل تغییر کرده باشد.

تب «تعارض دسترسی و کنترل جبرانی»

دکمهٔ «بررسی همه قوانین تعارض دسترسی» اسکن SoD را اجرا می‌کند. نتیجه اعلام می‌کند چند تعارض شناسایی شده و چند مورد قبلی رفع شده‌اند؛ پس از اجرا میزکار دوباره بارگذاری می‌شود. اسکن را پس از تغییر نقش‌ها یا پیش از ارزیابی دسترسی اجرا کنید، اما بدانید این بررسی فقط قواعد تعریف‌شده و داده‌های موجود را می‌بیند.

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

  • کنترل جبرانی: وقتی جداسازی کامل وظایف اکنون ممکن نیست، کنترل جایگزین واقعی و قابل پیگیری تعریف کنید. فرم یادداشت می‌خواهد؛ نام کنترل، مالک اجرا، تناوب و مدرک انجام را روشن بنویسید.
  • رفع تعارض: نقش، منبع یا محدودهٔ دسترسی را به حداقل لازم کاهش دهید. علت اقدام را ثبت کنید و پس از تغییر، دوباره اسکن کنید تا مطمئن شوید تعارض رفع شده است.
  • پذیرش ریسک: فقط با اختیار رسمی و دلیل مکتوب انجام دهید. پذیرش، ریسک را از بین نمی‌برد؛ مالک، مدت اعتبار و کنترل جبرانی را ثبت کنید. برای تعارض بحرانی، این سامانه پذیرش بدون دلیل را مجاز نمی‌داند.

پیش از تأیید پنجرهٔ اقدام، نام کاربر و شواهد همان تخلف را دوباره بخوانید. یادداشت خالی یا عبارتی مثل «مورد بررسی شد» برای حسابرسی کافی نیست؛ بنویسید چه تصمیمی، چرا و با چه کنترل جبرانی گرفته شده است.

تب «بازبینی دوره‌ای دسترسی»

در سمت کمپین‌ها، وضعیت، بازبین، موعد، تعداد کل موارد و تعداد تکمیل‌شده نمایش داده می‌شود. کمپین پیش‌نویس را می‌توان با «شروع» فعال کرد. پس از شروع، آیتم‌های بررسی دسترسی در ستون مقابل ظاهر می‌شوند؛ هر مورد کاربر، نقش، کمپین، نوع دامنه و شناسه‌های محدوده را مشخص می‌کند.

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

کمپین فعال تنها زمانی دکمهٔ تکمیل دارد که آیتم منتظر تصمیم باقی نمانده باشد. پیش از تکمیل، درصد پیشرفت و تعداد کل را بررسی کنید. تکمیل کمپین جایگزین اجرای تغییرات مصوب روی سامانه‌های وابسته نیست؛ نتیجهٔ هر تصمیم را در پروندهٔ دسترسی هم کنترل کنید.

نمونهٔ بازبینی دسترسی یک کارمند

فرض کنید یک کاربر هم می‌تواند خرید را ایجاد کند و هم خودش پرداخت را تأیید کند. اسکن SoD این دو مجوز را طبق یک قانون تعارض پیدا کرده است. ابتدا شواهد و نقش‌های مؤثر را باز کنید و از مدیر واحد بپرسید کدام وظیفه برای کار لازم است. اگر نقش تأیید پرداخت قابل حذف است، آن را از کمپین بازبینی اصلاح یا حذف کنید و دلیل را ثبت کنید. اگر جداسازی فوری ممکن نیست، کنترل جبرانی واقعی مانند بازبینی مستقل روزانه با ثبت مدرک تعریف کنید؛ سپس مالک و تناوب آن را بنویسید و تاریخ بازبینی بعدی بگذارید. بعد از اعمال تغییر، اسکن را دوباره اجرا کنید و بررسی کنید تعارض رفع یا تحت کنترل ثبت‌شده مانده است.

خطاهای متداول

  • اسکن صفر تعارض می‌دهد اما نگرانی باقی است: دامنهٔ قوانین تعریف‌شده، عضویت نقش‌ها و دادهٔ آخرین اسکن را بررسی کنید؛ سامانه ممکن است کنترل خارج از قواعد خود را نبیند.
  • تعارض بحرانی اجازهٔ پذیرش نمی‌دهد: دلیل مکتوب معتبر و مسیر کاهش دسترسی را طی کنید؛ خالی گذاشتن توضیح راه‌حل نیست.
  • آزمون کنترل تاریخ گذشته دارد: خود پروندهٔ کنترل، استثناها و وضعیت اصلاح را ببینید؛ تاریخ به‌تنهایی اثربخشی را ثابت نمی‌کند.
  • آیتم کمپین به شما نشان داده نمی‌شود: مجوز بازبینی و محدودهٔ نقش را بررسی کنید؛ تصمیم‌گیر باید مستقل و مجاز باشد.
  • کمپین تکمیل نمی‌شود: تعداد آیتم‌های منتظر را ببینید و برای هرکدام تصمیم و توجیه ثبت کنید.
  • تصمیم دسترسی ثبت شد ولی تعارض باقی است: تغییر در نقش/محدوده را تأیید کنید و اسکن مجدد انجام دهید؛ یادداشت تصمیم به‌تنهایی دسترسی را عوض نمی‌کند.

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

چگونه نتیجهٔ اسکن را به تصمیم قابل دفاع تبدیل کنیم؟

اسکن SoD قانون‌های تعارض تعریف‌شده را روی نقش‌ها و مجوزهای ثبت‌شده اجرا می‌کند. بعد از اجرا، شمارهٔ شواهد، کاربر و قانون را باز کنید تا روشن شود تعارض از کدام دو امکان ناسازگار به وجود آمده است. اگر فرد مجوز اضافه گرفته اما هیچ‌گاه استفاده نکرده، باز هم امکان دسترسی وجود دارد و باید در تصمیم لحاظ شود؛ «تا حالا استفاده نکرده» به تنهایی رفع تعارض نیست. قبل از تغییر دسترسی، مطمئن شوید کار حیاتی کاربر به نقش دیگری منتقل شده است تا اصلاح امنیتی باعث توقف عملیات نشود.

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

کمپین دسترسی را به برنامهٔ سازمان وصل کنید

پیش از شروع کمپین، فهرست کاربران، نقش‌های حساس و نوع محدودهٔ دسترسی را آماده کنید. بازبین نباید صرفاً همهٔ درخواست‌ها را برای سریع تمام‌کردن نگه دارد؛ باید با مدیر مالک فرایند نیاز جاری فرد را تأیید کند. در اصلاح scope، شناسهٔ محدوده باید با منبع واقعی (مثل واحد یا فروشگاه) سازگار باشد. بعد از حذف یا محدودکردن دسترسی، با حساب/پروندهٔ مناسب بررسی کنید آیا کاربر هنوز عملیات مورد نیازش را انجام می‌دهد یا خیر؛ کمپین دسترسی با برنامه‌ریزی و آموزش تغییر نقش کامل می‌شود.

این راهنما مفید بود؟بازخورد شما به بهترشدن راهنما کمک می‌کند.
ارسال بازخورد