مجموعات الأمان وأزواج المفاتيح

تُعد security group جدار حماية افتراضيًا ذا حالة يتحكم في حركة المرور الواردة والصادرة إلى مثيل EC2 ومنه، أو إلى موارد AWS الأخرى مثل RDS وLambda وELB ومنها. تعمل Security Groups على مستوى المثيل، إذ تحدد كل قاعدة بروتوكولًا (TCP/UDP/ICMP) ونطاق منافذ ومصدرًا أو وجهةً، مثل نطاق IP أو security group أخرى. وعلى عكس جدران الحماية التقليدية، تكون Security Groups ذات حالة: فإذا سمحت بحركة مرور واردة، يُسمح تلقائيًا بحركة مرور الاستجابة الصادرة دون الحاجة إلى قاعدة صريحة.

لدى Security Groups مجموعات قواعد منفصلة للوارد وللصادر. تتحكم قواعد الوارد في حركة المرور التي تصل إلى المثيل، ويُرفض افتراضيًا كل مرور وارد. وتتحكم قواعد الصادر في حركة المرور التي تغادر المثيل، ويُسمح افتراضيًا بكل المرور الصادر. يمكنك إضافة قواعد Allow صريحة؛ ولا توجد قواعد Deny صريحة في Security Groups، فاستخدم Network ACLs للرفض الصريح. تُقيَّم جميع قواعد security group معًا باستخدام OR منطقي، إذ تسمح أي قاعدة Allow مطابقة بحركة المرور.

تدعم Security Groups مراجع security group للمصدر أو الوجهة، وهي أكثر مرونة وأمانًا من تحديد نطاقات IP. على سبيل المثال، تسمح security group الخاصة بـ ALB بالوصول من 0.0.0.0/0 على المنفذ 443. وتسمح security group الخاصة بمثيلات EC2 بحركة المرور الواردة على المنفذ 8080 من معرّف security group الخاصة بـ ALB فقط، وليس من أي عنوان IP. إذا استُبدل ALB أو تم توسيعه، تظل القاعدة مطبقة بشكل صحيح دون تغييرات في عناوين IP. ينشئ هذا النمط دفاعًا ديناميكيًا متعدد الطبقات للبنى متعددة الطبقات.

تعني خاصية الحالة أن security group تتتبع حالة الاتصال. فإذا سمحت قاعدة الوارد لديك بمنفذ TCP رقم 80 من الإنترنت وأرسل عميل طلبًا، يُسمح تلقائيًا لحزم الاستجابة الصادرة بالعودة إلى العميل، حتى في حال عدم وجود قاعدة صادرة للمنفذ 80. يختلف ذلك جذريًا عن Network ACLs، فهي عديمة الحالة وتتطلب قواعد صريحة لكلا اتجاهي حركة المرور. تجعل خاصية الحالة إعداد Security Groups أسهل لأنماط حركة مرور التطبيقات المعتادة.

يمكنك إرفاق عدة Security Groups بمثيل EC2 واحد، حتى 5 افتراضيًا مع إمكانية التعديل. تُدمج قواعد جميع Security Groups المرفقة باستخدام الاتحاد، أي منطق OR، فإذا سمحت أي security group بطلب ما، يُسمح بالطلب. وهذا يعني أن Security Groups يمكنها فقط إضافة الأذونات ولا يمكنها تقييدها أبدًا. إذا أردت تشديد الوصول، يجب إزالة القواعد أو تعديلها، وليس إضافة security group أكثر تقييدًا. ضع هذا السلوك التراكمي في اعتبارك عند الإجابة عن أسئلة الاختبار المتعلقة بتقييد الوصول.

تتضمن كل VPC security group افتراضية. قواعدها الافتراضية هي: يسمح الوارد بكل حركة المرور من المثيلات الأخرى الموجودة أيضًا في security group الافتراضية، ويسمح الصادر بكل حركة المرور إلى أي مكان. هذه الإعدادات متساهلة عمدًا كي تتمكن المثيلات الجديدة من الاتصال افتراضيًا. في بيئات الإنتاج، أنشئ security group مخصصة بقواعد وارد مقيدة، وأزل ارتباطات المثيلات بـ security group الافتراضية لتجنب التعرض غير المقصود.

