ثبت SSH و مدیریت جلسه با استفاده از AWS SSM

راه اندازی ابزارها یا اسکریپت های سفارشی برای نگه داشتن گزارش SSH در لینوکس می تواند خسته کننده و مستعد خطا باشد.

مهندسان می توانند استفاده کنند ریشه یابی، صفحه نمایش، یا ابزار دیگری برای ثبت فعالیت کاربر، اما اگر مجوزهای کاربر به درستی تنظیم نشده باشد، یک کاربر ماهر می تواند گزارش های حسابرسی را پاک کند تا مسیرهای خود را پوشش دهد. یکی دیگر از گزینه ها، راه اندازی ورود به سیستم در سطح هسته است، اما تخصص مورد نیاز برای آن چندان رایج نیست.

خوشبختانه، راهی برای ثبت فعالیت کاربر بدون نوشتن حتی یک دستور لینوکس وجود دارد! ما به این خدمات نیاز خواهیم داشت:

بیایید ببینیم که چگونه هر یک از آنها را تنظیم کنیم.

EC2 و IAM

راه‌اندازی یک نمونه EC2 معمولاً نسبتاً آسان است، اما یک کار کلیدی وجود دارد که باید در حین راه‌اندازی انجام شود: ما باید یک نقش IAM را به نمونه خود اضافه کنیم، در غیر این صورت نمی‌توانیم به نتایج مورد انتظار که در پایان این مقاله توضیح داده شده است برسیم. مقاله.

نقش IAM که ما با نمونه EC2 خود مرتبط می‌کنیم باید داخلی باشد AmazonSSMMmanagedInstanceCore خط مشی، به علاوه این خط مشی (پیوست به صورت خطی یا مدیریت شده توسط مشتری):

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

جدا از نقش IAM، ما معمولاً از این پیکربندی نمونه EC2 استفاده می کنیم:

• را سیستم عامل آمازون لینوکس 2 است، زیرا به طور پیش فرض با AWS Systems Manager Agent (SSM Agent) نصب شده است. (توزیع های اوبونتو نیز که یک گزینه هستند نیز همینطور است.)
• را نوع نمونه t3.micro است (اما هر نوع انجام خواهد داد).
• پیشفرض گروه امنیتی که AWS به VPC اختصاص می دهد، کار خواهد کرد، زیرا برای این تمرین نیازی به یک پورت SSH باز نیست.

می‌توانیم بدون منتظر ماندن برای راه‌اندازی نمونه EC2، راه‌اندازی KMS را شروع کنیم.

KMS

اگر می‌خواهیم تمام گزارش‌های جلسه تحویل داده شده به CloudWatch به صورت رمزگذاری شده ذخیره شوند، به یک کلید KMS نیاز داریم. بیایید به سرویس KMS برویم و یک کلید ایجاد کنیم.

توصیه می‌کنیم یک سرپرست اختصاص دهید تا کلید توسط کاربرانی غیر از کاربر اصلی حساب AWS مدیریت شود، اما اگر دیگران نیازی به دسترسی ندارند، می‌توانیم مرحله 3 را نادیده بگیریم.

در اینجا ما “مدیر” کاربر 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 Log Group

در مرحله بعد، ما به یک گروه گزارش CloudWatch (و/یا یک سطل S3 – به زیر مراجعه کنید) نیاز داریم که در آن SSM Agent بتواند گزارش‌های جلسه 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

این آخرین مرحله کلیدی است، جایی که ما دسترسی ایمن به دستگاه لینوکس خود را برای نظارت بر جلسه SSH و ثبت نام پیکربندی می کنیم. از داشبورد Session Manager شروع می کنیم.

در داشبورد، روی دکمه سفید «پیکربندی تنظیمات برگزیده» در کادر بالا سمت راست «شروع جلسه» کلیک کنید تا ثبت جلسه فعال شود.

