ใช้ AWS SSM Session Manager เพื่อเข้าสู่ระบบ EC2อย่างปลอดภัยโดยไม่ต้องใช้ IP สาธารณะและไม่ต้องใช้คีย์

ในการทำงานและการบำรุงรักษาเซิร์ฟเวอร์คลาวด์แบบเดิมในการเข้าสู่ระบบ Linux EC2การกำหนดค่ามาตรฐานมักจะ: ผูก IP เครือข่ายสาธารณะ (หรือใช้เกตเวย์ NAT) กับเซิร์ฟเวอร์และปล่อยในกลุ่มความปลอดภัย

TCP:22

พอร์ตจากนั้นกำหนดค่าคีย์ SSH ในเครื่อง (

.Pem

File) และสุดท้ายเชื่อมต่อผ่านเทอร์มินัล

แต่กระบวนการมาตรฐานชุดนี้ซึ่งดำเนินมานานกว่าสิบปีกำลังเผชิญกับความท้าทายครั้งใหญ่ภายใต้กฎระเบียบด้านความปลอดภัยระดับองค์กรที่ทันสมัย:

ความเสี่ยงในการสตรีมบนเครือข่ายสาธารณะ: ตราบใดที่คุณเปิดพอร์ต22พอร์ตไม่ว่าคุณจะเปลี่ยนพอร์ตเริ่มต้นหรือไม่สคริปต์แฮ็กเกอร์หลายพันรายการจะถูกสแกนอย่างบ้าคลั่งและแตกอย่างรุนแรงทุกวัน

ภัยพิบัติด้านการจัดการคีย์: เมื่อแจกจ่ายไฟล์คีย์ไปยังการพัฒนาหรือการดำเนินการและการบำรุงรักษาหลายไฟล์อุบัติเหตุด้านความปลอดภัยครั้งใหญ่ที่เกิดจากการลาออกของพนักงานที่ไม่ถูกทำลายและคีย์ถูกส่งไปยัง GitHub สาธารณะโดยไม่ได้ตั้งใจ

ค่าใช้จ่ายสูง: เพื่อไม่ให้เซิร์ฟเวอร์มี IP สาธารณะหลายทีมต้องใช้จ่ายเงินเพื่อสร้าง Jumpbox หรือกำหนดค่าอุโมงค์ VPN ที่ซับซ้อนซึ่งจะเพิ่มงบประมาณรายวันจำนวนมาก

ในระบบ AWS มีเกมเพลย์ขั้นสูงฟรีที่เรียกได้ว่าเป็นการโจมตีแบบลดมิติซึ่งสามารถกำจัดจุดเจ็บปวดทั้งหมดข้างต้นได้อย่างสมบูรณ์แบบเรียกว่า

AWS Systems Manager Session Manager (ตัวจัดการเซสชัน)

。

วันนี้ไม่ได้พูดถึงทฤษฎีความปลอดภัยที่ซับซ้อนจับมือคุณผ่านกระบวนการทั้งหมดเพื่อให้บรรลุ

เซิร์ฟเวอร์ไม่ต้องการ IP เครือข่ายสาธารณะกลุ่มความปลอดภัยไม่จำเป็นต้องเปิดพอร์ตใดๆและโลคัลไม่ต้องการใดๆไฟล์คีย์ pem

คุณสามารถเข้าสู่ระบบเทอร์มินัล EC2ได้อย่างมั่นคง

ขั้นตอนที่1: การถอดชิ้นส่วนลึก "การเชื่อมต่อย้อนกลับ" เทคโนโลยีสีดำของ Session Manager

เหตุใดเราจึงไม่จำเป็นต้องใช้ IP เครือข่ายสาธารณะและพอร์ต22แต่เรายังสามารถเชื่อมต่อกับเซิร์ฟเวอร์จากระยะไกลได้

เข้าสู่ระบบ SSH แบบดั้งเดิมคือ

การเชื่อมต่อไปข้างหน้า

