แชร์ผ่าน

คำแนะนำสำหรับระบบบริหารจัดการตัวตนและการเข้าถึงทรัพยากร

  • บทความ

นำไปใช้กับคำแนะนำรายการตรวจสอบความปลอดภัย Power Platform Well-Architected:

SE:05 ใช้ระบบบริหารจัดการตัวตนและการเข้าถึงทรัพยากร (IAM) ที่เข้มงวด มีเงื่อนไข และตรวจสอบได้กับผู้ใช้ภาระงาน สมาชิกในทีม และส่วนประกอบของระบบทั้งหมด จำกัดการเข้าถึงเฉพาะตามความจำเป็น ใช้มาตรฐานอุตสาหกรรมสมัยใหม่สำหรับการใช้งานการรับรองความถูกต้องและการอนุญาตทั้งหมด จำกัดและตรวจสอบการเข้าถึงที่ไม่ได้อิงข้อมูลเฉพาะตัวอย่างเข้มงวด

คู่มือนี้อธิบายคำแนะนำในการตรวจสอบสิทธิ์และการอนุญาตข้อมูลประจำตัวที่พยายามเข้าถึงทรัพยากรภาระงาน

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

ข้อมูลประจำตัวโดยทั่วไป ได้แก่:

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

คำนิยาม

เงื่อนไข ข้อกำหนด
การรับรองความถูกต้อง (AuthN) กระบวนการที่ตรวจสอบว่าข้อมูลประจำตัวคือใครหรือสิ่งที่กล่าวไว้
การรับรองความถูกต้อง (AuthZ) กระบวนการที่ตรวจสอบว่าข้อมูลประจำตัวได้รับอนุญาตให้ดำเนินการตามที่ร้องขอหรือไม่
การเข้าถึงตามเงื่อนไข ชุดกฎที่อนุญาตการดำเนินการตามเกณฑ์ที่ระบุ
IdP ผู้ให้บริการข้อมูลประจำตัว เช่น Microsoft Entra ID
ลักษณะ หน้าที่งานหรือตำแหน่งที่มีชุดความรับผิดชอบและการกระทำ
คีย์ที่แชร์ล่วงหน้า ความลับประเภทหนึ่งที่แบ่งปันระหว่างผู้ให้บริการและผู้บริโภค และใช้ผ่านกลไกที่ปลอดภัยและตกลงกันไว้
ข้อมูลประจำตัวทรัพยากร ข้อมูลประจำตัวที่กำหนดสำหรับทรัพยากรระบบคลาวด์ที่ได้รับการจัดการโดยแพลตฟอร์ม
บทบาท ชุดสิทธิ์ที่กำหนดสิ่งที่ผู้ใช้หรือกลุ่มสามารถทำได้
Scope ระดับต่างๆ ของลำดับชั้นขององค์กรที่อนุญาตให้มีบทบาทได้ รวมถึงกลุ่มคุณสมบัติในระบบด้วย
หลักความปลอดภัย ข้อมูลประจำตัวที่ให้สิทธิ์ อาจเป็นผู้ใช้ กลุ่ม หรือบริการหลักก็ได้ สมาชิกกลุ่มใดก็ตามจะได้รับสิทธิ์การเข้าถึงในระดับเดียวกัน
ข้อมูลประจำตัวของผู้ใช้ ข้อมูลประจำตัวของบุคคล เช่น พนักงานหรือผู้ใช้ภายนอก
ข้อมูลประจำตัวของภาระงาน ข้อมูลประจำตัวของระบบสำหรับแอปพลิเคชัน บริการ สคริปต์ คอนเทนเนอร์ หรือส่วนประกอบอื่นๆ ของปริมาณงานที่ใช้เพื่อตรวจสอบสิทธิ์ตัวเองกับบริการและทรัพยากรอื่นๆ

หมายเหตุ

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

Microsoft Entra ID ในฐานะผู้ให้บริการข้อมูลประจำตัวสำหรับ Power Platform

