کپی دسترسی صندوقدار در نرم‌افزار فروشگاهی؛ نقش، حداقل دسترسی و تفکیک وظایف

کپی دسترسی صندوقدار یعنی چه و چه خطری دارد؟

بیشتر نرم‌افزارهای فروشگاهی و حسابداری امکان می‌دهند برای کاربر تازه، دسترسی‌های یک کاربر یا نقش موجود را کپی کنید تا لازم نباشد ده‌ها مجوز را یکی‌یکی تیک بزنید. این میان‌بر کار را سریع می‌کند، اما خطرش در منبع کپی است. اگر از حساب صندوقداری کپی بگیرید که در شب انبارگردانی، روز حراج یا غیبت سرپرست اختیار موقت گرفته و کسی آن را پس نگرفته، همه آن اختیارها به کاربر تازه هم منتقل می‌شود. راهنمای مجوزدهی بنیاد OWASP همین پدیده را «خزش امتیاز» می‌نامد و توصیه می‌کند دسترسی‌ها به‌طور دوره‌ای بازبینی شوند و آزمون‌هایی ساخته شود که نشان دهد مجوزهای طراحی‌شده واقعاً اعمال می‌شوند. ^[۱]

دو قاعده پایه از همان راهنما، چارچوب کار را می‌سازند. اول، حداقل دسترسی: به هر کاربر فقط کمترین مجوزی داده شود که برای انجام کارش لازم است، هم در عرض بین نقش‌های هم‌سطح و هم در طول سلسله‌مراتب. دوم، رد پیش‌فرض: هر دسترسی‌ای که صریحاً داده نشده، ممنوع است. مؤسسه ملی استاندارد و فناوری آمریکا هم حداقل دسترسی را اصل طراحی‌ای می‌داند که در آن هر موجودیت فقط حداقل منابع و مجوزهای لازم برای کارکردش را می‌گیرد. معنای این دو قاعده برای نقش صندوقدار این است که فهرست را از صفر و از روی شرح شغل بسازید، نه از روی کاربری که امروز کار می‌کند. ^{[۱] [۲]}

صندوقدار به چه دسترسی‌هایی نیاز دارد و به چه چیزهایی نه؟

شرح شغل صندوقدار کوتاه است: ثبت اقلام خرید، دریافت وجه و دادن باقی‌مانده و رسید، انجام مرجوعی و تعویض طبق سیاست فروشگاه و شمارش صندوق در ابتدا و انتهای شیفت. هر مجوزی بیرون از این فهرست باید دلیل مکتوب داشته باشد. در فروشگاه ایرانی یک محدودیت قانونی هم هست: طبق بند ت ماده ۲۲ قانون پایانه‌های فروشگاهی و سامانه مؤدیان، تحویل‌ندادن صورتحساب چاپی و حذف یا مخدوش‌کردن صورتحساب جریمه‌ای معادل دو درصد مبلغ آن یا بیست میلیون ریال، هر کدام بیشتر، دارد. پس دسترسی حذف صورتحساب برای هیچ نقش فروشی منطقی نیست و اشتباه باید با صورتحساب برگشت از فروش اصلاح شود. ^{[۴] [۵]}

دسترسی‌ها را برای نقش صندوقدار در سه ستون بنویسید: مجاز، مجاز با تأیید نفر دوم و ممنوع. هر صندوقدار نام کاربری خودش را دارد و هیچ دو نفری با یک حساب کار نمی‌کنند، چون سیاست‌های نقدداری می‌خواهند وجه نقد تا شخص مشخصی که آن را جابه‌جا کرده قابل ردیابی باشد و نام کاربری مشترک این ردیابی را از بین می‌برد. دسترسی به گزارش‌ها هم بخشی از نقش است: صندوقدار باید گزارش شیفت خودش را ببیند، نه فروش همه شعب یا مانده حساب مشتریان. ^[۶]

• مجاز: ثبت فروش، دریافت نقد و کارت و انتقال، چاپ رسید و صورتحساب، تخفیف ردیف تا سقف نقش، گزارش شیفت خود.
• مجاز با تأیید نفر دوم: مرجوعی بالاتر از سقف، تخفیف بیش از سقف نقش، فروش نسیه یا چکی، باز کردن کشوی پول بدون فروش.
• ممنوع: تغییر قیمت فهرست، ابطال یا حذف صورتحساب صادرشده، ویرایش سند حسابداری، مغایرت بانکی، خروجی گرفتن از کل داده‌ها، تعریف یا تغییر کاربر و نقش.

