تسجيل SSH وإدارة الجلسة باستخدام AWS SSM

يمكن أن يكون إعداد أدوات أو نصوص مخصصة للاحتفاظ بسجل SSH على Linux أمرًا مملًا وعرضة للخطأ.

يمكن للمهندسين استخدام rootsh أو الشاشة أو أداة مساعدة أخرى لتسجيل نشاط المستخدم ولكن إذا لم يتم تعيين أذونات المستخدم بشكل صحيح ، يمكن للمستخدم الماهر محو سجلات التدقيق لتغطية مساراتهم. قد يكون الخيار الآخر هو إعداد التسجيل على مستوى النواة ، لكن الخبرة اللازمة لذلك ليست شائعة جدًا.

لحسن الحظ ، هناك طريقة لتسجيل نشاط المستخدم دون كتابة أمر Linux واحد! سنحتاج هذه الخدمات:

• EC2
• IAM (إدارة الهوية والوصول)
• KMS (خدمة إدارة المفاتيح)
• سجلات CloudWatch (و / أو S3)
• AWS Systems Manager (المعروف سابقًا باسم SSM)

دعونا نرى كيفية إعداد كل منهم.

EC2 و IAM

عادةً ما يكون بدء تشغيل مثيل EC2 أمرًا سهلاً إلى حد ما ، ولكن هناك مهمة رئيسية واحدة يجب القيام بها أثناء الإطلاق: نحتاج إلى إرفاق دور IAM بمثيلنا ، وإلا فلن نتمكن من تحقيق النتائج المتوقعة المفصلة في نهاية هذا شرط.

يجب أن يكون لدور IAM الذي نربطه بمثيل EC2 الخاص بنا سياسة AmazonSSManagedInstanceCore المضمنة ، بالإضافة إلى هذه السياسة (المرفقة على أنها مضمنة أو يديرها العميل):

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

بصرف النظر عن دور IAM ، نستخدم بشكل عام تكوين مثيل EC2 هذا:

• نظام التشغيل هو Amazon Linux 2 ، لأنه يأتي مع AWS Systems Manager Agent (SSM Agent) بشكل افتراضي. (وكذلك توزيعات Ubuntu ، والتي تعد أيضًا خيارًا).
• نوع المثيل هو t3.micro (لكن أي نوع سيفي بالغرض).
• ستعمل مجموعة الأمان الافتراضية التي تعيّنها AWS إلى VPC ، لأننا لا نحتاج إلى فتح منفذ SSH لهذا التمرين.

يمكننا البدء في إعداد KMS دون انتظار تشغيل مثيل EC2.

KMS

نحتاج إلى مفتاح KMS إذا أردنا تخزين جميع سجلات الجلسات التي يتم تسليمها إلى CloudWatch بشكل مشفر. دعنا نتوجه إلى خدمة KMS وننشئ مفتاحًا.

نوصي بتعيين مسؤول بحيث يمكن إدارة المفتاح بواسطة مستخدمين بخلاف المستخدم الجذر لحساب AWS ، ولكن إذا لم يحتاج الآخرون إلى الوصول ، فيمكننا تخطي الخطوة 3.

هنا اخترنا "admin" مستخدم IAM كمسؤول رئيسي ، لكننا أحرار في اختيار أي مستخدم أو دور. يمكننا أيضًا اختيار تعطيل إذن حذف المفتاح للمسؤول.

لن نقوم بتعيين أي مستخدمين لهذا المفتاح لأننا نريد أن يتم استخدام هذا المفتاح فقط بواسطة خدمة CloudWatch Logs لعمليات تشفير وفك تشفير سجل SSH.

في صفحة المراجعة ، سنحتاج إلى تغيير سياسة المفاتيح التي تم إنشاؤها بواسطة KMS لأنها لا تتضمن أذونات لـ CloudWatch Logs لاستخدام المفتاح. سنقوم باستبدالها بهذه السياسة:

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

تأكد من استبدال جميع العناصر النائبة:

• يصبح ACCOUNT_ID معرّف حساب AWS الخاص بنا.
• يصبح USERNAME هو اسم مستخدم المسؤول المحدد في الخطوة 3. إذا اخترنا عدم المشاركة في هذه الخطوة ، فنحن هنا نزيل كتلة العبارة الثانية (التي تحتوي على "Sid": "Allow access for Key Administrators" ).
• تصبح REGION رمز المعرف الإقليمي الذي ننشر الخدمات إليه (على سبيل المثال ، us-west-1 ).

مع ذلك ، KMS جاهز للذهاب.

مجموعة سجل CloudWatch

بعد ذلك ، نحتاج إلى مجموعة CloudWatch Log (و / أو حاوية S3 - انظر أدناه) حيث يمكن لوكيل SSM إرسال سجلات جلسة SSH. دعونا ننشئه.

لاحظ حقل ARN الخاص بمفتاح KMS: تزودنا AWS بالقيمة المطلوبة هنا بعد إنشاء المفتاح في الخطوة 5 من قسم KMS.

(إذا لم نقم بربط السياسة الصحيحة بمفتاح KMS الخاص بنا سابقًا ، مما يسمح لخدمة CloudWatch Logs باستخدام المفتاح ، فسوف نتلقى خطأً متعلقًا بمفتاح KMS في هذه المرحلة.)

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

الآن بعد أن أعددنا مكانًا ما لتخزين السجلات - سجلات CloudWatch أو حاوية S3 أو كليهما - نحن مستعدون للاستفادة من جلسات SSH.

