فرض کنید نیمه‌شب یک سرویس حیاتی Down شده و ادمین اصلی در دسترس نیست. تیم عملیات برای بازیابی سرویس به یک حساب ممتاز نیاز دارد که در حالت عادی اجازه استفاده از آن را ندارد. اگر سازمان در این لحظه فقط دو انتخاب داشته باشد—یا توقف سرویس را ادامه دهد یا کنترل دسترسی را دور بزند—یعنی فرآیند Privileged Access برای بحران طراحی نشده است.

Break-Glass Access در PAM360 برای همین سناریوها معنا پیدا می‌کند: دسترسی اضطراری، محدود، ثبت‌شده و قابل بازبینی به حساب‌ها یا منابع ممتاز، بدون اینکه Credential به‌صورت دائمی در اختیار افراد بیشتری قرار گیرد. هدف این نیست که در شرایط بحرانی کنترل‌ها حذف شوند؛ هدف این است که مسیر اضطراری از قبل طراحی شده باشد.

Break-Glass Access چیست؟

Break-Glass اصطلاحی برای دسترسی استثنایی در زمان Incident، Disaster، Lockout یا خرابی فرایند عادی Approval است. چنین دسترسی‌ای معمولاً باید فقط برای افراد مشخص، منابع مشخص و مدت محدود فعال شود.

چرا حساب اضطراری نباید یک Password مشترک باشد؟

روش سنتی این است که Password یک حساب Administrator در پاکت، فایل رمزگذاری‌شده یا Password Manager عمومی نگهداری شود. مشکل این است که وقتی Credential افشا شد، Attribution دشوار می‌شود و مشخص نیست چه کسی، چه زمانی و برای چه کاری از آن استفاده کرده است.

یک PAM بالغ باید بتواند دسترسی را Broker کند، Session را ثبت کند و در صورت امکان بدون نمایش Password به کاربر اجازه ورود دهد. این مدل هم سرعت عملیات را حفظ می‌کند و هم Accountability را از بین نمی‌برد.

PAM360 در سناریوی اضطراری چه کمکی می‌کند؟

مستندات رسمی ManageEngine برای PAM360 به Break-Glass Permission، Session Brokering و ثبت فعالیت اشاره می‌کنند. همچنین بخش Emergency Measures در PAM360 امکان محدودکردن کانال‌های ارتباطی مانند API، Agent، SCIM و Application Gateway را هنگام رخداد امنیتی فراهم می‌کند تا دامنه حمله کنترل شود.

این دو مفهوم باید از هم جدا باشند: Break-Glass برای دسترسی اضطراری مجاز است؛ Emergency Measures برای مهار ارتباطات مشکوک یا پرریسک در خود پلتفرم PAM.

چه زمانی Break-Glass منطقی است؟

• خرابی سرویس حیاتی و عدم دسترسی Approver اصلی؛
• Lockout ادمین‌ها از Domain یا سیستم مدیریت؛
• Incident امنیتی که نیازمند Containment فوری است؛
• Disaster Recovery و فعال‌سازی سایت جایگزین؛
• خرابی سامانه Ticketing یا Workflow Approval؛
• نیاز فوری Vendor به دسترسی کنترل‌شده برای رفع اختلال.

Break-Glass نباید برای «عجله دارم» یا دور زدن فرآیند عادی استفاده شود.

طراحی درست حساب Break-Glass

۱. مالکیت مشخص

هر حساب اضطراری باید Owner مشخص داشته باشد. حساب بدون مالک خیلی سریع به Shared Admin Account تبدیل می‌شود.

۲. Scope محدود

به‌جای یک Global Admin برای همه‌چیز، چند مسیر اضطراری محدود برای Domain، Database، Network یا Cloud تعریف کنید.

۳. Time-bound Access

دسترسی باید بعد از زمان مشخص منقضی شود. پنجره ۳۰ دقیقه‌ای یا یک‌ساعته، بسته به سناریو، از Permission دائمی امن‌تر است.

۴. Session Recording

هر فرمان، Session و Connection باید در حد قابلیت پلتفرم قابل ثبت و بازبینی باشد.

۵. Credential Rotation

بعد از استفاده، Password یا Secret باید Rotate شود تا Credential اضطراری قبلی قابل استفاده مجدد نباشد.

Break-Glass و Just-in-Time چه تفاوتی دارند؟