ผลิตภัณฑ์ Power Platform ทั้งหมดใช้ Microsoft Entra ID (เดิม Azure Active Directory หรือ Azure AD) สำหรับการจัดการข้อมูลประจำตัวและการเข้าถึง Entra ID ช่วยให้องค์กรสามารถรักษาความปลอดภัยและจัดการข้อมูลประจำตัวสำหรับสภาพแวดล้อมแบบไฮบริดและมัลติคลาวด์ได้ Entra ID ยังจำเป็นสำหรับการจัดการผู้เยี่ยมชมทางธุรกิจที่ต้องการการเข้าถึงทรัพยากร Power Platform Power Platform ยังใช้ Entra ID เพื่อจัดการแอปพลิเคชันอื่นๆ ที่จำเป็นต้องผสานรวมเข้ากับ Power Platform API ที่ใช้ความสามารถหลักของบริการ โดยใช้ Entra ID Power Platform สามารถใช้ประโยชน์จากคุณสมบัติความปลอดภัยขั้นสูงของ Entra ID เช่น การเข้าถึงแบบมีเงื่อนไขและการประเมินการเข้าถึงอย่างต่อเนื่อง

การรับรองความถูกต้อง

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

  • ชื่อผู้ใช้และรหัสผ่าน
  • ข้อมูลลับที่แชร์ล่วงหน้า เช่น คีย์ API ที่ให้สิทธิ์การเข้าถึง
  • โทเค็นลายเซ็นการเข้าถึงร่วมกัน (SAS)
  • ใบรับรองที่ใช้ในการรับรองความถูกต้องร่วมกันของ Transport Layer Security (TLS)

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

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

การอนุญาต

Power Platform ใช้ Microsoft Entra ID แพลตฟอร์มข้อมูลประจำตัวของ Microsoft สำหรับการอนุญาตการเรียก API ทั้งหมดด้วยโปรโตคอล OAuth 2.0 มาตรฐานอุตสาหกรรม

กลยุทธ์การออกแบบที่สำคัญ

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

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

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

กำหนดข้อมูลประจำตัวทั้งหมดสำหรับการตรวจสอบสิทธิ์

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

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

กำหนดการดำเนินการเพื่อขออนุญาต

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

  • การเข้าถึงส่วนส่งข้อมูล การดำเนินการที่เกิดขึ้นในชั้นข้อมูลทำให้เกิดการถ่ายโอนข้อมูล ตัวอย่างเช่น แอปพลิเคชันอ่านหรือเขียนข้อมูลจาก Microsoft Dataverse หรือเขียนบันทึกลงใน Application Insights

  • การเข้าถึงส่วนการควบคุม การดำเนินการที่เกิดขึ้นในส่วนการควบคุมทำให้ทรัพยากร Power Platform ถูกสร้าง แก้ไข หรือลบ ตัวอย่างเช่น การแก้ไขคุณสมบัติสภาพแวดล้อมหรือการสร้างนโยบายข้อมูล

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

ให้การอนุญาตตามบทบาท

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

ลองพิจารณาข้อเท็จจริงต่อไปนี้

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

การกําหนดบทบาท

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

ถามคำถามเหล่านี้:

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

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

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

การแลกเปลี่ยน: แนวทางการเข้าถึงแบบละเอียดช่วยให้สามารถตรวจสอบและติดตามกิจกรรมของผู้ใช้ได้ดียิ่งขึ้น

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

เลือกการเข้าถึงแบบมีเงื่อนไข

อย่าให้ข้อมูลประจำตัวทั้งหมดมีระดับการเข้าถึงเท่ากัน ตัดสินใจโดยอาศัยปัจจัยหลักสองประการ:

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

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

ทันเวลา (JIT) แนวทางต่างๆ ให้สิทธิ์ที่จำเป็นเฉพาะเมื่อจำเป็นเท่านั้น

การเข้าถึงอย่างเพียงพอ (JEA) ให้สิทธิ์ที่จำเป็นเท่านั้น

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

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

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

