امنیت و حاکمیت در پشتیبانی شبکه؛ ISMS، GRC و COBIT در عمل
کنترل دسترسی، تغییر، شواهد و ریسک را به عملیات پشتیبانی وصل کنید؛ با نگاه ISMS، GRC و COBIT.
پیمانکار پشتیبانی برای انجام کار به دسترسی نیاز دارد؛ اما همین دسترسی اگر بدون طراحی باشد میتواند به یکی از ریسکهای اصلی سازمان تبدیل شود. مدل درست بین دو افراط قرار میگیرد: نه دسترسی دائمی و بیحساب، نه زنجیرهای از کنترلهای تکراری که عملیات را فلج کند.
مدل دسترسی پیشنهادی
هویت شخصی کارشناس → MFA → دسترسی به مشتری/دارایی مجاز → Remote Support یا PAM براساس حساسیت مقصد → Audit
لپتاپ کاربر و Domain Controller یک سطح ریسک ندارند. کنترل باید براساس Criticality دارایی و نوع دسترسی تنظیم شود.
PAM کجا لازم است و کجا نه؟
Remote Support عادی
پشتیبانی کاربر، بررسی نرمافزار و Troubleshooting معمول میتواند با هویت، MFA، Consent و Audit انجام شود.
Privileged Access
Domain Admin، Firewall، Hypervisor، Database و حساب حساس بهتر است تحت کنترل قویتر مانند PAM، Approval یا Credential Vault قرار بگیرند.
ISMS در کار روزانه چه معنی دارد؟
ISMS زمانی ارزش دارد که Access Control، Asset، Change، Backup، Logging، Incident و Supplier Management از مستندات جدا نباشند. Ticket و Log و Change Record میتوانند Evidence واقعی اجرای کنترل باشند.
GRC چه چیزی اضافه میکند؟
با نگاه GRC میتوان مشخص کرد کدام دارایی Critical است، چه Riskی دارد، چه Controlی باید اجرا شود و چه Evidenceی برای اثبات لازم است. این همان پلی است که عملیات فنی را به مدیریت ریسک وصل میکند. MedaGRC نمونه همین نگاه یکپارچه است.
COBIT چه چیزی از پیمانکار میخواهد؟
COBIT به پاسخگویی، نقش، سنجش و همسویی با هدف سازمان نگاه میکند. برای پشتیبانی یعنی Scope روشن، Owner مشخص، KPI قابل گزارش، ریسک شناختهشده و Change قابل کنترل.
حداقل کنترلهای عملی
امنیت باید در معماری خدمت باشد، نه در انتهای قرارداد
وقتی دسترسی، تغییر و شواهد از ابتدا طراحی شوند، هم تیم پشتیبانی سریعتر کار میکند و هم سازمان برای Audit و Incident آمادهتر است.
