وسيط API مشفّر يحمي من إعادة الإرسال
يحمي CRelay بيانات طلبات API الحساسة بعد HTTPS، عبر تشفير AES-256-GCM، والتحقق من حداثة الطلب، وربط الحمولة بالمسار، وتشفير الاستجابة.
SDK مفتوح. بروتوكول موثّق. حماية مُدارة.
HTTPS يحمي القناة. CRelay يحمي الحمولة.
بعد انتهاء TLS، قد تظهر البيانات الحساسة داخل السجلات أو البروكسيات أو الطوابير أو الخدمات الداخلية. يضيف CRelay حماية على مستوى الحمولة نفسها، مع منع إعادة الإرسال وربط الطلب بسياقه الصحيح.
عند انتهاء TLS، تصبح الحمولة نصًا واضحًا داخل البنية التحتية؛ وقد تصل إلى السجلات والطوابير والبروكسيات.
من دون حماية من إعادة الإرسال، يمكن استخدام الطلبات الملتقطة مرة أخرى. قبول الحمولة نفسها مرتين قد يعني رسومًا مزدوجة أو إجراءات مكررة.
من دون ربط الحمولة بالمسار عبر AAD، قد تُقبل حمولة مشفّرة وصحيحة لكن في سياق غير مقصود.
آلية العمل
يشفّر SDK الطلب
يشفّر SDK في تطبيقك حمولة الطلب باستخدام AES-256-GCM، ويربط AAD بطريقة الطلب والمسار والمستأجر.
تتحقق البوابة من AAD والحداثة وإعادة الإرسال
تراجع البوابة حداثة الطابع الزمني، وتتأكد من تطابق AAD مع المسار، وترفض أي طلب مكرر.
تمرر البوابة الطلب إلى الوجهة المسموحة
لا يصل الطلب بعد فك تشفيره إلا إلى عناوين URL المعتمدة مسبقًا.
تشفّر البوابة الاستجابة قبل إرجاعها
تُشفّر استجابة الخدمة باستخدام AAD مخصص للاستجابة قبل أن تعود إلى SDK.
يفك CRelay التشفير داخل حدود البوابة الموثوقة فقط لتطبيق فحوصات الأمان، ثم يمرر الطلب إلى الوجهة التي سمحت بها.
ميزات الأمان
تشفير مصدّق بمفاتيح 32 بايت، وnonce بحجم 12 بايت، وعلامات مصادقة 16 بايت. نمط تشفير معتمد وشائع في الأنظمة الحساسة.
كل طلب يحمل nonce فريدًا. ترفض البوابة أي nonce سبق استخدامه داخل نافذة الحداثة.
يجب أن تصل الطلبات ضمن نافذة زمنية قابلة للضبط، والافتراضي 5 دقائق. تُرفض الطلبات القديمة تلقائيًا.
تربط بيانات المصادقة الإضافية كل عملية تشفير بطريقة الطلب والمسار والمستأجر. هذا يمنع خلط المسارات.
لا تُمرر الطلبات إلا إلى عناوين URL المعتمدة مسبقًا. هذا يقلل مخاطر SSRF والتوجيه غير المصرح به.
تُشفّر الاستجابات قبل إرجاعها إلى SDK، باستخدام AAD مخصص للاستجابة (RESPONSE:/path:tenantId).
تحقق صفري الثقة على مستوى الحمولة
CRelay لا يفترض أن الطلب آمن لمجرد أنه وصل عبر HTTPS.
كل طلب محمي يجب أن يثبت أنه مشفّر بالمفتاح الصحيح، حديث، غير مكرر، مربوط بالمسار المقصود، ومتجه فقط إلى API مسموح.
يقوم CRelay بفك التشفير داخل حدود البوابة الموثوقة لتطبيق هذه الفحوصات، تمرير الطلب، ثم تشفير الاستجابة وإعادتها للعميل.
تتم حماية بيانات الطلب والاستجابة باستخدام AES-256-GCM.
يتم رفض requestId أو nonce المكرر.
يتم رفض الطلبات القديمة أو المؤرخة في المستقبل.
يتم ربط الحمولة بالـ method والمسار والـ tenant المقصود.
لا يتم تمرير الطلب إلا إلى upstream origin مسموح.
يسجل CRelay بيانات تشغيلية فقط، وليس محتوى الطلبات أو الاستجابات.
أسئلة حول تسجيل الحمولة
هل يسجل CRelay بيانات الطلب؟
لا. CRelay لا يسجل عمدًا محتوى الطلبات أو الاستجابات بصيغتها النصية.
يسجل CRelay بيانات تشغيلية ضرورية للتشخيص والاعتمادية، مثل request ID، tenant ID، key ID، method، path، حالة الاستجابة من الـ upstream، رمز الخطأ، ومدة التنفيذ.
لا يتم تسجيل مفاتيح API الخام، أو مفاتيح التشفير، أو محتوى الطلبات، أو محتوى الاستجابات.
هل CRelay نظام zero-knowledge؟
لا. CRelay في الإصدار v0.1 ليس نظام zero-knowledge.
تقوم البوابة بفك التشفير داخل حدود موثوقة حتى تتمكن من تطبيق حماية إعادة الإرسال، التحقق من حداثة الطلب، ربط الحمولة بالمسار، السماح بالوجهات المحددة، وتشفير الاستجابة.
مصمم للمطورين
SDK مفتوح. بروتوكول موثّق. حماية مُدارة.
يبقي CRelay الأجزاء الموجهة للمطورين واضحة وقابلة للمراجعة: SDK، والبروتوكول، ونموذج التهديد، ودليل البدء السريع. وتوفر البوابة المستضافة طبقة الحماية المُدارة لإيقاف إعادة الإرسال، والتحقق من الحداثة، وربط AAD بالمسار، وتحديد الوجهات المسموحة، وتشفير الاستجابات.
اطلع على تنسيق الظرف، وقواعد AAD، ونموذج الحداثة، وافتراضات التهديد.
شفافية كافية للمراجعة. وإدارة كافية للاستخدام العملي.
خارطة الطريق
قدرات مخطط لها للفرق التي تحمي حمولات API الحساسة.
خيارات لإدارة المفاتيح للمؤسسات التي تحتاج تحكمًا أكبر في حفظ المفاتيح وسير عمل تدويرها.
هوية workload، سياسات على مستوى المسار، قرارات سياسة، بيانات حالة المفاتيح، وسجلات تدقيق لقرارات التحقق.
حماية الـ prompts الحساسة، بيانات tool-calling، سياق RAG، واستجابات الذكاء الاصطناعي عند تمريرها عبر AI proxy أو backend مملوك للعميل.
سيساعد CRelay الفرق على تشفير طلبات واستجابات AI، التحقق من حداثة الطلب، منع إعادة الإرسال، ربط الطلب بالمسار المقصود، والسماح فقط بالتمرير إلى نقاط AI proxy المعتمدة.
CRelay لا يجعل مزودي الذكاء الاصطناعي الخارجيين zero-knowledge. إذا قام backend بإرسال prompt بصيغته النصية إلى مزود AI خارجي، فالمزود سيستقبل هذا المحتوى. دور CRelay هو حماية الحمولة داخل حدود تطبيقك وطبقة التحقق قبل تمرير الطلب.
أنماط حماية لحمولات GraphQL مع الحفاظ على نموذج CRelay لإيقاف إعادة الإرسال، التحقق من الحداثة، وربط الطلب بالسياق.
استكشاف تحقق مشفر للرسائل في الاتصالات طويلة العمر من دون إضعاف نموذج HTTP API.
أنماط تشغيلية لتوزيع بيانات المفاتيح عبر بيئات سحابية متعددة.
واجهة مستقبلية لمراجعة وضع التحقق، البيانات التشغيلية، وأحداث الأمان.