AWS IAM คืออะไร การแนะนำฟังก์ชันล่าสุดของ AWS

สวัสดีครับทุกคน ชิบะ(สะจิ) ครับ

รายการนี้จะเขียนเกี่ยวกับ AWS ปี 2022 ฉบับเบื้องต้น โดยฝ่าย Consulting ของบริษัทเราเอง นี่เป็นบทความที่จะมาเล่าเกี่ยวกับเนื้อหา AWS Service มาเล่าใหม่อีกครั้งว่ามีอะไรถูกอัพเดทอะไรบ้างแล้ว
แบบละเอียด/เจาะลึกตั้งแต่เบสิกพร้อมคำอธิบาย โดยเหล่าสมาชิกที่เคยเขียนบทความเหล่านี้มาแล้ว

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

งั้นก็ไปเริ่มกันเลยครับ Theme ในวันนี้คือ "AWS IAM" ครับ

สิ่งที่จะไม่เขียนในบทความนี้

• Best practices สำหรับการตั้งค่า IAM
• รายละเอียดของ IAM Policy หรือ recipes
• รายละเอียดอื่นในด้าน Technical ส่วนใหญ่

AWS IAM คือ web service ที่มีการเข้าถึง 500 ล้าน Access ต่อ 1 วินาที

AWS IAM คือ Web service ครับ เป็น Web service ที่จะช่วยเหลือในการควบคุม Access ที่เข้ามาถึงยัง AWS Resource ครับ โดยสิ่งที่จะทำก็คือการจัดการ Authentication และ Authorization ครับ

โดยแผนภาพด้านล่างเป็นรูปที่จะอธิบายครับ

ยกตัวอย่างว่า User ต้องการที่จะส่ง Request ไปยัง AWS Resource โดยถ้าจะให้เอาละเอียดกว่านี้คือ ผมต้องการสร้าง EC2 Instance ใหม่

ผมทำการใส่ User ID และ Password ของสัก IAM User เพื่อ Sign in ไปที่ Management Console จากนั้นเมื่อผมทำการสร้าง EC2 Instance จาก Management Console จะเป็นการส่ง Request ไปยัง Service Endpoint ของ EC2 Request จะถูกส่งไปที่ AWS IAM ผ่านทาง Service Endpoint และในนั้นเองจะถูก Authentication และ Authorization แล้วก็จะส่งกลับมาเป็นผลลัพท์ว่า Request สร้าง EC2 Instance จะได้รับอนุญาตให้สร้างหรือไม่

จุดสำคัญของเรื่องคือ เบื้องหลังของแต่ละ Request ที่ส่งไปยัง AWS Service จะถูกตรวจสอบด้วย AWS IAM
AWS IAM endpoint ที่ทำการตรวจสอบ Request นั้นมีให้บริการโดย Host จำนวนหลายล้านตัว โดยใน 1 วินาที ว่ากันว่ามีการเข้าถึงกว่า 500 ล้าน Access เลยทีเดียวครับ

Authentication และ Authorization

ถ้าจะให้อธิบายความหมายของ 2 คำนี้ง่ายๆ
"Authentication" นั้นหมายถึง "เป็นใคร"
"Authorization" นั้นหมายถึง "ทำอะไรได้บ้าง"

อย่างในกรณีตัวอย่างด้านบนที่พึ่งกล่าวไป ในการ Sign in เข้าไปยัง Management Console จำเป็นต้องใช้ "Authentication" ที่หมายถึง User ID และ Password แล้ว IAM Policy ที่ติดอยู่กับตัว IAM User คือ ข้อมูลที่ใช้สำหรับ "Authorization"

เมื่อแบ่ง Authentication ของ AWS IAM ออก จะได้เป็นหัวข้อใหญ่ๆด้านล่างนี้

• Password สำหรับ Sign in เข้าสู่ Management Console
• credentials (Access Key ID, Secret Access Key)
  • กรณีที่เป็น temporary credentials จะมี Session Token ด้วย

ส่วน Authorization ของ AWS IAM คือ Policy แต่ละชนิดรวมไปถึง "IAM Policy" ซึ่งเรื่องนี้จะขออธิบายในส่วนต่อไปครับ

