この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
AWS Access Key Security Awareness คืออะไร ?
ในช่วงไม่กี่ปีที่ผ่านมา มีหลายเหตุการณ์ที่เกิดขึ้นด้านความปลอดภัยร้ายแรง เช่น ค่าธรรมเนียมการใช้งานจำนวนมากและการรั่วไหลของข้อมูลที่สงสัยว่าเกิดขึ้นจากการบุกรุกบัญชีเนื่องจากการรั่วไหลของ Access key เข้าถึง AWS
ดังนั้นเราจึงเริ่มโครงการเพื่อแนะนำความพยายามของเราในการที่จะปรับปรุงความปลอดภัยที่เกี่ยวข้องกับการดำเนินการ Access key ภายในบล็อกของเรา
เมื่อใช้ Access key
ในการเข้าถึง เราต้องเข้าใจด้วยว่ามีความเสี่ยงในการใช้งานอย่างอยู่และควรคำนึงถึงการใช้มาตรการรักษาความปลอดภัยล่วงหน้าก่อนใช้งานอย่างเหมาะสม
และนี้คือบทความภาษาไทยที่อธิบายเกี่ยวกับความอันตรายของ AWS Access keys เพื่อให้ท่านนำไปศึกษาเพิ่มเติมครับ
[ข้อควรระวัง] เกี่ยวกับการที่ Access Key หลุด(รั่วไหล) และถูกนำไปใช้โดยไม่ได้รับอนุญาต
AWS CLI, จะถูกใช้งานที่ไหนได้บ้าง ?
โดยทั่วไปคนส่วนใหญ่จะใช้ 4 ประเภทต่อไปนี้
- local terminal
- การเชื่อมต่อไป EC2 เพื่อใช้ SSH
- การเชื่อมต่อไป EC2 เพื่อใช้ SSM (session manager)
- การใช้งาน AWS Cloud Shell
แล้วมีความแตกต่างกันอย่างไร ? ผมคิดว่ามันขึ้นอยู่กับสถานการณ์ในการใช้งาน แต่ในครั้งนี้ผมจะพยายามเปรียบเทียบจาก 3 มุมมองนั้นก็คือ
1.การจัดการ Access key
2.การทำ log record
3.การสร้างและจัดการ Environment
(*ในบทความครั้งนี้ใช้งาน Linux เป็นหลัก)
summary first
| place | IAM access key | Shell operation log | AWS API operation log | Environment construction and operation |
|---|---|---|---|---|
| local terminal | △ จำเป็น | △ ต้องจัดเตรียมเอง | ○ ตรวจสอบได้จาก IAM User | ○ (ขึ้นอยู่กับกฏของ workspace และอื่นๆ) |
| EC2 + SSH | ○ ไม่จำเป็น | △ ต้องจัดเตรียมเอง | (△-) ต้องการกลไกเพื่อระบุผู้ใช้เข้าสู่ระบบ EC2 | △ การจัดการ EC2 |
| EC2 + SSM | ○ ไม่จำเป็น | ○ มีฟังก์ชันเอาต์พุตอัตโนมัติไปยัง S3, CloudWatchLogs | (△+) การระบุตัวตนจากประวัติและ log Shell | △ การจัดการ EC2 |
| Cloud Shell | ○ ไม่จำเป็น | △ ต้องจัดเตรียมเอง | ○ ตรวจสอบได้จาก IAM User | ○ ไม่ใช้งาน |
- EC2 + SSH, EC2 + SSM, CloudShell ไม่จำเป็นต้องใช้ access keys
- เมื่อใช้งานกับ local terminal เราต้องระมัดระวังเกี่ยวกับการจัดการ access keys
- EC2 + SSM มีความสามารถในการทำ logging ได้ดี
- CloudShell ไม่จำเป็นต้องใช้งานการจัดการและการสร้าง environment
การจัดระเบียบวิธีการเชื่อมต่อของแต่ละรายการ
Local terminal
สำหรับ terminal ภายใน การทำงานพื้นฐานคือการใช้ Access key เข้าถึง
แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ Access key เพื่อเข้าถึง AWS ที่แสดงไว้ด้านล่างแต่โดยพื้นฐานแล้วจะมีข้อความว่า "ในกรณีส่วนใหญ่เราไม่จำเป็นต้องใช้ Access key ในการเข้าถึงระยะยาวที่ไม่มีวันหมดอายุ (เช่น Access key ที่เข้าถึงผู้ใช้ IAM)"
ส่วนใหญ่เราไม่จำเป็นต้องใช้ Access Key สำหรับใช้งานระยะยาวที่ไม่มีวันหมดอายุ (เช่น Access key เพื่อเข้าถึงของผู้ใช้ IAM)
.
เราสามารถสร้าง IAM role และสร้างข้อมูลรับรองความปลอดภัยชั่วคราวได้
ข้อมูลรับรองความปลอดภัยชั่วคราวประกอบด้วย ID Access key และ Secret access key แต่ยังมี token ด้านความปลอดภัยที่ระบุเมื่อข้อมูลรับรองหมดอายุ
Quote: Best Practices for Managing AWS Access Keys - AWS General Reference
โดยเฉพาะอย่างยิ่งเราต้องการหลีกเลี่ยงการใช้ Access Key เพื่อเข้าถึงสิทธิ์ขั้นสูง เช่น การดำเนินการใช้งาน EC2 และการสร้างผู้ใช้ IAM ด้วยวิธีนี้
เพื่อให้สอดคล้องกับแนวทางปฏิบัติที่ดีที่สุด
เราแนะนำให้ผู้ใช้ IAM มีสิทธิ์น้อยที่สุดเท่าที่จะทำได้ และเปลี่ยนบทบาทเป็นบทบาทที่มีสิทธิ์ที่กว้างขึ้นโดยใช้ MFA แทน
การจัดการเพื่อเชื่อมต่อ EC2 ผ่าน SSH
นี่เป็นการดำเนินการที่ใช้ SSH เพื่อเชื่อมต่อกับ EC2 Instance ที่สร้างขึ้นเพื่อการจัดการและ
ใช้ IAM role (โปรไฟล์อินสแตนซ์) ที่แนบมากับ EC2
ไม่จำเป็นต้องออกรหัสเพื่อใช้ในการเข้าถึง
อย่างไรก็ตาม นอกจาก IAM แล้ว ยังมีข้อควรพิจารณาเพิ่มเติม เช่น ความจำเป็นในการเปิดพอร์ตสำหรับ SSH / ความจำเป็นในการจัดการผู้ใช้ OS และคีย์ SSH
สามารถศึกษาข้อมูลเกี่ยวเพิ่มเติมเกี่ยวกับการเชื่อมต่อ EC2 ผ่าน SSH ได้จากลิ้งค์ด้านล่างนี้เลยครับ
【Update】วิธีติดตั้ง Amazon Linux 2 บน EC2 และเชื่อมต่อเซิร์ฟเวอร์ด้วยโปรแกรม PuTTY
การจัดการเพื่อเชื่อมต่อ EC2 ผ่าน SSM
เป็นการดำเนินการที่เชื่อมต่อกับอินสแตนซ์ EC2 ที่สร้างขึ้นสำหรับการจัดการโดยใช้ตัวจัดการเซสชัน SSM และ
ใช้ IAM role (โปรไฟล์อินสแตนซ์) ที่แนบมากับ EC2
ไม่ต้องใช้ Key Access ในการเข้าถึง
สามารถศึกษาข้อมูลเพิ่มเติมได้จากลิ้งค์ด้านล่างนี้นะครับ
การใช้งาน SSM เชื่อมต่อเข้า EC2 Instance โดยไม่ต้องมี Inbound
Cloud Shell
เราสามารถเริ่มใช้งานได้ทันทีโดยคลิกปุ่มที่ด้านบนขวาของ AWS Management Console การดำเนินการของเชลล์สามารถทำได้ด้วยสิทธิ์ของผู้ใช้ IAM (Role) ที่ล็อกอินเข้าสู่คอนโซลการจัดการ
ไม่ต้องใช้ Access key เข้าถึง
[บทความที่เกี่ยวข้องภาษาญี่ปุ่น] AWS CloudShell บริการใหม่ที่รอคอยมานานเปิดตัวแล้ว! #คิดค้นใหม่ | Developer IO
มุมมองที่ 1: IAM Access Key
ครั้งนี้ เราประเมินว่าเป็นวิธีการที่ไม่ใช้ Access key เข้าถึง IAM ตามแนวทางปฏิบัติที่ดีที่สุด อีกครั้ง หากเราใช้ Access key เข้าถึง ให้สิทธิแก่ผู้ใช้ IAM ในจำนวนที่น้อยที่สุดเท่าที่จะเป็นไปได้ และตั้งค่า MFA ด้วย
| place | IAM access key |
|---|---|
| local terminal | △ จำเป็น |
| EC2 + SSH | ○ ไม่จำเป็น |
| EC2 + SSM | ○ ไม่จำเป็น |
| Cloud Shell | ○ ไม่จำเป็น |
มุมมองที่ 2: การบันทึกการทำงาน (Operation logging)
โดยมีการเก็บบันทึกข้อมูล 2 แบบ คือ
1.Shell operation log
2.AWS API operation log
Shell operation log
นอกเหนือจาก SSM เราต้องเตรียมการตั้งค่า terminal และ SSH Client ของเราด้วยเพื่อเรียกใช้คำสั่งสคริปต์ ฯลฯ
| place | IAM access key | Shell operation log |
|---|---|---|
| local terminal | △ | △ ต้องจัดเตรียมเอง |
| EC2 + SSH | ○ | △ ต้องจัดเตรียมเอง |
| EC2 + SSM | ○ | ○ มีฟังก์ชันเอาต์พุตอัตโนมัติไปยัง S3, CloudWatchLogs |
| Cloud Shell | ○ | △ ต้องจัดเตรียมเอง |
ที่นี่ดูเหมือนว่า "การเชื่อมต่อผ่าน SSM" ซึ่งมีฟังก์ชันเดียวในการรวมบันทึกโดยอัตโนมัติจะเป็นผู้ชนะ
เราสามารถค้นหาบทความที่อธิบายคุณลักษณะนี้โดยละเอียดได้ที่นี่
AWS API operation log
สามารถตรวจสอบบันทึกการทำงานของ AWS API ผ่าน CLI จาก CloudTrail ได้ทุกรูปแบบ เราสามารถตรวจสอบได้ว่าใครเข้าถึง API ที่เกี่ยวข้องและเมื่อใด
ในการทดสอบ เราเรียกใช้ STS GetCallerIdentity API และจัดเรียงเอาต์พุต CloudTrail
* ข้อมูลการตรวจสอบสิทธิ์ IAM ดั้งเดิมสำหรับ Access key เข้าถึง, SSM และ CloudShell ได้รับมาพร้อมกับ Switch role
เราได้วงกลมจุดต่าง
ความแตกต่างที่สำคัญคือที่อยู่ IP ของผู้ออกและความสะดวกในการติดตามว่าใครเข้าถึง API
เราคิดว่าสิ่งที่ น่าสงสัยเป็นพิเศษคือ "ใครเป็นคนโจมตี API"
สำหรับการเชื่อมต่อจาก terminal ในเครื่อง สามารถระบุผู้ใช้ IAM ดั้งเดิมได้โดยการติดตาม CloudTrail ตามชื่อเซสชัน Swirch role CloudShell ใจดีพอที่จะแสดงชื่อผู้ใช้ IAM ของ role ก่อนสลับ (เป็นชื่อเซสชัน)
ในทางกลับกัน SSH ไม่สามารถรับข้อมูลที่เกิน ID อินสแตนซ์ EC2
SSM ยังบันทึกรหัสอินสแตนซ์ EC2 แต่ SSM สามารถทราบผู้ใช้ที่เชื่อมต่อในช่วงเวลาที่เกี่ยวข้องจากบันทึกเซสชันที่ผ่านมาดังนี้ หากเราเก็บประวัติการทำงานของเชลล์ดังกล่าวแล้ว เราจะสามารถระบุตัวตนได้จากที่นั่น
มุมมองที่ 3: การสร้าง Environment และการดำเนินงาน
local terminal
- เราต้องติดตั้ง AWS CLI และตั้งค่าไฟล์รับรองให้เป็น Access key
- ระดับความยาก-ง่ายจะแตกต่างกันไปในแต่ละคน แต่อาจเป็นปัญหาตามมาในส่วนของ environment ซึ่งแต่ละคนก็มีความต้องการที่จะจัดการ software ต่างๆที่ทำการติดตั้งภายใน local environment
EC2 + SSH
- ต้องมีการติดตั้ง AWS CLI (AMI หลายๆตัวในปัจจุบันก็ทำการติดตั้งเป็นที่เรียบร้อยแล้ว)
- SSH เป็นการเชื่อมต่อพื้นฐานที่เกี่ยวข้องกับตัวผู้ใช้และการใช้ SSH key management และ EC2 instance operation
EC2 + SSM
- ต้องมีการติดตั้ง AWS CLI (AMI หลายๆตัวในปัจจุบันก็ทำการติดตั้งเป็นที่เรียบร้อยแล้ว)
- SSM จำเป็นที่จะต้องตั้งค่าเพื่อการดำเนิน Instance EC2 ให้เกิดขึ้น
Cloud Shell
ในส่วนนี้ไม่จำเป็นก็ใช้งานก็ได้ (ถ้าเราสามารถเข้าสู่ระบบใน AWS Management Console)
So this is what happened.
| place | IAM access key | Shell operation log | AWS API operation log | Environment construction and operation |
|---|---|---|---|---|
| local terminal | △ | △ | ○ | ○ (ขึ้นอยู่กับกฏของ workspace และอื่นๆ) |
| EC2 + SSH | ○ | △ | (△-) | △ การจัดการ EC2 |
| EC2 + SSM | ○ | ○ | (△+) | △ การจัดการ EC2 |
| Cloud Shell | ○ | △ | ○ | ○ ไม่จำเป็นต้องใช้ |
สรุป
นี้คือสรุปของเนื้อหาทั้งหมดนะครับ - EC2 + SSH, EC2 + SSM, CloudShell ไม่ต้องการ Access key เข้าถึง - เมื่อใช้ local terminal เราต้องระมัดระวังเกี่ยวกับการจัดการ Access key เข้าถึง !! - EC2 + SSM มีความสามารถในการบันทึกที่ยอดเยี่ยม - CloudShell ไม่ต้องการการสร้างสภาพแวดล้อมและการดำเนินการ
ดังนั้น จึงมีการเปรียบเทียบข้อดีและข้อเสียตามการใช้งานจาก AWS CLI ของทั้งสามมุมมอง
Access key ปกติที่มีความเสี่ยงต่อการรั่วไหล หากเราจำเป็นต้องการป้องกันความเสียหายจากการรั่วไหลของข้อมูลและใช้งาน Access key เข้าถึงที่ปลอดภัย ให้พยายามตรวจสอบให้แน่ใจว่าได้กำหนด role และได้รับมอบอำนาจในการจัดการ Access key ขั้นสูงสุดแล้ว
ซึ่งหากเราต้องการทำบางสิ่งด้วยกลไกต่างๆและไม่ต้องคำนึงถึงอุปกรณ์แต่ละชิ้น ผมขอแนะนำให้พิจารณาใช้ SSM หรือ CloudShell โดยไม่ต้องออก Access key เพื่อเข้าใช้งานเลย
เนื้อหาในบล็อกนี้ทั้งหมด ผมแปลและเรียบเรียงมาจากบล็อกต้นฉบับภาษาญี่ปุ่นของคุณ Kato-Saori สามารถไปติดตามเนื้อหาใหม่ได้ที่โปรไฟล์ของเขาได้เลยนะครับ และนี้ก็เป็นบทความต้นฉบับที่ผมนำมาแปลในบล็อกนี้ครับ
- AWSのCLI作業はどこで行う？ 安全に管理するパターンとメリデメ集
หวังว่าทุกท่านจะได้รับความรู้และความเข้าใจ การตั้งค่าความปลอดภัยต่างๆและนำมาปรับใช้เพื่อเสริมความปลอดภัยในการใช้งาน AWS ให้รัดกุมมากยิ่งขึ้นนะครับ ขอบคุณครับ
บทความที่เกี่ยวข้อง
Link อ้างอิง
15
