การบันทึก SSH และการจัดการเซสชันโดยใช้ AWS SSM

การตั้งค่าเครื่องมือหรือสคริปต์ที่กำหนดเองเพื่อเก็บบันทึก SSH บน Linux อาจเป็นเรื่องที่น่าเบื่อหน่ายและเกิดข้อผิดพลาดได้ง่าย

วิศวกรสามารถใช้ rootsh , screen หรือยูทิลิตีอื่นเพื่อบันทึกกิจกรรมของผู้ใช้ได้ แต่ถ้าสิทธิ์ของผู้ใช้ไม่ได้รับการตั้งค่าอย่างถูกต้อง ผู้ใช้ที่มีทักษะสามารถลบบันทึกการตรวจสอบเพื่อปกปิดร่องรอยของพวกเขาได้ อีกทางเลือกหนึ่งคือการตั้งค่าการบันทึกที่ระดับเคอร์เนล แต่ความเชี่ยวชาญที่จำเป็นสำหรับสิ่งนั้นนั้นไม่ธรรมดา

โชคดีที่มีวิธีบันทึกกิจกรรมของผู้ใช้โดยไม่ต้องเขียนแม้แต่คำสั่ง Linux แม้แต่คำสั่งเดียว! เราต้องการบริการเหล่านี้:

• EC2
• IAM (การจัดการข้อมูลประจำตัวและการเข้าถึง)
• KMS (บริการจัดการคีย์)
• บันทึก CloudWatch (และ/หรือ S3)
• AWS Systems Manager (เดิมชื่อ SSM)

เรามาดูวิธีการตั้งค่าแต่ละอย่างกัน

EC2 และ IAM

โดยปกติแล้ว การเปิดใช้อินสแตนซ์ EC2 นั้นค่อนข้างง่าย แต่มีงานหลักอย่างหนึ่งที่ต้องทำในระหว่างการเปิดตัว: เราจำเป็นต้องแนบบทบาท IAM กับอินสแตนซ์ของเรา มิฉะนั้น เราจะไม่สามารถบรรลุผลลัพธ์ที่คาดหวังตามรายละเอียดในตอนท้ายนี้ บทความ.

