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