Zero Trust
مبدأ انعدام الثقة Zero Trust
لا تثق بأي طلب افتراضيًا — سواء أتى من خارج الشبكة أو من داخلها، بل تحقق من هويته وصلاحيته في كل مرة.
النموذج القديم (Perimeter Security) يفترض أن كل ما هو 'داخل' الشبكة (خلف جدار الحماية) موثوق تلقائيًا. Zero Trust يقلب هذا الافتراض: كل طلب — حتى لو جاء من خدمة أخرى داخل نفس البنية التحتية — يجب أن يثبت هويته (Authentication) وصلاحيته (Authorization) بشكل مستقل، دون افتراض ثقة بناءً على الموقع الشبكي فقط.
يظهر عمليًا في أمن المايكروسيرفيس عبر mTLS بين كل خدمتين، وفي أمن الوصول عبر التحقق من الصلاحية على كل طلب API بدل الاعتماد على شبكة داخلية 'آمنة'.
الصياغة
تحقق دائمًا (Verify explicitly) + أقل صلاحية (Least privilege) + افترض الاختراق (Assume breach)
📄 مثال
// بدل الثقة بأي طلب من الشبكة الداخلية
app.get('/internal/api/data', (req, res) => {
res.json(sensitiveData); // ثقة عمياء لأنه 'داخلي'
});
// Zero Trust: تحقق من هوية الخدمة المستدعية أيضًا (mTLS أو service token)
app.get('/internal/api/data', verifyServiceIdentity, (req, res) => {
if (!req.service.permissions.includes('read:data')) {
return res.status(403).json({ error: 'ممنوع' });
}
res.json(sensitiveData);
});أهم النقاط
| النقطة | الوظيفة |
|---|---|
| تحقق دائمًا | لا استثناء للطلبات 'الداخلية' — تحقق من الهوية والصلاحية في كل مرة |
| أقل صلاحية | كل خدمة أو مستخدم يحصل فقط على الصلاحية اللازمة لعمله، لا أكثر |
| افترض الاختراق | صمّم كأن جزءًا من الشبكة قد يكون مخترقًا بالفعل |
💡 نصائح عملية
- ابدأ تطبيقه تدريجيًا على أكثر المسارات حساسية (بيانات مالية، صلاحيات إدارية) بدل محاولة تطبيقه على كل شيء دفعة واحدة
⚠️ أخطاء شائعة
- الخلط بينه وبين منتج أمني معيّن تشتريه — هو نموذج تصميم وثقافة هندسية، لا أداة واحدة
خصائص ذات صلة
🎓 تريد فهم الصورة الكاملة خطوة بخطوة؟ ابدأ من مسار API-SECURITY الكامل بالعربي.