AWS IAM Policy Builder: สร้าง IAM Policy แบบ Least Privilege โดยไม่ต้องเดา

IAM JSON คือภาษาของการกำหนดสิทธิ์บน AWS — และ wildcard คือสิ่งที่เปลี่ยนความผิดพลาดเล็ก ๆ ให้กลายเป็นเหตุการณ์ระดับ incident ทุก Allow และ Deny ใน account ของคุณถูกเขียนเป็น policy document ทั้งหมด เพียงใส่ "Action": "s3:*" คู่กับ "Resource": "*" โดยไม่ได้ตั้งใจ คุณอาจมอบสิทธิ์อ่าน ลบ และแก้ไข policy ให้กับผู้ไม่ประสงค์ดี โดยที่ข้อมูลที่คิดว่าล็อกไว้แน่นกลับเปิดกว้างโดยไม่รู้ตัว

การเขียน JSON ด้วยมือใน AWS console ช้าและไม่ให้อภัย จุดหนึ่งใน comma ที่หายไป principal ที่ไม่ได้ใส่เครื่องหมายคำพูด หรือ ARN segment ที่พิมพ์ผิด ไม่ได้แจ้ง error แบบเป็นมิตรกับเรา แต่จะทำให้ deployment พัง หรือแย่กว่านั้นคือมอบสิทธิ์มากกว่าที่ตั้งใจไว้หลายเท่า

AWS IAM Policy Builder ช่วยขจัดปัญหาเหล่านี้ คุณประกอบ statement ด้วยภาพ — Effect, Action, Resource, Principal และ Condition block — แล้วเครื่องมือจะสร้าง JSON ที่ถูกต้อง ผ่านการ validate และเป็นมิตรกับ least privilege เพื่อนำไปวางใน IaC ของคุณได้ทันที ทุกอย่างประมวลผลในเบราว์เซอร์ 100% รายละเอียดโครงสร้างพื้นฐานของคุณจึงไม่หลุดออกจากเครื่อง

ทำไมต้องใช้ AWS IAM Policy Builder?

• ลดการวิ่งไปมาใน console — ประกอบและแก้ไข statement ในเครื่องได้เลย แล้ววาง policy ที่เสร็จแล้วลง IAM, Terraform หรือ CloudFormation
• Validate ระหว่างทำงาน — การตรวจสอบแบบเรียลไทม์จับ JSON ที่เสียโครงสร้าง action array ว่าง และความผิดพลาดเชิงโครงสร้างได้ตั้งแต่เนิ่น ๆ
• เป็นมิตรกับ least privilege — output ผลักดันให้คุณระบุ action ชัดเจนและกำหนดขอบเขต ARN แคบลง แทนการใช้ wildcard คลุมทั้งหมด
• รองรับคำศัพท์ IAM ครบถ้วน — Effect, Action, Resource, Principal และ Condition block เป็นฟิลด์หลักของเครื่องมือ ใช้ได้ทั้ง identity policy และ resource policy
• Output อ่านง่ายสม่ำเสมอ — การย่อหน้าและลำดับฟิลด์ที่เป็นระเบียบทำให้ policy ง่ายต่อการ diff และรีวิวใน pull request
• เป็นส่วนตัวโดยดีไซน์ — policy อาจเผยรายละเอียดโครงสร้างพื้นฐาน ทุกอย่างจึงประมวลผลในเบราว์เซอร์ล้วน ๆ ไม่มีการส่งขึ้นเซิร์ฟเวอร์

ฟีเจอร์หลัก

เครื่องมือนี้ตั้งใจโฟกัส: ทำหนึ่งอย่างให้ดีแทนการแทนที่ AWS console ลองใช้คู่กับ JSON Formatter เวลาต้องการจัดรูปแบบ policy ที่ดึงมาจาก Terraform state ให้อ่านง่าย

วิธีการใช้งาน

1. เปิดเครื่องมือ — เข้าไปที่ AWS IAM Policy Builder ไม่ต้องสมัครสมาชิก ไม่ต้องติดตั้ง และไม่ต้องใช้ AWS credentials
2. เพิ่ม statement แรก — เลือก Effect (Allow หรือ Deny) แล้วกรอก action ที่ต้องการในรูปแบบ service:Action ที่ระบุชัด เช่น s3:GetObject
3. กำหนดขอบเขต Resource — วาง ARN เฉพาะที่ statement นี้ครอบคลุม ลงระดับ bucket, key prefix หรือ role
4. เพิ่ม Principal และ Condition เมื่อจำเป็น — resource policy และ trust policy ต้องมี Principal ARN และเพิ่ม Condition เช่น aws:SourceIp เพื่อจำกัดเงื่อนไขของ grant
5. Validate และ export — ตรวจว่า JSON ผ่านการ validate แล้ว copy หรือ download ไปวางใน IAM config หรือ IaC templates

