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