: ในฐานะไคลเอนต์คอมพิวเตอร์ของคุณจะใช้ความคิดริเริ่มในการผ่านเครือข่ายสาธารณะเพื่อเคาะประตู22พอร์ตของเซิร์ฟเวอร์ EC2สิ่งนี้กำหนดให้เซิร์ฟเวอร์ต้องมีพอร์ทัลเครือข่ายสาธารณะและประตูต้องเปิด

Session Manager ใช้

การเชื่อมต่อย้อนกลับ

ตรรกะ:

ภายในเซิร์ฟเวอร์ EC2ของคุณมีการติดตั้ง daemon ขนาดเล็กอย่างเป็นทางการที่เรียกว่า SSM Agent

กระบวนการนี้ไม่จำเป็นต้องมีทราฟฟิกภายนอกเข้ามาโดยจะสร้างการเชื่อมต่อระยะยาวสองทางที่ปลอดภัยกับเซิร์ฟเวอร์ SSM อย่างเป็นทางการของ AWS ผ่าน HTTPS (พอร์ต443) จากภายในสู่ภายนอก

เมื่อคุณลงชื่อเข้าใช้คอนโซล AWS หรือต้องการเชื่อมต่อกับเซิร์ฟเวอร์ผ่าน AWS CLI ในเครื่องคำขอของคุณจะถูกส่งไปยังเซิร์ฟเวอร์ AWS SSM ก่อนจากนั้นเซิร์ฟเวอร์จะส่งคำสั่งไปยังตัวแทนภายใน EC2ผ่านช่องทางอินทราเน็ตที่สร้างขึ้นในตอนนี้ดำเนินการ.

ข้อสรุปด้านความปลอดภัยหลัก: เนื่องจากการรับส่งข้อมูลทั้งหมดมาจากภายในและภายนอกกฎการเข้าสู่กลุ่มความปลอดภัย EC2ของคุณจึงสามารถทำได้

ล้างข้อมูลทั้งหมด (ปิดพอร์ตขาเข้าทั้งหมดโดยสิ้นเชิง) แม้แต่แฮกเกอร์ก็ไม่พบการมีอยู่ของเซิร์ฟเวอร์ของคุณด้วยเครื่องตรวจจับดังนั้นความปลอดภัยจึงเต็มโดยตรง

ขั้นตอนที่สอง: แบบฝึกหัดการต่อสู้จริง1-ให้สิทธิ์ EC2ในการพูด (การกำหนดค่าบทบาท IAM)

หาก EC2ต้องการเชื่อมต่อกับเซิร์ฟเวอร์ SSM ของ AWS อย่างแข็งขันจะต้องได้รับอนุญาตจากคุณใน AWS บัตรเดียวที่อนุญาตทรัพยากรเรียกว่า

IAM Role (เอกลักษณ์และบทบาทการจัดการการเข้าถึง)

。

ลงชื่อเข้าใช้คอนโซล AWS ค้นหาและเข้าสู่บริการ IAM 。

คลิกที่เมนูด้านซ้าย "Roles"-> "Create Role"

ประเภทของหน่วยงานที่น่าเชื่อถือเลือก "บริการ AWS" บริการหรือกรณีการใช้งานเลือก EC2คลิกถัดไป

เพิ่มนโยบายการอนุญาต (ประเด็นสำคัญ): ป้อน AmazonSSMManagedInstanceCore ในช่องค้นหา (นี่คือนโยบายการลดสิทธิ์หลักที่กำหนดโดย AWS อย่างเป็นทางการสำหรับผู้จัดการช่วง) และตรวจสอบ

คลิกถัดไปตั้งชื่อตัวละครเช่น EC2-SSM-Access-Role คลิกสร้าง

ขั้นตอนที่สาม: แบบฝึกหัดการต่อสู้จริง2-เปิดตัว EC2ส่วนตัวที่ "ปิดสนิท"