تفکیک وظایف میان صندوقدار، حسابدار و تأییدکننده

طبق تعریف مؤسسه ملی استاندارد و فناوری آمریکا، تفکیک وظایف یعنی هیچ کاربری نباید آن‌قدر اختیار داشته باشد که بتواند به‌تنهایی از سیستم سوءاستفاده کند. همان واژه‌نامه دو شیوه اجرا را نام می‌برد: ایستا، یعنی تعریف نقش‌های ناسازگار که نمی‌توانند هم‌زمان به یک کاربر داده شوند؛ و پویا، یعنی کنترل در لحظه دسترسی، مثلاً اینکه کاربری که هر دو نقش را دارد نتواند مرجوعی‌ای را که خودش ثبت کرده، خودش تأیید کند. در نرم‌افزار فروشگاهی، شیوه ایستا برای نقش‌های اصلی و شیوه پویا برای جانشینی‌های موقت مناسب است. ^[۳]

جفت‌های ناسازگار در فروشگاه روشن‌اند. صندوقداری که مرجوعی خودش را تأیید می‌کند، می‌تواند کسری صندوق را پشت مرجوعی ساختگی پنهان کند. کسی که هم پول نقد را به بانک می‌برد و هم مغایرت بانکی را می‌بندد، می‌تواند تأخیر واریز را پنهان کند. حسابداری که سند را ثبت و تأیید می‌کند، بازبین مستقل ندارد. و هر کسی که می‌تواند کاربر و نقش تعریف کند، عملاً هر دسترسی دیگری را هم می‌تواند به خودش بدهد، پس مدیر سیستم نباید نقش مالی عملیاتی داشته باشد. سیاست نقدداری دانشگاه کالیفرنیا هم همین را با جمله ساده‌ای گفته است: هیچ فرد واحدی نباید کل فرایند وجه نقد را در کنترل داشته باشد. ^{[۳] [۶]}

کپی امن الگوی نقش؛ گام‌به‌گام

کپی امن از یک الگوی نقش شروع می‌شود، نه از یک شخص. الگو، مثلاً «صندوقدار شعبه»، فقط یک بار با فهرست سه‌ستونی بالا ساخته و با امضای مدیر مالی تأیید می‌شود و هیچ کاربری مستقیم در آن اختیار اضافه نمی‌گیرد. برای کاربر تازه، الگو کپی می‌شود و فقط ویژگی‌هایی مثل شعبه، صندوق و سقف تخفیف تنظیم می‌شوند. راهنمای OWASP برای همین می‌گوید مدل‌های مبتنی بر ویژگی و رابطه معمولاً بهتر از نقش خالص‌اند: به‌جای ساختن ده نقش برای ده شعبه، یک نقش با ویژگی شعبه تصمیم دقیق‌تری درباره هر رکورد می‌گیرد و تعداد نقش‌ها از کنترل خارج نمی‌شود. ^[۱]

پس از کپی، نقش را با یک کاربر آزمایشی امتحان کنید و فقط به پنهان‌شدن دکمه‌ها اکتفا نکنید. راهنمای OWASP تأکید می‌کند مجوز باید در هر درخواست بررسی شود، چون مهاجم فقط به یک راه ورود نیاز دارد؛ یعنی اگر دکمه ابطال در صفحه نیست اما سرور درخواست ابطال را می‌پذیرد، نقش امن نیست. هر کپی و هر تغییر نقش هم باید ثبت شود: چه کسی، چه وقت، از کدام الگو و با تأیید چه کسی. با خروج کارمند، حساب او همان روز غیرفعال شود، نه اینکه برای کپی‌های بعدی نگه داشته شود. ^[۱]

• منبع کپی را الگوی نقش تأییدشده انتخاب کنید، نه حساب کاربری صندوقدار دیگر.
• پیش از ذخیره، تفاوت مجوزهای نقش جدید با الگو را ببینید و هر مجوز اضافه را حذف کنید.
• دامنه را تنظیم کنید: شعبه، صندوق، دفتر یا شرکت، و سقف تخفیف و مرجوعی.
• با کاربر آزمایشی، کارهای ممنوع را امتحان کنید و مطمئن شوید سرور آن‌ها را رد می‌کند.
• کپی را با نام درخواست‌کننده، تأییدکننده و تاریخ ثبت کنید.
• هر فصل دسترسی همه صندوقداران را با الگو مقایسه کنید تا خزش امتیاز دیده شود.

مثال: نقش صندوقدار شعبه دوم و یک مجوز جامانده