บทบาท IAM ที่เราเชื่อมโยงกับอินสแตนซ์ EC2 ของเราต้องมีนโยบาย AmazonSSMManagedInstanceCore ในตัว รวมถึงนโยบายนี้ (แนบมาในรูปแบบอินไลน์หรือที่จัดการโดยลูกค้า):

 { "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 ได้

ที่นี่เราเลือก "ผู้ดูแลระบบ" ผู้ใช้ 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

นี่คือขั้นตอนสำคัญขั้นสุดท้าย ซึ่งเรากำหนดค่าการเข้าถึงที่ปลอดภัยไปยังเครื่อง Linux ของเราสำหรับการตรวจสอบและบันทึกเซสชัน SSH เราจะเริ่มที่แดชบอร์ดตัวจัดการเซสชัน

บนแดชบอร์ด ให้คลิกปุ่ม "กำหนดค่าการตั้งค่า" สีขาวที่ด้านขวาบนกล่อง "เริ่มเซสชัน" เพื่อเปิดใช้งานการบันทึกเซสชัน

ในหน้าการตั้งค่า เราจะพบส่วนต่างๆ ที่เราสามารถสำรวจได้ แต่เราจะเน้นที่การสตรีมบันทึกเซสชัน SSH ไปยัง CloudWatch หรือ S3 เพื่อให้เราเห็นสิ่งที่เกิดขึ้นภายในเครื่อง Linux ของเราได้อย่างรวดเร็ว

หลังจากส่วน "การบันทึก CloudWatch" จะมีส่วน "การบันทึก S3" ที่เราสามารถเลือกถังได้

เมื่อกำหนดค่าการบันทึก SSH แล้ว เราสามารถ SSH ลงในเครื่อง Linux และรันคำสั่งบางอย่างเพื่อดูว่ากิจกรรมนั้นถูกจับหรือไม่

เรามาเริ่มเซสชันกันเลย ในหน้าเดียวกัน เราจะพบแท็บ "เซสชัน" ซึ่งเราสามารถเริ่มเซสชันได้ การคลิกปุ่ม "เริ่มเซสชัน" จะทำให้เรามีรายชื่อเครื่อง EC2 ที่เราสามารถเริ่มเซสชันได้:

หากเราไม่เห็นอินสแตนซ์ EC2 Linux ของเราในรายการ เราควรตรวจสอบว่าอินสแตนซ์อยู่ในสถานะกำลังทำงานและมีสิทธิ์ IAM ที่เชื่อมโยงกับอินสแตนซ์ดังที่เราอธิบายไว้ก่อนหน้านี้หรือไม่

ข้อผิดพลาดในการจัดการตัวแทน SSM “ไม่รองรับบันทึกการสตรีม”

ในกรณีที่เราได้รับข้อผิดพลาดว่ารุ่น SSM Agent ที่ติดตั้งบนเครื่อง EC2 ของเราไม่รองรับการสตรีมบันทึก CloudWatch ไม่ต้องกังวล มีวิธีแก้ไขที่ไม่เจ็บปวด

ในการอัปเดต SSM Agent เราต้องไปที่ Run Command ในแผงด้านซ้ายของบริการ AWS Systems Manager

เมื่อเราไปถึงที่นั่นแล้ว เราสามารถคลิกที่ปุ่ม "เรียกใช้คำสั่ง" สีส้ม ซึ่งนำไปสู่หน้าใหม่ที่เราสามารถกรอกพารามิเตอร์บางอย่างได้

เราจะเริ่มต้นด้วยการเลือก AWS-UpdateSSMAgent จากรายการ

เมื่อเลือกแล้ว เราจะเลื่อนลงมาจนเห็นส่วน "เป้าหมาย" ที่นั่น เราจำเป็นต้องเลือกอินสแตนซ์ EC2 ที่เราต้องการอัปเดต SSM Agent จากนั้นกดปุ่ม "เรียกใช้" ในตอนท้าย การดำเนินการนี้จะส่งเราไปยังหน้าที่เราสามารถติดตามความคืบหน้าของการอัปเดตได้

การอัปเดตตัวแทนไม่ควรใช้เวลานานกว่าห้านาที เมื่อเสร็จแล้ว เราควรจะสร้างเซสชันกลับมาในตัวจัดการเซสชันได้

ณ จุดนี้ เราควรจะเริ่มเซสชัน SSH

หลังจากรันคำสั่งสองสามคำสั่ง ให้ไปที่กลุ่มบันทึก CloudWatch Logs (หรือบัคเก็ต S3 ของเราที่ไม่แสดง) และยืนยันว่ามีการบันทึกกิจกรรม

ตอนนี้เรามีการตั้งค่าแล้ว โดยเปิดใช้งานการเข้ารหัสขณะพัก บันทึกทุกคำสั่งที่ทำงานในเครื่อง Linux ของเรา

อันที่จริง ทุก คำสั่งอาจมากกว่าที่เราต้องการ: ความลับใดๆ ที่ให้หรือสร้างขึ้นระหว่างเซสชันจะถูกบันทึกไว้ใน CloudWatch หรือ S3 และทุกคนที่มีสิทธิ์ที่จำเป็นสามารถเห็นได้ เพื่อป้องกันสิ่งนั้น เราสามารถใช้ stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; สำหรับแต่ละความลับที่เราต้องจัดเตรียมในระหว่างเซสชัน

โซลูชันการบันทึก SSM/SSH AWS ที่ยอดเยี่ยมพร้อมข้อแม้เล็กน้อย

Session Manager เป็นเครื่องมือที่มีประโยชน์ในการเข้าถึง Virtual Machine ของเราจากระยะไกลใน AWS โดยไม่ต้องเปิดพอร์ต 22 อันที่จริง เราไม่สามารถสร้างบันทึก SSH ด้วยวิธีนี้ได้ หากเราใช้การส่งต่อพอร์ตหรือการเชื่อมต่อ SSH โดยตรงในฐานะตัวจัดการเซสชัน บันทึกย่อเอกสาร

อย่างไรก็ตาม การรวม Session Manager กับการบันทึกเซสชันเป็นโซลูชันที่มีประสิทธิภาพสำหรับการควบคุมและตรวจสอบกิจกรรมภายใน VM นอกจากนี้ เราจะไม่เรียกเก็บเงินสำหรับการใช้บริการตัวจัดการเซสชัน เราจ่ายเฉพาะอินสแตนซ์ EC2 และ CloudWatch Logs หรือบัคเก็ต S3 สำหรับการจัดเก็บบันทึกเท่านั้น

สำหรับผู้อ่านที่ชอบวิดีโอบทช่วยสอน ฉันได้กล่าวถึงขั้นตอนที่คล้ายกันมากบน YouTube อย่างละเอียดถี่ถ้วนแล้ว

อ่านเพิ่มเติมในบล็อก Toptal Engineering:

• กรณีศึกษา: เหตุใดฉันจึงใช้ AWS Cloud Infrastructure สำหรับผลิตภัณฑ์ของฉัน