Azure Fundamentals · บทเรียน

การออกแบบข้อมูลประจำตัวและการเข้าถึงระดับองค์กร

บทเรียน 4 จาก 413 ขั้นตอน

การออกแบบข้อมูลประจำตัวและการเข้าถึงระดับองค์กร เป็นบทเรียน Azure Fundamentals ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Azure Fundamentals และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

ข้อมูลประจำตัวในระดับองค์กร

ในสภาพแวดล้อม Azure ระดับองค์กร การจัดการข้อมูลประจำตัวและการเข้าถึงต้องรองรับการสมัครใช้งานหลายร้อยรายการ ผู้ใช้หลายพันคน และทีมหลายสิบทีม ซึ่งแต่ละทีมมีความต้องการเข้าถึงทรัพยากรแตกต่างกัน โมเดลข้อมูลประจำตัวที่ออกแบบมาอย่างดีช่วยป้องกันทั้งการให้สิทธิ์มากเกินไป (ผู้ใช้เข้าถึงได้มากเกินความจำเป็น) และการให้สิทธิ์น้อยเกินไป (ผู้ใช้ไม่สามารถทำงานของตนได้) พื้นฐานสำคัญคือ Microsoft Entra ID ที่ทำงานร่วมกับ Azure RBAC และเครื่องมือกำกับดูแลอย่าง Privileged Identity Management (PIM)

ทบทวนพื้นฐาน RBAC

Azure Role-Based Access Control (RBAC) มอบสิทธิ์การเข้าถึงผ่านองค์ประกอบสามอย่าง:

ผู้ควบคุมด้านความปลอดภัย — ใคร (ผู้ใช้ กลุ่ม ผู้ควบคุมบริการ หรือข้อมูลประจำตัวที่มีการจัดการ)
คำจำกัดความบทบาท — ทำอะไรได้บ้าง (ชุดการดำเนินการที่อนุญาต เช่น 'Contributor')
ขอบเขต — ที่ใด (กลุ่มการจัดการ การสมัครใช้งาน กลุ่มทรัพยากร หรือทรัพยากรแต่ละรายการ)

การรวมองค์ประกอบทั้งสามเข้าด้วยกันจะสร้างการกำหนดบทบาท บทบาทจะถ่ายทอดลงมาตามลำดับชั้น โดยบทบาทที่กำหนดในกลุ่มการจัดการจะมีผลกับการสมัครใช้งานทั้งหมดที่อยู่ภายใต้กลุ่มนั้น

# Assign the Reader role at a management group level:
az role assignment create \
  --assignee 'user@company.com' \
  --role 'Reader' \
  --scope '/providers/Microsoft.Management/managementGroups/LandingZones'

บทบาทที่มีมาให้เทียบกับบทบาทแบบกำหนดเอง

Azure มีบทบาทที่มีมาให้มากกว่า 100 บทบาท ซึ่งครอบคลุมสถานการณ์ทั่วไป (Owner, Contributor, Reader และบทบาทเฉพาะบริการ) สำหรับกรณีการใช้งานระดับองค์กรส่วนใหญ่ บทบาทที่มีมาให้ก็เพียงพอ อย่างไรก็ตาม หากคุณต้องการสิทธิ์ที่ไม่ตรงกับบทบาทที่มีมาให้ เช่น บทบาทที่อ่าน VMs ได้แต่ลบไม่ได้ คุณสามารถสร้างบทบาทแบบกำหนดเองที่มีสิทธิ์ตรงตามความต้องการได้อย่างแม่นยำ โดยยึดหลักสิทธิ์เท่าที่จำเป็น

# Create a custom role:
az role definition create --role-definition '{
  "Name": "VM Operator",
  "Description": "Can start and stop VMs but cannot create or delete them",
  "Actions": [
    "Microsoft.Compute/virtualMachines/start/action",
    "Microsoft.Compute/virtualMachines/powerOff/action",
    "Microsoft.Compute/virtualMachines/read"
  ],
  "NotActions": [],
  "AssignableScopes": ["/subscriptions/<subscription-id>"]
}'

การกำหนดสิทธิ์การเข้าถึงตามกลุ่ม

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

# Create a group and assign a role to the group:
az ad group create \
  --display-name 'ProductionContributors' \
  --mail-nickname 'prod-contributors'