AWS Systems Manager Session Manager

هذه هي الخطوة الأساسية الأخيرة ، حيث نقوم بتهيئة الوصول الآمن إلى جهاز Linux الخاص بنا لمراقبة جلسة SSH وتسجيلها. سنبدأ من لوحة معلومات مدير الجلسة.

في لوحة القيادة ، انقر على الزر الأبيض "تكوين التفضيلات" في أعلى يمين مربع "بدء جلسة" لتمكين تسجيل الجلسة.

في صفحة التفضيلات ، سنجد أقسامًا متعددة يمكننا استكشافها ، ولكن سينصب تركيزنا على دفق سجلات جلسة SSH إلى CloudWatch أو S3 للسماح لنا برؤية ما يحدث بسرعة داخل جهاز Linux الخاص بنا.

بعد قسم "تسجيل CloudWatch" ، يوجد قسم "تسجيل S3" حيث يمكننا تحديد الحاوية.

بمجرد تكوين SSH logging ، يمكننا SSH في جهاز Linux الخاص بنا وتنفيذ بعض الأوامر لمعرفة ما إذا كان يتم التقاط النشاط أم لا.

لذا ، لنبدأ جلسة. في نفس الصفحة ، سنجد علامة تبويب "الجلسات" حيث يمكننا بدء الجلسة. سيؤدي النقر فوق الزر "بدء الجلسة" إلى منحنا قائمة بأجهزة EC2 التي يمكننا من خلالها بدء جلسة:

إذا لم نرى مثيل EC2 Linux الخاص بنا في القائمة ، فيجب علينا التحقق مما إذا كان في حالة تشغيل ولديه أذونات IAM المرتبطة به التي وصفناها سابقًا.

التعامل مع وكيل SSM خطأ "لا يدعم سجلات البث"

في حال تلقينا خطأً يفيد بأن إصدار وكيل SSM المثبت على جهاز EC2 الخاص بنا لا يدعم تدفق سجلات CloudWatch ، فلا داعي للقلق. هناك طريقة غير مؤلمة لإصلاح هذا.

لتحديث وكيل SSM ، نحتاج إلى الانتقال إلى Run Command في اللوحة اليمنى لخدمة AWS Systems Manager .

بمجرد أن نكون هناك ، يمكننا النقر فوق الزر البرتقالي "تشغيل أمر" ، مما يؤدي إلى صفحة جديدة حيث يمكننا ملء بعض المعلمات.

سنبدأ بتحديد AWS-UpdateSSMAgent من القائمة.

بمجرد تحديد ذلك ، سنقوم بالتمرير لأسفل حتى نرى قسم "الأهداف". هناك نحتاج إلى تحديد مثيل EC2 الذي نريد تحديث عامل SSM عليه ، ثم الضغط على زر "تشغيل" في النهاية. سيرسلنا هذا إلى صفحة يمكننا من خلالها مراقبة تقدم التحديث.

يجب ألا يستغرق تحديث الوكيل أكثر من خمس دقائق. بمجرد الانتهاء من ذلك ، يجب أن نكون قادرين على إنشاء جلسة مرة أخرى في مدير الجلسة.

في هذه المرحلة ، يجب أن تبدأ جلسة SSH.

بعد تنفيذ بعض الأوامر ، دعنا ننتقل إلى مجموعة سجلات CloudWatch Logs (أو حاوية S3 الخاصة بنا ، غير معروضة) وتأكد من تسجيل النشاط.

لدينا الآن إعداد ، مع تمكين التشفير أثناء الراحة ، وتسجيل كل أمر يتم إطلاقه في جهاز Linux الخاص بنا.

في الواقع ، قد يكون كل أمر أكثر مما نريد: سيتم تسجيل أي أسرار يتم تقديمها أو إنشاؤها أثناء الجلسة في CloudWatch أو S3 ويمكن رؤيتها من قبل أي شخص لديه الأذونات المطلوبة. لمنع ذلك ، يمكننا استخدام stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; لكل سر نحتاج إلى تقديمه خلال الجلسة.

حل تسجيل AWS رائع لـ SSM / SSH مع تحذيرات بسيطة

يُعد Session Manager أداة مفيدة للوصول عن بُعد إلى أجهزتنا الافتراضية في AWS دون الحاجة إلى فتح المنفذ 22. في الواقع ، لا يمكننا إنشاء سجلات SSH بهذه الطريقة إذا استخدمنا إعادة توجيه المنفذ أو اتصال SSH المباشر ، كمدير الجلسة ملاحظات التوثيق.

ومع ذلك ، فإن الجمع بين مدير الجلسة وتسجيل الجلسة هو حل قوي للتحكم في النشاط ومراقبته داخل الأجهزة الافتراضية. علاوة على ذلك ، نحن لسنا مسؤولين عن استخدام خدمة مدير الجلسة. نحن ندفع فقط مقابل مثيل EC2 وسجلات CloudWatch أو حاوية S3 لتخزين السجلات.

بالنسبة للقراء الذين يفضلون مقاطع الفيديو التعليمية ، فقد قمت بتغطية إجراء مشابه جدًا بشكل أكثر شمولاً على YouTube.

مزيد من القراءة على مدونة Toptal Engineering:

• دراسة حالة: لماذا أستخدم البنية التحتية السحابية لـ AWS لمنتجاتي