---
title: "ما هي الهوية غير البشرية NHI؟ ولماذا أصبحت تحديًا جديدًا للأمن الإلكتروني؟"
description: "عند� ا نتحدث عن الهوية الرق� ية داخل � ؤسسة، نفكر عادةً في شخص لديه اس� � ستخد� وكل� ة � رور ورب� ا � صادقة � تعددة العوا� ل. لكن البشر ل� يعودوا الوحيدين الذين يسجلون الدخول إلى الأنظ�..."
url: https://awalbyte.com/%d8%a7%d9%84%d9%87%d9%88%d9%8a%d8%a9-%d8%ba%d9%8a%d8%b1-%d8%a7%d9%84%d8%a8%d8%b4%d8%b1%d9%8a%d8%a9/
date: 2026-09-30
modified: 2026-09-29
author: "فريق تحرير أول بايت"
image: https://awalbyte.com/wp-content/uploads/2026/09/ما-هي-Passkeys؟-وهل-ستنهي-عصر-كلمات-المرور؟-3.webp
categories: ["الأمن الإلكتروني"]
type: post
lang: ar
---

# ما هي الهوية غير البشرية NHI؟ ولماذا أصبحت تحديًا جديدًا للأمن الإلكتروني؟

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

لكن البشر لم يعودوا الوحيدين الذين يسجلون الدخول إلى الأنظمة.

تطبيق يتصل بقاعدة بيانات، وخدمة سحابية تتواصل مع خدمة أخرى، وسكربت ينفذ مهمة آلية، وخط CI/CD ينشر إصدارًا جديدًا، ووكيل ذكاء اصطناعي يستخدم API لتنفيذ مهمة؛ جميعها قد تحتاج إلى إثبات هويتها والحصول على صلاحيات للوصول إلى موارد رقمية.

هذه الهويات تعرف على نطاق واسع باسم **Non-Human Identities أو NHI — الهويات غير البشرية**.

ومع توسع الحوسبة السحابية والأتمتة والواجهات البرمجية والذكاء الاصطناعي الوكيل، ازداد عدد هذه الهويات وتعقيد إدارتها.

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

فما المقصود بالهوية غير البشرية؟ وكيف تختلف عن حساب المستخدم؟ وما علاقة API Keys وService Accounts بها؟

## **ما هي الهوية غير البشرية NHI؟**

**الهوية غير البشرية Non-Human Identity** هي هوية رقمية تستخدمها آلة أو تطبيق أو خدمة أو عملية برمجية للوصول إلى نظام أو مورد رقمي بدلًا من استخدامها مباشرة بواسطة شخص.

قد تمثل هذه الهوية:

- تطبيقًا.
- خدمة سحابية.
- خادمًا.
- حاوية Container.
- سكربتًا.
- عملية آلية.
- حساب خدمة.
- جهازًا.
- روبوتًا برمجيًا.
- وكيل ذكاء اصطناعي.

وتحتاج هذه الكيانات إلى هوية للسبب نفسه الذي يحتاج إليه الإنسان: يجب أن يعرف النظام **من يحاول الوصول، وما الذي يسمح له بفعله**.

لكن طريقة إثبات الهوية مختلفة.

الموظف قد يستخدم كلمة مرور وPasskey وبصمة.

أما التطبيق فقد يستخدم مفتاح API أو شهادة رقمية أو Token أو Secret أو بيانات اعتماد أخرى.

وهنا تبدأ المشكلة الأمنية.

## **ما أمثلة الهويات غير البشرية؟**

قد توجد آلاف NHIs داخل بنية تقنية واحدة دون أن يراها المستخدم العادي.

### **حسابات الخدمات Service Accounts**

هي حسابات مخصصة للتطبيقات والخدمات بدل الموظفين.

قد يحتاج تطبيق مثلًا إلى قراءة بيانات من قاعدة بيانات كل ساعة، ولذلك يمنح Service Account يستطيع استخدامه لتنفيذ المهمة.

### **API Keys**