บัญชีผลกระทบสำคัญ

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

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

  • ลดจำนวนบัญชีที่มีผลกระทบร้ายแรงให้เหลือน้อยที่สุด

  • ใช้บทบาทที่แยกจากกัน แทนที่จะยกระดับสิทธิพิเศษให้กับข้อมูลประจำตัวที่มีอยู่

  • หลีกเลี่ยงการเข้าถึงแบบถาวรหรือแบบยืน โดยใช้คุณสมบัติ JIT ของ IdP ของคุณ สำหรับสถานการณ์ฉุกเฉิน ให้ปฏิบัติตามขั้นตอนการเข้าถึงฉุกเฉิน

  • ใช้โปรโตคอลการเข้าถึงที่ทันสมัย เช่น การรับรองความถูกต้องแบบไม่ใช้รหัสผ่านหรือการรับรองความถูกต้องแบบหลายปัจจัย ส่งออกกลไกเหล่านั้นไปยัง IdP ของคุณ

  • บังคับใช้แอตทริบิวต์ความปลอดภัยที่สำคัญโดยใช้ นโยบายการเข้าถึงแบบมีเงื่อนไข

  • บัญชีผู้ดูแลระบบการเลิกจ้าง ที่ไม่ได้ใช้งาน

สร้างกระบวนการเพื่อจัดการวงจรการใช้งานข้อมูลประจำตัว

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

คำแนะนำนี้ใช้กับการควบคุมแหล่งที่มา ข้อมูล ส่วนการควบคุม ผู้ใช้ภาระงาน โครงสร้างพื้นฐาน เครื่องมือ การตรวจสอบข้อมูล บันทึก ตัวชี้วัด และเอนทิตีอื่นๆ

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

ปกป้องความลับที่ไม่ระบุตัวตน

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

ถือว่าความลับเหล่านี้เป็นเอนทิตีที่สามารถดึงออกจากร้านค้าลับแบบไดนามิกได้ สิ่งเหล่านี้ไม่ควรฮาร์ดโค้ดในแอป โฟลว์ ไปป์ไลน์การปรับใช้ หรือในส่วนอื่นๆ ของคุณ

ตรวจสอบให้แน่ใจว่าคุณมี ความสามารถในการในการเพิกถอนข้อมูลลับ

ใช้แนวทางปฏิบัติในการจัดการงานต่างๆ เช่น การหมุนเวียนคีย์และการหมดอายุ

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

รักษาสภาพแวดล้อมในการพัฒนาให้ปลอดภัย

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

รักษาบันทึกการตรวจสอบบัญชี

อีกด้านหนึ่งของการจัดการข้อมูลประจำตัวคือการทำให้มั่นใจว่าระบบสามารถตรวจสอบได้ การตรวจสอบจะตรวจสอบว่ากลยุทธ์การละเมิดที่สันนิษฐานไว้มีประสิทธิผลหรือไม่ การรักษาบันทึกการตรวจสอบบัญชีช่วยให้คุณ:

  • ตรวจสอบว่ามีการรับรองความถูกต้องของข้อมูลประจำตัวด้วยการรับรองความถูกต้องที่รัดกุม การกระทำใดๆ จะต้องติดตามได้ เพื่อป้องกันการโจมตีแบบปฏิเสธ

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

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

  • ติดตามความคืบหน้าหรือการเบี่ยงเบน จากข้อกำหนดการปฏิบัติตามข้อกำหนด

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

การอำนวยความสะดวก Power Platform

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

Microsoft Entra ID

ผลิตภัณฑ์ Power Platform ทั้งหมดใช้ Microsoft Entra ID (เดิม Azure Active Directory หรือ Azure AD) สำหรับการจัดการข้อมูลประจำตัวและการเข้าถึง Entra ID ช่วยให้องค์กรสามารถรักษาความปลอดภัยและจัดการข้อมูลประจำตัวสำหรับสภาพแวดล้อมแบบไฮบริดและมัลติคลาวด์ได้ Entra ID ยังจำเป็นสำหรับการจัดการผู้เยี่ยมชมทางธุรกิจที่ต้องมีการเข้าถึงทรัพยากร Power Platform Power Platform ยังใช้ Entra ID เพื่อจัดการแอปพลิเคชันอื่นๆ ที่จำเป็นต้องผสานรวมเข้ากับ Power Platform API ที่ใช้ความสามารถหลักของบริการ โดยใช้ Entra ID Power Platform สามารถใช้ประโยชน์จากคุณสมบัติความปลอดภัยขั้นสูงของ Entra ID เช่น การเข้าถึงแบบมีเงื่อนไขและการประเมินการเข้าถึงอย่างต่อเนื่อง

