معهد ماساتشوستس للتكنولوجيا. محاضرة رقم 6.858. "أمن أنظمة الكمبيوتر." نيكولاي زيلدوفيتش ، جيمس ميكنز. 2014 سنة
أمان أنظمة الكمبيوتر هي دورة حول تطوير وتنفيذ أنظمة الكمبيوتر الآمنة. تغطي المحاضرات نماذج التهديد ، والهجمات التي تهدد الأمن ، وتقنيات الأمان بناءً على العمل العلمي الحديث. تشمل الموضوعات أمان نظام التشغيل (OS) ، والميزات ، وإدارة تدفق المعلومات ، وأمان اللغة ، وبروتوكولات الشبكة ، وأمان الأجهزة ، وأمان تطبيقات الويب.
المحاضرة 1: "مقدمة: نماذج التهديد"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 2: "السيطرة على هجمات القراصنة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 3: "تجاوزات العازلة: المآثر والحماية"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 4: "فصل الامتيازات"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 5: "من أين تأتي أنظمة الأمن؟"
الجزء 1 /
الجزء 2المحاضرة 6: "الفرص"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 7: "وضع حماية العميل الأصلي"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 8: "نموذج أمن الشبكات"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 9: "أمان تطبيق الويب"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 10: "التنفيذ الرمزي"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 11: "لغة برمجة Ur / Web"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 12: أمن الشبكات
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 13: "بروتوكولات الشبكة"
الجزء 1 /
الجزء 2 /
الجزء 3المحاضرة 14: "SSL و HTTPS"
الجزء 1 /
الجزء 2 /
الجزء 3 سنلقي الآن نظرة على كيفية استخدام بروتوكولات التشفير لحماية اتصالات الشبكة على الإنترنت وكيف تتفاعل بشكل عام مع عوامل الشبكة. قبل الخوض في التفاصيل ، أود أن أذكركم أنه سيكون هناك اختبار يوم الأربعاء ، ولكن ليس في هذا الجمهور ، ولكن في ووكر ، في الطابق الثالث ، خلال وقت المحاضرة المنتظم.
لذلك ، سنتحدث اليوم عن كيفية استخدام الإنترنت للتشفير لحماية اتصال الشبكة ، والنظر في موضوعين وثيق الصلة.
الأول هو كيفية تأمين الاتصالات المشفرة على نطاق أكبر من نظام Kerberos ، الذي تناولناه في المحاضرة الأخيرة. والثاني هو كيفية دمج حماية التشفير هذه ، المقدمة على مستوى الشبكة ، في التطبيق بأكمله ، وكيف يضمن متصفح الويب استخدام الحماية التي يوفرها بروتوكول التشفير. ترتبط هذه الموضوعات ارتباطًا وثيقًا ، لذلك اتضح أن حماية اتصالات الشبكة من السهل جدًا توفيرها ، لأن التشفير يعمل دائمًا. لكن دمجها في المتصفح هي مهمة أكثر صعوبة من بناء نظام حول التشفير.
قبل التعمق في هذه المناقشة ، أود أن أذكرك بالعناصر الأساسية للتشفير التي سنستخدمها.
في محاضرتنا الأخيرة حول Kerberos ، استخدمنا التشفير المتماثل ، أو
التشفير وفك التشفير. معناه أنه لديك مفتاح سري K ووظيفتان. وبالتالي ، يمكنك أخذ بعض البيانات ، دعنا نسميها P ، هذا نص عادي يمكنك تطبيق وظيفة التشفير عليه ، وهذه وظيفة بعض المفتاح K. وإذا قمت بتشفير هذا النص العادي ، فستحصل على النص المشفر C. وبالمثل ، لدينا هناك وظيفة فك تشفير D تستخدم نفس المفتاح K ، ونتيجة لذلك سيتحول النص المشفر C إلى نص عادي P. هذا هو البدائي الذي بني حوله Kerberos.
ولكن اتضح أن هناك بدائية أخرى ستكون مفيدة لمناقشة اليوم ، والتي تسمى التشفير وفك التشفير غير المتناظر. الفكرة هنا هي الحصول على مفاتيح مختلفة للتشفير وفك التشفير. دعونا نرى لماذا هذا مفيد للغاية.
هنا توجد وظيفة E ، والتي يمكنها تشفير مجموعة معينة من الرسائل P بمفتاح عام معين ، ونتيجة لذلك ، للحصول على النص المشفر C. من أجل فك تشفيره مع الوظيفة D ، تحتاج فقط إلى تحديد المفتاح السري المقابل sk والحصول على النص المصدر P.
سهولة التشفير غير المتماثل هو أنه يمكنك نشر مفتاح عام على الإنترنت ويمكن للأشخاص تشفير الرسائل نيابةً عنك ، ولكنك تحتاج إلى مفتاح سري لفك تشفير رسائلهم. سنرى اليوم كيف يتم استخدام هذا في البروتوكول. في الممارسة العملية ، غالبًا ما تستخدم تشفير المفتاح العام بطريقة مختلفة قليلاً. على سبيل المثال ، بدلاً من تشفير الرسائل وفك تشفيرها ، قد تحتاج إلى توقيع الرسائل أو التحقق منها.
اتضح أن هذه العمليات ذات الصلة على مستوى التنفيذ ، ولكن على مستوى تطبيق API قد تبدو مختلفة قليلاً. على سبيل المثال ، يمكنك تسجيل الرسالة M باستخدام المفتاح السري sk والحصول على بعض التوقيع S. ثم يمكنك التحقق من هذه الرسالة باستخدام المفتاح العام المقابل pk ونتيجة لذلك الحصول على إشارة منطقية تخبر إذا كان التوقيع S صحيحًا للرسالة M.
فيما يلي بعض الضمانات البديهية نسبيًا التي توفر هذه الميزات. على سبيل المثال ، إذا تلقيت هذا التوقيع وتم التحقق منه بشكل صحيح ، فهذا يعني أنه يجب أن يتم إنشاؤه بواسطة شخص لديه مفتاح السر الصحيح. هل هذا واضح؟
ثم دعنا نحاول معرفة كيفية حماية اتصالات الشبكة على نطاق أكبر من Kerberos. في Kerberos ، كان لدينا نموذج بسيط إلى حد ما ، حيث استخدم جميع المستخدمين والخوادم نوعًا من الاتصال بكائن KDC الذي كان يحتوي على هذا الجدول العملاق من المستخدمين والخدمات ومفاتيحهم. عندما يريد المستخدم التحدث إلى خادم ما ، يجب عليه أن يطلب من شركة KDC إنشاء التذكرة التي يحتاجها بناءً على هذه الطاولة العملاقة.
لذا يبدو أن هذا نموذج بسيط إلى حد ما. فلماذا نحتاج إلى شيء آخر؟ لماذا Kerberos ليست جيدة بما يكفي للعمل مع المواقع؟ لماذا لا يستخدم الإنترنت Kerberos حصريًا لتأمين جميع الاتصالات؟
لقد أجبت بشكل صحيح - لأن KDC الوحيد يجب أن يثق في الجميع ، وهذا أمر سيئ. قد تواجه مشاكل إذا كنت تعتقد أن جهازًا معينًا آمن تمامًا.
ربما يرغب الأشخاص في معهد ماساتشوستس للتكنولوجيا في الوثوق بشخص ما على الشبكة المحلية التي تديرها شركة KDC ، ولكن ليس الجميع على الإنترنت.
وإجابة الطالب الثاني صحيحة أيضًا - من الصعب جدًا إدارة هذا العدد الضخم من المفاتيح. في الواقع ، قد يكون من الصعب جدًا إنشاء KDC واحد يمكنه إدارة مليار مفتاح أو عشرة مليارات مفتاح لجميع الأشخاص في العالم. من المضاعفات الأخرى لاستخدام Kerberos للإنترنت بالكامل أنه يجب أن يكون لدى جميع المستخدمين مفتاح ، أو يجب أن يكونوا معروفين بواسطة KDC. لا يمكنك حتى استخدام Kerberos في معهدنا للاتصال ببعض الخوادم إذا لم يكن لديك حساب في قاعدة بيانات Kerberos. في حين أنه بالنسبة إلى الإنترنت بالكامل ، من المنطقي أن نتوقع أنه عندما تذهب إلى الكمبيوتر ، فإنه لا يعرف على الإطلاق من أنت ، ولكنه سيسمح لك بالانتقال إلى موقع أمازون المحمي بالتشفير.
هاه؟
هناك العديد من الأشياء الأخرى التي تتوقعها من بروتوكول التشفير ، وسنلقي نظرة على كيفية ظهورها في SSL. لكن الفكرة الأساسية هي أن هذا الحل هو نفسه بالنسبة إلى Kerberos ، و SSL أو TLS. أنت على صواب عندما تذكر أن بروتوكولات Kerberos الأصلية التي قرأناها في مواد المحاضرة تم تطويرها منذ فترة طويلة. وإذا أردنا استخدامها للإنترنت الحديث ، فسوف يحتاجون إلى تغيير شيء ما. ما هي الأفكار الأخرى التي لديك ، فلماذا لا نستخدم Kerberos؟
هذا صحيح ، هناك مشكلة في التوسع عند استعادة الوصول ، وربما عند تسجيل مستخدمين جدد ، لأنك ستضطر شخصيًا للذهاب إلى مكتب حساب والحصول على حساب هناك. ماذا ايضا؟
الطالب: يجب أن يكون خادم Kerberos متصلاً بالإنترنت دائمًا.
الأستاذ: نعم ، هذه مشكلة أخرى. لقد أدرجنا نوعًا من مشكلات الإدارة ، ولكن على مستوى البروتوكول ، يجب أن تكون KDC دائمًا عبر الإنترنت ، لأنها تعمل في الواقع كوسيط لأي تفاعلاتك مع الخدمات. هذا يعني أنه في كل مرة تزور فيها موقعًا إلكترونيًا جديدًا ، فأنت بحاجة إلى التحدث إلى KDC. أولاً ، سيكون هناك اختناق من حيث الأداء. مثل الأنواع الأخرى من قابلية التوسع ، سيؤدي هذا المبدأ إلى قابلية الأداء ، في حين أن المبادئ المذكورة أعلاه تؤدي فقط إلى قابلية التوسع للإدارة.
لذا ، كيف يمكننا حل هذه المشكلة باستخدام هذه المبادئ؟ الفكرة هي استخدام تشفير المفتاح للتوقف عن استخدام KDC.
دعنا أولاً نكتشف ما إذا كان بإمكانك إنشاء اتصال آمن إذا كنت تعرف فقط بعض المفاتيح العامة للجانب الآخر. وبعد ذلك سنرى كيف نربط إصدار مفتاح KDC العام بمصادقة الأطراف في هذا البروتوكول. إذا كنت لا ترغب في استخدام KDC ، فيمكنك القيام بما يلي باستخدام تشفير المفتاح العام: بطريقة أو بأخرى ، اكتشف المفتاح العام للشريك على الجانب الآخر من الاتصال. لذلك ، في Kerberos ، إذا كنت أرغب في الاتصال بخادم الملفات ، فأنا أعرف فقط المفتاح العام لخادم الملفات من مكان ما. بصفتي طالبًا جديدًا ، أحصل على نسخة مطبوعة تفيد بأن المفتاح العام لخادم الملفات هو كذا وكذا ، ويمكنني استخدامه للاتصال.
يمكنك ببساطة تشفير الرسالة للمفتاح العام لخادم الملفات الذي تريد الاتصال به. ولكن اتضح أنه في الممارسة العملية ، فإن هذه العمليات باستخدام هذه المفاتيح العامة بطيئة جدًا. هم عدة أوامر من حجم أبطأ من مفاتيح التشفير المتماثل. لذلك في الممارسة العملية ، عادة ما تريد دائمًا التخلي عن استخدام التشفير العام.
وبالتالي ، قد يبدو بروتوكول نموذجي مثل هذا. لديك A و B ، ويريدون التواصل ، و A يعرف المفتاح العام B. وفي نفس الوقت ، يولد A نوعًا ما من مفتاح الجلسة S ، ما عليك سوى اختيار رقم عشوائي له. ثم A على وشك إرسال المفتاح B لجلسة S ، بحيث يبدو مثل Kerberos. سنقوم بتشفير مفتاح الجلسة S لـ B.
إذا تذكرت ، للقيام بذلك ، في Kerberos ، كنا بحاجة إلى KDC لأن A لم يكن يعرف مفتاح B أو لم يُسمح له بمعرفته ، لأنه سر لا يعرفه سوى B. ولكن باستخدام مفتاح عام ، يمكنك القيام بذلك على الفور ، فقط قم بتشفير السر باستخدام مفتاح Bspk العمومي ، وأرسل الرسالة ب. الآن يمكن لـ B فك تشفير هذه الرسالة والقول: أحتاج إلى استخدام هذا المفتاح السري. الآن لدينا قناة اتصال حيث يتم تشفير جميع الرسائل ببساطة باستخدام هذا المفتاح السري S.
لذلك هناك بعض الميزات المفيدة في هذا البروتوكول. أولاً ، تخلصنا من الحاجة إلى وجود KDC عبر الإنترنت وإنشاء مفتاح جلسة لنا. يمكننا ببساطة ضمان سرية المعلومات المرسلة إذا أنشأها أحد أطراف الاتصال ثم قام بتشفيرها للجانب الآخر دون استخدام KDC.
شيء جيد آخر هو الثقة في أن B فقط يمكنه قراءة الرسائل المرسلة من A إلى B ، لأن B فقط يمكنه فك تشفير هذه الرسالة. لذلك ، يجب أن يكون B المفتاح الخاص المطابق S.
الطالب: هل يهم من يعطي هذا المفتاح - المستخدم أم الخادم؟
الأستاذ: ربما. أعتقد أن ذلك يعتمد على الخصائص التي تريدها من هذا البروتوكول. لذلك ، ماذا لو ارتكبت أ خطأ أو استخدمت عشوائية خاطئة ، فإن الخادم الذي يرسل البيانات مرة أخرى يعتقد: "أوه ، هذه هي البيانات الوحيدة التي ستراها أ." قد لا يكون هذا صحيحًا تمامًا ، لذا يجب التفكير فيه. هناك العديد من المشاكل الأخرى مع هذا البروتوكول.
الطالب: هل يمكن للمهاجم استخدام مفتاح لإرسال رسائل متكررة؟
البروفيسور: نعم ، قد تكون المشكلة أنه يمكنني فقط إرسال هذه الرسائل مرة أخرى ، وستبدو كما لو كانت إرسال رسالة B مرة أخرى ، وهكذا.
لذلك ، عادة ما يكون حل هذه المشكلة هو أن طرفي الاتصال متورطين في توليد S وهذا يضمن أن المفتاح الذي نستخدمه هو "جديد". لأنه هنا ، في الشكل ، في الواقع ، لا يولد B أي شيء ، لذلك تبدو رسائل البروتوكول هذه متشابهة في كل مرة.
عادة ما يحدث أن يختار أحد الجانبين رقمًا عشوائيًا مثل S ، ثم يختار الجانب الآخر ، B ، أيضًا رقمًا عشوائيًا ، يسمى عادةً nonce. هناك رقمان ومفتاح لم يتم اختيارهما حقًا من جانب واحد فقط ، إنه تجزئة اختاره كلا الجانبين للتفاعل المشترك. بالإضافة إلى التجزئة ، يمكنك استخدام بروتوكول Diffie-Hellman ، الذي درسناه في المحاضرة الأخيرة ، والذي بفضله تحصل على الخصوصية أولاً. هذه الرياضيات أكثر تعقيدًا من تجزئة رقمين عشوائيين اختاروا هذين الجانبين. ولكن بعد ذلك ستحصل على خاصية جيدة مثل مفتاح السر المشترك الأصلي ، مما يلغي الحاجة إلى نقل مفتاح فك التشفير عند نقل البيانات المشفرة.
وبالتالي ، يمكن تجنب الهجمات المتكررة على النحو التالي. يقوم B بإنشاء nonce ثم تعيين المفتاح السري الحقيقي S '، والذي يُستخدم لتجزئة المفتاح السري S باستخدام هذا nonce. وبطبيعة الحال ، سيتعين على B إرسال nonce مرة أخرى إلى A لمعرفة ما يحدث عندما يتفق كلاهما على المفتاح.
مشكلة أخرى هي أنه لا يوجد مصادقة حقيقية أ. أ يعرف من هو ب ، أو على الأقل يعرف من يمكنه فك تشفير البيانات. لكن B ليس لديه فكرة عن الطرف الآخر ، سواء كان نوعًا من الخصم الذي يتظاهر بأنه الآخر ، أو شخص آخر. كيف يمكن إصلاح ذلك في عالم المفتاح العام؟
هناك عدة طرق للقيام بذلك. أحد الاحتمالات هو التوقيع على هذه الرسالة في البداية ، لأن لدينا مبدأ التوقيع الجيد هذا. لذا ربما يمكننا توقيع هذا بمفتاح سري. يوفر هذا التوقيع توقيعًا ، ولكن من المفترض أنك تقوم بتعيينه ، كما يمكنك تقديم هذه الرسالة.
ثم يجب أن يعرف B أن A هو مفتاح عام للتحقق من التوقيع. ولكن إذا كان B يعرف أن A هو مفتاح عام ، فسيكون B متأكدًا تمامًا من أن A هو الذي أرسل هذه الرسالة.
شيء آخر يمكنك القيام به هو الثقة في التشفير. لذلك ربما يمكن لـ B إرسال nonce مرة أخرى إلى A ، وتشفيرها باستخدام المفتاح العام الذي توفره A. وبعد ذلك يمكن لـ A فقط فك تشفير nonce وإنشاء مفتاح الجلسة النهائية S '. لذلك هناك بعض الحيل التي يمكنك القيام بها. هذه هي الطريقة التي تعمل بها شهادات العميل في متصفحات الإنترنت اليوم.
وبالتالي ، يحتوي A على مفتاح سري ، وبالتالي ، عندما تتلقى شهادة MIT شخصية ، يقوم متصفحك بإنشاء مفتاح سري طويل الأمد ويحصل على شهادة له. وفي كل مرة ترسل طلبًا إلى خادم الويب ، تثبت حقيقة أنك تعرف المفتاح السري لشهادة المستخدم الخاصة بك ، ثم تقوم بتعيين المفتاح السري S لبقية الاتصال.
هذه مشاكل يمكن إصلاحها بسهولة على مستوى البروتوكول. ومع ذلك ، فإن أساس كل ما سبق هو أن جميع الأطراف تعرف المفاتيح العامة لبعضها البعض. كيف يمكنك معرفة المفتاح العام لشخص ما؟ لنفترض أنني أريد الاتصال بموقع ويب ، ولدي عنوان URL أريد الاتصال به ، أو اسم مضيف ، كيف يمكنني معرفة أي مفتاح عام يطابقه؟
وبالمثل ، إذا اتصلت بخادم MIT لرؤية تقديراتي ، فكيف يعرف الخادم ما يجب أن يكون مفتاحي العام لتمييزه عن المفتاح العام لطالب MIT آخر؟
هذه هي القضية الرئيسية التي عالجتها KDC. في الواقع ، قامت شركة الحفر الكويتية بحل مشكلتين لنا. أولاً ، أنشأ رسالة (Ebspk (S)) ، وأنشأ مفتاح الجلسة وشفّرها للخادم. لقد أصلحنا هذا الآن من خلال إنشاء تشفير المفتاح العام. ولكننا كنا بحاجة أيضًا إلى مطابقة أسماء السلسلة الرئيسية مع مفاتيح التشفير Kerberos التي تم توفيرها لنا سابقًا.
يوجد بروتوكول TLC لمثل هذه الأشياء في عالم HTTPS. معناه هو أننا سنستمر في الاعتماد على جوانب معينة من العملية التي تدعم هذه الجداول العملاقة التي تعين أسماء المشاركين في العملية إلى مفاتيح التشفير. الخطة هي أنه سيكون لدينا شيء يسمى مرجع مصدق ، والذي يشار إليه بالحرفين CA في جميع أنواع الأدبيات حول أمان الشبكة. يدعم المرجع المصدق (CA) هذا أيضًا الجدول بشكل منطقي ، في جزء واحد يتم عرض أسماء جميع المشاركين فيه ، وفي جزء آخر - المفاتيح العامة المقابلة. والفرق الرئيسي بين هذا المركز و Kerberos هو أن هذا المرجع المصدق ليس بالضرورة أن يكون عبر الإنترنت لجميع المعاملات.
في Kerberos ، من أجل التواصل مع شخص ما أو العثور على مفتاح شخص آخر ، تحتاج إلى التحدث إلى KDC. بدلاً من ذلك ، في عالم CA ، يفعلون ذلك.
إذا كان لديك اسم من نوع ما هنا ومفتاح المفتاح المطابق في جزء آخر من الجدول ، فستقوم سلطة التصديق بتوقيع الرسائل التي تحتوي على صفوف معينة في هذا الجدول. وبالتالي ، يجب أن يكون لدى المرجع المصدق مفاتيح خاصة وعامة هنا. سيستخدم مفتاحًا سريًا للعثور على رسائل لمستخدمين آخرين على النظام يمكنك الاعتماد عليهم.
لذلك إذا كان لديك سجل "name + key" في قاعدة بيانات CA ، فسيقوم CA بإنشاء رسالة تفيد بأن هذا الاسم يطابق هذا المفتاح العام ويوقع هذه الرسالة بمفتاح CA الخاص.
يتيح لك هذا القيام بأشياء مشابهة جدًا لما يفعله Kerberos ، ولكن في نفس الوقت نتخلص من الحاجة إلى العثور على CA عبر الإنترنت لجميع المعاملات. وسيكون في الواقع أكثر قابلية للتطوير. هذا هو بالضبط ما يسمى الشهادة. يتم ضمان قابلية التوسع من خلال حقيقة أنه بالنسبة للعميل أو أي شخص آخر يستخدم هذا النظام ، فإن الشهادة المقدمة من مصدر واحد ليست أدنى من شهادة من أي مصدر آخر. تم توقيعه بواسطة المفتاح السري لمرجع التصديق. لذا يمكنك التحقق من أصالته دون الحاجة فعليًا إلى الاتصال بمرجع التصديق أو أي طرف آخر مدرج هنا.
يعمل هكذا. الخادم الذي تريد التحدث إليه يخزن الشهادة التي حصل عليها في الأصل من المرجع المصدق. وفي كل مرة تتصل بها ، يخبرك الخادم: "حسنًا ، ها هي شهادتي. تم التوقيع عليه من قبل هذا المرجع المصدق. يمكنك التحقق من التوقيع والتأكد من أنه مفتاحي العام وأنه اسمي ".
من ناحية أخرى ، يحدث نفس الشيء مع شهادات العميل. عندما يتصل مستخدم بخادم الويب ، تشير شهادة العميل الخاصة به إلى أن المفتاح العمومي الخاص بك يطابق المفتاح السري الذي تم إنشاؤه أصلاً في المستعرض. وبالتالي ، عند الاتصال بالخادم ، ستقدم شهادة موقعة من المرجع المصدق MIT ، والتي تشير إلى أن اسم المستخدم الخاص بك يتوافق مع هذا المفتاح العام. , , , , Athena.
: , ?
: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.
, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.
: ?
: , . , , KDC, . , . , , . , , , . Kerberos, . Kerberos , . , , . , , . , .
, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .
. , CA , , , , - , . , , . - , amazon.com, , - .
, -, , , , . , . «» , , .
, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».
, , , CRL, , web-, CRL. , - , , . , , , , , .
, . , . , . , . , CRL, - .
, ? , . , CRL .
, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .
26:30 دقيقةدورة MIT "أمن أنظمة الكمبيوتر". المحاضرة 14: "SSL و HTTPS" ، الجزء 2النسخة الكاملة من الدورة متاحة هنا .شكرا لك على البقاء معنا. هل تحب مقالاتنا؟ هل تريد رؤية مواد أكثر إثارة للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية به لأصدقائك ،
خصم 30 ٪ لمستخدمي Habr على نظير فريد من خوادم مستوى الدخول التي اخترعناها لك: الحقيقة الكاملة حول VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps من 20 $ أو كيفية تقسيم الخادم؟ (تتوفر الخيارات مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجابايت DDR4).
VPS (KVM) E5-2650 v4 (6 نوى) 10GB DDR4 240GB SSD 1Gbps حتى ديسمبر مجانًا عند الدفع لمدة ستة أشهر ، يمكنك الطلب
هنا .
ديل R730xd أرخص مرتين؟ فقط لدينا
2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV من 249 دولارًا في هولندا والولايات المتحدة! اقرأ عن
كيفية بناء مبنى البنية التحتية الطبقة باستخدام خوادم Dell R730xd E5-2650 v4 بتكلفة 9000 يورو مقابل سنت واحد؟