عندما يريد تطبيق استخدام خدمة عبر API، قد يحصل على مفتاح يثبت أنه مخول بالوصول إليها.

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

### **Access Tokens**

التوكنات بيانات اعتماد مؤقتة أو محددة النطاق تستخدم للسماح بالوصول إلى مورد أو API.

تظهر في عدد كبير من أنظمة المصادقة الحديثة.

### **الشهادات الرقمية**

يمكن للأجهزة والخدمات استخدام الشهادات لإثبات هويتها وإنشاء اتصالات موثوقة.

### **Workload Identities**

في البنى السحابية الحديثة يمكن منح Workload مثل تطبيق أو Container أو وظيفة Serverless هوية خاصة به بدل تخزين كلمة مرور ثابتة داخله.

كل هذه أمثلة مختلفة لفكرة واحدة:

**هناك كيان برمجي يحتاج إلى إثبات هويته قبل أن يسمح له النظام بالعمل.**

## **لماذا تحتاج الآلات إلى هوية أصلًا؟**

لنفترض أن متجرًا إلكترونيًا يحتوي على خدمة للدفع وخدمة للمخزون وخدمة للطلبات.

عندما ترسل خدمة الطلبات طلبًا إلى نظام المخزون، يجب أن يعرف نظام المخزون أن الطلب صادر فعلًا عن خدمة موثوقة.

وإلا فقد يستطيع أي برنامج على الشبكة إرسال أوامر إليه.

الهوية تسمح بتطبيق ثلاث وظائف مهمة:

**Authentication — المصادقة:**من أنت؟

**Authorization — التفويض:**ما الذي يسمح لك بفعله؟

**Auditing — التدقيق:**ما الذي فعلته؟

هذه المبادئ لا تختلف كثيرًا بين البشر والآلات.

لكن إدارة هوية الآلة قد تكون أصعب بسبب العدد الهائل من الخدمات والعمليات التي تعمل بصورة مستمرة.

## **ما الفرق بين هوية المستخدم والهوية غير البشرية؟**

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

| **الهوية البشرية** | **الهوية غير البشرية** |
| --- | --- |
| تمثل شخصًا | تمثل آلة أو تطبيقًا أو خدمة |
| قد تستخدم Passkey أو كلمة مرور | قد تستخدم Token أو Secret أو شهادة |
| تسجيل الدخول يحدث عند الحاجة | قد تعمل طوال الوقت |
| يمكن مطالبة الشخص بالمصادقة | لا يوجد إنسان ليكتب رمز تحقق |
| ترتبط غالبًا بوظيفة الموظف | ترتبط بوظيفة التطبيق أو Workload |
| يمكن ملاحظة نشاط المستخدم | قد تنفذ آلاف الطلبات آليًا |

وهذا يجعل بعض وسائل الحماية المخصصة للبشر غير مناسبة للآلات.

لا يمكن مثلًا إرسال رمز تحقق إلى هاتف Microservice في كل مرة تريد فيها الوصول إلى قاعدة البيانات.

نحتاج بدل ذلك إلى أنظمة مصادقة وإدارة صلاحيات مصممة للعمليات الآلية.

## **ما علاقة API Keys بالهوية غير البشرية؟**

API Key هو أحد أبسط الأمثلة.

لنفترض أن تطبيقًا يحتاج إلى استخدام خدمة خارجية.

تمنح الخدمة المطور مفتاحًا مثل سلسلة طويلة من الأحرف، ويرسله التطبيق مع الطلبات.

تستخدم الخدمة المفتاح لمعرفة الجهة المخولة باستخدام API.

لكن المشكلة تبدأ عندما يُعامل المفتاح مثل نص عادي.

قد يضعه مطور داخل الكود:

API_KEY = “…”

ثم يرفع المشروع إلى مستودع عام بالخطأ.

أو قد يظهر المفتاح في Log.

أو يتم نسخه إلى عدة خوادم وينسى الفريق أماكن وجود النسخ.

عندها يتحول المفتاح إلى Secret يصعب التحكم فيه.

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