AWS Resource และ AWS Account

สิ่งที่เขียนต่อไปนี้จะเป็นรายละเอียดพื้นฐานครับ

AWS Resource ชนิดต่างๆ เช่น EC2 Instance หรือ S3 Bucket จะถูกสร้างให้อยู่ในวงสมาชิกของ AWS Account
IAM User หรือ IAM Role ก็เป็น AWS Resource ครับ (ในบางบริบทอาจจะถูกยกให้เป็น Component สำหรับ AWS Resource)

AWS Account คือกล่องที่ใหญ่ที่สุดสำหรับการ Grouping(จัดกลุ่ม) AWS Resource โดยเลขของ Account จะเป็นเลข 12 หลักครับ AWS Account จะผูกติดอยู่กับหนึ่ง Root User ซึ่งอาจจะมีบางกรณีที่เราเรียก Root User ว่า AWS Account ครับ

Root User เป็น IAM User ที่มีสิทธิ์จำนวนมาก จึงไม่นิยมให้นำมาใช้งานโดยตรง หากข้อมูลที่ทำให้เข้าถึง Root User หลุดออกไป อาจจะทำให้เกิดความเสียหายอันใหญ่หลวง
ด้านล่างนี้จะเขียนเกี่ยวกับ Authentication information ที่ Root User มีอยู่

• Mail Address กับ Password
• credentials (Access Key ID, Secret Access Key)

เพื่อป้องกันข้อมูลที่ทำให้เข้าถึง Root User หลุด จะสร้าง IAM User ที่มีสิทธิน้อยกว่ามาใช้งานแทน(Best practice)

Cross Account Access

จากหัวข้อด้านบน เราได้พูดไปแล้วว่า AWS Resource จะถูกจัดกลุ่มอยู่ในสัก AWS Account หนึ่ง โดยพื้นฐานแล้วเราไม่สามารถ Access แบบคร่อม Account ได้ หมายความว่าเราไม่สามารถใช้ Authentication information ของ AWS Account นึ่ง เพื่อใช้งาน AWS Resource ของอีก AWS Account หนึ่งได้

แต่ไม่ใช่ทุกอย่างที่จะใช้คร่อม Account ไม่ได้ หากอยู่ในเงื่อนไขบางอย่างก็สามารถทำให้สำเร็จได้ ยกตัวอย่างเช่น เรามีการเปิดอนุญาตใน AWS Resource อีกฝั่งครับ โดยการอนุญาตนี้จะถูกกระทำโดยสิ่งที่เรียกว่า resource-based policy และในกรณีที่ "ต้นทางการรัน Request" กับ "ปลายทาง AWS Resource" อยู่คนละ AWS Account การ Access นี้จะเรียกว่า Cross Account Access

ไม่ใช่ว่าทุก AWS Resource จะรองรับ resource-based policy, AWS Resource ที่ไม่รองรับ resource-based policy จะไม่สามารถ Cross Account Access ได้ ตามภาพด้านบนที่เห็น EC2 Instance หรือ IAM User คือ AWS Resource ที่ไม่รองรับ Cross Account Access ครับ

การ Access ไปยัง "AWS Layer"

"Access" ในที่นี้หมายถึง การส่ง Request ไปยัง AWS Service ครับ
Cross Account Access หมายถึง การส่ง Request ไปยัง AWS Service ที่อยู่ต่าง Account ครับ

ไม่ได้หมายถึงการ "Access" แบบที่ใช้ SSH เข้าไปยัง EC2 Instance ครับ
การที่เราใช้ SSH เข้าไปยัง EC2 Instance ที่อยู่ต่าง Account จะไม่เรียกว่า Cross Account Access ครับ

ตามรูปด้านล่างครับ

คำว่า "AWS Layer" ในบทความนี้เป็นคำที่ประดิษฐ์ขึ้นมา ไม่ได้มีใช้ในทั่วไป เพราะฉนั้นไม่ควรเอาไปใช้กันข้างนอกนะครับ

