ثبت 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 با پودر سوخاری
مرحله 1: انتخاب نوع کلید متقارن.

یک اسکرین شات از AWS با همان پودرهای نان، اکنون در مرحله 2:
مرحله 2: نام گذاری کلید ما

یک اسکرین شات از AWS با همان پودرهای نان، اکنون در مرحله 3:
مرحله 3 (اختیاری): تعیین یک مدیر.

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

در اینجا ما “مدیر” کاربر IAM را به عنوان مدیر کلیدی انتخاب کردیم، اما در انتخاب هر کاربر یا نقشی آزاد هستیم. همچنین می‌توانیم مجوز حذف کلید را برای سرپرست غیرفعال کنیم.

یک اسکرین شات از AWS با همان پودرهای نان، اکنون در مرحله 4:
مرحله 4: پرش از صفحه تخصیص کاربر.

ما هیچ کاربری را به این کلید اختصاص نمی دهیم زیرا می خواهیم این کلید فقط توسط سرویس CloudWatch Logs برای عملیات رمزگذاری و رمزگشایی گزارش SSH استفاده شود.

یک اسکرین شات از AWS با همان پودرهای نان، اکنون در مرحله 5:
مرحله 5: تنظیمات ما را مرور کنید و خط مشی کلید پیش فرض را عوض کنید.

در صفحه بازبینی، باید خط‌مشی کلید تولید شده توسط 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 را ارسال کند. بیایید آن را ایجاد کنیم.

تصویری از AWS با پودر سوخاری
ایجاد یک گروه گزارش “CloudWatch Logs”.

به فیلد 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

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

تصویری از داشبورد AWS Session Manager با بخش‌ها،
مرحله 1: شروع به کار با داشبورد.

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

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

تصویری از یک بخش AWS با عنوان
مرحله 2a: فعال کردن گزارش CloudWatch.

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

تصویری از یک بخش AWS با عنوان
مرحله 2b: فعال کردن ثبت S3.

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

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

یک اسکرین شات از AWS با خرده نان AWS Systems Manager، Session Manager و Start a session.  آ
مرحله 3: انتخاب نمونه EC2 برای شروع یک جلسه SSH با آن.

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

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

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

تصویری از یک پیام خطای AWS با متن سفید روی پس‌زمینه قرمز.  یک X دایره شده در کنار پیام است، "نسخه SSM Agent نصب شده در این نمونه از گزارش‌های جریان در CloudWatch پشتیبانی نمی‌کند.  یا SSM Agent را به آخرین نسخه به‌روزرسانی کنید، یا گزینه استریم گزارش‌ها را در تنظیمات برگزیده خود غیرفعال کنید."
یک خطای احتمالی «نسخه عامل SSM قدیمی».

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

تصویری از داشبورد AWS Systems Manager Run Command با بخش‌هایی،
مرحله 1: با داشبورد “Run Command” شروع کنید.

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

یک اسکرین شات از AWS با خرده نان AWS Systems Manager، Run Command و Run a command.  کادر جستجو با برچسب
مرحله 2: انتخاب یک سند فرمان.

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

تصویری از یک بخش AWS با عنوان
مرحله 3: انتخاب نمونه EC2 که یک عامل SSM نیاز به به روز رسانی دارد.

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

تصویری از AWS با پودر سوخاری
مرحله 4: نظارت بر پیشرفت به‌روزرسانی.

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

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

تصویری از AWS با شناسه جلسه و شناسه نمونه بالای ترمینال.  اعلان این است
یک جلسه SSH با استفاده از عامل SSM از طریق AWS Systems Manager Session Manager.

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

تصویری از AWS با پودر سوخاری
رویدادهای گزارش SSH در حال ثبت در گزارش‌های CloudWatch.

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

در حقیقت، هر دستور ممکن است بیشتر از چیزی باشد که ما می خواهیم: هر اسرار ارائه شده یا ایجاد شده در طول جلسه در 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 (Secure Shell) برای دسترسی ایمن به ماشین های دیگر حتی از طریق یک شبکه ناامن استفاده می شود، زیرا ارتباط بین مشتری و سرور رمزگذاری شده است. همچنین برای انتقال فایل ها به یا از سرور از طریق پروتکل SFTP، که از SSH در زیر هود استفاده می کند، استفاده می شود. SSH به طور پیش فرض در پورت 22 گوش می دهد.

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

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

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

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

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



منبع

Matthew Newman

Matthew Newman Matthew has over 15 years of experience in database management and software development, with a strong focus on full-stack web applications. He specializes in Django and Vue.js with expertise deploying to both server and serverless environments on AWS. He also works with relational databases and large datasets
[ Back To Top ]