امنیت نرمافزار حسابداری: چکلیست سطح دسترسی، لاگ تغییرات، بکاپ و بازیابی
چرا امنیت نرمافزار حسابداری فقط مسئولیت IT نیست؟
وقتی در یک سازمان از «امنیت نرمافزار حسابداری» صحبت میشود، معمولاً یک اتفاق رخ میدهد: مدیر مالی موضوع را به IT ارجاع میدهد و IT هم آنتیویروس و فایروال را نشان میدهد و موضوع تمام میشود. این تقسیمکار ساده با واقعیت تهدیدات مالی همخوانی ندارد.
بخش قابلتوجهی از خطاها و تخلفات مالی از درون سازمان شروع میشود: کاربری که بیش از نیازش دسترسی دارد، تغییری که قابل ردیابی نیست، سندی که اشتباهاً حذف میشود، یا بکاپی که وجود دارد اما هرگز آزمایش نشده است. هیچکدام از اینها لزوماً حمله خارجی نیستند؛ بلکه شکست کنترلهای داخلیاند.
محرمانگی، صحت و دسترسپذیری به زبان ساده
سه مفهوم بنیادی امنیت اطلاعات که در استانداردهای مرجعی مانند ISO/IEC 27001:2022 تعریف شدهاند، برای سیستم مالی معنای عملی دارند:
- محرمانگی: آیا فقط کسانی که باید، به اطلاعات مالی دسترسی دارند؟ حقوق پرسنل، وضعیت جریان نقدی یا قراردادهای حساس نباید برای همه قابل مشاهده باشد.
- صحت: آیا میتوان مطمئن بود که داده تغییر نکرده یا اگر تغییر کرده، توسط چه کسی، چه زمانی و چرا؟ سند حسابداری که بدون ردپا ویرایش شده، ارزش حسابرسی ندارد.
- دسترسپذیری: آیا در صورت خرابی سیستم یا از دست رفتن داده، میتوان عملیات مالی را در زمان قابل قبول بازیابی کرد؟
اثر خطای داخلی، دسترسی اضافی و خرابی سیستم
سه سناریوی رایج که در سازمانهای ایرانی تکرار میشوند:
- دسترسی اضافی: کاربری که برای «راحتی کار» دسترسی حذف داده مالی دارد، در یک لحظه اشتباه سوابق را پاک میکند. بازیابی دقیق ممکن نیست چون لاگی ثبت نشده.
- غیاب ردپای حسابرسی: دو رقم در گزارش مالی پایان سال با سوابق میانه سال مطابقت ندارد. چون لاگ تغییرات وجود ندارد، نمیتوان تشخیص داد خطا از کجا آمده.
- بکاپ بدون تست: نسخه پشتیبان هر شب گرفته میشود. اما وقتی سرور خراب میشود، مشخص میشود که آخرین بکاپ سالم سه هفته پیش بوده و فرایند بازیابی هرگز آزمایش نشده.
چهار لایه امنیت در سیستم مالی
امنیت عملیاتی یک سیستم مالی را میتوان در چهار لایه مجزا دید. تفکیک این لایهها برای تعیین مسئولیت ضروری است.
کاربر و هویت
اولین خط دفاعی، هویت کاربر است: احراز هویت قوی، رمز عبور منحصر به هر کاربر (نه اشتراکی)، و غیرفعال کردن فوری دسترسی پس از خروج کارمند.
فرایند و تفکیک وظایف
تفکیک وظایف یعنی یک نفر نمیتواند تنها سند را ثبت کند، تأیید کند و پرداخت انجام دهد. این اصل در استانداردهای کنترل داخلی مانند COSO Internal Control Framework مبنای اصلی پیشگیری از تقلب است.
نرمافزار و ثبت رویداد
نرمافزار باید تغییرات را ثبت کند، دسترسیها را محدود کند و گردش کار تأیید را اجرا کند. این قابلیتها باید در محصول وجود داشته باشند، نه صرفاً وعده شوند.
زیرساخت، بکاپ و بازیابی
این لایه شامل بکاپگیری منظم، نگهداری نسخهها در مکان جداگانه، و مهمتر از همه، آزمون دورهای بازیابی است. این لایه در نسخههای نصبی (ویندوزی) اغلب مسئولیت کامل با مشتری است.
سطح دسترسی کاربران چگونه طراحی شود؟
اصل حداقل دسترسی
اصل Least Privilege که در منابعی مانند NIST SP 800-53 مستند است، میگوید: هر کاربر باید فقط به آنچه برای انجام وظیفهاش نیاز دارد دسترسی داشته باشد، نه بیشتر. این اصل ساده در عمل اغلب رعایت نمیشود چون «دادن دسترسی بیشتر راحتتر است».
نقشهای حسابدار، خزانهدار، فروش، مدیر مالی و مدیر سیستم
هر نقش باید دسترسی مشخص و محدود داشته باشد. در ادامه (بخش ماتریس) این را به تفصیل میبینید. نکته کلیدی: نقش «مدیر سیستم» نرمافزاری نباید با نقش «مدیر مالی» ترکیب شود؛ یکی تنظیمات فنی را کنترل میکند و دیگری تراکنشهای مالی را.
دسترسی مشاهده، ثبت، ویرایش، حذف، تأیید و گزارش
این شش سطح دسترسی باید بهصورت مستقل قابل تنظیم باشند. نرمافزاری که فقط دسترسی «کامل» یا «محدود» دارد، کنترل کافی نمیدهد.
بازبینی دورهای کاربران فعال
هر سه تا شش ماه، لیست کاربران فعال باید با وضعیت استخدامی مقایسه شود. کارمندانی که سازمان را ترک کردهاند یا جابجا شدهاند، دسترسیشان باید فوراً بهروز شود.
تفکیک وظایف در فرایندهای مالی
ایجاد، تأیید و پرداخت
این سه مرحله باید توسط سه نفر (یا حداقل دو نفر متفاوت در سازمانهای کوچکتر) انجام شود. یک حسابدار که هر سه کار را میکند، کنترل داخلی معناداری ندارد.
ثبت فروش و دریافت
کاربر ثبتکننده فاکتور فروش نباید بهتنهایی قادر به تأیید دریافت وجه باشد. این تفکیک مانع از ثبت تراکنشهای ساختگی میشود.
ایجاد طرف حساب و تغییر اطلاعات حساس
ایجاد یک طرف حساب جدید یا تغییر شماره حساب بانکی آن، باید توسط کاربر متفاوتی از کسی که تراکنش را ثبت میکند، تأیید شود. این یکی از رایجترین نقاط ضعف در سیستمهای مالی است.
دسترسی اضطراری و ثبت دلیل
در مواقع ضرورت که نیاز به دسترسی فراتر از سطح معمول است، این دسترسی باید موقت، مستند، و با ثبت دلیل همراه باشد. دسترسی اضطراری دائمی، دیگر اضطراری نیست.
لاگ تغییرات و ردپای حسابرسی چه چیزی باید نشان دهد؟
چه کسی، چه چیزی، چه زمانی
یک لاگ حسابرسی (Audit Trail) مؤثر باید حداقل سه عنصر را ثبت کند: شناسه کاربر، نوع عملیات (ثبت، ویرایش، حذف، تأیید)، و زمان دقیق. بدون این سه، ردیابی حادثه ممکن نیست.
مقدار قبل و بعد، در صورت پشتیبانی
بهترین سطح لاگنویسی مالی، ثبت مقدار قبل و بعد از تغییر است. اگر مبلغ یک سند از ۱۰ میلیون به ۱۲ میلیون تغییر کرد، لاگ باید هر دو مقدار را نشان دهد. این قابلیت در همه نرمافزارها وجود ندارد و باید در دمو بهصراحت آزمایش شود.
ایجادکننده، ویرایشکننده و تأییدکننده
برای هر سند مالی، سیستم باید نشان دهد چه کسی آن را ایجاد کرده، چه کسی آن را ویرایش کرده (و چند بار)، و چه کسی آن را تأیید نهایی کرده است. ثبت فقط «آخرین ویرایشکننده» کافی نیست.
نگهداری و دسترسی به گزارش رویداد
لاگها باید:
- برای حداقل یک دوره مالی (و ترجیحاً چند سال) نگهداری شوند
- قابل حذف یا ویرایش توسط کاربران عادی نباشند
- برای حسابرس داخلی و مدیر مالی قابل گزارشگیری باشند
بکاپ خوب بدون آزمون بازیابی کافی نیست
📌 توقف مهم: اگر الان نسخه پشتیبان دارید اما زمان آخرین آزمون بازیابی را نمیدانید، نخست همین مورد را با تیم مالی و IT روشن کنید.
دامنه دادههای پشتیبان
بکاپ باید شامل همه اطلاعات لازم برای بازیابی کامل باشد: پایگاه داده، تنظیمات سیستم، فایلهای پیوست (در صورت وجود) و دادههای کاربری. بکاپ جزئی که امکان بازیابی کامل ندهد، در بحران بیفایده است.
تناوب و نگهداری نسخهها
این جدول راهنمای عمومی است. تناوب و محل ذخیره باید با ارزیابی ریسک سازمان و الزامات قانونی تطبیق داده شود.
جداسازی نسخه پشتیبان از محیط اصلی
اگر بکاپ روی همان سروری که نرمافزار اجرا میشود ذخیره شود، در صورت خرابی آن سرور، هم نرمافزار و هم بکاپ از دست میرود. این یک خطای رایج است. نسخه پشتیبان باید حداقل از نظر فیزیکی یا شبکهای از محیط اصلی جدا باشد.
آزمون بازیابی و ثبت نتیجه
آزمون بازیابی یعنی عملاً از یک نسخه پشتیبان، داده را در یک محیط جداگانه بازیابی کنید و بررسی کنید که آیا سیستم کار میکند. این آزمون باید:
- در یک محیط تست (نه تولید) انجام شود
- نتیجه آن مستند و تاریخگذاری شود
- مشکلات احتمالی قبل از بحران شناسایی شوند
تعریف مسئولیتها در نسخه نصبی و تحت وب
برای مقایسهٔ الزامات استقرار، نرمافزار حسابداری تحت وب و حسابداری ابری را نیز ببینید.
این تفاوت مهم است و اغلب در قرارداد مبهم میماند:
نسخه نصبی (ویندوزی): مسئولیت بکاپ، نگهداری سرور و بازیابی اغلب کاملاً با مشتری است. فروشنده نرمافزار معمولاً فقط راهنمایی میدهد.
نسخه تحت وب (Cloud/SaaS): بخشی از مسئولیت زیرساخت با ارائهدهنده است، اما شرایط دقیق آن (RPO، RTO، محل نگهداری داده، حق دسترسی به بکاپ) باید در قرارداد مستند باشد.
در هر دو حالت، قرارداد و SLA را با دقت بخوانید و هرچه مبهم است، پیش از امضاء روشن کنید.
چکلیست امنیتی پیش از خرید نرمافزار حسابداری
این ۲۵ سؤال را در جلسه دمو یا قبل از امضای قرارداد بپرسید. پاسخ شفاهی کافی نیست؛ برای هر مورد، شواهد قابل مشاهده یا بند قراردادی بخواهید.
سطح دسترسی و کاربران
- آیا امکان تعریف نقشهای دسترسی سفارشی وجود دارد؟ سطوح چیست؟
- آیا میتوان برای هر کاربر بهصورت مستقل دسترسی مشاهده، ثبت، ویرایش، حذف، تأیید و گزارش را مدیریت کرد؟
- آیا حذف کاربر با غیرفعالسازی دسترسی فوری همراه است؟ سوابق آن کاربر چه میشود؟
- آیا گزارشی از کاربران فعال و سطح دسترسی هر یک قابل تهیه است؟
- آیا چند کاربر میتوانند با یک نام کاربری مشترک وارد شوند؟ (پاسخ ایدهآل: خیر)
تفکیک وظایف
- آیا امکان تنظیم گردش کار تأیید (یک یا چند مرحلهای) وجود دارد؟
- آیا یک کاربر میتواند هم سند را ثبت کند، هم تأیید کند؟ اگر بله، آیا این محدودیتپذیر است؟
- آیا تغییر اطلاعات طرف حساب (مثل شماره حساب بانکی) نیاز به تأیید جداگانه دارد؟
لاگ تغییرات
- آیا سیستم تمام تغییرات اسناد (ثبت، ویرایش، حذف، تأیید) را لاگ میکند؟
- آیا لاگ شامل مقدار قبل و بعد از تغییر است؟
- آیا شناسه کاربر، تاریخ و زمان دقیق در لاگ ثبت میشود؟
- آیا کاربر عادی میتواند لاگ را ویرایش یا حذف کند؟ (پاسخ ایدهآل: خیر)
- آیا گزارش لاگ برای یک سند یا کاربر خاص قابل فیلتر و استخراج است؟
- لاگها چه مدت نگهداری میشوند؟
قفل سند و دوره مالی
- آیا سند پس از تأیید قابل ویرایش است؟ چه کسی میتواند قفل را بشکند؟
- آیا قفل دوره مالی (بستن دوره) وجود دارد تا از ثبت در دوره بسته جلوگیری شود؟
بکاپ و بازیابی
- در نسخه نصبی، ابزار یا راهنمای بکاپگیری چیست؟ مسئولیت بکاپ با کیست؟
- در نسخه تحت وب، بکاپ کجا ذخیره میشود و آیا مشتری میتواند نسخه بکاپ خود را دریافت کند؟
- فرایند بازیابی کامل داده چیست و مستند است؟
- آیا تیم شما سابقه آزمون بازیابی موفق با این نرمافزار دارد؟
بهروزرسانی و پشتیبانی
- چرخه انتشار بهروزرسانی چگونه است و مشتری چطور مطلع میشود؟
- اگر یک آسیبپذیری امنیتی شناسایی شود، فرایند اطلاعرسانی و رفع آن چیست؟
- کانال رسمی گزارش مشکل یا رخداد کجاست؟
قرارداد و مسئولیت
- در قرارداد، حدود مسئولیت فروشنده و مشتری در حوزه امنیت داده چطور تعریف شده است؟
- اگر داده مالی از دست برود، فرایند رسیدگی و جبران در قرارداد چیست؟
سناریوی آزمون عملی در دمو
این سناریو برای آزمون سه کنترل اصلی طراحی شده است. نتیجه را از قبل فرض نکنید؛ هدف دیدن رفتار واقعی سیستم است.
سناریو: ویرایش سند تأییدشده، ردیابی رویداد و آزمون بازیابی
مرحله ۱: کاربر ثبتکننده و سند تأییدشده
از نماینده فروش بخواهید یک کاربر با نقش «حسابدار پایه» (دسترسی ثبت، بدون تأیید) ایجاد کند. یک سند حسابداری با این کاربر ثبت شود. سپس مدیر مالی (یا کاربر تأییدکننده) این سند را تأیید کند.
سؤال آزمون: حالا همان کاربر اول تلاش میکند سند تأییدشده را ویرایش کند. سیستم چه میکند؟
پاسخ قابل قبول: سیستم اجازه ویرایش نمیدهد و پیام خطا نشان میدهد.
پاسخ نگرانکننده: ویرایش انجام میشود بدون هیچ هشدار یا لاگی.
مرحله ۲: ردیابی رویداد توسط مدیر مالی
از نماینده بخواهید گزارش لاگ رویدادهای همین سند را نشان دهد.
سؤال آزمون: آیا تلاش برای ویرایش ناموفق هم لاگ شده است؟ آیا نام کاربر، زمان دقیق و نوع عملیات قابل مشاهده است؟
پاسخ قابل قبول: هر دو رویداد (ثبت + تلاش ویرایش) با جزئیات کامل قابل مشاهدهاند.
پاسخ نگرانکننده: فقط رویداد موفق لاگ شده یا لاگ اصلاً وجود ندارد.
مرحله ۳: آزمون بازیابی کنترلشده
این مرحله را در محیط دمو یا با هماهنگی قبلی انجام دهید:
از نماینده بخواهید فرایند بازیابی داده را توضیح دهد و مستندات آن را نشان دهد. اگر امکانپذیر است، بخواهید از یک نسخه بکاپ تستی، داده را در محیط جداگانه بازیابی کنند.
سؤال آزمون: آیا مستندات مکتوب برای بازیابی وجود دارد؟ آیا آخرین بار این فرایند آزمایش شده است؟
پاسخ قابل قبول: مستندات وجود دارد، تاریخ آخرین تست مشخص است.
پاسخ نگرانکننده: «تا به حال مشکلی نداشتیم» یا پاسخ شفاهی بدون سند.
📌 برای بررسی عملی سطح دسترسی، گردش تأیید و قابلیتهای مستند راهکارهای مالی کاربرد کامپیوتر، یک دموی سناریومحور درخواست کنید. بهجای معرفی کلی محصول، از ما بخواهید همین سه مرحله بالا را روی داده نمونه اجرا کنیم تا رفتار واقعی سیستم را ببینید، نه توضیح شفاهی آن را.
ماتریس پیشنهادی نقش و دسترسی
این ماتریس یک نقطه شروع است، نه نسخه نهایی. آن را با ساختار سازمانی و حجم تراکنش خود تطبیق دهید.
سه نکته درباره این ماتریس:
- مدیر مالی نباید ثبتکننده باشد. اگر کسی که تأیید میکند خودش هم ثبت کند، تفکیک وظایف از بین میرود. در سازمانهای کوچک که این تفکیک ممکن نیست، حداقل باید هر ثبت مدیر مالی بهصورت خودکار علامتگذاری و در گزارش دورهای بازبینی شود.
- مدیر سیستم نباید به داده مالی دسترسی تراکنشی داشته باشد. او زیرساخت و کاربران را مدیریت میکند، نه اسناد را. اگر مدیر سیستم بتواند هم دسترسیها را تغییر دهد و هم سند ثبت کند، عملاً هیچ کنترلی روی او وجود ندارد.
- نقش حسابرس داخلی فقطخواندنی است. این نقش باید به همه چیز از جمله لاگها دسترسی داشته باشد، اما هیچ امکان تغییری نداشته باشد.
اشتباهات رایج سازمانها
کاربر مشترک برای چند نفر. رایجترین خطا. وقتی سه نفر با یک نام کاربری وارد میشوند، لاگ بیمعنا میشود؛ میدانید چه اتفاقی افتاده اما نمیدانید چه کسی آن را انجام داده.
دسترسی موقت که دائمی میشود. دسترسی برای «فقط همین یک بار» داده میشود و هرگز پس گرفته نمیشود. بدون بازبینی دورهای، دسترسیها فقط انباشته میشوند.
بکاپ روی همان سرور. پوشه بکاپ در درایو D همان سروری که پایگاه داده روی درایو C آن است. در خرابی سختافزار یا حمله باجافزاری، هر دو با هم از بین میروند.
اعتماد به وعده شفاهی در جلسه فروش. «بله، همه اینها را داریم» بدون نمایش عملی. اگر قابلیتی در دمو نشان داده نشد، فرض کنید وجود ندارد یا نیاز به توسعه دارد.
نبود مالک مشخص برای امنیت مالی. وقتی مدیر مالی فکر میکند IT مسئول است و IT فکر میکند این موضوع مالی است، هیچکس مسئول نیست. برای هر کنترل، یک نام باید ثبت شود.
تعویق آزمون بازیابی. همیشه کار مهمتری هست. تا روزی که دیگر دیر است.
پرسشهای متداول
آیا نرمافزار حسابداری میتواند کاملاً امن باشد؟
خیر. هیچ سیستمی «غیرقابل نفوذ» نیست و هر ادعایی در این زمینه باید شما را محتاط کند. هدف واقعی، کاهش ریسک تا سطح قابل قبول و توانایی تشخیص و بازیابی سریع در صورت وقوع حادثه است.
تفاوت امنیت نسخه ویندوزی و تحت وب چیست؟
در نسخه ویندوزی، کنترل و مسئولیت زیرساخت (سرور، شبکه، بکاپ) عمدتاً با شماست؛ این یعنی آزادی عمل بیشتر و بار مسئولیت بیشتر. در نسخه تحت وب، بخشی از این بار به ارائهدهنده منتقل میشود، اما شما همچنان مسئول مدیریت کاربران و دسترسیها هستید. هیچکدام ذاتاً امنتر نیست؛ آنچه تعیینکننده است، کیفیت اجرای کنترلها در هر دو مدل است.
هر چند وقت یکبار باید سطوح دسترسی را بازبینی کنیم؟
حداقل هر شش ماه یکبار بهصورت کامل، و بهصورت موردی در هر تغییر سازمانی: استخدام، جابجایی، ارتقاء یا خروج کارمند. خروج کارمند باید همان روز اعمال شود، نه در بازبینی بعدی.
اگر لاگ تغییرات وجود نداشته باشد چه ریسکی داریم؟
سه ریسک اصلی: نمیتوانید منشأ خطا را پیدا کنید، نمیتوانید در برابر ادعای تخلف از خود دفاع کنید، و در حسابرسی داخلی یا خارجی مدرکی برای اثبات صحت فرایند ندارید. عملاً کنترل داخلی مستندی ندارید.
آزمون بازیابی را چگونه بدون ریسک انجام دهیم؟
در محیط تست جداگانه، نه روی سیستم عملیاتی. یک نسخه بکاپ را در یک سرور یا ماشین مجازی مجزا بازیابی کنید، صحت دادهها را بررسی کنید و نتیجه را با تاریخ مستند کنید. این کار هیچ اثری روی داده اصلی ندارد.
در سازمان کوچک با سه کارمند، تفکیک وظایف چطور ممکن است؟
تفکیک کامل ممکن نیست، اما جایگزین دارد: مدیر یا مالک کسبوکار میتواند نقش تأییدکننده را بر عهده بگیرد؛ گزارش دورهای تغییرات مهم بهصورت خودکار برای مدیر ارسال شود؛ و لاگ تغییرات بهطور منظم (مثلاً ماهانه) مرور شود. کنترل جبرانی بهتر از نبود کنترل است.
جمعبندی و گام بعدی
امنیت نرمافزار حسابداری نه یک ویژگی فنی در فهرست امکانات محصول، بلکه ترکیبی از سه چیز است: قابلیتهای نرمافزار، طراحی درست فرایند، و انضباط سازمانی در اجرا. نرمافزار خوب بدون فرایند درست، امنیت نمیآورد.
سه گام عملی که همین هفته میتوانید بردارید:
- لیست کاربران فعال سیستم فعلی خود را استخراج کنید و با فهرست پرسنل فعلی مقایسه کنید. هر اختلافی را ظرف همان هفته رفع کنید.
- تاریخ آخرین آزمون موفق بازیابی را از تیم IT بپرسید. اگر پاسخی وجود ندارد، این را در اولویت قرار دهید.
- برای هر یک از چهار لایه امنیتی این مقاله، یک نام بهعنوان مالک مسئول تعیین و مکتوب کنید.
اگر در آستانه انتخاب یا تعویض نرمافزار حسابداری هستید، چکلیست ۲۵ سؤالی این مقاله را چاپ کنید و با خود به جلسه دمو ببرید. تفاوت یک تصمیم خوب و یک پشیمانی چندساله، اغلب در همین سؤالهایی است که پیش از امضای قرارداد پرسیده میشوند.
برای مشاهده عملی سطوح دسترسی، گردش کار تأیید، لاگ تغییرات و مستندات بازیابی در راهکارهای مالی کاربرد کامپیوتر، درخواست دموی سناریومحور ثبت کنید. سناریوی خود را از قبل برای ما بفرستید تا جلسه بهجای معرفی عمومی، روی همان کنترلهایی متمرکز شود که برای سازمان شما اهمیت دارد.
