Nordlet

← المدونة

Building an Accounting API That Survives an Audit

A practical guide to the security and audit controls a financial API needs before Dutch businesses trust it with their books.

Nordlet Team · · 10 دقائق قراءة

واجهة برمجة تطبيقات (API) للمحاسبة تعيد رمز الاستجابة 200 OK عند إجراء عملية دفع لا تقدم لك أي معلومات تقريباً؛ فهي لم تؤكد أن دفتر الأستاذ قد سجّل القيد، أو أن الجهة المنفذة تمتلك الصلاحية للقيام بذلك، أو أن المبلغ قد اجتاز التحقق، أو أن أي شخص مخول قد وافق عليه. بالنسبة للشركات في هولندا، حيث تتوقع مصلحة الضرائب حفظ السجلات وإمكانية إعادة بناءها لمدة سبع سنوات، فإن تلك الفجوة بين "نجاح الطلب" و"صحة الدفاتر" هي الموضع الذي تعاني فيه عمليات التدقيق من المشكلات.

الاستعداد للتدقيق هو هدف تشغيلي للتصميم وليس مجرد شهادة. وهو يعني أن واجهة برمجة التطبيقات تحافظ على سلسلة متكاملة تتضمن: جهة مصادق عليها، وإجراءً مصرحاً به، وتغييراً في الحالة خاضعاً للتحقق، وموافقة، ونتيجة مسجلة في دفتر الأستاذ، وأدلة مقاومة للتلاعب. وكل ما يلي يتعلق ببناء هذه السلسلة عن قصد بدلاً من افتراض أن المصادقة وبروتوكول (TLS) يغطيان الأمر بالكامل.

ما الذي يجعل واجهة برمجة تطبيقات المحاسبة "جاهزة للتدقيق"

يحتاج المدقق الذي يعيد بناء المعاملة إلى الإجابة عن تسلسل محدد من الأسئلة: من بدأها؟ وهل كان مسموحاً له بذلك؟ وهل اجتاز التغيير التحقق المحاسبي؟ ومن وافق عليها؟ وما الذي سجله دفتر الأستاذ؟ وهل يمكن تعديل هذا السجل لاحقاً دون ترك أي أثر؟

إذا كانت واجهة برمجة التطبيقات الخاصة بك عاجزة عن الإجابة عن كل هذه الأسئلة الستة من خلال سجلاتها ونموذج بياناتها الخاص، فهي ليست جاهزة للتدقيق، بغض النظر عن مدى نظافة الكود البرمجي. وتتعامل معظم واجهات برمجة التطبيقات مع السؤال الأول بشكل جيد بينما تتعامل مع البقية بشكل ضعيف.

تنقسم الضوابط التي تسد هذه الفجوة إلى عدة مجموعات: الحالة المحاسبية الصريحة، والتفويض متعدد الطبقات، والمصادقة المقيدة، وعمليات الكتابة ذات المعاملة الواحدة (idempotent writes)، والتحقق من جانب الخادم، والفصل بين المهام، والسجلات المقاومة للتلاعب. وهي تدعم بعضها البعض؛ فالتفويض الضعيف يقوض سجل التدقيق القوي، لعدم إمكانية الوثوق بعد ذلك بأن الجهة المسجلة كان لها الحق في تنفيذ هذا الإجراء.

نمذجة الحالات المحاسبية قبل نمذجة نقاط النهاية

خطأ التصميم الأكثر شيوعاً هو التعامل مع كل سجل مالي ككتر قابل للتعديل بحرية ويتضمن عمليات الإنشاء (create)، والقراءة (read)، والتحديث (update)، والحذف (delete). لا تعمل المحاسبة بهذه الطريقة، وسلاحظ المدقق فوراً إذا كان قيد اليومية المرحل قابلاً للكتابة فوقه صمت.

يحتاج كل مورد ذي قيمة مالية إلى آلة حالات (state machine) صريحة. وعادة ما يمر قيد اليومية أو الدفعة عبر المراحل التالية:

draft → submitted → approved → posted → settled

لا تؤدي عمليات التصحيح إلى التراجع في هذا المسار. فالقيد المرحل الذي يحتوي على خطأ يتلقى قيد عكسي مرتبط أو تسوية تعويضية، بينما يبقى القيد الأصلي سليماً.

