البحث في الموقع

عندما يتعلق الأمر ببناء نوع معيّنٍ من تطبيقات الويب، فأوّل ما يخطر ببالي هو استخدام ووردبريس! ومن بين المشاريع البرمجية التي عملتُ عليها في السنتين الماضيتين، تطلّب نصفها - على الأقل - إمكانية إدارة حسابات المستخدمين، وهو ما يعني عادةً السماح للمستخدمين بإنشاء حساباتهم، بإدخال بعض البيانات في حقلَي الاسم وعنوان البريد الإلكتروني، ومن ثم ستُرسَل إليهم رسالةٌ بريديةٌ لتفعيل حسابهم بعد إرسال النموذج. توفِّر ووردبريس طريقةً سهلةً لإدارة المستخدمين عبر لوحة التحكم، وإذا كان موقعك تعليميًا أو كنتَ تستعمله مدونةً لك، فلا حاجة إلى إنشاء آليةٍ أخرى لإدارة المستخدمين، لكن إذا كنتَ تبني تطبيقًا متكاملًا، فهنالك طرائق أخرى للتعامل مع حسابات المستخدمين. لنقل مثلًا أنَّ المُصمِّم قد وضع طريقةً معينةً لإدارة الحسابات في الموقع، وإذا أجبرتَ المستخدمين على استخدام لوحة التحكم فستتسبَّب بتخريب تجربة المستخدم، أليس كذلك؟ هنالك طرائقٌ أفضل لتسجيل حسابات المستخدمين وإدارتها بدلًا من استخدام لوحة التحكم التابعة لووردبريس، وسنناقش في هذا الدرس كيفية إنشاء حسابات المستخدمين برمجيًا، وسنلقي نظرةً على النقاط الآتية: الحصول على معلومات المستخدم بصيغةٍ معيّنة، التعرّف على المعلومات اللازمة لإنشاء حساب مستخدم، إنشاء الحساب، التأكد أنَّ شيفرتنا تخضع لمعايير كتابة الشفرات القياسية، وأنها سهلة القراءة والصيانة. لا تقلق، لن يكون هذا الدرس طويلا ومملًّا، أعدك بذلك! إنشاء حسابات مستخدمي ووردبريس يحتاج أحدنا إلى المعلومات الآتية –على الأقل– لإنشاء حساب مستخدم جديد: اسم المستخدم كلمة المرور عنوان البريد الإلكتروني عندما يتعلق الأمر بإنشاء اسم المستخدم، فأنا أفضِّل استخدام البريد الإلكتروني اسمًا للمستخدم لأنني أضمن أنَّه فريد ولن يتكرر مرةً أخرى؛ ولهذا سنستخدمه في هذا الدرس؛ وسنتحدث عن توليد كلمة المرور لاحقًا. أضف إلى ذلك ضرورة افتراض أنَّ البيانات ستأتيك بأيّ صيغة: فربما تكون بصيغة JSON، أو تكون حقولًا مفصولةً بفواصل كما في CSV، وقد تأتي بصيغة XML. بغض النظر عن الصيغة المستعملة، فيجدر بك كتابة الشفرات اللازمة لتفسير تلك المعلومات باستخدام PHP لكي تستطيع التعامل معها لاحقًا. ولتبسيط الشيفرات المعروضة في هذا الدرس، سنفترض وجود تسجيلة Record لمستخدمٍ وحيدٍ مخزنةٌ معلوماته في مصفوفة. هذا لا يعني أنَّ المعلومات ستأتيك مباشرةً على شكل مصفوفة جاهزة، وإنما عليك تحويلها برمجيًا إلى واحدة. أولًا: معلومات المستخدم لنفترض أنَّنا سنضيف شخصًا باسم Meghan إلى نظامنا، ولدينا عنوان بريده الإلكتروني. لكن لا بأس بذلك، فلدينا المعلومات الأساسية التي نريدها: <?php $user_info = array( 'email' => 'meghan@emaildomain.com', 'first_name' => 'Meghan', 'last_name' => 'McFarlin', ); ولنحوِّلها إلى شيءٍ نستطيع من خلاله إنشاء حسابٍ له. ثانيًا: إنشاء الحساب أوّل ما علينا فعله هو التحقق من عدم وجود مستخدم مرتبط بعنوان البريد الإلكتروني نفسه، وإذا حدث ذلك فسنستعمل التعليمة return فقط، لكنك قد ترغب بإظهار رسالة خطأ أو أي نوع من التنبيهات لتخبر المستخدم أنَّك لا تستطيع إنشاء هذا الحساب لوجوده من قبل؛ لكن ذلك خارجٌ عن نطاق هذا الدرس: <?php // التحقق من صحة البريد الإلكتروني الذي أدخله المستخدم وعدم وجوده مسبقًا في قاعدة البيانات $email = $user_info['email']; if ( ! filter_var( $email, FILTER_VALIDATE_EMAIL ) || username_exists( $email ) ) { return; } لنفترض في هذا الدرس أنَّ المستخدم غير موجود، وعلينا إنشاء حساب له؛ ولفعل ذلك سنحتاج إلى عنوان البريد الإلكتروني إضافةً إلى كلمة مرور؛ ولحسن الحظ، توليد كلمات المرور سهلٌ جدًا: <?php $password = wp_generate_password( 16, false ); لنأخذ البريد الإلكتروني الذي أدخله المستخدم وكلمة المرور التي ولّدناها ولنُنشِئ الحساب: <?php // الحصول على البريد الإلكتروني وتوليد كلمة المرور $email = $user_info['email']; $password = wp_generate_password( 12, false ); // إنشاء حساب المستخدم $user_id = wp_create_user( $email, $password, $email ); // ضبط امتيازات أو دور المستخدم $user = new \WP_User( $user_id ); $user->set_role( 'author' ); لاحظ في الشيفرة السابقة أننا ضبطنا دور المستخدم (role)، وذلك عبر الحصول على نسخةٍ من الصنف Wp_User ثم استخدام مُعرِّف المستخدم المُخزَّن في المتغير ‎$user_id لضبط الدور الخاص به. استخدمتُ دور الكاتب Author في المثال السابق، لكن هنالك أدوار ووردبريس أخرى يمكنك اختيار أحدها. ثالثًا: ألا توجد خطواتٌ أخرى؟! أصبح حساب المستخدم جاهزًا عند هذه المرحلة؛ دعني أذكِّرُكَ أنَّ جزءًا كبيرًا من عملية إنشاء المستخدم متعلقٌ بكيفية استقبال البيانات، ومن ثم معالجتها، والطريقة التي تسمح بها لمدير الموقع بإنشاء الحسابات. هذه الأمور مهمة، لكنني وعدتُكَ أن أبقي هذا الدرس قصيرًا ومركَّزًا، وتلك الأمور ترتبط ارتباطًا وثيقًا بشكل موقعك وتجربة المستخدم فيه، أي أنها تختلف من موقعٍ لآخر. الخلاصة لقد تعلمنا في هذا الدرس طريقة إنشاء مستخدمي ووردبريس برمجيًا، عبر تجربتنا لذلك على حساب مستخدمٍ واحد. إذا أردتَ إنشاء مستخدمين عدّة، فعليك إنشاء مصفوفات فيها معلومات المستخدمين، والتي تستطيع الدوران عليها عبر حلقة تكرار وتُنشِئ الحسابات كما فعلنا في هذا الدرس. ترجمة –وبتصرّف– للمقال Programmatically Creating WordPress Users لصاحبه Tom McFrlin. حقوق الصورة البارزة محفوظة لـ Freepik