در صفحه تنظیمات، بخش‌های متعددی را می‌یابیم که می‌توانیم کاوش کنیم، اما تمرکز ما بر روی پخش گزارش‌های جلسه SSH به CloudWatch یا S3 خواهد بود تا به ما امکان دهد به سرعت آنچه را که در دستگاه لینوکس ما اتفاق می‌افتد، ببینیم.

درست بعد از بخش «Logging CloudWatch»، یک بخش «Logging S3» وجود دارد که می‌توانیم سطل را انتخاب کنیم.

هنگامی که ثبت SSH پیکربندی شد، می‌توانیم SSH را در دستگاه لینوکس خود انجام دهیم و برخی از دستورات را اجرا کنیم تا ببینیم آیا فعالیت ضبط می‌شود یا خیر.

بنابراین، اجازه دهید یک جلسه را شروع کنیم. در همان صفحه، ما یک برگه “جلسات” را پیدا می کنیم که می توانیم یک جلسه را شروع کنیم. با کلیک بر روی دکمه “شروع جلسه” لیستی از ماشین های EC2 را به ما می دهد که می توانیم یک جلسه را روی آنها شروع کنیم:

اگر نمونه لینوکس EC2 خود را در لیست نمی‌بینیم، باید بررسی کنیم که آیا در حالت در حال اجرا است و مجوزهای IAM مرتبط با آن را دارد که قبلاً توضیح دادیم.

مدیریت خطای SSM Agent “Doesn’t Support Streaming Logs”.

در صورتی که خطایی دریافت کردیم مبنی بر اینکه نسخه SSM Agent نصب شده در دستگاه EC2 ما از گزارش‌های CloudWatch از پخش جریانی پشتیبانی نمی‌کند، نگران نباشید. یک راه بدون درد برای رفع این مشکل وجود دارد.

برای به روز رسانی SSM Agent، باید به آن بروید اجرای دستور در پانل سمت چپ مدیر سیستم های AWS سرویس.

هنگامی که به آنجا رسیدیم، می‌توانیم روی دکمه نارنجی «اجرای فرمان» کلیک کنیم، که به صفحه جدیدی منتهی می‌شود که در آن می‌توانیم برخی از پارامترها را پر کنیم.

ما با انتخاب شروع می کنیم AWS-UpdateSSMAgent از لیست

پس از انتخاب آن، به پایین پیمایش می کنیم تا قسمت “هدف ها” را ببینیم. در آنجا باید نمونه EC2 را که می‌خواهیم SSM Agent را در آن به‌روزرسانی کنیم، انتخاب کنیم، سپس دکمه «Run» را در انتها بزنید. این ما را به صفحه ای می فرستد که می توانیم پیشرفت به روز رسانی را نظارت کنیم.

به روز رسانی نماینده نباید بیش از پنج دقیقه طول بکشد. پس از انجام این کار، باید بتوانیم یک جلسه در Session Manager ایجاد کنیم.

در این مرحله، باید یک جلسه SSH را شروع کنیم.

پس از اجرای چند دستور، بیایید به گروه گزارش CloudWatch Logs (یا سطل S3 ما، نشان داده نشده) برویم و تأیید کنیم که فعالیت در حال ثبت است.

اکنون ما یک راه‌اندازی داریم که رمزگذاری در حالت استراحت فعال است و هر دستوری را که در دستگاه لینوکس اجرا می‌شود ضبط می‌کند.

در حقیقت، هر دستور ممکن است بیشتر از چیزی باشد که ما می خواهیم: هر اسرار ارائه شده یا ایجاد شده در طول جلسه در CloudWatch یا S3 ثبت می شود و توسط هر کسی که مجوزهای لازم را دارد قابل مشاهده است. برای جلوگیری از آن، می توانیم استفاده کنیم stty -echo; read passwd; stty echo; برای هر رازی که باید در طول جلسه ارائه کنیم.

یک راه حل عالی ثبت SSM/SSH AWS با هشدارهای جزئی

Session Manager ابزار مفیدی برای دسترسی از راه دور به ماشین های مجازی ما در AWS بدون نیاز به باز کردن پورت 22 است. در واقع، اگر از انتقال پورت یا اتصال مستقیم SSH استفاده کنیم، نمی توانیم گزارش های SSH را به این روش تولید کنیم. مستندات مدیر جلسه یادداشت.