JIT Access برای کاهش Standing Privilege در عملیات روزمره است؛ Break-Glass برای زمانی است که مسیر عادی دسترسی یا Approval پاسخ‌گو نیست.

برای طراحی JIT، مقاله مانیتورینگ دسترسی ممتاز Just-in-Time با PAM360 مکمل این راهنماست.

سناریو: خرابی Domain Controller و قفل‌شدن مسیر عادی

1. Incident بحرانی اعلام می‌شود.
2. Incident Commander یا مدیر مسئول Break-Glass را فعال می‌کند.
3. ادمین مجاز فقط به Resource موردنیاز دسترسی می‌گیرد.
4. Session از PAM360 اجرا و ثبت می‌شود.
5. پس از Recovery، دسترسی اضطراری بسته می‌شود.
6. Credential مرتبط Rotate می‌شود.
7. Audit Log و Session در Post-Incident Review بررسی می‌شوند.

چه کسانی باید مجاز به Break-Glass باشند؟

تعداد افراد باید حداقل باشد. ManageEngine در Solution Brief خود توصیه می‌کند Permission اضطراری به Administrator قابل اعتماد محدود شود و مدت دسترسی فقط به اندازه انجام Task باشد.

در سازمان‌های بزرگ می‌توان نقش‌ها را به این شکل جدا کرد:

• Incident Commander: اجازه فعال‌سازی؛
• Privileged Operator: اجرای عملیات؛
• Security Reviewer: بازبینی Session؛
• Platform Owner: Rotation و Closure.

Emergency Measures در خود PAM360

اگر خود PAM360 یا Integrationهای اطراف آن در معرض Incident باشند، امکان محدودکردن API، Agent، SCIM و Application Gateway وجود دارد. این اقدام می‌تواند سطح تماس سامانه را کاهش دهد، اما باید فقط بر اساس Runbook مشخص استفاده شود چون ممکن است Integrationهای عملیاتی را نیز متوقف کند.

اتصال Break-Glass به ITSM

هر استفاده اضطراری باید به Incident یا Change اضطراری متصل باشد. این اتصال مشخص می‌کند چه کسی درخواست داده، چرا دسترسی لازم بوده، چه Resourceهایی استفاده شده‌اند و چه زمانی دسترسی بسته شده است.

اگر ServiceDesk Plus در سازمان وجود دارد، Ticket می‌تواند مرجع Audit باشد. برای طراحی Workflowهای Incident و Change می‌توانید از منابع Service Desk مدانت استفاده کنید.

چک‌لیست کنترل Break-Glass

• حساب اضطراری Owner دارد.
• Scope آن محدود است.
• افراد مجاز مشخص‌اند.
• دسترسی Time-bound است.
• Session Recording فعال است.
• Password پس از استفاده Rotate می‌شود.
• استفاده به Ticket متصل است.
• پس از هر استفاده Post-Incident Review انجام می‌شود.
• سناریو حداقل دوره‌ای تست می‌شود.
• Emergency Measures خود PAM360 در Runbook جداگانه تعریف شده‌اند.

نکات کلیدی

• Break-Glass یعنی مسیر اضطراری کنترل‌شده، نه حذف کنترل.
• Credential مشترک و بدون Audit الگوی مناسبی نیست.
• دسترسی باید حداقل، زمان‌دار و قابل ثبت باشد.
• پس از هر استفاده Rotation و Review لازم است.
• JIT و Break-Glass مکمل هم هستند، نه جایگزین هم.

منابع

• ManageEngine PAM360 — Emergency Measures
• ManageEngine PAM360 — Product Overview
• ManageEngine PAM360 — Solution Brief

سخن پایانی

بحران بدترین زمان برای اختراع فرآیند دسترسی ممتاز است. اگر Break-Glass از قبل طراحی نشده باشد، تیم‌ها معمولاً به Shared Password، Permission دائمی یا دور زدن Approval پناه می‌برند. PAM360 کمک می‌کند مسیر اضطراری از قبل تعریف، محدود و قابل Audit باشد.

مدانت خدمات استعلام و خرید لایسنس PAM360، طراحی معماری PAM، پیاده‌سازی JIT و Break-Glass، Session Management، Integration با ServiceDesk Plus، آموزش، مهاجرت و پشتیبانی ارائه می‌کند. برای بررسی راهکار به صفحه PAM360 مدانت مراجعه کنید یا از طریق تماس با مدانت مشاوره تخصصی بگیرید.