لقد شاع استخدام الاقتباس التالي (وأحيانًا بطريقة خاطئة) لهنري فورد، وقد اتضح مؤخّرًا أن هنري فورد لم يقل هذه الكلمات أصلاً، لكنني لحسن الحظ لا أكتب بحثًا أكاديميًا، وإنما أكتب مقالاً، لذا، بغض النظر عن دقة المعلومات التاريخية، أظن أنكم تتفقون معي حيال كون هذا الاقتباس محفزًا للعديد من الأفكار. وإليكم اقتباسًا آخر، هذه المرة من ستيف جوبز: لقد عرف ستيف جوبز بوضوح أن المستخدم ليس على حق دائمًا. لا يعرف المستخدمون ما هو مناسب لهم كما ترى، لقد عرف كل من ستيف جوبز وهنري فورد درسًا بالغ الأهميّة. درسٌ لم يفهمه الكثير من المصمّمين، الباحثين ورجال الأعمال: لا يعرف الزبون والعميل ما هو جيّد له. ولا أتحدث هنا عن أمور ابتكار المنتجات والخدمات الجديدة، أنا أتحدث بصفة عامة. لا يعرف المستخدمون ما هو جيّد بالنسبة لهم ببساطة وحسب، نعم، لقد سمعت ذلك بوضوح. ليس المستخدم على حقٍ دائمًا، في الواقع، غالبًا ما يكون المستخدم مخطئًا بكل بساطة. بالطبع، ليس ذلك خطأ المستخدم. فكيف نتوقع من المستخدمين أن يكونوا على صواب مع ضيق أفقهم ومحدوديته في نظرتهم السطحية للأمور وآرائهم الفردية حيال مشكلة ما في التصميم؟ لنتوقف عن ممازحة أنفسنا. فالمستخدمون ليسوا مصممين، وفي أغلب الوقت لا يكونون خبراءً في المجال، وحتى لو عرفوا مدخلات ومخرجات الموضوع، سيبقون دائمًا ناقصي الخبرة في تحويل المعرفة بالموضوع إلى حلول تصميم جيدة. مع ذلك، أصادف أحيانًا من يتوقعون أننا سنحتاج فقط إلى سؤال المستخدمين كي يعطونا بأعجوبة كل الأجوبة التي نريدها. سنسأل المستخدمين عمّا يحتاجونه، سنسأل المستخدمين عن المزايا الأهم بالنسبة لهم، سنسأل المستخدمين عن كيفية تنظيم الموقع، سنسأل المستخدمين عمّا يجب وضعه في الصفحة الرئيسية. لنسأل المستخدمين تذكّرني هذه الثقافة الخطرة، ثقافة "لنسأل المستخدمين" بحلقة مميزة من "The Simpsons". أحب أن أستخرج أفضل دروس الحياة من هذه المُسلسل، كنصيحة Homer التي تقول، "إذا لم تنجح من المرة الأولى، استسلم". في إحدى الحلقات يكتشف Homer بأن لديه أخًا غير شقيق يدعى Herb، وصادف أن Herb هو رئيس مصنع Powell motors، مصنع أمريكي كبير، ومع انخفاض مبيعات المصنع، يطلب Herb من Homer أن يساعده في تصميم سيارة للمواطن الأمريكي البسيط، سيارة عادية لزيد وعبيد، من المصمم فلان العادي (أو ربما الأقل من العادي بالنسبة لـ Homer)، ويأمر Herb مصممي سياراته بأن يعطوا زمام تصميم السيارة إلى Homer ويستعملوا كل أفكاره، مهما بلغ جنونها. إنها مريعة لأنها سيارة مصممة بواسطة ولأجل Homer، ولأن من صمّمها ليس مصمّمًا، آمل أن لدى مستخدميك ذوقًا أرقى من ذو Homer (رغم أنني لا أضمن لك ذلك)، لكنني عمومًا أظن بأن هنالك درسًا مهمًا وراء هذه القصة: لا يعرف المستخدمون ما هو أفضل لهم، حتى المستخدمين الخياليين. سيارة Homer - إيضاح لما قد يحدث عندما تتبع اقتراحات المستخدمين اتباعًا أعمى. التصميم ليس مهمة الزبون كما ترى، إنها مسؤولية المصممين. ليس على المستخدمين أن يبدعوا حلولاً مذهلة لتحلّ مشاكلهم. ولا أعني بمسؤولية المصممين فقط من عمله هو التصميم، إنني أعني كامل فريق المنتج. يمكن للمطوّر أن يكون مصمّمًا بقدر ما يمكن لمصمم تجربة الاستخدام أن يكون مصممًا عاديًّا، يمكن للمستخدم من ناحية أخرى أن يكون مصمّمًا سيئًا، وتوقع غير هذا هو مجرّد كسلٍ في التصميم. إن مهمة فهم المستخدمين تعود على المصممين وفريق المنتج مهمة تحديد احتياجاتهم، مشاكلهم، آمالهم، أمنياتهم وأحلامهم، مهمة صنع حلول تصميمٍ أنيقة، مفيدة وسهلة الاستعمال لتلبّي احتياجاتهم تعود تمامًا عليهم، حتى لو لم يدرك المستخدمون حاجتهم لتلك الحلول، كما هو عليه الحال مع سيارة model T وجهاز الـ iPad. التصميم للأطفال كأبٍ لطفلين صغيرين، أرى أن العلاقة بين المصممين والمستخدمين تبدو مشابهة بعض الشيء للعلاقة بين أب وأطفاله (أو طفله). يجب عليك كأب أن تضع أبناءك في المركز. أبناؤك يأتون دومًا في المقام الأول، بدءًا من اتخاذ قرار حيال ما يجب عليك أن تفعله في يوم ماطر ووصولًا إلى التفكير في الطعام الذي يجب عليك أن تشتريه لهذا الأسبوع، كل ما تفعله مرتكز على احتياجات أطفالك. لكن ما يجب عليك ألّا تفعله هو ترك الأطفال ليُخبروك بما يجب عليك فعله لأنهم سيحاولون فعل ذلك، صدّقني سيحاولون! أنت الرئيس بالتأكيد بلا شك، لذلك، أنت العاقل هنا وأنت الأعلم بالأمور (أو على الأقل، هذه هي الصورة التي تحاول إظهارها). وهذه هي الطريقة التي يجب أن تعامل بها المستخدمين. لا أعني بهذا أن الواجب عليك هو معاملة المستخدمين كأطفال (إلا إن كانوا أطفالًا بالفعل)، لكن الواجب عليك هو إمضاء وقتك في محاولة فهمهم، إيجاد ما هو أفضل لهم، أخذهم لأيامٍ من المرح بجانب البحر، وأن لا تتبع إراداتهم اتباعًا أعمى. بالتأكيد، يجب عليك أن تُشرك المستخدمين في عملية التصميم، أن تأخذ آرائهم، تجرّب أفكارهم وتصوّراتهم، اقتراحاتهم وإضافاتهم، دون أن تنسى بأنك خبير التصميم وليسوا هم. أنت من تقود عملية التصميم، وليسوا هم. أود أن أترككم مع هذا الاقتباس الأخير، هذه المرة من Alan Cooper خبير تجربة المُستخدم وأب الـ Visual Basic، وقد أُخذت هذا الاقتباس من محادثة في مؤتمر لـ Microsoft يتحدث فيه Alan عن السبب الذي يجعل من المستخدمين مصدرًا سيّئًا لأخذ لتكوين فكرة عن برنامج ما. إليكم ما قاله Alan Cooper: أظن بأن Alan كان يمزح قليلًا حين قال بأن المستخدمين لا علاقة لهم به، لكنني أرجو أن فكرة Alan قد وصلت إليكم. وبالنسبة لي، لا أخالفه الرأي أبدًا. ترجمة -وبتصرف- للمقال Why the user is not always right لصاحبه Neil Turner.