مجموعة قواعد قابلة للتطبيق:

  • يمكن تعديل المسودات بواسطة المستخدمين المصرح لهم.
  • لا يمكن تعديل السجلات المقدمة إلا بواسطة الأدوار المسموح لها بذلك، أو إعادتها إلى مسودة.
  • تتطلب السجلات الموافق عليها تعديلاً محكوماً وموافقة جديدة.
  • لا يمكن الكتابة فوق السجلات المرحلة أو حذفها، بل يمكن عكسها أو تسويتها فقط.
  • تتطلب التغييرات في الفترات المغلقة تفويضاً مرتفع المستوى، وسبباً معلناً، وحدث تدقيق.

إن محاولة إجراء انتقال غير قانوني، مثل تعديل قيد مرحل، يجب أن تعيد خطأً مستقراً وتكتب مع ذلك سجل تدقيق؛ فالمحاولة الفاشلة تُعد دليلاً أيضاً.

هنا يثبت دفتر الأستاذ مزدوج القيد غير القابل للتعديل جدارته. فقد صُمم دفتر الأستاذ الخاص بـ Nordlet بحيث تصل كل معاملة في صورة قيد متوازن ودائم، مع فرض التوازن بواسطة مشغل قاعدة بيانات (database trigger) وقت الالتزام، وتتم عمليات التصحيح من خلال القيود العكسية بدلاً من إعادة الكتابة. ويبدو هذا القيد مقيداً أثناء التطوير، ليتحول لاحقاً إلى العنصر الذي يثق به محاسبك أثناء التدقيق.

تفويض كل طلب وليس المصادقة عليه فقط

تثبت المصادقة هوية الجهة المتصلة، لكنها لا تقدم أي إشارة عما إذا كان هذا المتصل مسموحاً له بالوصول إلى فاتورة معينة، أو دفتر يومية، أو كيان قانوني محدد. يضع مشروع أمان واجهات برمجة التطبيقات من منظمة OWASP ضعف تفويض مستوى الكائنات في صدارة قائمة المخاطر، تحديداً لأن واجهات برمجة التطبيقات تعرض معرفات الكائنات مما يسهل الوصول بين المستأجرين في حال غياب عمليات التحقق.

يجب تفويض كل طلب موجه إلى واجهة برمجة تطبيقات مالية بناءً على مجموعة من العوامل، وليس الاعتماد على رمز مميز (token) وحده:

  • الجهة المصادق عليها
  • تطبيق العميل أو حساب الخدمة
  • المستأجر (tenant)
  • الكيان القانوني
  • معرف المورد
  • العملية المطلوبة
  • حالة المورد الحالية
  • المبلغ أو حد المعاملة

هناك قاعدتان عمليتان تحظيان بأهمية أكبر من البقية. أولاً، اشتق سياق المستأجر والمستخدم من الهوية المصادق عليها، واقضِ برفض أي مطالبة بدور أو مستأجر يرسلها العميل وتتعارض معها؛ إذ يجب ألا يتمكن أي متصل من تحديد الشركة نيابة عنها. ثانياً، استخدم مبدأ الرفض الافتراضي (deny-by-default)، فإذا لم تمنح أي سياسة إذناً صريحاً بإجراء عملية ما، فإنها تفشل.

اختبر كلا الاتجاهين: الوصول الأفقي، حيث يصل مستأجر إلى بيانات مستأجر آخر، والوصول العمودي، حيث يصل مستخدم عادي إلى وظائف الموافقة، أو الترحيل، أو التصدير. كلاهما شائع وكلاهما كارثي في البيانات المحاسبية.

نموذج الأدوار في Nordlet، والذي يتضمن أدوار المالك (owner)، والمسؤول (admin)، والمحاسب (accountant)، والمدير (manager)، والمطور (developer)، والمشاهد (viewer) عبر شركات متعددة تحت حساب واحد، وُجد لجعل هذا الفصل قابلاً للتنفيذ وليس مجرد أمنية. فدور المطور القادر على إنشاء مسودات الفواتير يجب ألا يكون قادراً على إطلاق المدفوعات.

تقييد الرموز المميزة بقدرات الأعمال وليس بأفعال الدورات الأساسية

