สวัสดีครับทุกท่าน กลับมาพบกันเหมือนเดิมครับ สำหรับบทความตอนนี้ของผมจะเป็นเรื่องราวของ Security ใน Microsoft Azure ครับ ซึ่งต้องบอกว่ามีรายละเอียดเยอะมากเลยครับ แต่สำหรับบทความนี้ผมจะหยิบเอาเรื่องหนึ่งมานำเสนอเล่าสู่กันฟังครับ และต้องบอกว่าเรื่องดังกล่าวนี้ถือเป็นพื้นฐานสำคัญสำหรับท่านผู้อ่านที่ทำหน้าที่เป็นผู้ดูแลระบบ (Cloud Admintrator), Cloud Architect, Consultant ตลอดจนท่านที่สนใจเรื่องราวของความปลอดภัยใน Microsoft Azure ครับ เรื่องดังกล่าวนี้ คือ "Access Control" ใน Microsoft Azure ครับ
Access Control คืออะไร?
ผมเชื่อว่าท่านผู้อ่านโดยส่วนใหญ่น่าจะเคยได้ยินตลอดจนรู้จักกับ Access Control กันมาอยู่แล้วครับ เช่น ใน Active Directory Domain Service (AD DS) เรื่องของ Access Control คือ การกำหนดสิทธิ์ (Privileges หรือ Permissions) ในการเข้าถึงตลอดจนการใช้งาน Resources ต่างๆ ใน Forest/Domain ของ Actvie Directory Domain Service (AD DS) ครับ โดยใน AD DS จะมีรูปแบบการกำหนดสิทธิ์หรือ Access Control ได้ 2 แบบ คือ
- Shared Permissions
- NTFS Permisssions
โดยมีผู้ดูแลระบบหรือท่านที่เกี่ยวข้องเป็นผู้พิจารณาและกำหนดสิทธิ์ต่างๆ ให้กับผู้ใช้งานในองค์กรครับ สำหรับเรื่องราวของ Access Control นั้นจะเกี่ยวกับกระบวนการหนึ่งที่เรียกว่า "Authorization" ซึ่งจะเป็นกระบวนที่เกิดหลังจากกระบวนการแรกที่เรียกว่า "Authentication" ครับ และท่านผู้อ่านท่านใดที่ศึกษาเกี่ยวกับเรื่องราวของ Security น่าจะคุ้นเคยกับคอนเซปที่เรียกว่า "AAA" ผมเรียกว่า Triple A หรือ A สามตัวครับ โดย A แต่ละตัวย่อมาจาก
A ตัวที่ 1 = Authentication, เป็นกระบวนเกี่ยวกับการพิสูจน์ตัวตน (Identity) ตัวอย่างของ Services ที่ทำหน้าที่ดังกล่าว เช่น Active Directory Domain Service (AD DS), Azure Active Directory (Azure AD), เป็นต้น
A ตัวที่ 2 = Authorization, เป็นกระบวนเกี่ยวกับกำหนดสิทธิ์ (Privileges หรือ Permissions) ในการเข้าถึง Resources ต่างๆ ตัวอย่าง เช่น ถ้าใน AD DS ก็จะเป็น Shared และ NTFS Permissions ที่ได้อธิบายไว้ข้างต้น, ถ้าเป็น Azure AD ก็จะเป็น Role-Based Access Control หรือ RBAC ซึ่งเป็น Feature หนึ่งใน Azure AD ครับ
A ตัวที่ 3 = Accounting หรือ Auditing, เป็นการกระบวนการบันทึกเหตุการณ์ต่างๆ ที่เกิดขึ้น โดยเหตุการณ์ดังกล่าวนี้ ก็จะเป็นข้อมูลที่เก็บอยู่ใน Logs ต่างๆ เช่น Security Log, Activity Log, เป็นต้น
สำหรับบทความนี้ผมจะโฟกัสที่ A ตัวที่ 2 คือ Authorization หรือ Access Control ที่เกี่ยวข้องกับ Microsoft Azure เพราะฉะนั้นก็จะเกี่ยวข้องกับ Feature หนึ่งใน Azure AD คือ Role-Based Access Control (RBAC) ครับ
ส่วนประกอบของ Role-Based Access Control (RBAC)
อย่างที่ผมได้อธิบายคร่าวๆ ไว้ข้างต้นว่า RBAC เป็น Feature หนึ่งใน Azure Active Directory (Azure AD) ที่ใช้สำหรับการทำ Access Control นั่นก็คือ การกำหนดหรือ Assign สิทธิ์ (Privileges หรือ Permissions) หรือระดับการเข้าถึงเพื่อใช้ในการบริหารจัดการและใช้งาน Resources ต่างๆ ใน Microsoft Azure ครับ เพราะฉะนั้นท่านผู้อ่านท่านใดที่เป็นผู้ดูแลระบบท่านจะต้องรู้จักและเข้าใจคอนเซปตลอดจนเรื่องราวต่างๆ ของ RBAC ครับ โดยตัวของ RBAC ประกอบไปด้วยส่วนประกอบต่างๆ ดังนี้:
- Security Principals (SPs)
- Role Definitions
- Role Assignment
Security Principals (SPs)
คือ สิ่งที่อธิบายหรืออ้างอิงถึง Azure AD Objects ที่เราสามารถกำหนดหรือ Assign สิทธิ์ ได้ครับ ผมอยากให้ท่านผู้อ่านลองนึกดูครับว่า มันคือ Azure AD Objects ? ครับ..... คำตอบ คือ User Accounts, Group Accounts, เป็นต้นครับ Security Principals (SPs) มีอะไรบ้าง สามารถดูจากรูปด้านล่างครับ
Security Principals (User Account)
เรามาเริ่มกันที่ User Accounts เป็น Object ที่ใช้แทนหรือสำหรับผู้ใช้งาน และผมเชื่อว่าทุกท่านน่าจะรู้จักและคุ้นเคยกับ User Accounts เป็นอย่างดี เพราะทุกคนต้องมีเพื่อใช้เป็น Identity สำหรับเข้าถึงหรือใช้งาน Resources ต่างๆ โดย User Accounts ใน Azure AD จะมี 3 ชนิด คือ
1. Cloud User Accounts
2. Hybrid User Accounts
3. External User Accounts
Security Principals (Group Account)
เราใช้ SPs ชนิดนี้เพื่อช่วยทำให้การทำ Access Control มีความสะดวกและยืดหยุ่นมากขึ้น และตาม Best Practices ของ Microsoft ควร(Privileges หรือ Permissions) ให้กับ Group Accounts นั่นหมายความว่าใน Azure AD เราควรกำหนดหรือ Assign Group Accounts เข้าไปยัง RBAC Roles ที่เกี่ยวข้องหรือที่ต้องการ
Security Principals (Service Principal)
คือ Identity ของ Applications ต่างๆ ที่เราได้มีการ Deploy ใช้งาน เพื่อทำให้เราสามารถกำหนดหรือ Assign สิทธิ์ (Privileges หรือ Permissions) ให้กับ Applications เพื่อให้ Applications ดังกล่าวเข้าถึง Azure Resources ต่างๆ ได้ครับ การที่ท่านผู้อ่านจะสร้าง Identity ให้กับ Application หรือ Application Identity ได้นั้น ท่านผู้อ่านจะต้องนำเอา Application ดังกล่าวมาทำการ Registered กับ Azure AD โดยใช้ App Registrations ดังรูปด้านล่างครับ
Security Principals (Managed Identity)
เป็น Feature หนึ่งใน Azure AD ที่ทำให้เราสามารถกำหนดสิทธิ์ (Privileges หรือ Permissions)ให้กับ Azure Services เพื่อให้เข้าถึง Azure Resources อื่นๆ ได้ครับ
Role Definitions
ส่วนประกอบต่อมาของ RBAC คือ Role Definitions ครับ โดย Role Definitions คือ ชุดของสิทธิ์ (Privileges หรือ Permissions) ต่างๆ ที่จะใช้กับ Azure Resources ต่างๆ เช่น Read, Write, Delete, เป็นต้น ดังรูปด้านล่างครับ
โดยเราสามารถใช้ Role Definitions ที่ทาง Microsoft Azure เตรียมเอาไว้แล้วผ่านทาง RBAC ที่เรียกว่า "Built-In RBAC Roles" ครับ โดย Built-In ดังกล่าว แบ่งได้เป็น 2 รูปแบบ ดังนี้:
รูปแบบที่ 1 เรียกว่า Azure Active Directory Built-In RBAC ซึ่งเป็น RBAC Roles ต่างๆ ที่เอาไว้ใช้สำหรับการบริหารจัดการ Azure AD Tenant ดังรูปด้านล่าง
รูปแบบที่ 2 เรียกว่า Azure Active Directory Resources Built-In RBAC ซึ่งเป็น RBAC Roles ต่างๆ ที่เอาไว้ใช้สำหรับการบริหารจัดการ Azure AD Resources ต่างๆ ดังรูปด้านล่างครับ
Role Assignment
ส่วนประกอบสุดท้ายของ RBAC คือ Role Assignment คือ ส่วนประกอบที่ใช้สำหรับการกำหนดหรือ Assign สิทธิ์ (Privileges หรือ Permissions) นั่นก็คือการ Assign Security Principals (SPs) เข้าไปยัง RBAC Roles ที่ต้องการ จากนั้นทำการกำหนดขอบเขต (Scope) ตลอดจนระดับ (Levels) ของสิทธิ์ดังกล่าวที่กำหนดผ่านทาง RBAC ว่ามีขอบเขต (Scopes) เป็นอย่างไร โดยขอบเขตที่ว่านี้จะอ้างอิงจาก "Azure Hierarchy" ขององค์กรนั้นๆ ว่าเป็นลักษณะเป็นอย่างไร โดยปรกติจะมี ขอบเขตและระดับต่างๆ ดังรูปด้านล่าง
Scopes และ Levels จากรูปด้านบนที่เราสามารถกำหนดได้ คือ Management Group, Subscription, Resouce Group, และ Resouce ครับ สำหรับ Best Practices ของการทำ Access Control นั้น Microsoft แนะนำให้กำหนดหรือ Assign สิทธิ์ที่ระดับ (Scope และ Level) ของ Azure Hierarchy ที่สูงที่สุดเท่าที่จะเป็นได้หรือตามความต้องการเพราะเมื่อกำหนดสิทธิ์เรียบร้อยแล้ว สิทธิ์ดังกล่าวที่ถูกกำหนดไว้ก็จะถ่ายทอดลงมายังระดับหรือ Level ที่อยู่ด้านล่างของ Azure Hierarchy ตามรูปด้านบนครับ ซึ่งเราเรียกคอนเซปนี้ว่า "Inheritance" ครับ
และภาพรวมของส่วนประกอบต่างๆ ของ RBAC ที่ผมอธิบายไป จะมีหน้าตาตามรูปด้านล่างครับ
และทั้งหมดนี้คือเรื่องราวของ RBAC ที่ผมหยิบเอามานำเสนอทุกท่านครับผม.....
ขอบคุณมากครับ เข้าใจมากขึ้นเลย
ตอบลบขอบคุณเช่นกันครับ
ลบ