ตัวอย่างการ Access ไปยัง "AWS Layer" คือการควบคุมการสร้าง EC2 Instance, เปลี่ยน Instance type, ปรับเปลี่ยน Security Group ที่ติดอยู่
ตัวอย่างการ Access ไปยัง "OS Layer" คือ การสร้าง OS User, เปลี่ยน Perminssion ของ Directrtory, สร้าง File ใหม่

แนะนำให้จำไว้ว่า สิ่งที่ AWS IAM สามารถควบคุมได้ สิ่งที่ถูกบันทึกใน CloudTrail คือการ Access ไปยัง "AWS Layer" ครับ

AWS Resource ของ AWS IAM (IAM Resource)

ในหัวข้อนี้เราจะมาพูดถึง AWS Resource ที่อยู่ในหมวด AWS IAM ว่ามีอะไรกันบ้างครับ
โดยก็จะแบ่งออกใหญ่ๆได้ตามด้านล่างนี้ครับ

• IAM User
• IAM Role
• IAM Group
• IAM Policy

หากใครที่อยากลงลึกไปอีก ก็สามารถอ่านได้ที่บทความด้านล่างครับ

• Actions, resources, and condition keys for Identity And Access Management - Service Authorization Reference

IAM Identities, IAM Resource, IAM Principal

IAM Resource ที่ได้กล่าวไปด้านบน ได้มีการเรียกหลายๆแบบ เราจึงได้ทำการรวบรวมวิธีการเรียกเหล่านี้มาเป็นภาพเพื่อความเข้าใจง่ายๆครับ

ข้อกำหนดในการเรียกพวกนี้ไม่ค่อยมีการเข้มงวดมากนัก โดยส่วนใหญ่มักเปลี่ยนวิธีเรียกไปตามบริบทที่ต้องการพูดถึง สิ่งที่มักจะใช้บ่อยจริงๆคือ IAM Identities หมายถึง User, Role, Group ครับ

นอกจาก 4 Resource นี้แล้ว ยังมี IdP(ID Providers) Session Principals, Federated Users, MFA ฯลฯ ที่เป็น Component ที่สามารถใส่อยู่ตรงไหนสักที่ในวงกลมด้านบน เราไม่จำเป็นต้องไปจำแผนภาพที่เขียนไว้ด้านบนทั้งหมดนะครับ เอาแค่ IAM Identities ก็พอครับ

IAM User

IAM User คือ Resource ที่เอาไว้ใช้ Authentication สำหรับ IAM ครับ หลังจากสร้าง IAM User แล้วสามารถสร้าง Authentication Information ตามด้านล่างได้ครับ

• Password สำหรับการ Sign-in Management Console
• credentials (Access Key ID, Secret Access Key)

IAM Role

IAM User ก็คือ Resource ที่เอาไว้ใช้ Authentication สำหรับ IAM เหมือนกันครับ จุดที่แตกต่างระหว่าง IAM User คือ IAM Role จะไม่เป็นตัวหลักในการส่ง Request ครับ

สิ่งที่จะเป็นตัวหลักคือ "Session ที่รับ IAM Role ไป" ลองดูเคสด้านล่าง ที่ IAM User ทำการรับ IAM Role นะครับ

IAM User ที่เป็น Request ต้นทาง จะทำการส่ง Request ไปยัง Service ที่มีชื่อว่า AWS STS
เนื้อหาข้างใน Request คือ ต้องการรับ IAM Role ที่ระบุ
เมื่อ Request ได้รับอนุญาต จะได้รับ temporary credentials กลับมา ซึ่งมาจากการประกอบกันของสิ่งด้านล่างนี้

• Access Key
• Secret Access Key
• Session Token

เมื่อกี้ที่เราดูไป credentials ที่ IAM User สามารถสร้างได้จะเรียกว่า permanent credentials และไม่มี Session Token หรือก็คือ ไม่มีเวลาจำกัดนั่นเอง ในกรณีที่ดำเนินการ Request โดยใช้ temporary credentials นั้น ตัวหลักจะไม่ใช่ IAM User หรือ IAM Role แต่จะเป็น "Session ที่รับ IAM Role ไป" นั่นเองครับ

