الأمن والنزاهة

أمن معاملاتنا المالية ونزاهتها

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

1. خوادم الأنظمة المصرفية الأساسية

تشكل هذه الخوادم العمود الفقري التشغيلي المركزي، إذ تدير حسابات العملاء والمعاملات والامتثال:

• خوادم معالجة المعاملات: تنفّذ التفويض الفوري للمدفوعات وفحوص الاحتيال والتسويات (مثل SWIFT وSEPA).
• خوادم إدارة الحسابات: تعالج أحداث دورة حياة الحساب (الفتح والإغلاق)، واحتساب الفوائد، ومراقبة السيولة.
• خوادم الامتثال التنظيمي: أتمتة عمليات التحقق الخاصة بـ AML (مكافحة غسل الأموال) ومسارات التدقيق وإعداد التقارير (مثل IFRS وGDPR).

2. خوادم دفتر الأستاذ

مسؤولة عن الحفاظ على السجلات المالية غير القابلة للتغيير:

• خوادم دفتر الأستاذ العام: تتتبع القيد المزدوج عبر الحسابات، بما يضمن الامتثال للمعايير المحاسبية مثل IFRS.
• خوادم تقنية السجل الموزع (DLT): أنظمة قائمة على سلسلة الكتل (البلوكتشين) للمدفوعات عبر الحدود والتحقق من KYC وسجلات المعاملات المحصّنة ضد العبث.

3. خوادم الاتصال الخارجي
تتيح التفاعل الآمن مع الجهات الخارجية:

• خوادم EBICS: تدير معيار الاتصال المصرفي الإلكتروني عبر الإنترنت (Electronic Banking Internet Communication Standard) لمدفوعات SEPA، وتُستخدم على نطاق واسع في ألمانيا وفرنسا وسويسرا.
• خوادم الربط المباشر بين الأنظمة (H2H): اتصالات SFTP/FTPS مباشرة لمعاملات الشركات كبيرة الحجم (مثل معالجة الرواتب المجمّعة).
• خوادم بوابة واجهات برمجة التطبيقات (API): توفّر واجهات RESTful لبدء الدفع وتجميع الحسابات في الوقت الفعلي (مؤمَّنة عبر OAuth2/mTLS).
• خوادم واجهة Swift: تربط المصرف بشبكة Swift لتبادل الرسائل بين المصارف (و SCORE هي المجموعة المغلقة من المستخدمين التي أنشأتها Swift لوصول الشركات، وليست نوعًا من الخوادم).

4. خوادم قواعد البيانات
مستودعات مركزية للبيانات المالية المنظمة:

• خوادم بيانات العملاء: تخزّن مستندات KYC وسجلات المعاملات والتحليلات السلوكية.
• خوادم كتالوج المنتجات: تدير العروض مثل القروض والرهون العقارية وأسعار الودائع.

5. خوادم الأمن والبنية التحتية
ضمان سلامة النظام والالتزام بالمتطلبات التنظيمية:

• خوادم وحدات الأمان المادية (HSM): تحمي المفاتيح التشفيرية المستخدمة في التوقيعات الرقمية وفي تشفير SSL/TLS.
• خوادم جدار الحماية/الشبكة الخاصة الافتراضية (VPN): تفرض تجزئة الشبكة وتؤمّن الوصول عن بُعد للموظفين.
• خوادم التعافي من الكوارث: تستضيف أنظمة احتياطية لضمان استمرارية الأعمال أثناء الانقطاعات.

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

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

• الأسلوب المركّب: المحاكاة الافتراضية (VMware، KVM) أو الحاويات (Docker/Kubernetes)
• مثال: استضافة بوابات مصرفية متعددة (للأفراد والشركات والهاتف المحمول) على مجموعة خوادم افتراضية (hypervisor cluster) مع موازنة الأحمال.

2. خوادم قواعد البيانات

• أسلوب الجمع: قواعد بيانات سحابية متعددة المستأجرين (AWS RDS وAzure SQL)
• يمكن لقواعد بيانات الأنظمة المصرفية الأساسية القائمة على Oracle/MS SQL أن تتعايش مع أنظمة التحليلات القائمة على PostgreSQL/MongoDB في بيئات السحابة الهجينة.

