IAM คืออะไรและทำไมต้องรู้จัก
เวลาเราใช้งาน AWS (บริการเช่าคอมพิวเตอร์และพื้นที่เก็บข้อมูลบนอินเทอร์เน็ต) เรามักจะเผลอคิดว่ามีแค่เราคนเดียวที่ใช้ระบบ แต่ในโลกการทำงานจริงจะมีทั้งเพื่อนร่วมทีม โปรแกรมที่เขียนขึ้นเอง หรือแม้แต่เซิร์ฟเวอร์ที่ต้องคุยกันเอง IAM (ระบบจัดการตัวตนและการเข้าถึง) จึงถูกสร้างมาเพื่อคุมว่าใครทำอะไรได้บ้าง
ลองนึกภาพว่าคุณเป็นเจ้าของบริษัท คุณคงไม่อยากให้พนักงานทุกคนมีกุญแจเข้าห้องเก็บเงินหรือห้องเซิร์ฟเวอร์เหมือนกันหมด Authentication (การยืนยันตัวตนว่าเป็นใคร) คือการตรวจบัตรพนักงาน ส่วน Authorization (การอนุญาตให้ทำอะไรได้) คือการดูว่าบัตรของคุณเปิดประตูห้องไหนได้บ้าง
ถ้าคุณกำลังฝึกเขียนโค้ด การเข้าใจเรื่องนี้สำคัญมาก เพราะถ้าคุณตั้งค่าไม่เป็น คุณอาจจะเผลอเปิดช่องโหว่ให้คนอื่นเข้ามาลบข้อมูลในฐานข้อมูลหรือแอปของคุณได้ง่ายๆ การเรียนรู้ IAM จึงเป็นการสร้างวินัยความปลอดภัยตั้งแต่ก้าวแรกของการเป็นโปรแกรมเมอร์
แยกแยะ User และ Group ให้เป็นระบบ
IAM User (ผู้ใช้งาน) คือบัญชีรายบุคคลสำหรับคนหรือโปรแกรมที่ต้องการเข้ามาใช้งาน AWS ถ้าในทีมมี 5 คน เราก็ควรสร้าง 5 User เพื่อให้รู้ว่าใครเป็นคนทำอะไร และถ้าคนไหนลาออกไป เราก็แค่ลบ User นั้นทิ้งได้ทันทีโดยไม่กระทบคนอื่น
แต่การไล่ตั้งค่าทีละคนมันเหนื่อยเกินไป เราจึงใช้ IAM Group (กลุ่มผู้ใช้งาน) เข้ามาช่วย สมมติว่าคุณมีทีม Developer (นักพัฒนาซอฟต์แวร์) 10 คน แทนที่จะกดให้สิทธิ์ทีละคน คุณก็แค่สร้างกลุ่มชื่อ Developers แล้วใส่ 10 คนนี้เข้าไปในกลุ่มนั้น
ข้อควรระวังคืออย่าให้สิทธิ์เกินความจำเป็น มือใหม่มักจะให้สิทธิ์ AdministratorAccess (สิทธิ์สูงสุด) กับทุกคนเพราะขี้เกียจแก้ปัญหาตอนเข้าใช้งานไม่ได้ ซึ่งเป็นวิธีที่อันตรายมาก ให้เริ่มจากการให้สิทธิ์แค่เท่าที่จำเป็นก่อนเสมอ
รู้จักกับ Policies หัวใจของการอนุญาต
IAM Policy (นโยบายการเข้าถึง) คือเอกสารที่เขียนด้วยภาษา JSON เพื่อระบุว่าอนุญาตหรือห้ามทำอะไรบ้าง มันคือตัวกำหนดกฎเกณฑ์ว่า User คนนี้มีสิทธิ์อ่านไฟล์ หรือมีสิทธิ์ลบข้อมูลใน S3 Bucket (ที่เก็บไฟล์ออนไลน์) ได้หรือไม่
ตัวอย่างการเขียนกฎง่ายๆ เพื่ออนุญาตให้อ่านข้อมูลมีหน้าตาแบบนี้:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-test-bucket/*"
}
]
}
ในโค้ดนี้ Version คือเวอร์ชันของกฎ Effect คือการเลือกให้ Allow (อนุญาต) Action คือคำสั่งที่ให้ทำได้ในที่นี้คือดึงไฟล์ออกมา และ Resource คือระบุเจาะจงว่าให้ทำได้แค่กับถังเก็บไฟล์ที่ชื่อ my-test-bucket เท่านั้น
ผลลัพธ์ที่ได้คือเมื่อ User ที่ถือ Policy นี้พยายามดึงไฟล์ในถัง my-test-bucket ระบบจะยอมให้ผ่าน แต่ถ้าไปสั่งลบไฟล์ ระบบจะปฏิเสธทันทีเพราะเราไม่ได้เขียนกฎอนุญาตไว้ การเขียน Policy จึงเป็นการวางกรอบความปลอดภัยที่ชัดเจนที่สุด
เมื่อไหร่ควรใช้ Roles แทน User
หลายคนสับสนระหว่าง User กับ IAM Role (บทบาทสมมติ) ให้จำง่ายๆ ว่า User คือคนจริงๆ ที่มีรหัสผ่านและคีย์ลับ ส่วน Role คือ "ชุดเครื่องแบบ" ที่ใครหรือโปรแกรมไหนก็ได้หยิบไปใส่เพื่อขอรับสิทธิ์ชั่วคราว
สมมติคุณเขียนโปรแกรมรันบน EC2 (เซิร์ฟเวอร์จำลอง) แล้วอยากให้มันอัปโหลดรูปไปที่ S3 คุณไม่ควรเอา Access Key (รหัสผ่านสำหรับโปรแกรม) ไปใส่ไว้ในโค้ด เพราะถ้าโค้ดหลุด รหัสคุณก็หลุด แต่ให้คุณสร้าง Role ที่มีสิทธิ์อัปโหลดไฟล์ แล้วเอา Role นั้นไป "สวม" ให้กับเซิร์ฟเวอร์แทน
วิธีนี้ปลอดภัยกว่ามากเพราะเราไม่ต้องเก็บรหัสผ่านไว้ในเครื่องเลย Role จะจัดการเรื่องการขอสิทธิ์และหมดอายุสิทธิ์ให้เองโดยอัตโนมัติ เป็นแนวทางที่โปรแกรมเมอร์มืออาชีพใช้กันเป็นมาตรฐานในการเชื่อมต่อบริการต่างๆ ใน AWS
ยึดหลัก Least Privilege เพื่อความปลอดภัย
Principle of Least Privilege (หลักการให้สิทธิ์น้อยที่สุด) คือกฎทองของงานสายนี้ หมายความว่าเราจะให้สิทธิ์ทุกคนแค่ "เท่าที่จำเป็นต้องใช้" เพื่อทำงานนั้นให้สำเร็จเท่านั้น ถ้าเขาแค่ต้องอ่านไฟล์ ก็ห้ามให้สิทธิ์ลบไฟล์เด็ดขาด
มือใหม่มักจะพลาดโดยการใช้ Root User (บัญชีผู้ดูแลสูงสุด) ในการทำงานประจำวัน ซึ่งเป็นเรื่องอันตรายมาก เพราะถ้าบัญชีนี้โดนแฮ็ก ผู้บุกรุกจะทำลายทุกอย่างในระบบของคุณได้ทันที ให้สร้าง User ใหม่ที่มีสิทธิ์จำกัดแล้วใช้ตัวนั้นแทน
ลองเช็คลิสต์ตัวเองดูว่าในแต่ละโปรเจกต์ที่เราทำ เราได้ให้สิทธิ์กว้างเกินไปหรือไม่ ถ้าคุณกำลังเริ่มโปรเจกต์ใหม่ ให้ลองเขียนรายการสิทธิ์ที่ต้องใช้จริงๆ ใส่กระดาษไว้ก่อน แล้วค่อยไปสร้าง Policy ใน AWS ให้ตรงกับรายการนั้น
สรุป: นำไปใช้จริงในโปรเจกต์แรกของคุณ
การเข้าใจ IAM จะช่วยให้คุณทำงานกับ Cloud ได้อย่างมั่นใจ ไม่ว่าจะเป็นการทำ CI/CD (กระบวนการส่งโค้ดขึ้นเซิร์ฟเวอร์แบบอัตโนมัติ) หรือการเชื่อมต่อฐานข้อมูล ทุกอย่างต้องผ่านการตรวจสอบสิทธิ์เสมอ เริ่มต้นด้วยการสร้าง User ของตัวเองและตั้งค่า MFA (การยืนยันตัวตนสองชั้น) เพื่อความปลอดภัย
ตัวอย่างการใช้งานจริงสำหรับคุณ: หากคุณกำลังฝึกทำเว็บแอปพลิเคชันที่ต้องเก็บรูปภาพผู้ใช้ อย่าลืมสร้าง Role ให้ Lambda (ฟังก์ชันที่ทำงานเฉพาะจุด) เพื่อให้มันเข้าถึง S3 ได้โดยตรง แทนที่จะต้องมานั่งจัดการรหัสผ่านในโค้ดของคุณเอง
ความปลอดภัยไม่ใช่เรื่องที่ทำทีหลังได้ แต่เป็นส่วนหนึ่งของโค้ดที่คุณเขียน หากฝึกใช้ IAM ให้คล่องตั้งแต่วันนี้ คุณจะกลายเป็นโปรแกรมเมอร์ที่บริษัทต่างๆ อยากได้ตัวไปร่วมงาน เพราะคุณไม่ได้แค่เขียนโค้ดเก่ง แต่คุณยัง "เขียนโค้ดอย่างปลอดภัย" อีกด้วย
ที่มา: AWS IAM Explained: Users, Groups, Roles and Policies — DEV Community
