الفصل : 6
الجزء : 1
العنوان : ال Certificates
"يا إلهي، نحتاج إلى استخدام الشهادات لجعل هذا يعمل."
اقتباس حقيقي من أي مسؤول بعد اكتشاف أن أحدث برنامج تم شراؤه يتطلب استخدام الشهادات.
إذا كان هذا الاقتباس، أو ربما نسخة أكثر تعبيرًا منه، مألوفًا لك، فلا تتخلى عن المشروع الجديد بعد! لسبب ما، يبدو أن استخدام الشهادات مهمة شاقة بالنسبة للكثير منا، حتى لأولئك الذين عملوا في مجال تكنولوجيا المعلومات لسنوات عديدة. أعتقد أن هذا ربما بسبب وجود العديد من الخيارات المختلفة المتاحة على خادم الشهادات، ولكن ليس هناك الكثير من المنطق الشائع أو سهولة الاستخدام في وحدة التحكم الإدارية للتعامل مع الشهادات. هذا، بالإضافة إلى نقص المتطلبات العامة للشهادات على الخوادم لسنوات عديدة، يعني أنه حتى مع أن هذه التقنية موجودة منذ فترة طويلة، لم تتح الفرصة للعديد من مديري الخوادم للتعمق فيها ونشر الشهادات بأنفسهم. بانتظام أقوم بنشر بعض التقنيات التي تتطلب استخدامًا واسعًا للشهادات في مؤسسة، وغالبًا ما أحتاج إلى إصدارها لكل محطة عمل أو مستخدم في الشبكة، وأسمع هذه المخاوف طوال الوقت. إصدار شهادة لخادم ويب حيوي تجاري واحد يبدو مهمة شاقة بما فيه الكفاية إذا لم يكن لديك أي خبرة في العملية، فما بالك بإصدار مئات أو آلاف الشهادات عبر الشركة.
سيناريو آخر شائع هو أن تقرر شركة أن الشهادات في مصلحتها الفضلى لكنها تفتقر إلى الموارد البشرية لتطبيقها بنفسها، وبالتالي تقوم بتوظيف طرف ثالث لتنفيذ الشهادات داخل الشبكة. بينما يبدأ هذا في تشغيل الشهادات، فإنه غالبًا ما يترك فجوة معرفية لا تُملأ أبدًا، لذلك قد يكون لديك خادم شهادات قيد التشغيل ولكنك لست مرتاحًا تمامًا مع تعديله أو استخدامه.
المصطلح العام لبيئة الشهادات هو البنية التحتية للمفتاح العامpublic key infrastructure (PKI). أذكر هذا تحديدًا لأنك ربما ستراه مدرجًا في الوثائق أو المتطلبات في وقت ما إذا لم تكن قد رأيته بالفعل. يتم توفير البنية التحتية للمفتاح العام (PKI) من قبل الخوادم في شبكتك، والغرض من هذا الفصل هو مساعدتك في فهم كيفية تكوين تلك الخوادم لإصدار الشهادات.
الخوادم التي تحددها لتكون خوادم الشهادات تُعرف بخوادم سلطة الشهادات certification authority (CA) وسنشير إليها كخوادم CA طوال هذا الكتاب.
للبدء في استخدام الشهادات في شبكتك، إليك المواضيع التي سنغطيها في هذا الفصل:
أنواع الشهادات الشائعة
تخطيط بنية PKI الخاصة بك
إنشاء قالب شهادة جديد
إصدار الشهادات الجديدة
إنشاء سياسة التوزيع التلقائي
الحصول على شهادة SSL من سلطة عامة
تصدير واستيراد الشهادات
الOpenSSL لخوادم Linux
أنواع الشهادات الشائعة
هناك عدد من أنواع الشهادات المختلفة التي قد تحتاج إلى نشرها. كما ستلاحظ، عندما تحتاج إلى شهادة تحتوي على قائمة بمتطلبات معينة، يمكنك بناء قالب شهادة بالمواصفات التي تريدها. لذلك، من الناحية التقنية، ليس هناك حقًا أنواع معينة من الشهادات، بل قوالب شهادة تحدد فيها القطع المطلوبة من المعلومات. بينما هذا صحيح تقنيًا، يكون من الأسهل عمومًا تقسيم الشهادات إلى مجموعات مختلفة، مما يجعلها أكثر تمييزًا للعمل الذي من المفترض أن تقوم به.
شهادات المستخدم (User certificates)
كما يوحي الاسم، تُستخدم شهادة المستخدم لأغراض معينة للمستخدمين
الذين يحملون تلك الشهادات. أحد القوى الدافعة وراء المستويات الأعلى من تبني الشهادات هو عملية التحقق من هوية الشبكة. الشركات التي تبحث عن طرق أقوى للتحقق من الهوية في بيئاتها غالبًا ما تنظر إلى الشهادات كجزء من عملية التحقق من الهوية. البطاقات الذكية هي إحدى الآليات التي يمكن استخدامها لهذا الغرض، تحديدًا، نوع من البطاقات المادية ليتم توصيلها بجهاز الكمبيوتر لكي يتمكن المستخدم من الوصول إلى ذلك الجهاز.
يمكن أيضًا تخزين البطاقات الذكية بشكل افتراضي داخل مكان خاص على الأجهزة الحديثة، يُسمى TPM. لكن هذا موضوع ليوم آخر. السبب في ذكرنا للبطاقات الذكية هنا هو أنه غالبًا ما يتم توفير الوظيفة الأساسية لمصادقة البطاقات الذكية بواسطة شهادة مستخدم تم تخزينها على تلك البطاقة الذكية. إذا وجدت نفسك في وسط مشروع لنشر البطاقات الذكية أو نوع من مفاتيح الدخول الفيزيائية، فمن المحتمل أن تجد نفسك بحاجة إلى PKI.
شكل آخر شائع من المصادقة القوية هو one-time passwords (OTPs). تتطلب هذه أن يدخل المستخدم رقم تعريف شخصي (PIN) مُولد عشوائيًا بالإضافة إلى معايير تسجيل الدخول العادية، وفي بعض الحالات، عندما يدخل المستخدم رقم التعريف الشخصي، يتم إصدار شهادة مستخدم مؤقتة تُستخدم كجزء من سلسلة المصادقة.
أماكن إضافية حيث تُستخدم شهادات المستخدم بشكل شائع تشمل عندما توظف الشركات تقنيات تشفير الملفات، مثل EFS (اختصارًا لـ Encrypting File System)، أو عند بناء أنظمة virtual private network (VPN) لتمكين المستخدمين عن بُعد من ربط أجهزة الكمبيوتر المحمولة الخاصة بهم بالشبكة المؤسسية. العديد من الشركات لا ترغب في الاعتماد فقط على اسم المستخدم وكلمة المرور لمصادقة VPN، لذا إصدار شهادات المستخدم والمطالبة بوجودها لبناء نفق VPN أمر شائع.
شهادات الكمبيوتر (Computer certificates)
غالبًا ما تُعرف باسم شهادات الكمبيوتر أو شهادات الجهاز، وتُصدر هذه الشهادات للأجهزة للمساعدة في التفاعل بين الشبكة وحساب الكمبيوتر نفسه. التقنيات مثل SCCM التي تتفاعل مع وتدير أنظمة الكمبيوتر بغض النظر عن المستخدمين المسجلين الدخول إلى تلك الأجهزة تستخدم شهادات الكمبيوتر. تُستخدم هذه الأنواع من الشهادات أيضًا لعمليات التشفير بين الأنظمة على الشبكة، على سبيل المثال، إذا كنت مهتمًا باستخدام IPsec لتشفير الاتصالات بين العملاء وخادم الملفات الآمن. إصدار شهادات الكمبيوتر أو الجهاز لنقاط النهاية في سلسلة الاتصال هذه سيكون ضروريًا لجعل ذلك يعمل بشكل صحيح. أجد نفسي غالبًا أصدر شهادات الكمبيوتر لأجهزة الشركات لمصادقة أنفاق DirectAccess، وهو شكل من أشكال الوصول عن بُعد التلقائي. هناك العديد من الأسباب والتقنيات المختلفة التي قد تكون مهتمًا بها والتي تتطلب إصدار الشهادات لمحطات العمل في بيئتك.
شهادات SSL
إذا وجدت نفسك في منتصف الطريق فيما يتعلق بالشهادات، حيث لم تقم بإدارة خادم CA من قبل ولكنك قد أصدرت وثبتت نوعًا من الشهادات في وقت ما، فمن المحتمل أن الشهادة التي تعاملت معها كانت شهادة SSL. هذا هو النوع الأكثر شيوعًا من الشهادات المستخدمة في البنية التحتية التقنية اليوم، ومن المرجح أن شركتك تستخدم شهادات SSL، حتى لو لم تكن على دراية بها ولم يكن لديك خادم CA واحد يعمل داخل شبكتك.
تُستخدم شهادات SSL بشكل أساسي لتأمين حركة مرور مواقع الويب. في كل مرة تزور فيها موقع ويب وترى HTTPS في شريط العناوين، يستخدم متصفحك حزمة SSL لإرسال المعلومات ذهابًا وإيابًا بين جهاز الكمبيوتر الخاص بك وخادم الويب الذي تتحدث إليه. يحتوي خادم الويب على شهادة SSL، ويتحقق متصفحك من تلك الشهادة قبل السماح لك بالدخول إلى صفحة الويب، للتأكد من أن الشهادة صالحة وأن الموقع بالفعل هو ما يدعيه. ترى، إذا لم نستخدم شهادات SSL على مواقع الويب، يمكن لأي شخص انتحال موقعنا والحصول على المعلومات المرسلة إلى الموقع.
لنقدم مثالاً سريعًا. لنفترض أن أحد مستخدميك في مقهى، يستخدم شبكة Wi-Fi عامة. اكتشف مهاجم طريقة للتلاعب بـ DNS على تلك الشبكة اللاسلكية. يحاول المستخدم زيارة mail.contoso.com للوصول إلى Outlook Web Access الخاص بالشركة للتحقق من بريده الإلكتروني، لكن المهاجم اختطف ذلك المرور والآن يصل المستخدم إلى موقع يبدو كأنه بوابة الشركة ولكنه في الواقع موقع مستضاف بواسطة المهاجم. يكتب موظفك اسم المستخدم وكلمة المرور الخاصة به، وبنجو، أصبح لدى المهاجم الآن بيانات اعتماد ذلك المستخدم ويمكنه استخدامها للوصول إلى شبكتك الحقيقية.
ما الذي يمنع هذا من الحدوث كل يوم في العالم الحقيقي؟ شهادات SSL. عندما تجبر مواقع الويب التي تواجه الخارج، مثل صفحة تسجيل الدخول إلى البريد الإلكتروني تلك، على أن تكون مواقع HTTPS، يتطلب الأمر من المتصفحات العميلة التحقق من شهادة SSL المقدمة مع الموقع. تحتوي شهادة SSL تلك على معلومات لا يمتلكها سوى شركتك؛ لا يمكن انتحالها. بهذه الطريقة، عندما يصل المستخدمون إلى صفحة تسجيل الدخول الحقيقية الخاصة بك، يتحقق المتصفح من شهادة SSL، يجدها صحيحة، ويواصل طريقه بسلاسة. لا يعرف المستخدمون حتى أنهم يتم حمايتهم إلا من خلال رمز القفل الصغير بالقرب من شريط عناوين المتصفح. من ناحية أخرى، إذا تم اعتراض مرورهم وإعادة توجيهه إلى موقع زائف، سيفشل التحقق من شهادة SSL (لأن المهاجم لن يكون لديه شهادة SSL صالحة لاسم موقع شركتك)، وسيتم إيقاف المستخدم في مساره، على الأقل لقراءة صفحة تحذير حول الشهادة الغير صالحة، إذا لم تُنبهه هذه الصفحة على الفور بأن هناك خطأ ما.
بينما سنتحدث عن إنشاء قالب شهادة جديد من أجل شهادة SSL لمواقع الويب الداخلية لاحقًا في هذا الفصل، هناك مكان واحد لاستخدام الشهادات يتجاوز سلسلة شهادات PKI القياسية التي قد تراها على الشبكة. لأن شهادات SSL تستخدم على نطاق واسع على الإنترنت، كانت هناك عدد من الحالات البارزة حيث تم التلاعب بإصدار الشهادات أو سرقة الشهادات نفسها من مراكز بيانات سلطة إصدار الشهادات (CA) نفسها. بدأت المتصفحات الكبرى تفرض قوانين وأنظمة أكثر صرامة للتحقق من شرعية شهادات SSL على الإنترنت، لذا إذا كنت تتطلع إلى نشر شهادة SSL على موقع ويب يتم الوصول إليه بشكل عام، قد يكون من الأفضل الحصول على تلك الشهادة من مرجع عام، مثل Verisign أو Entrust، بدلاً من الاعتماد على خادم CA داخلي. سنستعرض كيفية القيام بذلك لاحقًا في هذا الفصل أيضًا.
عند حصول شركة على شهادة SSL من إحدى هذه السلطات العامة، هناك عملية تحقق معمقة تمر بها السلطة للتأكد من أن الشخص الذي يطلب الشهادة (أنت) هو فعلاً شخص له الصلاحية في الشركة ومخول لإصدار هذه الشهادات. هذا هو أساس الأمان في استخدام شهادات SSL من CA العامة. جميع أجهزة الكمبيوتر الجديدة تعرف بشكل افتراضي أن تثق في الشهادات التي تم إصدارها من قبل هذه السلطات، ولا تحتاج لاتخاذ أي إجراءات خاصة لجعل مواقع الويب الخاصة بك تعمل على الإنترنت. من ناحية أخرى، من الممكن إصدار شهادات SSL من خادم CA الذي قمت ببنائه بنفسك وتقوم بتشغيله داخل شبكتك، لكن هذا يتطلب عدة أمور تجعل الأمر صعبًا، لأن خادم CA الخاص بك ليس موثوقًا به من قبل جميع أجهزة الكمبيوتر في كل مكان، ولا ينبغي أن يكون كذلك. أولاً، إذا كنت تريد إصدار شهادة SSL الخاصة بك لاستخدامها على موقع ويب عام، تحتاج إلى نشر على الأقل جزء من PKI الداخلي الخاص بك، المعروف بقائمة إلغاء الشهادات certificate revocation list (CRL) ، على الإنترنت. في أي وقت تقوم فيه بنشر مكون داخلي لشبكتك على الإنترنت، فإنك تقوم بإدخال مخاطرة أمنية، لذا ما لم يكن عليك فعل ذلك تمامًا، لا يُنصح عمومًا بفعل ذلك. السبب الثاني لصعوبة استخدام شهادات SSL الخاصة بك على مواقع الويب العامة هو أن أجهزة الكمبيوتر المرتبطة بنطاق شركتك فقط هي التي ستعرف كيفية الوثوق بهذه الشهادة. لذا، إذا أخذ المستخدم جهاز الكمبيوتر المحمول الخاص بالشركة إلى المنزل واستخدمه للوصول إلى صفحة تسجيل الدخول إلى البريد الإلكتروني، فسيعمل الأمر بشكل جيد على الأرجح. لكن إذا حاول المستخدم الوصول إلى نفس صفحة تسجيل الدخول إلى البريد الإلكتروني من جهاز الكمبيوتر الخاص به في المنزل، والذي ليس جزءًا من نطاقك أو شبكتك، فسيحصل على رسالة تحذير من الشهادة ويحتاج لاتخاذ خطوات خاصة للوصول إلى الموقع. يا له من ألم للمستخدمين. لا ينبغي أبدًا تشجيع المستخدمين على قبول المخاطرة والمضي قدمًا عبر رسالة تحذير الشهادة—هذه وصفة لكارثة، حتى لو كانت الشهادة التي ينقرون عليها هي واحدة صادرة عن CA الخاص بك. من حيث المبدأ، لا ينبغي أبدًا قبول تلك المخاطرة.
يمكن التخفيف من هذه المشكلات عن طريق شراء شهادة SSL من واحدة من CA العامة تلك، وبالتالي فإن شراء هذه الأنواع من الشهادات هو الطريقة العادية والموصى بها لاستخدام SSL على مواقع الويب العامة الخاصة بك. المواقع التي تكون بالكامل داخل الشبكة هي قصة مختلفة، حيث إنها ليست مواجهة للإنترنت وبصمتها الأمنية أصغر بكثير. يمكنك استخدام خادم CA الداخلي الخاص بك لإصدار شهادات SSL لمواقع الويب الداخلية الخاصة بك، دون الحاجة إلى تكبد التكاليف المرتبطة بشراء الشهادات لجميع هذه المواقع.
هناك بعض الطبقات المختلفة لشهادات SSL التي يمكنك شراؤها من CA العامة، والمعلومات عنها مدرجة على مواقع الويب الخاصة بالسلطة نفسها. الفكرة بشكل أساسي هي أنه كلما دفعت أكثر، كلما كانت شهادتك أكثر أمانًا. هذه الطبقات تتعلق بالطريقة التي تقوم بها السلطة بالتحقق من مقدم طلب الشهادة، حيث أن هذا هو فعلاً المكان الذي يأتي منه الأمان مع شهادات SSL. السلطة تضمن أنه عند الوصول إلى الصفحة المؤمنة بشهادتها، فإن الشهادة قد تم إصدارها للشركة الحقيقية التي تملك تلك الصفحة.
بخلاف طبقة التحقق، التي يمكنك اختيارها عند شراء شهادة، هناك خيار آخر يجب عليك أن تقرره أيضًا، وهذا الخيار أكثر أهمية من الناحية الفنية للطريقة التي تعمل بها الشهادات. هناك اصطلاحات تسمية مختلفة متاحة لك عند شراء شهادة، ولا يوجد إجابة أفضل حول أي واحدة تختار. كل حالة تتطلب شهادة ستكون فريدة ويجب تقييمها بشكل فردي لتحديد أي خطة تسمية تعمل بشكل أفضل. دعونا نغطي بسرعة ثلاث احتمالات لاصطلاح تسمية شهادة SSL.
الشهادات ذات الاسم الفردي (Single-name certificates)
هذه هي الطريقة الأرخص والأكثر شيوعًا عند شراء شهادة لموقع ويب أو خدمة ويب فردية. تحمي شهادة الاسم الفردي وتحتوي على معلومات حول اسم DNS فردي. عند إعداد موقع ويب جديد على portal.contoso.com وترغب في أن يحمي هذا الموقع بعض حركة المرور باستخدام HTTPS، ستقوم بتثبيت شهادة SSL على الموقع. عند إصدار الطلب إلى CA الخاص بك للحصول على هذه الشهادة الجديدة، ستدخل الاسم المحدد portal.contoso.com في حقل الاسم الشائع للنموذج. هذا الاسم الوحيد لـ DNS هو الاسم الوحيد الذي يمكن حمايته والتحقق منه بواسطة هذه الشهادة.
الشهادات متعددة المجالات أو شهادات الاسم البديل للموضوع (SAN)Multi-domain or subject alternative name certificates
الشهادات متعددة المجالات، والتي تسمى أحيانًا شهادات subject alternative name (SAN) ، تكلف عادةً أكثر قليلاً من الشهادات ذات الاسم الفردي، لأنها تمتلك قدرات أكثر. عند طلب شهادة SAN، يكون لديك الخيار لتحديد أسماء DNS متعددة يمكن للشهادة حمايتها. بمجرد الإصدار، ستحتوي شهادة SAN على اسم DNS الأساسي، والذي يكون عادةً الاسم الرئيسي للموقع، وبالإضافة إلى ذلك، داخل خصائص الشهادة، ستجد الأسماء الإضافية لـ DNS التي قمت بتحديدها خلال الطلب. يمكن تثبيت هذه الشهادة الواحدة على خادم ويب، أو ربما خوادم متعددة، واستخدامها للتحقق من حركة المرور لأي من أسماء DNS المدرجة في الشهادة. من الأمثلة الشائعة لاستخدام شهادة SAN هي عند إعداد خادم Lync (Skype for Business) أو خادم Exchange. يستخدم Lync العديد من أسماء DNS المختلفة، ولكن جميع الأسماء تكون داخل نفس نطاق DNS. هنا قائمة بالأسماء التي قد ندرجها في شهادة SAN واحدة لأغراض Lync:
- Lync.contoso.com (الاسم الرئيسي)
- Lyncdiscover.contoso.com
- Meet.contoso.com
- Dialin.contoso.com
- Admin.contoso.com
تُستخدم هذه المواقع/الخدمات المختلفة بواسطة Lync، ثم يتم تنفيذها عبر خادم أو خوادم متعددة، ويمكنك استخدام نفس شهادة SAN على جميع هذه الخوادم للتحقق من حركة المرور المتجهة نحو أي من أسماء DNS هذه.
من الممكن تضمين أسماء متعددة في شهادة SAN لا علاقة لها ببعضها البعض، وتستخدمها أنواع أنظمة مختلفة تمامًا داخل بيئتك. على سبيل المثال، إذا كان لديك بوابة بريد إلكتروني، وبوابة RD، وحل VPN، يمكنك بالتأكيد الحصول على شهادة SAN بالأسماء التالية:
- Mail.contoso.com
- Gateway.contoso.com
- VPN.contoso.com
ستكون الشهادة المذكورة أعلاه غريبة بعض الشيء، وليس شائعًا أن تجدها في العالم الحقيقي. بدلاً من ذلك، عند مواجهة الحاجة لاستخدام شهادة واحدة عبر أنظمة متعددة، من الشائع أكثر شراء...
شهادات wildcard
أخيرًا وليس آخرًا هي شهادة wildcard. هذه هي النموذج الفاخر، الذي يمتلك أكبر عدد من القدرات، ويمنحك أكبر قدر من المرونة، وفي نفس الوقت يوفر أسهل طريق لتنفيذها على العديد من الخوادم. يبدأ الاسم على شهادة wildcard بنجمة (*). تعني هذه النجمة أي، كما في أي شيء يسبق اسم نطاق DNS يتم تغطيته بواسطة هذه الشهادة. إذا كنت تملك contoso.com وتخطط لإنشاء العديد من سجلات DNS العامة التي ستتدفق إلى العديد من المواقع وخوادم الويب المختلفة، يمكنك شراء شهادة wildcard واحدة بالاسم *.contoso.com، وقد تغطي جميع احتياجاتك من الشهادات.
عادةً، يمكن تثبيت شهادات wildcard على العديد من خوادم الويب كما تحتاج، دون حد لعدد أسماء DNS المختلفة التي يمكنها التحقق منها. لقد واجهت استثناءً لهذا مرة واحدة، عندما حدد اتفاق عميل معين مع سلطة الشهادة الخاصة بهم أنهم يجب أن يبلغوا ويدفعوا عن كل حالة استخدام لشهادة wildcard الخاصة بهم. لذا انتبه لتلك الاتفاقيات عند إبرامها مع CA الخاص بك. في معظم الأوقات، تكون شهادة wildcard مفتوحة بالكامل داخل الشركة حتى تتمكن من نشر العديد من المواقع والخدمات عبر العديد من الخوادم واستخدام شهادة wildcard الخاصة بك في كل مكان.
الجانب السلبي لشهادة wildcard هو أنها تكلف أكثر، بشكل ملحوظ. لكن إذا كانت لديك احتياجات كبيرة من الشهادات أو خطط كبيرة للنمو، ستجعل إدارة الشهادات الخاصة بك أسهل وأسرع وأكثر فعالية من حيث التكلفة على المدى الطويل.
تخطيط PKI الخاص بك
نظرًا لأننا نركز في مناقشتنا في هذا الكتاب حول Windows Server 2022، فهذا يعني أن خادم CA الداخلي الخاص بك يمكن ويجب أن يكون أحد الخوادم المقدمة من هذا الإصدار الأحدث والأفضل من أنظمة التشغيل. مثل معظم القدرات في Server 2022، فإن إنشاء خادم سلطة الشهادة في شبكتك بسيط كإضافة دور Windows. عند إضافة الدور إلى خادم جديد، يكون الدور الأول في القائمة هو Active Directory Certificate Services (AD CS). عند تثبيت هذا الدور، ستواجه بعض الخيارات المهمة، ويجب أن تفهم معناها قبل أن تنشئ بيئة PKI قوية.
خدمات الأدوار (Role services)
أول قرار تحتاج إلى اتخاذه عند تثبيت دور AD CS هو اختيار خدمات الأدوار التي ترغب في تثبيتها، كما هو موضح في الشكل 6.1:
عند النقر على كل خيار، ستحصل على وصف لقدراته، لذا يمكنك على الأرجح تحديد الأجزاء التي تحتاجها من الدور عن طريق استكشاف هذه الشاشة. هنا ملخص قصير لهذه الخيارات. لاحظ أنني أقوم بسردها بترتيب مختلف عن الذي تظهر فيه عادة، بسبب الطريقة التي أراها تُكوَّن بها في الميدان:
-ال Certification Authority هذا هو المحرك الأساسي للشهادات الذي يجب تثبيته لكي يصبح هذا الخادم CA بشكل رسمي.
- الCertification Authority Web Enrollment غالبًا ما يتم تثبيت هذا الخيار أيضًا، خاصة في البيئات الصغيرة بما يكفي لتشغيل خادم CA واحد للبيئة بأكملها. الجزء الخاص بالتسجيل عبر الويب سيقوم بتثبيت قدرات IIS (خادم الويب) على هذا الخادم وإطلاق موقع صغير يُستخدم لأغراض طلب الشهادات. سنتناول هذا بمزيد من التفصيل عندما نمر عبر إصدار الشهادات من خلال هذا الواجهة في وقت لاحق في الفصل.
-ال Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service معظم الوقت، نهتم فقط بإصدار الشهادات لأنظمة الشركة المرتبطة بالنطاق. في هذه الحالات، لا تكون هذه الخيارات ضرورية. إذا كنت تخطط لإصدار الشهادات لأجهزة الحاسوب غير المرتبطة بالنطاق من هذا الخادم CA، فيجب عليك تحديد هذه الخيارات.
-ال Network Device Enrollment Service كما يشير الاسم، يوفر هذا الجزء من دور CA القدرة على إصدار الشهادات لأجهزة التوجيه وغيرها من أجهزة الشبكة.
-ال Online Responder هذه وظيفة خاصة مخصصة للبيئات الكبيرة. داخل كل شهادة يوجد تحديد لـ CRL. عندما يستخدم جهاز حاسوب العميل شهادة، فإنه يتحقق من هذه القائمة للتأكد من أن شهادته لم يتم إبطالها. CRL هي جزء مهم من لغز أمان الشهادات؛ في بيئة تحتوي على آلاف العملاء، قد تكون قائمتك مشغولة جدًا بالاستجابة لجميع هذه الطلبات. يمكنك نشر خوادم CA إضافية تقوم بتشغيل Online Responder للمساعدة في تخفيف هذا الحمل.
لأغراض مختبرنا، ولتغطية القدرات المطلوبة لمعظم الشركات الصغيرة إلى المتوسطة، سأختار الخيارين الموضحين في الشكل 6.1: Certification Authority و Certification Authority Web Enrollment .
ال Enterprise مقابل standalone
بعد تثبيت دور AD CS، سيعلمك مدير الخادم أن خدمات الشهادات تحتاج إلى بعض التكوين الإضافي، كما هو الحال مع العديد من تثبيتات الأدوار. عند تكوين دور CA لأول مرة، سيتم تقديمك بخيار كبير. هل تريد أن يكون هذا الخادم CA Enterprise أو Standalone؟
لنبدأ بـ Enterprise CA. كما سيخبرك المعالج، يجب أن يكون خادم Enterprise CA عضوًا في النطاق الخاص بك، وتبقى هذه الخوادم الشهادة متصلة بالإنترنت عادةً حتى تتمكن من إصدار الشهادات لأجهزة الحاسوب والمستخدمين الذين يحتاجونها. انتظر لحظة! لماذا نرغب في إيقاف تشغيل خادم الشهادة على أي حال؟ سنتحدث عن ذلك في دقيقة، ولكن إذا كنت تنوي استخدام هذا الخادم CA لإصدار الشهادات، فيجب بالطبع أن يبقى قيد التشغيل. معظم خوادم CA داخل بيئة النطاق ستكون Enterprise CAs. عند إنشاء Enterprise CA، يمكن أن تخزن القوالب وبعض المعلومات الخاصة بالشهادات داخل Active Directory، مما يجعل التكامل بين الشهادات والنطاق أكثر إحكامًا وأكثر فائدة. إذا كانت هذه هي المرة الأولى التي تتعامل فيها مع دور CA، أوصي ببدء استخدام Enterprise CA لأنه يلبي احتياجات معظم المنظمات بشكل أفضل.
كما يمكنك الاستنتاج بشكل صحيح من النص السابق، هذا يعني أن استخدام Standalone CA أقل شيوعًا. يمكن أن تكون Standalone عضوًا في النطاق، أو يمكن أن تظل خارج تلك الجزء من الشبكة وتكون في مجموعة عمل محلية. إذا كان لديك متطلب أمني ينص على أن خادم الشهادة لا يمكن أن يكون مرتبطًا بالنطاق، فقد يكون هذا سببًا لاستخدام Standalone CA. سبب آخر قد يكون عدم وجود Active Directory في البيئة المختارة.
في رأيي، سيكون من النادر للغاية العثور على شبكة يحاول فيها شخص ما استخدام Windows Server 2022 كسلطة إصدار شهادات دون تشغيل خدمات Active Directory Domain Services، ولكنني متأكد من وجود حالة خاصة في مكان ما تقوم بذلك بالضبط. في هذه الحالة، ستحتاج أيضًا إلى اختيار Standalone. مثال ثالث على متى تختار Standalone هو الحالة التي أشرنا إليها بالفعل، حيث قد يكون لديك سبب لإيقاف تشغيل خادمك. عندما تستخدم هذا السيناريو، يشار إليه عادةً على أنه امتلاك "سلطة الجذر غير المتصلة". لم نتحدث عن الجذر CAs بعد، ولكننا سنتناول ذلك قريبًا. عندما تقوم بتشغيل جذر غير متصل، تقوم بإنشاء المستوى العلوي من تسلسل PKI كجذر مستقل، ثم تقوم ببناء جذر فرعي تحته. جذر الفرعي هو من يقوم بالأعمال الشاقة لإصدار الشهادات، مما يعني أن الجذر يمكن إيقاف تشغيله بأمان حيث إنه لا يقوم بأي مهام مستمرة. لماذا قد ترغب في القيام بذلك؟ حسنًا، معظم الشركات لا تفعل ذلك، ولكنني عملت مع بعض الشركات التي لديها سياسات أمان عالية المستوى، ولهذا السبب قد يكون هذا الموضوع ذا صلة. إذا كانت جميع خوادم CA الخاصة بالشركة مرتبطة ببعضها البعض كـ Enterprise CAs وتخزن جميع معلوماتها داخل Active Directory، فإن اختراق أحد الجذور الفرعية قد يكون كارثيًا على بيئة PKI بأكملها. قد يكون الحل الوحيد لمعالجة الهجوم هو مسح بيئة PKI بالكامل، جميع خوادم CA، وبناءها مرة أخرى. إذا كنت مضطرًا للقيام بذلك، فسيتطلب الأمر ليس فقط إعادة بناء الخوادم بل أيضًا إعادة إصدار نسخ جديدة من جميع الشهادات لجميع المستخدمين والأجهزة التي تمتلكها.
من ناحية أخرى، إذا كنت تستخدم جذر CA غير متصل، فلن يكون قد تأثر بالهجوم. في هذه الحالة، يمكنك التخلص من خوادم الشهادات المتضررة، لكن خادم الجذر الأساسي سيكون مخفيًا بأمان. يمكنك بعد ذلك إعادة تشغيل الجذر، وإعادة بناء جذور فرعية جديدة منه، وستكون لديك مسار أسهل لتصبح تعمل بكامل طاقتها مرة أخرى لأن مفاتيح الجذر المخزنة داخل CA لن تحتاج إلى إعادة إصدار، حيث إنها لم تكن تعرضت للاختراق أثناء الهجوم.
كما قلت، لا أرى هذا كثيرًا في الميدان، لكنه احتمال. إذا كنت مهتمًا بمعرفة المزيد عن جذور CA غير المتصلة واستخداماتها، أوصي بشدة بالاطلاع على المقالة التقنية على الرابط التالي: [Technet article](http://social.technet.microsoft.com/wiki/contents/articles/2900.offline-root-certification-authority-ca.aspx). إذا كنت تفكر في المضي قدمًا بجذر CA غير متصل فقط لأنه يبدو أكثر أمانًا، ولكن ليس لديك سبب محدد للقيام بذلك، أوصيك بتغيير الاتجاه والمضي قدمًا بجذر CA Enterprise على الإنترنت. بينما هناك بعض الفوائد الأمنية للجذر غير المتصل، فإن معظم الشركات لا تجد هذه الفوائد تستحق المتاعب الإضافية التي تصاحب استخدام جذر CA غير متصل. هناك تنازلات في الاستخدام عند اتباع المسار غير المتصل. إذا وجدت نفسك ترغب في إعداد جذر CA مستقل تخطط لإيقاف تشغيله، لكنه أيضًا مرتبط بالنطاق، فإنك تواجه مشاكل حقًا. مثل هذا الخادم سيتوقف عن التزامن مع النطاق بينما يكون غير متصل، وعندما تجد الحاجة لإعادة تشغيل هذا الجذر CA، ستكون لديك صداع كبير ينتظرك.
في معظم الحالات، ستحتاج إلى اختيار جذر CA Enterprise والمضي قدمًا.
ال Root مقابل subordinate (الإصدار)
هذا هو الاختيار الثاني الأكبر الذي تحتاج إلى اتخاذه عند بناء خادم CA جديد. هل سيكون خادمك الجديد Root CA أم subordinate ؟ في بعض الحالات، حتى في الكثير من وثائق Microsoft، يشار إلى الجذر الفرعي (subordinate) أكثر بالـ "إصدار CA بالانجليزية تكون (issuing CA)".
عمومًا، في PKI متعددة الطبقات، تكون الجذور الفرعية هي التي تقوم بإصدار الشهادات للمستخدمين والأجهزة في شبكتك. الفرق يكمن في ما تريده أن يبدو تسلسل CA الخاص بك. في شجرة PKI، هناك شهادة عالية المستوى واحدة، موقعة بنفسها بواسطة الجذر CA، التي تتسلسل إليها جميع الشهادات الأخرى. من ناحية أخرى، يكون الجذر الفرعي هو الذي يقيم تحت الجذر CA في الشجرة، وقد تم إصدار شهادة له من الجذر الذي فوقه.
إذا كانت خططك هي تشغيل خادم CA واحد فقط، فيجب أن يكون جذر. إذا كنت تنشئ نهجًا طبقيًا لإصدار الشهادات، يجب أن يكون الجذر الأول في بيئتك جذرًا، ويمكنك إدراج الجذور الفرعية تحته. يُسمح لك بامتلاك جذور متعددة، وبالتالي أشجار متعددة، داخل شبكة. لذا يمكن هيكلة PKI الخاصة بك بأي طريقة تراها مناسبة. في الشركات الصغيرة، من الشائع جدًا رؤية خادم CA واحد فقط، جذر Enterprise. من أجل البساطة في الإدارة، يكون هؤلاء العملاء مستعدين لتحمل المخاطر التي قد تحدث إذا حدث شيء لهذا الخادم، فلن يكون الأمر صعبًا لبناء واحد جديد وإعادة إصدار الشهادات.
بالنسبة للشبكات الكبيرة، من الشائع رؤية جذر واحد مع عدد قليل من الجذور الفرعية تحته. عادةً في هذه الحالة، يكون الجذر مسؤولًا فقط عن كونه المستوى الأعلى وحامل المفاتيح الهامة، بينما تقوم الجذور الفرعية بالعمل الحقيقي - إصدار الشهادات للعملاء.
تسمية خادم CA الخاص بك
في هذه النقطة، الآن بعد أن قمت بتثبيت الدور، تم تحديد اسم الخادم نفسه بالفعل. كنت تعرف هذا بالفعل. لكن عندما تتقدم في المعالجات لتكوين CA لأول مرة، ستجد شاشة تسمى "تحديد اسم CA". ماذا؟ اعتقدت أننا قمنا بذلك بالفعل عندما قمنا بتحديد اسم الخادم!
لا، لدينا الاسم النهائي بالفعل، واسم الخادم هذا تم توصيله بـ Active Directory حيث تم ضم الخادم إلى النطاق، لكن الاسم الفعلي لـ "CA" هو شيء آخر تمامًا. هذا هو الاسم الذي سيتم تحديده داخل خصائص كل شهادة يصدرها هذا CA. هذا أيضًا اسم سيتم تكوينه في أماكن متعددة داخل Active Directory، حيث نقوم ببناء جذر CA Enterprise. يقوم المعالج بتحديد اسم محتمل لاستخدامه، والذي يقبله العديد من المسؤولين ويستخدمونه. إذا كنت تريد تكوين اسمك الخاص، هذا هو المكان الذي يجب عليك القيام بذلك.
بمجرد تعيين الاسم هنا، هذا هو اسم CA إلى الأبد:
هل يمكنني تثبيت دور CA على وحدة تحكم المجال؟
بما أن الدور يسمى رسميًا Active Directory Certificate Services، هل يعني ذلك أنه يجب علي تثبيت هذا الدور على أحد خوادم وحدة تحكم المجال؟ لا! لسوء الحظ، لقد صادفت العديد من الشركات الصغيرة إلى المتوسطة التي قامت بذلك بالضبط، ولحسن الحظ لم تواجه الكثير من المشاكل. لذا من الناحية الفنية، فإنه يعمل. ومع ذلك، لا يُوصى من قبل Microsoft كمسار تثبيت، ويجب عليك بناء CAs الخاصة بك على خوادمها الخاصة؛ حاول عدم استضافة الأدوار الأخرى معها كلما كان ذلك ممكنًا.
النهاية
نكون هنا انتهينا من الجزء 1 من الفصل 6 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