ไดอะแกรมของระบบการประมวลผลแบบคลาวด์

การมอบหมายสิทธิ์การใช้งาน

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

นโยบายการเข้าถึงแบบมีเงื่อนไข

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

สำหรับข้อมูลเพิ่มเติม โปรดดู:

การเข้าถึงต่อเนื่อง

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

ปัจจุบัน Power Platform เฉพาะ Dataverse เท่านั้นที่รองรับการประเมินการเข้าถึงอย่างต่อเนื่อง Microsoft กำลังทำงานเพื่อเพิ่มการสนับสนุนให้กับบริการของ Power Platform และไคลเอ็นต์อื่นๆ สำหรับข้อมูลเพิ่มเติม ดู การประเมินการเข้าถึงอย่างต่อเนื่อง

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

การจัดการการเข้าถึงแบบกลุ่ม

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

สำหรับข้อมูลเพิ่มเติม โปรดดู ควบคุมการเข้าถึงอย่างปลอดภัยโดยใช้กลุ่มใน Microsoft Entra ID

การตรวจหาภัยคุกคาม

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

การตรวจจับภัยคุกคามอาจอยู่ในรูปแบบของการตอบสนองต่อการแจ้งเตือนกิจกรรมที่น่าสงสัยหรือการค้นหาเหตุการณ์ผิดปกติในบันทึกกิจกรรมในเชิงรุก การวิเคราะห์พฤติกรรมผู้ใช้และเอนทิตี (UEBA) ใน Microsoft Sentinel ทำให้การตรวจจับกิจกรรมที่น่าสงสัยเป็นเรื่องง่าย สำหรับข้อมูลเพิ่มเติม ดู ระบุภัยคุกคามขั้นสูงด้วย UEBA ใน Microsoft Sentinel

การบันทึกข้อมูลประจำตัว

การบันทึกกิจกรรม Power Apps, Power Automate, Copilot Studio, ตัวเชื่อมต่อ และการป้องกันข้อมูลสูญหายจะได้รับการติดตามและดูจากพอร์ทัลการปฏิบัติตามข้อกำหนดของ Microsoft Purview สำหรับข้อมูลเพิ่มเติม โปรดดูเรียนรู้เกี่ยวกับ Microsoft Purview

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

หน้าที่ผู้ดูแลระบบบริการ

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

ใช้ Microsoft Entra Privileged Identity Management (PIM) เพื่อจัดการบทบาทผู้ดูแลระบบที่มีสิทธิ์สูงในศูนย์การจัดการ Power Platform

การรักษาความปลอดภัยข้อมูล Dataverse

หนึ่งในคุณสมบัติที่สำคัญของ Dataverse คือโมเดลการรักษาความปลอดภัยที่หลากหลายซึ่งสามารถปรับให้เข้ากับสถานการณ์การใช้งานทางธุรกิจจำนวนมาก โมเดลการรักษาความปลอดภัยนี้จะพร้อมใช้งานเมื่อมีฐานข้อมูล Dataverse ในสภาพแวดล้อมเท่านั้น ในฐานะผู้เชี่ยวชาญด้านความปลอดภัย คุณคงไม่สร้างโมเดลความปลอดภัยทั้งหมดด้วยตัวเอง แต่อาจมีส่วนร่วมในการทำให้แน่ใจว่าการใช้คุณลักษณะความปลอดภัยนั้นสอดคล้องกับข้อกำหนดด้านความปลอดภัยข้อมูลขององค์กร Dataverse ใช้การรักษาความปลอดภัยตามบทบาทเพื่อจัดกลุ่มตามชุดของสิทธิ์การใช้งาน บทบาทการรักษาความปลอดภัย (Security role) เหล่านี้สามารถเชื่อมโยงได้โดยตรงกับผู้ใช้ หรือเชื่อมโยงกับทีมและหน่วยธุรกิจของ Dataverse สำหรับข้อมูลเพิ่มเติม ดู แนวคิดเรื่องความปลอดภัยใน Microsoft Dataverse