az role assignment create \
  --assignee '<group-object-id>' \
  --role 'Contributor' \
  --scope '/subscriptions/prod-subscription-id'

Privileged Identity Management (PIM)

Privileged Identity Management (PIM) คือบริการของ Entra ID ที่ให้สิทธิ์การเข้าถึงระดับสูงแบบทันเวลา (JIT) ไปยังทรัพยากร Azure และบทบาท Entra ID แทนที่จะมีสิทธิ์ Owner หรือ Global Administrator อย่างถาวร ผู้ใช้จะมีสิทธิ์ขอใช้งานบทบาทระดับสูง และต้องส่งคำขอเปิดใช้งานเมื่อจำเป็นต้องใช้สิทธิ์ที่สูงขึ้น การเปิดใช้งานอาจกำหนดให้ใช้ MFA ระบุเหตุผล และได้รับอนุมัติจากผู้อนุมัติที่กำหนดไว้

# Workflow with PIM:
# 1. Security team makes 'alice@company.com' eligible for 'Owner' on prod subscription
# 2. Alice requests activation via PIM portal or myaccess.microsoft.com
# 3. Alice provides justification: 'Emergency patching for CVE-2026-1234'
# 4. Manager approves the request (optional step)
# 5. Alice receives Owner access for 4 hours, then access expires automatically
# 6. All activation events are logged in Entra ID audit logs

ประโยชน์ของ PIM ในองค์กร

PIM มอบประโยชน์ด้านความปลอดภัยหลายประการสำหรับสภาพแวดล้อมระดับองค์กร:

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

การออกแบบโมเดล RBAC

โดยทั่วไป โมเดล RBAC ระดับองค์กรที่ออกแบบมาอย่างดีจะมีชั้นต่าง ๆ ดังนี้:

ระดับกลุ่มการจัดการ — สิทธิ์ดูในวงกว้างสำหรับทีมกำกับดูแล และการกำหนดนโยบาย
ระดับการสมัครใช้งาน — สิทธิ์ Contributor ระดับทีมสำหรับทีมแอปพลิเคชันที่จัดการการสมัครใช้งานหนึ่งรายการ
ระดับกลุ่มทรัพยากร — บทบาทเฉพาะบริการ (เช่น Storage Blob Contributor สำหรับแอปที่ต้องการเข้าถึง Blob เท่านั้น)
ระดับทรัพยากร — ใช้เฉพาะกรณีพิเศษที่ต้องการการควบคุมแบบละเอียด

Service Principal และข้อมูลประจำตัวที่มีการจัดการ

แอปพลิเคชันและกระบวนการอัตโนมัติไม่ควรใช้บัญชีผู้ใช้เพื่อยืนยันตัวตนกับ Azure แต่ควรใช้สิ่งต่อไปนี้:

Service Principal — การลงทะเบียนแอปพลิเคชันใน Entra ID ที่มีรหัสไคลเอ็นต์และข้อมูลลับหรือใบรับรอง ใช้โดยไปป์ไลน์ CI/CD และระบบอัตโนมัติภายในองค์กร
ข้อมูลประจำตัวที่มีการจัดการ — ข้อมูลรับรองที่จัดการโดยอัตโนมัติสำหรับทรัพยากรที่โฮสต์บน Azure (VM, App Service, AKS) จึงไม่ต้องจัดการหรือเปลี่ยนข้อมูลลับ

กำหนด บทบาท RBAC ขั้นต่ำที่จำเป็น ให้กับ Service Principal และข้อมูลประจำตัวที่มีการจัดการ

# Assign a role to a managed identity:
az role assignment create \
  --assignee-object-id '<managed-identity-object-id>' \
  --assignee-principal-type ServicePrincipal \
  --role 'Storage Blob Data Contributor' \
  --scope '/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>'

การเข้าถึงตามเงื่อนไขสำหรับการเข้าถึงทรัพยากร

นโยบายการเข้าถึงตามเงื่อนไขใน Entra ID ช่วยเพิ่มข้อมูลประกอบการตัดสินใจยืนยันตัวตน สำหรับการจัดการทรัพยากร Azure คุณสามารถกำหนดให้การเข้าถึงระดับผู้ดูแลระบบ (พอร์ทัล Azure, CLI) อนุญาตเฉพาะจากแหล่งต่อไปนี้:

อุปกรณ์ที่เป็นไปตามข้อกำหนด (จัดการโดย Intune)
ตำแหน่งที่ระบุชื่อ (เครือข่ายองค์กรหรือ VPN)
หลังจากใช้ MFA (บังคับใช้เสมอสำหรับการดำเนินการที่มีสิทธิ์ระดับสูง)

การผสานการเข้าถึงตามเงื่อนไขเข้ากับ PIM ช่วยสร้างมาตรการรักษาความปลอดภัยที่แข็งแกร่งมากสำหรับการเข้าถึง Azure ในระดับผู้ดูแลระบบ

การตรวจสอบการเข้าถึง

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

บัญชีสำหรับการเข้าถึงฉุกเฉิน

ทุกองค์กรควรรักษาบัญชีสำหรับการเข้าถึงฉุกเฉิน (บัญชีฉุกเฉิน)ไว้อย่างน้อยสองบัญชี — เป็นบัญชีผู้ดูแลระบบส่วนกลางที่ไม่อยู่ภายใต้ข้อกำหนดการเข้าถึงตามเงื่อนไขหรือ MFA (แต่ใช้กุญแจฮาร์ดแวร์ FIDO2 แทน) บัญชีเหล่านี้ใช้เฉพาะเมื่อระบบ Entra ID หรือ MFA ไม่พร้อมใช้งาน และไม่สามารถเข้าถึงบัญชีผู้ดูแลระบบตามปกติได้ การใช้งานบัญชีสำหรับการเข้าถึงฉุกเฉินควรทำให้เกิดการแจ้งเตือนความปลอดภัยทันที และต้องได้รับการตรวจสอบอย่างเข้มงวด

ตรวจสอบความเข้าใจ

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

ตอบคำถามในบทเรียนแบบโต้ตอบ

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า RBAC ระดับองค์กรใช้การกำหนดสิทธิ์ตามกลุ่มในขอบเขตกลุ่มการจัดการ การสมัครใช้งาน และกลุ่มทรัพยากร; การจัดการข้อมูลประจำตัวที่มีสิทธิ์ระดับสูงมอบสิทธิ์เข้าถึงแบบให้ตรงเวลาที่ต้องใช้ เพื่อกำจัดบทบาทผู้ดูแลระบบถาวร และควรใช้ข้อมูลประจำตัวที่มีการจัดการและService Principalสำหรับการยืนยันตัวตนของแอปพลิเคชันแทนบัญชีผู้ใช้ ขอแสดงความยินดี — คุณเรียนจบส่วนสถาปัตยกรรมและการกำกับดูแลระดับองค์กรของหลักสูตร AZ-900 แล้ว!

เริ่มต้นได้ฟรี

เรียนรู้ Azure Fundamentals ด้วย AI tutor — ฟรี

เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป

คอร์ส: 30
บทเรียน: 120

เริ่มเรียนฟรี ดูหลักสูตรเต็ม

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

บทเรียน “การออกแบบข้อมูลประจำตัวและการเข้าถึงระดับองค์กร” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การออกแบบข้อมูลประจำตัวและการเข้าถึงระดับองค์กร” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Azure Fundamentals ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การออกแบบข้อมูลประจำตัวและการเข้าถึงระดับองค์กร”

ออกแบบแบบจำลอง RBAC ขนาดใหญ่โดยใช้กลุ่มการจัดการ บทบาทแบบกำหนดเอง และ Privileged Identity Management เพื่อบังคับใช้การเข้าถึงแบบทันเวลาสำหรับการดำเนินการกับข้อมูลสำคัญ คุณปฏิบัติ Azure Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Azure Fundamentals หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Azure Fundamentals บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “การออกแบบข้อมูลประจำตัวและการเข้าถึงระดับองค์กร” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Azure Fundamentals นี้ได้ไหม

ได้ บทเรียน Azure Fundamentals ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

ภาพรวมกรอบการนำคลาวด์มาใช้
โซนรองรับการใช้งาน Azure
โทโพโลยีเครือข่ายแบบฮับและสโปก
การออกแบบข้อมูลประจำตัวและการเข้าถึงระดับองค์กร

← กลับไปที่ Azure Fundamentals