## **ما المقصود بـSecrets؟**

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

مثل:

- API Keys.
- Tokens.
- كلمات مرور قواعد البيانات.
- مفاتيح التشفير.
- Client Secrets.
- مفاتيح SSH.

يمكن اعتبار الهوية والـSecret شيئين مرتبطين لكنهما ليسا الشيء نفسه.

**الهوية:** من هو التطبيق أو الخدمة؟

**Secret:** إحدى الوسائل التي قد يستخدمها لإثبات تلك الهوية.

ولهذا يعرف مجال كامل باسم **Secrets Management** يهتم بتخزين بيانات الاعتماد وتوزيعها وتدويرها وإلغائها بصورة آمنة.

## **لماذا أصبحت NHI مشكلة أمنية كبيرة؟**

السبب الأول هو الحجم.

قد تحتوي بيئة سحابية حديثة على عدد ضخم من التطبيقات والحاويات والعمليات الآلية والخدمات.

وكلما ازداد عددها، ازدادت الهويات التي يجب إدارتها.

المشكلة الثانية هي السرعة.

يمكن إنشاء Workload جديد خلال دقائق، ثم حذفه وإنشاء آخر.

المشكلة الثالثة هي الصلاحيات.

بعض الهويات تحصل على صلاحيات أوسع مما تحتاج إليه لأن ذلك يجعل التطوير أسهل.

ثم تبقى الصلاحيات لسنوات.

والمشكلة الرابعة هي أن بعض بيانات الاعتماد طويلة العمر.

قد يتم إنشاء API Key ثم استخدامه لأشهر أو سنوات دون تغييره.

إذا تسرب المفتاح ولم ينتبه الفريق، يصبح لدى المهاجم وقت طويل لاستغلاله.

ولهذا أصبحت NHIs جزءًا متزايد الأهمية من مفهوم **Identity Security**.

## **كيف تتم سرقة هوية غير بشرية؟**

ليس المطلوب دائمًا “اختراق” التطبيق نفسه.

أحيانًا يكفي العثور على بيانات اعتماده.

### **مستودعات الكود**

يمكن أن يرفع مطور Secret إلى Git repository بالخطأ.

وحتى إذا حذف الملف لاحقًا، قد يبقى المفتاح موجودًا في سجل Git.

### **ملفات الإعداد**

قد تحتوي ملفات Environment أو Configuration على مفاتيح حساسة.

إذا تمكن المهاجم من قراءتها، يحصل على بيانات الاعتماد.

### **سجلات Logs**

قد تظهر Tokens أو مفاتيح داخل سجلات التطبيق نتيجة خطأ في البرمجة.

### **أجهزة المطورين**

إذا تمت سرقة بيانات اعتماد مخزنة محليًا، قد يستطيع المهاجم استخدامها للوصول إلى خدمات المؤسسة.

### **ثغرات التطبيقات**

يمكن لثغرة أن تسمح بقراءة متغيرات البيئة أو ملفات إعداد تحتوي على Secrets.

### **سلسلة التوريد البرمجية**

إذا تم اختراق أداة أو مكون لديه وصول إلى بيانات اعتماد حساسة، يمكن أن ينتقل الهجوم عبر سلسلة التوريد.

## **لماذا تكون صلاحيات NHI خطيرة؟**

وجود المفتاح وحده لا يحدد حجم المشكلة.

السؤال الأهم:

**ماذا يستطيع صاحب هذه الهوية أن يفعل؟**

تخيل Service Account يحتاج فقط إلى قراءة ملف واحد.

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

هنا يظهر مبدأ **Least Privilege — أقل قدر من الصلاحيات**.

كل هوية يجب أن تحصل فقط على الصلاحيات الضرورية لتنفيذ وظيفتها.

لا أكثر.

إذا كانت الخدمة تحتاج إلى القراءة فقط، فلا يجب أن تستطيع الحذف.