للوصول المفوض، استخدم إرشادات الأمان الحديثة لبروتوكول OAuth 2.0 بدلاً من كلمات المرور القابلة لإعادة الاستخدام أو مفاتيح واجهة برمجة التطبيقات الثابتة واسعة النطاق. تُعد وثيقة RFC 9700 أفضل ممارسة حالية وتضع متطلبات واضحة للعملاء وخوادم التفويض، تشمل: عناوين إعادة التوجيه التي تم التحقق منها، واستخدام PKCE عند الاقتضاء، والتحقق من الجهة الماصدرة والجمهور، وعمر الرموز المميزة للوصول القصيرة، وتدوير رموز التحديث مع إبطالها.

قرار تحديد النطاقات (scoping) هو الموضع الذي يظهر فيه التفكير الخاص بالمحاسبة. فالنطاقات العامة مثل القراءة (read) والكتابة (write) تكاد تكون عديمة الفائدة لأغراض الفصل بين المهام، لذا يجب أن تتطابق النطاقات مع القدرات الفعلية:

  • نطاقا journal:create وjournal:approve منفصلان.
  • إنشاء تعليمات الدفع لا يمنح صلاحية إطلاقها.
  • إذن التصدير يختلف عن إذن القراءة، نظراً لأن التصدير بالجملة يُعد مساراً لتسريب البيانات.

كن دقيقاً بشأن موضع تواجد منتج معين على هذا النطاق. فمفاتيح واجهة برمجة التطبيقات الخاصة بـ Nordlet تحمل نطاقات خاصة بالوحدات مثل sales:read وsales:write والتي يتم التحقق منها مع كل إجراء، مما يفصل بين الوحدات وبين القراءة والكتابة، وإن لم يفصل تماماً بين الإنشاء والموافقة؛ وحيثما احتجت إلى هذا الفصل الدقيق اليوم، قم بفرضه داخل خدمتك الخاصة قبل تنفيذ الطلب.

بالنسبة للعمليات ذات القيمة العالية، يجدر تقييم ما إذا كان ملف تعريف الأمان FAPI 2.0 ينطبق عليها. فقد صُمم خصيصاً لواجهات برمجة التطبيقات التي تحمي البيانات المالية الحساسة ويوفر ضمانات أقوى مقارنة ببروتوكول OAuth الأساسي. معظم عمليات تكامل محاسبة الشركات الصغيرة والمتوسطة لن تحتاج إلى ملف التعريف كاملاً، لكن تدفقات إطلاق المدفوعات والاتصال بالبنوك هي المواضع التي يجب أخذه فيها بعين الاعتبار.

تسجيل الدخول بدون كلمة مرور في Nordlet عبر روابط البريد الإلكتروني ذات الاستخدام الواحد يزيل مشكلة كلمات المرور القابلة لإعادة الاستخدام للمستخدمين البشريين، مما يقلل بيانات الاعتماد التي تحتاج إلى تدوير، أو التي قد تتعرض للتسريب أو التصيد الاحصائي.

جعل عمليات الكتابة المالية ذات معاملة واحدة (Idempotent)

تتعطل الشبكات في منتصف الطلب؛ حيث يرسل العميل تعليمة دفع، وينقطع الاتصال قبل وصول الاستجابة، فيعيد العميل المحاولة. وبدون حماية، يصبح لديك مدفوعتان الآن.

تحل مفاتيح المعاملة الواحدة (Idempotency keys) هذه المشكلة؛ إذ يرسل العميل مفتاحاً فريداً مع كل عملية كتابة، ويقوم الخادم بتسجيل المفتاح ونتيجته. إعادة المحاولة بنفس المفتاح تعيد النتيجة الأصلية بدلاً من إنشاء إدخال ثانٍ. تقبل Nordlet ترويسة Idempotency-Key في كل طلب تعديل، وتعيد تشغيل الاستجابة المخزنة عند إعادة المحاولة بنفس الحمولة وترفض نفس المفتاح إذا تغيرت الحمولة، وكل واجهة برمجة تطبيقات محاسبية تتخلى عن هذه الميزة ستنتج في النهاية قيوداً مزدوجة في دفتر الأستاذ يجب على شخص ما فك تشابكها يدوياً.

اقرن ذلك بالتحقق من جانب الخادم. لا تثق أبداً في العميل للتحقق من أن المدين يساوي الدائن، أو أن نسبة ضريبة القيمة المضافة صالحة للبلد والفترة، أو أن الحساب موجود. يتم إجراء التحقق على الخادم قبل انتقال الحالة، وتنتج عملية الكتابة المرفوضة خطأً مستقراً وسجل تدقيق.

