0Pricing
Azure Fundamentals · บทเรียน

ข้อมูลประจำตัวที่จัดการเพื่อการยืนยันตัวตนแบบไร้รหัสผ่าน

กำหนดข้อมูลประจำตัวที่จัดการแบบกำหนดโดยระบบให้กับ VM หรือ App Service มอบสิทธิ์ RBAC เพื่อเข้าถึง Key Vault และ Blob Storage แล้วนำข้อมูลลับออกจากโค้ดแอปพลิเคชัน

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

ปัญหาของข้อมูลรับรองที่จัดเก็บไว้

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

ข้อมูลระบุตัวตนที่มีการจัดการคืออะไร

ข้อมูลระบุตัวตนที่มีการจัดการคือ ตัวการบริการ ใน Microsoft Entra ID ที่ระบบจัดการโดยอัตโนมัติและเชื่อมโยงกับทรัพยากร Azure เช่น VM, App Service หรือ Function App แพลตฟอร์ม Azure จะสร้างและดูแลข้อมูลรับรองของข้อมูลระบุตัวตน รวมถึงหมุนเวียนข้อมูลดังกล่าวเป็นประจำ ทำให้โค้ดของคุณไม่ต้องจัดการรหัสผ่านหรือข้อมูลลับ แอปพลิเคชันที่ทำงานบนทรัพยากรจะเรียกปลายทาง บริการข้อมูลเมทาดาทาของอินสแตนซ์ Azure (IMDS) ที่ http://169.254.169.254 เพื่อรับโทเคน OAuth อายุสั้น แล้วนำโทเคนนั้นไปแสดงต่อบริการ Azure

# Get a token from IMDS (runs inside an Azure VM or App Service)
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/' \
  -H 'Metadata: true'

แบบกำหนดโดยระบบเทียบกับแบบกำหนดโดยผู้ใช้

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

# Enable system-assigned managed identity on an App Service
az webapp identity assign \
  --resource-group myRG \
  --name myWebApp

# Create and assign a user-assigned identity
az identity create --name mySharedIdentity --resource-group myRG
az webapp identity assign \
  --resource-group myRG \
  --name myWebApp \
  --identities mySharedIdentity

การให้สิทธิ์ RBAC

หลังจากเปิดใช้งานข้อมูลระบุตัวตนที่มีการจัดการแล้ว คุณต้องให้ สิทธิ์ RBAC แก่ข้อมูลระบุตัวตนนั้นบนทรัพยากร Azure เป้าหมาย ตัวอย่างเช่น หากต้องการอนุญาตให้ App Service อ่าน Blob ให้กำหนดบทบาท Storage Blob Data Reader ให้กับข้อมูลระบุตัวตนที่มีการจัดการของ App Service บนบัญชีพื้นที่จัดเก็บ การกำหนด RBAC ยึดตาม หลักการให้สิทธิ์น้อยที่สุด — ให้เฉพาะสิทธิ์ขั้นต่ำที่จำเป็นเท่านั้น อย่ากำหนด Owner หรือ Contributor ให้กับข้อมูลระบุตัวตนที่มีการจัดการ เว้นแต่จำเป็นอย่างยิ่ง

# Get the managed identity object ID
PRINCIPAL_ID=$(az webapp identity show \
  --resource-group myRG --name myWebApp \
  --query principalId --output tsv)

# Assign Storage Blob Data Reader role
az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role 'Storage Blob Data Reader' \
  --scope '/subscriptions/<sub>/resourceGroups/myRG/providers/Microsoft.Storage/storageAccounts/mystorageacct'

การใช้ DefaultAzureCredential ในโค้ด

Azure SDK มีคลาส DefaultAzureCredential ที่ลองใช้วิธีการตรวจสอบสิทธิ์หลายรูปแบบตามลำดับโดยอัตโนมัติ ได้แก่ ตัวแปรสภาพแวดล้อม ข้อมูลระบุตัวตนของภาระงาน ข้อมูลระบุตัวตนที่มีการจัดการ Azure CLI, Visual Studio และวิธีอื่น ๆ เมื่อแอปพลิเคชันทำงานบน Azure เช่น App Service, VM หรือ Function App DefaultAzureCredential จะใช้ข้อมูลระบุตัวตนที่มีการจัดการโดยอัตโนมัติโดยไม่ต้องเปลี่ยนโค้ด ในเครื่อง นักพัฒนาจะตรวจสอบสิทธิ์ผ่านเซสชัน Azure CLI ข้อมูลรับรองคลาสเดียวนี้ทำงานได้ในทุกสภาพแวดล้อมโดยไม่ต้องใช้ตรรกะแบบมีเงื่อนไข