3. بوابات الاتصال الخارجية

• أسلوب الدمج: بوابات واجهات برمجة التطبيقات الموحّدة (Apigee وMuleSoft)
• يمكن تشغيل خدمات EBICS وSWIFT وSFTP على بنية تحتية مشتركة مع خدمات مصغّرة خاصة بكل بروتوكول.

4. خوادم التعافي من الكوارث

• أسلوب الدمج: التكرار الجغرافي النشط-النشط
• يمكن لنسخ النظام المصرفي الأساسي وخوادم دفتر الأستاذ الاحتياطية أن تتشارك مجموعات خوادم التعافي من الكوارث.

5. خوادم الوسيط البرمجي (Middleware)

• أسلوب الدمج: ناقل الخدمات المؤسسي (ESB)
• توحيد خدمات توجيه المدفوعات وفحوصات الامتثال وتحويل العملات على منصتي IBM Integration Bus/SAP PI.

الخوادم التي ينبغي أن تبقى معزولة
1. خوادم معالجة المعاملات الأساسية

• السبب: إن الفصل (المادي أو بتجزئة صارمة) يقلّص نطاق ضوابط PCI DSS وSOC 2
• مثال: لا يمكن لأنظمة IBM zSystems التي تشغّل مراقبات معاملات CICS مشاركة العتاد مع أحمال عمل أخرى.

2. خوادم وحدات الأمان المادية (HSM)

• السبب: يشترط المعيار FIPS 140-2/140-3 المستوى 3 استخدام أجهزة مخصصة مقاومة للعبث
• التنفيذ: وحدات أمان مادية (HSM) من Thales/Gemalto تتولى التوقيعات الرقمية ومفاتيح التشفير.

3. أنظمة دفتر الأستاذ الفورية

• السبب: يقتضي القيد المزدوج في مسك الدفاتر أن تكون العمليات ذرّية (غير قابلة للتجزئة)
• مثال: خوادم دفتر الأستاذ في Oracle Financial Services المزوّدة بوحدات تخزين NVMe متصلة مباشرةً.

4. خوادم الإبلاغ التنظيمي

• السبب: يجب حماية سجلات التدقيق من التعديل والاحتفاظ بها للمدد التي تشترطها اللائحة العامة لحماية البيانات (GDPR) وقوانين مكافحة غسل الأموال؛ ويسهّل الفصل بينها إثبات ذلك
• الإعداد: مثيلات SQL Server معزولة لتقارير MiFID II/FATCA.

5. أنظمة التفويض لأجهزة الصراف الآلي/نقاط البيع

• السبب: اتفاقية مستوى الخدمة التي تضمن جاهزية بنسبة 99.999% ومتطلبات تجزئة الشبكة
• البنية: أنظمة IBM Power مع شبكات تخزين SAN احتياطية تعمل بتقنية Fibre Channel.

القيود التقنية:

• تتطلب أنظمة الخدمات المصرفية الأساسية ذات الحجم الكبير اتصالات شبكية مخصصة وعالية النطاق الترددي
• يشترط معيار PCI DSS جعل أرقام البطاقات المخزَّنة (PAN) غير قابلة للقراءة وعزل بيئة بيانات حامل البطاقة
• يشترط برنامج أمن العملاء (CSP) من SWIFT أن تقع البنية التحتية لـ SWIFT ضمن منطقة آمنة محمية

لقد نجحنا في دمج 80% من الخوادم غير الحرجة (الويب/التطبيقات/البرمجيات الوسيطة) مع إبقاء الأنظمة الأساسية ووحدات HSM وأنظمة دفتر الأستاذ معزولة تمامًا.

يتطلب تأمين خوادم دفتر الأستاذ في السحابة حمايات متعددة الطبقات تتناسب مع حساسية البيانات المالية. واستنادًا إلى أفضل ممارسات الأمن لدى AWS وإلى التطبيقات الخاصة بالقطاع المصرفي، نعرض فيما يلي مقاربة منظمة:

1. تقنية السجل غير القابل للتغيير
استخدام قواعد بيانات سجلية مصممة لهذا الغرض مع تحقق تشفيري من كل معاملة:

• التسلسل التشفيري: تُحسب قيمة تجزئة (Hash) لكل معاملة وتُربط بالقيد السابق، مما يُنشئ سجل تدقيق غير قابل للتعديل.
• ضوابط نزاهة مدمجة: تتحقق قاعدة البيانات تلقائياً من سجلّها التاريخي، بما يحول دون العبث بها.
• الاستعلام بأسلوب SQL: يحافظ على التوافق مع الأنظمة المالية القائمة مع إضافة أمن يضاهي أمن سلاسل الكتل.

2. عزل الشبكة

• بنية VPC: نشر خوادم دفتر الأستاذ في شبكات فرعية خاصة دون أي اتصال بالإنترنت العام.
• مجموعات الأمان: تقييد حركة البيانات الواردة بمنافذ محددة (مثل PostgreSQL/Aurora) من نطاقات عناوين IP المعتمدة مسبقًا.
• نقاط نهاية VPC: استخدام AWS PrivateLink للاتصال الآمن بين خوادم دفتر الأستاذ والخدمات مثل S3/KMS دون تعريض البيانات للإنترنت العام.

3. التشفير

• في حالة السكون: تقوم مفاتيح مُدارة عبر AWS KMS بتشفير بيانات دفتر الأستاذ في Amazon Aurora، مع تدوير تلقائي للمفاتيح.
• أثناء النقل: فرض بروتوكول TLS 1.3 على جميع الاتصالات بين العميل والخادم وبين الخدمات.
• التشفير من جانب العميل: تشفير الحقول الحساسة (مثل أرصدة الحسابات) قبل تخزينها باستخدام AWS Encryption SDK.

4. التحكم في الوصول

• أدوار إدارة الهوية والوصول (IAM): منح صلاحيات دقيقة (مثل أدوار الإدخال فقط) لمنع حذف البيانات عن طريق الخطأ أو بدافع خبيث.
• بيانات الاعتماد المؤقتة: استخدام AWS STS لإتاحة وصول محدد المدة أثناء أعمال الصيانة.
• فرض المصادقة متعددة العوامل: اشتراط استخدام رموز مصادقة مادية (YubiKey) لحسابات الجذر والمسؤولين.

5. الرقابة والتدقيق

• التنبيهات الفورية: قم بضبط AWS CloudWatch لإطلاق تنبيهات عند رصد أنماط معاملات غير معتادة (مثل التحويلات التي تتجاوز 1 مليون يورو).
• سجلات النشاط: تتبّع جميع التعديلات على دفتر الحسابات عبر AWS CloudTrail المتكامل مع أدوات SIEM.
• عمليات التدقيق الآلية: تشغيل قواعد AWS Config أسبوعياً للتحقق من حالة التشفير وسياسات الشبكة.

6. الامتثال والحوكمة

• التقسيم القائم على النطاقات: فصل بيئات دفتر الأستاذ الخاصة بالتطوير والاختبار والإنتاج (DEV/TEST/PROD) باستخدام AWS Organizations.
• التقارير الآلية: إعداد تقارير الامتثال لمعيار PCI DSS واللائحة العامة لحماية البيانات (GDPR) عبر AWS Audit Manager.
• عمليات التدقيق من جهات خارجية: جدولة اختبارات اختراق سنوية بالاستعانة بشركاء معتمدين من AWS.

7. التعافي من الكوارث

• النسخ المتماثل عبر المناطق: الاحتفاظ بنسخ متماثلة مشفّرة من دفتر الأستاذ في منطقتي AWS في فرانكفورت وستوكهولم.
• الاسترداد إلى نقطة زمنية محددة: تفعيل النسخ الاحتياطية المستمرة لاستعادة البيانات إلى أي ثانية ضمن مدة الاحتفاظ (حتى 35 يومًا).
• النسخ الاحتياطية المعزولة عن الشبكات: تُحفظ لقطات دفتر الأستاذ الفصلية في AWS Backup Vault مع الاحتفاظ بها لمدة 7 سنوات.

