تسجيل 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 في هذه المرحلة.)

تخزين سجلات SSH في حاوية S3

لتخزين سجلات النشاط مع S3 بدلاً من – أو بالإضافة إلى – سجلات CloudWatch نحتاج إلى إضافة هذه الأذونات إلى ملف تعريف مثيل EC2 الخاص بنا كسياسة منفصلة (أو دمجها يدويًا مع أذونات أخرى قد نحتاج إلى ربطها):

{
    "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": "*"
        }
    ]
}

في المقتطف أعلاه تأكد من استبدال العنصر النائب BUCKET_NAME

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

AWS Systems Manager Session Manager

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

في لوحة القيادة انقر على الزر الأبيض “configure preferences” في أعلى يمين مربع “start a session” لتمكين تسجيل الجلسة.

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

بعد قسم “cloudwatch logging” يوجد قسم “s3 logging” حيث يمكننا تحديد الحاوية.

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

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

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

التعامل مع وكيل SSM خطأ “doesn’t support streaming logs“

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

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

بمجرد وصولنا إلى هناك يمكننا النقر فوق الزر البرتقالي “run a command” مما يؤدي إلى صفحة جديدة حيث يمكننا ملء بعض المعلمات.

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

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

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

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

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

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

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

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

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

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

المصدر