# Python example using DefaultAzureCredential
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
client = BlobServiceClient(
  account_url='https://mystorageacct.blob.core.windows.net',
  credential=credential
)
blobs = client.get_container_client('mycontainer').list_blobs()
for blob in blobs:
    print(blob.name)

ข้อมูลระบุตัวตนที่มีการจัดการกับ Azure Key Vault

รูปแบบที่ใช้กันทั่วไปคือการใช้ข้อมูลระบุตัวตนที่มีการจัดการเพื่อเข้าถึงข้อมูลลับใน Azure Key Vault ขณะทำงาน แทนที่จะจัดเก็บรหัสผ่านฐานข้อมูลไว้ในการตั้งค่าแอปพลิเคชัน ให้จัดเก็บไว้ใน Key Vault และกำหนดบทบาท Key Vault Secrets User บนห้องนิรภัยให้กับข้อมูลระบุตัวตนที่มีการจัดการของแอป เมื่อเริ่มต้นทำงาน แอปพลิเคชันจะดึงข้อมูลลับจาก Key Vault โดยใช้ DefaultAzureCredential รูปแบบนี้ทำให้มั่นใจได้ว่าข้อมูลลับจะไม่ถูกจัดเก็บไว้ในโค้ด ไฟล์การกำหนดค่า หรือตัวแปรสภาพแวดล้อม — ข้อมูลลับจะมีอยู่เฉพาะใน Key Vault และถูกดึงมาใช้ชั่วคราวเท่านั้น

# Python: Read a Key Vault secret using managed identity
from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient

credential = DefaultAzureCredential()
client = SecretClient(
  vault_url='https://mykeyvault.vault.azure.net/',
  credential=credential
)
secret = client.get_secret('DatabasePassword')
print('Secret value retrieved successfully')

ข้อมูลระบุตัวตนที่มีการจัดการสำหรับการเข้าถึง Azure SQL

Azure SQL Database รองรับ การตรวจสอบสิทธิ์ด้วย Entra ID ซึ่งหมายความว่าข้อมูลระบุตัวตนที่มีการจัดการสามารถตรวจสอบสิทธิ์กับ SQL ได้โดยไม่ต้องใช้ชื่อผู้ใช้หรือรหัสผ่าน หากต้องการเปิดใช้งาน ให้กำหนดผู้ดูแลระบบ Entra ID บนเซิร์ฟเวอร์ SQL จากนั้นเรียกใช้คำสั่ง CREATE USER ในฐานข้อมูลเป้าหมายสำหรับชื่อที่แสดงของข้อมูลระบุตัวตนที่มีการจัดการ และกำหนดบทบาทฐานข้อมูลที่เหมาะสมให้ แอปพลิเคชันเชื่อมต่อโดยใช้ DefaultAzureCredential ของ Azure SDK และโทเคนการเข้าถึงที่กำหนดขอบเขตเป็น https://database.windows.net/ โดยไม่ใช้รหัสผ่านโดยสิ้นเชิง

-- In Azure SQL: create a user for the managed identity
CREATE USER [myWebApp] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [myWebApp];
ALTER ROLE db_datawriter ADD MEMBER [myWebApp];

ข้อมูลระบุตัวตนที่มีการจัดการสำหรับภาระงาน AKS

ใน Azure Kubernetes Service พ็อดแต่ละรายการสามารถรับโทเคนข้อมูลระบุตัวตนที่มีการจัดการได้โดยใช้ ข้อมูลระบุตัวตนของภาระงาน ซึ่งเป็นรุ่นต่อจาก AAD Pod Identity คุณจะสร้างข้อมูลระบุตัวตนที่มีการจัดการแบบกำหนดโดยผู้ใช้ เชื่อมโยงข้อมูลดังกล่าวกับตัวออกโทเคน OIDC ของ AKS ใส่คำอธิบายประกอบให้บัญชีบริการ Kubernetes และเว็บฮุก Azure Workload Identity จะเพิ่มตัวแปรสภาพแวดล้อมที่จำเป็น เพื่อให้ DefaultAzureCredential ของพ็อดรับโทเคนได้ วิธีนี้ขยายการตรวจสอบสิทธิ์โดยไม่ใช้รหัสผ่านไปยังไมโครเซอร์วิสแบบคอนเทนเนอร์ โดยไม่ต้องจัดเก็บข้อมูลลับไว้ในออบเจ็กต์ Kubernetes Secrets