يجب أن تضع الحماية نصب عينيّك عند تثبيت ونشر واستخدام أي نوع من أنظمة تشغيل الحاسوب؛ وعلى الرغم من أن تثبيتًا حديثًا لأوبنتو هو آمن نسبيًا للاستخدام الفوري على الإنترنت، لكن من المهم أن يكون لديك فهم متوازن لحالة حماية أنظمتك بناءً على طريقة استخدامها بعد «نشرها» (deployment). يزودك هذا الدرس بلمحة عن المواضيع المرتبطة بالحماية المتعلقة بنسخة خادوم أوبنتو 14.04، ويخط الخطوط العريضة للإجراءات التي يمكنك أن تستخدمها لحماية خادومك وشبكتك من أي عدد من التهديدات الأمنية المحتملة. إدارة المستخدمينإدارة المستخدمين هي جزء جوهري في الحفاظ على نظامٍ آمن؛ تقود الإدارة غير الكفء للمستخدمين والامتيازات عادةً إلى إضعاف أمان النظام؛ وبالتالي من الضروري أن تفهم كيف تحميه باستخدام تقنيات إدارة حسابات المستخدمين. أين هو حساب الجذر؟اتخذ مطورو أوبنتو قرارًا واعيًا بتعطيل حساب الجذر الإداري افتراضيًا في جميع حالات تثبيت أوبنتو؛ هذا لا يعني أن حساب الجذر محذوفٌ أو لا يمكن الوصول إليه، حيث أُسنِدَت إليه ببساطة كلمة مرور لا تُطابِق أيّة قيمة؛ أي أنك لا تستطيع الدخول إليه مباشرةً. لكن بدلًا من ذلك، يُحَثّ المستخدمون أن يستخدموا أداةً باسم sudo لتنفيذ مهام إدارة النظام؛ حيث تسمح sudo لمستخدم موثوق بترقية امتيازاته باستخدام كلمة مروره بدلًا من الحاجة لمعرفة كلمة المرور الخاصة بحساب الجذر. هذه الطريقة البسيطة تعطي المسؤولية لجميع أفعال المستخدم، وتمنح مدير النظام تحكمًا بالأفعال التي يستطيع القيام بها مع امتيازاته الحالية. إذا أردت تفعيل حساب الجذر لسبب ما، فببساطة أسند كلمة مرور لذاك الحساب: sudo passwdستطلب منك أداة sudo كلمة مرورك، ثم ستطلب منك توفير كلمة مرور جديدة لحساب الجذر كما هو موضح هنا: [sudo] password for username: (enter your own password) Enter new UNIX password: (enter a new password for root) Retype new UNIX password: (repeat new password for root) passwd: password updated successfullyاستخدم الأمر passwd بهذه الطريقة لتعطيل كلمة مرور حساب الجذر: sudo passwd -l rootلكن إذا أردت تعطيل الحساب نفسه، فاستخدم الأمر الآتي: usermod --expiredate 1تستطيع التعلم أكثر عن sudo بالنظر إلى صفحة الدليل المتعلقة بهذا الأمر: man sudoينتمي المستخدم الذي أُنشِئ أثناء تثبيت أوبنتو افتراضيًا إلى المجموعة «sudo» المُضافة إلى ملف ‎/etc/sudoers كمستخدم sudo موثوق؛ إذا رغبت بمنح أيّ حساب آخر امتيازات الجذر كاملةً عبر sudo، فأضف ذاك الحساب إلى المجموعة sudo. إضافة وحذف المستخدمينعملية إدارة المستخدمين المحليين والمجموعات هي عملية بسيطة ومباشرة ولا تختلف إلا قليلًا بين أغلبية أنظمة تشغيل غنو/لينُكس الأخرى؛ تحث أوبنتو، والتوزيعات المبنية على دبيان، على استخدام الحزمة «adduser» لإدارة الحسابات. لإضافة حساب مستخدم جديد، استخدم الشكل العام الآتي، وأكمل مع الرسائل التي تطلب منك إعطاء كلمة مرور للحساب، وتعريف بعض الخاصيات مثل الاسم الكامل ورقم الهاتف ...إلخ. sudo adduser usernameاستخدم الأمر الآتي لحذف مستخدم ومجموعته الرئيسية: sudo deluser usernameلا يؤدي حذف حساب مستخدم إلى حذف مجلد المنزل الموافق له؛ هذا يعود لك إن كنت تريد أو لا تريد حذف المجلد يدويًا أو الإبقاء عليه وفقًا لسياساتك. تذكر أن أي مستخدم آخر يُضاف لاحقًا بنفس معرفَيّ UID/GID للمستخدم القديم سيحصل على وصول كامل لهذا المجلد إذا لم تتخذ الاحتياطات اللازمة. قد ترغب بتغيير قيم UID/GID إلى قيم أخرى ملائمة أكثر -كحساب الجذر مثلًا- وربما تريد أيضًا نقل المجلد لتفادي التضاربات المستقبلية: sudo chown -R root:root /home/username/ sudo mkdir /home/archived_users/ sudo mv /home/username /home/archived_users/لكي تقفل حساب مستخدم مؤقتًا أو تلغي قفله، فاستخدم الأمر passwd مع الخيارات الموافقة للعملية التي تريد إجراءها كما يلي (على التوالي وبالترتيب): sudo passwd -l username sudo passwd -u usernameلإضافة أو حذف مجموعة خاصة، فاستخدم الأمرين الآتيين على التوالي وبالترتيب: sudo addgroup groupname sudo delgroup groupnameاستخدم الشكل الآتي من أمر adduser لإضافة مستخدم إلى مجموعة: sudo adduser username groupnameأمن حساب المستخدمعندما يُنشأ مستخدمٌ جديد، فستُنشِئ الأداة adduser مجلد منزل جديد باسم ‎/home/username، يتشكل ملف الحساب (profile) الافتراضي اعتمادًا على المحتويات الموجودة في مجلد ‎/etc/skel الذي يحتوي على أساسيات ضبط الحساب. إذا كان سيحتوي خادومك على عدّة مستخدمين، فيجب أن تولي أذونات مجلد المنزل للمستخدم اهتمامًا شديدًا لتحقيق سرية بياناته؛ افتراضيًّا، مجلدات منزل المستخدم في أوبنتو تُنشَأ بأذونات القراءة والتنفيذ؛ هذا يعني أن كل المستخدمين يستطيعون الوصول والتجول في محتويات مجلدات المنزل للمستخدمين الآخرين، ربما لا يلائم ذلك احتياجات بيئة تشغيل نظامك. استخدم الأمر الآتي للتأكد من أذونات مجلد المنزل للمستخدمين الحاليين: ls -ld /home/usernameيُظهِر الناتج الآتي أن مجلد ‎/home/username لديه أذن القراءة لجميع المستخدمين (العالم أو world): drwxr-xr-x 2 username username 4096 2007-10-02 20:03 usernameتستطيع إزالة أذن القراءة للجميع بتنفيذ الأمر: sudo chmod 0750 /home/usernameملاحظة: بعض الأشخاص يميلون لاستخدام الخيار التعاودي (‎-R‏ [recursive]) دومًا دون تمييز الحالات التي يجب استخدامه فيها، الذي يُعدِّل أذونات المجلدات «الأبناء» والملفات التي فيها، لكن هذا ليس ضروريًا، وربما يتسبب ببعض النتائج غير المرغوب بها؛ يكفي تعديل أذونات المجلد «الأب» فقط لمنع المستخدمين غير المصرَّح لهم بدخول أي شيء داخل هذا المجلد الأب. طريقة أخرى أكثر فعاليةً هي تعديل ضبط الأذونات الافتراضية العام للأداة adduser عند إنشاء مجلدات المنزل للمستخدمين الجدد؛ عدِّل ببساطة الملف ‎/etc/adduser.conf وغيِّر قيمة المتغير DIR_MODE إلى قيمةٍ مناسبةٍ، حيث ستحصل جميع مجلدات المنزل الجديدة على الأذونات الصحيحة: DIR_MODE=0750بعد تصحيح أذونات المجلد باستخدام إحدى الطرق السابق ذكرها، فتأكد من النتائج بالأمر: ls -ld /home/usernameالنتائج الآتية تُظهِر أنه قد أُزيل إذن القراءة لجميع المستخدمين: drwxr-x--- 2 username username 4096 2007-10-02 20:03 usernameسياسة كلمة المرورأحد أهم الجوانب في حماية نظامك هو استخدام سياسة قوية لكلمات المرور؛ إذ تتطلب العديد من الاختراقات الأمنية الناجحة استخدام هجمات «القوة القاسية» (brute force) وتخمين كلمات المرور الضعيفة من القاموس؛ إذا كنت تنوي توفير أي نوع من التحكم البعيد الذي يتطلب كلمة المرور المحلية للنظام، فتأكد أنك تحقق المتطلبات الدنيا من تعقيد كلمات المرور، ومدة كلمة المرور الدنيا، والتدقيق الرتيب لأنظمة الاستيثاق عندك. طول كلمة المرور الدنياتتطلب أوبنتو افتراضيًا طولًا أصغريًا لكلمة المرور يساوي ستة محارف، يمكن التحكم بهذه القيمة في ملف ‎/etc/pam.d/common-password الظاهر هنا: password [success=2 default=ignore] pam_unix.so obscure sha512إذا أردت تغيير الحد الأدنى لطول كملة المرور إلى ثمانية محارف، فعدِّل المتغير الملائم إلى min=8؛ كما يلي: password [success=2 default=ignore] pam_unix.so obscure sha512 min=8ملاحظة: التحقق البسيط من كلمة المرور، والطول الأدنى لها لا يُطبَّق على الأوامر المُنفَّذة باستخدام sudo لإعداد مستخدم جديد. مدة صلاحية كلمة المرورعند إنشاء حسابات للمستخدمين، فيجب أن تُنشِئ سياسة لعمر كلمة المرور الأدنى والأقصى وإجبار المستخدمين على تغيير كلمات مرورهم عندما تنتهي مدتها. استخدم الأمر الآتي لعرض حالة حساب مستخدم: sudo chage -l usernameيُظهِر ناتج الأمر السابق حقائق مثيرة للاهتمام حول حساب المستخدم، ولنفترض أنه لا توجد أيّة سياسات مطبَّقة: Last password change : Jan 20, 2008 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7استخدم الأمر الآتي ببساطة وتابع مع الرسائل التفاعلية لضبط أيّة قيمة من هذه القيم: sudo chage usernameما يلي مثالٌ لطريقة تغيير تاريخ انتهاء الصلاحية (‎-E) إلى 01/31/2008، والعمر الأدنى لكلمة المرور (‎-m) إلى 5 أيام، والعمر الأقصى لكلمة المرور (‎-M) إلى 90 يومًا، ومدة الخمول (inactivity، الخيار ‎-I) إلى 5 أيام بعد انتهاء صلاحية كلمة المرور، ومدة وقت التحذير (‎-W) إلى 14 يومًا قبل انتهاء صلاحية كلمة المرور. sudo chage -E 01/31/2008 -m 5 -M 90 -I 5 -W 14 usernameللتأكد من التعديلات، استخدم نفس الأمر المذكور آنفًا: sudo chage -l usernameيجب أن يُظهِر الناتج السياسات الجديدة التي أعددناها لهذا الحساب: Last password change : Jan 20, 2008 Password expires : Apr 19, 2008 Password inactive : May 19, 2008 Account expires : Jan 31, 2008 Minimum number of days between password change : 5 Maximum number of days between password change : 90 Number of days of warning before password expires : 14اعتبارات أمنية أخرىتستخدم العديد من التطبيقات آليات استيثاق أخرى يمكن أن يغفلها حتى مدراء الأنظمة الخبراء؛ وبالتالي فمن المهم فهم والتحكم في طريقة استيثاق المستخدمين وحصولهم على الوصول إلى الخدمات والتطبيقات على خادومك. وصول SSH من المستخدمين المعطلينلا يمنع تعطيل حساب مستخدم من دخوله إلى خادومك عن بعد إن كان قد ضبط استيثاق بمفتاح RSA عام؛ وسيتمكنون من الحصول على وصول إلى الصدفة (shell) في الخادوم دون الحاجة لأيّة كلمة مرور؛ تذكر أن تتحقق من مجلد المنزل للمستخدمين الذي يسمحون بهذا النوع من وصول SSH الذي تم الاستيثاق منه؛ أي ‎/home/username/.ssh/authroized_keys. احذف أو أعد تسمية مجلد ‎.ssh/‎ في مجلد المنزل للمستخدم لتعطيل إمكانيات الاستيثاق عبر SSH. تأكد أن تتحقق من أيّة اتصالات SSH قد أُنشِئت من المستخدم المعطَّل؛ حيث من الممكن أن يملكوا اتصالات داخلة أو خارجة موجودة مسبقًا، «اقتل» (kill) تلك العمليات إذا عثرت عليها. who | grep username # to get the pts/X terminal sudo pkill -f pts/Xاحصر الوصول عبر SSH إلى حسابات المستخدمين الذين يجب أن يحصلوا عليها فقط؛ فعلى سبيل المثال، ربما تنُشِئ مجموعة تسميها «sshlogin» وتضيف اسم المجموعة كقيمة مرتبطة بالمتغير AllowGroups الموجود في الملف ‎/etc/ssh/sshd_config. AllowGroups sshloginثم أضف مستخدمي SSH المسموح لهم إلى المجموعة «sshlogin»، وأعد تشغيل خدمة SSH: sudo adduser username sshlogin sudo service ssh restartاستيثاق المستخدم بقواعد البيانات الخارجيةتتطلب معظم الشبكات المشاريع التجارية آليةَ استيثاقٍ مركزية والتحكم بالوصول إلى جميع مصادر النظام، إذا ضبطت خادومك ليستوثق من المستخدمين من قاعدة بيانات خارجية؛ فتأكد من تعطيل حسابات المستخدمين محليًا وخارجيًا، وبهذا تتأكد من أن البديل المحلي للاستيثاق غير متوفر. تأمين الطرفيةوكما غيرها من ترسانة الحماية التي تستخدمها لحماية خادومك، من القواعد الصارمة هو التأمين ضد الأضرار الناتجة عن شخص لديه الوصول الفيزيائي لبيئتك، على سبيل المثال، سرقة الأقراص الصلبة، أو خلل في الطاقة الكهربائية ...إلخ؛ وبالتالي يجب أن يكون تأمين الطرفية جزءًا رئيسيًا في استراتيجية الحماية الفيزيائية؛ سيحد «قفل الشاشة» (screen door) من تأثير مجرم عادي، أو على الأقل سيبطئ عمل مجرم مصمم على إلحاق الأذى بنظامك! لذلك من المستحسن إجراء بعض احتياطات الوقاية فيما يتعلق بحماية الطرفية. سيساعدك ما يلي في الدفاع عن خادومك ضد المشاكل التي قد تسبب عواقب وخيمة. تعطيل Ctrl+Alt+Deleteبادئ ذي بدء، يستطيع أي شخص لديه الوصول الفيزيائي للوحة المفاتيح ببساطة أن يستخدم تجميعة المفاتيح «Ctrl+Alt+Delete» لإعادة إقلاع الخادوم دون الحاجة لتسجيل الدخول؛ طبعًا يمكن لأي شخص إزالة كبل الكهرباء من المقبس، لكن ما يزال عليك منع استخدام هذه التجميعة على خادوم إنتاجي؛ وهذا يجبر المهاجم على اتخاذ إجراءات عنيفة لإعادة إقلاع الخادوم، وسوف يمنع إعادة الإقلاع غير المقصودة في نفس الوقت. لتعطيل إعادة إقلاع الخادوم بالضغط على تجميع الأزرار Ctrl+Alt+Delete، فضع رمز التعليق قبل السطر الآتي في ملف ‎/etc/init/control-alt-delete.conf: #exec shutdown -r now "Control-Alt-Delete pressed"ترجمة -وبتصرف- للمقال Ubuntu Server Guide: User Management.