الأمان والحماية

Zero-Trust Security Model

منصة ميثاق مبنية على بنية Zero-Trust — لا ثقة ضمنية، تحقق من كل طلب، سجّل كل شيء.

نموذج الأمان Zero-Trust

Zero-Trust يعني أن المنصة لا تثق بأي طلب بشكل ضمني — سواء جاء من داخل الشبكة أو خارجها. كل طلب يُصادَق عليه، يُرخَّص له، ويُشفَّر.

⚠️
تهديد محتمل
أي طلب — داخلي أو خارجي
🛡️
WAF / الطبقة الأمنية
فحص الحزم، Rate-limiting، إزالة الـ headers الخطرة
🔐
طبقة الهوية
التحقق من token، فحص الـ scope، SAML/OIDC
🧠
محرك الذكاء الاصطناعي
تقييم المخاطر في الوقت الفعلي
قرار الوصول
سماح أو رفض بناءً على التقييم

مبادئ Zero-Trust في ميثاق

التحقق دائمًا — لا ثقة بالنطاق.network source وحده
أقل صلاحية ممكنة — كل عميل يحصل على الصلاحيات الدنيا المطلوبة
تشفير كل شيء — البيانات في النقل وفي حالة السكون
مراقبة مستمرة — كل حركة مرور تُسجَّل وتحلَّل
عزل تام — العقد لا تتواصل مباشرة مع بعضها

تشفير البيانات

التشفير في النقل (In Transit)

كل الاتصالات بين المكونات مؤمّنة باستخدام TLS 1.2 أو TLS 1.3. الوكيل العكسي (Nginx) يفرض HTTPS على جميع الاتصالات العامة.

# TLS — منفذ HTTPS
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;

# HSTS — إجبار HTTPS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

التشفير في حالة السكون (At Rest)

قاعدة البيانات PostgreSQL مشفرة بالكامل باستخدام AES-256. مفاتيح التشفير تُدار بشكل منفصل عن بيانات المستخدم.

المستوىالتشفيرالمفتاح
قاعدة البياناتAES-256مُدارة عبر Vault
التخزين المؤقت (Redis)TLS + AUTHمُعرفة في التكوين
ملفات التكوينbcrypt
كلمات المرورbcrypt / Argon2لا يمكن عكسها
رموز JWTRS256 / ES256مُوقعة وليس مشفرة

خوارزميات التووقيع

# Access Tokens — RS256 (RSA Signature with SHA-256)
{
  "alg": "RS256",
  "typ": "JWT",
  "kid": "key-id-1"
}

# ID Tokens — RS256
# Refresh Tokens — مشفرة (encrypted at rest)

# ميثاق يستخدم RSA 2048-bit keys (minimum)
# الموصى به للإنتاج: RSA 4096-bit

سياسات كلمات المرور

كل نطاق (Realm) يمكن أن يحتوي على سياسات مختلفة لكلمات المرور. هذهPolicies تُفرض عند التسجيل وعند تغيير كلمة المرور.

الإعدادات المتاحة

الإعدادالقيمة الافتراضيةالوصف
Minimum Length8 أحرفالحد الأدنى لطول كلمة المرور
Maximum Length255 حرفالحد الأقصى لطول كلمة المرور
Require Digits✓ مفعليجب أن تحتوي على رقم واحد على الأقل
Require Special Characters✓ مفعليجب أن تحتوي على رمز خاص
Require Non-Alphanumeric✓ مفعلأحرف غير أبجدية
Check History3 كلماتعدم السماح بإعادة آخر N كلمة مرور
Force Expiration365 يومإجبار تغيير كلمة المرور دورياً
Max Login Failures5 محاولاتحظر الحساب بعد N محاولات فاشلة

تكوين سياسة كلمة المرور

# Admin Console → Realm Settings → Password Policy
# أو عبر Admin REST API:

PUT /admin/realms/{realm}
Content-Type: application/json

{
  "passwordPolicy": "length(12) and specialChars(1) and digits(1) and notUsername() and notEmail() and forceExpire()"
}
⚠️ أفضل الممارسات: لا تفرض تغيير كلمات المرور بشكل متكرر جداً — هذا يدفع المستخدمين لاختيار كلمات مرور أضعف._policy_best_practice الموصى به: 90-365 يوم.

سجلات التدقيق (Audit Logs)

كل عملية وصول وتغيير تُسجَّل في سجل تدقيق غير قابل للتعديل. هذه السجلات ضرورية للامتثال ولتحليل الحوادث الأمنية.