# Create federated identity credential for AKS workload identity
az identity federated-credential create \
  --name myFederatedCredential \
  --identity-name mySharedIdentity \
  --resource-group myRG \
  --issuer $(az aks show --resource-group myRG --name myAKS --query 'oidcIssuerProfile.issuerUrl' -o tsv) \
  --subject 'system:serviceaccount:default:myapp-sa' \
  --audiences 'api://AzureADTokenExchange'

การตรวจสอบการเข้าถึงของข้อมูลระบุตัวตนที่มีการจัดการ

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

# Query Entra ID sign-in logs for a managed identity
az monitor activity-log list \
  --resource-group myRG \
  --caller myWebApp \
  --start-time 2024-06-01 \
  --output table

การย้ายจากสตริงการเชื่อมต่อ

หากปัจจุบันแอปพลิเคชันของคุณใช้สตริงการเชื่อมต่อหรือคีย์ API ให้ย้ายไปใช้ข้อมูลระบุตัวตนที่มีการจัดการในสามขั้นตอน ได้แก่ ขั้นตอนที่ 1 — เปิดใช้งานข้อมูลระบุตัวตนที่มีการจัดการบนทรัพยากรประมวลผล ขั้นตอนที่ 2 — กำหนดบทบาท RBAC ที่เหมาะสมให้กับข้อมูลระบุตัวตนบนบริการเป้าหมายแต่ละรายการ ขั้นตอนที่ 3 — อัปเดตโค้ดแอปพลิเคชันให้ใช้ DefaultAzureCredential แทนสตริงการเชื่อมต่อ นำสตริงการเชื่อมต่อออกจากการกำหนดค่า App Service และ Key Vault หลังจากตรวจสอบการย้ายเรียบร้อยแล้ว โดยทั่วไปการย้ายนี้ทำได้ด้วยการเปลี่ยนแปลงโค้ดเพียงเล็กน้อยในแอปพลิเคชันที่ใช้ Azure SDK รุ่นใหม่

สรุปประโยชน์ด้านความปลอดภัย

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

ตรวจสอบความเข้าใจอย่างรวดเร็ว

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

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า ข้อมูลระบุตัวตนที่มีการจัดการช่วยกำจัดข้อมูลรับรองที่จัดเก็บไว้ โดยมอบข้อมูลระบุตัวตน Entra ID ที่ Azure จัดการให้อัตโนมัติแก่ทรัพยากร Azure, DefaultAzureCredential ใน Azure SDK จะใช้ข้อมูลระบุตัวตนที่มีการจัดการใน Azure และใช้ข้อมูลรับรองของนักพัฒนาในเครื่องโดยอัตโนมัติอย่างโปร่งใส และ การกำหนดบทบาท RBAC ในบริการเป้าหมายจะควบคุมสิ่งที่ข้อมูลระบุตัวตนดังกล่าวเข้าถึงได้ ต่อไปเราจะสำรวจ Azure Service Bus สำหรับการส่งข้อความระหว่างส่วนประกอบของแอปพลิเคชันที่แยกออกจากกัน

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

บทเรียน “ข้อมูลประจำตัวที่จัดการเพื่อการยืนยันตัวตนแบบไร้รหัสผ่าน” ฟรีหรือไม่

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

คุณจะเรียนรู้อะไรในบทเรียน “ข้อมูลประจำตัวที่จัดการเพื่อการยืนยันตัวตนแบบไร้รหัสผ่าน”

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

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

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

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

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

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

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

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

  1. ข้อมูลประจำตัวที่จัดการเพื่อการยืนยันตัวตนแบบไร้รหัสผ่าน
  2. Azure Service Bus สำหรับการส่งข้อความแบบแยกส่วน
  3. Azure Container Apps
  4. เวิร์กโฟลว์นักพัฒนาแบบต้นจนจบ
← กลับไปที่ Azure Fundamentals