وإذا كانت تحتاج إلى قاعدة بيانات واحدة، فلا ينبغي أن تحصل تلقائيًا على جميع قواعد البيانات.

هذه الفكرة بسيطة نظريًا، لكنها تصبح معقدة جدًا عندما توجد آلاف الهويات والخدمات.

## **ما هي الهوية غير البشرية اليتيمة؟**

تظهر مشكلة أخرى عندما يتوقف النظام الذي أنشئت الهوية من أجله، لكن بيانات الاعتماد تبقى فعالة.

مثلًا:

ينشئ فريق مشروعًا تجريبيًا.

يتم إنشاء Service Account ومفتاح API.

بعد ستة أشهر يتم إلغاء المشروع.

لكن لا أحد يلغي المفتاح.

أصبحت لدينا هوية لم تعد هناك حاجة إليها لكنها ما تزال قادرة على الوصول إلى النظام.

يمكن تسمية هذه الحالات **Orphaned Identities أو الهويات اليتيمة**.

كلما طالت حياة البنية التقنية، يمكن أن تتراكم هذه الحسابات والمفاتيح المنسية.

ولهذا فإن اكتشاف الهوية وإنشاءها ليسا كافيين؛ يجب إدارة **دورة حياتها كاملة**.

## **ما دورة حياة الهوية غير البشرية؟**

يمكن النظر إلى إدارة NHI على أنها سلسلة مراحل:

**إنشاء → منح صلاحيات → استخدام → مراقبة → تدوير بيانات الاعتماد → تعديل الصلاحيات → إلغاء الهوية.**

المشكلة أن المؤسسات تنجح غالبًا في الخطوات الأولى وتفشل في الأخيرة.

إنشاء API Key سهل.

لكن:

من المسؤول عنه؟

أين يستخدم؟

متى استخدم آخر مرة؟

ما الصلاحيات التي يملكها؟

هل ما يزال التطبيق موجودًا؟

متى يجب تغيير المفتاح؟

هذه الأسئلة تصبح ضرورية عندما يصل العدد إلى آلاف الهويات.

## **ما هو تدوير Secrets؟**

**Secret Rotation** يعني استبدال بيانات الاعتماد القديمة بأخرى جديدة بصورة دورية أو عند الحاجة.

الفكرة هي تقليل المدة التي يمكن خلالها استغلال Secret مسروق.

إذا بقي المفتاح نفسه صالحًا خمس سنوات، فإن تسرب نسخة قديمة منه يظل خطرًا.

أما إذا تم تغييره بانتظام، تنتهي صلاحية النسخ القديمة.

لكن التدوير اليدوي صعب في الأنظمة الكبيرة.

يجب تحديث التطبيق والمخزن والخدمات المرتبطة دون التسبب في توقف النظام.

ولهذا تحاول المنصات الحديثة أتمتة العملية أو الانتقال إلى بيانات اعتماد قصيرة العمر.

## **لماذا تكون بيانات الاعتماد قصيرة العمر أفضل؟**

بدل إنشاء مفتاح يعمل سنة كاملة، يمكن للنظام إصدار Token يعمل ساعة واحدة.

بعدها يصبح عديم الفائدة.

هذا لا يمنع سرقته، لكنه يقلل نافذة الاستغلال.

ويمكن إصدار Token جديد تلقائيًا عندما تحتاج الخدمة إليه.

هذه الفكرة جزء من الاتجاه نحو تقليل الاعتماد على **Long-Lived Credentials**.

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

## **ما علاقة Zero Trust بالهويات غير البشرية؟**

مفهوم **Zero Trust** يقوم على عدم اعتبار الكيان موثوقًا فقط لأنه موجود داخل شبكة المؤسسة.

يجب التحقق من الهوية والصلاحيات والسياق.

وينطبق هذا على الآلات أيضًا.

وجود خدمة داخل الشبكة الداخلية لا يعني أنها يجب أن تستطيع الوصول إلى كل شيء.

يجب أن يكون لكل Workload هوية واضحة، وأن يتم التحقق منها قبل الوصول إلى الموارد.