مسارات تدقيق مقاومة للتلاعب ومتطلبات الاحتفاظ الهولندية

سجل التدقيق هو طبقة الأدلة، وله متطلبات تختلف عن بيانات الأعمال العادية. يجب أن يسجل قرار التفويض، وإصدار السياسة، والجهة المنفذة، والكسر المستهدف، والعملية، والحالة السابقة والجديدة، ورمز السبب، دون تسجيل الأسرار أو بيانات الاعتماد الكاملة للدفع بأي حال من الأحوال.

الخاصية الحاسمة هنا هي مقاومة التلاعب. فإذا تمكن أي مسؤول من تعديل أو حذف سجلات التدقيق بهدوء، فلن يثبت السجل أي شيء. التخزين المقتصر على الإضافة فقط، أو التسلسل التشفيري، أو الاحتفاظ الذي يُكتب لمرة واحدة، كلها طرق تعالج هذه المشكلة. والهدف هو أن يكون أي تعديل قابلاً للاكتشاف.

يستحق الاحتفاظ سياسة مستقلة خاصة به، منفصلة عن عمليات حذف سجلات الأعمال. ففي هولندا، تبلغ فترة الاحتفاظ العامة بالسجلات الإدارية سبع سنوات، وتمتد إلى عشر سنوات بالنسبة للسجلات المتعلقة بالعقارات. يجب ألا تتمكن سير عمل حذف البيانات العادية ومحو البيانات وفق لائحة حماية البيانات العامة (GDPR) من تدمير السجلات أو أدلة التدقيق التي لا تزال تخضع لقواعد الاحتفاظ القانونية. حدد قواعد الاحتفاظ القانوني، والأرشفة، والحذف لأدلة التدقيق بشكل مستقل، واربطها بالولاية القضائية التي تعمل ضمنها.

يدعم تأفل الفترات (Period locking) هذا الأمر على المستوى المحاسبي. بمجرد إغلاق الشهر، لا يمكن تغيير القيود الواردة فيه دون تفويض مرتفع المستوى وسبب مسجل. تطبق Nordlet تأفل الفترات لتبقى الشهر المغلقة مغلقة، وترفض أي قيد يحمل تاريخاً داخل فترة مغلقة حتى عبر واجهة برمجة التطبيقات، وهو أحد أوائل الأمور التي يتحقق منها المدقق الهولندي.

تأمين الحواف: خطافات الويب (Webhooks)، والصادرات، وعمليات التكامل

غالباً ما تكون واجهة برمجة التطبيقات الأساسية هي الجزء الأكثر تأميناً في النظام، بينما تتسرب الحواف من الأطراف.

خطافات الويب تمثل مخاطرة للطلبات المزوّرة. يجب توقيع حدث مثل sale_invoice.paid لكي يتمكن المستلم من التحقق من صدوره عنك، وينبغي على المستلم التعامل مع التسليم على أنه يتم "مرة واحدة على الأقل" واستخدام معرف الحدث لمنع التكرار. توقّع Nordlet كل عملية تسليم لخطاف الويب باستخدام توقيع HMAC على النص البرمجي الخام وتعيد محاولة عمليات التسليم الفاشلة بتراجع أسي، لذا يتعين على المستلم التحقق من التوقيع ومنع التكرار بمعرف الحدث بدلاً من افتراض التسليم مرة واحدة بالضبط.

تُعد الصادرات مساراً لتسريب البيانات بالجملة. فصادرات التقارير بتنسيقات XLSX أو PDF أو JSON تسحب أحجاماً كبيرة من البيانات المالية في عملية واحدة، ولذلك فهي تحتاج إلى إذن خاص بها، وحدود للسرعة، وتنسيق لسجلات التدقيق. أما عمليات التكامل التابعة لجهات خارجية والتي تستهلكها فيجب التعامل معها كمدخلات غير موثوقة، والتحقق منها بالطريقة التي تحقق بها مع طلبات العملاء المباشرة.

قائمة التحقق من الجاهزية للتدقيق لواجهة برمجة تطبيقات المحاسبة الهولندية