รากฐานพร้อมแล้วตอนนี้เราจะดึงเซิร์ฟเวอร์ขึ้นมาเพื่อทดสอบจริง

ไปที่คอนโซล EC2แล้วคลิก "ตัวอย่างการเริ่มต้น"

ระบบมิเรอร์ (AMI): ขอแนะนำให้เลือก Amazon Linux 2023หรือ Amazon Linux 2รุ่นล่าสุดเคล็ดลับการหลีกเลี่ยงหลุม: ระบบทั้งสองนี้ได้รับการติดตั้งในตัวโดยค่าเริ่มต้นและ SSM Agent ได้รับการเปิดใช้งานด้วยตนเองคุณไม่จำเป็นต้องพิมพ์คำสั่งเพื่อติดตั้งด้วยตนเองหากคุณเลือก Ubuntu หรือ CentOS แบบเนทีฟคุณต้องติดตั้งซอฟต์แวร์ SSM Agent ด้วยตนเองด้วย apt หรือ yum หลังจากเริ่มต้นระบบ

ตัวอย่างประเภท: สุ่มเลือกระดับ t3.micro ฟรี

คู่คีย์: เลือก "ดำเนินการต่อโดยไม่มีคู่คีย์" โดยตรงในเมนูแบบเลื่อนลง (สัมผัสกับความสดชื่นของการเข้าสู่ระบบโดยไม่ต้องใช้คีย์)

การตั้งค่าเครือข่าย (ต้นทุนและความปลอดภัย): จัดสรร IP สาธารณะโดยอัตโนมัติ: เลือก "ปิดใช้งาน" เราไม่จำเป็นต้อง IP สาธารณะกฎการเข้ากลุ่มความปลอดภัย: ลบกฎ "อนุญาตให้ใช้พอร์ต SSH 22" เริ่มต้นโดยคลิกที่ถังขยะโดยตรงให้กฎการเข้าว่างเปล่า

รายละเอียดขั้นสูง (ฉีดวิญญาณ): เลื่อนลงและค้นหา "โปรไฟล์อินสแตนซ์ IAM" ในเมนูแบบเลื่อนลงให้เลือก EC2-SSM-Access-Role ที่เราสร้างขึ้นในขั้นตอนที่สองอย่างแม่นยำ

คลิกเริ่มต้นอินสแตนซ์

ขั้นตอนที่สี่: ช่วงเวลาแห่งการเป็นสักขีพยานในวิธีการเข้าสู่ระบบพลังงานสูงสามวิธี

เซิร์ฟเวอร์เริ่ม2 ~ หลังจาก3นาทีตรวจสอบให้แน่ใจว่าชั้นล่างสุดของ SSM Agen

T เชื่อมต่อกับระบบคลาวด์เรียบร้อยแล้วมาดูวิธีการเข้าสู่ระบบ

วิธีที่1: การเข้าถึงโดยตรงด้วยปุ่มเดียวบนคอนโซล (รายการโปรดของคนขี้เกียจ)

ในรายการอินสแตนซ์ EC2เลือกเซิร์ฟเวอร์ที่ไม่มีเครือข่ายสาธารณะและไม่มีพอร์ตที่คุณเพิ่งสร้างขึ้น

คลิกที่ "Connect" ที่ด้านบน

สลับไปที่แท็บ "Session Manager" (คุณจะพบว่าปุ่ม "การเชื่อมต่อ" สีเทาเดิมสว่างขึ้นเนื่องจากการกำหนดค่าที่ถูกต้อง)

คลิก "เชื่อมต่อ" เบราว์เซอร์จะปรากฏขึ้นทันทีเทอร์มินัลเนทีฟสีดำบริสุทธิ์คุณมีสิทธิ์ ssm-user อยู่แล้วดำเนินการ sudo su-เพิ่มสิทธิ์โดยตรงไปยังรูทเพื่อควบคุมที่สมบูรณ์แบบ

