كيف تستورد إرسالات النماذج العامة إلى شبكة خاصة

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

ابدأ من حيث يحط الإرسال

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

ثم يسحب عامل خاص الصفوف المعلّقة عبر النفق ويقرر ما يفعل بكل واحد منها. وهو يعمل بهوية خاصة به، وهي موضوع القسم التالي.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

امنح المستورد السلطة التي يحتاجها فقط

ينبغي أن تكون عملية الويب العامة والهوية التي تكتب في التطبيق الداخلي جهتين أصليتين مختلفتين. فخادم عام لا يحتاج إلى إدارة داخلية لمجرد أنه يجب عليه تسليم بيانات نموذج، وحساب واحد مشترك للجانبين يحوّل أي خلل في الويب إلى كتابة داخلية. امنح العامل بيانات اعتماد خاصة به، وقصّر نطاقها على عملية الاستيراد الواحدة، وسجّل أي جهة أصلية نفّذت كل استيراد. ذلك الفصل هو ما يجعل حدود النفق ذات معنى بدلاً من أن تكون زخرفة.

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

والدالة قصيرة العمر ليست معفاة من المراجعة نفسها. فطالما أنها تعمل، فإن موضعها في الشبكة وبيانات اعتمادها يمنحانها سلطة، والعمر الأقصر لا يضيّق سوى النافذة. والعمر ليس بديلاً عن تحديد العمليات التي يجوز للهوية تنفيذها.

تحقّق قبل أن يتغير أي شيء داخلي

تبقى حقول النماذج العامة نصاً يتحكم فيه المهاجم حتى يثبت العكس، وإرشادات التحقق من المدخلات لدى OWASP تعدّ تدفقات الخلفية مصادر غير موثوقة لهذا السبب بالتحديد. النقل المشفّر يقول إن البايتات وصلت سليمة، وليس إنها تصف طلباً مسموحاً به. حلّل وتحقّق قبل أي خطوة ذات امتياز، حتى لا يصل صف سيئ أبداً إلى مسار شفرة قادر على التصرف.

حدّد الحقول المسموح بها وصيغها وأحجامها وقواعد العمل التي يجب أن تنطبق. فالتاريخ يمكن أن يكون صحيح الشكل ومع ذلك خاطئاً للعملية المطلوبة، والحمولة التي تسمّي حساباً داخلياً أو حالة موافقة يجب ألا تكون قادرة على منح نفسها أياً منهما.

أرسل الصفوف المرفوضة إلى نتيجة مراجعة بدلاً من تخمين تصحيح أو تحويلها إلى صدفة أو واجهة قاعدة بيانات خام. سجّل معرّف السجل والقاعدة التي فشلت، لا كل حقل كتبه مقدّم الطلب.

اجعل نقطة إعادة المحاولة عند عملية واحدة

إذا سُحب السجل submission-1042 مرتين لأن الإشعار الأول ضاع، فإن العامل يحتاج إلى طريقة دائمة للتعرف على سجل المصدر ونتيجته المثبّتة. والجدول الذي يشغّل المهمة مرة واحدة لا يثبت أن كل صف قد طُبّق مرة واحدة. التسليم المكرر أمر طبيعي، لذلك يجب أن يستوعبه التصميم.

استخدم آلية المعاملات ومعالجة التكرار الخاصة بالتطبيق الداخلي، واحتفظ بمعرّف المصدر والنتيجة والإشعار في تسلسل واحد متماسك. لا تُشعر إلا بعد تثبيت العملية المقصودة أو إسنادها بشكل دائم، ولا تحذف صف الاستقبال لمجرد أن البايتات قد نُزّلت.

ثم أثبت ذلك بثلاث حالات: صف صالح، وصف سيئ التكوين، ومعرّف المصدر المضبوط نفسه يُسلَّم مرتين. تمر كل حالة عبر نقطة الوصول نفسها التي يستخدمها العامل.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

يجب أن ينتهي الصفان الأولان في حالتين داخليتين مختلفتين، ويجب أن يعيد الثالث المعرّف المثبّت مسبقاً لسجل المصدر ذلك بدلاً من إنشاء معرّف ثانٍ. وأي شيء آخر يعني أن الاستيراد ليس قابلاً للتكرار بعد.