استخدم هذه القائمة قبل أن تزعم أن التكامل جاهز للتدقيق:

  • آلة حالات صريحة على كل مورد مالي؛ ولا يمكن الكتابة فوق القيود المرحلة
  • تفويض على مستوى الكائنات والكيان القانوني لكل طلب، مع الرفض الافتراضي
  • اشتقاق سياق المستأجر والدور من الرمز المميز وليس من مطالبات العميل
  • بروتوكول OAuth 2.0 وفقاً لـ RFC 9700؛ ونطاقات قائمة على القدرات؛ وفصل بين الإنشاء والموافقة
  • الفصل بين المهام مفروض في الأدوار، وليس مجرد موثق
  • مفاتيح المعاملة الواحدة على جميع عمليات الكتابة المالية
  • التحقق المحاسبي ومن ضريبة القيمة المضافة من جانب الخادم قبل انتقال الحالة
  • سجل تدقيق مقتصر على الإضافة وقابل للاكتشاف في حال التلاعب، ومرفق برمز الأسباب
  • قواعد الاحتفاظ والحفظ القانوني مرتبطة بالفترات الهولندية (سبع سنوات، وعشر سنوات للعقارات)
  • تأفل الفترات للأشهر المغلقة
  • خطافات ويب موقعة مع منع التكرار؛ وعمليات تصدير مقيدة النطاق ومحدودة المعدل وخاضعة للتسجيل

ما نبدؤه أولاً

لو كنا بصدد تضمين المحاسبة في منصة هولندية غداً، لبدأنا بنموذج الحالة وتفويض مستوى الكائنات، قبل كتابة نقطة نهاية أعمال واحدة. فهذان القرارآن يفرضان قيوداً على كل ما يأتي لاحقاً، وإعادة هندستهما في نظام كان يتعامل مع قيود دفتر الأستاذ كصفوف قابلة للتعديل تمثل عملية شاقة بحق. وتأتي مفاتيح المعاملة الواحدة وسجل التدقيق في المرتبة التالية، لرخص إضافتهما مبكراً وارتفاع تكلفتهما بعد تدفق البيانات.

أما البقية -الرموز المميزة المقيدة، وخطافات الويب الموقعة، وتأفل الفترات- فتتبع ذلك بسهولة أكبر بمجرد استقرار الأساس. ويمكن اختبار كل ذلك مقابل شركة افتراضية (sandbox) قبل أن يلامس أي جزء منها بيانات الإنتاج الفعلي.

FAQ

هل تعني واجهة برمجة التطبيقات الجاهزة للتدقيق أن الشركة ممتثلة تنظيمياً؟

لا، ومن المهم توخي الدقة هنا. الجاهزية للتدقيق هي خاصية تصميمية في النظام: حيث يتم بناء دفتر الأستاذ والضوابط وسلسلة الأدلة بطريقة تتيح نجاح التدقيق. أما الامتثال لإطار عمل ضريبي أو محاسبي أو أمني معين فهو تقييم منفصل يربط تلك الضوابط بمعيار محدد. واجهة برمجة التطبيقات المصممة جيداً تسهل العمل الخاص بالامتثال، لكنها لا تحل محله.

ما هي المدة التي يجب الاحتفاظ خلالها بالسجلات المحاسبية في هولندا؟

الالتزام العام هو سبع سنوات للسجلات الإدارية، ويمتد إلى عشر سنوات للسجلات المرتبطة بالعقارات. قم ببناء قواعد الاحتفاظ والحفظ القانوني بحيث لا تتمكن سير عمل الحذف العادية لديك من تجاوزها.

هل يكفي مفتاح واجهة برمجة تطبيقات ثابت لتكامل مالي؟

يمكن أن يفيد في أتمتة الاتصال بين الخوادم ذات النطاق الضيق، لكن المفاتيح الثابتة القابلة لإعادة الاستخدام يصعب تدويرها وتشكل خطورة في حال تسريبها. أما للوصول المفوض وأي تدفق يواجه المستخدم البشري، يظل بروتوكول OAuth 2.0 مع رموز قصيرة العمر ومقيدة النطاق هو الخيار الأقوى.

لماذا تُعد المعاملة الواحدة مهمة جداً للمحاسبة تحديدا؟

لأن تكرار عملية الكتابة في معظم الأنظمة يمثل إزعاجاً بسيطاً، بينما يمثل تكرارها في المحاسبة رقماً خاطئاً في الدفاتر يجب على شخص ما العثور عليه وعكسه. تجعل مفاتيح المعاملة الواحدة عمليات إعادة المحاولة آمنة بدلاً من كونها محفوفة بالمخاطر.

قراءات إضافية