بهذا المعنى، إدارة NHI جزء أساسي من تطبيق Zero Trust على البنية الحديثة.

## **ما علاقة الذكاء الاصطناعي بـNHI؟**

هنا يصبح الموضوع أكثر أهمية.

وكلاء الذكاء الاصطناعي لا يكتفون بإنشاء النصوص.

بعض الأنظمة تستطيع:

- قراءة ملفات.
- استخدام APIs.
- البحث في قواعد بيانات.
- إرسال رسائل.
- تشغيل أدوات.
- التعامل مع أنظمة أعمال.

لكي ينفذ AI Agent هذه المهام، يحتاج إلى صلاحيات.

وهنا يظهر سؤال أمني جديد:

**بأي هوية يعمل الوكيل؟**

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

لذلك يجب التعامل مع وكيل AI باعتباره كيانًا يحتاج إلى هوية وصلاحيات محددة، وليس مجرد واجهة محادثة.

## **ماذا يحدث إذا حصل AI Agent على صلاحيات واسعة؟**

لنفترض أن وكيلًا يستطيع الوصول إلى البريد والملفات وقاعدة بيانات العملاء.

قد تكون قدرته مفيدة جدًا.

لكن سطح المخاطر أصبح أكبر أيضًا.

إذا تمكن محتوى خبيث من التأثير في سلوك الوكيل، فقد يحاول استخدام الأدوات الممنوحة له بطريقة غير متوقعة.

لهذا لا يكفي تأمين النموذج نفسه.

يجب أيضًا التحكم في:

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

وهنا تلتقي **AI Security** مع **Identity Security**.

## **هل Machine Identity هي نفسها NHI؟**

المصطلحان متقاربان جدًا ويستخدمان أحيانًا للإشارة إلى نطاقات متداخلة.

**Machine Identity** كان يستخدم تقليديًا عند الحديث عن هوية الأجهزة والخوادم والتطبيقات والشهادات.

أما **Non-Human Identity** فهو مصطلح أوسع يستخدم بكثرة اليوم ليشمل Workloads وService Accounts وBots والعمليات الآلية وكيانات أخرى ليست مستخدمين بشريين.

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

الأهم أمنيًا ليس الاسم، بل معرفة جميع الكيانات غير البشرية التي تستطيع الوصول إلى موارد المؤسسة.

## **كيف تحمي المؤسسات الهويات غير البشرية؟**

لا توجد أداة واحدة تحل المشكلة كاملة.

الحماية تبدأ بمعرفة ما هو موجود أصلًا.

### **اكتشاف جميع الهويات**

لا يمكن حماية NHI لا تعرف المؤسسة بوجودها.

يجب إنشاء Inventory يشمل Service Accounts والمفاتيح والشهادات وTokens والـWorkloads وغيرها.

### **تطبيق أقل الصلاحيات**

كل هوية تحصل على ما تحتاج إليه فقط.

### **تجنب Secrets داخل الكود**

يجب ألا تخزن API Keys وكلمات المرور مباشرة داخل Source Code.

تستخدم بدلًا من ذلك أنظمة Secrets Management أو آليات الهوية الأصلية في المنصات السحابية.

### **استخدام بيانات اعتماد قصيرة العمر**

عندما يكون ذلك ممكنًا، تكون Credentials المؤقتة أفضل من مفاتيح ثابتة تعمل لسنوات.

### **تدوير المفاتيح**

إذا كان استخدام Secrets الثابتة ضروريًا، يجب تغييرها وإلغاء القديمة.

### **مراقبة الاستخدام**

إذا كانت هوية تستخدم عادةً API واحدًا ثم بدأت فجأة بتحميل كميات ضخمة من البيانات، فهذا يستحق التحقيق.

### **حذف الهويات غير المستخدمة**

الهوية التي لم تعد لها وظيفة يجب إلغاؤها، لا تركها تعمل “احتياطًا”.

## **كيف تعرف أن NHI تعرضت للاختراق؟**