กายวิภาคของ Statement แบบ Least Privilege

แต่ละ statement ใน IAM policy ตอบคำถาม 5 ข้อ

Effect บอกว่า statement นี้ให้สิทธิ์หรือถอนสิทธิ์ — Allow หรือ Deny โดย Deny แบบระบุชัดจะชนะ Allow เสมอ จึงใช้เป็น guardrail กัน action ที่เสี่ยงได้ทุกสถานการณ์

Action ระบุ operation ที่ให้สิทธิ์ ตาม convention service:Action เช่น s3:GetObject, ec2:StartInstances, iam:PassRole โดย service prefix เป็นตัวพิมพ์เล็ก ส่วน action เป็น CamelCase และแม้การจับคู่จะไม่สนตัวพิมพ์ แต่ควรเขียนตาม convention เพื่อให้ผู้รีวิว scan ได้เร็ว และควรระบุเฉพาะ action ที่จำเป็นจริง แทนการใช้ service:*

Resource ตรึง grant ไว้กับ ARN เฉพาะ ARN อ่านได้ในรูป arn:partition:service:region:account-id:resource เช่น arn:aws:s3:::reports-2026 คือ S3 bucket ที่ไม่มี segment region และ account ส่วน arn:aws:iam::123456789012:role/DeployRole ชี้ไปที่ role ใน account 123456789012 ทุก segment ที่ระบุค่าชัดจะลด blast radius และทุก * ที่ค้างอยู่จะขยายขอบเขตกลับกัน

Principal ระบุว่า statement มีผลกับใคร ใช้ได้เฉพาะใน resource-based policy เท่านั้น — เช่น bucket policy, key policy และ trust policy — ไม่ใช้ใน identity policy ควรระบุ role หรือ account ARN แบบเต็ม และมอง Principal: "*" เป็นสัญญาณอันตรายที่ต้องมีเหตุผลรองรับเสมอ

Condition คือตัวคูณที่เปลี่ยน policy กว้าง ๆ ให้แคบลง operator อย่าง StringEquals, IpAddress และ ArnLike ผูก grant กับบริบทของคำขอ เช่น จำกัด action ให้ใช้ได้จาก CIDR ของสำนักงานด้วย aws:SourceIp หรือจาก organization ของคุณด้วย aws:PrincipalOrgID

wildcard ที่ผิดพลาดคลาสสิกมีลักษณะแบบนี้:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

policy นี้ให้สิทธิ์สร้าง ลบ และแก้ไข policy บนทุก bucket ทุก region แต่ความต้องการเดียวกันเมื่อเขียนแบบ least privilege เพื่ออ่านอย่างเดียวจาก bucket เดียวจะเป็นดังนี้:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:GetObjectVersion", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::reports-2026",
        "arn:aws:s3:::reports-2026/*"
      ],
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

งานเดียวกัน แต่ความเสี่ยงต่างกันคนละขั้ว: action ชัดเจน 3 ตัว bucket ที่ระบุชื่อ และรั้งเครือข่ายล้อมทั้ง grant

กรณีการใช้งานจริง

CI/CD Deploy Users

Credentials ของ pipeline คือความลับที่ถูกเปิดเผยง่ายที่สุดในหลายองค์กร สร้าง deploy identity เฉพาะกิจที่ statement ครอบคลุมเฉพาะสิ่งที่ pipeline ทำ — push artifact, update Lambda function, invalidate distribution — พร้อมแนบ condition ที่ผูก grant กับ build environment ของคุณ

Service Roles for Lambda and EC2

Lambda execution role ต้องการแค่ logs:CreateLogGroup กับ action ของ DynamoDB หรือ S3 ไม่กี่ตัวที่ชี้ไปยัง resource ที่ระบุชื่อ — ไม่ใช่ AdministratorAccess เมื่อร่าง trust policy ด้วย Principal ที่ถูกต้องและ permissions policy ด้วย ARN ที่กำหนดขอบเขตในครั้งเดียว function ของคุณจะไม่ถือสิทธิ์ที่โค้ดไม่เคยเรียกอีกต่อไป

Cross-Account Access

การให้อีก account เข้าถึง bucket หรือ KMS key ของคุณต้องแก้ resource policy ซึ่งหมายถึงการใส่ Principal, Action และ Condition ให้ถูกต้องเป๊ะ ฟิลด์แบบมีโครงสร้างของเครื่องมือช่วยให้ account ARN, external role และ StringEquals condition ไม้ปนกัน

Audit Remediation

