MedaGRC
داده GRC حساس است؛ معماری باید به اندازه فرایندها جدی گرفته شود
ثبت ریسک، ضعف کنترل، یافته ممیزی و Evidence اطلاعات حساسی تولید می‌کند. استقرار MedaGRC باید بر مبنای حداقل دسترسی، جداسازی دامنه‌ها، پشتیبان‌گیری و مدیریت ارتقا طراحی شود.
Domains
تفکیک دامنه‌های کاری و اعمال Scope دسترسی در ساختار سازمان.
Roles
تعریف نقش‌ها و مجوزها متناسب با مسئولیت Analyst، Auditor و Owner.
Perimeters
محدودکردن ارزیابی به سرویس، فرایند یا دامنه مشخص در صورت نیاز.
Auditability
حفظ تاریخچه و شواهد لازم برای پاسخ‌گویی و بررسی تغییرات.
Backup
طراحی Backup، نگهداری و بازیابی متناسب با حساسیت داده‌های GRC.
Controlled Upgrade
ارتقای نسخه با تست، نسخه پایدار و امکان بازگشت به وضعیت قبلی.
کمترین دسترسی و کوچک‌ترین Scope لازم را مبنا قرار دهید
هر کاربر نباید همه Risk Assessmentها و Auditها را ببیند. Domain و Perimeter باید متناسب با ساختار مالکیت و محرمانگی سازمان طراحی شوند.
Need to Know
دسترسی را بر اساس نیاز کاری واقعی تعریف کنید.
Separation of Duties
در نقش‌های حساس، اجرا و تأیید را تا حد ممکن از هم جدا نگه دارید.
Operational Review
دسترسی‌ها، حساب‌ها و تنظیمات امنیتی را دوره‌ای بازبینی کنید.
پایداری محصول به Backup و Upgrade کنترل‌شده وابسته است
نسخه‌های جدید هسته باید ابتدا در محیط کنترل‌شده بررسی شوند. تغییرات برند و فارسی‌سازی نیز باید طوری نگهداری شوند که مسیر ارتقا را مسدود نکنند.
Stable Release
برای محیط عملیاتی از نسخه پایدار و مشخص استفاده کنید.
Preflight
قبل از ارتقا، Backup، فضای دیسک، وابستگی‌ها و Migrationها را کنترل کنید.
Post-Upgrade
پس از ارتقا، Login، Dashboard، Risk، Audit و مسیرهای کلیدی را Smoke Test کنید.
معماری MedaGRC را با محدودیت‌های امنیتی سازمان تطبیق دهیم
در جلسه فنی می‌توان مدل دسترسی، شبکه، استقرار، Backup و الزامات یکپارچه‌سازی را پیش از Go-Live نهایی کرد.