ใครบ้างที่สามารถรับ IAM Role ได้

สิ่งที่สามารถรับ IAM Role ได้ มีดังต่อไปนี้

• IAM User ที่อยู่ใน AWS Account เดียวกับ IAM Role
• IAM User ที่อยู่ใน AWS Account ต่างกับ IAM Role
• AWS Service
• User ภายนอกที่ได้รับการรองรับจาก IdP ภายนอก

"AWS Service" หมายถึง web Service ที่ AWS เป็นผู้ให้บริการ ครับ

ยกตัวอย่างเช่น User หรือ Application ที่อยู่บน EC2 Instance ต้องการที่จะรับ IAM Role
ขั้นตอนคือ Request จะถูกส่งไปที่ EC2 Instance ผ่าน Instance Protocol ที่ติดอยู่กับ Instance และส่งกลับมาให้ EC2 Service ได้รับ IAM Role (สุดท้ายคือ User หรือ Application จะได้ temporary credentials)

นอกจากนี้ User ภายนอกที่ได้รับการรองรับจาก IdP ภายนอก ที่มีความเข้ากันได้กับ SAML 2.0 หรือ OIDC ก็สามารถรับได้เหมือนกัน ยกตัวอย่างเช่น ผมทำการ federation Active Directory กับ AWS IAM และ Mapping AD User กับ IAM Role
เมื่อทำการ Access ไปยัง Endpoint เฉพาะ ที่ได้รับการ Authentication ให้เป็น AD User จะทำให้สามารถ Sign-in ไปยัง Management Console โดย มี IAM Role ติดมาอยู่
โดยเราจะเรียก User ภายนอก แบบนี้ว่า federated user ครับ

วิธีการควบคุมว่าใครสามารถรับ IAM Role ได้บ้าง

เราสามารถควบคุมได้โดยใช้ trust policy

IAM Role จะสามารถติด IAM Policy ได้เหมือนกับ IAM User ทำให้สามารถควบคุมได้ว่า "Session ที่รับ IAM Role ไป" สามารถทำอะไรได้บ้าง
และนอกจากนั้นสามารถติด Policy ที่เรียกว่า trust policy เพื่อทำให้สามารถควบคุมได้ว่า "ใครสามารถรับ IAM Role ไปได้บ้าง"

ประเภทของ trust policy จะอยู่ใน resource-based policy ครับ

IAM Group

IAM Group นั้นแตกต่างจาก IAM User และ IAM Role ที่ไม่มี Authentication Information อยู่
ประโยชน์ของสิ่งนี้คือการทำให้ IAM Policy สามารถแบ่ง Authorization ออกได้อย่างมีประสิทธิภาพครับ

เราสามารถเพิ่ม IAM User เข้าไปใน IAM Group ได้
IAM Policy ที่ติดให้กับ IAM Group จะถูกส่งให้กับ IAM User ที่อยู่ใน IAM Group นั้นครับ
นั่นคือสิ่งที่ IAM Group สามารถทำได้ครับ
มีแค่ Policy ประเภท identity-based policy ของ IAM Policy เท่านั้นที่สามารถติดกับ IAM Group ได้

แล้วก็ไม่สามารถทำสิ่งต่อไปนี้ได้

• เพิ่ม root เข้าไปใน IAM Group
• เพิ่ม IAM Role เข้าไปใน IAM Group
• เพิ่ม IAM Group เข้าไปใน IAM Group (nesting)

IAM Policy

IAM Policy คือ Resource ที่ทำหน้าที่ Authorization ครับ

IAM มี Policy อยู่ทั้งหมด 6 แบบ ได้แก่

• identity-based policy
• resource-based policy
• Permissions boundary
• Organizations SCP
• access control list
• session policy

โดยความหมายกว้างๆของทั้งหมดจะเรียกว่า IAM Policy ครับ
แต่ถ้าพอพูดถึง IAM Policy ส่วนใหญ่จะหมายถึง identity-based policy ครับ
ต้องอาศัยฟังจากรูปประโยคด้วยครับ