لمنع انتقال المدخلات الضارة إلى خوادم التعافي من الكوارث (DR)، تطبّق المصارف استراتيجيات أمنية متعددة الطبقات تعزل النسخ الاحتياطية وتفرض ضوابط صارمة للوصول وتتحقق من سلامة البيانات. وفيما يلي عرض تقني للتدابير الرئيسية:
1. نسخ احتياطية غير قابلة للتعديل بتكوينات الكتابة مرة واحدة والقراءة مرات عديدة (WORM)

• الغرض: منع برمجيات الفدية من تعديل بيانات النسخ الاحتياطية أو تشفيرها.

التنفيذ: استخدام خاصية Object Lock في AWS S3 أو التخزين غير القابل للتعديل في Azure Blob لمنع الحذف أو التعديل خلال مدة احتفاظ محددة. وتطبيق التجزئة التشفيرية (SHA-256) على الملفات الاحتياطية؛ بحيث يؤدي أي تلاعب إلى إبطال قيمة التجزئة وإطلاق تنبيهات.
2. النسخ المتماثل المعزول عن الشبكة وغير المتصل

• عزل الشبكة: تُخزَّن خوادم التعافي من الكوارث في شبكة سحابية افتراضية خاصة (VPC) أو شبكة محلية افتراضية (VLAN) منفصلة دون أي اتصال وارد من الإنترنت. ويُستخدم النسخ المتماثل أحادي الاتجاه (من الخادم الرئيسي إلى خادم التعافي) عبر أدوات مثل AWS Storage Gateway أو Azure Site Recovery، مع حظر المزامنة العكسية.
• العزل المادي عن الشبكة: بالنسبة إلى الأنظمة الحرجة، يُحتفظ بنسخ احتياطية على أشرطة أو بتخزين غير متصل بالإنترنت لا يتصل إلا خلال نوافذ النسخ المتماثل المجدولة.

3. ضوابط النفاذ القائمة على مبدأ انعدام الثقة

• المصادقة: فرض المصادقة متعددة العوامل (MFA) على جميع واجهات إدارة التعافي من الكوارث (مثل AWS SSO وAzure AD Conditional Access). وإسناد أدوار إدارة الهوية والوصول (IAM) بأقل الصلاحيات اللازمة (مثل `s3:GetObject` فقط).
• أمن الشبكة: قصر حركة المرور الخاصة بالنسخ المتماثل على أنفاق الشبكات الخاصة الافتراضية (VPN) المعتمدة على IPsec أو على AWS Direct Connect/Azure ExpressRoute. ونشر أنظمة كشف التسلل (IDS) مثل Snort أو Suricata لمراقبة قنوات النسخ المتماثل.

4. التحقق من سلامة البيانات

• الفحوص السابقة للنسخ المتماثل: فحص البيانات المصدر بحثًا عن البرمجيات الخبيثة باستخدام أدوات مثل ClamAV أو CrowdStrike Falcon قبل النسخ. ومقارنة المجاميع الاختبارية (checksums) قبل النقل وبعده للكشف عن أي عبث.
• عمليات التدقيق بعد النسخ المتماثل: استخدم AWS Config أو Azure Policy لفرض سياسات التشفير والوصول على خوادم التعافي من الكوارث. وجدوِل فحوصات سلامة يومية عبر نصوص برمجية (مثل التحقق باستخدام `sha256sum`).

5. بيئات مقسَّمة منطقيًا

6. اختبار التحويل التلقائي عند الأعطال

• الهجمات المحاكاة: استخدام أدوات مثل Chaos Monkey لمحاكاة الإصابة ببرمجيات الفدية والتحقق من قدرة خوادم التعافي من الكوارث على الصمود. وقياس أهداف زمن التعافي (RTO) وأهداف نقطة التعافي (RPO) أثناء التمارين.
• التحليل الجنائي الرقمي: الاحتفاظ بسجلات تدفق VPC وأحداث CloudTrail لمدة 90 يوماً لتتبع حالات الشذوذ في عمليات النسخ المتماثل.