الأحداث المسجلة

تسجيل الدخول

كل محاولات تسجيل الدخول — ناجحة وفاشلة، مع IP وdevice

تسجيل الخروج

كل عمليات تسجيل الخروج الطوعي أو بسبب انتهاء الجلسة

إنشاء/تعديل/حذف مستخدم

كل عمليات إدارة المستخدمين والأدوار

محاولات الوصول المرفوضة

طلبات مرفوضة بسبب صلاحية غير كافية

تغيير كلمة المرور

تغيير كلمة المرور — لا تُسجَّل كلمة المرور نفسها

أحداث MFA

تسجيل دخول MFA ناجح أو فاشل

تنسيق السجلات

# نموذج سجل التدقيق (Audit Log Entry)
{
  "event": "LOGIN",
  "realm": "methaq",
  "client": "web-app",
  "user": "johndoe",
  "ipAddress": "203.0.113.42",
  "timestamp": "2026-04-24T10:30:00.000Z",
  "device": "Chrome 124 / Windows 11",
  "result": "SUCCESS",
  "sessionId": "session-uuid-here",
  "details": {
    "authMethod": "password",
    "mfaUsed": "TOTP",
    "riskScore": 0.1
  }
}

# الأحداث الفاشلة
{
  "event": "LOGIN_ERROR",
  "error": "invalid_user_credentials",
  "attemptCount": 3,
  "ipAddress": "198.51.100.14",
  "result": "FAILURE"
}

تصدير السجلات

# تصدير عبر Admin API
GET /admin/realms/{realm}/events?from=2026-01-01&to=2026-04-24&type=LOGIN,LOGIN_ERROR

# تصدير الأحداث من فترة محددة
GET /admin/realms/{realm}/events?from=2026-04-01T00:00:00Z&max=1000

#Events يمكن تصديرها بـ JSON أو CSV
# التكامل مع SIEM (Splunk, ELK, ArcSight) عبر webhook

حماية DDoS

طبقة WAF مخصصة تعمل على حافة الشبكة قبل وصول أي طلب إلى خادم التطبيق. مصممة لـ:

  • منعattacks الحجمية (SYN flood, UDP flood, HTTP flood)
  • منع滥用 (abuse) من عناوين IP معينة
  • تطبيق rate-limiting على مستوى الحافة
  • كشف وإزالةtraffic المشبوهة

تكوين Rate Limiting

# Nginx — حدود المعدل
limit_req_zone $binary_remote_addr zone=general:10m rate=10r/s;
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;
limit_req_zone $binary_remote_addr zone=auth:10m rate=5r/m;

# تطبيق الحدود
location / {
    limit_req zone=general burst=20 nodelay;
}

location /api/ {
    limit_req zone=api burst=50 nodelay;
}

location /auth/ {
    limit_req zone=auth burst=5 nodelay;
}

OWASP CRS Rules

ModSecurity مع OWASP Core Rule Set (CRS) يوفر حماية من:

الفئةأمثلة
SQL Injection' OR 1=1--, UNION SELECT, DROP TABLE
XSS<script>, javascript:, onerror=
Command Injection; cat /etc/passwd, | ls, $()
Path Traversal../../../etc/passwd, %2e%2e%2f
Scanner Detectionsqlmap, nikto, nmap signatures
Remote File Inclusionhttp://evil.com/shell.txt

كشف الاختراق والسلوك المشبوه

محرك الذكاء الاصطناعي يقيّم كل طلب في الوقت الفعلي ويعين درجة مخاطر (Risk Score). بناءً على النتيجة، يمكن للمنصة:

1

جمع الإشارات

IP, device fingerprint, browser, geolocation, وقت الطلب, معدل الطلبات, تاريخ المستخدم

2

تقييم المخاطر

المحرك يقارن الإشارات بالنماذج المدربة لاكتشاف الأنماط المشبوهة

3

قرار التكيف

النتيجة تحدد الإجراء — allow, challenge (MFA), or deny

4

التسجيل والتحذير

كل قرار يُسجَّل، وإذا كانت النتيجة عالية يُرسل تنبيه فوري

درجات المخاطر

النتيجةالمستوىالإجراء
0.0 - 0.3🟢 طبيعيسماح فوري
0.3 - 0.6🟡 مشبوهتسجيل ومراقبة
0.6 - 0.8🟠 مرتفعطلب MFA إضافي
0.8 - 1.0🔴 حرجرفض الطلب + إشعار