فروشگاهی با دو شعبه می‌خواهد برای شعبه دوم صندوقدار تازه‌ای تعریف کند. الگوی تأییدشده «صندوقدار شعبه» تخفیف ردیف را تا ۵ درصد و حداکثر ۲٬۰۰۰٬۰۰۰ ریال در هر صورتحساب و مرجوعی نقدی را تا ۵٬۰۰۰٬۰۰۰ ریال بدون تأیید مجاز می‌داند. مسئول سیستم به‌جای الگو، دسترسی صندوقدار قدیمی شعبه اول را کپی می‌کند. مقایسه پیش از ذخیره دو مجوز اضافه نشان می‌دهد: «ابطال صورتحساب صادرشده» که شب انبارگردانی موقتاً داده شده بود و «گزارش فروش همه شعب» که در غیبت سرپرست اضافه شده بود. هر دو حذف و سپس از حساب صندوقدار قدیمی هم پس گرفته می‌شوند. ^[۱]

اگر این مقایسه انجام نمی‌شد، سناریوی سوءاستفاده ساده بود: مشتری فروش نقدی ۳٬۵۰۰٬۰۰۰ ریالی را می‌پردازد و می‌رود، صندوقدار صورتحساب را ابطال و پول را برمی‌دارد و شمارش پایان شیفت هم کسری نشان نمی‌دهد، چون فروش ثبت‌شده و نقد موجود با هم می‌خوانند. این کار علاوه بر زیان فروشگاه، طبق بند ت ماده ۲۲ قانون پایانه‌ها جریمه‌ای معادل دو درصد مبلغ یا بیست میلیون ریال، هر کدام بیشتر، برای فروشگاه می‌سازد. تنها کنترل مؤثر این است که مجوز ابطال اصلاً در نقش نباشد و سرپرست گزارش ابطال‌ها و مرجوعی‌ها را روزانه بخواند. ^{[۵] [۶]}

اشتباه‌های رایج در تعریف دسترسی صندوقدار

بیشتر خطاها در روزهای شلوغ ساخته می‌شوند و بعد فراموش می‌شوند. دسترسی موقتی که برای حراج یا انبارگردانی داده شده و تاریخ پایان ندارد، نام کاربری مشترک برای شیفت شب، صندوقداری که می‌تواند کاربر جدید بسازد و نقش‌هایی که فقط در ظاهر محدودند اما سرور درخواست ممنوع را رد نمی‌کند، چهار الگوی تکراری‌اند. هر کدام یکی از قاعده‌های حداقل دسترسی، رد پیش‌فرض یا بررسی مجوز در هر درخواست را نقض می‌کند. ^{[۱] [۲]}

• کپی از حساب کاربری فرد به‌جای الگوی نقش.
• دسترسی موقت بدون تاریخ انقضا و بدون ثبت دلیل.
• نام کاربری مشترک یا رمز مشترک بین صندوقداران.
• صندوقدار یا سرپرست شعبه با اختیار تعریف کاربر و نقش.
• مخفی‌کردن دکمه در صفحه به‌جای رد درخواست در سرور.

چک‌لیست بازبینی فصلی دسترسی‌ها

این بازبینی را هر سه ماه و پس از هر جابه‌جایی کارکنان انجام دهید. خروجی آن فهرستی است از کاربران، نقش‌ها، تفاوت هر کاربر با الگو و دلیل هر استثنا، با امضای مدیر مالی. همین فهرست در رسیدگی به کسری صندوق یا پرسش بازرس مالیاتی درباره صورتحساب‌های ابطال‌شده، نشان می‌دهد چه کسی در آن روز چه اختیاری داشته است. اگر نرم‌افزار شما ابزار مقایسه نقش‌ها دارد، آن را در دمو با یک کاربر محدود امتحان کنید، همان‌طور که صفحه امنیت ژرف‌بان پیشنهاد می‌کند. ^{[۱] [۶] [۷]}

• هر کاربر فعال صاحب مشخص دارد و کاربر بی‌صاحب یا کارمند خارج‌شده فعال نیست.
• هیچ کاربری بیرون از الگوی نقش خود مجوز بدون دلیل مکتوب ندارد.
• هیچ نقش فروشی مجوز حذف یا ابطال صورتحساب صادرشده ندارد.
• صندوقدار، تأییدکننده مرجوعی و مغایرت‌گیر بانک سه نفر متفاوت‌اند.
• مدیر سیستم نقش مالی عملیاتی ندارد.
• گزارش ابطال‌ها، مرجوعی‌ها و تخفیف‌های بیش از سقف روزانه خوانده می‌شود.