IAM JSON Policy

IAM Policy ที่ไม่ใช่ Policy ประเภท access control list จะถูกเขียนอยู่ในรูป JSON ทั้งหมดครับ โดยสามารถอ่านรายละเอียดเพิ่มเติมได้ที่ลิ้งค์ด้านล่างนี้

• IAM JSON policy elements reference - AWS Identity and Access Management

เนื้อหาใน Policy จะเป็นการเขียนกำหนดเกี่ยวกับ การอนุญาต และ ไม่ อนุญาต

identity-based policy

identity-based policy คือ IAM Policy ที่สามารถติดกับ IAM identity (User, Role, Group) ได้
บางทีก็ถูกเรียกว่า Permission Policy ครับ

• Management policy
  • AWS managed policy
    • AWS managed policy for job functions
  • Customer Managed Policy
• inline policy

Management policy คือ Resource ที่แยกตัวออกมาครับ
ต่อให้ไม่ทำการติดกับ IAM identity ก็สามารถคงอยู่ได้ และนอกจากนี้ยังสามารถใช้ร่วมกันได้กับ IAM identity จำนวนหลายๆตัว

inline policy คือ สิ่งที่ถูกฝังอยู่ใน IAM identity หรือจะเรียกได้ว่าเป็น Parameter ของ IAM identity ก็ว่าได้

Resource-based Policy

Policy ที่ติดกับฝั่ง AWS Resource ที่เป็นเป้าหมายของการ Request

ไม่ใช่ทุก Resource จะ Support Resource-based Policy
เราสามารถดู Resource ที่ Support ได้จากลิ้งค์ด้านล่าง

• AWS services that work with IAM - AWS Identity and Access Management

เราสามารถรวม Resource-based Policy กับ Principal เพื่อทำการควบคุมต้นทางที่ทำการ Request ได้

• AWS JSON policy elements: Principal - AWS Identity and Access Management

Principal(ต้นทางการดำเนินการ) ที่เราสามารถกำหนดได้มีตามล่างนี้ (ไม่รวมกับ IAM Group)

• AWS account กับ root user
• IAM roles
• roll session
  • Assumed-role session
  • web identity session (สำหรับ trust policy)
  • SAML session (สำหรับ trust policy)
• IAM user
• AWS STS Federated User Session
• AWS services
• all principals (anonymous users)

ที่เขียนว่า (สำหรับ trust policy) หมายถึง Principal Type สำหรับ trust policy ที่สามารถใช้ได้แค่ Principal ครับ

Principal กับ Identity หมายถึงอะไร

principal (adj) สำคัญ, เป็นส่วนใหญ่, รายใหญ่

เมื่อเราทำการตรวจสอบจาก AWS Document จะได้ความว่าดังนี้

A principal is a person or application that can make a request for an action or operation on an AWS resource. The principal is authenticated as the AWS account root user or an IAM entity to make requests to AWS. As a best practice, do not use your root user credentials for your daily work. Instead, create IAM entities (users and roles). You can also support federated users or programmatic access to allow an application to access your AWS account.

• Understanding how IAM works - AWS Identity and Access Management

อาจจะดูเข้าใจยากไปสักหน่อย แต่เมื่อตรวจสอบด้านบนในลิ้งค์บทความเดียวกัน เราจะเจอข้อความที่เขียนไว้ว่า

A person or application that uses the AWS account root user, an IAM user, or an IAM role to sign in and make requests to AWS. Principals include federated users and assumed roles.

หากใครยังไม่ค่อยเข้าใจให้ดูแผนภาพด้านล่างได้ครับ

คำว่า Principal มักจะถูกใช้กับคำว่า Identity โดยคำว่า Identity มีความหมายว่า (n) เอกลักษณ์, รูปพรรณ, หลักฐาน ครับ

ในความหมายแคบๆ(narrowly defined) ของ Principal จะหมายถึง หน่วยงานที่ไม่มีตัวตนใน AWS เช่น คน ตามในภาพนั่นเอง หรือจะเป็น Application พวก Systems Manager agent ก็ไม่มีตัวตนใน AWS ครับ

