الأول من نوفمبر قادم - هل خادم Exchange جاهز؟

1 نوفمبر 2015: القواعد الجديدة تدخل حيز التنفيذ

يود أصدقاؤك في SSL.com إعلامك بهذه البداية نوفمبر شنومست، شنومكس، بعض تغييرات مهمة للغاية بشأن ما يمكن تغطيته شهادات SSL يسري مفعولها:

• لن يتم إصدار الشهادات الجديدة التي تحتوي على أسماء داخلية بعد الآن من قبل أي مرجع مصدق يتبع إرشادات CA / Browser Forum (أي جميع السمعة)
  
  لاحظ أنه لبعض الوقت الآن ، لم يُصدر SSL.com شهادات إنترانت للأسماء الداخلية مع تواريخ انتهاء الصلاحية بعد الأول من نوفمبر 1 ، وبالتالي يجب ألا يواجه عملاء SSL.com أي مشكلات فورية - ومع ذلك ، فإننا نشجعك بشدة على التحقق مرة أخرى من شهاداتك عن الطرق المحتملة التي قد تؤثر بها هذه الأحكام عليك.
• لن يتم إعادة إصدار الشهادات الحالية التي تحتوي على أسماء داخلية بعد 1 نوفمبر 2015.
  
  مرة أخرى ، عملت SSL.com للتأكد من أنك لن تواجه مشاكل بسبب هذا - ومع ذلك ، فقد قدمنا ​​سيناريو أسوأ حالة لتعديلك أدناه.
• سيتم إبطال الشهادات الحالية التي تحتوي على أسماء داخلية تلقائيًا في الأول من تشرين الثاني (نوفمبر) 1.
  
  هذه سياسة شاملة ، حيث قد يكون لدى بعض بنيات الأمان شهادات قديمة موجودة منذ فترة طويلة ولا تلتزم بهذه القواعد.

تعني هذه التغييرات أن البريد الإلكتروني - الأداة الأولى والأكثر فائدة للإنترنت - قد يتأثر سلبًا بالتغييرات ، لا سيما إذا كنت تستخدم خادم Microsoft Exchange Server (الذي تشير أبحاث السوق إلى أنه يمثل 63 بالمائة من الجميع). وبالتالي يمكن أن تبدأ بنية الأمان الخاصة بك بالتأثر بدءًا من يوم All Saint's القادم.

هل أنت مستعد؟

ماذا تقصد عندما تقول "الأسماء الداخلية"؟

أبسط تعريف للاسم الداخلي هو أي معرف شبكة جزء من شبكة خاصة و لا يمكن الوصول إليه باستخدام اسم باستخدام نطاق المستوى الأعلى (TLD) أو عنوان IP فريد. بالتضمين ، أي معرف شبكة مسجل بشكل عام مع سلطة مركزية مثل ICAAN سيكون قابلاً للاستخدام في الشهادات

في الأيام السابقة ، الأبسط للإنترنت ، كان على بنية DNS الداخلية فقط أن تقلق بشأن تجنب مجموعة محدودة من TLDs - وبالتالي ، يمكن أن تدعم شبكة AwfulBigCo.com الداخلية ليس فقط ABC و ABC لندن لكن 1600 بنسلفانيا. حفظ, بريد و جاندالف. وعلاوة على ذلك، يتم وضع بعض نطاقات عناوين IPv4 و IPv6 جانبًا للاستخدام المحلي البحت - تتضمن هذه النطاقات المحجوزة "192.168. *. *" للتوجيه و 10. *. *. * للشبكات المحلية. يعد تأمين الشبكات الداخلية بشهادات SSL فكرة جيدة بالطبع ، وحتى صدور الحكم الجديد ، يمكن لأي مسؤول شبكة أن يطلب ويستلم شهادة تتضمن أيًا من هذه الشهادات.

اعتبارًا من الأول من تشرين الثاني (نوفمبر) 1 ، لن يكون هذا هو الحال - لن يتم إصدار الشهادات بعد الآن - أو ، بشكل حاسم ، إعادة إصدار - التي تحتوي على أسماء داخلية. تم تصميم هذه القواعد الجديدة لتحسين الأمان والسماح بالاستخدام المناسب لأسماء نطاقات المستوى الأعلى الجديدة (على سبيل المثال ، تعد كل من .london و .nyc نطاقات TLDs عامة الآن). ومع ذلك ، فإنها تتطلب من أي مستخدم Exchange إلقاء نظرة فاحصة على الشبكة وإعدادات الأمان الخاصة بهم وإجراء تغييرات للإقرار بهذه القواعد الجديدة. نظرًا لأن العديد من تصميمات أمان Exchange قد استخدمت في الماضي أسماء داخلية ، فقد يتسبب ذلك في حدوث مشكلات خطيرة في خدمة البريد الخاصة بك عندما تنتهي صلاحية شهاداتك ، نظرًا لأنه لا يمكن إصدار شهادات جديدة بأسماء داخلية لتحل محل شهاداتك الحالية - والأسوأ من ذلك ، أي شهادة متعددة المجالات ستفشل عملية التجديد التي تحتوي على حتى اسم داخلي واحد ، مما قد يعرض حركة مرور بريدك إلى عمليات استغلال ضارة.

قد يؤثر عدم القيام بذلك بشكل سلبي على حركة البريد الخاص بك ، عملك و / أو سمعتك.

يبدو رهيبة.

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

انظر ، قام موفر شهادة AwfulBigCo بتشغيل طلبه بعد الروبوتات الخاصة به ، واكتشف تلك الأسماء الداخلية و (وفقًا لقواعد منتدى CA / B) رفض التجديد.