วิธีที่2: การเชื่อมต่อโดยตรงกับเทอร์มินัลในพื้นที่ (ขั้นตอนการดำเนินการและการบำรุงรักษาแบบมืออาชีพ)

การใช้งานและการบำรุงรักษาอาวุโสหลายคนไม่ชอบเขียนโค้ดในเบราว์เซอร์และคุ้นเคยกับเทอร์มินัลภายในเครื่อง (เช่น Mac Terminal, iTerm2หรือ Windows PowerShell) ไม่มีปัญหาผู้จัดการเซสชั่นยังสนับสนุน

ตรวจสอบให้แน่ใจว่าคุณได้ติดตั้งเครื่องมือ AWS CLI บนคอมพิวเตอร์ของคุณและกำหนดค่าคีย์การเข้าถึง IAM ส่วนตัวของคุณผ่านโปรไฟล์ aws

คอมพิวเตอร์ในพื้นที่จำเป็นต้องติดตั้งปลั๊กอินขนาดเล็กฟรีที่เรียกว่า Session Manager Plugin (ไปที่เว็บไซต์ทางการของ AWS เพื่อดาวน์โหลดแพ็คเกจการติดตั้งของระบบปฏิบัติการที่เกี่ยวข้องและติดตั้งโดยไม่ต้องใช้สมองในขั้นตอนเดียว)

เปิดเทอร์มินัลภายในเครื่องของคุณและพิมพ์บรรทัดคำสั่งนี้โดยตรง (แทนที่รหัสอินสแตนซ์ด้วยของคุณเอง):Bashaws ssm start-session-target i-0123456789abcdef0ไม่มีข้อความแจ้งที่สำคัญและไม่จำเป็นต้องป้อนรหัสผ่านหลังจากนั้นหนึ่งวินาทีของคุณเทอร์มินัลท้องถิ่นข้ามจักรวาลโดยตรงเข้าถึงเซิร์ฟเวอร์คลาวด์ที่ไม่มี IP เครือข่ายสาธารณะ

ขั้นตอนที่5: การตรวจสอบขั้นสูงระดับองค์กร-ใครทำอะไรในเซิร์ฟเวอร์ของฉัน?

หากคุณคิดว่า Session Manager เป็นเพียงการประหยัดปัญหาให้ดูถูกข้อกำหนดของผู้ผลิต AWS เหตุผลหลักที่บริษัทได้รับการสนับสนุนอย่างแท้จริงจากบริษัทที่มีข้อกำหนดด้านกฎระเบียบสูงเช่นการเงินและหลักทรัพย์ก็คือมี

สายการตรวจสอบที่สมบูรณ์แบบโดยไม่มีจุดบอด

。

ในการเข้าสู่ระบบ SSH แบบเดิมนักพัฒนาได้เชื่อมต่อไฟล์ที่ถูกลบและมีการเปลี่ยนแปลงการกำหนดค่าใดๆเว้นแต่คุณจะใช้เวลามากในการจัดสรรการถ่ายโอนข้อมูลบันทึกภายในระบบก็ยากที่จะติดตาม

ในการตั้งค่า AWS Systems Manager คุณสามารถกำหนดค่าบันทึกเซสชันเพื่อเปิดการจัดส่งได้โดยตรง:

ส่งไปยังถังเก็บข้อมูล S3: ทุกบรรทัดของคำสั่งที่ผู้ใช้พิมพ์ในเทอร์มินัลและทุกอักขระที่พิมพ์บนหน้าจอ (รวมถึงการปฏิเสธและการรายงานข้อผิดพลาด) จะถูกบันทึกเป็นไฟล์ข้อความที่เข้ารหัสแบบเรียลไทม์และอัปโหลดไปยัง S3เพื่อจัดเก็บถาวร

ส่งไปยัง CloudWatch Logs: ตระหนักถึงการแจ้งเตือนบันทึกแบบเรียลไทม์

