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