หาก Principal เหล่านั้นต้องการส่ง Request ไปยัง AWS Service จำเป็นต้องมี Authentication information อะไรสักอย่าง ทำให้เราทำเป็นต้องใช้ IAM Entity ที่มีตัวต้นใน AWS โดยสิ่งที่จะใช้เป็น Authentication สำหรับ IAM Entity คือ IAM User หรือ IAM Role ครับ

เมื่อเราได้รับ Authentication ด้วย IAM Entity เราก็จะเรียกสภาพขณะนี้ว่า Principal(broadly defined) ด้วย ยกตัวอย่างเช่น เราใช้ IAM User Sign-in ไปที่ Management Console
ส่วนประกอบ Principal ของ Resource-based Policy ก็สื่อความหมายถึง Principal(broadly defined) ครับ

สำหรับการอธิบายความหมายของ Principal กับ Identity ก็จบเพียงเท่านี้ครับ ถ้าใครลืมก็เข้ามาดูที่หัวข้อนี้ใหม่ได้ครับ

AWS STS (Security Token Service) คืออะไร

ในหัวข้อนี้เราจะมาอธิบายเกี่ยวกับ AWS STS ที่ได้โผล่มาในบทความนี้ หลายต่อหลายครั้งกันครับ

AWS STS คือ AWS Service อย่างหนึ่งครับ โดย Service นี้เวลาจะใช้ จะต้องใช้กับ AWS IAM ครับ
โดย Service นี้ มีหน้าที่ ให้บริการและสร้าง Temporary Authentication information ซึ่งจะช่วยแบ่งเบาหน้าที่ของ AWS IAM ครับ
หรือก็คือ นี่คือ ผลิตภัณฑ์ Sub-product ของ AWS IAM ครับ

การให้บริการและสร้าง Temporary Authentication information

รายการ AWS STS Operation ที่จะรับ Temporary Authentication information มีดังต่อไปนี้

• AssumeRole
• AssumeRoleWithSAML
• AssumeRoleWithWebIdentity
• DecodeAuthorizationMessage
• GetAccessKeyInfo
• GetCallerIdentity
• GetFederationToken
• GetSessionToken

โดยหากใครสนใจรายละเอียดเพิ่มเติมสามารถอ่านได้ที่ ลิ้งค์ด้านล่างนี้

ด้านล่างนี้คือแผ่นภาพที่จะรวบรวม Target กับ ต้นทาง Request ไว้ให้เข้าใจง่ายๆครับ

เมื่อสักครู่เราได้กล่าวไปเกี่ยวกับ Principal ที่สามารถกำหนดองค์ประกอบ Principal ของ Resource-based Policy ได้ดังนี้

• AWS account กับ root user
• IAM roles
• roll session
  • Assumed-role session
  • web identity session (สำหรับ trust policy)
  • SAML session (สำหรับ trust policy)
• IAM user
• AWS STS Federated User Session
• AWS services
• all principals (anonymous users)

ในส่วนนี้ค่อนข้างจะยุ่งยากเพราะในองค์ประกอบ Principal เราสามารถกำหนด "Session ที่ใช้ Temporary Authentication information" เป็นตัวมันเองได้ และกำหนด Base ของ Temporary Authentication ที่กลายเป็น Target ก็ได้เช่นกัน

ยกตัวอย่างเช่น IAM Role ไม่สามารถดำเนินการ Request ได้ด้วยตนเอง แต่เราสามารถกำหนดให้ IAM Role สามารถเป็นPrincipalได้ครับ

Federated User

Principal ที่สามารถกำหนดองค์ประกอบ Principal ได้มีหัวข้อ "AWS STS Federated User Session" เขียนไว้ ซึ่งนั่นหมายถึง Federated User ที่ถูกสร้างขึ้นจาก sts:GetFederationToken ครับ

User ภายนอกที่ได้รับการรองรับจาก IdP ภายนอก จะได้รับ IAM Role จาก sts:AssumeRoleWithWebIdentity หรือ sts:AssumeRoleWithSAML กลายเป็น Principal ที่เป็น "Session ที่รับ IAM Role ไป" ยกตัวอย่างเช่น เราต้องการทำการนิยาม Resource-based Policy ของ S3 Bucket เพื่ออนุญาต Request จาก Principal ละก็ เราจำเป็นต้องกำหนด Principal ดังต่อไปนี้