تستخدم key pairs في EC2 التشفير غير المتماثل لمصادقة SSH. تنشئ AWS زوج المفاتيح، أو تستورد مفتاحك العام بنفسك: تحتفظ AWS بـ المفتاح العام وتحقنه في المثيل عند التشغيل، بينما تنزّل المفتاح الخاص وتخزنه، وهو ملف .pem، ولا تحتفظ AWS به أبدًا. يستخدم SSH المفتاح الخاص لإثبات هويتك للخادم من دون إرسال كلمة مرور. يجب أن تكون للمفتاح الخاص أذونات مقيدة (chmod 400) وإلا فسيرفض SSH استخدامه.

إذا فقدت المفتاح الخاص لمثيل Linux EC2، فلن تتمكن من الاتصال عبر SSH بالطريقة المعتادة. تشمل خيارات الاستعادة: Systems Manager Session Manager، إذا كان وكيل SSM يعمل وكان دور IAM مرفقًا، ولا يحتاج إلى مفتاح؛ وEC2 Instance Connect، الذي يحقن مفتاحًا مؤقتًا عبر المتصفح أو CLI ويتطلب منفذ SSH مفتوحًا وأذونات EIC؛ أو إيقاف المثيل، وفصل وحدة تخزين EBS الجذرية، وإرفاقها بمثيل آخر، وتعديل ملف authorized_keys، ثم إعادة إرفاقها وإعادة التشغيل. بالنسبة إلى Windows، استخدم Systems Manager لاسترداد كلمة المرور.

إن ترك SSH، المنفذ 22، مفتوحًا أمام 0.0.0.0/0 يعرّض مثيلك لهجمات القوة الغاشمة وحشو بيانات الاعتماد من أي مكان على الإنترنت. من أفضل الممارسات: تقييد SSH على نطاق IP المؤسسي المحدد لديك، أو استخدام bastion host، أي jump box، في شبكة فرعية عامة مع security group مضبوطة بإحكام، ثم الاتصال عبر SSH من bastion إلى المثيلات الخاصة. والأفضل من ذلك استخدام Systems Manager Session Manager لإلغاء تعريض منفذ SSH بالكامل، فلا تحتاج إلى أي قواعد وارد على الإطلاق.

من الحدود الافتراضية المهمة لـ Security Groups، والقابلة للتعديل عبر Service Quotas: ما يصل إلى 2,500 security group لكل VPC، و60 قاعدة وارد و60 قاعدة صادر لكل security group، و5 Security Groups لكل واجهة شبكة. عند الإشارة إلى security group أخرى كمصدر، يُحتسب كل اقتران بين security group المُشار إليها والقاعدة كقاعدة واحدة. إذا وصلت إلى حدود القواعد، فاجمعها عبر الإشارة إلى معرّفات Security Groups بدلًا من نطاقات IP الفردية، أو استخدم prefix lists لتجميع عدة CIDRs في كيان واحد يسهل إدارته.

تُعد managed prefix list مجموعة من كتل CIDR يمكنك الإشارة إليها في قواعد security group أو جداول التوجيه. تحتفظ AWS بـ AWS-managed prefix lists لخدمات مثل S3 وCloudFront، بحيث يمكنك السماح بحركة المرور إلى هذه الخدمات ومنها من دون إدارة نطاقات IP بنفسك، والتي تتغير مع الوقت. يمكنك أيضًا إنشاء customer-managed prefix lists لتجميع نطاقات IP المؤسسية لديك، فتحدّث prefix list في مكان واحد وترث جميع Security Groups التي تشير إليها التغيير تلقائيًا.

اختبر فهمك لمفاهيم AWS Solutions Architect ‏(SAA-C03) من هذا الدرس.

تعلمت في هذا الدرس أن Security Groups هي جدران حماية افتراضية ذات حالة تسمح بحركة المرور وفق قواعدها وتمنعها افتراضيًا، وأن ربط Security Groups بالمعرّف أكثر أمانًا ومرونة من استخدام نطاقات IP، وأن key pairs توفر مصادقة SSH غير متماثلة، بينما يلغي Systems Manager Session Manager الحاجة إلى منافذ SSH المفتوحة. سنتناول بعد ذلك خيارات تخزين EC2: Instance Store مقابل EBS.