هذه مشكلة. لن يتم تجديد UCC ولن يقتصر الأمر على حماية الخدمات التي تستخدم الأسماء الداخلية التي تم طلبها (أي جميع بريد الشركة ونسخ FTP الاحتياطية) - ولن يتم أيضًا حماية أي نطاقات أخرى مدرجة في UCC ، مثل الأساسي و .co. uk لـ AwfulBigCo.

بالتأكيد ، هذا هو السيناريو الأسوأ - لكننا نعتقد حقًا أن الأمن الكامل يعتمد على الاستعداد لذلك بالضبط.

حسنًا ، أنا خائف شرعي - ماذا أفعل الآن؟

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

في الأساس ، هناك بعض الخيارات التي يمكنك اختيارها:

1. أعد تكوين النظام لاستخدام أسماء النطاقات المسجلة علنًا فقط.
   ربما يكون هذا هو الحل الأفضل - فهو يجعل قضية الاسم الداخلي محل نقاش وسيكون أبسط بشكل عام للمحافظة عليها وتوسيعها في المستقبل. لسوء الحظ ، من المحتمل أن يتطلب هذا الخيار قدرًا كبيرًا من العمل مقدمًا ، ولكن يمكن إعداد خوادم Microsoft Exchange لاستخدام أسماء نطاقات عامة مؤهلة بالكامل (وهذا المنتدى CA / Browser ورقة بيضاء يخبرنا المزيد عن تنفيذ FQDNs في شبكات Active Directory). من المؤكد تقريبًا أن الإدارة بعد التغيير ستكون بسيطة أو أبسط من ذي قبل (إضافة كبيرة لـ Bob) والمضي قدمًا سيكون AwfulBigCo قادرًا على استخدام الشهادات الموثوقة بشكل عام لتأمين جميع حركة المرور داخليًا وخارجيًا. من العيوب المحتملة لهذه الطريقة أنها قد تسمح باكتشاف معلومات حول البنية التحتية الداخلية للشركة عبر DNS ، لكن التكوين الذكي لمناطق DNS يمكن أن يساعد في معالجة ذلك - على سبيل المثال ، استخدام نطاقات فرعية مثل أسماء النطاقات "الداخلية" أو المنفصلة والحل المقيد من هؤلاء خارج شبكات الشركة.
2. تسجيل الأسماء الداخلية كـ FQDNs.
   لسوء الحظ ، ليس هناك خيار لعنوان IP المحجوز ، و "Mail" و "Gandalf" بالطبع متاحان. (سنفترض من أجل سلامة عقل بوب أن نطاقي .com و. co.uk مسجلين بأمان بالفعل - يومه صعب بما فيه الكفاية.)
   أيضا ، حتى لو التبادل متاح - وتذكر أن .exchange هو أحد نطاقات TLD الجديدة التي تساعد تقديمها في دفع هذا التغيير في القاعدة - من الممكن أن يتم الاستغناء عنها ومتاح فقط بسعر باهظ - من المحتمل أن تتوفر بدائل أسهل وأرخص.
3. قم بإعداد CA Enterprise
   هذه طريقة مستخدمة بالفعل من قبل كيانات كبيرة حقًا تحتاج إلى تأمين الاتصالات الداخلية بشكل أساسي. يعمل المرجع المصدق للمؤسسة باعتباره مرجعًا لشهادة الشركة - بشكل أساسي ، بدلاً من سلسلة الثقة التي تصل إلى مرجع مصدق خارجي ، يتم تأمين جميع الشهادات في نهاية المطاف بواسطة شهادة جذر مُنشأة داخليًا. الحفاظ على بنية التسمية القديمة التي تمتلكها AwfulBigCo) هناك مشكلات أمنية خطيرة يجب مراعاتها - قد يؤدي الاختراق على غرار Sony إلى الكشف عن شهادة جذر المؤسسة و / أو المفتاح الخاص ، مما يسمح باستغلال غير محدود تقريبًا للشبكة. أيضًا ، لن يتم الوثوق بالشهادات الصادرة داخليًا في أي مكان آخر - فهذه طريقة تؤمن الاتصالات الداخلية ولكن لا يمكنها توسيع الثقة خارج جدران شبكة عملك. أخيرًا ، لا يعد إنشاء مرجع مصدق للمؤسسة بأي حال من الأحوال حلاً بين عشية وضحاها ، وقد يكون أكثر صعوبة من الخيارات الأخرى المدرجة هنا ، وبالتالي فهو قابل للتطبيق فقط للشبكات الكبيرة (أو المتنامية).
   
   يسعد SSL.com بتقديم خدمات استشارية وإدارية لمساعدتك في التفاوض على المسار لإنشاء Enterprise CA خاص بك - فقط أرسل رسالة إلى Enterpriseca@ssl.com وسيتصل بك أحد كبار المسؤولين لدينا قريبًا.
4. استخدم الشهادات الموقعة ذاتيا
   يحتوي هذا الخيار على عيوب مماثلة لتلك الخاصة بـ Enterprise CA ، ولكنه لا يتسع نطاقه جيدًا - نظرًا لأن كل شهادة موقعة ذاتيًا لا تحتوي على سلسلة ثقة تتجاوز نفسها ، يجب تثبيت كل شهادة فردية على كل عميل لتجنب رسائل الخطأ . ستؤدي الإدارة عبر شبكة واسعة أيضًا إلى خلق مجموعة جديدة كاملة من المتاعب لبوب المسكين - شيء بسيط مثل تحديثات المتصفح التلقائية يمكن أن يسبب الفوضى ما لم يتم الحفاظ على اليقظة المستمرة على كل جهاز.

كالعادة، تواصل معنا في SSL.com إذا كان لديك أي أسئلة. تذكر - الإنترنت الأكثر أمانًا هو إنترنت أفضل.