แชร์ผ่าน


สถาปัตยกรรมความปลอดภัยการตรวจสอบสิทธิ์ใน Test Engine (ตัวอย่าง)

หมายเหตุ

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

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

ภาพรวมวิธีการพิสูจน์ตัวตน

Test Engine รองรับวิธีการตรวจสอบสิทธิ์หลักสองวิธี:

  • การตรวจสอบสถานะการจัดเก็บข้อมูล - ขึ้นอยู่กับคุกกี้เบราว์เซอร์ถาวรและสถานะการจัดเก็บข้อมูล
  • การตรวจสอบสิทธิ์ตามใบรับรอง - ขึ้นอยู่กับใบรับรอง X.509 และ Dataverse การรวม

ทั้งสองวิธีได้รับการออกแบบมาเพื่อรองรับข้อกำหนดด้านความปลอดภัยสมัยใหม่ รวมถึงการตรวจสอบสิทธิ์แบบหลายปัจจัย (MFA) และนโยบายการเข้าถึงแบบมีเงื่อนไข

สถาปัตยกรรมการตรวจสอบสถานะการจัดเก็บข้อมูล

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

ภาพรวมของกระบวนการตรวจสอบสิทธิ์ใน Test Engine

การนำการป้องกันข้อมูลของ Windows ไปใช้

การใช้งานสถานะการจัดเก็บข้อมูลในเครื่องใช้ Windows Data Protection API (DPAPI) เพื่อการจัดเก็บข้อมูลที่ปลอดภัย:

ภาพรวมของการตรวจสอบสิทธิ์โดยใช้ Windows Data Protection API (DPAPI) ในเครื่อง

ข้อควรพิจารณาด้านความปลอดภัย

สถาปัตยกรรมความปลอดภัยสถานะการจัดเก็บข้อมูลประกอบด้วย:

  • การปกป้องโทเค็นการตรวจสอบสิทธิ์ที่ไม่ได้ใช้งานโดยใช้การเข้ารหัส DPAPI
  • รองรับ Microsoft Entra MFA และนโยบายการเข้าถึงแบบมีเงื่อนไข
  • การแยกแซนด์บ็อกซ์ผ่านบริบทเบราว์เซอร์ของ Playwright
  • การปฏิบัติตามนโยบายอายุการใช้งานเซสชัน Microsoft Entra

สถาปัตยกรรมการตรวจสอบสิทธิ์ตามใบรับรอง

การตรวจสอบสิทธิ์ตามใบรับรองจะรวมเข้ากับ Dataverse และใช้ใบรับรอง X.509 เพื่อเพิ่มความปลอดภัยและการเข้ารหัสของข้อมูลที่เก็บอยู่

ภาพรวมของการตรวจสอบสิทธิ์โดยใช้ Dataverse

Dataverse การใช้งานระบบจัดเก็บข้อมูล

การใช้งาน Dataverse ใช้ที่เก็บข้อมูล XML ที่กำหนดเองสำหรับการจัดเก็บคีย์การป้องกันอย่างปลอดภัย:

ภาพรวมของการจัดเก็บค่า Dataverse

เทคโนโลยีการเข้ารหัส

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

AES-256-CBC + HMACSHA256

โดยค่าเริ่มต้น ค่าข้อมูลจะถูกเข้ารหัสโดยใช้การผสมผสานระหว่าง AES-256-CBC และ HMACSHA256:

ภาพรวมของการเข้ารหัสโดยใช้ ASP.Net Data Protection API Dataverse

แนวทางนี้จัดให้มี:

  1. ความลับ ผ่านการเข้ารหัส AES-256
  2. ความสมบูรณ์ ผ่านการตรวจสอบ HMAC
  3. การตรวจสอบความถูกต้องของแหล่งข้อมูล

การรวม API การปกป้องข้อมูล

เครื่องมือทดสอบจะรวมเข้ากับ API การปกป้องข้อมูลของ Core สำหรับการจัดการคีย์และการเข้ารหัส: ASP.NET

ภาพรวมการใช้งาน Dataverse API การปกป้องข้อมูล

การใช้งานที่เก็บข้อมูล XML แบบกำหนดเอง

Test Engine นำ IXmlRepository ที่กำหนดเองมาใช้งานเพื่อการรวม: Dataverse

ภาพรวมของผู้ให้บริการ XML แบบกำหนดเองของ Data Protection API

การเข้าถึงแบบมีเงื่อนไขและความเข้ากันได้ของ MFA

สถาปัตยกรรมการตรวจสอบสิทธิ์ของ Test Engine ได้รับการออกแบบมาให้ทำงานได้อย่างราบรื่นกับนโยบายการเข้าถึงแบบมีเงื่อนไข: Microsoft Entra

ภาพรวมของนโยบายการเข้าถึงแบบมีเงื่อนไขและการตรวจสอบสิทธิ์แบบหลายปัจจัย

การพิจารณาความปลอดภัยขั้นสูง

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

Dataverse การบูรณาการโมเดลความปลอดภัย

Test Engine ใช้โมเดลความปลอดภัยที่แข็งแกร่งของ Dataverse:

  • ความปลอดภัยระดับระเบียน - ควบคุมการเข้าถึงข้อมูลการตรวจสอบสิทธิ์ที่จัดเก็บไว้
  • โมเดลการแบ่งปัน - ช่วยให้สามารถแบ่งปันบริบทการตรวจสอบสิทธิ์การทดสอบได้อย่างปลอดภัย
  • การตรวจสอบ - ติดตามการเข้าถึงข้อมูลการตรวจสอบสิทธิ์ที่ละเอียดอ่อน
  • การรักษาความปลอดภัยระดับคอลัมน์ - ให้การป้องกันแบบละเอียดของฟิลด์ที่ละเอียดอ่อน

การจัดการโทเค็น Azure CLI

สำหรับการตรวจสอบสิทธิ์ Test Engine จะได้รับโทเค็นการเข้าถึงอย่างปลอดภัย: Dataverse

ภาพรวมของการตรวจสอบสิทธิ์ตาม Azure Command Line (CLI)

แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัย

เมื่อนำการตรวจสอบสิทธิ์ของ Test Engine ไปใช้ ควรพิจารณาแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยดังต่อไปนี้:

  • สิทธิ์การเข้าถึงขั้นต่ำ - ให้สิทธิ์ที่จำเป็นขั้นต่ำในการทดสอบบัญชี
  • การหมุนเวียนใบรับรองปกติ - อัปเดตใบรับรองเป็นระยะ
  • ตัวแปร CI/CD ที่ปลอดภัย - ปกป้องตัวแปรไปป์ไลน์ที่มีข้อมูลละเอียดอ่อน
  • ตรวจสอบการเข้าถึง - ตรวจสอบการเข้าถึงทรัพยากรการตรวจสอบสิทธิ์
  • การแยกสภาพแวดล้อม - ใช้สภาพแวดล้อมที่แยกจากกันสำหรับการทดสอบ

การปรับปรุงความปลอดภัยในอนาคต

การปรับปรุงในอนาคตที่อาจเกิดขึ้นกับสถาปัตยกรรมความปลอดภัยในการรับรองความถูกต้อง ได้แก่:

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

การปกป้องข้อมูลใน ASP.NET Core
API การปกป้องข้อมูลของ Windows
Microsoft Entra การรับรองความถูกต้อง
Dataverse แบบจำลองความปลอดภัย
การตรวจสอบสิทธิ์ตามใบรับรอง X.509