เมื่อ IAM Access Analyzer แจ้งเตือน external trust หรือ finding ชี้ไปที่ resource แบบ wildcard ให้สร้าง statement เดิมใหม่ด้วย action ที่ระบุชัด ARN ที่ระบุชื่อ และ condition แล้วแนบ JSON ก่อน-หลังไปกับ ticket เพื่อเป็นหลักฐานว่าช่องโหว่ถูกปิดแล้ว

Best Practices

• เริ่มจากศูนย์แล้วค่อยเพิ่ม — เริ่มจากสิทธิ์เป็นศูนย์แล้วมอบทีละ action เมื่อพิสูจน์ความจำเป็นได้ ช้ากว่าการ copy template แต่ปลอดภัยกว่าการไล่ลดทีหลังมาก
• ตรวจสอบด้วย IAM Access Analyzer — หลัง deploy ให้ให้ AWS วิเคราะห์ external access และสิทธิ์ที่ไม่ถูกใช้ แล้วนำผลกลับมาปรับ policy ให้แคบลง
• อย่าใช้ Principal "*" อย่างลอย ๆ — principal แบบไม่จำกัดใน resource policy เท่ากับเชิญชวนอินเทอร์เน็ต ถ้าจำเป็นต้องเปิดกว้าง ให้ชดเชยด้วย condition ที่เข้มงวดและ explicit Deny
• ทดสอบด้วย simulator — รัน identity และ policy ที่เตรียมจะใช้ผ่าน IAM policy simulator ก่อนขึ้นของจริง เพื่อให้รู้ว่าลืม s3:ListBucket ใน sandbox แทนที่จะพังตอน deploy
• เลือก condition ดีกว่า wildcard ที่แคบลง — condition ที่อิง source IP, MFA หรือ organization มักช่วยล็อก grant ได้ดีกว่าการพยายามสะกดทุก action ที่มีอยู่
• ทบทวน wildcard ตามรอบ — ทุกไตรมาส ค้นหา * ใน policy ของคุณ แล้วแทนที่ตัวที่ไม่มีเหตุผลรองรับไว้เป็นลายลักษณ์อักษร

สร้าง Policy ถัดไปของคุณอย่างมั่นใจ

IAM ไม่จำเป็นต้องเป็นเหมืองระเบิดของ syntax อีกต่อไป เปิด AWS IAM Policy Builder ประกอบ statement ถัดไปด้วยฟิลด์แบบมีโครงสร้างและการ validate แบบเรียลไทม์ แล้วส่งมอบ policy ที่คุณกล้าอธิบายในห้อง audit ได้ — ฟรี และทำงานในเบราว์เซอร์ล้วน ๆ

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• JSON Formatter — จัดรูปแบบและตรวจสอบ policy JSON ให้อ่านง่ายก่อนนำไปใช้งาน
• Security Headers Generator — สร้าง HTTP security headers ที่ผ่านการ hardening สำหรับเว็บแอปที่ policy ของคุณปกป้องอยู่
• Safelink Decoder — ถอด URL แบบ safelink และ tracking link ให้เห็นปลายทางจริง

ขอให้สนุกกับการเขียน policy!

คำถามที่พบบ่อย

ถ: AWS IAM Policy Builder เชื่อมต่อกับ AWS account ของฉันหรือไม่?

ตอบ: ไม่ครับ เครื่องมือทำงานฝั่ง client ทั้งหมด คุณอธิบาย statement ที่ต้องการ เครื่องมือสร้างและ validate policy JSON ในเครื่องของคุณ และไม่มีข้อมูลใดถูกส่งออกไปไหนเลย

ถ: ควรใช้ Principal element เมื่อไร?

ตอบ: เฉพาะใน resource-based policy เช่น S3 bucket policy, KMS key policy และ IAM role trust policy ส่วน identity policy ไม่มี Principal เพราะ principal คือ identity ที่ policy ผูกอยู่นั่นเอง

ถ: การใช้ wildcard ใน IAM policy ยอมรับได้หรือไม่?

ตอบ: ได้ ถ้าตั้งใจและกำหนดขอบเขตชัดเจน s3:GetObject บน Resource: "arn:aws:s3:::reports-2026/*" เป็นแนวทางที่เหมาะสมสำหรับการอ่าน object ใน bucket เดียว แต่การเอา wildcard action มาคู่กับ wildcard resource โดยไม่ได้ตั้งใจนั้นไม่มีข้อยกเว้น

ถ: นำ output ไปใช้กับ Terraform หรือ CloudFormation ได้ไหม?

ตอบ: ได้ JSON ที่ได้มาเป็น IAM policy grammar มาตรฐาน วางลง block jsonencode() ของ Terraform หรือ property PolicyDocument ของ CloudFormation ได้เลย