Example of specifying an IAM role session

"Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }

โดยยังสามารถเขียนให้กว้างขึ้นอีกหน่อยได้ดังนี้ (ขึ้นอยู่กับว่าต้องการกำหนดในระดับไหน)

Example of specifying an IAM role

"Principal": { "AWS": "arn:aws:iam::AWS-account-ID:role/role-name" }

Example of specifying the entire AWS account

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

วิธีเขียนองค์ประกอบ Principal ที่ต้องการทำการนิยาม trust policy ของ IAM Role เพื่อให้ User ภายนอกที่ได้รับการรองรับจาก IdP ภายนอก จะได้รับ IAM Role มีตัวอย่างดังนี้

Example Trust Policy for WebID Sessions

"Principal": { "Federated": "web-provider-name" }

Example Trust Policy for SAML Sessions

"Principal": { "Federated": "arn:aws:iam::AWS-account-ID:saml-provider/provider-name" }

ตัวอย่างเหล่านี้เขียนลงไปใน Resource-based Policy ของ S3 Bucket ก็ไม่มีความหมายอะไรครับ อาจจะดูยุ่งยาก แต่ก็ควรจะจำไว้ครับ

การส่ง Request ไปยัง AWS

ในหัวข้อสุดท้ายนี้ เราจะมาดูขั้นตอนการส่ง Request ไปยัง AWS ทั้งหมดกันครับ โดยเมื่อเขียนออกมาจะได้ประมาณภาพด้านล่างนี้ครับ

Principal จะทำวิธีการสักอย่างเพื่อทำการส่ง Request ไปยัง AWS Service โดยวิธีการจะแบ่งออกเป็นจาก Management Console และ นอกเหนือจากนั้นครับ

ในกรณีของ Management Console จะเป็นการใช้ผ่าน Console ส่วนนอกเหนือการนั้นที่เป็น Program Access (AWS CLI, AWS SDK หรือ อื่นๆ) จะเป็นการเชื่อมต่อโดยตรง ส่ง Request ไปยัง AWS Endpoint Serive (มีบางกรณีที่มีข้อยกเว้น)

Request ที่ถูกส่งมายัง AWS Serive จะถูกส่งไปยัง AWS IAM ก่อน ตามที่เขียนไว้ด้านบน แล้วใน IAM จะใช้สิ่งที่เรียกว่า AWS enforcement code ในการตรวจสอบ Authentication และ Authorization

ข้อมูลข้างใน AWS Request

ข้างใน Request จะมีข้อมูลดังต่อไปนี้อยู่ข้างใน

• Action หรือ Operation
  • ยกตัวอย่างเช่น s3:PutObject
• Resource
  • AWS Resource ที่เป็นเป้าหมาย Request
• Principal
  • ข้อมูลของ Principal
  • ข้อมูล Policy ที่เกี่ยวกับ Principal ที่ส่งมา
• environmental data
  • IP Address
  • user agent
  • SSL enabled status
  • time, etc.
• Resource Data
  • Target resource data (name, tags, etc.)

ข้อมูลเหล่านี้จะถูกรวมอยู่ใน request context และถูกใช้ในการประเมินและอนุญาต Request

การลงนามไปยัง AWS Request(signature)

จบไปสำหรับข้อมูลข้างใน AWS Request แล้ว เราจำเป็นต้องมี การเซ็นต์ หรือ signature สำหรับการส่งต่อไปยัง Authentication process ต่อ
Authentication Information ที่เราดูในหัวข้อที่ผ่านๆมา จะถูกใช้ใน signature นี้

signature นั้นมีลายละเอียด่อนข้างเยอะ เราเลยจะไม่ขอพูดในบทความนี้ แต่หากสนใจ สามารถดูเพิ่มเติมได้ที่บทความด้านล่างนี้ครับ

• Signing AWS API requests - AWS General Reference