กำหนดค่าการรับรองความถูกต้องของผู้ใช้ใน Copilot Studio

Microsoft Copilot Studio รองรับตัวเลือกการรับรองความถูกต้องหลายแบบ เลือกตัวเลือกที่เหมาะกับความต้องการของคุณ การรับรองความถูกต้องอนุญาตให้ผู้ใช้ลงชื่อเข้าใช้ ซึ่งจะให้เอเจนต์ของคุณสามารถเข้าถึงทรัพยากรหรือข้อมูลที่ถูกจำกัด ผู้ใช้สามารถลงชื่อเข้าใช้ด้วย Microsoft Entra ID หรือผู้ให้บริการข้อมูลประจำตัว OAuth 2.0 ของคุณ เช่น Google หรือ Facebook เรียนรู้เพิ่มเติมใน กำหนดค่าการรับรองความถูกต้องของผู้ใช้ใน Copilot Studio

ด้วย ความปลอดภัยของ Direct Line คุณสามารถจำกัดการเข้าถึงเฉพาะสถานที่ที่คุณควบคุมโดยเปิดใช้งานการเข้าถึงที่ปลอดภัยด้วยข้อมูลลับหรือโทเค็น Direct Line

Copilot Studio รองรับการลงชื่อเข้าระบบครั้งเดียว (SSO) ซึ่งหมายความว่าเอเจนต์สามารถลงชื่อเข้าใช้ให้ผู้ใช้ได้ ต้องใช้ SSO บนหน้าเว็บและแอปพลิเคชันมือถือของคุณ สำหรับ Microsoft Teams SSO จะดำเนินการอย่างราบรื่น หากคุณเลือกตัวเลือกการรับรองความถูกต้อง "เฉพาะใน Teams" นอกจากนี้ ยังสามารถกำหนดค่าด้วยตนเองด้วย Azure AD v2 อย่างไรก็ตาม ในกรณีนี้ ต้องติดตั้งแอป Teams เป็นไฟล์ zip ไม่ใช่ผ่านการปรับใช้งาน Teams ด้วยการคลิกครั้งเดียวจาก Copilot Studio

เรียนรู้เพิ่มเติม:

เข้าถึงข้อมูลอย่างปลอดภัยโดยใช้ Customer Lockbox

การดำเนินงาน การสนับสนุน และการแก้ไขปัญหาส่วนใหญ่ดำเนินการโดยบุคลากรของ Microsoft (รวมถึงผู้ประมวลผลย่อย) ไม่ต้องการการเข้าถึงข้อมูลลูกค้า ด้วย Customer Lockbox ของ Power Platform เราให้อินเทอร์เฟซแก่ลูกค้าเพื่อตรวจทานและอนุมัติ (หรือปฏิเสธ) คำขอเข้าถึงข้อมูลได้ในบางครั้งเมื่อจำเป็นต้องเข้าถึงข้อมูลไปยังข้อมูลลูกค้า ตัวอย่างเช่น ใช้ในกรณีที่วิศวกรของ Microsoft ต้องการเข้าถึงข้อมูลลูกค้า ไม่ว่าจะเพื่อตอบสนองต่อตั๋วการสนับสนุนที่เริ่มต้นโดยลูกค้าหรือปัญหาที่ Microsoft ระบุ สำหรับข้อมูลเพิ่มเติม ดู เข้าถึงข้อมูลลูกค้าอย่างปลอดภัยโดยใช้ Customer Lockbox ใน Power Platform และ Dynamics 365

รายการตรวจสอบความปลอดภัย

โปรดดูชุดคำแนะนำทั้งหมด

รายการตรวจสอบความปลอดภัย