แม้ว่าการดำเนินการและการบำรุงรักษาที่มีสิทธิ์สูงสุดจะดำเนินการในเซิร์ฟเวอร์

อาร์

M-rf

เขาไม่สามารถลบหลักฐานเหล็กที่บินไปยังถังตรวจสอบ S3ได้ใครเป็นผู้ดำเนินการและเมื่อใดที่คุณทำคุณจะรู้ว่าคุณมีคุณสมบัติตรงตามข้อกำหนดการตรวจสอบการปฏิบัติตามข้อกำหนดที่เข้มงวดที่สุด

ขั้นตอนที่หก: ประวัติการหลีกเลี่ยงเลือดและน้ำตาของการดำเนินงานและการบำรุงรักษาประจำวัน

ข้อความแจ้งการเชื่อมต่อ "อินสแตนซ์ไม่ได้ลงทะเบียนหรือออนไลน์": หลังจากดึงเซิร์ฟเวอร์ใหม่ขึ้นมาหากปุ่มเชื่อมต่อคอนโซลเป็นสีเทา99% เป็นเพราะซับเน็ตส่วนตัวของคุณถูกตัดการเชื่อมต่ออย่างสมบูรณ์แม้ว่า SSM Agent จะร้องขอจากภายในและภายนอกแต่หากเครือข่ายย่อยส่วนตัวของคุณไม่ได้กำหนดค่าเกตเวย์ NAT หรือกำหนดค่า VPC Endpoints (โหนดเทอร์มินัล) Agent ไม่สามารถส่งทราฟฟิก HTTPS ของชื่อโดเมนอย่างเป็นทางการของ AWS ได้แต่ก็จะสูญหายไปโดยสิ้นเชิงการเชื่อมต่อ. ตรวจสอบให้แน่ใจว่าอย่างน้อยเครือข่ายส่วนตัวสามารถเชื่อมต่อกับชื่อโดเมนสาธารณะของบริการ AWS หรือสร้างโหนดเทอร์มินัล VPC สามโหนด ssm, ssmessages และ ec2messages ใน VPC

การ์ดสิทธิ์ตายเกินไปและทีมไม่สามารถทำงานร่วมกันได้: ผู้จัดการเซสชั่นไม่รู้จักอีกต่อไปไฟล์ pem จะรับรู้สิทธิ์ผู้ใช้ AWS IAM ส่วนบุคคลหากคุณต้องการให้ Xiao Zhang นักพัฒนาใหม่เข้าสู่ระบบเครื่องนี้คุณต้องเพิ่มกลยุทธ์ในบัญชีส่วนตัวของเขาใน IAM ที่อนุญาตให้ใช้ ssm:StartSession สำหรับอินสแตนซ์ EC2การแทนที่การกระจายคีย์ทางกายภาพด้วย IAM โดยสิ้นเชิงเป็นวิธีที่ถูกต้องสำหรับคลาวด์เนทีฟสมัยใหม่

สรุป

เข้าสู่ระบบ EC2ด้วย AWS SSM Session Manager ซึ่งโดยพื้นฐานแล้ว

การตรวจสอบตัวตนที่ทันสมัย (IAM) แทนที่การตรวจสอบเครือข่ายโบราณ (22พอร์ตที่มีคีย์ทางกายภาพ)

。การใช้เทคโนโลยีสีดำฟรีนี้ให้เป็นประโยชน์ไม่เพียงแต่ช่วยคุณลดงบประมาณ IP ของป้อมปราการและเครือข่ายสาธารณะที่ไม่จำเป็นเท่านั้นแต่ยังช่วยให้โครงสร้างพื้นฐานระบบคลาวด์ของคุณ "มองไม่เห็น" บนเครือข่ายสาธารณะได้ทันทีมีทั้งความปลอดภัยและความสะดวกสบายนี่คือท่าทางมาตรฐานการทำงานและการบำรุงรักษาบนคลาวด์ที่หรูหราและเป็นของแท้