قد تكون مراقبة الآلات أصعب من مراقبة البشر لأن نشاطها آلي وسريع.

لكن يمكن البحث عن سلوكيات غير معتادة مثل:

- الوصول من موقع أو بيئة جديدة.
- استخدام API لم تستخدمه الهوية سابقًا.
- زيادة مفاجئة في حجم الطلبات.
- الوصول إلى بيانات خارج نطاق الوظيفة.
- محاولات تصعيد الصلاحيات.
- استخدام بيانات اعتماد في وقت غير متوقع.
- ظهور Secret في مستودع أو سجل.

لكن اكتشاف السلوك الشاذ يحتاج إلى معرفة **السلوك الطبيعي للهوية أولًا**.

وهذا أحد أسباب أهمية وجود Inventory وسياق لكل NHI.

## **هل يمكن التخلص من API Keys نهائيًا؟**

ليس بسهولة، ولا في جميع الأنظمة.

API Keys بسيطة ومدعومة على نطاق واسع، ولذلك ستستمر في الاستخدام.

لكن الاتجاه الأمني الأفضل عندما تسمح البنية بذلك هو تقليل الاعتماد على المفاتيح الثابتة طويلة العمر واستخدام آليات توفر هويات مباشرة للـWorkloads وبيانات اعتماد قصيرة العمر.

بهذه الطريقة لا يحتاج التطبيق إلى الاحتفاظ بسر دائم يمكن نسخه وسرقته.

الفكرة ليست أن API Keys “سيئة” دائمًا، بل أن **Secret ثابتًا وواسع الصلاحيات وطويل العمر** يمثل خطرًا أكبر من هوية محدودة تستخدم Credential مؤقتًا.

## **لماذا ستزداد أهمية NHI؟**

السبب ليس مجرد نمو عدد الخوادم.

البنية التقنية نفسها تتحول نحو مزيد من الأتمتة.

لدينا اليوم:

- Microservices.
- Containers.
- Kubernetes.
- Serverless.
- Cloud APIs.
- CI/CD.
- Infrastructure as Code.
- Bots.
- AI Agents.

كل هذه الأنظمة تجعل البرمجيات تتحدث مع البرمجيات بصورة مستمرة.

وبالتالي قد تصبح نسبة متزايدة من عمليات المصادقة داخل المؤسسات ناتجة عن آلات لا أشخاص.

وهذا يغير السؤال الأمني التقليدي.

لم يعد كافيًا أن نسأل:

**من الموظفون الذين يستطيعون الوصول إلى النظام؟**

بل يجب أن نسأل أيضًا:

**ما التطبيقات والخدمات والوكلاء والعمليات التي تستطيع الوصول إليه، وبأي صلاحيات، وبأي بيانات اعتماد؟**

## **هل الهوية غير البشرية هي الجبهة الجديدة لأمن الهوية؟**

يمكن النظر إليها باعتبارها امتدادًا طبيعيًا لمشكلة قديمة أصبحت أكبر بكثير.

الأنظمة احتاجت دائمًا إلى حسابات خدمات ومفاتيح وشهادات.

الجديد هو الحجم والسرعة والتعقيد.

السحابة جعلت إنشاء الموارد أسرع.

Microservices ضاعفت عدد العلاقات بين التطبيقات.

الأتمتة جعلت البرمجيات تنفذ المزيد من العمليات دون تدخل بشري.

والذكاء الاصطناعي الوكيل يضيف الآن نوعًا جديدًا من البرمجيات القادرة على اختيار الأدوات والإجراءات أثناء تنفيذ المهمة.

كل ذلك يجعل **الهوية** نقطة مركزية في الأمن الإلكتروني.

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

ولهذا فإن السؤال المهم في البنية الحديثة ليس فقط:

**هل هذا المستخدم مخول بالدخول؟**

بل أيضًا:

**من هي هذه الآلة؟ لماذا تحتاج إلى الوصول؟ ما الذي تستطيع فعله؟ ومتى يجب أن تنتهي صلاحيتها؟**