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