يُعدّ تطبيق النسخ الاحتياطية غير القابلة للتعديل أمرًا بالغ الأهمية لحماية البيانات من برامج الفدية والحذف العرضي ومخالفات الامتثال. واستنادًا إلى معايير القطاع وأدوات مثل AWS وVeeam وAzure، فيما يلي أفضل الممارسات:
1. فرض عدم قابلية التعديل على مستوى التخزين

• استخدام تكوينات WORM (الكتابة مرة واحدة والقراءة المتعددة) عبر تخزين الكائنات باستخدام S3 Object Lock (AWS) أو Azure Immutable Blob Storage أو Veeam Hardened Repositories.
• فعّل أقفال الاحتفاظ لمنع الحذف أو التعديل قبل الأوان، حتى من جانب المسؤولين.

2. اعتماد استراتيجية النسخ الاحتياطي 3-2-1-1

• 3 نسخ من البيانات (النسخة الأساسية + نسختان احتياطيتان)
• نوعان من وسائط التخزين (مثل القرص + السحابة)
• نسخة واحدة خارج الموقع (معزولة جغرافيًا)
• نسخة واحدة غير قابلة للتعديل (معزولة عن الشبكة أو مزوّدة بتقنية WORM).

3. تطبيق ضوابط صارمة للوصول

• الوصول القائم على الأدوار (RBAC): تقييد الصلاحيات باستخدام أدوار إدارة الهوية والوصول (IAM) (مثل سياسات الوصول إلى خزائن النسخ الاحتياطي في AWS Backup).
• المصادقة متعددة العوامل (MFA): تُفرض على واجهات إدارة النسخ الاحتياطي (مثل الوصول المشروط في Azure AD).
• عزل الشبكة: تخزين النسخ الاحتياطية في شبكات فرعية/سحابات افتراضية خاصة دون أي وصول إلى الإنترنت العام.

4. تشفير البيانات من طرف إلى طرف

• عند التخزين: استخدم AES-256 أو مفاتيح مُدارة عبر KMS (AWS وAzure).
• أثناء النقل: بروتوكول TLS 1.3 لقنوات النسخ المتماثل.
• التشفير من جانب العميل: تشفير الحقول الحساسة مسبقًا قبل النسخ الاحتياطي (مثل تشفير AES-256 في Veeam باستخدام مفاتيح يديرها المستخدم).

5. أتمتة الاحتفاظ بالسجلات والتحقق منها

• سياسات الاحتفاظ: تحديد هدف نقطة الاسترداد (RPO) وهدف وقت الاسترداد (RTO) وأتمتة قواعد دورة الحياة (مثل الاحتفاظ لمدة 7 سنوات في AWS Backup Vault).
• التحقق من المجموع الاختباري (Checksum): التحقق من سلامة البيانات قبل النسخ المتماثل وبعده (مثل التجزئة باستخدام SHA-256).
• عمليات تدقيق منتظمة: استخدم أدوات مثل AWS Config أو Veeam SureBackup لاختبار عمليات الاستعادة.

6. اعتماد طبقات أمنية متعددة للبيئات الهجينة

7. ضمان الامتثال وعدم قابلية الرجوع

• تثبيت إعدادات عدم قابلية التعديل بعد الاختبار (مثل حالة «مُفعَّل ومقفل» في Azure).
• الامتثال للأنظمة: مواءمة العمليات مع اللائحة العامة لحماية البيانات (GDPR) وقانون HIPAA وقانون SOX باستخدام أدوات مثل AWS Audit Manager.
• عمليات التدقيق من أطراف ثالثة: جدولة اختبارات اختراق سنوية (باستخدام شركاء معتمدين من AWS على سبيل المثال).

مثال على سير العمل باستخدام AWS وVeeam
1. النسخ الاحتياطي الرئيسي: Veeam Backup & Replication إلى حاوية S3 مع Object Lock.
2. النسخ المتماثل: AWS DataSync إلى منطقة ثانوية (فرانكفورت ← ستوكهولم).
3. التحقق: سجلات CloudTrail اليومية + تمارين استعادة ربع سنوية.
4. الاحتفاظ: فترة 90 يوماً غير قابلة للتعديل مع تشفير KMS.

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