کارشناس برای بررسی خطای پایگاه داده، رمز حساب مدیریتی را درخواست میکند. در فرم یک شماره تیکت مینویسد و دسترسی میگیرد؛ اما بعداً مشخص میشود تیکت برای سرور دیگری بوده و درخواستکننده آن نیز شخص دیگری است. شماره ثبت شده، ظاهر فرایند را منظم کرده است، ولی دلیل قابل اتکایی برای این دسترسی وجود ندارد.
اعتبارسنجی تیکت در دسترسی مدیریتی یعنی بررسی کنیم درخواست واقعی، مرتبط و مجاز است؛ نه اینکه فقط یک کادر اجباری به فرم اضافه کنیم. در این مقاله، اتصال PAM360 به ServiceDesk Plus را از همین زاویه بررسی میکنیم: چه چیزی بهصورت مستند قابل کنترل است، چه شرطهایی باید طراحی شوند و چگونه اجرای درست سیاست را با آزمون اثبات کنیم.
ثبت دلیل با اعتبارسنجی دلیل فرق دارد
متن آزاد برای توضیح کار مفید است، اما بهتنهایی معلوم نمیکند مجوز از کجا آمده است. حتی وجود یک تیکت باز نیز برای هر عملیاتی کافی نیست. تیکت نصب چاپگر نباید مجوز تغییر پایگاه داده مالی شود و تیکت تیمی، بدون بررسی مسئول اجرا، نباید دسترسی نامحدود ایجاد کند.
پیشنهاد اجرایی این است که «چه کسی»، «به کدام منبع»، «برای چه عملیاتی» و «با کدام مجوز» در هر درخواست مشخص باشد. برای دسترسی زماندار، پنجره مجاز نیز باید به این اطلاعات اضافه شود. سپس تعیین کنید هر شرط با قابلیت آماده، گردش کار یا توسعه اختصاصی کنترل میشود؛ همه این موارد را نباید خودکار و پیشفرض فرض کرد.
اتصال تیکتینگ در محصول چه کاری انجام میدهد؟
طبق مستند رسمی اتصال سامانه تیکتینگ، PAM360 میتواند پیش از دریافت یا بازنشانی رمز، اعتبار شناسه تیکت و بسته نبودن آن را بررسی کند و مجوز کاربر برای منبع یا عملیات را نیز کنترل کند. این ارتباط برای نسخههای مختلف ServiceDesk Plus و چند سامانه دیگر مستند شده است. شناسه تیکت همچنین امکان ردیابی عملیات در سوابق را فراهم میکند.
این قابلیت را با ساخت خودکار تیکت برای انقضای گواهی یا با راهاندازی نشست از داخل پورتال یکی ندانید. هرکدام کاربرد و پیکربندی جدا دارد. تمرکز این راهنما، کنترل درخواست دسترسی از طریق اعتبار تیکت است؛ نه ادعای اینکه یک اتصال، تمام مسیرهای دسترسی سازمان را بهتنهایی پوشش میدهد.
قبل از اتصال، قرارداد داده را روشن کنید
| موضوع | تصمیم پیشنهادی سازمان | ریسک طراحی ناقص |
|---|---|---|
| شناسه کاربر | روش تطبیق حساب در دو سامانه مشخص باشد | استفاده از تیکت شخص دیگر |
| منبع هدف | نام یا شناسه دارایی قابل تطبیق باشد | گسترش مجوز به سرور نامرتبط |
| وضعیت مجاز | مرحله قابل قبول برای اجرای کار تعریف شود | دسترسی با درخواست ردشده یا قدیمی |
| نوع عملیات | مشاهده رمز و تغییر رمز جدا بررسی شوند | اعطای اختیار بیش از نیاز |
| بازه اجرا | شروع، پایان و رفتار پس از انقضا تعیین شود | باقی ماندن دسترسی پس از پایان کار |
بهتر است تطبیق منبع با شناسه پایدار انجام شود. تغییر نام نمایشی سرور یا نوشتن نام کوتاه در یک سامانه و نام کامل در دیگری، میتواند درخواست معتبر را رد کند. در مقابل، تطبیق بیش از حد سست ممکن است چند منبع متفاوت را یکی بگیرد. نمونههای واقعی نامگذاری را پیش از اجرا بررسی کنید.
تفاوت نسخه داخلی و ابری مهم است
راهنمای پیکربندی PAM360 برای ServiceDesk Plus داخلی، کلید تکنسین و نشانی سامانه را توضیح میدهد. گزینه Use ChangeID for Validation تعیین میکند شناسه تغییر به جای شناسه درخواست مبنا قرار گیرد؛ تأیید تغییر نیز در این مسیر اهمیت دارد. در نسخه ابری، مراحل ثبت برنامه، شناسه و راز اتصال و مجوزدهی جداگانه مستند شدهاند.
در طراحی، روش احراز هویت را از نسخه دیگر کپی نکنید. حساب اتصال باید مسئول مشخص و فقط مجوز مورد نیاز داشته باشد. نشانی پورتال، اعتبار گواهی و امکان ارتباط از سرور PAM را در محیط واقعی بررسی کنید. مستند اتصال، ارتباط HTTPS و گواهی معتبر با نام جایگزین موضوع را لازم میداند؛ دور زدن اعتبارسنجی گواهی، راهحل مناسبی برای خطای اتصال نیست.
شرطهای پیشرفته را محدود و قابل آزمون نگه دارید
در تنظیمات پیشرفته تیکتینگ، تطبیق فیلدهای کاربر و منبع با فیلدهای سامانه تیکتینگ و بررسی شرطهای اضافی توضیح داده شده است. امکان آزمون پیکربندی با شناسه تیکت نیز وجود دارد. در صورت کافی نبودن تنظیمات آماده، مستندات مسیر توسعه اختصاصی را معرفی میکنند.
برای شروع، چند شرط روشن بهتر از مجموعهای طولانی از قواعد مبهم است. ابتدا تطبیق هویت، منبع و وضعیت را اثبات کنید؛ سپس نیازهای خاص مانند پنجره اجرایی را بررسی کنید. اگر یک شرط فقط در مستند سیاست آمده اما در مسیر واقعی اجرا نمیشود، آن را کنترل پیادهسازیشده گزارش نکنید.
اگر در کنار اتصال آماده، فرم یا میانافزار اختصاصی توسعه میدهید، قرارداد داده، مجوزها و رفتار پس از قطع ارتباط را جدا طراحی کنید. راهنمای اتصال امن فرمها به سامانهها این ملاحظات را با تمرکز بر جلوگیری از ثبت تکراری و نتیجه نامعلوم توضیح میدهد.
وضعیت تکمیلشده را معادل مجوز جدید نگیرید
نام وضعیت در سازمانها یکسان نیست. ممکن است «تأییدشده» مجوز شروع کار باشد و «تکمیلشده» نشان دهد کار قبلاً انجام شده است. نمونههای مستندات محصول نباید بدون تطبیق با گردش کار سازمان اجرا شوند. برای روشن شدن این تفاوت، راهنمای وضعیت درخواستها در سرویس دسک را کنار تعریف سیاست دسترسی قرار دهید.
استثناها میتوانند اثر کنترل را خنثی کنند
راهنمای پیکربندی محصول تصریح میکند مدیران ارشد سامانه بهصورت پیشفرض از الزام شناسه تیکت مستثنا هستند و گزینههایی برای تنظیم الزام در سطح گروهها و عملیات وجود دارد. بنابراین گزارش موفقیت اتصال کافی نیست؛ دامنه واقعی اجرا و استثناهای آن را نیز بررسی کنید.
برای دسترسی اضطراری، مسیر جدا با مسئول، دلیل و بازبینی پس از استفاده طراحی کنید. قطع بودن میز خدمت نباید به بهانهای دائمی برای کنار گذاشتن کنترل تبدیل شود. از طرف دیگر، مسیر بازیابی بحران نیز نباید فقط به همان سامانهای وابسته باشد که ممکن است از دسترس خارج شود. راهنمای دسترسی اضطراری این بخش مکمل را بررسی میکند.
استثنایی که به پذیرش ریسک نیاز دارد باید دامنه، صاحب اختیار و شرایط بازبینی مشخص داشته باشد. راهنمای پذیرش ریسک با مسئول مشخص به مستندسازی این تصمیم کمک میکند تا دسترسی استثنایی به مجوز دائمی و بدون پاسخگو تبدیل نشود.
آزمون منفی از نمایش اتصال موفق مهمتر است
| سناریوی آزمون | انتظار از سیاست طراحیشده | شاهد پذیرش |
|---|---|---|
| تیکت معتبر برای کاربر و منبع درست | اجرای عملیات مجاز | ثبت شناسه تیکت و نتیجه |
| شناسه ناموجود یا تیکت بسته | رد درخواست | پیام قابل فهم و سابقه رد |
| تیکت معتبر برای منبع دیگر | رد طبق شرط تطبیق منبع | آزمون با حساب غیرمستثنا |
| درخواست متعلق به شخص دیگر | رد طبق سیاست هویتی | ثبت نتیجه تطبیق |
| قطع ارتباط یا انقضای مجوز اتصال | رفتار امن و از پیش تعیینشده | ثبت خطا و آزمون مسیر اضطراری |
| تغییر وضعیت تیکت پس از شروع کار | بررسی رفتار واقعی دسترسی جاری | مستندسازی محدودیت و کنترل مکمل |
همه انتظارهای جدول باید در اجرای آزمایشی اثبات شوند. بهخصوص از اعتبارسنجی اولیه تیکت نتیجه نگیرید که بستن آن حتماً نشست باز را قطع میکند یا رمز دیدهشده فوراً بیاعتبار میشود. این رفتارها به کنترل نشست و سیاست رمز نیاز دارند و باید جداگانه بررسی شوند.
مدرک ممیزی را بدون افشای رمز نگه دارید
سوابق باید مشخص کنند درخواست از چه کاربری، برای چه منبعی و با کدام تیکت انجام شده است. خود رمز، راز اتصال و داده غیرضروری نباید وارد شرح تیکت یا گزارش عمومی شوند. دسترسی به فیلم نشست یا جزئیات فعالیت مدیریتی نیز باید محدود باشد؛ وجود یک لینک در تیکت به معنای مجاز بودن همه خوانندگان آن برای مشاهده محتوا نیست.
برای شاخصهای مدیریتی، سهم عملیات مشمول اعتبارسنجی، تعداد استثناهای فعال، خطاهای اتصال و نمونههای دسترسی نامرتبط ردشده را جدا گزارش کنید. هدف، زیاد شدن تیکتها نیست؛ هدف این است که دلیل دسترسی به منبع حساس قابل اثبات باشد.
نکات کلیدی
- وجود شماره تیکت با اعتبار درخواست دسترسی یکسان نیست.
- تطبیق کاربر، منبع و وضعیت باید با نمونه واقعی آزمون شود.
- استثناهای مدیران و گروهها بخشی از دامنه کنترل هستند.
- پایان نشست و بیاعتبار شدن رمز، کنترلهایی جدا از اعتبارسنجی اولیهاند.
سخن پایانی
تیکت زمانی کنترل امنیتی ایجاد میکند که به هویت، منبع و مجوز واقعی کار متصل باشد. با طراحی محدود، آزمون منفی و رسیدگی به استثناها، دسترسی مدیریتی از یک درخواست شفاهی به فرایندی قابل ردیابی تبدیل میشود.
مدانت برای خرید و استقرار PAM360 و یکپارچهسازی آن با سرویس دسک پلاس خدمات تخصصی ارائه میدهد. برای تعریف معیار پذیرش، بررسی نسخهها و طراحی کنترل دسترسی متناسب با سازمان، از جلسه فنی مدانت استفاده کنید.
