مشروع لعميل
القطاع: المحاسبة والامتثال الضريبي
إضافة متصفح للفاتورة الإلكترونية لا توقّع أي مستند دون موافقة بشرية
- Chrome Manifest V3
- JavaScript
- Web Crypto API
- AES-256-GCM
- ECDSA P-256
- Cloudflare Workers
- Cloudflare D1
- ExcelJS
مدة التنفيذ: تُحدد بعد دراسة النطاق؛ لا يوجد سجل تسليم موثق منشور.
نظرة عامة
منتجنا الخاص: إضافة متصفح مستقلة موجّهة لفرق المحاسبة والمالية في مصر، تضيف إلى بوابة الفاتورة الإلكترونية التابعة لمصلحة الضرائب المصرية التصدير المجمّع للفواتير، ومطابقتها مع إقرار ضريبة القيمة المضافة، وأرشيفًا مشفّرًا، وإصدار الفواتير الإلكترونية. وقد أُطلقت الإضافة بفترة تجريبية مجانية وترخيص مدفوع، وخدمة التراخيص الخاصة بها تعمل حاليًا.
التحدي
تعرض البوابة الفواتير صفحةً تلو الأخرى، بلا تصدير مجمّع ولا مطابقة مع إقرار ضريبة القيمة المضافة ولا أرشيف، فكانت فرق المحاسبة تنقل البيانات يدويًا. وكان سدّ هذه الفجوة يتطلب تشغيل كود داخل موقع حكومي لا نتحكم فيه وقد يتغير دون إشعار، حيث يتقاسم هذا الكود الصفحة مع أي سكربت آخر يُحمَّل عليها، مع التعامل في الوقت نفسه مع أرقام PIN لشهادات التوقيع وبيانات الاعتماد السرية لأنظمة ERP وبيانات ضريبية حقيقية.
الحل
أقمنا داخل الإضافة حدًّا صارمًا للثقة. فالكود الذي يعمل داخل صفحة البوابة يستطيع تجهيز الفاتورة ووضعها في قائمة الانتظار، لكنه لا يستطيع توقيعها أو إرسالها مطلقًا. ولا يحتفظ بأرقام PIN للشهادات وبيانات الاعتماد السرية لأنظمة ERP إلا مكوّن الخلفية في الإضافة (service worker)، وفي الذاكرة فقط، وكل توقيع ينتظر موافقة شخص عبر نافذة Secure Console منفصلة لا تستطيع الصفحة الوصول إليها. وترفض قاعدة البيانات المحلية للإضافة تخزين أي حقل باسم token أو authorization أو PIN أو password أو client secret، حتى لا يؤدي أي تعديل لاحق في الكود إلى حفظ أي منها عن غير قصد، وإذا لم تتطابق الشركة المختارة مع التسجيل الضريبي للحساب المفتوح على البوابة تتوقف الإضافة بدلًا من تصدير فواتير شركة أخرى. وتُحفظ الأرشيفات في خزينة محمية بكلمة مرور ومشفّرة بـ AES-256-GCM لكل شركة على حدة، وتُشفَّر النسخ الاحتياطية بـ AES-256-GCM، مع اشتقاق المفاتيح عبر PBKDF2 بـ 310,000 تكرار. وتحمل التراخيص المدفوعة توقيع ECDSA P-256 مرتبطًا برمز التثبيت وبتاريخ انتهاء، تتحقق منه الإضافة دون أي اتصال بالشبكة. ولا يُقبل أي تحديث إلا إذا طابق بصمة SHA-256 وحمل توقيع ECDSA P-256 صالحًا يُتحقق منه بمفتاح عام ثبّته المستخدم. ولم يخضع هذا التصميم لأي تقييم أمني خارجي.
كيف نتحقق من النجاح
نتفق قبل التنفيذ على خط أساس ومعايير قبول واضحة. ثم نوثق الأداء والفحوصات الأمنية واختبارات الاستعادة والتسليم التشغيلي مقارنة بهذا الأساس. لا ندّعي أي نسبة تحسن دون قياس موثق.