แต่ถ้าให้อธิบายคร่าวๆ จะได้เป็นแผนภาพด้านล่างนี้ครับ

เราสามารถสร้างลายเซ็นต์(Signature)ได้ด้วยตนเอง แต่น้อยโอกาสนักที่จะได้ทำจริงๆ เพราะหากเราใช้ Tool เช่น AWS CLI หรือ AWS SDK จะทำการสร้างสิ่งเหล่านี้เองโดยอัตโนมัตินั่นเอง (ในข้อมูล Official ไม่พอข้อมูลเหล่านี้ แต่ทางผู้เขียนคิดว่า ในส่วน Management Console จะทำการจัดการเรื่องเหล่านี้ได้อย่างเรียบร้อยดี)

Request โดยทั่วไป(ที่ไม่ใช่ Request เฉพาะทางที่ไม่จำเป็นต้องมี Authentication Information)จำเป็นต้องมี Signature อยู่เสมอ หาก Signature ไม่ถูกต้อง ข้อมูลจะถูกตีกลับใน Authentication process

Authorization ที่ใช้ค่าของ Request Context

ในหัวข้อที่ผ่านมา เราคุยกันไปแล้วว่า ข้อมูลที่อยู่ใน Request จะถูกเก็บอยู่ใน Request Context

แล้ว AWS enforcement code จะทำการ Authorization ค่านั้น
ในการ Authorization นั้น Policy Type ทั้งหลายจะถูกประเมินโดยรวม แล้วสุดท้ายก็จะได้ผลลัพท์ว่า อนุญาตหรือไม่ ออกมา

พอเราแยก Pattern ออกอีกหน่อยก็จะได้รูปแบบตามด้านล่างนี้

• Implicit Deny: การปฎิเสธเนื่องจากไม่ได้รับอนุญาตจาก Policy (Default)
• Explicit Deny: การปฎิเสธเนื่องจาก Policy ได้รับการนิยามให้ปฎิเสธ
• Allow: ไม่พบ Explicit Deny และมีการอนุญาต

นอกจากนี้เรายังมีข้อมูลเพิ่มเติมเกี่ยวกับ สิทธิการ Access ในกรณีที่เป็น Account เดียวกัน และ ต่างกันมาให้ดูกันครับ (ซึ่งมีที่มามาจากการสัมมนาภาษาญี่ปุ่น(เนื้อหาข้างในเป็นภาษาญี่ปุ่น) AWS Identity and Access Management (IAM) Part1)

เท่านี้รายละเอียดขั้นตอนการส่ง Request ไปยัง AWS ทั้งหมดก็ถือว่าจบกันเพียงเท่านี้ครับ

ทิ้งท้าย

เป็นไงกันบ้างครับกับเนื้อ AWS IAM ซึ่งโดยส่วนตัวผมรู้สึกว่าเนื้อหาในคราวนี้ค่อนข้างลึก และ ซับซ้อนพอสมควร หากท่านผู้อ่านอ่านแล้วรู้สึกงง หรือไม่เข้าใจตรงไหน ผมแนะนำ ลิ้งค์ 2 บทความด้านล่างนี้น่าจะช่วยไขข้อข้องใจของท่านผู้อ่านได้ครับ

สำหรับบทความนี้ก็ถือว่าจบเพียงเท่านี้ แล้วเจอกันในบทความต่อไปครับ สวัสดีครับ / ต้า

บทความต้นฉบับ

AWS再入門ブログリレー2022 AWS IAM編 | DevelopersIO

บทความที่เกี่ยวข้อง

• Actions, resources, and condition keys for Identity And Access Management - Service Authorization Reference
• IAM JSON policy elements reference - AWS Identity and Access Management
• AWS services that work with IAM - AWS Identity and Access Management
• AWS JSON policy elements: Principal - AWS Identity and Access Management
• Understanding how IAM works - AWS Identity and Access Management
• Actions - AWS Security Token Service
• Signing AWS API requests - AWS General Reference
• AWS IAM | Identity and Access Management | Amazon Web Services
• AWS Identity and Access Management Documentation