الرمز البديل لبيانات حساسة يختلف عن الرمز الذي يخول الوصول. يظل نطاق الاستخدام والتحقق من الصلاحيات على الخادم أساسيين للحماية.
استبدال القيمة لا يلغي كل المخاطر
تستبدل تقنية tokenization قيمة حساسة برمز بديل. قد يكون التصميم قابلًا للعكس أو غير قابل له، مع خزنة للمطابقة أو دونها. وقد يتيح الرمز الربط بين السجلات أو تنفيذ عمليات مسموحة؛ لذا ليست سرقته عديمة الأثر بالضرورة. استخدام أسماء مستعارة لا يساوي إخفاء الهوية: تبقى البيانات شخصية متى تحققت شروط GDPR.
حماية القناة وفحص كل عملية
يحمي TLS الاتصال بين نقطتي إنهائه، لكنه لا يصلح خلل الصلاحيات أو خادمًا مخترقًا. رمز JWT الموقّع ليس مشفرًا بالضرورة؛ فقد تكون محتوياته مقروءة. تحقق من التوقيع والمُصدر والجمهور المقصود والصلاحية وفق البروتوكول ثم من حقوق الكائن. مع OAuth، استند إلى RFC 9700 وحدد العمر والإلغاء والحماية من إعادة الاستخدام حسب البنية.
ثلاث آليات وحدود حمايتها
| الآلية | الوظيفة | الحد الواجب فحصه |
|---|---|---|
| الترميز البديل للبيانات | استبدال قيمة حساسة. | المطابقة وإعادة التعرف والاستخدامات الممكنة للرمز. |
| التشفير | حماية السرية باستخدام المفاتيح. | إدارة المفاتيح وانكشاف البيانات بعد فك التشفير. |
| رمز الوصول | تقديم تفويض إلى خدمة. | قد يعاد استخدام bearer token مسروق؛ يجب فحص الحقوق على الخادم. |
المصادر ونطاقها
- PCI SSC · Tokenization Product Security Guidelines · 2015 · pp. 6–8
- IETF · RFC 7519 · JSON Web Token · 2015
- IETF · RFC 9700 · OAuth 2.0 Security BCP · 2025
- EUR-Lex · GDPR / RGPD · Art. 4(5), recital 26
المراجعة التحريرية: 31 أكتوبر 2026.
لا تخلط بين البيانات المحمية والإجراءات المصرح بها.
يقلل التشفير والترميز من انكشاف بعض البيانات، لكنهما لا يحددان ما إذا كان استدعاء واجهة برمجة التطبيقات (API) مسموحاً له بقراءة كائن أو تشغيل عملية. تُدرج OWASP التخويل على مستوى الكائن ومستوى الوظيفة ضمن مخاطر واجهة برمجة التطبيقات الرئيسية.
- تحقق من الأذونات على كل كائن وإجراء مطلوب، حتى خلف بوابة مصادقة.
- اختبار الطلبات بين الحسابات والأدوار باستخدام بيانات تجريبية.
- الاحتفاظ بسجلات جاهزة للتحقيق دون تسجيل البيانات السرية أو القيم الحساسة كنص عادي.
المصدر الأساسي: OWASP API Security Top 10 — 2023. المنهج المرتبط: اقرأ الدليل العملي.
مفاتيح المرور: الاستعداد لتغيير النطاق وRP ID
فصل الحساب وأصل الويب وRP ID لتجنب إعادة ربط بيانات الاعتماد بصمت.
- سجّل الأصول القديمة والجديدة وRP ID والحسابات المرتبطة. تطابق اسم الحساب لا يجعل مفتاح المرور صالحاً لـRP ID آخر. افحص التركيبات المسموحة في WebAuthn ومسارات الوصول المتاحة أثناء الانتقال.
- في بيئة اختبار مصرح بها افحص التحدي والأصل وRP ID وربط الحساب بمكتبة مناسبة. جرّب أصلاً غير متوقع وتحدياً معاداً. تغيير RP ID يتطلب تسجيلاً جديداً موثّقاً؛ نسخ صف لا ينقل المفتاح.
- اختبر مستخدماً يملك الاعتماد القديم فقط والاسترداد والجلسات المفتوحة. حدّد فتح المسارات وإيقافها مع رجوع مختبر. التسجيل في النطاق الجديد لا يثبت إلغاء كل الجلسات القديمة.
حالة قبول قابلة للتكرار
مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.
عرض بيانات الحالة
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}القرار المتوقع
مثال افتراضي: الحساب نفسه، لكن old.example يصبح new.example مع RP ID مختلف. لا يعاد ربط الاعتماد القديم بصمت؛ يتبع التسجيل الجديد المسار الموثّق المخطط.
هل يمكن تغيير RP ID لمفتاح المرور بتعديل قاعدة البيانات؟
لا. RP ID جزء من النطاق المتحقق منه للاعتماد. أعد تسجيلاً صالحاً للنطاق الجديد وربط حساب موثّقاً.
المصدر الأساسي: W3C — Web Authentication Level 2. المنهج المرتبط: اقرأ الدليل العملي.
تجديد TLS: التحقق من الشهادة المقدمة فعلياً
متابعة التجديد إلى نقاط إنهاء TLS والعملاء قبل إعلان اكتمال التغيير.
- سجّل الأسماء وCDN وموازنات الحمل والوكلاء والاتصالات الداخلية ذات الشهادات. دوّن الشهادة المقدمة وسلسلتها وانتهاءها والمسؤول. الإصدار لا يثبت التثبيت على كل عقدة. احم المفاتيح الخاصة ولا تدرجها في السجل.
- اختبر الأتمتة في بيئة اختبار المزود إن وجدت. افحص تحديات التحقق وأسماء SAN والتخزين المحمي وإعادة تحميل المكونات. تجنب الإصدار عند كل بدء إذا وجدت شهادة صالحة وفق سياسة المفاتيح.
- افحص الأسماء والتواريخ وسلسلة الثقة بالعملاء المدعومين عبر المسارات المهمة. أبق تحقق TLS فعالاً. راقب انتهاء الشهادة المقدمة لا حالة المجدول فقط. الرجوع يحتاج شهادة صالحة ومفتاحاً غير مخترق؛ وإلا أصلح النقطة أو اعزلها.
حالة قبول قابلة للتكرار
مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.
عرض بيانات الحالة
{
"issuance_succeeded": true,
"proxy_count": 2,
"proxies_serving_expected_certificate": 1,
"other_proxy_certificate_expired": true,
"tls_verification_enabled": true,
"expected": "change_incomplete_fix_and_verify_client_paths"
}القرار المتوقع
مثال افتراضي: التجديد ناجح لكن أحد وكيلين يقدم شهادة منتهية. التغيير غير مكتمل؛ أصلح الوكيل وافحص مسارات العملاء دون تعطيل تحقق TLS.
المصدر الأساسي: Let’s Encrypt — Integration Guide. المنهج المرتبط: اقرأ الدليل العملي.
المراجع: البيانات والاستخدامات والحدود
تاريخ مراجعة الوثائق .
الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.
| المصدر والغرض | بيانات أو معيار متحقق منه | كيفية الاستخدام | حدود يجب مراعاتها |
|---|---|---|---|
| MITRE · Common Weakness Enumeration Name classes of software and hardware weakness. |
A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. | Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests. | A keyword in a report alone does not establish the correct CWE classification. |
| OASIS · TAXII 2.1 Exchange threat intelligence through an application protocol. |
TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. | Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed. | TAXII transports data; it replaces neither the content model nor assessment of reliability. |
استكشاف كتالوج CISA KEV
الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.
One identifier can span several technical layers
An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.
- Connect the CVE, component supplier and final-product supplier.
- Check version, configuration and execution path in the authorised environment.
- Do not infer remediation from an empty search result.
CISA KEV · 2026.11.06 · Documentary review : 2026-11-07
الوسائط: التطهير والأدلة
الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.
Encryption and erasure require different evidence
Encryption protects access while keys and implementation retain their properties. Cryptographic erase requires suitable encrypted scope and sanitization of relevant keys; it does not follow from API-token removal.
- Map data-encryption, wrapping and derivation keys and external copies.
- Check whether target sensitive data previously existed in plaintext.
- Record technical outcome, limits and validation without retaining secrets in the evidence.
Read the methods, evidence points and annotated situations →
NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23