با این وجود، ترکیب Session Manager با Session Logg راه حلی قوی برای کنترل و نظارت بر فعالیت در ماشین های مجازی است. علاوه بر این، برای استفاده از سرویس Session Manager هزینه‌ای دریافت نمی‌کنیم. ما فقط برای نمونه EC2 و گزارش‌های CloudWatch یا یک سطل S3 برای ذخیره گزارش‌ها پرداخت می‌کنیم.

برای خوانندگانی که آموزش های ویدیویی را ترجیح می دهند، من یک روش بسیار مشابه را کمی دقیق تر پوشش داده ام در یوتیوب.

ادامه مطلب در وبلاگ مهندسی تاپتال:

درک اصول اولیه

برای چه کاری می توان از SSH استفاده کرد؟

SSH (Secure Shell) برای دسترسی ایمن به ماشین های دیگر حتی از طریق یک شبکه ناامن استفاده می شود، زیرا ارتباط بین مشتری و سرور رمزگذاری شده است. همچنین برای انتقال فایل ها به یا از سرور از طریق پروتکل SFTP، که از SSH در زیر هود استفاده می کند، استفاده می شود. SSH به طور پیش فرض در پورت 22 گوش می دهد.

چگونه می توانم جلسات فعال در SSH را ببینم؟

راه های متعددی برای یافتن جلسات SSH فعال وجود دارد، از جمله دستورات w، who، و “ss | grep ssh”. با AWS Systems Manager می توان آنها را در کنسول Session Manager یا از طریق “aws ssm describe-sessions –state Active” در ترمینال مشاهده کرد.

AWS CloudWatch Logs چیست؟

AWS CloudWatch Logs یک سرویس جمع‌آوری گزارش کاملاً مدیریت شده است. می توانید پرس و جو کنید، نظارت کنید، فیلتر کنید، و آلارم های مبتنی بر شرایط را فعال کنید، به عنوان مثال، زمانی که بیش از 10٪ از درخواست های HTTP یک کد خطای 5xx دریافت می کنند. علاوه بر این، CloudWatch Logs Insights داده‌های گزارش را در نمودارهای نواری، خطی و منطقه‌ای انباشته ارائه می‌کند.

AWS IAM چیست؟

AWS IAM مسئول احراز هویت و مجوز درخواست های ارائه شده به منابع AWS است. از هر دو مدل مجوز RBAC و ABAC پشتیبانی می کند. در RBAC، مجوزها بر اساس نقش های شغلی اعطا می شوند. در ABAC، مجوزها بر اساس یک ویژگی اعطا می شود، به عنوان مثال، تخصیص مجوزها به یک اصلی بر اساس برچسب ها.

نمونه EC2 چیست؟

Amazon EC2 (Elastic Compute Cloud) به توسعه دهندگان اجازه می دهد ماشین های مجازی را در فضای ابری راه اندازی کنند. EC2 در ماهیت بسیار مقیاس پذیر، اجازه می دهد تا نمونه ها از 1vCPU به 20 و بالعکس در تنها چند دقیقه بروند. نمونه‌ها می‌توانند از پردازنده‌های Intel، AMD یا ARM استفاده کنند و بارهای کاری را روی Linux، Windows یا macOS اجرا کنند.

نمونه EC2 برای چه استفاده می شود؟

نمونه‌های EC2 ماشین‌های مجازی در فضای ابری هستند که برای اجرای بارهای کاری بدون نیاز به مدیریت سخت‌افزار زیربنایی استفاده می‌شوند، اما همچنان کنترل کامل منابع محاسباتی را فراهم می‌کنند. EC2 طیف وسیعی از پردازنده‌ها، سیستم‌عامل‌ها و فضای ذخیره‌سازی را برای اجرای هر چیزی از یک برنامه وب کوچک گرفته تا پایگاه داده بزرگ SAP HANA ارائه می‌کند.