แชร์ผ่าน

การวางแผนการใช้งาน Power BI: การตรวจสอบระดับผู้เช่า

  • บทความ

หมายเหตุ

บทความนี้เป็นส่วนหนึ่งของ ชุดการวางแผน การใช้งาน Power BI ของบทความ ชุดข้อมูลนี้เน้นไปที่ประสบการณ์การใช้งาน Power BI ภายใน Microsoft Fabric เป็นหลัก สําหรับบทนําสู่ชุดข้อมูล โปรดดู ที่ การวางแผนการใช้งาน Power BI

บทความการวางแผนการตรวจสอบระดับผู้เช่ารายนี้มีเป้าหมายเป็นหลักที่:

  • ผู้ดูแลระบบ Power BI: ผู้ดูแลระบบที่รับผิดชอบในการตรวจสอบ Power BI ในองค์กร ผู้ดูแลระบบ Power BI อาจต้องทํางานร่วมกับฝ่าย IT ความปลอดภัย การตรวจสอบภายใน และทีมอื่นๆ ที่เกี่ยวข้อง
  • ทีม แห่งความเป็นเลิศ ทีม IT และ BI: ทีมที่รับผิดชอบในการตรวจสอบ Power BI พวกเขาอาจจําเป็นต้องทํางานร่วมกับผู้ดูแลระบบ Power BI และทีมอื่น ๆ ที่เกี่ยวข้อง

สำคัญ

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

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

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

สําหรับการตรวจสอบระดับรายงาน ซึ่งมีการกําหนดเป้าหมายที่ผู้สร้างรายงาน โปรดดู การตรวจสอบระดับรายงาน

สําหรับการตรวจสอบแอสเซทข้อมูล ซึ่งมีการกําหนดเป้าหมายไปที่ผู้สร้างข้อมูล โปรดดู การตรวจสอบระดับข้อมูล

ส่วนที่เหลือของบทความนี้จะมุ่งเน้นไปที่การตรวจสอบระดับผู้เช่า

เคล็ดลับ

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

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

เมื่อคุณวางแผนที่จะสร้างโซลูชันการตรวจสอบระดับผู้เช่า วางแผนที่จะใช้เวลาในสี่ขั้นตอนต่อไปนี้

ระยะที่ 1: การวางแผนและการตัดสินใจ

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

ไดอะแกรมโฟลว์ที่อธิบายระยะที่ 1 ซึ่งมุ่งเน้นการวางแผนและการตัดสินใจสําหรับการสร้างโซลูชันการตรวจสอบระดับผู้เช่า

ข้อกําหนดและลําดับความสําคัญ

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

นี่คือคําถามบางอย่างที่คุณควรตอบ

  • คุณต้องตอบคําถามสําคัญอะไรบ้าง มีข้อมูลการตรวจสอบจํานวนมากที่คุณสามารถสํารวจได้ วิธีที่มีประสิทธิภาพที่สุดในการตรวจสอบคือการมุ่งเน้นไปที่การตอบคําถามเฉพาะ
  • เป้าหมายของวัฒนธรรมการปรับใช้และวัฒนธรรมข้อมูลของคุณคืออะไร ตัวอย่างเช่น คุณอาจมีเป้าหมายในการเพิ่มจํานวนผู้สร้างเนื้อหา BI แบบบริการตนเองในองค์กร ในกรณีดังกล่าว คุณจะต้องวัดกิจกรรมของผู้ใช้ที่เกี่ยวข้องกับการสร้าง การแก้ไข และการเผยแพร่เนื้อหา
  • มีความเสี่ยงทันทีอะไรบ้าง? ตัวอย่างเช่น คุณอาจทราบว่าการแชร์เนื้อหามากเกินไปเกิดขึ้นในอดีต การฝึกอบรมผู้ใช้ได้รับการปรับปรุงและตอนนี้คุณต้องการตรวจสอบการตั้งค่าความปลอดภัยและกิจกรรมอย่างต่อเนื่อง
  • มีตัวบ่งชี้ประสิทธิภาพหลัก (KPI) หรือเป้าหมายขององค์กรปัจจุบันหรือไม่ ตัวอย่างเช่น คุณอาจมี KPI ขององค์กรที่เกี่ยวข้องกับการแปลงแบบดิจิทัลหรือกลายเป็นองค์กรที่ขับเคลื่อนด้วยข้อมูลมากขึ้น ข้อมูลการตรวจสอบระดับผู้เช่าสามารถช่วยให้คุณวัดได้ว่าการใช้งาน Power BI ของคุณสอดคล้องกับเป้าหมายเหล่านี้หรือไม่

เคล็ดลับ

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

สําหรับแนวคิดเพิ่มเติมเกี่ยวกับวิธีการที่คุณสามารถใช้ข้อมูลการตรวจสอบ ดู ภาพรวมการตรวจสอบและการตรวจสอบ

รายการ ตรวจสอบ - เมื่อระบุข้อกําหนดและลําดับความสําคัญ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • ระบุข้อกําหนด: รวบรวมและจัดทําเอกสารข้อกําหนดทางธุรกิจที่สําคัญสําหรับการตรวจสอบผู้เช่า Power BI ของคุณ
  • ข้อกําหนดการจัดลําดับความสําคัญ : ตั้งค่าลําดับความสําคัญสําหรับข้อกําหนด จัดประเภทเป็นทันที ระยะสั้น ระยะกลาง และระยะยาว (งานที่ตกค้าง)
  • สร้างแผนสําหรับลําดับความสําคัญทันที: วางแผนเพื่อเริ่มรวบรวมข้อมูลเพื่อให้พร้อมใช้งานเมื่อคุณต้องการ
  • ประเมินข้อกําหนดซ้ําเป็นประจํา: สร้างแผนเพื่อประเมินข้อกําหนดซ้ําเป็นประจํา (ตัวอย่างเช่น สองครั้งต่อปี) ตรวจสอบว่าโซลูชันการตรวจสอบและการตรวจสอบตรงกับข้อกําหนดที่ระบุไว้หรือไม่ อัปเดตรายการการดําเนินการบนแผนของคุณตามความจําเป็น

ความต้องการข้อมูล

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

ข้อมูลส่วนใหญ่ที่คุณต้องการมาจาก ผู้ดูแลระบบ API ซึ่งมีเมตาดาต้าจํานวนมากเกี่ยวกับผู้เช่า Power BI สําหรับข้อมูลเพิ่มเติม โปรดดู เลือก API ของผู้ใช้หรือผู้ดูแลระบบ API ในภายหลังในบทความนี้

ข้อมูลกิจกรรมของผู้ใช้

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

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

ต่อไปนี้เป็นคําถามทั่วไปที่ข้อมูลกิจกรรมของผู้ใช้สามารถตอบได้

  • ค้นหาผู้ใช้งานอันดับสูงสุดและเนื้อหาสูงสุด
    • มีการดูเนื้อหาใดบ่อยที่สุดและผู้ใช้รายใด
    • แนวโน้มรายวัน รายสัปดาห์ และรายเดือนสําหรับการดูเนื้อหาคืออะไร
    • มุมมองรายงานกําลังนิยมขึ้นหรือลง?
    • มีผู้ใช้ที่ใช้งานอยู่กี่คน
  • ทําความเข้าใจลักษณะการทํางานของผู้ใช้
    • ความปลอดภัยชนิดใดที่ใช้บ่อยที่สุด (แอป พื้นที่ทํางาน หรือการแชร์ต่อรายการ)
    • ผู้ใช้กําลังใช้เบราว์เซอร์หรือแอปสําหรับอุปกรณ์เคลื่อนที่บ่อยที่สุดหรือไม่
    • ผู้สร้างเนื้อหาคนใดเผยแพร่และอัปเดตเนื้อหามากที่สุด
    • เนื้อหาใดบ้างที่เผยแพร่หรืออัปเดต เมื่อใดและโดยผู้ใช้ใด
  • ระบุโอกาสการศึกษาของผู้ใช้และการฝึกอบรม
    • ใครกําลังทําการแชร์ (มากเกินไป) จากพื้นที่ทํางานส่วนบุคคลของพวกเขา
    • ใครกําลังทําการส่งออกจํานวนมาก
    • ใครคือผู้ดาวน์โหลดเนื้อหาเป็นประจํา
    • ใครกําลังเผยแพร่แบบจําลองความหมายใหม่จํานวนมาก
    • ใครกําลังใช้การสมัครใช้งานอย่างมาก
  • ปรับปรุงการกํากับดูแลและความพยายามในการปฏิบัติตามกฎระเบียบ
    • เมื่อใดที่มีการเปลี่ยนแปลงการตั้งค่าผู้เช่า และโดยผู้ดูแลระบบ Power BI คนใด
    • ใครเริ่มทดลองใช้ Power BI
    • มีการเข้าถึงเนื้อหาใดจากผู้ใช้ภายนอก ใคร เมื่อไหร่ และอย่างไร
    • ใครเพิ่มหรืออัปเดตป้ายชื่อระดับความลับ
    • เปอร์เซ็นต์ของการดูรายงานจะขึ้นอยู่กับแบบจําลองความหมายที่ได้รับการรับรอง
    • เปอร์เซ็นต์ของแบบจําลองความหมายใดที่สนับสนุนมากกว่าหนึ่งรายงาน
    • เมื่อใดที่เกตเวย์หรือแหล่งข้อมูลจะถูกสร้างขึ้นหรืออัปเดต และโดยผู้ใช้คนใด

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการใช้ข้อมูลนี้ ให้ดู ทําความเข้าใจรูปแบบการใช้งาน

สำคัญ

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

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

สินค้าคงคลังของผู้เช่า

บ่อยครั้งที่ลําดับความสําคัญที่สองคือการดึงข้อมูลเพื่อสร้างสินค้าคงคลังของผู้เช่า ในบางครั้งจะเรียกว่าสินค้าคงคลังของพื้นที่ทํางาน เมตาดาต้าของพื้นที่ทํางาน หรือเมตาดาต้าของผู้เช่า

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

ต่อไปนี้เป็นคําถามทั่วไปที่ผู้เช่าสามารถตอบได้

  • ทําความเข้าใจว่าคุณมีเนื้อหามากแค่ไหนและที่ไหน
    • พื้นที่ทํางานใดมีเนื้อหามากที่สุด
    • มีการเผยแพร่เนื้อหาชนิดใดในแต่ละพื้นที่ทํางาน (โดยเฉพาะอย่างยิ่งเมื่อคุณกําลังแยกพื้นที่ทํางานการรายงานและพื้นที่ทํางานข้อมูล)
    • มีการอ้างอิงระหว่างรายการใด (เช่น กระแสข้อมูลที่สนับสนุนแบบจําลองความหมายจํานวนมาก หรือแบบจําลองความหมายที่เป็นแหล่งข้อมูลสําหรับโมเดลแบบรวมอื่นๆ)
    • สายข้อมูลคืออะไร (การขึ้นต่อกันระหว่างรายการ Power BI รวมถึงแหล่งข้อมูลภายนอก)
    • มีรายงานที่กํากวม (ซึ่งไม่ได้เชื่อมต่อจากแบบจําลองความหมายของพวกเขา) หรือไม่?
  • ทําความเข้าใจอัตราส่วนของแบบจําลองความหมายต่อรายงาน
    • มีการนําแบบจําลองความหมายกลับมาใช้ใหม่มากน้อยเพียงใด
    • มีแบบจําลองความหมายซ้ําซ้อนหรือคล้ายกันสูงหรือไม่?
    • มีโอกาสรวมแบบจําลองความหมายหรือไม่
  • ทําความเข้าใจแนวโน้มระหว่างจุดในเวลา
    • จํานวนรายงานเพิ่มขึ้นเมื่อเวลาผ่านไปหรือไม่
    • จํานวนแบบจําลองความหมายเพิ่มขึ้นเมื่อเวลาผ่านไปหรือไม่
  • ค้นหาเนื้อหาที่ไม่ได้ใช้งาน
    • รายงานใดที่ไม่ได้ใช้งาน (หรือใช้น้อยไป)
    • แบบจําลองความหมายใดที่ไม่ได้ใช้ (หรือใช้น้อยไป)
    • มีโอกาสถอนเนื้อหาหรือไม่

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับวิธีการใช้สินค้าคงคลังของผู้เช่า ให้ดู ทําความเข้าใจเนื้อหาที่เผยแพร่

เคล็ดลับ

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

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

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

ข้อมูลผู้ใช้และกลุ่ม

เมื่อความต้องการด้านการวิเคราะห์ของคุณเพิ่มขึ้น คุณอาจตัดสินใจว่าคุณต้องการรวมข้อมูลเกี่ยวกับผู้ใช้และกลุ่มในโซลูชันการตรวจสอบแบบ end-to-end ของคุณ เมื่อต้องการเรียกใช้ข้อมูลนั้น คุณสามารถใช้ Microsoft Graph ซึ่งเป็นแหล่งข้อมูลที่เชื่อถือได้สําหรับข้อมูลเกี่ยวกับผู้ใช้และกลุ่มรหัส Microsoft Entra

ข้อมูลที่ดึงมาจาก Power BI REST API มีที่อยู่อีเมลเพื่ออธิบายผู้ใช้ หรือชื่อของกลุ่มความปลอดภัย ข้อมูลนี้เป็นสแนปช็อตณ จุดเวลาที่กําหนด

ต่อไปนี้เป็นคําถามทั่วไปที่ Microsoft Graph สามารถตอบได้

  • ระบุผู้ใช้และกลุ่ม
    • ชื่อผู้ใช้แบบเต็ม (นอกเหนือจากที่อยู่อีเมล) แผนก หรือตําแหน่งที่ตั้งที่ มาจากโปรไฟล์ผู้ใช้คืออะไร
    • ใครคือสมาชิกของกลุ่มความปลอดภัย
    • ใครเป็นเจ้าของกลุ่มความปลอดภัย (เพื่อจัดการสมาชิก)
  • รับข้อมูลผู้ใช้เพิ่มเติม
    • สิทธิ์การใช้งานใด – Power BI Pro หรือ Power BI Premium Per User (PPU) ที่กําหนดให้กับผู้ใช้
    • ผู้ใช้ คนใดลงชื่อเข้าใช้ บ่อยที่สุด
    • ผู้ใช้คนใดยังไม่ได้ลงชื่อเข้าใช้บริการของ Power BI เมื่อเร็ว ๆ นี้

คำเตือน

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

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

ข้อมูลความปลอดภัย

คุณอาจมีข้อกําหนดในการดําเนินการตรวจสอบความปลอดภัยปกติ

ต่อไปนี้คือคําถามทั่วไปบางอย่างที่ Power BI REST API สามารถตอบได้

สำคัญ

ในบางครั้งที่บทความนี้อ้างอิงถึง Power BI Premium หรือการสมัครใช้งานความจุ (P SKU) โปรดทราบว่าในขณะนี้ Microsoft กําลังรวมตัวเลือกการซื้อและหยุดใช้งาน Power BI Premium ต่อความจุ SKU ลูกค้าใหม่และลูกค้าที่มีอยู่ควรพิจารณาซื้อการสมัครใช้งานความจุ Fabric (F SKU) แทน

สําหรับข้อมูลเพิ่มเติม โปรดดู ที่ การอัปเดตที่สําคัญเกี่ยวกับการให้สิทธิ์การใช้งาน Power BI Premium และ คําถามที่ถามบ่อยของ Power BI Premium

เคล็ดลับ

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

คําถามทั่วไปเหล่านี้ไม่ใช่รายการที่ครบถ้วน มี Power BI REST API ที่พร้อมใช้งานมากมาย สําหรับข้อมูลเพิ่มเติม ดูการใช้ Power BI REST API

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

รายการตรวจสอบ - เมื่อระบุข้อมูลที่จําเป็นสําหรับการตรวจสอบ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

ชนิดของโซลูชันการตรวจสอบ

การตรวจสอบระดับผู้เช่าสามารถทําได้ด้วยตนเองหรือด้วยกระบวนการอัตโนมัติ

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

กระบวนการตรวจสอบด้วยตนเอง

การตรวจสอบด้วยตนเองอาศัยสคริปต์และกระบวนการที่เรียกใช้ตามความต้องการโดยผู้ใช้ (โดยปกติจะเป็นผู้ดูแลระบบ Power BI) เมื่อจําเป็น ผู้ใช้เรียกใช้คิวรี แบบ โต้ตอบเพื่อดึงข้อมูลการตรวจสอบ

การตรวจสอบด้วยตนเองเหมาะสมที่สุดสําหรับ:

  • สคริปต์ใหม่ที่กําลังได้รับการพัฒนาและทดสอบ
  • ความต้องการในการตรวจสอบเพียงครั้งเดียวในบางครั้ง
  • ความต้องการตรวจสอบแบบสํารวจ
  • กระบวนการตรวจสอบที่ไม่จําเป็นการสนับสนุนเต็มรูปแบบ

กระบวนการตรวจสอบอัตโนมัติ

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

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

การตรวจสอบอัตโนมัติเหมาะสมที่สุดสําหรับ:

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

ชนิดของกระบวนการ—ด้วยตนเองหรืออัตโนมัติ—อาจส่งผลกระทบต่อวิธีที่คุณจัดการการรับรองความถูกต้อง ตัวอย่างเช่น ผู้ดูแลระบบ Power BI อาจใช้การรับรองความถูกต้องผู้ใช้สําหรับกระบวนการตรวจสอบด้วยตนเอง แต่ใช้โครงร่างสําคัญของบริการสําหรับกระบวนการอัตโนมัติ สําหรับข้อมูลเพิ่มเติม ดู กําหนดวิธี การรับรองความถูกต้องในภายหลังในบทความนี้

เคล็ดลับ

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

รายการตรวจสอบ - เมื่อพิจารณาชนิดของโซลูชันการตรวจสอบเพื่อพัฒนา การตัดสินใจที่สําคัญและการดําเนินการรวมถึง:

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

สิทธิ์และความรับผิดชอบ

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

สิทธิ์ผู้ใช้

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

ต่อไปนี้คือข้อควรพิจารณาบางประการที่ควรคํานึงถึง

การเข้าถึงข้อมูลการตรวจสอบโดยตรง

คุณควรตัดสินใจว่าใครสามารถเข้าถึงข้อมูลการตรวจสอบได้โดยตรง มีหลายวิธีในการคิดเกี่ยวกับเรื่องนี้

  • ใครควรเป็นผู้ดูแลระบบ Power BI ผู้ดูแลระบบ Power BI มีสิทธิ์เข้าถึงเมตาดาต้าของผู้เช่าทั้งหมด รวมถึง API ของผู้ดูแลระบบด้วย สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการตัดสินใจว่าใครควรเป็นผู้ดูแลระบบ Power BI ให้ดู การวางแผนความปลอดภัยระดับผู้เช่า
  • ใครสามารถใช้บริการหลักที่มีอยู่ได้บ้าง เมื่อต้องใช้โครงร่างสําคัญของบริการ (แทนสิทธิ์ผู้ใช้) ในการเข้าถึงข้อมูลการตรวจสอบ ความลับจะต้องจัดเตรียมให้กับผู้ใช้ที่ได้รับอนุญาตเพื่อให้พวกเขาสามารถดําเนินการรับรองความถูกต้องโดยใช้รหัสผ่านได้ การเข้าถึงความลับ (และคีย์) ควรมีการควบคุมอย่างเข้มงวด
  • จําเป็นต้องควบคุมอุปกรณ์อย่างเข้มงวดหรือไม่? บางอุตสาหกรรมที่มีข้อกําหนดด้านกฎระเบียบและการปฏิบัติตามข้อกําหนดต้องควบคุมการเข้าถึงอย่างเข้มงวดมากขึ้นกว่าอุตสาหกรรมอื่น ๆ
  • มีปริมาณข้อมูลกิจกรรมขนาดใหญ่หรือไม่ เพื่อหลีกเลี่ยงไม่ให้ถึงขีดจํากัดการควบคุม API คุณอาจจําเป็นต้องควบคุมอย่างเข้มงวดว่าใครได้รับอนุญาตให้เข้าถึง API ที่ผลิตข้อมูลการตรวจสอบโดยตรง ในกรณีนี้จะเป็นประโยชน์เพื่อให้แน่ใจว่าไม่มีความพยายามซ้ําซ้อนหรือทับซ้อนกัน
การเข้าถึงข้อมูลดิบที่แยกออกมา

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

เข้าถึงข้อมูลการวิเคราะห์ที่รวบรวมไว้

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

หน้าที่และความรับผิดชอบ

เมื่อคุณตัดสินใจแล้วว่าสิทธิ์ของผู้ใช้ทํางานอย่างไร คุณอยู่ในตําแหน่งที่ดีในการเริ่มคิดเกี่ยวกับบทบาทและความรับผิดชอบ เราขอแนะนําให้คุณเกี่ยวข้องกับบุคคลที่เหมาะสมในช่วงต้น โดยเฉพาะอย่างยิ่งเมื่อนักพัฒนาหรือทีมหลายคนมีส่วนร่วมในการสร้างโซลูชันการตรวจสอบตั้งแต่ต้นจนจบ

ตัดสินใจว่าผู้ใช้หรือทีมใดที่จะรับผิดชอบกิจกรรมต่อไปนี้

บทบาท ประเภทของความรับผิดชอบ บทบาทที่ดําเนินการโดยทั่วไปโดย
ติดต่อผู้มีส่วนได้เสีย การรวบรวมกิจกรรมและข้อกําหนดการสื่อสาร COE ร่วมกับ IT นอกจากนี้อาจรวมถึงการเลือกบุคคลจากหน่วยธุรกิจหลัก
ตัดสินใจจัดลําดับความสําคัญและให้ทิศทางเกี่ยวกับข้อกําหนด กิจกรรมการตัดสินใจที่เกี่ยวข้องกับโซลูชันการตรวจสอบแบบ end-to-end รวมถึงวิธีการปฏิบัติตามข้อกําหนด ทีมที่ดูแล Power BI ในองค์กร เช่น COE ผู้บริหารหรือคณะกรรมการกํากับดูแลข้อมูลอาจมีส่วนร่วมในการตัดสินใจที่สําคัญหรือเลื่อนระดับปัญหา
แยกและจัดเก็บข้อมูลดิบ การสร้างสคริปต์และกระบวนการเพื่อเข้าถึงและแยกข้อมูล นอกจากนี้ยังเกี่ยวข้องกับการเขียนข้อมูลดิบลงในที่เก็บข้อมูล เจ้าหน้าที่ด้านวิศวกรรมข้อมูล โดยปกติจะอยู่ในไอทีและร่วมมือกับ COE
สร้างข้อมูลที่รวบรวม การทําความสะอาดข้อมูล การแปลง และการสร้างข้อมูลที่รวบรวมไว้ในการออกแบบแบบจําลองมิติที่ดาว เจ้าหน้าที่ด้านวิศวกรรมข้อมูล โดยปกติจะอยู่ในไอทีและร่วมมือกับ COE
สร้างแบบจําลองข้อมูล การสร้างแบบจําลองข้อมูลการวิเคราะห์ที่ยึดตามข้อมูลที่รวบรวม ผู้สร้างเนื้อหา Power BI โดยปกติแล้วจะอยู่ใน IT หรือ COE
สร้างรายงานการวิเคราะห์ การสร้างรายงานเพื่อวิเคราะห์ข้อมูลที่รวบรวมไว้ การเปลี่ยนแปลงอย่างต่อเนื่องไปยังรายงานที่ยึดตามข้อกําหนดใหม่และเมื่อข้อมูลการตรวจสอบใหม่พร้อมใช้งาน ผู้สร้างรายงาน Power BI โดยปกติแล้วจะอยู่ใน IT หรือ COE
วิเคราะห์ข้อมูลและดําเนินการกับผลลัพธ์ วิเคราะห์ข้อมูลและดําเนินการเพื่อตอบสนองต่อข้อมูลการตรวจสอบ ทีมที่ดูแล Power BI ในองค์กร มักจะเป็น COE นอกจากนี้อาจรวมถึงทีมอื่น ๆ โดยขึ้นอยู่กับผลลัพธ์การตรวจสอบและการดําเนินการ ทีมอื่น ๆ สามารถรวมถึงการรักษาความปลอดภัย การปฏิบัติตามกฎระเบียบ กฎหมาย การบริหารความเสี่ยง หรือการจัดการการเปลี่ยนแปลง
ทดสอบและตรวจสอบ ทดสอบเพื่อให้แน่ใจว่าเป็นไปตามข้อกําหนดการตรวจสอบและข้อมูลที่นําเสนอนั้นถูกต้อง ผู้สร้างเนื้อหา Power BI ร่วมกับทีมที่ดูแล Power BI ในองค์กร
รักษาความปลอดภัยของข้อมูล ตั้งค่าและจัดการความปลอดภัยสําหรับชั้นที่เก็บข้อมูลแต่ละชั้น รวมถึงข้อมูลดิบและข้อมูลที่รวบรวมไว้ จัดการการเข้าถึงแบบจําลองความหมายที่สร้างขึ้นสําหรับการวิเคราะห์ข้อมูล ผู้ดูแลระบบสําหรับระบบที่จัดเก็บข้อมูลร่วมกับทีมที่ดูแล Power BI ในองค์กร
การจัดกําหนดการและระบบอัตโนมัติ ดําเนินการตามโซลูชันและจัดกําหนดการกระบวนการด้วยเครื่องมือที่เลือก เจ้าหน้าที่ด้านวิศวกรรมข้อมูล โดยปกติจะอยู่ในไอทีและร่วมมือกับ COE
สนับสนุนโซลูชัน ตรวจสอบโซลูชันการตรวจสอบ รวมถึงการเรียกใช้งาน ข้อผิดพลาด และการสนับสนุนสําหรับปัญหาทางเทคนิค ทีมที่จัดการการสนับสนุนระบบ Power BI ซึ่งมักจะเป็น IT หรือ COE

คุณสามารถรวมบทบาทและความรับผิดชอบข้างต้นจํานวนมากเข้าไว้ด้วยกันได้หากพวกเขากําลังจะดําเนินการโดยทีมเดียวกันหรือบุคคลเดียวกัน ตัวอย่างเช่น ผู้ดูแลระบบ Power BI ของคุณอาจดําเนินบทบาทเหล่านี้บางอย่าง

นอกจากนี้ยังเป็นไปได้ว่าคนต่างก็มีบทบาทที่แตกต่างกันโดยขึ้นอยู่กับสถานการณ์ การดําเนินการจะเป็นไปตามบริบทโดยขึ้นอยู่กับข้อมูลการตรวจสอบและการดําเนินการที่เสนอ

พิจารณาหลายตัวอย่าง

  • ตัวอย่างที่ 1: ข้อมูลการตรวจสอบแสดงให้เห็นว่าผู้ใช้บางรายมักจะส่งออกข้อมูลไปยัง Excel การดําเนินการที่ดําเนินการ: COE ติดต่อผู้ใช้ที่เฉพาะเจาะจงเพื่อทําความเข้าใจความต้องการของพวกเขาและสอนทางเลือกที่ดีกว่า
  • ตัวอย่างที่ 2: ข้อมูลการตรวจสอบแสดงการเข้าถึงของผู้ใช้ภายนอกในลักษณะที่ไม่คาดคิด การดําเนินการที่ดําเนินการ: ผู้ดูแลระบบ IT จะอัปเดตการตั้งค่า Microsoft Entra ID ที่เกี่ยวข้องสําหรับการเข้าถึงของผู้ใช้ภายนอก ผู้ดูแลระบบ Power BI จะอัปเดตการตั้งค่าผู้เช่าที่เกี่ยวข้องกับการเข้าถึงของผู้ใช้ภายนอก COE อัปเดตเอกสารและการฝึกอบรมสําหรับผู้สร้างเนื้อหาที่จัดการความปลอดภัย สําหรับข้อมูลเพิ่มเติม ดู กลยุทธ์สําหรับผู้ใช้ภายนอก
  • ตัวอย่างที่ 3: ข้อมูลการตรวจสอบแสดงให้เห็นว่า แบบจําลองข้อมูลหลายตัวกําหนดหน่วยวัดเดียวกันแตกต่างจากที่ เมตาดาต้าที่กําลังสแกน APIถ้าได้รับอนุญาตให้ตั้งค่าผู้เช่าเมตาดาต้าโดยละเอียด) การดําเนินการที่ดําเนินการ: คณะกรรมการกํากับดูแลข้อมูลเริ่มต้นโครงการเพื่อกําหนดคําจํากัดความทั่วไป COE อัปเดตเอกสารและการฝึกอบรมสําหรับผู้สร้างเนื้อหาที่สร้างแบบจําลองข้อมูล COE ยังทํางานร่วมกับผู้สร้างเนื้อหาเพื่ออัปเดตแบบจําลองของพวกเขาตามความเหมาะสม สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการดึงข้อมูลเมตาดาต้าโดยละเอียด โปรดดู เข้าถึงข้อมูล สินค้าคงคลังของผู้เช่าในภายหลังในบทความนี้

หมายเหตุ

การตั้งค่ากระบวนการแยกข้อมูลมักใช้ความพยายามเพียงครั้งเดียวในการปรับปรุงและการแก้ไขปัญหาเป็นครั้งคราว การวิเคราะห์และดําเนินการกับข้อมูลเป็นความพยายามอย่างต่อเนื่องซึ่งต้องใช้ความพยายามอย่างต่อเนื่องในกิจวัตร

รายการ ตรวจสอบ - เมื่อพิจารณาสิทธิ์และความรับผิดชอบ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • ระบุว่าทีมใดมีส่วนเกี่ยวข้อง: กําหนดทีมที่จะเกี่ยวข้องกับการสร้างแบบ end-to-end และการสนับสนุนของโซลูชันการตรวจสอบ
  • ตัดสินใจว่าสิทธิ์ของผู้ใช้: กําหนดวิธีการตั้งค่าสิทธิ์ของผู้ใช้สําหรับการเข้าถึงข้อมูลการตรวจสอบ สร้างเอกสารประกอบสําหรับการตัดสินใจที่สําคัญสําหรับการอ้างอิงในภายหลัง
  • ตัดสินใจเลือกบทบาทและความรับผิดชอบ: ตรวจสอบให้แน่ใจว่าความคาดหวังมีความชัดเจนสําหรับผู้ที่ทําอะไร โดยเฉพาะเมื่อมีทีมจํานวนมากที่เกี่ยวข้อง สร้างเอกสารสําหรับบทบาทและความรับผิดชอบ ซึ่งรวมถึงการดําเนินการที่คาดหวัง
  • กําหนดบทบาทและความรับผิดชอบ: กําหนดบทบาทและความรับผิดชอบเฉพาะให้กับบุคคลหรือทีมที่ระบุ อัปเดตคําอธิบายงานแต่ละรายการด้วย ทรัพยากรบุคคล เมื่อเหมาะสม
  • จัดทําแผนการฝึกอบรม: จัดตั้งแผนสําหรับบุคลากรอบรมเมื่อพวกเขาต้องการทักษะใหม่ๆ
  • สร้างแผนการฝึกอบรมแบบข้าม: ตรวจสอบให้แน่ใจว่ามีการฝึกอบรมแบบข้ามและการสํารองข้อมูลสําหรับบทบาทสําคัญหรือไม่

การตัดสินใจทางเทคนิค

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

ระยะการวางแผนระยะแรกเกี่ยวข้องกับการตัดสินใจต่อไปนี้

เลือกเทคโนโลยีเพื่อเข้าถึงข้อมูลการตรวจสอบ

สิ่งแรกที่คุณต้องตัดสินใจคือ วิธี การเข้าถึงข้อมูลการตรวจสอบ

วิธีที่ง่ายที่สุดในการเริ่มต้นใช้งานคือการใช้รายงานที่สร้างไว้ล่วงหน้าซึ่งพร้อมใช้งานใน พื้นที่ทํางานการตรวจสอบผู้ดูแลระบบ

เมื่อคุณต้องการเข้าถึงข้อมูลโดยตรงและสร้างโซลูชันของคุณเอง คุณจะใช้ API (อินเทอร์เฟซโปรแกรมแอปพลิเคชัน) API ถูกออกแบบมาเพื่อแลกเปลี่ยนข้อมูลผ่านอินเทอร์เน็ต Power BI REST API สนับสนุนการร้องขอข้อมูลโดยใช้โพรโทคอล HTTP ภาษาหรือเครื่องมือใด ๆ สามารถเรียกใช้ Power BI REST API เมื่อสามารถส่งคําขอ HTTP และรับการตอบสนอง JSON ได้

เคล็ดลับ

cmdlet ของ PowerShell ใช้ Power BI REST API เพื่อเข้าถึงข้อมูลการตรวจสอบ สําหรับข้อมูลเพิ่มเติม โปรดดู เลือก API หรือ cmdlet ของ PowerShell ในภายหลังที่บทความนี้

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

ตัวเลือกแพลตฟอร์ม

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

นี่คือเทคโนโลยีบางอย่างที่คุณสามารถใช้เพื่อดึงข้อมูลโดยใช้ Power BI REST API

เทคโนโลยี ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
ผู้ดูแลระบบตรวจสอบพื้นที่ทํางาน ผู้ดูแลระบบตรวจสอบพื้นที่ทํางานเป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง
ลองใช้ ลองใช้เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง
PowerShell PowerShell เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง PowerShell เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
Power BI Desktop Power BI Desktop เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง
Power Automate Power Automate เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
บริการ Azure ที่ต้องการ บริการ Azure ที่ต้องการเป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
เครื่องมือ/ภาษาที่ต้องการ เครื่องมือ/ภาษาที่ต้องการเป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง เครื่องมือ/ภาษาที่ต้องการเป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
การค้นหาบันทึกการตรวจสอบ Microsoft Purview การค้นหาบันทึกการตรวจสอบ Purview ของ Microsoft เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง
Defender สำหรับแอประบบคลาวด์ Defender สําหรับ Cloud Apps เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง
Microsoft Sentinel Microsoft Sentinel เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ

ส่วนที่เหลือของส่วนนี้จะให้คําแนะนําสั้น ๆ เกี่ยวกับตัวเลือกแต่ละตัวที่แสดงในตาราง

ผู้ดูแลระบบตรวจสอบพื้นที่ทํางาน

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

ลองใช้ในเอกสาร API

ลองใช้เป็นเครื่องมือแบบโต้ตอบที่ช่วยให้คุณประสบกับ Power BI REST API ได้โดยตรงในเอกสารประกอบของ Microsoft เป็นวิธีที่ง่ายในการสํารวจ API เนื่องจากไม่จําเป็นต้องใช้เครื่องมืออื่นหรือการตั้งค่าใด ๆ บนเครื่องของคุณ

คุณสามารถใช้ลองทําเพื่อ:

  • ส่งคําขอไปยัง API ด้วยตนเองเพื่อตรวจสอบว่าจะส่งกลับข้อมูลที่คุณต้องการหรือไม่
  • เรียนรู้วิธีสร้าง URL ก่อนที่คุณจะเขียนสคริปต์
  • ตรวจสอบข้อมูลด้วยวิธีที่ไม่เป็นทางการ

หมายเหตุ

คุณต้องมีสิทธิ์การใช้งานและผู้ใช้ Power BI ที่ได้รับการรับรองความถูกต้องจึงจะสามารถใช้ Try-it ได้ ซึ่งจะเป็นไปตามแบบจําลองสิทธิ์มาตรฐาน ซึ่งหมายความว่า API ของผู้ใช้จะต้องอาศัยสิทธิ์ผู้ใช้ และ API ของผู้ดูแลระบบจําเป็นต้องมีสิทธิ์ของผู้ดูแลระบบ Power BI คุณไม่สามารถรับรองความถูกต้องด้วย Try-it โดยใช้โครงร่างสําคัญของบริการ

เนื่องจากเป็นแบบโต้ตอบ Try-เหมาะที่สุดสําหรับการเรียนรู้ การสํารวจ และกระบวนการตรวจสอบด้วยตนเองแบบใหม่

PowerShell และ Azure Cloud Shell

คุณสามารถสร้างและเรียกใช้ สคริปต์ PowerShell ได้หลายวิธี

ต่อไปนี้เป็นตัวเลือกทั่วไปหลายตัว

  • Visual Studio Code: ตัวแก้ไขซอร์สโค้ดที่ทันสมัยและน้ําหนักเบา เป็นเครื่องมือโอเพนซอร์สที่ใช้งานได้อย่างอิสระซึ่งได้รับการสนับสนุนในหลายแพลตฟอร์มรวมถึง Windows, macOS และ Linux คุณสามารถใช้ Visual Studio Code กับหลายภาษา รวมถึง PowerShell (โดยใช้ส่วนขยาย PowerShell) ได้
  • Azure Data Studio: เครื่องมือสําหรับสร้างสคริปต์และสมุดบันทึก ซึ่งสร้างขึ้นจากบน Visual Studio Code Azure Data Studio พร้อมใช้งานอย่างอิสระ หรือกับ SQL Server Management Studio (SSMS) มีส่วนขยายมากมาย รวมถึงส่วนขยายสําหรับ PowerShell
  • Azure Cloud Shell: เป็นทางเลือกในการทํางานกับ PowerShell ภายในเครื่อง คุณสามารถเข้าถึง Azure Cloud Shell ได้จากเบราว์เซอร์
  • ฟังก์ชัน Azure: เป็นทางเลือกในการทํางานกับ PowerShell ภายในเครื่อง ฟังก์ชัน Azure คือบริการของ Azure ที่ช่วยให้คุณเขียนและเรียกใช้โค้ดในสภาพแวดล้อมแบบไร้เซิร์ฟเวอร์ PowerShell เป็นหนึ่งในหลายภาษาที่ได้รับการสนับสนุน

สำคัญ

เราขอแนะนําให้คุณใช้ PowerShell เวอร์ชัน ล่าสุด (PowerShell Core) สําหรับงานพัฒนาใหม่ทั้งหมด คุณควรยกเลิกการใช้ Windows PowerShell (ซึ่งไม่สามารถเรียกใช้ PowerShell Core) และใช้หนึ่งในตัวแก้ไขโค้ดที่ทันสมัยที่สนับสนุน PowerShell Core แทน โปรดระวังเมื่ออ้างถึงตัวอย่างออนไลน์มากมายที่ใช้ Windows PowerShell (เวอร์ชัน 5.1) เนื่องจากอาจไม่ใช้รหัสล่าสุด (และดีกว่า) ที่เข้ามาใกล้

คุณสามารถใช้ PowerShell ในหลายวิธีที่แตกต่างกัน สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการตัดสินใจทางเทคนิคนี้ ดู เลือก API หรือ cmdlet ของ PowerShell ในภายหลังในบทความนี้

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

Power BI Desktop

เนื่องจาก Power BI Desktop สามารถเชื่อมต่อกับ API คุณอาจถูกล่อลวงให้ใช้เพื่อสร้างโซลูชันการตรวจสอบของคุณ อย่างไรก็ตาม มีข้อเสียและความซับซ้อนที่สําคัญบางอย่าง

  • ประวัติการสะสม: เนื่องจากบันทึกกิจกรรม Power BI มีข้อมูลสูงสุด 30 วัน การสร้างโซลูชันการตรวจสอบทั้งหมดของคุณเกี่ยวข้องกับการสะสมชุดไฟล์ในช่วงเวลาที่จัดเก็บเหตุการณ์ในอดีตทั้งหมด การสะสมไฟล์ในอดีตเป็นเรื่องง่ายกว่าในการทํากับเครื่องมืออื่น ๆ
  • การจัดการข้อมูลประจําตัวและคีย์ได้อย่างปลอดภัย: โซลูชันมากมายที่คุณพบทางออนไลน์จากบล็อกเกอร์ชุมชนไม่ปลอดภัยเนื่องจากข้อมูลประจําตัวและคีย์ที่ตายตัวในข้อความธรรมดาภายในคิวรี Power Query แม้ว่าวิธีการนั้นจะเป็นเรื่องง่าย แต่ก็ไม่แนะนําเนื่องจากใครก็ตามที่ได้รับไฟล์ Power BI Desktop ของคุณสามารถอ่านค่าได้ คุณไม่สามารถจัดเก็บรหัสผ่าน (เมื่อใช้การรับรองความถูกต้องผู้ใช้) หรือข้อมูลลับ (เมื่อใช้โครงร่างสําคัญของบริการ) ได้อย่างปลอดภัยใน Power BI Desktop เว้นแต่ว่าคุณ:
    • ใช้ตัวเชื่อมต่อแบบกําหนดเองที่พัฒนาด้วย Power Query SDK ตัวอย่างเช่น ตัวเชื่อมต่อแบบกําหนดเองสามารถอ่านค่าที่เป็นความลับจาก Azure Key Vault หรือบริการอื่นที่จัดเก็บค่าที่เข้ารหัสลับได้อย่างปลอดภัย นอกจากนี้ยังมีตัวเลือกตัวเชื่อมต่อแบบกําหนดเองต่าง ๆ ที่พร้อมใช้งานจากชุมชน Power BI ส่วนกลาง
    • ใช้ตัวเลือก ApiKeyName ที่ทํางานได้ดีใน Power BI Desktop อย่างไรก็ตาม จะไม่สามารถจัดเก็บค่าคีย์ไว้ในบริการของ Power BI ได้
  • ชนิดของคําขอ: คุณอาจพบข้อจํากัดบางอย่างสําหรับสิ่งที่คุณสามารถเรียกใช้ใน Power BI Desktop ได้ ตัวอย่างเช่น Power Query ไม่สนับสนุนคําขอ API ทุกประเภท ตัวอย่างเช่น เฉพาะคําขอ GET และ POST เท่านั้นที่ได้รับการสนับสนุนเมื่อใช้ฟังก์ชัน Web.Contents สําหรับการตรวจสอบ โดยทั่วไปแล้วคุณจะส่งคําขอ GET
  • ความสามารถในการรีเฟรช: คุณจําเป็นต้องทําตามรูปแบบการพัฒนา Power Query เฉพาะเพื่อรีเฟรชแบบจําลองความหมายในบริการของ Power BI ให้สําเร็จ ตัวอย่างเช่น RelativePath ตัวเลือกต้องมีอยู่เมื่อใช้ Web.Contents เพื่อให้ Power BI สามารถตรวจสอบตําแหน่งที่ตั้งของแหล่งข้อมูลได้อย่างถูกต้องโดยไม่สร้างข้อผิดพลาดในบริการของ Power BI

ในกรณีส่วนใหญ่ เราขอแนะนําให้คุณใช้ Power BI Desktop สําหรับวัตถุประสงค์สองข้อเท่านั้น คุณควรใช้เพื่อ:

  • สร้างแบบจําลองข้อมูลของคุณโดยยึดตามข้อมูลที่รวบรวมไว้ที่มีอยู่ (แทนที่จะใช้เพื่อแยกข้อมูลการตรวจสอบเบื้องต้น)
  • สร้างรายงานการวิเคราะห์ที่ยึดตามแบบจําลองข้อมูลของคุณ
Power Automate

คุณสามารถใช้ Power Automate กับ Power BI ได้หลายวิธี ในความสัมพันธ์ระหว่างการตรวจสอบ คุณสามารถใช้ Power Automate เพื่อส่งคําขอไปยัง Power BI REST API จากนั้นจัดเก็บข้อมูลที่แยกออกมาในตําแหน่งที่ตั้งที่คุณเลือก

เคล็ดลับ

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

สําหรับแนวคิดอื่น ๆ เกี่ยวกับวิธีใช้ Power Automate ให้ค้นหา Power BI ใน เทมเพลต Power Automate

บริการ Azure ที่ต้องการ

มีหลายบริการ Azure ที่สามารถส่งคําขอไปยัง Power BI REST API คุณสามารถใช้บริการ Azure ที่คุณต้องการเช่น:

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

เครื่องมือและ/หรือภาษาที่ต้องการ

คุณสามารถใช้เครื่องมือที่คุณต้องการและภาษาที่คุณต้องการเพื่อส่งคําขอไปยัง Power BI REST API ซึ่งเป็นวิธีการที่ดีเมื่อทีมของคุณมีความเชี่ยวชาญเกี่ยวกับเครื่องมือหรือภาษาเฉพาะ เช่น:

  • Python
  • C# บน .NET framework อีกวิธีหนึ่งคือ คุณสามารถใช้ Power BI .NET SDK ซึ่งทําหน้าที่เป็นตัวครอบด้านบนของ Power BI REST API เพื่อลดความซับซ้อนของกระบวนการบางอย่างและเพิ่มประสิทธิภาพการทํางาน
  • JavaScript

พอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview (เดิมคือศูนย์การปฏิบัติตามข้อบังคับ Microsoft 365) มีส่วนติดต่อผู้ใช้ที่ช่วยให้คุณสามารถดูและค้นหาบันทึกการตรวจสอบได้ บันทึกการตรวจสอบแบบรวมประกอบด้วย Power BI และบริการอื่น ๆ ทั้งหมดที่สนับสนุนบันทึกการตรวจสอบแบบรวมของ Microsoft 365

ข้อมูลที่รวบรวมไว้ในบันทึกการตรวจสอบแบบรวมคือข้อมูลเดียวกับที่มีอยู่ในบันทึกกิจกรรม Power BI เมื่อคุณทําการค้นหาบันทึกการตรวจสอบในพอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview ก็จะเพิ่มคําขอของคุณไปยังคิว ซึ่งอาจใช้เวลาสักครู่ (หรือนานกว่า นั้นขึ้นอยู่กับปริมาณของข้อมูล) เพื่อให้ข้อมูลพร้อม

ต่อไปนี้เป็นวิธีการทั่วไปในการใช้เครื่องมือค้นหาบันทึกการตรวจสอบ คุณสามารถ:

  • เลือกปริมาณงาน Power BI เพื่อดูเหตุการณ์สําหรับชุดของวันที่
  • ค้นหากิจกรรมที่เฉพาะเจาะจงอย่างน้อยหนึ่งรายการ เช่น:
    • ลบรายงาน Power BI แล้ว
    • เพิ่มการเข้าถึงของผู้ดูแลระบบในพื้นที่ทํางานส่วนบุคคลใน Power BI
  • ดูกิจกรรมของผู้ใช้หนึ่งรายหรือมากกว่า

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

Defender สําหรับส่วนติดต่อผู้ใช้ของ Cloud Apps

Defender สําหรับ Cloud Apps พร้อมใช้งานสําหรับผู้ดูแลระบบใน Microsoft Defender XDR (พอร์ทัล Microsoft 365) ซึ่งรวมถึงอินเทอร์เฟสผู้ใช้เพื่อดูและค้นหาบันทึกกิจกรรมสําหรับบริการคลาวด์ต่าง ๆ รวมถึง Power BI ซึ่งแสดงเหตุการณ์บันทึกเดียวกันกับที่มีต้นกําเนิดในพอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview นอกเหนือจากเหตุการณ์อื่น ๆ เช่นกิจกรรมการลงชื่อเข้าใช้ของผู้ใช้จาก Microsoft Entra ID

อินเทอร์เฟซบันทึกการตรวจสอบใน Defender สําหรับ Cloud Apps เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง สําหรับข้อมูลเพิ่มเติม โปรดดู Defender for Cloud Apps ในภายหลังที่บทความนี้

Microsoft Sentinel และ KQL

Microsoft Sentinel เป็นบริการ Azure ที่ช่วยให้คุณสามารถรวบรวม ตรวจจับ ตรวจสอบ และตอบสนองต่อเหตุการณ์และภัยคุกคามด้านความปลอดภัยได้ Power BI สามารถตั้งค่าใน Microsoft Sentinel เป็นตัวเชื่อมต่อข้อมูล เพื่อให้บันทึกการตรวจสอบถูกสตรีมจาก Power BI ลงใน Microsoft Sentinel Azure Log Analytics (ซึ่งเป็นคอมโพเนนต์ของ บริการ Azure Monitor ) คุณสามารถใช้ Kusto Query Language (KQL) เพื่อวิเคราะห์เหตุการณ์บันทึกกิจกรรมที่จัดเก็บไว้ใน Azure Log Analytics

การใช้ KQL ในการค้นหาข้อมูลใน Azure Monitor เป็นตัวเลือกที่ดีสําหรับการดูส่วนหนึ่งของบันทึกการตรวจสอบ ซึ่งเป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเองเช่นกัน สําหรับข้อมูลเพิ่มเติม โปรดดู Microsoft Sentinel ในภายหลังที่บทความนี้

ข้อควรพิจารณาของแพลตฟอร์ม

ต่อไปนี้คือข้อควรพิจารณาบางอย่างสําหรับวิธีที่คุณอาจเข้าถึงข้อมูลการตรวจสอบ

  • คุณใช้กระบวนการตรวจสอบด้วยตนเองหรืออัตโนมัติใช่หรือไม่ เครื่องมือบางตัวปรับให้สอดคล้องกับการประมวลผลด้วยตนเองหรือการประมวลผลอัตโนมัติ ตัวอย่างเช่น ผู้ใช้จะเรียกใช้ฟังก์ชัน Try-it แบบโต้ตอบเสมอ ดังนั้นจึงเหมาะสมสําหรับกระบวนการตรวจสอบด้วยตนเองเท่านั้น
  • คุณจะรับรองความถูกต้องอย่างไร? ตัวเลือกทั้งหมดไม่รองรับทุกตัวเลือกการรับรองความถูกต้อง ตัวอย่างเช่น ฟังก์ชัน Try-it สนับสนุนเฉพาะการรับรองความถูกต้องผู้ใช้เท่านั้น
  • คุณจะจัดเก็บข้อมูลประจําตัวอย่างปลอดภัยได้อย่างไร เทคโนโลยีที่แตกต่างกันมีตัวเลือกที่แตกต่างกันสําหรับการจัดเก็บข้อมูลประจําตัว สําหรับข้อมูลเพิ่มเติม ดู กําหนดวิธี การรับรองความถูกต้องในภายหลังในบทความนี้
  • เทคโนโลยีใดที่ทีมของคุณเชี่ยวชาญอยู่แล้ว หากมีเครื่องมือที่ทีมของคุณชอบและมีความสะดวกในการใช้ ให้เริ่มต้นที่นั่น
  • ทีมของคุณมีความสามารถในการสนับสนุนอะไร หากทีมอื่นจะสนับสนุนโซลูชันที่ปรับใช้ให้พิจารณาว่าทีมนั้นสามารถสนับสนุนได้อย่างเพียงพอหรือไม่ นอกจากนี้ ให้พิจารณาว่าทีมภายในของคุณอาจสนับสนุนการพัฒนาที่ผู้ให้คําปรึกษาทํา
  • คุณมีเครื่องมือใดที่คุณต้องอนุมัติเพื่อใช้ เครื่องมือและเทคโนโลยีบางอย่างอาจจําเป็นต้องได้รับการอนุมัติ ซึ่งอาจเกิดจากค่าใช้จ่าย ซึ่งอาจเนื่องมาจากนโยบายการรักษาความปลอดภัยด้าน IT
  • การกําหนดลักษณะของคุณสําหรับกําหนดเวลาคืออะไร? เทคโนโลยีบางอย่างตัดสินใจให้คุณ บางครั้งมันจะเป็นการตัดสินใจอีกอย่างที่คุณต้องทํา ตัวอย่างเช่น ถ้าคุณเลือกที่จะเขียนสคริปต์ PowerShell มีหลายวิธีที่คุณสามารถกําหนดตารางเวลาการเรียกใช้สคริปต์เหล่านั้นได้ ในทางกลับกัน ถ้าคุณใช้บริการระบบคลาวด์ เช่น Azure Data Factory การจัดกําหนดการจะถูกสร้างขึ้นมา

เราขอแนะนําให้คุณตรวจสอบส่วนที่เหลือของบทความนี้ก่อนที่จะเลือกเทคโนโลยีเพื่อเข้าถึงข้อมูลการตรวจสอบ

รายการตรวจสอบ - เมื่อตัดสินใจว่าจะใช้เทคโนโลยีใดในการเข้าถึงข้อมูลการตรวจสอบ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • พูดคุยกับเจ้าหน้าที่ไอทีของคุณ: พูดคุยกับทีมไอทีของคุณเพื่อดูว่ามีเครื่องมือบางอย่างที่ได้รับการอนุมัติหรือต้องการ
  • สํารวจตัวเลือกพร้อมการพิสูจน์แนวคิด (POC) ขนาดเล็ก: ทําการทดลองกับ POC ทางเทคนิค มุ่งเน้นไปที่การเรียนรู้เบื้องต้น จากนั้นมุ่งเน้นไปที่การตัดสินใจของคุณสําหรับสิ่งที่จะใช้ในอนาคต

กําหนดวิธีการรับรองความถูกต้อง

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

สำคัญ

ปรึกษากับทีมไอทีและทีมรักษาความปลอดภัยของคุณในเรื่องนี้ ใช้เวลาในการเรียนรู้พื้นฐานของวิธีการทํางานของการรักษาความปลอดภัยใน Microsoft Entra ID

ไม่ใช่ทุก API บนอินเทอร์เน็ตที่จําเป็นต้องรับรองความถูกต้อง อย่างไรก็ตาม Power BI REST API ทั้งหมดจําเป็นต้องมีการรับรองความถูกต้อง เมื่อคุณเข้าถึงข้อมูลการตรวจสอบระดับผู้เช่า กระบวนการรับรองความถูกต้องถูกจัดการโดยแพลตฟอร์มข้อมูลประจำตัวของ Microsoft ซึ่งเป็นวิวัฒนาการของบริการข้อมูลประจําตัวของ Microsoft Entra ที่สร้างขึ้นบนโพรโทคอลมาตรฐานอุตสาหกรรม

เคล็ดลับ

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

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

เมื่อผู้ใช้หรือบริการหลักรับรองความถูกต้อง โทเค็นการเข้าถึง Microsoft Entra ถูกออกไปยังเซิร์ฟเวอร์ทรัพยากร เช่น Power BI REST API หรือ Microsoft Graph API ตามค่าเริ่มต้น โทเค็นการเข้าถึงจะหมดอายุหลังจากหนึ่งชั่วโมง สามารถร้องขอโทเค็นการรีเฟรชได้ถ้าจําเป็น

มีโทเค็นการเข้าถึงสองชนิด:

  • โทเค็นผู้ใช้: ออกในนามของผู้ใช้ที่มีข้อมูลประจําตัวที่รู้จัก
  • โทเค็นเฉพาะแอป: ออกในนามของแอปพลิเคชัน Microsoft Entra (บริการหลัก)

สําหรับข้อมูลเพิ่มเติม ดู แอปพลิเคชันและบริการหลักในรหัส Microsoft Entra

หมายเหตุ

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

เคล็ดลับ

วิธีที่ง่ายที่สุดในการรับรองความถูกต้องคือการใช้ Connect-PowerBIServiceAccount cmdlet จากโมดูลการจัดการ Power BI คุณอาจเห็น cmdlet ที่เกี่ยวข้องกับการรับรองความถูกต้องอื่น ๆ ในบทความและบล็อกโพสต์ออนไลน์ ตัวอย่างเช่น มี Login-PowerBI cmdlet และ Login-PowerBIServiceAccount ซึ่งเป็นนามแฝงสําหรับ Connect-PowerBIServiceAccount cmdlet นอกจากนี้ยังมี cmdlet Disconnect-PowerBIServiceAccount ที่คุณสามารถใช้เพื่อลงชื่อออกอย่างชัดเจนในตอนท้ายของกระบวนการ

ตารางต่อไปนี้อธิบายตัวเลือกการรับรองความถูกต้องสองตัวเลือก

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

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

การรับรองความถูกต้องของผู้ใช้

การรับรองความถูกต้องผู้ใช้มีประโยชน์ในสถานการณ์ต่อไปนี้

  • กระบวนการตรวจสอบด้วยตนเอง: คุณต้องการเรียกใช้สคริปต์โดยใช้สิทธิ์ผู้ใช้ของคุณ สิทธิ์อาจเป็นหนึ่งในสองระดับ ขึ้นอยู่กับชนิดของคําขอ API:
    • สิทธิ์ผู้ดูแลระบบสําหรับ api ของผู้ดูแลระบบ: คุณจําเป็นต้องใช้สิทธิ์ผู้ดูแลระบบ Power BI ของคุณเพื่อส่งคําขอไปยังAPI ผู้ดูแลระบบของ
    • สิทธิ์ผู้ใช้สําหรับ API ของผู้ใช้: คุณจําเป็นต้องใช้สิทธิ์ผู้ใช้ Power BI ของคุณเพื่อส่งคําขอไปยังAPI ของผู้ใช้ สําหรับข้อมูลเพิ่มเติม ดูเลือก API ของผู้ใช้หรือผู้ดูแลระบบ API
  • ลงชื่อเข้าใช้แบบโต้ตอบ: คุณต้องการลงชื่อเข้าใช้แบบโต้ตอบ ซึ่งต้องการให้คุณป้อนที่อยู่อีเมลและรหัสผ่านของคุณ ตัวอย่างเช่น คุณต้องลงชื่อเข้าใช้แบบโต้ตอบเพื่อใช้ ประสบการณ์ Try-it ซึ่งอยู่ในเอกสาร Microsoft API
  • ติดตามว่าใครเข้าถึงเมตาดาต้าของผู้เช่า: เมื่อผู้ใช้แต่ละคนและผู้ดูแลระบบส่งคําขอ API คุณอาจต้องการตรวจสอบว่าบุคคลเหล่านั้นเป็นใคร เมื่อคุณรับรองความถูกต้องด้วยบริการหลัก (อธิบายต่อไป) ID ผู้ใช้ที่รวบรวมโดยบันทึกกิจกรรมคือ ID แอปพลิเคชัน ถ้าผู้ดูแลระบบหลายคนรับรองความถูกต้องด้วยบริการหลักเดียวกัน อาจเป็นเรื่องยากที่จะทราบว่าผู้ดูแลระบบคนใดเข้าถึงข้อมูลดังกล่าว
  • บัญชีผู้ดูแลที่ใช้ร่วมกัน : บางทีมไอทีใช้บัญชีผู้ดูแลระบบที่ใช้ร่วมกัน อาจไม่ใช่แนวทางปฏิบัติที่ดีที่สุด ทั้งนี้ขึ้นอยู่กับวิธีการใช้งานและการควบคุม แทนที่จะเป็นบัญชีที่ใช้ร่วมกัน คุณควรพิจารณาใช้ Microsoft Entra Privileged Identity Management (PIM) ซึ่งสามารถให้สิทธิ์ผู้ดูแลระบบ Power BI เป็นบางครั้งและชั่วคราวสําหรับผู้ใช้ได้
  • API ที่สนับสนุนเฉพาะการรับรองความถูกต้องผู้ใช้: บางครั้งคุณอาจจําเป็นต้องใช้ API ที่ไม่สนับสนุนการรับรองความถูกต้องโดยโครงร่างสําคัญของบริการ ในเอกสารประกอบ บันทึกย่อ API แต่ละรายการว่าโครงร่างสําคัญของบริการสามารถเรียกใช้ได้หรือไม่

สำคัญ

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

การรับรองความถูกต้องหลักของบริการ

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

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

เนื่องจากโครงร่างสําคัญของบริการคือการเป็นตัวแทนภายในเครื่อง คําว่า การรับรองความถูกต้องของ โครงร่างสําคัญของบริการเป็นวิธีทั่วไปในการอ้างอิงถึงการลงชื่อเข้าใช้

เคล็ดลับ

ผู้ดูแลระบบ Microsoft Entra ของคุณสามารถบอกคุณได้ว่าใครได้รับอนุญาตให้ สร้างและยินยอมให้ลงทะเบียนแอปในองค์กรของคุณ

การรับรองความถูกต้องแบบโครงร่างสําคัญของบริการจะมีประโยชน์ในสถานการณ์ต่อไปนี้

  • กระบวนการตรวจสอบอัตโนมัติ: คุณต้องการเรียกใช้กระบวนการทํางานแบบอัตโนมัติตามกําหนดเวลา
  • ไม่จําเป็นต้องลงชื่อเข้าใช้บริการของ Power BI: คุณเพียงแค่ต้องเชื่อมต่อและแยกข้อมูลเท่านั้น บริการหลักไม่สามารถลงชื่อเข้าใช้บริการของ Power BI ได้
  • การเข้าถึงที่แชร์ไปยังข้อมูล : คุณ (ส่วนบุคคล) ไม่ใช่ผู้ดูแลระบบ Power BI แต่คุณได้รับอนุญาตให้ใช้บริการหลัก โครงร่างสําคัญของบริการมีสิทธิ์ในการเรียกใช้ API ของผู้ดูแลระบบเพื่อดึงข้อมูลระดับผู้เช่า (หรือสิทธิ์เฉพาะอื่น ๆ)
  • ใช้โดยผู้ดูแลระบบหลายคน: คุณต้องการอนุญาตให้ผู้ดูแลระบบหรือผู้ใช้หลายคนสามารถใช้บริการหลักเดียวกันได้
  • ตัวบล็อกทางเทคนิค: มีตัวบล็อกทางเทคนิคที่ป้องกันไม่ให้ใช้การรับรองความถูกต้องของผู้ใช้ ตัวบล็อกทางเทคนิคทั่วไปประกอบด้วย:
    • การรับรองความถูกต้องโดยใช้หลายปัจจัย (MFA): กระบวนการตรวจสอบอัตโนมัติ (ที่เรียกใช้แบบอัตโนมัติ) ไม่สามารถรับรองความถูกต้องโดยใช้บัญชีผู้ใช้เมื่อเปิดใช้งานการรับรองความถูกต้องแบบหลายปัจจัย
    • Password Hash synchronization: Microsoft Entra ID ต้องการการซิงโครไนซ์แฮชรหัสผ่าน สําหรับบัญชีผู้ใช้เพื่อรับรองความถูกต้อง บางครั้งแผนกไอทีหรือทีมรักษาความปลอดภัยทางไซเบอร์อาจปิดใช้งานฟังก์ชันนี้
วัตถุประสงค์การลงทะเบียนแอปและแบบแผนการตั้งชื่อ

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

พิจารณาใช้แบบแผนการตั้งชื่อเช่น: <ปริมาณ> งาน - <วัตถุประสงค์> - <เป้าหมาย -><ชนิดของวัตถุ>

ต่อไปนี้คือส่วนต่างๆ ของแบบแผนการตั้งชื่อ

  • ปริมาณงาน: โดยปกติแล้วจะเทียบเท่ากับแหล่งข้อมูล (ตัวอย่างเช่น ข้อมูล Power BI หรือข้อมูล Microsoft Graph)
  • วัตถุประสงค์: คล้ายกับระดับของสิทธิ์ (ตัวอย่างเช่น อ่านเทียบกับ ReadWrite) ตามที่อธิบายไว้ด้านล่าง วัตถุประสงค์จะช่วยให้คุณสามารถปฏิบัติตาม หลักการของสิทธิ์พิเศษ เป็นอย่างน้อยเมื่อคุณสร้างการลงทะเบียนแอปแยกต่างหากที่สามารถอ่านได้เฉพาะข้อมูลเท่านั้น
  • ผู้ชมเป้าหมาย: เป็นทางเลือก ผู้ชมเป้าหมายช่วยให้คุณสามารถกําหนดผู้ใช้ที่ต้องการของการลงทะเบียนแอปได้ ทั้งนี้ขึ้นอยู่กับปริมาณและวัตถุประสงค์
  • ชนิดวัตถุ : EntraApp ถูกรวมไว้เพื่อความชัดเจน

มาตรฐานการตั้งชื่อของคุณสามารถระบุได้มากขึ้นเมื่อคุณมีผู้เช่าหลายรายหรือหลายสภาพแวดล้อม (เช่น การพัฒนาและการผลิต)

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

ชื่อการลงทะเบียนแอป วัตถุประสงค์ ผู้ชมเป้าหมาย
PowerBIData-Read-AdminAPIs-EntraApp แยกเมตาดาต้าทั่วทั้งผู้เช่าสําหรับการตรวจสอบและการจัดการ Power BI Api ของผู้ดูแลระบบจะเป็นแบบอ่านอย่างเดียวเสมอและอาจไม่มีสิทธิ์ที่มอบให้ใน Microsoft Entra ID (การตั้งค่าผู้เช่า Power BI เท่านั้น) ผู้ดูแลระบบ Power BI และศูนย์แห่งความเป็นเลิศ
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp จัดการผู้เช่า Power BI จําเป็นต้องมีสิทธิ์ในการอ่าน/เขียนเพื่อสร้างหรืออัปเดตทรัพยากร ผู้ดูแลระบบ Power BI และศูนย์แห่งความเป็นเลิศ
GraphData-Read-PowerBIAdministrators-EntraApp แยกข้อมูลผู้ใช้และกลุ่มสําหรับการตรวจสอบและการจัดการ Power BI จําเป็นต้องมีสิทธิ์ในการอ่าน ผู้ดูแลระบบ Power BI และศูนย์แห่งความเป็นเลิศ

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

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

มีสองวิธีหลักที่การลงทะเบียนแอปสามารถเข้าถึงข้อมูลและแหล่งข้อมูลได้ ซึ่งเกี่ยวข้องกับการอนุญาตและการยินยอม

  • สิทธิ์เฉพาะแอป: การเข้าถึงและการอนุญาตถูกจัดการโดยโครงร่างสําคัญของบริการโดยไม่ต้องมีผู้ใช้ที่ลงชื่อเข้าใช้ วิธีการรับรองความถูกต้องนั้นมีประโยชน์สําหรับสถานการณ์อัตโนมัติ เมื่อใช้สิทธิ์เฉพาะแอป เป็นสิ่งสําคัญที่ต้องทําความเข้าใจว่าสิทธิ์ ไม่ได้ถูก กําหนดไว้ใน MICROSOFT Entra ID แต่จะมีการมอบหมายสิทธิ์หนึ่งในสองวิธี:
    • สําหรับการเรียกใช้ api ของผู้ดูแลระบบ: การตั้งค่าผู้เช่า Fabric บางรายการอนุญาตให้เข้าถึงจุดสิ้นสุดสําหรับ API ของผู้ดูแลระบบ (ที่ส่งกลับเมตาดาต้าการตรวจสอบทั่วทั้งผู้เช่า) สําหรับข้อมูลเพิ่มเติม โปรดดู ตั้งค่าผู้เช่า Fabric ภายหลังในบทความนี้
    • สําหรับการเรียกใช้ API ของผู้ใช้: ใช้สิทธิ์ในพื้นที่ทํางานของ Power BI และรายการ สิทธิ์ Power BI มาตรฐานควบคุมว่าข้อมูลใดสามารถถูกส่งกลับไปยังบริการหลักเมื่อเรียกใช้ API ของผู้ใช้ (ที่ส่งกลับการตรวจสอบข้อมูลตามสิทธิ์ของผู้ใช้หรือบริการหลักที่กําลังเรียกใช้ API)
  • สิทธิ์ที่ได้รับมอบหมาย: ใช้สิทธิ์ตามขอบเขต บริการหลักเข้าถึงข้อมูลในนามของผู้ใช้ที่มีการลงชื่อเข้าใช้ในปัจจุบัน ซึ่งหมายความว่าโครงร่างสําคัญของบริการไม่สามารถเข้าถึงสิ่งที่นอกเหนือจากสิ่งที่ผู้ใช้ที่ลงชื่อเข้าใช้สามารถเข้าถึงได้ โปรดทราบว่านี่เป็นแนวคิดที่แตกต่างจากการรับรองความถูกต้องเฉพาะผู้ใช้ที่อธิบายไว้ก่อนหน้านี้ เนื่องจากจําเป็นต้องใช้แอปพลิเคชันแบบกําหนดเองเพื่อจัดการการรวมกันของสิทธิ์ของผู้ใช้และแอปอย่างถูกต้อง สิทธิ์ที่ได้รับมอบจึงไม่ค่อยใช้สําหรับสถานการณ์การตรวจสอบ แนวคิดนี้มักเข้าใจผิด ซึ่งนําไปสู่การลงทะเบียนแอปจํานวนมากที่มีสิทธิ์การใช้งานมากเกินไป

สำคัญ

ในบทความนี้ มุ่งเน้นเฉพาะการรับรองความถูกต้องผู้ใช้หรือการรับรองความถูกต้องเฉพาะแอปเท่านั้น สิทธิ์ที่ได้รับมอบ (ด้วยผู้ใช้แบบโต้ตอบและโครงร่างสําคัญของบริการ) สามารถมีบทบาทสําคัญเมื่อทําการฝังเนื้อหา Power BI ทางโปรแกรม อย่างไรก็ตาม เราไม่สนับสนุนคุณจากการตั้งค่าสิทธิ์ที่ได้รับมอบหมายสําหรับการดึงข้อมูลการตรวจสอบ API ทุกตัวจะจํากัดความถี่ที่สามารถเรียกใช้ได้ (ด้วยการจํากัดผลลัพธ์) ดังนั้นจึงไม่เป็นประโยชน์ที่จะให้ผู้ใช้ที่แตกต่างกันเข้าถึงข้อมูลการตรวจสอบดิบโดยตรง แต่เราขอแนะนําให้คุณแยกข้อมูลการตรวจสอบดิบหนึ่งครั้ง (ด้วยกระบวนการแบบรวมศูนย์) จากนั้นจึงทําให้ข้อมูลการตรวจสอบที่รวบรวมไว้พร้อมใช้งานสําหรับปลายทางของผู้ใช้ที่ได้รับอนุญาต

สําหรับข้อมูลเพิ่มเติม ดู ลงทะเบียนแอป Microsoft Entra ภายหลังในบทความนี้

ข้อมูลลับในการลงทะเบียนแอป

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

นอกจากนี้คุณยังจําเป็นต้องกังวลเกี่ยวกับตําแหน่งที่จะจัดเก็บข้อมูลลับอย่างปลอดภัย ชุดเก็บรหัสผ่านขององค์กร เช่น Azure Key Vault เป็นตัวเลือกที่ยอดเยี่ยม

เคล็ดลับ

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

จัดการข้อมูลประจําตัวอย่างปลอดภัย

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

ข้อควรระวัง

กฎข้อแรกคือหลายคนละเมิด: รหัสผ่านและคีย์ไม่ควรปรากฏในข้อความธรรมดาในสคริปต์ บทความ บล็อก และตัวอย่างมากมายทําออนไลน์เพื่อความเรียบง่าย อย่างไรก็ตาม เป็นแนวทางปฏิบัติที่ไม่ดีที่ควรหลีกเลี่ยง ทุกคนที่ได้รับสคริปต์ (หรือไฟล์) อาจสามารถเข้าถึงข้อมูลเดียวกันกับที่ผู้เขียนมีสิทธิ์เข้าถึงได้

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

  • รวมกับ Azure Key Vault หรือระบบชุดเก็บรหัสผ่านขององค์กรอื่นเมื่อใดก็ตามที่เป็นไปได้
  • ใช้ ข้อมูลประจําตัวและสตริง ที่ปลอดภัยในสคริปต์ PowerShell ของคุณ ข้อมูลประจําตัวทํางานสําหรับการรับรองความถูกต้องผู้ใช้และการรับรองความถูกต้องแบบโครงร่างสําคัญของบริการ อย่างไรก็ตาม คุณไม่สามารถใช้ข้อมูลประจําตัวเมื่อมีการเปิดใช้งานการรับรองความถูกต้องแบบหลายปัจจัยสําหรับบัญชีผู้ใช้
  • พร้อมท์สําหรับรหัสผ่านในสคริปต์ PowerShell ของคุณ หรือใช้การรับรองความถูกต้องแบบโต้ตอบกับเบราว์เซอร์
  • ใช้มอดูลการจัดการความลับสําหรับ PowerShell ที่เผยแพร่โดย Microsoft ซึ่งสามารถจัดเก็บค่าโดยใช้ชุดเก็บภายในเครื่อง นอกจากนี้ยังสามารถรวมกับ Azure Key Vault จากระยะไกล ซึ่งจะเป็นประโยชน์เมื่อมีผู้ดูแลระบบหลายคนในองค์กรของคุณที่ทํางานกับสคริปต์เดียวกัน
  • สร้างตัว เชื่อมต่อ แบบกําหนดเองสําหรับ Power BI Desktop เพื่อให้สามารถจัดการข้อมูลประจําตัวได้อย่างปลอดภัย ตัวเชื่อมต่อแบบกําหนดเองบางตัวจะพร้อมใช้งานจากสมาชิกชุมชน (โดยปกติอยู่บน GitHub)

เคล็ดลับ

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

ไลบรารีการรับรองความถูกต้องของ Microsoft

การสนับสนุนสําหรับ Azure AD Authentication Library (ADAL) สิ้นสุดในเดือนธันวาคม 2022 ไปข้างหน้า คุณควรใช้ ไลบรารี การรับรองความถูกต้องของ Microsoft (MSAL) ทีมรักษาความปลอดภัยในองค์กรของคุณควรมีความคุ้นเคยกับการเปลี่ยนแปลงที่สําคัญนี้

แม้ว่าจะไม่สําคัญที่ผู้เชี่ยวชาญ Power BI จะเข้าใจอย่างลึกซือเกี่ยวกับการเปลี่ยนไปยัง MSAL คุณควรปฏิบัติตามคําแนะนําต่อไปนี้

  • ใช้เวอร์ชันล่าสุดของโมดูลการจัดการ Power BI เมื่อคุณรับรองความถูกต้องด้วย cmdlet Connect-PowerBIServiceAccount PowerShell โดยเปลี่ยนจาก ADAL เป็น MSAL ในเวอร์ชัน 1.0.946 (26 กุมภาพันธ์ 2021)
  • ใช้จุดสิ้นสุด Microsoft Entra V2 เมื่อคุณรับรองความถูกต้องในสคริปต์ของคุณโดยตรง จุดสิ้นสุด Microsoft Entra V2 ใช้ MSAL ในขณะที่จุดสิ้นสุด Microsoft Entra V1 ใช้ ADAL
  • ยุติการใช้ API และโมดูลที่เลิกใช้แล้ว สําหรับข้อมูลเพิ่มเติม โปรดดู API และโมดูล ที่ไม่สนับสนุนในบทความนี้ในภายหลัง
  • ถ้าคุณพบโซลูชันชุมชนออนไลน์ ตรวจสอบให้แน่ใจว่า ใช้ MSAL สําหรับการรับรองความถูกต้องแทน ADAL

รายการตรวจสอบ – เมื่อตัดสินใจวิธีการจัดการการรับรองความถูกต้อง การตัดสินใจที่สําคัญและการดําเนินการประกอบด้วย:

  • ตัดสินใจว่าการรับรองความถูกต้องประเภทใดที่จะใช้: ตรวจสอบว่าการรับรองความถูกต้องของผู้ใช้หรือการรับรองความถูกต้องแบบโครงร่างสําคัญของบริการเหมาะสมที่สุดหรือไม่ โดยขึ้นอยู่กับชนิดของโซลูชันการตรวจสอบที่คุณวางแผนที่จะสร้าง
  • วางแผนสําหรับการลงทะเบียนแอปที่คุณต้องการ: พิจารณาข้อกําหนด ปริมาณงาน และผู้ชมเป้าหมายของคุณ (ผู้ใช้ของแต่ละการลงทะเบียนแอป) วางแผนสําหรับจํานวนการลงทะเบียนแอปที่คุณต้องการสร้างเพื่อสนับสนุนความต้องการเหล่านี้
  • สร้างแบบแผนการตั้งชื่อสําหรับการลงทะเบียนแอป: ตั้งค่ามาตรฐานการตั้งชื่อที่ทําให้ง่ายต่อการทําความเข้าใจวัตถุประสงค์ที่ตั้งใจไว้และผู้ใช้ที่ตั้งใจลงทะเบียนแอป
  • วางแผนสําหรับวิธีการจัดการข้อมูลประจําตัวได้อย่างปลอดภัย : พิจารณาวิธีการจัดการรหัสผ่าน ความลับ และคีย์อย่างปลอดภัย พิจารณาว่าเอกสารประกอบและการฝึกอบรมใดที่จําเป็น
  • ยืนยันการใช้ MSAL: ตรวจสอบว่ามีโซลูชันการตรวจสอบด้วยตนเองหรืออัตโนมัติที่มีอยู่ที่อาศัย ADAL หรือไม่ ถ้าจําเป็น ให้สร้างแผนที่จะเขียนโซลูชันเหล่านี้ใหม่เพื่อใช้ไลบรารีการรับรองความถูกต้อง MSAL ที่ใหม่กว่า

เลือก API ของผู้ใช้หรือ API ผู้ดูแลระบบ

เมื่อวางแผนที่จะดึงข้อมูลการตรวจสอบคุณจําเป็นต้องใช้ API ประเภทที่ถูกต้อง

มี API สองประเภทที่ต้องพิจารณา

  • Api ของผู้ใช้ : ขึ้นอยู่กับสิทธิ์ของผู้ใช้ที่ลงชื่อเข้าใช้ (หรือบริการหลัก) เพื่อส่งคําขอไปยัง API ตัวอย่างเช่น วิธีหนึ่งในการส่งคืนรายการแบบจําลองความหมายในพื้นที่ทํางานคือ ด้วย API ของผู้ใช้ สิทธิ์ใน การอ่านแบบจําลอง ความหมายสามารถได้รับโดยบทบาทพื้นที่ทํางานหรือสิทธิ์ต่อรายการอย่างใดอย่างหนึ่ง การเรียกใช้ API ของผู้ใช้มีสองวิธี:
    • การรับรองความถูกต้องผู้ใช้: ผู้ใช้ที่ลงชื่อเข้าใช้ต้องมีสิทธิ์ในการเข้าถึงพื้นที่ทํางานหรือรายการ
    • การรับรองความถูกต้องของบริการหลัก: บริการหลักต้องมีสิทธิ์ในการเข้าถึงพื้นที่ทํางานหรือรายการ
  • Admin API: เรียกใช้เมตาดาต้าจากผู้เช่า บางครั้งเรียกว่า ขอบเขตองค์กร ตัวอย่างเช่น ในการส่งคืนรายการของแบบจําลองความหมายทั้งหมดในผู้เช่า ให้คุณใช้ API ของผู้ดูแลระบบ มีสองวิธีในการเรียกใช้ API ของผู้ดูแลระบบ:
    • การรับรองความถูกต้องผู้ใช้ : ผู้ใช้ที่ลงชื่อเข้าใช้ต้องเป็นผู้ดูแลระบบ Power BI เพื่อเรียกใช้ API ของผู้ดูแลระบบ
    • การรับรองความถูกต้องของบริการหลัก: โครงร่างสําคัญของบริการต้องมีสิทธิ์ในการเรียกใช้ API ของผู้ดูแลระบบ (โดยไม่ต้องขึ้นอยู่กับสิทธิ์ด้านความปลอดภัยอย่างที่ API ของผู้ใช้ทํา)

เคล็ดลับ

API ของผู้ดูแลระบบทั้งหมดอยู่ในกลุ่มการดําเนินการของผู้ดูแลระบบ API ใดก็ตามที่มี คําต่อท้ายเป็นผู้ดูแลระบบ คือ API ของผู้ดูแลระบบ API ที่เหลือทั้งหมดคือ API ของผู้ใช้

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

ชื่อ API ชนิดของ API Scope จํานวนของแบบจําลองความหมาย
รับชุดข้อมูล User พื้นที่ทํางานส่วนบุคคล หนึ่ง
รับชุดข้อมูล User พื้นที่ทํางานส่วนบุคคล All
รับชุดข้อมูลในกลุ่ม User หนึ่งพื้นที่ทํางาน หนึ่งในกรณีที่ผู้ใช้ที่ลงชื่อเข้าใช้มีสิทธิ์ในการอ่านแบบจําลองความหมาย
รับชุดข้อมูลในกลุ่ม User หนึ่งพื้นที่ทํางาน ทั้งหมด ที่ระบุให้ผู้ใช้ที่ลงชื่อเข้าใช้มีสิทธิ์ในการอ่านแบบจําลองความหมายแต่ละแบบ
รับชุดข้อมูลในกลุ่มในฐานะผู้ดูแลระบบ ผู้ดูแลระบบ หนึ่งพื้นที่ทํางาน All
รับชุดข้อมูลเป็นผู้ดูแลระบบ ผู้ดูแลระบบ ผู้เช่าทั้งหมด All

หมายเหตุ

ชื่อ API บางชื่อรวมกลุ่มเป็นการอ้างอิงไปยังพื้นที่ทํางาน คํานั้นมาจากรูปแบบความปลอดภัยของ Power BI เดิม ซึ่งขึ้นอยู่กับกลุ่ม Microsoft 365 ในขณะที่แบบจําลองความปลอดภัยของ Power BI มีการพัฒนาอย่างมากในช่วงหลายปีที่ผ่านมา แต่ชื่อ API ที่มีอยู่ยังคงไม่เปลี่ยนแปลงเพื่อหลีกเลี่ยงการทําลายโซลูชันที่มีอยู่

สําหรับข้อมูลเกี่ยวกับการตั้งค่าผู้เช่า โปรดดู ตั้งค่าผู้เช่า Fabric ภายหลังในบทความนี้

รายการตรวจสอบ - เมื่อเลือกว่าจะใช้ API ของผู้ใช้หรือ API ของผู้ดูแลระบบ การตัดสินใจและการดําเนินการที่สําคัญรวมถึง:

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

เลือก API หรือ cmdlet ของ PowerShell

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

PowerShell เป็นโซลูชันแบบอัตโนมัติของงาน คําว่า PowerShell เป็นคํารวมที่อ้างถึงภาษาการเขียนสคริปต์ แอปพลิเคชันเชลล์บรรทัดคําสั่ง และเฟรมเวิร์กการจัดการการกําหนดค่า PowerShell Core เป็น PowerShell เวอร์ชันใหม่ล่าสุดที่ทํางานบน Windows, Linux และ macOS

Cmdlet ของ PowerShell เป็นคําสั่งที่ทําการดําเนินการ มอดูล PowerShell เป็นแพคเกจที่ประกอบด้วยสมาชิก PowerShell เช่น cmdlets ผู้ให้บริการ ฟังก์ชัน เวิร์กโฟลว์ ตัวแปร และนามแฝง คุณดาวน์โหลดและติดตั้งโมดูล

มอดูล PowerShell สร้างเลเยอร์ของนามธรรมเหนือ API ตัวอย่างเช่น รับ-PowerBIActivityEvent cmdlet เรียกใช้ (หรือ รับ) เหตุการณ์การตรวจสอบสําหรับผู้เช่า Power BI cmdlet ของ PowerShell นี้จะดึงข้อมูลมาจาก รับกิจกรรมกิจกรรม REST API โดยทั่วไปแล้ว จะง่ายกว่าในการเริ่มต้นใช้งานโดยใช้ cmdlet เนื่องจากจะทําให้ง่ายต่อการเข้าถึง API พื้นฐาน

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

โมดูล PowerShell

Microsoft ได้เผยแพร่มอดูล PowerShell สองมอดูลที่มี cmdlet ที่เกี่ยวข้องกับ Power BI ซึ่งเป็นมอดูลการจัดการ Power BI และเกตเวย์ข้อมูล โมดูล PowerShell เหล่านี้ทําหน้าที่เป็น ตัวคลุม API ที่ด้านบนของ Power BI REST API พื้นฐาน การใช้โมดูล PowerShell เหล่านี้สามารถทําให้การเขียนสคริปต์ง่ายขึ้น

เคล็ดลับ

นอกเหนือจากมอดูลที่เผยแพร่โดย Microsoft แล้ว ยังมีมอดูลและสคริปต์ของ PowerShell ที่เผยแพร่อย่างอิสระ (โดยปกติบน GitHub) โดยสมาชิกชุมชน คู่ค้า และผู้ประกอบอาชีพที่มีค่ามากที่สุดของ Microsoft (MVP)

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

มอดูลการจัดการ Power BI

มอดูลการจัดการ Power BI เป็นโมดูลค่าสะสมที่มีโมดูล Power BI เฉพาะสําหรับการดูแลระบบ, ความจุ, พื้นที่ทํางาน และอื่น ๆ คุณสามารถเลือกที่จะติดตั้งโมดูลค่าสะสมเพื่อรับโมดูลทั้งหมด หรือคุณสามารถติดตั้งโมดูลเฉพาะ โมดูลการจัดการ Power BI ทั้งหมดได้รับการสนับสนุนทั้งใน Windows PowerShell และ PowerShell Core

สำคัญ

เราขอแนะนําให้คุณยกเลิกการใช้ Windows PowerShell (ซึ่งไม่สามารถเรียกใช้ PowerShell Core) ได้ แต่ใช้หนึ่งในตัวแก้ไขโค้ดที่ทันสมัยที่สนับสนุน PowerShell Core Windows PowerShell ISE (สภาพแวดล้อมสคริปต์รวม) สามารถเรียกใช้ PowerShell เวอร์ชัน 5.1 เท่านั้น ซึ่งไม่ได้รับการอัปเดตอีกต่อไป Windows PowerShell ในขณะนี้ไม่ได้รับการสนับสนุน ดังนั้นเราขอแนะนําให้คุณใช้ PowerShell Core สําหรับงานการพัฒนาใหม่ทั้งหมด

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

โมดูลการจัดการ Cmdlet วัตถุประสงค์
โปรไฟล์ Connect-PowerBIServiceAccount รับรองความถูกต้องผู้ใช้ Power BI หรือบริการหลัก
ผู้ดูแลระบบ รับ-PowerBIActivityEvent ดูหรือแยกเหตุการณ์บันทึกกิจกรรม Power BI สําหรับผู้เช่า
พื้นที่ทำงาน รับ-PowerBIWorkspace รวบรวมรายการพื้นที่ทํางาน
รายงาน รับ-PowerBIReport รวบรวมรายการของรายงานสําหรับพื้นที่ทํางานหรือผู้เช่า
ข้อมูล รับ-PowerBIDataset รวบรวมรายการแบบจําลองความหมายสําหรับพื้นที่ทํางานหรือผู้เช่า
โปรไฟล์ Invoke-PowerBIRestMethod ส่งคําขอ REST API (คําสั่ง) cmdlet นี้เป็นตัวเลือกที่ดีเนื่องจากสามารถเรียกใช้ Power BI REST API ใด ๆ ได้ นอกจากนี้ยังเป็นตัวเลือกที่ดีเมื่อคุณต้องการใช้รูปแบบการรับรองความถูกต้องที่ง่ายขึ้นโดยใช้ Connect-PowerBIServiceAccount cmdlet และสามารถเรียกใช้ API ที่ไม่มี cmdlet ของ PowerShell ที่สอดคล้องกัน สําหรับข้อมูลเพิ่มเติม โปรดดู ข้อควรพิจารณาสําหรับการใช้ cmdlet ของ PowerShell ในภายหลังในส่วนนี้

เคล็ดลับ

มี cmdlet อื่นๆ ที่พร้อมใช้งานสําหรับการจัดการและการเผยแพร่เนื้อหา อย่างไรก็ตาม จุดมุ่งเน้นของบทความนี้คือการดึงข้อมูลการตรวจสอบ

คุณสามารถดาวน์โหลดมอดูลการจัดการ Power BI จาก แกลเลอรี PowerShell ได้ วิธีที่ง่ายที่สุดในการติดตั้งโมดูลคือการใช้ PowerShellGet

เราขอแนะนําให้คุณติดตั้งมอดูลค่าสะสมการจัดการ Power BI ด้วยวิธีนี้ cmdlet ทั้งหมดที่คุณอาจต้องการจะพร้อมใช้งาน อย่างน้อยคุณต้องมีโมดูลโปรไฟล์ (สําหรับการรับรองความถูกต้อง) และโมดูลเฉพาะใดๆ ที่ประกอบด้วย cmdlet ที่คุณต้องการใช้

ข้อควรระวัง

ตรวจสอบให้แน่ใจว่าคุณรักษาโมดูลให้เป็นปัจจุบันอยู่เสมอในทุกเซิร์ฟเวอร์ เครื่องผู้ใช้ และบริการบนระบบคลาวด์ (เช่น Azure Automation) ที่คุณใช้ PowerShell หากไม่ได้อัปเดตโมดูลเป็นประจํา ข้อผิดพลาดหรือปัญหาที่ไม่สามารถคาดเดาได้อาจเกิดขึ้น เครื่องมือบางอย่าง (เช่น รหัส Visual Studio) ช่วยให้คุณอัปเดตมอดูลอยู่เสมอ นอกจากนี้ โปรดทราบว่า PowerShellGet ไม่ได้ถอนการติดตั้งมอดูลเวอร์ชันเก่าโดยอัตโนมัติเมื่อคุณติดตั้งหรืออัปเดตเวอร์ชันที่ใหม่กว่า ซึ่งจะติดตั้งเวอร์ชันที่ใหม่กว่าควบคู่ไปกับเวอร์ชันเก่า เราขอแนะนําให้คุณ ตรวจสอบ เวอร์ชันที่ติดตั้งและถอนการติดตั้งเวอร์ชันที่เก่ากว่าเป็นระยะ ๆ

โมดูลเกตเวย์ข้อมูล

โมดูลเกตเวย์ข้อมูลประกอบด้วย cmdlet ที่ดึงข้อมูลจากเกตเวย์ข้อมูลภายในองค์กรและแหล่งข้อมูล โมดูลเกตเวย์ข้อมูลได้รับการสนับสนุนเฉพาะบน PowerShell Core เท่านั้น ไม่ได้รับการสนับสนุนบน Windows PowerShell

โมดูลเกตเวย์ข้อมูลไม่มี cmdlet ของผู้ดูแลระบบใด ๆ ซึ่งแตกต่างจากมอดูลการจัดการ Power BI (อธิบายไว้ก่อนหน้านี้) cmdlet จํานวนมาก (และ API ของเกตเวย์ที่สอดคล้องกัน) จําเป็นต้องให้ผู้ใช้มีสิทธิ์ผู้ดูแลระบบเกตเวย์

คำเตือน

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

นี่คือ cmdlet หลายตัวจากโมดูลเกตเวย์ข้อมูลที่คุณสามารถใช้เพื่อดึงข้อมูลการตรวจสอบ

Cmdlet วัตถุประสงค์
Connect-DataGatewayServiceAccount การรับรองความถูกต้องผู้ใช้ Power BI (โดยปกติแล้วจําเป็นต้องให้ผู้ใช้นั้นเป็นของบทบาทผู้ดูแลระบบเกตเวย์)
รับ-DataGatewayCluster รวบรวมรายการของคลัสเตอร์เกตเวย์
รับ-DataGatewayClusterDataSource รวบรวมรายการของแหล่งข้อมูลสําหรับคลัสเตอร์เกตเวย์
Get-DataGatewayInstaller ตรวจสอบว่าผู้ใช้รายใดที่ได้รับอนุญาตให้ติดตั้งและลงทะเบียนเกตเวย์ในองค์กร

คุณสามารถดาวน์โหลดมอดูลเกตเวย์ข้อมูลจาก แกลเลอรี PowerShell ได้

เทคนิคการใช้ PowerShell

คุณสามารถใช้ PowerShell ในหลายวิธีที่แตกต่างกัน การตัดสินใจที่คุณทํานั้นเป็นสิ่งสําคัญมาก

ตารางต่อไปนี้อธิบายเทคนิคที่แตกต่างกันสามเทคนิคสําหรับการใช้ PowerShell

เทคนิค คำอธิบาย: ตัวอย่าง
ใช้ cmdlet ของ PowerShell เพื่อลดความซับซ้อนของการรับรองความถูกต้อง และเรียกใช้ API โดยตรง วิธีการที่แนะนํา ด้วยเทคนิคนี้ จึงมีความสมดุลของความเรียบง่ายและความยืดหยุ่น cmdlet Invoke-PowerBIRestMethod พร้อมใช้งานจากมอดูลโปรไฟล์การจัดการ Power BI cmdlet นี้มักจะเรียกว่ามี ด ทหารสวิสเนื่องจากคุณสามารถใช้เพื่อเรียกใช้ Power BI REST API ใด ๆ ได้ ข้อดีของการใช้เทคนิคนี้คือ คุณสามารถลดความซับซ้อนของการรับรองความถูกต้อง จากนั้นเรียกใช้ Power BI REST API ใด ๆ เราขอแนะนําให้คุณใช้เทคนิคนี้ หลังจากรับรองความถูกต้องด้วย Connect-PowerBIServiceAccount cmdlet ให้ใช้ cmdlet Invoke-PowerBIRestMethod เพื่อดึงข้อมูลจาก API ที่คุณต้องการ (ตัวอย่างเช่น รับผู้ใช้ไปป์ไลน์เป็นผู้ดูแลระบบ)
ใช้ cmdlets จาก PowerShell มากที่สุดทั้งสําหรับการรับรองความถูกต้องและสําหรับการเรียกข้อมูล ด้วยเทคนิคนี้ PowerShell ถูกนํามาใช้อย่างกว้างขวาง PowerShell ถูกใช้เพื่อประสานงานการเรียกใช้สคริปต์ และมอดูล PowerShell จะถูกใช้เมื่อใดก็ตามที่เป็นไปได้สําหรับการเข้าถึงข้อมูล การดําเนินการนี้จะสร้างการขึ้นต่อกันที่มากขึ้นบน PowerShell จากหลายแง่มุม หลังจากรับรองความถูกต้องด้วย Connect-PowerBIServiceAccount cmdlet ให้ใช้ cmdlet (ตัวอย่างเช่น Get-PowerBIActivityEvent) เพื่อดึงข้อมูล
ใช้ PowerShell เท่านั้นเพื่อประสานงานการเรียกใช้กระบวนการ มอดูล PowerShell จะถูกใช้น้อยที่สุดเท่าที่เป็นไปได้ ด้วยเทคนิคนี้ มีการขึ้นต่อกันน้อยกว่าบน PowerShell เป็นเครื่องมือเนื่องจากการใช้งานหลักคือการเรียงลําดับการเรียกใช้ API ใช้มอดูล PowerShell ทั่วไปเพียงโมดูลเดียวเท่านั้นเพื่อเข้าถึง API (ไม่มีมอดูลใดจากมอดูลการจัดการ Power BI ที่ใช้อยู่) หลังจากรับรองความถูกต้องโดยใช้ ไลบรารี การรับรองความถูกต้องของ Microsoft (MSAL) เรียกใช้ API ที่คุณต้องการ (ตัวอย่างเช่น รับผู้ใช้ไปป์ไลน์เป็นผู้ดูแลระบบ) โดยใช้ cmdlet Invoke-RestMethod ทั่วไปเพื่อดึงข้อมูล

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

เคล็ดลับ

คุณสามารถใช้ cmdlet ของ PowerShell Invoke-ASCmd เพื่อสร้างและดําเนินการ สคริปต์ DAX, XMLA และ TMSL ได้ อย่างไรก็ตาม กรณีการใช้งานเหล่านี้อยู่นอกขอบเขตสําหรับบทความนี้ สําหรับข้อมูลเพิ่มเติมเกี่ยวกับคิวรีมุมมองการจัดการแบบไดนามิก (DMV) ดู การตรวจสอบระดับข้อมูล

ผู้ใช้ทางเทคนิค (และผู้ดูแลระบบ) สามารถใช้โมดูลการจัดการ Power BI เพื่อดึงข้อมูลหรือทําให้บางแง่มุมของการจัดการเนื้อหาเป็นแบบอัตโนมัติ

  • สําหรับของผู้ดูแลระบบ : ตั้งค่าพารามิเตอร์ -Scope เป็น Organization เพื่อเข้าถึงเอนทิตีทั่วทั้งผู้เช่า (ตัวอย่างเช่น เพื่อเรียกดูรายการของ พื้นที่ทํางานทั้งหมด)
  • สําหรับผู้ใช้ทางเทคนิค: ตั้งค่าพารามิเตอร์ -Scope เป็น Individual (หรือไม่ใช้พารามิเตอร์) เพื่อเข้าถึงเอนทิตีที่เป็นของผู้ใช้ (ตัวอย่างเช่น เพื่อเรียกดูรายการของพื้นที่ทํางาน ที่ผู้ใช้มีสิทธิ์ในการเข้าถึง)

พิจารณาสถานการณ์ที่คุณจําเป็นต้องรับรายการของแบบจําลองความหมาย ถ้าคุณเลือกที่จะทํางานกับ API โดยตรง คุณต้องระบุ API ที่จะเรียกใช้ อย่างไรก็ตาม ถ้าคุณเลือกที่จะใช้ cmdlet รับ-PowerBIDataset คุณสามารถตั้งค่า -Scope พารามิเตอร์เพื่อดึงรายการแบบจําลองความหมายเฉพาะผู้ใช้หรือผู้เช่า ตัวเลือกของคุณจะขึ้นอยู่กับการตัดสินใจของคุณเกี่ยวกับวิธีการใช้ PowerShell (ครอบคลุมในตารางก่อนหน้า)

ตารางต่อไปนี้อธิบายวิธีการที่พารามิเตอร์ที่ใช้ใน cmdlet ของ PowerShell แปลเป็นการเรียก API PowerShell

พารามิเตอร์ Cmdlet API ที่ cmdlet ใช้ ชนิดของ API Scope รายการที่เรียกใช้
-DatasetID {DatasetID}
-Scope Individual		 รับชุดข้อมูล User พื้นที่ทํางานส่วนบุคคล แบบจําลองความหมายหนึ่งแบบ
-Scope Individual รับชุดข้อมูล User พื้นที่ทํางานส่วนบุคคล แบบจําลองความหมายทั้งหมด
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 รับชุดข้อมูลในกลุ่ม User หนึ่งพื้นที่ทํางาน แบบจําลองความหมายหนึ่งรายการ หากผู้ใช้ที่ลงชื่อเข้าใช้มีสิทธิ์ในการอ่านแบบจําลองความหมาย
-GroupID {WorkspaceID} รับชุดข้อมูลในกลุ่ม User หนึ่งพื้นที่ทํางาน แบบจําลองความหมายทั้งหมด หากผู้ใช้ที่ลงชื่อเข้าใช้มีสิทธิ์ในการเข้าถึงพื้นที่ทํางานและอ่านแบบจําลองความหมาย
-GroupID {WorkspaceID}
-Scope Organization		 รับชุดข้อมูลในกลุ่มในฐานะผู้ดูแลระบบ ผู้ดูแลระบบ หนึ่งพื้นที่ทํางาน แบบจําลองความหมายทั้งหมด
-Scope Organization รับชุดข้อมูลเป็นผู้ดูแลระบบ ผู้ดูแลระบบ ผู้เช่าทั้งหมด แบบจําลองความหมายทั้งหมด
ข้อควรพิจารณาสําหรับการใช้ cmdlet ของ PowerShell

cmdlet ของ PowerShell ของ Power BI นั้นใช้งานได้ง่ายกว่า เนื่องจากเป็นนามธรรมต่อความซับซ้อนบางอย่างของการเรียกใช้ REST API

ต่อไปนี้เป็นวิธีการบางอย่างที่ทําให้ cmdlet ง่ายต่อการเข้าถึงข้อมูลการตรวจสอบ

  • การรับรองความถูกต้อง: วิธีที่ง่ายที่สุดในการรับรองความถูกต้องในสคริปต์ PowerShell คือการใช้ cmdlet ของ Connect-PowerBIServiceAccount
  • ความเรียบง่าย: การเริ่มต้นทําได้ง่ายกว่าเพราะเทคนิคการดึงข้อมูลการตรวจสอบนั้นตรงไปตรงมา พิจารณาว่าเมื่อคุณใช้ Get-PowerBIActivityEvent cmdlet คุณจะดึงข้อมูลการตรวจสอบหนึ่งวัน อย่างไรก็ตาม เมื่อคุณเรียกใช้ GET Activity Events REST API โดยตรง คุณจะดึงข้อมูลการตรวจสอบหนึ่งชั่วโมง ดังนั้นเมื่อคุณใช้ REST API เพื่อดึงข้อมูลการตรวจสอบหนึ่งวัน คุณต้องใช้การวนรอบเพื่อเรียกใช้ API 24 ครั้งเพื่อแยกแต่ละชั่วโมงของวัน
  • การแบ่งหน้าของชุดผลลัพธ์ขนาดใหญ่: ชุดผลลัพธ์ขนาดใหญ่จะถูกเรียกใช้อย่างมีประสิทธิภาพการแบ่งหน้า การแบ่งหน้าเกี่ยวข้องกับการดึงข้อมูลหนึ่งกลุ่มของผลลัพธ์ในแต่ละครั้ง cmdlet จะจัดการการแบ่งหน้าให้คุณโดยอัตโนมัติ อย่างไรก็ตาม เมื่อคุณใช้ REST API โดยตรง สคริปต์ของคุณต้องตรวจสอบโทเค็นต่อเนื่องเพื่อตรวจสอบว่ามีผลลัพธ์ใด ๆ เพิ่มเติมให้มาหรือไม่ สคริปต์ควรทําการเรียกข้อมูลกลุ่มของผลลัพธ์ต่อไปจนกว่าจะไม่ได้รับโทเค็นความต่อเนื่อง สําหรับตัวอย่างของการใช้โทเค็นต่อเนื่อง ดูกิจกรรมกิจกรรม REST API
  • Access token หมดอายุ: หลังจากการรับรองความถูกต้อง โทเค็นการเข้าถึงจะถูกส่งกลับ ตามค่าเริ่มต้น การดําเนินการนี้จะหมดอายุหลังจากหนึ่งชั่วโมง cmdlets จัดการการหมดอายุของโทเค็นการเข้าถึงสําหรับคุณ ด้วยวิธีนี้ คุณไม่จําเป็นต้องเขียนตรรกะเพื่อร้องขอโทเค็นการรีเฟรช
  • จัดรูปแบบ: ข้อมูลที่ส่งกลับโดย cmdlet มีการจัดรูปแบบที่ดีกว่าข้อมูลที่ REST API ส่งกลับเล็กน้อย เอาต์พุตใช้งานได้ง่ายยิ่งขึ้น สําหรับกระบวนการตรวจสอบอัตโนมัติ นั่นไม่น่าจะเป็นปัญหา อย่างไรก็ตาม สําหรับกระบวนการตรวจสอบด้วยตนเอง การจัดรูปแบบที่ดีกว่าอาจเป็นประโยชน์
ข้อควรพิจารณาสําหรับการใช้ REST API โดยตรง

ในบางครั้งมีข้อดีของการเรียก Power BI REST API โดยตรง

  • มี API ที่พร้อมใช้งานอีกมากมาย: มี REST API ที่พร้อมใช้งานมากกว่า cmdlet ของ PowerShell อย่างไรก็ตาม อย่ามองข้ามความยืดหยุ่นของ cmdlet Invoke-PowerBIRestMethod ซึ่งคุณสามารถใช้เพื่อเรียกใช้ Power BI REST API ใด ๆ ได้
  • ความถี่ ของการอัปเดต: Microsoft อัปเดต REST API บ่อยมากกว่าการอัปเดตมอดูล PowerShell ตัวอย่างเช่น ถ้ามีการเพิ่มแอตทริบิวต์ใหม่ในการตอบสนองรับชุดข้อมูล API อาจใช้เวลาสักครู่ก่อนที่แอตทริบิวต์จะพร้อมใช้งานในผลลัพธ์ของ cmdlet รับ PowerBIDataset
  • การอ้างอิงภาษา/เครื่องมือน้อยกว่า : เมื่อคุณใช้ REST API โดยตรง (แทน cmdlet) คุณไม่จําเป็นต้องใช้ PowerShell หรือคุณอาจเลือกใช้ PowerShell เฉพาะเพื่อเรียงลําดับการเรียก API จํานวนมากในสคริปต์ ด้วยการลบ (หรือหลีกเลี่ยง) การขึ้นต่อกันใด ๆ บน PowerShell ในอนาคต คุณสามารถเขียนตรรกะของคุณในภาษาอื่นได้อีกครั้ง เมื่อทีมไอทีหรือนักพัฒนาของคุณมีการกําหนดลักษณะที่แข็งแกร่งสําหรับเครื่องมือและภาษา การขึ้นต่อกันน้อยกว่าอาจเป็นการพิจารณาที่สําคัญที่ต้องคํานึงถึง

ไม่ว่าคุณจะเลือกใช้วิธีใด REST API สามารถเปลี่ยนแปลงได้เมื่อเวลาผ่านไป เมื่อเทคโนโลยีพัฒนาขึ้น API (และโมดูล PowerShell) จะสามารถถูกยกเลิกและแทนที่ได้ ดังนั้น เราขอแนะนําให้คุณสร้างสคริปต์ที่ง่ายต่อการรักษาและยืดหยุ่นในการเปลี่ยนแปลง

รายการ ตรวจสอบ - เมื่อเลือกว่าจะเข้าถึง REST API โดยตรงหรือโดยใช้ cmdlet ของ PowerShell การตัดสินใจและการดําเนินการหลักรวมถึง:

  • ปรึกษากับฝ่าย IT เกี่ยวกับการใช้PowerShell : ติดต่อทีมไอทีที่เกี่ยวข้องเพื่อตรวจสอบว่ามีข้อกําหนดหรือการตั้งค่าภายในที่มีอยู่เกี่ยวกับวิธีการใช้ PowerShell หรือไม่
  • ตัดสินใจว่าคุณต้องการใช้ PowerShellอย่างไร : พิจารณาว่าเทคนิคใดของ PowerShell ที่จะใช้ และคุณต้องการเพิ่มหรือลดการขึ้นต่อกันของคุณบน PowerShell หรือไม่ พิจารณาว่าการสื่อสารภายในหรือการฝึกอบรมเป็นสิ่งจําเป็นหรือไม่
  • อัปเกรดเป็นPowerShell Core : การวิจัยโดยใช้ PowerShell Core กําหนดว่าจําเป็นต้องอัปเดตเครื่องของผู้ดูแลระบบหรือไม่ พิจารณาว่าสคริปต์ใดที่ต้องได้รับการทดสอบ พิจารณาว่าผู้ดูแลระบบหรือนักพัฒนาต้องการการฝึกอบรมเพิ่มเติมเพื่ออัปเกรดทักษะของพวกเขาหรือไม่
  • พิจารณาว่าจะใช้โมดูล PowerShell ใดใน: พิจารณาว่าจะใช้โมดูลการจัดการ Power BI และ/หรือมอดูลเกตเวย์ข้อมูล
  • ตัดสินใจว่าโครงการชุมชนได้รับอนุญาตหรือไม่ : พิจารณาว่าคุณได้รับอนุญาต (หรือได้รับการสนับสนุน) เพื่อใช้มอดูล PowerShell พร้อมใช้งานแบบออนไลน์ได้ (เทียบกับมอดูลที่เผยแพร่โดย Microsoft) หรือไม่ ปรึกษากับฝ่ายไอทีเพื่อดูว่ามีเกณฑ์สําหรับโครงการชุมชนที่ได้รับออนไลน์หรือไม่
  • ชี้แจงวิธีการสนับสนุนโครงการชุมชน: ถ้าโครงการชุมชน PowerShell ได้รับอนุญาตให้พิจารณาว่าใครเป็นผู้รับผิดชอบในการสนับสนุนโครงการดังกล่าวเมื่อมีการใช้ภายใน
  • การพิสูจน์แนวคิด (POC) ขนาดเล็กเสร็จสิ้น: ทดลองใช้ POC ทางเทคนิค ยืนยันเครื่องมือไคลเอ็นต์และวิธีการเข้าถึงข้อมูลที่คุณต้องการ
  • กําหนดวิธีการสนับสนุนผู้ใช้ขั้นสูง: พิจารณาวิธีการที่คุณจะสนับสนุนผู้ใช้ทางเทคนิคที่สร้างระบบอัตโนมัติด้วยตนเองโดยใช้ API ของผู้ใช้

กําหนดตําแหน่งที่จะจัดเก็บข้อมูลการตรวจสอบ

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

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

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

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

นี่คือตัวเลือกบางอย่างสําหรับการจัดเก็บข้อมูลดิบ

  • Data lake หรือเก็บข้อมูลวัตถุ : บริการระบบคลาวด์ เช่น OneLake ที่เชี่ยวชาญในการจัดเก็บไฟล์ของโครงสร้างต่าง ๆ ซึ่งเป็นตัวเลือกที่เหมาะสําหรับการจัดเก็บข้อมูลการตรวจสอบดิบ ในสถาปัตยกรรมที่จัดเก็บข้อมูลดิบข้อมูลควรเก็บไว้ในชั้นทองแดง
  • ไฟล์ระบบ: ระบบไฟล์ (เช่น Windows หรือ Linux) เป็นตัวเลือกทั่วไปสําหรับการจัดเก็บข้อมูลการตรวจสอบดิบ
  • ฐานข้อมูล: คุณสามารถจัดเก็บข้อมูล JSON ในฐานข้อมูลเชิงสัมพันธ์ เช่น ฐานข้อมูล Azure SQL อย่างไรก็ตาม เป็นเรื่องปกติน้อยกว่าการจัดเก็บข้อมูลใน data lake หรือระบบไฟล์ นั่นเป็นเพราะว่าการคิวรีและการรักษาข้อมูล JSON อาจเป็นเรื่องยากและมีราคาแพง โดยเฉพาะอย่างยิ่งเมื่อปริมาณข้อมูลเพิ่มขึ้น

เคล็ดลับ

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

พิจารณาตัวอย่างที่เกี่ยวข้องกับโซนข้อมูลดิบของที่จัดเก็บข้อมูลดิบ โซนมีลําดับชั้นของโฟลเดอร์สําหรับการจัดเก็บข้อมูลบันทึกกิจกรรม: Raw > ActivityLog > YYYY > MM โฟลเดอร์มีการแบ่งพาร์ติชันตามปีและเดือน ไฟล์ที่จัดเก็บไว้ในโฟลเดอร์เดือนจะใช้รูปแบบต่อไปนี้: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json YYYYMMDD แสดงถึงข้อมูลจริง และ YYYYMMDDTTTT แสดงถึงประทับเวลาการแยก เมื่อรวมสแตมป์เวลาการแยกคุณสามารถกําหนดว่าไฟล์ใดเป็นไฟล์ล่าสุด (ในกรณีที่คุณต้องดึงข้อมูลอีกครั้ง) ตัวอย่างเช่น ถ้าคุณแยกข้อมูลเวลา 9.00 น. (UTC) ในวันที่ 25 เมษายน 2023 สําหรับกิจกรรมในวันที่ 23 เมษายน 2023 ชื่อไฟล์จะเป็น PBIActivityLog-20230523-202305250900

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

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

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

  • เป็นกระบวนการตรวจสอบด้วยตนเองหรืออัตโนมัติ? โดยทั่วไปกระบวนการตรวจสอบอัตโนมัติมีข้อกําหนดที่เข้มงวดสําหรับวิธีการและตําแหน่งที่เก็บข้อมูล
  • ขอบเขตเนื้อหามีความอ่อนไหวเป็นพิเศษหรือไม่ องค์กรของคุณอาจมีข้อกําหนดสําหรับวิธีการและตําแหน่งที่จัดเก็บ ทั้งนี้ขึ้นอยู่กับชนิดของข้อมูลและความละเอียดอ่อน ข้อมูลการตรวจสอบ Power BI ประกอบด้วยการระบุข้อมูลผู้ใช้และที่อยู่ IP ดังนั้นจึงควรจัดเก็บไว้ในพื้นที่ปลอดภัย
  • มีเทคโนโลยีการจัดเก็บข้อมูลที่ต้องการหรือไม่ อาจมีเทคโนโลยีการจัดเก็บข้อมูลที่มีอยู่ที่ใช้งานอยู่ภายในองค์กร ดังนั้นจึงเป็นตัวเลือกเชิงตรรกะ
  • ผู้ใช้จะเข้าถึงที่เก็บข้อมูลโดยตรงหรือไม่? แบบจําลองความปลอดภัยเป็นข้อควรพิจารณาที่สําคัญ โดยปกติแล้ว ผู้ใช้น้อยมากที่ได้รับอนุญาตให้เข้าถึงข้อมูลดิบ การเข้าถึงข้อมูลที่รวบรวมโดยทั่วไปแล้วจะพร้อมใช้งานสําหรับผู้สร้างเนื้อหา Power BI ที่รับผิดชอบในการสร้างแบบจําลองข้อมูลส่วนกลาง (แบบจําลองความหมายที่ทําหน้าที่เป็นเลเยอร์สําหรับการรายงาน)
  • คุณมีข้อกําหนดที่อยู่ข้อมูลหรือไม่? บางองค์กรมีข้อกําหนดการเก็บข้อมูลทางกฎหมายหรือข้อบังคับเพื่อจัดเก็บข้อมูลในขอบเขตข้อมูลเฉพาะ
  • ข้อมูลจะถูกจัดระเบียบอย่างไร การใช้ สถาปัตยกรรม เหรียญเป็นแนวทางปฏิบัติทั่วไปโดยเฉพาะอย่างยิ่งในการใช้งานที่จัดเก็บข้อมูลทะเลสาบและทะเลสาบ เป้าหมายคือการจัดเก็บข้อมูลของคุณในเลเยอร์ข้อมูลสีบรอนซ์สีเงินและทอง ชั้นทองแดงประกอบด้วยข้อมูลดิบเดิม เลเยอร์เงินประกอบด้วยข้อมูลที่ผ่านการตรวจสอบและทําซ้ําที่ใช้สําหรับการแปลง เลเยอร์ทองประกอบด้วยข้อมูลที่รวบรวมและปรับแต่งสูงซึ่งพร้อมสําหรับการวิเคราะห์

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

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

วางแผนเพื่อสร้างข้อมูลที่รวบรวมไว้

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

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

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

ที่จัดเก็บข้อมูลดิบ

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

ใช้ data lake เพื่อแปลงและดูแลรักษาข้อมูลเมื่อ:

  • คุณคาดหวังว่าจะมีแบบจําลองข้อมูล Power BI หลายตัวที่ให้บริการการรายงาน (ซึ่งเพียงแค่การสร้างเลเยอร์เงินกลาง)
  • คุณจําเป็นต้องสนับสนุนผู้สร้างเนื้อหาแบบบริการตนเองหลายรายที่ต้องการเข้าถึงข้อมูลการตรวจสอบระดับผู้เช่า
  • คุณมีเครื่องมือและกระบวนการอยู่แล้วที่คุณต้องการใช้ในการแปลงและโหลดข้อมูล
  • คุณต้องการลดการเตรียมข้อมูลที่ต้องทํา (และอาจทําซ้ํา) ภายในแบบจําลองข้อมูล Power BI อย่างน้อยหนึ่งรายการ
แบบจําลองข้อมูล Power BI

คุณอาจสามารถดําเนินการแปลงทั้งหมดใน Power BI ได้ ใช้ Power Query เพื่อเข้าถึงและแปลงข้อมูลจากสถานะดิบเป็นรูปแบบที่รวบรวมไว้

ใช้แบบจําลองข้อมูล Power BI เมื่อ:

  • คุณต้องการลดความซับซ้อนของสถาปัตยกรรมแบบ end-to-end และโหลดแบบจําลองข้อมูลโดยตรงจากข้อมูลดิบ (การรีเฟรช แบบเพิ่มทีละส่วนสามารถช่วยลดระยะเวลาการรีเฟรชได้)
  • การกําหนดลักษณะของคุณคือการทํางานการแปลงทั้งหมดในขณะที่โหลดแบบจําลองข้อมูล
  • คุณคาดว่าจะมีหนึ่งแบบจําลองข้อมูลส่วนกลางสําหรับข้อมูลการตรวจสอบระดับผู้เช่า รายงานทั้งหมด (หรือแบบจําลองข้อมูลอื่นๆ) สามารถใช้แบบจําลองความหมายของ Power BI แบบรวมศูนย์เป็นแหล่งข้อมูล
  • คุณต้องการให้ผู้ใช้เข้าถึงเฉพาะแบบจําลองความหมาย Power BI แบบรวมศูนย์เท่านั้น (และไม่ใช่กับแหล่งข้อมูลใด ๆ)

เคล็ดลับ

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

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

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

  • ตัดสินใจว่าควรทําการแปลงข้อมูลอย่างไร: พิจารณาว่าควรดําเนินการแปลงข้อมูลในขั้นตอนใดและควรดําเนินการให้เหมาะสมกับแผนของคุณสําหรับสถาปัตยกรรมทั้งหมดเพียงใด
  • ตัดสินใจว่าจะใช้เครื่องมือใดในการแปลงข้อมูลเป็นSchema รูปดาว: ยืนยันว่าเครื่องมือและบริการใดที่จะใช้สําหรับการแปลงข้อมูลดิบเป็นข้อมูลที่มีการรวบรวม
  • ตัดสินใจว่าควรจัดเก็บข้อมูลที่รวบรวมไว้ที่ใด: กําหนดตัวเลือกที่ดีที่สุดสําหรับการจัดเก็บข้อมูลดิบที่มีการแปลงเป็นรูปแบบ Schema รูปดาว ตัดสินใจว่าเลเยอร์เงินระดับกลางมีประโยชน์ในสถาปัตยกรรมแบบ end-to-end หรือไม่
  • สร้างแบบแผนการตั้งชื่อ : กําหนดข้อกําหนดการตั้งชื่อที่จะใช้สําหรับไฟล์และโฟลเดอร์ของข้อมูลที่รวบรวมไว้แล้ว (ถ้ามี) ใส่รายละเอียดลงในเอกสารทางเทคนิคของคุณ
  • พิจารณาว่าความปลอดภัยสําหรับข้อมูลที่รวบรวมจะทํางานอย่างไร: ในขณะที่ออกแบบตําแหน่งที่เก็บข้อมูลที่รวบรวม ให้พิจารณาว่าใครจะต้องเข้าถึงข้อมูลและวิธีกําหนดความปลอดภัย

การตัดสินใจของแหล่งข้อมูล

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

เข้าถึงข้อมูลกิจกรรมของผู้ใช้

ข้อมูลกิจกรรมของผู้ใช้ Power BI ซึ่งในบางครั้งเรียกว่า บันทึก กิจกรรมหรือ บันทึกการตรวจสอบจะมีข้อมูลจํานวนมากเพื่อช่วยให้คุณเข้าใจสิ่งที่เกิดขึ้นในผู้เช่า Power BI ของคุณ สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการระบุความต้องการในข้อมูลของคุณ โปรดดู ข้อมูล กิจกรรมของผู้ใช้ ก่อนหน้าในบทความนี้

Power BI รวมบันทึกกับบันทึกการตรวจสอบแบบรวมของ Microsoft Purview (เดิมเรียกว่าบันทึกการตรวจสอบแบบรวมของ Microsoft 365) การรวมนี้เป็นข้อได้เปรียบเพราะหมายความว่าทุกบริการภายใน Microsoft 365 ไม่จําเป็นต้องใช้วิธีการบันทึกที่เป็นเอกลักษณ์ของตัวเอง ซึ่งเปิดใช้งานไว้แล้วตามค่าเริ่มต้น

สำคัญ

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

คุณมีหลายตัวเลือกในการดึงข้อมูลกิจกรรมของผู้ใช้

เทคนิค คำอธิบาย: วันเริ่มต้นของประวัติที่พร้อมใช้งาน ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ ตัวเลือกที่ดีในการตั้งค่าการแจ้งเตือน ตัวเลือกที่ดีเพื่อเริ่มต้นใช้งานได้อย่างรวดเร็ว
ด้วยตนเอง (ส่วนติดต่อผู้ใช้) พอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview 90 พอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง พอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview เป็นตัวเลือกที่ดีในการเริ่มต้นใช้งานได้อย่างรวดเร็ว
ด้วยตนเอง (ส่วนติดต่อผู้ใช้) Defender สำหรับแอประบบคลาวด์ 30 Defender สําหรับ Cloud Apps เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง Defender สําหรับ Cloud Apps เป็นตัวเลือกที่ดีในการตั้งค่าการแจ้งเตือน
การเขียนโปรแกรม บันทึกกิจกรรม Power BI (API หรือ PowerShell cmdlet) 30 บันทึกกิจกรรม Power BI (API หรือ PowerShell cmdlet) เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ บันทึกกิจกรรม Power BI (API หรือ PowerShell cmdlet) เป็นตัวเลือกที่ดีในการเริ่มต้นใช้งานอย่างรวดเร็ว
การเขียนโปรแกรม Office 365 Management Activity API 7 Office 365 Management Activity API เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
การเขียนโปรแกรม Microsoft Sentinel (Azure Monitor) 30 Microsoft Sentinel (Azure Monitor) เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ Microsoft Sentinel (Azure Monitor) เป็นตัวเลือกที่ดีในการตั้งค่าการแจ้งเตือน

ส่วนที่เหลือของส่วนนี้จะแนะนําเทคนิคแต่ละเทคนิคที่แสดงในตาราง

พอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview

เครื่องมือค้นหาการตรวจสอบในพอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview (เดิมเรียกว่า ศูนย์การปฏิบัติตามข้อบังคับ Microsoft 365) เป็นสถานที่ที่สะดวกในการดูกิจกรรมและการแจ้งเตือน เครื่องมือนี้ไม่จําเป็นต้องให้คุณสร้างสคริปต์เพื่อแยกและดาวน์โหลดข้อมูล คุณสามารถเลือกปริมาณงาน Power BI เพื่อดูบันทึกการตรวจสอบทั้งหมดในช่วงระยะเวลาหนึ่งได้ คุณยังสามารถจํากัดผลลัพธ์ให้แคบลงโดยการเลือกกิจกรรมและผู้ใช้ที่เฉพาะเจาะจง ตัวอย่างเช่น ผู้จัดการขอให้คุณค้นหาว่าใครลบพื้นที่ทํางานวันนั้นเพื่อให้พวกเขาสามารถติดต่อบุคคลเพื่อพูดคุยเกี่ยวกับสถานการณ์ดังกล่าวได้อย่างรวดเร็ว

ประวัติใน 90 วันล่าสุดนั้นมีพร้อมสําหรับการตรวจสอบ (มาตรฐาน) ด้วยการตรวจสอบ (Premium) การเก็บรักษาระยะยาวช่วยให้คุณสามารถ (ไม่บังคับ) เก็บบันทึกการตรวจสอบไว้นานกว่า เนื่องจากการเก็บข้อมูลระยะยาวมีผลเฉพาะกับ ผู้ใช้ E5 ที่ได้รับอนุญาตเท่านั้น จึงไม่รวมบันทึกการตรวจสอบสําหรับผู้ใช้ที่ไม่ใช่ E5 และผู้ใช้ที่เป็นผู้เยี่ยมชม ดังนั้น เราขอแนะนําให้คุณพึ่งพาประวัติ 90 วันตามค่าเริ่มต้นเท่านั้นเพื่อให้แน่ใจว่าได้บันทึกกิจกรรมทั้งหมดแล้ว

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

เคล็ดลับ

ตามค่าเริ่มต้น ผู้ดูแลระบบ Power BI ไม่มีสิทธิ์ในการเข้าถึงการค้นหาบันทึกการตรวจสอบแบบรวมในพอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview เนื่องจากประกอบด้วยข้อมูลสําหรับบริการ Microsoft 365 จํานวนมาก จึงเป็นบทบาทสิทธิ์การใช้งานสูง ในองค์กรส่วนใหญ่ สิทธิ์เหล่านั้นจะถูกสงวนไว้สําหรับผู้ดูแลระบบ IT จํานวนน้อย มีตัวเลือกอื่น ๆ สําหรับผู้ดูแลระบบ Power BI ซึ่งจะอธิบายในภายหลังในส่วนนี้

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

Defender สำหรับแอประบบคลาวด์

พอร์ทัลใน Defender for Cloud Apps คือสถานที่ที่สะดวกในการดูกิจกรรมและการแจ้งเตือนโดยไม่จําเป็นต้องสร้างสคริปต์เพื่อแยกและดาวน์โหลดข้อมูล นอกจากนี้ยังช่วยให้คุณสามารถดูข้อมูลจากบันทึกกิจกรรม Power BI และการลงชื่อเข้าใช้ของผู้ใช้

Defender สําหรับ Cloud Apps มีส่วนติดต่อผู้ใช้เพื่อดูและค้นหาบันทึกกิจกรรมสําหรับบริการคลาวด์ต่าง ๆ รวมถึง Power BI ซึ่งแสดงเหตุการณ์บันทึกเดียวกันกับที่มีต้นกําเนิดในบันทึกการตรวจสอบแบบรวมของ Microsoft Purview และรวมถึงเหตุการณ์อื่น ๆ เช่น กิจกรรมการลงชื่อเข้าใช้ของผู้ใช้จาก Microsoft Entra ID

เช่นเดียวกับพอร์ทัลการปฏิบัติตามข้อบังคับของ Microsoft Purview (อธิบายไว้ในส่วนก่อนหน้า) Defender for Cloud Apps มีส่วนติดต่อผู้ใช้ที่สามารถค้นหาได้ อย่างไรก็ตาม ตัวเลือกตัวกรองจะแตกต่างกัน นอกจากประวัติ 30 วันมาตรฐานแล้ว คุณสามารถใช้ Defender สําหรับ Cloud Apps เพื่อดูประวัติบันทึกกิจกรรมได้ถึงหกเดือน (โดยเพิ่มทีละเจ็ดวัน) ได้

มี ข้อกําหนด สิทธิ์การใช้งานเพื่อเข้าถึง Defender สําหรับ Cloud Apps นอกจากนี้ ยังจําเป็นต้องมีสิทธิ์แยกต่างหาก

เคล็ดลับ

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

ส่วนติดต่อผู้ใช้ใน Defender สําหรับ Cloud Apps มีประโยชน์สําหรับกระบวนการตรวจสอบด้วยตนเองและการตรวจสอบกิจกรรมของผู้ใช้เพียงครั้งเดียว

บันทึกกิจกรรม Power BI

บันทึกกิจกรรม Power BI มาจากบันทึกการตรวจสอบแบบรวม ซึ่งประกอบด้วยกิจกรรมของผู้ใช้ที่เกี่ยวข้องกับบริการของ Power BI เท่านั้น

เคล็ดลับ

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

คุณมีสองตัวเลือกในการเข้าถึงบันทึกกิจกรรม Power BI

สําหรับข้อมูลเกี่ยวกับตัวเลือกที่จะใช้ ดู เลือก API หรือ cmdlet ของ PowerShell ก่อนหน้าในบทความนี้

เคล็ดลับ

สําหรับตัวอย่างของวิธีการเข้าถึงบันทึกกิจกรรม Power BI ด้วย PowerShell ให้ดู เข้าถึงบันทึกกิจกรรม Power BI

ข้อมูลบันทึกกิจกรรมของ Power BI พร้อมใช้งานสําหรับผู้ดูแลระบบ Fabric และผู้ดูแลระบบ Power Platform ทั้งหมด ข้อมูลสามารถเข้าถึงได้จากบันทึกการตรวจสอบแบบรวม ที่พร้อมใช้งานสําหรับบทบาทบางอย่างของ Exchange Online สําหรับข้อมูลเพิ่มเติม ดู ติดตามกิจกรรมของผู้ใช้ใน Power BI

เราขอแนะนําให้คุณใช้บันทึกกิจกรรม Power BI เมื่อความตั้งใจของคุณคือการดึงข้อมูลบันทึกการตรวจสอบ Power BI เท่านั้น

หมายเหตุ

ในข้อมูลบันทึกการตรวจสอบ พื้นที่ทํางานจะเรียกว่าโฟลเดอร์ ใน Power BI REST API พื้นที่ทํางานจะเรียกว่ากลุ่ม

Office 365 Management Activity API

คุณสามารถแยกข้อมูลจากบันทึกการตรวจสอบแบบรวมสําหรับบริการอื่น ๆ เช่น SharePoint Online, Teams, Exchange Online, Dynamics 365 และ Power BI เมื่อเป้าหมายของคุณคือการใช้การตรวจสอบและตรวจสอบโซลูชันสําหรับบริการหลายอย่าง เราขอแนะนําให้คุณใช้ Office 365 Management Activity API เนื่องจาก API นี้จะส่งกลับข้อมูลจากบริการจํานวนมาก ซึ่งเรียกว่า API การตรวจสอบแบบรวม (หรือ บันทึกการตรวจสอบแบบรวม) ซึ่งเป็นหนึ่งใน API การจัดการ Office 365

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

คุณสามารถเข้าถึงข้อมูลหนึ่งในสองวิธี

สำคัญ

Search-UnifiedAuditLog cmdlet ไม่ได้ปรับมาตราส่วนได้ดีและจําเป็นต้องใช้กลยุทธ์การวนรอบเพื่อเอาชนะขีดจํากัด 5,000 แถว ด้วยเหตุผลเหล่านี้ จึงเหมาะสมกับคิวรีเป็นครั้งคราว หรือสําหรับองค์กรขนาดเล็กที่ประสบกับกิจกรรมต่ํา เมื่อคุณจําเป็นต้องใช้ข้อมูล Power BI เท่านั้น เราขอแนะนําให้คุณใช้ Get-PowerBIActivityEvent cmdlet แทน

โดยทั่วไป การเริ่มต้นใช้งาน Office 365 Management Activity API นั้นท้าทายกว่าการใช้บันทึกกิจกรรม Power BI (อธิบายไว้ก่อนหน้านี้) นั่นเป็นเพราะ API ส่งกลับ blobs ของเนื้อหา และแต่ละ blob ของเนื้อหาประกอบด้วยระเบียนการตรวจสอบแต่ละรายการ สําหรับองค์กรขนาดใหญ่ อาจมีจํานวนมากของ blobs เนื้อหาต่อวัน เนื่องจากลูกค้าและแอปพลิเคชันของบุคคลที่สามใช้ API นี้อย่างมาก Microsoft จึงใช้การควบคุมเพื่อให้แน่ใจว่าการใช้บริการของพวกเขาจะไม่ส่งผลกระทบเชิงลบต่อผู้อื่น (เรียกว่า ปัญหา Noisy Neighbor ) ดังนั้นการเรียกคืนข้อมูลประวัติจํานวนมากจึงเป็นความท้าทายในองค์กรขนาดใหญ่ สําหรับข้อมูลเพิ่มเติม โปรดดูบทความการแก้ไขปัญหานี้

หากต้องการใช้ API นี้ คุณต้องรับรองความถูกต้องกับโครงร่างสําคัญของบริการที่ได้รับสิทธิ์ในการดึงข้อมูลจาก API กิจกรรมการจัดการของ Office 365

เคล็ดลับ

ตามค่าเริ่มต้น ผู้ดูแลระบบ Power BI ไม่มีสิทธิ์ในการเข้าถึง Office 365 Management Activity API เนื่องจากประกอบด้วยข้อมูลสําหรับบริการ Microsoft 365 จํานวนมาก การเข้าถึงจําเป็นต้องมีผู้ดูแลระบบสิทธิ์สูงหรือบทบาทการตรวจสอบ ในองค์กรส่วนใหญ่ บทบาทเหล่านี้จะถูกสงวนไว้สําหรับผู้ดูแลระบบ IT จํานวนน้อย บันทึกกิจกรรม Power BI มีไว้สําหรับผู้ดูแลระบบ Power BI

การดึงข้อมูลการตรวจสอบทางโปรแกรมจาก Office 365 Management Activity API เป็นตัวเลือกที่ดีเมื่อ IT ต้องแยกและจัดเก็บบันทึกการตรวจสอบจากบริการต่าง ๆ (นอกเหนือจาก Power BI)

Microsoft Sentinel

Microsoft Sentinel เป็นบริการ Azure ที่ช่วยให้คุณสามารถรวบรวม ตรวจจับ ตรวจสอบ และตอบสนองต่อเหตุการณ์และภัยคุกคามด้านความปลอดภัยได้ คุณสามารถตั้งค่า Power BI ใน Microsoft Sentinel ในฐานะตัว เชื่อมต่อข้อมูลได้ เมื่อเชื่อมต่อแล้ว บันทึกการตรวจสอบ (ที่มีชุดย่อยของข้อมูล) จะสตรีมจาก Power BI ลงใน Azure Log Analytics ซึ่งเป็นความสามารถของ Azure Monitor

เคล็ดลับ

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

เนื่องจากเป็นบริการ Azure แยกต่างหาก ผู้ดูแลระบบหรือผู้ใช้ใด ๆ ที่คุณต้องการเรียกใช้ คิวรี Kusto Query Language (KQL) ต้องได้รับสิทธิ์ใน Azure Log Analytics (Azure Monitor) เมื่อพวกเขามีสิทธิ์ พวกเขาสามารถคิวรีข้อมูลการตรวจสอบที่จัดเก็บไว้ใน ตาราง PowerBIActivity ได้ อย่างไรก็ตาม โปรดทราบว่าในกรณีส่วนใหญ่คุณจะอนุญาตให้ผู้ใช้เข้าถึงข้อมูลที่รวบรวมไว้ในเลเยอร์ทองแทนที่จะเป็นข้อมูลดิบในชั้นทองแดง

คุณใช้ KQL เพื่อวิเคราะห์เหตุการณ์บันทึกกิจกรรมที่จัดเก็บไว้ใน Azure Log Analytics ถ้าคุณมีประสบการณ์ใน SQL คุณจะพบความคล้ายคลึงกันมากกับ KQL

มีหลายวิธีในการเข้าถึงเหตุการณ์ที่จัดเก็บไว้ใน Azure Log Analytics คุณสามารถใช้:

  • การวิเคราะห์บันทึกจัดทําสําเร็จ สําหรับแอปเทมเพลตแบบจําลอง ความหมาย Power BI
  • ตัวเชื่อมต่อ Power BI Desktop สําหรับ Azure Data Explorer (Kusto)
  • ประสบการณ์คิวรี บนเว็บใน Azure Data Explorer
  • เครื่องมือคิวรีใด ๆ ที่สามารถส่งคิวรี KQL ได้

ข้อควรระวัง

โปรดทราบว่าเฉพาะ ชุด ย่อยของข้อมูลบันทึกกิจกรรม Power BI เท่านั้นที่จัดเก็บไว้ใน Azure Monitor เมื่อคุณวางแผนที่จะทําการวิเคราะห์ที่ครอบคลุมของการใช้งานและการปรับใช้ Power BI ในองค์กร เราขอแนะนําให้คุณใช้ตัวเลือกอื่น ๆ (อธิบายไว้ก่อนหน้าในส่วนนี้) เพื่อดึงข้อมูลกิจกรรม

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

Microsoft Sentinel และ Azure Monitor เป็นตัวเลือกที่ดีเมื่อ IT ได้ทําการลงทุนกับ Microsoft Sentinel แล้ว ระดับของรายละเอียดที่จับได้ตรงกับความต้องการของคุณและกิจกรรมต่าง ๆ เช่น การตรวจหา ภัยคุกคามเป็นสิ่งที่มีความสําคัญ อย่างไรก็ตาม เนื่องจาก Microsoft Sentinel ไม่เก็บข้อมูลกิจกรรม Power BI ทั้งหมด จึงไม่รองรับการวิเคราะห์การใช้งานและการปรับใช้ Power BI ที่ครอบคลุม

ข้อควรพิจารณาเกี่ยวกับข้อมูลกิจกรรมของผู้ใช้

ต่อไปนี้คือข้อควรพิจารณาบางอย่างเพื่อช่วยให้คุณเลือกแหล่งข้อมูลสําหรับข้อมูลกิจกรรมของผู้ใช้

  • จะเป็นกระบวนการตรวจสอบด้วยตนเองหรืออัตโนมัติ? ตัวเลือกส่วนติดต่อผู้ใช้ทํางานได้ดีสําหรับกระบวนการตรวจสอบด้วยตนเองและคิวรีแบบครั้งเดียวเป็นครั้งคราว โดยเฉพาะอย่างยิ่งเมื่อคุณต้องการตรวจสอบกิจกรรมที่เฉพาะเจาะจง กระบวนการตรวจสอบอัตโนมัติที่แยกข้อมูลกิจกรรมของผู้ใช้ตามกําหนดเวลายังจําเป็นเพื่อสนับสนุนการวิเคราะห์ข้อมูลในอดีต
  • คุณต้องการข้อมูลกิจกรรมของผู้ใช้บ่อยแค่ไหน สําหรับกระบวนการตรวจสอบอัตโนมัติ วางแผนที่จะแยกข้อมูลอย่างน้อยหนึ่งวันก่อนวันที่ปัจจุบันโดยใช้เวลามาตรฐานสากล (UTC) แทนที่จะเป็นเวลาท้องถิ่นของคุณ ตัวอย่างเช่น ถ้ากระบวนการของคุณทํางานในตอนเช้าวันศุกร์ (เวลา UTC) คุณควรแยกข้อมูลจากวันพุธ มีหลายสาเหตุที่คุณควรดึงข้อมูลที่มีเวลาแฝงหนึ่งวัน
    • ไฟล์ของคุณจะทํางานง่ายขึ้นเมื่อคุณแยกไฟล์ทั้ง 24 ชั่วโมงต่อครั้ง เพื่อหลีกเลี่ยงผลลัพธ์บางส่วนของวัน
    • คุณจะลดความเสี่ยงที่จะเกิดเหตุการณ์การตรวจสอบบางอย่างหายไป โดยปกติแล้ว เหตุการณ์การตรวจสอบจะมาถึงภายใน 30 นาที บางครั้งเหตุการณ์บางอย่างอาจใช้เวลาถึง 24 ชั่วโมงในการเข้าถึงบันทึกการตรวจสอบแบบรวม
  • คุณต้องการมากกว่าข้อมูล Power BI หรือไม่? พิจารณาวิธีที่มีประสิทธิภาพที่สุดในการเข้าถึงสิ่งที่คุณต้องการ
    • เมื่อคุณต้องการเฉพาะข้อมูลกิจกรรมของผู้ใช้ Power BI ให้ใช้บันทึกกิจกรรม Power BI
    • เมื่อคุณต้องการบันทึกการตรวจสอบจากบริการหลายบริการ ให้ใช้ Office 365 Management Activity API เพื่อเข้าถึงบันทึกการตรวจสอบแบบรวม
  • ใครจะพัฒนาโซลูชัน วางแผนที่จะลงทุนบางเวลาเพื่อสร้างโซลูชัน ซึ่งอาจใช้ความพยายามอย่างมากในการสร้างสคริปต์ที่พร้อมสําหรับการผลิต

รายการตรวจสอบ - เมื่อวางแผนวิธีการเข้าถึงข้อมูลกิจกรรมของผู้ใช้ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • ชี้แจงขอบเขตความต้องการ: ตรวจสอบว่าคุณจําเป็นต้องเข้าถึงเฉพาะบันทึกการตรวจสอบ Power BI เท่านั้นหรือตรวจสอบข้อมูลสําหรับบริการหลายบริการ
  • ปรึกษากับ IT: ค้นหาว่าขณะนี้ IT แยกบันทึกการตรวจสอบหรือไม่ และอาจเป็นไปได้ที่จะรับการเข้าถึงข้อมูลดิบเพื่อที่คุณจะได้ไม่ต้องสร้างโซลูชันใหม่
  • ตัดสินใจเกี่ยวกับแหล่งข้อมูล : กําหนดแหล่งข้อมูลที่ดีที่สุดเพื่อใช้ในการเข้าถึงข้อมูลกิจกรรมของผู้ใช้
  • พิสูจน์แนวคิดเสร็จสมบูรณ์ : วางแผนเพื่อเสร็จสิ้นการพิสูจน์แนวคิดทางเทคนิคขนาดเล็ก (POC) ใช้เพื่อตรวจสอบการตัดสินใจของคุณเกี่ยวกับวิธีการสร้างโซลูชันขั้นสุดท้าย
  • ติดตามความต้องการข้อมูลเพิ่มเติม: คุณสามารถเชื่อมโยงข้อมูลบันทึกกิจกรรมกับแหล่งข้อมูลอื่น ๆ เพื่อปรับปรุงค่าของข้อมูล ติดตามโอกาสทางการขายเหล่านี้ตามที่เกิดขึ้นเพื่อให้พวกเขาสามารถเพิ่มลงในขอบเขตของโครงการของคุณได้

เข้าถึงข้อมูลสินค้าคงคลังของผู้เช่า

สินค้าคงคลังของผู้เช่าคือโซลูชันที่ทรงคุณค่าและจําเป็น ส่วนหนึ่งของโซลูชันการตรวจสอบและการตรวจสอบที่เป็นผู้ใหญ่ จะช่วยให้คุณเข้าใจว่าพื้นที่ทํางานและเนื้อหาใด (แบบจําลองความหมาย รายงาน และรายการอื่น ๆ) มีอยู่ใน Power BI และเป็นส่วนเสริมที่ยอดเยี่ยมสําหรับข้อมูลกิจกรรมของผู้ใช้ (อธิบายไว้ในส่วนก่อนหน้า) สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการระบุความต้องการข้อมูลของคุณ โปรดดู ที่สินค้าคงคลัง ของผู้เช่า ก่อนหน้าในบทความนี้

กิจกรรมของผู้ใช้ (อธิบายไว้ก่อนหน้านี้) เป็นเหตุการณ์ที่ผ่านการตรวจสอบ ซึ่งเป็นบันทึกของการดําเนินการที่ผู้ใช้ใช้วันที่และเวลาเฉพาะ อย่างไรก็ตาม ผู้เช่าสินค้าคงคลังจะแตกต่างกัน สินค้าคงคลังของผู้เช่าเป็น สแนปช็อต ณ จุดเวลาที่กําหนด ซึ่งอธิบายสถานะปัจจุบันของรายการที่เผยแพร่ทั้งหมดในบริการของ Power BI ในเวลาที่คุณแยกออก

หมายเหตุ

เอกสารประกอบ Power BI REST API หมายถึงรายการที่เผยแพร่เป็นอาร์ทิแฟกต์

เคล็ดลับ

องค์กรหลายแห่งพบว่าการแยกสินค้าคงคลังของผู้เช่าในเวลาเดียวกันของวันทุกๆ สัปดาห์นั้นเป็นประโยชน์

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับค่าของสินค้าคงคลังของผู้เช่า ดู ที่สินค้าคงคลัง ของผู้เช่าก่อนหน้าในบทความนี้

เคล็ดลับ

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

คุณสามารถรับข้อมูลสินค้าคงคลังของผู้เช่าได้สองวิธี

เทคนิค คำอธิบาย: เหมาะสมที่สุดสําหรับ ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
การเขียนโปรแกรม Get Groups as Admin API หรือ cmdlet ของ Get-PowerBIWorkspace PowerShell สามารถระบุรายการของพื้นที่ทํางานสําหรับผู้เช่าทั้งหมดได้ อีกทางหนึ่งคือสามารถรวมรายการแต่ละรายการ (เช่น แบบจําลองความหมายและรายงาน) ต่อพื้นที่ทํางานได้ องค์กรขนาดเล็กหรือปริมาณข้อมูลต่ํา รับกลุ่มเป็นผู้ดูแลระบบ API หรือ Get-PowerBIWorkspace PowerShell cmdlet เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง รับกลุ่มเป็นผู้ดูแลระบบ API หรือ Get-PowerBIWorkspace PowerShell cmdlet เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
การเขียนโปรแกรม ชุด API ของผู้ดูแลระบบแบบอะซิงโครนัสซึ่งเรียกรวมกันว่า การสแกนเมตาดาต้า API หรือ API ของสแกนเนอร์ สามารถแสดงรายการของพื้นที่ทํางานและแต่ละรายการได้ อีกทางหนึ่งคือ สามารถรวมเมตาดาต้าโดยละเอียด (เช่น ตาราง คอลัมน์ และนิพจน์หน่วยวัด) ได้เช่นกัน องค์กรที่มีปริมาณข้อมูลสูง และ/หรือจําเป็นต้องได้รับผลลัพธ์โดยละเอียด การสแกน API ของเมตาดาต้าเป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ

ส่วนที่เหลือของส่วนนี้จะแนะนําเทคนิคแต่ละเทคนิคที่แสดงในตาราง

Cmdlet ของ Api หรือพื้นที่ทํางานของกลุ่ม

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

หมายเหตุ

API ที่ชื่อว่ารวมถึงกลุ่มคําเพื่อเป็นการอ้างอิงไปยังพื้นที่ทํางาน คํานั้นมาจากรูปแบบความปลอดภัยของ Power BI เดิม ซึ่งขึ้นอยู่กับกลุ่ม Microsoft 365 ในขณะที่แบบจําลองความปลอดภัยของ Power BI มีการพัฒนาอย่างมากในช่วงหลายปีที่ผ่านมา แต่ชื่อ API ที่มีอยู่ยังคงไม่เปลี่ยนแปลงเพื่อหลีกเลี่ยงการทําลายโซลูชันที่มีอยู่

Get Groups as Admin REST API มีพารามิเตอร์ที่เป็นประโยชน์$expand พารามิเตอร์นี้ช่วยให้คุณสามารถเลือกที่จะขยายผลลัพธ์เพื่อให้รวมรายการของรายการที่เผยแพร่ไปยังพื้นที่ทํางาน (เช่น แบบจําลองความหมายและรายงาน) คุณยังสามารถส่งผ่าน users ชนิดข้อมูลไปยัง $expand พารามิเตอร์เพื่อรวมผู้ใช้ที่ได้รับมอบหมายบทบาทพื้นที่ทํางาน

คุณยังสามารถใช้ cmdlet รับ -PowerBIWorkspace PowerShell ได้ ซึ่งมาจากมอดูลพื้นที่ทํางานการจัดการ Power BI เมื่อคุณตั้งค่า -Scope พารามิเตอร์ organizationมันจะทําหน้าที่เหมือนกับ Get Groups as Admin API cmdlet ยังยอมรับ -Include พารามิเตอร์ (ซึ่งเทียบเท่ากับ $expand พารามิเตอร์ใน REST API) เพื่อรวมรายการที่เผยแพร่ในพื้นที่ทํางาน (เช่น แบบจําลองความหมายและรายงาน)

เคล็ดลับ

ด้วยการส่งผ่านพารามิเตอร์ คุณสามารถใช้ cmdlet ในลักษณะที่แตกต่างกัน ส่วนนี้มุ่งเน้นไปที่การดึงข้อมูลสินค้าคงคลังที่กว้างขวางของผู้เช่า สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้ -Scope พารามิเตอร์ ดู เลือก API ของผู้ใช้หรือผู้ดูแลระบบ API ก่อนหน้าในบทความนี้

เพื่อช่วยให้คุณเลือกตัวเลือกที่จะใช้ ดู เลือก API หรือ cmdlet ของ PowerShell ก่อนหน้าในบทความนี้

Get Groups as Admin REST API หรือ cmdlet ของ Get-PowerBIWorkspace PowerShell เหมาะสมที่สุดสําหรับกระบวนการตรวจสอบด้วยตนเองและการตรวจสอบแบบครั้งเดียว องค์กรขนาดใหญ่ที่มีปริมาณข้อมูลสูงโดยทั่วไปแล้วจะพบตัวเลือกเหล่านี้ที่ท้าทายในการใช้งาน REST API และ cmdlet จะแยกชุดข้อมูลเต็มรูปแบบเพื่อให้สามารถใช้เวลานานในการเรียกใช้งาน ดังนั้นจึงเป็นไปได้ว่าองค์กรขนาดใหญ่จะพบข้อจํากัดเกี่ยวกับจํานวนคําขอที่ได้รับอนุญาตต่อชั่วโมง (เรียกว่า การจํากัดผลลัพธ์ ซึ่งดําเนินการเพื่อปกป้องสถานภาพของบริการ) การสแกน API ของเมตาดาต้า (อธิบายต่อไป) เป็นทางเลือกที่เชื่อถือได้และสามารถปรับขนาดได้มากขึ้น

การสแกน API ของเมตาดาต้า

การสแกน API ของเมตาดาต้า มักเรียกว่า API ของสแกนเนอร์ คือ ชุดของ API ที่แสดงรายการของพื้นที่ทํางานและรายการ Power BI (แบบจําลองความหมาย รายงาน และรายการอื่น ๆ) ตามแนวคิดแล้ว จะมีข้อมูลเดียวกัน (และอื่น ๆ) เป็นกลุ่ม API หรือ cmdlet ของพื้นที่ทํางาน ซึ่งจะอธิบายไว้ในส่วนก่อนหน้า อย่างไรก็ตาม วิธีการที่คุณใช้เพื่อดึงข้อมูลนั้นแตกต่างกันและเหมาะสมกว่าในการแยกสินค้าคงคลังของผู้เช่า

หมายเหตุ

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

มีเหตุผลหลักสองประการที่คุณควรพิจารณาใช้เมตาดาต้าในการสแกน API แทน Get Groups as Admin REST API หรือ Get-PowerBIWorkspace cmdlet (อธิบายไว้ก่อนหน้านี้)

  • การแยกข้อมูลแบบเพิ่มหน่วย: API ของสแกนเนอร์จะแยกเฉพาะข้อมูลที่มีการเปลี่ยนแปลงนับตั้งแต่มีการเรียกใช้ครั้งล่าสุดเท่านั้น Get Groups as Adminในทางกลับกัน REST API และ Get-PowerBIWorkspace cmdlet เป็นการดําเนินการแบบซิงโครนัสที่แยกชุดข้อมูลทั้งหมดทุกครั้งที่เรียกใช้งาน
  • รายละเอียดที่ละเอียดมากขึ้น: API ของสแกนเนอร์สามารถเรียกรายละเอียดที่ละเอียดมากขึ้น (เช่น นิพจน์ตาราง คอลัมน์ และหน่วยวัด) โดยให้สิทธิ์จากการตั้งค่าผู้เช่าสองรายการสําหรับเมตาดาต้าโดยละเอียด ในทางกลับกัน ระดับรายละเอียดต่ําสุดที่พร้อมใช้งานกับ Get Groups as Admin REST API และ Get-PowerBIWorkspace cmdlet คือตามประเภทหน่วยข้อมูล (ตัวอย่างเช่น รายการของรายงานในพื้นที่ทํางาน)

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

นี่คือลําดับของขั้นตอนที่กระบวนการของคุณควรปฏิบัติตามเมื่อใช้ API ของสแกนเนอร์

  1. ลงชื่อเข้าใช้: ลงชื่อเข้าใช้บริการของ Power BI โดยใช้บัญชีผู้ดูแลระบบ Power BI หรือบริการหลักที่มีสิทธิ์ในการเรียกใช้ API ของผู้ดูแลระบบ สําหรับข้อมูลเพิ่มเติม ดู กําหนดวิธี การรับรองความถูกต้องก่อนหน้าในบทความนี้
  2. รับรหัสพื้นที่ทํางาน: ส่งคําขอเพื่อเรียกดูรายการรหัสพื้นที่ทํางาน ในครั้งแรกที่เรียกใช้ คุณจะไม่มีวันที่ปรับเปลี่ยน ดังนั้นจึงจะส่งกลับรายการทั้งหมดของพื้นที่ทํางาน โดยทั่วไปแล้ว คุณจะผ่านวันที่ที่ปรับเปลี่ยนแล้วเพื่อดึงข้อมูลเฉพาะพื้นที่ทํางานที่มีการเปลี่ยนแปลงตั้งแต่เวลานั้น วันที่ปรับเปลี่ยนต้องอยู่ภายใน 30 วันที่ผ่านมา
  3. เริ่มต้นการสแกนเมตาดาต้า: เริ่มการโทรไปที่ ร้องขอการสแกนข้อมูลพื้นที่ทํางาน โดยการส่งผ่านใน ID พื้นที่ทํางานที่เรียกใช้ในขั้นตอนที่ 2 โปรดทราบว่านี่คือ POST API (แทน GET API ซึ่งพบได้บ่อยกว่าเมื่อดึงข้อมูลการตรวจสอบ) POST API เป็นคําขอ HTTP ที่สร้างหรือเขียนข้อมูลสําหรับทรัพยากรที่ระบุ คิวรีนี้ระบุระดับของรายละเอียดที่จะถูกแยก เช่น รายละเอียดแหล่งข้อมูล Schema แบบจําลองความหมาย นิพจน์แบบจําลองความหมาย หรือผู้ใช้ เมื่อส่งแล้ว API จะส่งกลับ ID สําหรับการสแกน นอกจากนี้ยังส่งกลับวันที่และเวลาของการสแกนซึ่งคุณควรบันทึกเป็นวันที่สแนปช็อต
  4. ตรวจสอบสถานะการสแกน: ใช้ ID การสแกนที่ได้รับในขั้นตอนที่ 3 เพื่อรับสถานะการสแกน คุณอาจจําเป็นต้องเรียกใช้ API นี้มากกว่าหนึ่งครั้ง เมื่อสถานะที่แสดงเป็น สําเร็จ แล้ว สามารถดําเนินการขั้นตอนถัดไปได้ เวลาที่ใช้ในการสแกนจะขึ้นอยู่กับปริมาณข้อมูลที่คุณร้องขอ
  5. รับผลลัพธ์: ใช้ ID การสแกนที่ได้รับในขั้นตอนที่ 3 เพื่อรับผลลัพธ์การสแกน และแยกข้อมูล คุณต้องทําขั้นตอนนี้ภายใน 24 ชั่วโมงหลังจากเสร็จสิ้นขั้นตอนที่ 4 โปรดทราบว่าสแตมป์เวลาสแนปช็อตควรสัมพันธ์กับขั้นตอนที่ 3 แทนที่จะเป็นขั้นตอนที่ 5 (เมื่อมีความล่าช้าที่สําคัญ) ด้วยวิธีนี้ คุณจะมีสแนปช็อตเวลาสแนปช็อตที่แม่นยํา บันทึกผลลัพธ์ใน ตําแหน่งที่เก็บข้อมูลที่คุณต้องการ ตามที่อธิบายไว้ในบทความนี้ เราขอแนะนําให้คุณจัดเก็บข้อมูลดิบในสถานะดั้งเดิม
  6. เตรียมพร้อมสําหรับกระบวนการถัดไป: บันทึกการประทับเวลาของการสแกนจากขั้นตอนที่ 3 เพื่อให้คุณสามารถใช้ได้ในขั้นตอนที่ 2 ในครั้งต่อไปที่คุณเรียกใช้กระบวนการ ด้วยวิธีนี้ คุณจะดึงข้อมูลที่มีการเปลี่ยนแปลงตั้งแต่จุดเวลานั้นเท่านั้น การแยกข้อมูลที่ตามมาทั้งหมดต่อไปจะเป็นการเปลี่ยนแปลงแบบเพิ่มหน่วยแทนที่จะเป็นสแนปช็อตแบบเต็ม

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

  • ยืนยันข้อกําหนด: ชี้แจงความต้องการสําหรับการรวบรวมสินค้าคงคลังของผู้เช่าและข้อกําหนดการวิเคราะห์สําหรับข้อมูล
  • ตัดสินใจเกี่ยวกับความถี่ในการแยกสินค้าคงคลังของผู้เช่า: ยืนยันความถี่ของจํานวนครั้งที่คุณจะต้องใช้สินค้าคงคลังของผู้เช่าใหม่ (เช่น ทุกสัปดาห์)
  • ตัดสินใจว่าจะแยกสินค้าคงคลังของผู้เช่าอย่างไร : ยืนยันว่าคุณจะใช้วิธีใดเพื่อรับข้อมูลสินค้าคงคลังของผู้เช่า (API, cmdlet หรือเมตาดาต้าที่กําลังสแกน API)
  • พิสูจน์แนวคิดเสร็จสมบูรณ์ : วางแผนเพื่อเสร็จสิ้นการพิสูจน์แนวคิดทางเทคนิคขนาดเล็ก (POC) ใช้เพื่อตรวจสอบการตัดสินใจของคุณเกี่ยวกับวิธีการสร้างโซลูชันขั้นสุดท้าย

เข้าถึงข้อมูลผู้ใช้และกลุ่ม

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

ต่อไปนี้เป็นรายละเอียดเกี่ยวกับวัตถุ Microsoft Entra ที่คุณสามารถเข้าถึงได้

  • ผู้ใช้ : ข้อมูลประจําตัวที่มีอยู่ใน Microsoft Entra ID เป็นบัญชีที่ทํางาน โรงเรียน หรือ Microsoft คําว่า ผู้ใช้ โดเมนมักใช้เพื่ออธิบายผู้ใช้ขององค์กร ในขณะที่คําที่เป็นทางการคือ ชื่อ หลักของผู้ใช้ (UPN) UPN มักจะเป็นค่าเดียวกับที่อยู่อีเมลของผู้ใช้ (อย่างไรก็ตาม ถ้าที่อยู่อีเมลเปลี่ยนแปลง UPN จะไม่เปลี่ยนแปลงเนื่องจากไม่สามารถเปลี่ยนแปลงได้) นอกจากนี้ยังมี ID ของ Microsoft Graph ที่ไม่ซ้ํากันสําหรับผู้ใช้แต่ละราย บ่อยครั้งที่บัญชีผู้ใช้เชื่อมโยงกับบุคคลเดียว บางองค์กรสร้างผู้ใช้ที่เป็น บัญชี บริการที่ใช้สําหรับกิจกรรมอัตโนมัติหรือสําหรับงานดูแลระบบ
  • บริการหลัก : ข้อมูลประจําตัวชนิดต่างๆ ที่เตรียมใช้งานเมื่อคุณสร้างการลงทะเบียนแอป บริการหลักมีไว้สําหรับกิจกรรมอัตโนมัติแบบอัตโนมัติ สําหรับข้อมูลเพิ่มเติม ดู กําหนดวิธี การรับรองความถูกต้องก่อนหน้าในบทความนี้
  • กลุ่ม : คอลเลกชันของผู้ใช้และบริการหลัก มีกลุ่มหลายชนิดที่คุณสามารถใช้เพื่อลดความซับซ้อนของการจัดการสิทธิ์ สําหรับข้อมูลเพิ่มเติม ดูกลยุทธ์สําหรับการใช้กลุ่ม

หมายเหตุ

เมื่อบทความนี้อ้างอิงถึง ผู้ใช้และกลุ่ม คํานี้ประกอบด้วยโครงร่างสําคัญของบริการด้วย คําที่สั้นลงนี้ใช้เพื่อความกระชับ

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

เคล็ดลับ

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับผู้ใช้ บริการหลัก และกลุ่ม ดู การรวมด้วย ID Microsoft Entra

แอตทริบิวต์การวิเคราะห์

สําหรับการตรวจสอบระดับผู้เช่า Power BI คุณอาจแยกและจัดเก็บแอตทริบิวต์ต่อไปนี้จาก Microsoft Graph ได้

  • ชื่อเต็มของผู้ใช้: แหล่งข้อมูลหลายแหล่งรวมเฉพาะที่อยู่อีเมลของผู้ใช้ที่ดําเนินการกิจกรรมหรือผู้ที่มอบหมายบทบาทให้ ใช้แอตทริบิวต์นี้เมื่อคุณต้องการแสดงชื่อเต็ม (ชื่อที่แสดง) ในรายงานการวิเคราะห์ การใช้ชื่อเต็มจะทําให้รายงานใช้งานได้ง่ายยิ่งขึ้น
  • คุณสมบัติของผู้ใช้อื่น: แอตทริบิวต์เชิงพรรณนาอื่น ๆ เกี่ยวกับผู้ใช้อาจพร้อมใช้งานใน Microsoft Entra ID ตัวอย่างบางส่วนของแอตทริบิวต์โปรไฟล์ผู้ใช้ที่มีอยู่ภายในที่มีค่าการวิเคราะห์รวมถึงตําแหน่งงาน แผนก ผู้จัดการ ภูมิภาค และตําแหน่งที่ตั้งของสํานักงาน
  • สมาชิกของกลุ่มความปลอดภัย: แหล่งข้อมูลส่วนใหญ่มีชื่อของกลุ่ม (ตัวอย่างเช่น บันทึกกิจกรรม Power BI ที่กลุ่มความปลอดภัยถูกกําหนดให้กับบทบาทพื้นที่ทํางาน) การดึงการเป็นสมาชิกกลุ่มช่วยปรับปรุงความสามารถของคุณในการวิเคราะห์สิ่งที่ผู้ใช้แต่ละคนกําลังทําอยู่หรือมีสิทธิ์เข้าถึงอย่างเต็มที่
  • สิทธิ์การใช้งานผู้ใช้: มีประโยชน์ในการวิเคราะห์สิทธิ์การใช้งานของผู้ใช้ —ฟรี Power BI Pro หรือ Power BI Premium Per User (PPU) จะถูกกําหนดให้กับผู้ใช้ ข้อมูลนี้สามารถช่วยให้คุณระบุได้ว่าใครไม่ได้ใช้สิทธิการใช้งานของตน นอกจากนี้ยังช่วยให้คุณสามารถวิเคราะห์ผู้ใช้ทั้งหมด (ผู้ใช้ที่แตกต่างกันที่มีสิทธิ์การใช้งาน) เทียบกับผู้ใช้ที่ใช้งานอยู่ (ด้วยกิจกรรมล่าสุด) หากคุณกําลังพิจารณาเพิ่มหรือขยายสิทธิ์การใช้งาน Power BI Premium ของคุณ เราขอแนะนําให้คุณวิเคราะห์ข้อมูลสิทธิ์การใช้งานผู้ใช้พร้อมกับข้อมูลกิจกรรมของผู้ใช้เพื่อดําเนินการวิเคราะห์ค่าใช้จ่าย
  • สมาชิกของบทบาทผู้ดูแลระบบ: คุณสามารถรวบรวมรายชื่อผู้ดูแลระบบ Power BI ของคุณคือ (ซึ่งรวมถึงผู้ดูแลระบบ Power Platform)

สําหรับการอ้างอิงอย่างเป็นทางการของข้อมูลสิทธิ์การใช้งาน Power BI ที่คุณสามารถค้นหาในข้อมูลการตรวจสอบจาก Microsoft Graph ดูชื่อผลิตภัณฑ์และตัวระบุแผนบริการสําหรับการให้สิทธิ์การใช้งาน

เคล็ดลับ

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

ต่อไปนี้เป็นแอตทริบิวต์อื่น ๆ ที่คุณอาจแยกและจัดเก็บ

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

เคล็ดลับ

บันทึกกิจกรรม Power BI ประกอบด้วยเหตุการณ์ที่บันทึกเมื่อผู้ใช้ลงทะเบียนสําหรับสิทธิ์การใช้งานรุ่นทดลองใช้ คุณสามารถรวมเหตุการณ์นั้นกับข้อมูลสิทธิ์การใช้งานผู้ใช้ (ที่มาจากรหัส Microsoft Entra) เพื่อสร้างรูปภาพที่สมบูรณ์

ดึงข้อมูลผู้ใช้และกลุ่ม

คุณสามารถเรียกใช้ข้อมูลเกี่ยวกับผู้ใช้และกลุ่มได้หลายวิธี

เทคนิค คำอธิบาย: ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง ตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
ด้วยตนเอง การสำรวจกราฟ Graph Explorer เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบด้วยตนเอง
การเขียนโปรแกรม API และ SDK ของ Microsoft Graph Microsoft Graph API และ SDK เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ
การเขียนโปรแกรม โมดูล Az PowerShell โมดูล Az PowerShell เป็นตัวเลือกที่ดีสําหรับกระบวนการตรวจสอบอัตโนมัติ

ส่วนที่เหลือของส่วนนี้จะแนะนําเทคนิคแต่ละเทคนิคที่แสดงในตาราง เทคนิคอื่น ๆ ที่เลิกใช้แล้วและไม่ควรใช้สําหรับโซลูชันใหม่ จะอธิบายไว้ในตอนท้ายของส่วนนี้

หมายเหตุ

โปรดระวังเมื่อคุณอ่านข้อมูลออนไลน์เนื่องจากชื่อเครื่องมือจํานวนมากมีลักษณะคล้ายกัน เครื่องมือบางอย่างในระบบนิเวศของ Microsoft มีคําว่า Graph ในชื่อของเครื่องมือ เช่น Azure Resource GraphQL และ Microsoft Security Graph API เครื่องมือเหล่านั้นไม่เกี่ยวข้องกับ Microsoft Graph และไม่อยู่ในขอบเขตสําหรับบทความนี้

Microsoft Graph Explorer

Microsoft Graph Explorer เป็นเครื่องมือสําหรับนักพัฒนาที่ช่วยให้คุณเรียนรู้เกี่ยวกับ Microsoft Graph API ซึ่งเป็นวิธีง่ายๆ ในการเริ่มต้นใช้งานเนื่องจากไม่จําเป็นต้องมีเครื่องมือหรือการตั้งค่าอื่น ๆ บนเครื่องของคุณ คุณสามารถลงชื่อเข้าใช้เพื่อดึงข้อมูลจากผู้เช่าของคุณ หรือดึงข้อมูลตัวอย่างจากผู้เช่าเริ่มต้นได้

คุณสามารถใช้ Graph Explorer เพื่อ:

  • ส่งคําขอไปยัง Microsoft Graph API ด้วยตนเองเพื่อตรวจสอบว่าจะส่งกลับข้อมูลที่คุณต้องการหรือไม่
  • ดูวิธีการสร้าง URL ส่วนหัว และเนื้อหาก่อนที่คุณจะเขียนสคริปต์
  • ตรวจสอบข้อมูลด้วยวิธีที่ไม่เป็นทางการ
  • กําหนดสิทธิ์ที่จําเป็นสําหรับแต่ละ API คุณยังสามารถให้ ความยินยอม สําหรับสิทธิ์ใหม่ได้
  • รับส่วนย่อยของโค้ดที่จะใช้เมื่อคุณสร้างสคริปต์

ใช้ ลิงก์ นี้เพื่อเปิด Graph Explorer

API และ SDK ของ Microsoft Graph

ใช้ API ของ Microsoft Graph เพื่อดึงข้อมูลผู้ใช้และกลุ่ม คุณยังสามารถใช้เพื่อดึงข้อมูลจากบริการ เช่น Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook และอื่นๆ อีกมากมาย

SDK ของ Microsoft Graph ทําหน้าที่เป็นตัวตัด API ที่ด้านบนของ API ของ Microsoft Graph พื้นฐาน SDK คือ ชุด การพัฒนาซอฟต์แวร์ที่รวมเครื่องมือและฟังก์ชันการทํางานเข้าด้วยกัน SDK ของ Microsoft Graph แสดงชุดของ API ของ Microsoft Graph ทั้งหมด

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

SDK ของ Microsoft Graph รองรับหลายภาษา และมี มอดูล Microsoft Graph PowerShell ด้วย SDK อื่นๆ จะพร้อมใช้งานสําหรับ Python, C# และภาษาอื่น ๆ

สำคัญ

โมดูล Microsoft Graph PowerShell จะแทนที่โมดูล Azure AD PowerShell และมอดูล MSOnline (MSOL) ซึ่งทั้งสองไม่ได้รับการสนับสนุน คุณไม่ควรสร้างโซลูชันใหม่ด้วยโมดูลที่เลิกใช้แล้ว โมดูล Microsoft Graph PowerShell มีคุณลักษณะและประโยชน์มากมาย สําหรับข้อมูลเพิ่มเติม โปรดดู อัปเกรดจาก Azure AD PowerShell ไปยัง Microsoft Graph PowerShell

คุณสามารถติดตั้งมอดูล Microsoft Graph PowerShell จาก แกลเลอรี PowerShell ได้ เนื่องจาก Microsoft Graph ทํางานกับบริการ Microsoft 365 จํานวนมาก จึงมีมอดูล PowerShell มากมายที่คุณติดตั้ง

สําหรับการตรวจสอบระดับผู้เช่า Power BI นี่คือมอดูล PowerShell ที่พบบ่อยที่สุดที่คุณจะต้องติดตั้ง

เคล็ดลับ

Microsoft จะอัปเดตโมดูล Microsoft Graph PowerShell เป็นประจํา ในบางครั้ง มอดูลตัวอย่างจะพร้อมใช้งานบนพื้นฐานการเผยแพร่ล่วงหน้าหรือจุดสิ้นสุดเบต้า คุณอาจต้องการระบุเวอร์ชันที่คุณสนใจเมื่อคุณติดตั้งและอัปเดตโมดูล นอกจากนี้ เมื่อคุณตรวจสอบเอกสารแบบออนไลน์ โปรดทราบว่าหมายเลขเวอร์ชันปัจจุบันจะถูกผนวกเข้ากับส่วนท้ายของ URL โดยอัตโนมัติ (โปรดระมัดระวังเมื่อบันทึกหรือแชร์ URL)

โมดูล Az PowerShell

คุณยังสามารถใช้ ม อดูล Az PowerShell เพื่อดึงข้อมูลผู้ใช้และกลุ่มได้ ซึ่งมุ่งเน้นไปที่ทรัพยากร Azure

สำคัญ

โมดูล Az PowerShell จะแทนที่โมดูล AzureRM PowerShell ซึ่งจะถูกยกเลิก คุณไม่ควรสร้างโซลูชันใหม่ด้วยโมดูลที่เลิกใช้แล้ว

คุณสามารถใช้ cmdlet Invoke-AzRestMethod เมื่อไม่มี cmdlet ที่สอดคล้องกันสําหรับ API ซึ่งเป็นวิธีการที่ยืดหยุ่นซึ่งช่วยให้คุณสามารถส่งคําขอไปยัง Microsoft Graph API โดยใช้มอดูล Az PowerShell

เริ่มต้นด้วย Az เวอร์ชัน 7 cmdlet ของ Az ตอนนี้อ้างอิง API ของ Microsoft Graph ดังนั้น โมดูล Az ทําหน้าที่เป็น ตัวตัด API ด้านบนของ Microsoft Graph โมดูล Az มีชุดย่อยของฟังก์ชันการทํางานที่มีอยู่ในโมดูล Microsoft Graph API และ PowerShell สําหรับโซลูชันใหม่ เราขอแนะนําให้คุณใช้ Microsoft Graph PowerShell SDK

API และโมดูลที่เลิกใช้แล้ว

คุณอาจพบบทความและโพสต์ในบล็อกออนไลน์ที่แนะนําตัวเลือกอื่นที่ไม่ได้แสดงในส่วนนี้ เราขอแนะนําอย่างยิ่งว่าคุณ อย่า สร้างโซลูชันใหม่ (และ/หรือย้ายโซลูชันที่มีอยู่ของคุณ) โดยใช้ API หรือมอดูลต่อไปนี้

  • โมดูล AzureRM PowerShell: เลิกใช้และจะปลดใช้งาน พวกเขาถูกแทนที่ด้วยมอดูล Az PowerShell
  • โมดูล Azure AD Graph API และ Azure AD PowerShell: เลิกใช้และจะถูกยกเลิก การเปลี่ยนแปลงนี้คือผลลัพธ์ของการโยกย้ายจาก Azure AD Graph ไปยัง Microsoft Graph (โปรดทราบว่า Graph ปรากฏในทั้งสองชื่อ แต่ Microsoft Graph เป็นทิศทางในอนาคต) การลงทุนของ PowerShell ในอนาคตทั้งหมดจะดําเนินการใน Microsoft Graph PowerShell SDK
  • โมดูล MS Online (MSOL) PowerShell: ยกเลิกและจะถูกยกเลิก การลงทุนของ PowerShell ในอนาคตทั้งหมดจะดําเนินการใน Microsoft Graph PowerShell SDK

ข้อควรระวัง

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

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ Microsoft Entra ID และ MSOL โปรดดู โพสต์ประกาศการเกษียณนี้

หากคุณมีคําถามหรือต้องการการชี้แจงเกี่ยวกับทิศทางการเข้าถึงข้อมูลทางโปรแกรมในอนาคต ให้ติดต่อทีมบัญชี Microsoft ของคุณ

รายการตรวจสอบ - เมื่อวางแผนที่จะเข้าถึงข้อมูลผู้ใช้และกลุ่ม การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • ยืนยันข้อกําหนด: ชี้แจงความต้องการในการคอมไพล์ข้อมูลที่เกี่ยวข้องกับผู้ใช้ กลุ่ม และสิทธิ์การใช้งาน
  • ข้อกําหนดการจัดลําดับความสําคัญ : ยืนยันว่าสิ่งใดที่มีลําดับความสําคัญสูงสุดเพื่อให้คุณทราบว่าต้องใช้เวลาอะไรเป็นอันดับแรก
  • ตัดสินใจเกี่ยวกับความถี่ในการแยกข้อมูล : กําหนดความถี่ที่คุณต้องการสแนปช็อตใหม่ของข้อมูลผู้ใช้และกลุ่ม (เช่น ทุกสัปดาห์หรือทุกเดือน)
  • ตัดสินใจว่าจะดึงข้อมูลด้วย Microsoft Graphอย่างไร : กําหนดวิธีที่คุณจะใช้เพื่อดึงข้อมูล
  • พิสูจน์แนวคิดเสร็จสมบูรณ์ : วางแผนเพื่อเสร็จสิ้นการพิสูจน์แนวคิดทางเทคนิค (POC) ขนาดเล็กเพื่อแยกข้อมูลผู้ใช้และกลุ่ม ใช้เพื่อตรวจสอบการตัดสินใจของคุณเกี่ยวกับวิธีการสร้างโซลูชันขั้นสุดท้าย

เข้าถึงข้อมูลจาก Power BI REST API

อาจเป็นลําดับความสําคัญที่ต่ํากว่า คุณยังสามารถเรียกใช้ข้อมูลอื่น ๆ โดยใช้ Power BI REST API ได้

ตัวอย่างเช่น คุณสามารถดึงข้อมูลเกี่ยวกับ:

ในระหว่างการตรวจสอบความปลอดภัย คุณอาจต้องการระบุ:

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ API ประเภทอื่น ๆ ดู เลือก API ผู้ใช้หรือ API ผู้ดูแลระบบก่อนหน้าในบทความนี้

รายการตรวจสอบ - เมื่อวางแผนสําหรับการเข้าถึงข้อมูลจาก API ของ Power BI การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • ขอรับข้อกําหนด: รวบรวมข้อกําหนดการวิเคราะห์ตามที่เกิดขึ้น ติดตามรายการเหล่านั้นในงานค้างของคุณ
  • ข้อกําหนดการจัดลําดับความสําคัญ : ตั้งค่าลําดับความสําคัญสําหรับข้อกําหนดใหม่ที่เกิดขึ้น

ระยะที่ 2: ข้อกําหนดเบื้องต้นและการตั้งค่า

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

ไดอะแกรมโฟลว์ที่อธิบายขั้นตอนที่ 2 ซึ่งมุ่งเน้นข้อกําหนดเบื้องต้นและการตั้งค่าสําหรับการสร้างโซลูชันการตรวจสอบระดับผู้เช่า

สร้างบัญชีเก็บข้อมูล

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

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

รายการ ตรวจสอบ – เมื่อสร้างบัญชีเก็บข้อมูล การตัดสินใจที่สําคัญและการดําเนินการประกอบด้วย:

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

ติดตั้งซอฟต์แวร์และตั้งค่าบริการ

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

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

หากคุณได้ตัดสินใจ (อธิบายไว้ก่อนหน้านี้) เพื่อใช้ PowerShell แล้ว คุณควรติดตั้ง PowerShell Core และมอดูล PowerShell ที่จําเป็นสําหรับ:

  • เครื่องของผู้ดูแลระบบ/นักพัฒนาแต่ละรายที่จะเขียนหรือทดสอบสคริปต์การตรวจสอบ
  • แต่ละเครื่องเสมือนหรือเซิร์ฟเวอร์ที่จะเรียกใช้สคริปต์ที่กําหนดเวลาไว้
  • แต่ละบริการออนไลน์ (เช่น ฟังก์ชัน Azure หรือ Azure Automation)

ถ้าคุณเลือกที่จะใช้บริการใดๆ ของ Azure (เช่น ฟังก์ชัน Azure, Azure Automation, Azure Data Factory หรือ Azure Synapse Analytics) คุณควรเตรียมใช้งานและตั้งค่าดังกล่าวได้เช่นกัน

รายการ ตรวจสอบ – เมื่อติดตั้งซอฟต์แวร์และตั้งค่าบริการ การตัดสินใจและการดําเนินการที่สําคัญ ประกอบด้วย:

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

ลงทะเบียนแอปพลิเคชัน Microsoft Entra

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

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

รายการตรวจสอบ - เมื่อลงทะเบียนแอปพลิเคชัน Microsoft Entra การตัดสินใจที่สําคัญและการดําเนินการรวมถึง:

  • ตรวจสอบว่าการลงทะเบียนแอปที่มีอยู่มีอยู่: ตรวจสอบว่าการลงทะเบียนแอปที่มีอยู่พร้อมใช้งานสําหรับวัตถุประสงค์ในการเรียกใช้ API ของผู้ดูแลระบบหรือไม่ ถ้าเป็นเช่นนั้น ให้กําหนดว่าควรใช้ชุดที่มีอยู่หรือควรสร้างขึ้นใหม่หรือไม่
  • สร้างการลงทะเบียนแอปใหม่: สร้างการลงทะเบียนแอปเมื่อเหมาะสม พิจารณาใช้ชื่อแอปเช่น PowerBI-AdminAPIs-EntraApp ซึ่งอธิบายวัตถุประสงค์ได้อย่างชัดเจน
  • สร้างข้อมูลลับสําหรับการลงทะเบียนแอป: เมื่อมีการลงทะเบียนแอปแล้ว ให้สร้างข้อมูลลับสําหรับการลงทะเบียนแอป ตั้งค่าวันหมดอายุตามความถี่ที่คุณต้องการหมุนข้อมูลลับ
  • บันทึกค่าได้อย่างปลอดภัย: จัดเก็บข้อมูลลับ ID แอป (ID ไคลเอ็นต์) และ ID ผู้เช่าเนื่องจากคุณจะต้องให้พวกเขารับรองความถูกต้องด้วยบริการหลัก ใช้ตําแหน่งที่ตั้งที่มีความปลอดภัย เช่น ชุดเก็บรหัสผ่านขององค์กร (ถ้าคุณต้องการร้องขอการสร้างการลงทะเบียนแอปจาก IT ให้ระบุว่าคุณต้องใช้ค่าเหล่านี้กลับมาหาคุณ)
  • สร้างกลุ่มความปลอดภัย: สร้าง (หรือร้องขอ) กลุ่มความปลอดภัยที่จะใช้สําหรับ Power BI พิจารณาใช้ชื่อกลุ่ม เช่น บริการหลักของผู้ดูแลระบบ Power BI ซึ่งบ่งบอกว่ากลุ่มจะถูกใช้เพื่อเข้าถึงเมตาดาต้าทั่วทั้งผู้เช่า
  • เพิ่มโครงร่างสําคัญของบริการเป็นสมาชิกของกลุ่มความปลอดภัย: ใช้ ID แอป (ID ไคลเอ็นต์) เพื่อเพิ่มบริการหลัก (หรือที่มีอยู่) ใหม่เป็นสมาชิกของกลุ่มความปลอดภัยใหม่
  • อัปเดตการตั้งค่าผู้เช่า API ผู้ดูแลระบบใน Fabric: ในพอร์ทัลผู้ดูแลระบบ Fabric เพิ่มกลุ่มความปลอดภัยไปยัง อนุญาตให้โครงร่างสําคัญของบริการใช้ API ผู้ดูแลระบบ Power BI แบบอ่านอย่างเดียว การตั้งค่าผู้เช่า
  • ข้ามการกําหนดสิทธิ์ใน Azure: อย่ามอบหมายสิทธิ์ใดๆ ให้กับการลงทะเบียนแอป (จะสามารถเข้าถึงข้อมูลการตรวจสอบระดับผู้เช่า Power BI ได้โดยวิธี อนุญาตให้โครงร่างสําคัญของบริการใช้ API ผู้ดูแลระบบ Power BI แบบอ่านอย่างเดียว การตั้งค่าผู้เช่า)
  • ตัดสินใจว่าการลงทะเบียนแอปควรเข้าถึงเมตาดาต้าโดยละเอียดหรือไม่: พิจารณาว่าคุณต้องการแยกข้อมูลโดยละเอียดเกี่ยวกับตาราง แบบจําลองความหมาย คอลัมน์ และนิพจน์หน่วยวัดหรือไม่เมื่อคุณสร้างสินค้าคงคลังของผู้เช่าของคุณ
  • อัปเดตการตั้งค่าผู้เช่าเมตาดาต้าโดยละเอียดใน Power BI: ไม่บังคับ ในพอร์ทัลผู้ดูแลระบบ Fabric เพิ่มกลุ่มความปลอดภัยไปยัง ปรับปรุงการตอบกลับ API ของผู้ดูแลระบบ ด้วยเมตาดาต้าโดยละเอียด การตั้งค่าผู้เช่า และยัง ปรับปรุงการตอบกลับ API ผู้ดูแลระบบด้วย DAX และนิพจน์ mashup การตั้งค่าผู้เช่า
  • ทดสอบโครงร่างสําคัญของบริการ: สร้างสคริปต์อย่างง่ายเพื่อลงชื่อเข้าใช้โดยใช้บริการหลัก และทดสอบว่าสามารถเรียกใช้ข้อมูลจาก API ของผู้ดูแลระบบได้
  • สร้างกระบวนการจัดการความลับในการลงทะเบียนแอป: สร้างเอกสารและกระบวนการเพื่อหมุนข้อมูลลับเป็นประจํา กําหนดวิธีที่คุณจะสื่อสารข้อมูลลับใหม่กับผู้ดูแลระบบและนักพัฒนาซอฟต์แวร์ที่ต้องการได้อย่างปลอดภัย

ตั้งค่าผู้เช่า Fabric

มีการตั้งค่าผู้เช่ามากมายในพอร์ทัลผู้ดูแลระบบ Fabric ที่เกี่ยวข้องสําหรับการดึงข้อมูลการตรวจสอบระดับผู้เช่า

API ของผู้ดูแลระบบ

มีการตั้งค่าผู้เช่าสามรายการที่เกี่ยวข้องกับการเรียกใช้ API ของผู้ดูแลระบบ

สำคัญ

เนื่องจากการตั้งค่าเหล่านี้ให้การเข้าถึงเมตาดาต้าสําหรับผู้เช่าทั้งหมด (โดยไม่ต้องกําหนดสิทธิ์ Power BI โดยตรง) คุณควรควบคุมผู้เช่าเหล่านี้อย่างเข้มงวด

การตั้งค่าผู้เช่าของผู้ดูแลระบบ Power BI แบบอ่านอย่างเดียวช่วยให้คุณสามารถตั้งค่าโครงร่างสําคัญของบริการสามารถเรียกใช้ API ของผู้ดูแลระบบได้ การตั้งค่านี้ยังอนุญาตให้ Microsoft Purview สแกนผู้เช่า Power BI ทั้งหมดเพื่อให้สามารถใส่แค็ตตาล็อกข้อมูล

หมายเหตุ

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

การ ตอบกลับ API ของผู้ดูแลระบบขั้นสูงด้วยการตั้งค่าผู้เช่าเมตาดาต้า โดยละเอียดช่วยให้คุณสามารถตั้งค่าผู้ใช้และบริการหลักที่สามารถดึงข้อมูลเมตาดาต้าโดยละเอียดได้ เมตาดาต้าจะถูกเรียกใช้โดยใช้เมตาดาต้าที่สแกน API และรวมถึงตาราง คอลัมน์ และอื่น ๆ การตั้งค่านี้ยังอนุญาตให้ Microsoft Purview เข้าถึงข้อมูลระดับ schema เกี่ยวกับแบบจําลองความหมายของ Power BI เพื่อให้สามารถจัดเก็บไว้ในแค็ตตาล็อกข้อมูล

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

หมายเหตุ

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

API ของผู้ใช้

มีการตั้งค่าผู้เช่าหนึ่งรายการที่นําไปใช้กับการเรียกใช้ API ของผู้ใช้ ในสถานการณ์นี้ สิทธิ์ Power BI ยังจําเป็นสําหรับบริการหลัก (ตัวอย่างเช่น บทบาทพื้นที่ทํางาน)

การตั้งค่าอนุญาตให้โครงร่างสําคัญของบริการใช้ API ของ Power BI ผู้เช่าช่วยให้คุณสามารถตั้งค่าโครงร่างสําคัญของบริการที่มีสิทธิ์เข้าถึงเพื่อเรียกใช้ REST API (ยกเว้น API ของผู้ดูแลระบบ ซึ่งได้รับจากการตั้งค่าผู้เช่าอื่นตามที่อธิบายไว้ข้างต้น)

มีการตั้งค่าผู้เช่าอื่น ๆ ที่เกี่ยวข้องกับ API ซึ่งอนุญาตให้เข้าถึง API การฝัง API การสตรีม API การส่งออก API และ การดําเนินการคิวรี API อย่างไรก็ตาม API เหล่านี้อยู่นอกขอบเขตสําหรับบทความนี้

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการตั้งค่าผู้เช่าสําหรับเมตริกการใช้งาน ดู การตรวจสอบระดับรายงาน

รายการตรวจสอบ - เมื่อตั้งค่าการตั้งค่าผู้เช่า Fabric การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • ตรวจสอบว่าแต่ละบริการหลักอยู่ในกลุ่มที่ถูกต้อง : ยืนยันว่าโครงร่างสําคัญของบริการผู้ดูแลระบบ Power BI กลุ่มประกอบด้วยโครงร่างสําคัญของบริการที่ถูกต้อง
  • อัปเดตการตั้งค่าผู้เช่า API ผู้ดูแลระบบใน Power BI: เพิ่มกลุ่มความปลอดภัยไปยัง อนุญาตให้โครงร่างสําคัญของบริการใช้ API ของผู้ดูแลระบบ Power BI แบบอ่านอย่างเดียว การตั้งค่าผู้เช่า ซึ่งอนุญาตให้ใช้ API ของผู้ดูแลระบบเพื่อดึงข้อมูลเมตาดาต้าของทั้งผู้เช่า
  • อัปเดตการตั้งค่าผู้เช่าเมตาดาต้าโดยละเอียดใน Power BI: ถ้าจําเป็น ให้เพิ่มกลุ่มความปลอดภัยไปยัง ปรับปรุงการตอบกลับ API ของผู้ดูแลระบบด้วยการตั้งค่าเมตาดาต้า ผู้เช่าโดยละเอียด และการตอบกลับของ DAX และ Mash up ของผู้ดูแลระบบ การตั้งค่าผู้เช่า
  • ยืนยันว่า API ของผู้ใช้ใดจะเข้าถึงได้: ตรวจสอบว่าต้องมีผู้ใช้ API อย่างน้อยหนึ่งคนหรือมากกว่านั้น (นอกเหนือจากการใช้ API ของผู้ดูแลระบบ)
  • อัปเดตการตั้งค่าผู้เช่า API ผู้ใช้ใน Power BI: เพิ่มกลุ่มความปลอดภัยไปยัง อนุญาตให้โครงร่างสําคัญของบริการใช้ Power BI API การตั้งค่าผู้เช่า ซึ่งมีไว้สําหรับผู้ใช้ API

ระยะที่ 3: การพัฒนาและการวิเคราะห์โซลูชัน

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

ไดอะแกรมโฟลว์ที่อธิบายระยะที่ 3 ซึ่งมุ่งเน้นการพัฒนาโซลูชันและการวิเคราะห์โซลูชันการตรวจสอบระดับผู้เช่า

แยกและจัดเก็บข้อมูลดิบ

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

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

JSON แสดงออบเจ็กต์ข้อมูลที่ประกอบด้วยคู่ของแอตทริบิวต์-ค่าและอาร์เรย์ ตัวอย่างเช่น "state": "Active" เป็นตัวอย่างที่ค่าแอตทริบิวต์สถานะใช้งานอยู่ อาร์เรย์ JSON ประกอบด้วยรายการองค์ประกอบที่เรียงลําดับซึ่งคั่นด้วยเครื่องหมายจุลภาคและอยู่ในวงเล็บ ([ ]) ซึ่งเป็นเรื่องปกติที่จะค้นหาอาร์เรย์ที่ซ้อนกันในผลลัพธ์ JSON เมื่อคุณคุ้นเคยกับโครงสร้างแบบลําดับชั้นของผลลัพธ์ JSON การทําความเข้าใจโครงสร้างข้อมูลอย่างเช่น รายการ (อาร์เรย์) ของแบบจําลองความหมายในพื้นที่ทํางานจะตรงไปตรงมา

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

  • จะใช้แบบแผนการตั้งชื่อแบบใด สําหรับระบบที่ใช้ไฟล์ ข้อกําหนดการตั้งชื่อจําเป็นสําหรับไฟล์ โฟลเดอร์ และโซน data lake สําหรับฐานข้อมูล หลักทั่วไปในการตั้งชื่อจําเป็นสําหรับตารางและคอลัมน์
  • รูปแบบใดที่จะใช้ในการจัดเก็บข้อมูลดิบ? เมื่อ Power BI ยังคงแนะนําคุณลักษณะใหม่ กิจกรรมใหม่จะปรากฏขึ้นซึ่งไม่มีอยู่ในปัจจุบัน ด้วยเหตุผลนี้ เราขอแนะนําให้คุณแยกและเก็บผลลัพธ์ JSON ต้นฉบับไว้ อย่าแยกวิเคราะห์ กรอง หรือจัดรูปแบบข้อมูลขณะที่แยกออกมา ด้วยวิธีนี้ คุณสามารถใช้ข้อมูลดิบต้นฉบับเพื่อสร้างข้อมูลการตรวจสอบที่รวบรวมไว้ใหม่ได้
  • ตําแหน่งที่เก็บข้อมูลใดที่จะใช้? ที่จัดเก็บข้อมูลดิบหรือที่เก็บข้อมูล blob มักใช้เพื่อจัดเก็บข้อมูลดิบ สําหรับข้อมูลเพิ่มเติม ดู กําหนดตําแหน่งที่จะจัดเก็บข้อมูล การตรวจสอบไว้ก่อนหน้าในบทความนี้
  • คุณจะเก็บประวัติไว้มากแค่ไหน? ส่งออกข้อมูลการตรวจสอบไปยังตําแหน่งที่ตั้งที่คุณสามารถจัดเก็บประวัติได้ วางแผนที่จะสะสมประวัติอย่างน้อยสองปี ด้วยวิธีนี้ คุณสามารถวิเคราะห์แนวโน้มและการเปลี่ยนแปลงเกินระยะเวลาการเก็บรักษา 30 วันตามค่าเริ่มต้นได้ คุณอาจเลือกที่จะจัดเก็บข้อมูลอย่างไม่มีกําหนด หรือคุณอาจตัดสินใจในช่วงเวลาที่สั้นลง ทั้งนี้ขึ้นอยู่กับนโยบายการเก็บข้อมูลสําหรับองค์กรของคุณ
  • คุณจะติดตามเมื่อเรียกใช้กระบวนการล่าสุดได้อย่างไร ตั้งค่าไฟล์การกําหนดค่าหรือเทียบเท่าเพื่อบันทึกการประทับเวลาเมื่อกระบวนการเริ่มต้นและเสร็จสิ้น ในครั้งถัดไปที่กระบวนการทํางาน จะสามารถเรียกใช้การประทับเวลาเหล่านี้ได้ เป็นสิ่งสําคัญอย่างยิ่งที่คุณต้องจัดเก็บประทับเวลาเมื่อคุณดึงข้อมูลโดยใช้เมตาดาต้าที่สแกน API
  • คุณจะจัดการกับการควบคุมได้อย่างไร Power BI REST API บางตัวและ Microsoft Graph API ใช้การจํากัดผลลัพธ์ คุณจะได้รับข้อผิดพลาด 429 (คําขอมากเกินไป) ถ้าคําขอ API ของคุณถูกจํากัดปริมาณ การควบคุมอาจเป็นปัญหาทั่วไปสําหรับองค์กรขนาดใหญ่ที่จําเป็นต้องดึงข้อมูลจํานวนมาก วิธีที่คุณหลีกเลี่ยงความพยายามที่ล้มเหลวเนื่องจากการจํากัดผลลัพธ์จะขึ้นอยู่กับเทคโนโลยีที่คุณใช้ในการเข้าถึงและแยกข้อมูล ตัวเลือกหนึ่งคือการพัฒนาตรรกะในสคริปต์ของคุณที่ตอบสนองต่อข้อผิดพลาด "คําขอมากเกินไป" 429 รายการ โดยลองอีกครั้งหลังจากระยะเวลารอ
  • จําเป็นต้องมีข้อมูลการตรวจสอบเพื่อให้เป็นไปตามข้อกําหนดหรือไม่ องค์กรจํานวนมากใช้บันทึกการตรวจสอบดิบเพื่อทําการตรวจสอบการปฏิบัติตามกฎระเบียบหรือเพื่อตอบสนองต่อการตรวจสอบความปลอดภัย ในกรณีเหล่านี้ เราขอแนะนําให้คุณจัดเก็บข้อมูลดิบในพื้นที่เก็บข้อมูลที่ไม่สามารถเปลี่ยนได้ ด้วยวิธีดังกล่าว หลังจากเขียนข้อมูลแล้ว จะไม่สามารถเปลี่ยนหรือลบได้โดยผู้ดูแลระบบหรือผู้ใช้อื่น
  • เลเยอร์พื้นที่เก็บข้อมูลใดที่จําเป็นในการสนับสนุนข้อกําหนดของคุณ? สถานที่ที่ดีที่สุดในการจัดเก็บข้อมูลดิบคือที่จัดเก็บข้อมูลดิบ (เช่น Azure Data Lake Storage รุ่น2) หรือที่เก็บข้อมูลวัตถุ (เช่น Azure Blob Storage) ระบบไฟล์ยังสามารถใช้ได้หากบริการคลาวด์ไม่ใช่ตัวเลือก

รายการตรวจสอบ - เมื่อแยกและจัดเก็บข้อมูลดิบ การตัดสินใจและการดําเนินการที่สําคัญรวมถึง:

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

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

สร้างข้อมูลที่รวบรวม

ณ จุดนี้ ข้อมูลดิบจะถูกแยกและจัดเก็บไว้ ขั้นตอนถัดไปคือการสร้างเลเยอร์ข้อมูลทองคําที่แยกต่างหากสําหรับข้อมูลที่รวบรวม เป้าหมายของการแปลงและจัดเก็บไฟล์ข้อมูลในโครงสร้างข้อมูลแบบดาว สคีมาแบบดาวประกอบด้วยตารางมิติและตารางข้อเท็จจริง และได้รับการปรับให้เหมาะสมโดยตั้งใจสําหรับการวิเคราะห์และการรายงาน ไฟล์ในเลเยอร์ข้อมูลที่รวบรวมจะกลายเป็นแหล่งข้อมูลของแบบจําลองข้อมูล Power BI (อธิบายไว้ในหัวข้อถัดไป)

เคล็ดลับ

เมื่อคุณคาดว่าจะมีแบบจําลองข้อมูลมากกว่าหนึ่งรูปแบบ การลงทุนในเลเยอร์ข้อมูลที่รวบรวมแบบรวมศูนย์จะมีประโยชน์อย่างยิ่ง

รายการตรวจสอบ - เมื่อสร้างเลเยอร์ข้อมูลที่รวบรวม การตัดสินใจและการดําเนินการที่สําคัญรวมถึง:

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

สร้างแบบจําลองข้อมูล

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

ในบริบทของการตรวจสอบและตรวจสอบ แหล่งข้อมูลแบบจําลองข้อมูลจากเลเยอร์ข้อมูล (ทอง) ที่รวบรวมไว้ หากคุณเลือกที่จะไม่สร้างเลเยอร์ข้อมูลที่รวบรวมไว้ แหล่งข้อมูลของแบบจําลองข้อมูลนั้นโดยตรงจากข้อมูลดิบ

เราขอแนะนําให้แบบจําลองข้อมูล Power BI ของคุณออกแบบ Schema รูปดาว เมื่อข้อมูลต้นทางเป็นเลเยอร์ข้อมูลที่มีการรวบรวม Schema รูปดาวแบบจําลองข้อมูล Power BI ควรสะท้อน Schema รูปดาวของชั้นข้อมูลที่มีการรวบรวม

เคล็ดลับ

สําหรับภาพรวมของการออกแบบแบบจําลองข้อมูลรูปดาว โปรดดู ทําความเข้าใจโครงสร้างรูปดาวและความสําคัญสําหรับ Power BI

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

นี่คือตารางมิติข้อมูลที่มีประโยชน์บางส่วนที่คุณสามารถรวมไว้ในแบบจําลองข้อมูลได้

  • วันที่: ชุดของแอตทริบิวต์วันที่เพื่อเปิดใช้งานการวิเคราะห์ (การแบ่งส่วนและการแบ่งส่วนข้อมูล) ตามวัน สัปดาห์ เดือน ไตรมาส ปี และช่วงเวลาที่เกี่ยวข้องอื่น ๆ
  • Time: หากคุณต้องการวิเคราะห์ตามช่วงเวลาและคุณมีข้อมูลการตรวจสอบจํานวนมาก ให้พิจารณาจัดเก็บส่วนเวลาแยกต่างหากจากวันที่ วิธีการนี้สามารถช่วยปรับปรุงประสิทธิภาพการทํางานของคิวรีได้
  • ผู้ใช้: แอตทริบิวต์ที่อธิบายผู้ใช้ (เช่น แผนกและภูมิภาคทางภูมิศาสตร์) ที่สามารถกรองชื่อเรื่องของข้อมูลการตรวจสอบได้มากมาย เป้าหมายคือการลบรายละเอียดผู้ใช้ทั้งหมดออกจากตารางข้อเท็จจริงและจัดเก็บไว้ในตารางมิตินี้เพื่อให้พวกเขาสามารถกรองตารางข้อเท็จจริงจํานวนมากได้ คุณยังสามารถจัดเก็บบริการหลักในตารางนี้ได้
  • เหตุการณ์กิจกรรม: แอตทริบิวต์ที่จัดกลุ่มและอธิบายเหตุการณ์กิจกรรม (การดําเนินการ) เพื่อปรับปรุงการรายงานของคุณ คุณอาจสร้างพจนานุกรมข้อมูลที่อธิบายแต่ละเหตุการณ์กิจกรรม นอกจากนี้ คุณยังอาจสร้างลําดับชั้นที่จัดกลุ่มและจัดประเภทเหตุการณ์กิจกรรมที่คล้ายกัน ตัวอย่างเช่น คุณอาจจัดกลุ่มเหตุการณ์การสร้างรายการทั้งหมด ลบเหตุการณ์ และอื่น ๆ
  • พื้นที่ทํางาน: รายการของพื้นที่ทํางานในคุณสมบัติผู้เช่าและพื้นที่ทํางาน เช่น ชนิด (ส่วนบุคคลหรือมาตรฐาน) และคําอธิบาย บางองค์กรบันทึกรายละเอียดเพิ่มเติมเกี่ยวกับพื้นที่ทํางาน (อาจใช้รายการ SharePoint) คุณสามารถรวมรายละเอียดเหล่านี้ลงในตารางมิตินี้ได้ คุณจําเป็นต้องตัดสินใจว่าตารางสําหรับจัดเก็บข้อมูลสําหรับมิติข้อมูลนี้จัดเก็บเฉพาะสถานะปัจจุบันของพื้นที่ทํางานหรือจะจัดเก็บข้อมูลที่มีการกําหนดเวอร์ชันซึ่งสะท้อนการเปลี่ยนแปลงพื้นที่ทํางานที่สําคัญเมื่อเวลาผ่านไปหรือไม่ ตัวอย่างเช่น เมื่อชื่อพื้นที่ทํางานเปลี่ยนชื่อ การรายงานในอดีตแสดงชื่อพื้นที่ทํางานปัจจุบันหรือชื่อพื้นที่ทํางานที่เป็นปัจจุบันในเวลานั้นหรือไม่ สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการกําหนดเวอร์ชัน โปรดดู การเปลี่ยนมิติอย่างช้าๆ
  • ชนิดหน่วยข้อมูล: รายการของชนิดหน่วยข้อมูล Power BI (แบบจําลองความหมาย รายงาน และอื่น ๆ)
  • ความจุ: รายการของความจุแบบพรีเมียมในผู้เช่า
  • เกตเวย์ : รายการของเกตเวย์ข้อมูลในผู้เช่า
  • แหล่งข้อมูล: รายการของแหล่งข้อมูลที่ใช้โดยแบบจําลองความหมาย กระแสข้อมูล หรือ datamart

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

  • กิจกรรมของผู้ใช้: ข้อมูลข้อเท็จจริงที่มาจากข้อมูล JSON ต้นฉบับ แอตทริบิวต์ใดๆ ที่ไม่มีค่าการวิเคราะห์จะถูกลบออก แอตทริบิวต์ใด ๆ ที่อยู่ในตารางมิติ (ด้านบน) จะถูกลบออกเช่นกัน
  • สินค้าคงคลังของผู้เช่า: สแนปช็อตแบบจุดต่อเวลาของรายการทั้งหมดที่เผยแพร่ในผู้เช่า สําหรับข้อมูลเพิ่มเติม ดู สินค้าคงคลัง ของผู้เช่า ก่อนหน้าในบทความนี้
  • แบบจําลองความหมาย: รวมกิจกรรมของผู้ใช้ที่เกี่ยวข้องกับแบบจําลองความหมาย (เช่น การเปลี่ยนแปลงแบบจําลองความหมาย) หรือแหล่งข้อมูลที่เกี่ยวข้อง
  • แบบจําลองความหมายจะรีเฟรช: จัดเก็บการดําเนินการรีเฟรชข้อมูล รวมถึงรายละเอียดเกี่ยวกับชนิด (ตามกําหนดการหรือตามคําขอ) ระยะเวลา สถานะ และผู้ใช้ที่เริ่มต้นการดําเนินการ
  • บทบาทพื้นที่ทํางาน: สแนปช็อตแบบจุดต่อเวลาของการกําหนดบทบาทพื้นที่ทํางาน
  • สิทธิ์การใช้งานของผู้ใช้: สแนปช็อตแบบจุดต่อเวลาของสิทธิการใช้งานของผู้ใช้ แม้ว่าคุณอาจถูกชักจูงให้จัดเก็บสิทธิ์การใช้งาน ของผู้ใช้ในตารางมิติผู้ใช้ แต่วิธีการดังกล่าวจะไม่สนับสนุนการวิเคราะห์การเปลี่ยนแปลงสิทธิ์การใช้งานและแนวโน้มเมื่อเวลาผ่านไป
  • สมาชิกกลุ่มผู้ใช้: สแนปช็อตแบบจุดต่อเวลาของผู้ใช้ (และบริการหลัก) ที่กําหนดให้กับกลุ่มความปลอดภัย
  • กิจกรรมชุมชน: รวมข้อเท็จจริงที่เกี่ยวข้องกับชุมชน เช่น กิจกรรมการฝึกอบรม ตัวอย่างเช่น คุณสามารถวิเคราะห์กิจกรรมของผู้ใช้ Power BI เมื่อเทียบกับการเข้าร่วมการฝึกอบรม ข้อมูลนี้สามารถช่วยให้ศูนย์แห่งความเป็นเลิศสามารถระบุผู้สนับสนุนใหม่ที่มีศักยภาพได้

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

ตัวอย่างเช่น ตารางมิติผู้ใช้ จะเกี่ยวข้องกับตารางข้อเท็จจริงทุกตาราง ซึ่งควรเกี่ยวข้องกับตารางข้อเท็จจริงกิจกรรมของผู้ใช้ (ผู้ดําเนินการกิจกรรม) ตารางข้อเท็จจริงของผู้เช่าสินค้าคงคลัง (ผู้ที่สร้างรายการที่เผยแพร่) และตารางข้อเท็จจริงอื่น ๆ ทั้งหมด เมื่อรายงานกรองโดยผู้ใช้ ในตารางมิติผู้ใช้ วิชวลในรายงานนั้นสามารถแสดงข้อเท็จจริงสําหรับผู้ใช้รายนั้นจากตารางข้อเท็จจริงใด ๆ ที่เกี่ยวข้อง

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

เราขอแนะนําให้คุณสร้างแบบจําลองข้อมูลของคุณแยกต่างหากจากรายงาน การแยกส่วนของแบบจําลองความหมายและรายงานมีผลในแบบจําลองความหมายแบบรวมศูนย์ที่สามารถให้บริการรายงานจํานวนมาก สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการใช้แบบจําลองความหมายที่ใช้ร่วมกัน ให้ดู สถานการณ์การใช้งาน BI แบบบริการตนเองที่มีการจัดการ

พิจารณาการตั้งค่า ความปลอดภัย ระดับแถว (RLS) เพื่อให้ผู้ใช้รายอื่นนอกเหนือจาก Center of Excellence ผู้ตรวจสอบ และผู้ดูแลระบบสามารถวิเคราะห์และรายงานเกี่ยวกับข้อมูลการตรวจสอบได้ ตัวอย่างเช่น คุณสามารถใช้กฎ RLS เพื่ออนุญาตให้ผู้สร้างเนื้อหาและผู้บริโภครายงานเกี่ยวกับกิจกรรมของผู้ใช้หรือความพยายามในการพัฒนาของตนเองได้

รายการตรวจสอบ - เมื่อสร้างแบบจําลองข้อมูล การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

ปรับปรุงแบบจําลองข้อมูล

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

สร้างการจัดประเภท

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

คุณอาจเลือกที่จะจัดประเภท ผู้ใช้ ตามระดับการใช้งานหรือจัดประเภท เนื้อหา ตามระดับการใช้งาน

การจัดประเภทการใช้งานของผู้ใช้

พิจารณาการจัดประเภทต่อไปนี้สําหรับการใช้งานของผู้ใช้

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

เคล็ดลับ

การทราบว่าผู้ใช้เป็นครั้งคราวหรือไม่ใช้งานจะเป็นประโยชน์โดยเฉพาะอย่างยิ่งเมื่อพวกเขามีสิทธิการใช้งาน Pro หรือ PPU (ซึ่งเกี่ยวข้องกับค่าใช้จ่าย) นอกจากนี้ยังเป็นประโยชน์ในการทราบว่าผู้ใช้ที่คุณใช้งานบ่อยและบ่อยที่สุดคือใคร ลองเชิญพวกเขาเข้าร่วมเวลาทําการหรือเข้าร่วมการฝึกอบรม ผู้สร้างเนื้อหาที่ใช้งานมากที่สุดของคุณอาจเป็นผู้สมัครที่จะเข้าร่วมเครือข่ายแชมเปี้ยนของคุณ

การจัดประเภทการใช้งานเนื้อหา

พิจารณาการจัดประเภทต่อไปนี้สําหรับการใช้งานเนื้อหา

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

พิจารณาการจัดประเภทต่อไปนี้สําหรับ ชนิดผู้ใช้

  • ผู้สร้างเนื้อหา : กิจกรรมที่บันทึกไว้ในช่วงหกเดือนที่ผ่านมาที่สร้าง เผยแพร่ หรือแก้ไขเนื้อหา
  • ผู้ชมเนื้อหา : กิจกรรมที่บันทึกไว้ในหกเดือนที่ผ่านมาที่ดูเนื้อหา แต่ไม่มีกิจกรรมการสร้างเนื้อหาใด ๆ

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

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

  • ผู้จัดการดูรายงานหนึ่งฉบับในสัปดาห์นี้ อย่างไรก็ตาม ก่อนสัปดาห์นั้น ผู้จัดการยังไม่เคยดูรายงานใดๆ ในช่วงหกเดือนที่ผ่านมา คุณไม่ควรพิจารณาให้ผู้จัดการรายนี้เป็นผู้ใช้งานบ่อยโดยยึดตามการใช้งานล่าสุดเพียงอย่างเดียว
  • ผู้สร้างรายงานเผยแพร่รายงานใหม่ทุกสัปดาห์ เมื่อคุณวิเคราะห์การใช้งานโดยผู้ใช้บ่อย กิจกรรมปกติของผู้สร้างรายงานจะปรากฏเป็นบวก อย่างไรก็ตาม เมื่อมีการตรวจสอบเพิ่มเติม คุณพบว่าผู้ใช้รายนี้ได้รับการเผยแพร่รายงานใหม่ (ด้วยชื่อรายงานใหม่) ทุกครั้งที่พวกเขาแก้ไขรายงาน ซึ่งจะเป็นประโยชน์สําหรับผู้สร้างรายงานที่จะมีการฝึกอบรมเพิ่มเติม
  • ผู้บริหารจะดูรายงานเป็นระยะ ๆ ดังนั้นการจัดประเภทการใช้งานของพวกเขาจึงมีการเปลี่ยนแปลงบ่อย คุณอาจจําเป็นต้องวิเคราะห์ผู้ใช้บางประเภท เช่น ผู้บริหาร แตกต่างกัน
  • ผู้ตรวจสอบภายในจะดูรายงานที่สําคัญหนึ่งครั้งต่อปี ผู้ตรวจสอบภายในอาจดูเหมือนเป็นผู้ใช้ที่ไม่ได้ใช้งานเนื่องจากการใช้งานไม่บ่อยนัก อาจมีคนทําตามขั้นตอนในการลบสิทธิ์การใช้งาน Pro หรือ PPU ของพวกเขา หรือบางคนอาจเชื่อว่าควรเลิกใช้รายงานเนื่องจากมีการใช้งานไม่บ่อยนัก

เคล็ดลับ

คุณสามารถคํานวณค่าเฉลี่ยและแนวโน้มได้โดยใช้ฟังก์ชันตัวแสดงเวลาของ DAX หากต้องการเรียนรู้วิธีการใช้ฟังก์ชันเหล่านี้ ให้ทํางานผ่าน โมดูลการเรียนรู้ ใช้ฟังก์ชันตัวแสดงเวลาของ DAX ในแบบจําลอง Power BI Desktop

รายการตรวจสอบ – เมื่อสร้างการจําแนกประเภทข้อมูลการใช้งาน การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

สร้างรายงานการวิเคราะห์

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

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

  • ผู้สนับสนุนระดับผู้บริหาร
  • ศูนย์แห่งความเป็นเลิศ
  • ผู้ดูแลระบบ Power BI
  • ผู้ดูแลระบบพื้นที่ทํางาน
  • ผู้ดูแลระบบความจุพรีเมียม
  • ผู้ดูแลระบบเกตเวย์
  • นักพัฒนา Power BI และผู้สร้างเนื้อหา
  • ผู้ตรวจสอบ

นี่คือข้อกําหนดการวิเคราะห์ที่พบบ่อยที่สุดที่คุณอาจต้องการเริ่มต้นด้วยเมื่อคุณสร้างรายงานการตรวจสอบของคุณ

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

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

เคล็ดลับ

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

เมื่อต้องการเรียนรู้วิธีการสร้างรายงานการวิเคราะห์ ให้ทํางานผ่านรายงานที่มีประสิทธิภาพการออกแบบในเส้นทางการเรียนรู้ Power BI

รายการตรวจสอบ - เมื่อวางแผนสําหรับรายงานการตรวจสอบการวิเคราะห์ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

ดําเนินการตามข้อมูล

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

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

การใช้เนื้อหา

ต่อไปนี้คือการดําเนินการบางอย่างที่คุณอาจดําเนินการตามวิธีการใช้เนื้อหา

  • เนื้อหามักจะถูกใช้บ่อย (รายวัน หรือรายสัปดาห์): ตรวจสอบว่าเนื้อหาที่สําคัญใด ๆ ได้รับการรับรอง ยืนยันว่าความเป็นเจ้าของนั้นชัดเจนและโซลูชันได้รับการสนับสนุนอย่างเพียงพอ
  • จํานวนการเข้าชมพื้นที่ทํางานสูง: เมื่อมีมุมมองพื้นที่ทํางานจํานวนมากเกิดขึ้น ให้ตรวจสอบสาเหตุที่แอป Power BI ไม่สามารถใช้งานได้
  • เนื้อหาจะไม่ค่อยถูกใช้: ติดต่อผู้ใช้เป้าหมายเพื่อตรวจสอบว่าโซลูชันตรงกับความต้องการของพวกเขาหรือไม่ หรือข้อกําหนดของพวกเขามีการเปลี่ยนแปลงหรือไม่
  • กิจกรรมรีเฟรชเกิดขึ้นบ่อยกว่าการดู: ติดต่อเจ้าของเนื้อหาเพื่อทําความเข้าใจว่าทําไมแบบจําลองความหมายจึงได้รับการรีเฟรชเป็นประจําโดยไม่ต้องใช้แบบจําลองความหมายหรือรายงานที่เกี่ยวข้องเมื่อเร็ว ๆ นี้

กิจกรรมของผู้ใช้

ต่อไปนี้เป็นการดําเนินการบางอย่างที่คุณอาจดําเนินการตามกิจกรรมของผู้ใช้

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

โอกาสในการฝึกอบรมผู้ใช้

นี่คือโอกาสการฝึกอบรมผู้ใช้บางส่วนที่คุณอาจระบุจากข้อมูลการตรวจสอบ

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

เคล็ดลับ

นอกจากนี้คุณยังสามารถปรับปรุงเนื้อหาหรือเอกสารการฝึกอบรมของคุณได้โดยการตรวจสอบคําถามที่ตอบคําถามโดยชุมชน Power BI ภายในของคุณและประเด็นที่ส่งไปยังแผนกให้ความช่วยเหลือ

ความปลอดภัย

ต่อไปนี้คือสถานการณ์ด้านความปลอดภัยบางอย่างที่คุณอาจต้องการตรวจสอบอย่างแข็งขัน

  • มีผู้ใช้จํานวนมากเกินไปที่กําหนดให้กับบทบาทผู้ดูแลระบบ Fabric ที่มีสิทธิพิเศษสูง
  • ผู้ดูแลระบบพื้นที่ทํางานมากเกินไป (เมื่อสมาชิก ผู้สนับสนุน หรือผู้ชม บทบาท พื้นที่ทํางานเพียงพอ)
  • สิทธิ์ในการสร้างที่มากเกินไปที่กําหนดให้กับแบบจําลองความหมาย (เมื่อสิทธิ์ในการอ่านเพียงพอ)
  • การใช้ สิทธิ์ต่อรายการสูง เมื่อ สิทธิ์ ของแอป Power BI หรือ บทบาท ผู้ชมพื้นที่ทํางานจะเป็นตัวเลือกที่ดีกว่าสําหรับผู้ใช้เนื้อหา
  • วิธีแชร์เนื้อหากับ ผู้ใช้ภายนอก

สําหรับข้อมูลเพิ่มเติม ให้ดู บทความการวางแผน ความปลอดภัย

การกํากับดูแลและการลดความเสี่ยง

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

  • จํานวนการเข้าชมสูงสําหรับรายงาน (และแบบจําลองความหมายพื้นฐาน) ที่ไม่ได้รับรอง
  • การใช้แหล่งข้อมูลที่ไม่รู้จักหรือไม่ได้สวดมนต์ที่สําคัญ
  • ตําแหน่งที่ตั้งไฟล์ที่ไม่สอดคล้องกับแนวทางการกํากับดูแลสําหรับตําแหน่งที่ควรอยู่ไฟล์ต้นฉบับ
  • ชื่อ พื้นที่ทํางานไม่สอดคล้องกับข้อกําหนดการกํากับดูแล
  • ป้ายชื่อระดับความลับใช้สําหรับ การป้องกันข้อมูล
  • การรีเฟรชข้อมูลที่สอดคล้องกันล้มเหลว
  • การใช้การพิมพ์ที่สําคัญและเกิดขึ้นประจํา
  • การสมัครใช้งานที่ไม่คาดคิดหรือมากเกินไป
  • การใช้ เกตเวย์ส่วนบุคคลที่ไม่คาดคิด

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

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

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

ระยะที่ 4: บํารุงรักษา ปรับปรุง และตรวจสอบ

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

ไดอะแกรมโฟลว์ที่อธิบายขั้นตอนที่ 4 ซึ่งมุ่งเน้นไปที่การบํารุงรักษา การปรับปรุง และการตรวจสอบโซลูชันการตรวจสอบระดับผู้เช่า

ใช้งานและปรับปรุง

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

กระบวนการตรวจสอบระดับการผลิตได้รับ การดําเนินการแล้ว โดยทั่วไปโซลูชันที่ใช้งานได้นั้นมีลักษณะดังต่อไปนี้

  • Secure: ข้อมูลประจําตัวถูกจัดเก็บและจัดการได้อย่างปลอดภัย สคริปต์ไม่มีรหัสผ่านหรือคีย์ในข้อความธรรมดา
  • จัดกําหนดการ: มีระบบจัดกําหนดการที่เชื่อถือได้
  • การจัดการการเปลี่ยนแปลง : ใช้แนวทางการจัดการการเปลี่ยนแปลงและสภาพแวดล้อมหลายรายการเพื่อให้แน่ใจว่าสภาพแวดล้อมการผลิตได้รับการปกป้อง นอกจากนี้ คุณอาจทํางานกับสภาพแวดล้อมการพัฒนาและการทดสอบ หรือเพียงแค่สภาพแวดล้อมการพัฒนา
  • สนับสนุน: มีการกําหนดทีมที่สนับสนุนโซลูชันอย่างชัดเจน สมาชิกในทีมได้รับการฝึกฝนและเข้าใจความคาดหวังในการดําเนินงาน มีการระบุสมาชิกสํารองและการฝึกอบรมข้ามเกิดขึ้นเมื่อเหมาะสม
  • การแจ้งเตือน : เมื่อมีบางอย่างผิดพลาดเกิดขึ้น การแจ้งเตือนจะแจ้งให้ทีมสนับสนุนทราบโดยอัตโนมัติ การแจ้งเตือนมีทั้งบันทึกและอีเมล (แทนที่จะเป็นอีเมลเท่านั้น) บันทึกมีประโยชน์สําหรับการวิเคราะห์ข้อผิดพลาดและคําเตือนในการบันทึก
  • บันทึก: กระบวนการจะถูกบันทึกเพื่อให้มีประวัติเมื่อมีการอัปเดตข้อมูลการตรวจสอบ ข้อมูลที่บันทึกควรบันทึกเวลาเริ่มต้น เวลาสิ้นสุด และข้อมูลประจําตัวของผู้ใช้หรือแอปที่เรียกใช้กระบวนการ
  • จัดการข้อผิดพลาด: สคริปต์และกระบวนการจัดการและบันทึกข้อผิดพลาดอย่างนุ่มนวล (เช่น จะออกจากระบบทันที ดําเนินการต่อ หรือรอและลองอีกครั้ง) การแจ้งเตือนจะถูกส่งไปยังทีมสนับสนุนเมื่อเกิดข้อผิดพลาด
  • มาตรฐานการเข้ารหัส : เทคนิคการเขียนโค้ดที่ดีที่ใช้งานได้ดี ตัวอย่างเช่น รอบ จะหลีกเลี่ยงอย่างมีวัตถุประสงค์ยกเว้นเมื่อจําเป็น มีการใช้มาตรฐานการเข้ารหัส ข้อคิดเห็น การจัดรูปแบบ และไวยากรณ์ที่สอดคล้องกันเพื่อให้ง่ายต่อการบํารุงรักษาและสนับสนุนโซลูชัน
  • นํากลับมาใช้ใหม่และ modularization: เพื่อลดการทําซ้ํา โค้ดและค่าการกําหนดค่า (เช่น สตริงการเชื่อมต่อหรือที่อยู่อีเมลสําหรับการแจ้งเตือน) จะถูกแยกประเภทเพื่อให้สคริปต์และกระบวนการอื่น ๆ สามารถนํากลับมาใช้ใหม่ได้

เคล็ดลับ

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

รายการตรวจสอบ - เมื่อวางแผนที่จะดําเนินการและปรับปรุงโซลูชันการตรวจสอบ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

เอกสารประกอบและการสนับสนุน

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

เอกสารทางเทคนิค

เอกสารทางเทคนิคมีเป้าหมายที่ทีมเทคนิคที่สร้างโซลูชันและผู้ที่จะค่อยๆปรับปรุงและขยายโซลูชันเมื่อเวลาผ่านไป นอกจากนี้ยังเป็นแหล่งข้อมูลที่มีประโยชน์สําหรับทีมสนับสนุน

เอกสารทางเทคนิคควรประกอบด้วย:

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

เอกสารประกอบการสนับสนุน

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

เอกสารประกอบการสนับสนุนบางครั้งเรียกว่าฐานความรู้หรือ runbook เอกสารนี้มุ่งเน้นที่ฝ่ายช่วยเหลือหรือทีมสนับสนุนของคุณ และควรประกอบด้วย:

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

เอกสารผู้สร้างเนื้อหา

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

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

รายการ ตรวจสอบ – เมื่อมีการวางแผนจัดทําเอกสารและการสนับสนุนสําหรับโซลูชันการตรวจสอบของคุณ การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

  • ยืนยันว่าใครคาดว่าจะสนับสนุนโซลูชัน : กําหนดว่าใครจะสนับสนุนโซลูชันการตรวจสอบที่ถือว่าเป็นระดับการผลิต (หรือมีการขึ้นต่อกันของรายงานปลายทาง)
  • ตรวจสอบให้แน่ใจว่าการสนับสนุนความพร้อมของทีม: ตรวจสอบว่าทีมสนับสนุนได้รับการเตรียมพร้อมเพื่อสนับสนุนโซลูชันการตรวจสอบ ระบุว่ามีช่องว่างของความพร้อมใด ๆ ที่จําเป็นในการจัดการหรือไม่
  • เตรียมความพร้อมสําหรับการฝึกอบรมข้าม : ดําเนินการถ่ายทอดความรู้หรือเซสชันการฝึกอบรมข้ามสําหรับทีมสนับสนุน
  • ชี้แจงความคาดหวังของทีมสนับสนุน: ตรวจสอบให้แน่ใจว่าความคาดหวังสําหรับการตอบสนองและการแก้ปัญหาได้รับการบันทึกและสื่อสารอย่างชัดเจน ตัดสินใจว่าทุกคนจําเป็นต้องโทรออกเพื่อแก้ไขปัญหาที่เกี่ยวข้องกับโซลูชันการตรวจสอบอย่างรวดเร็วหรือไม่
  • สร้างเอกสารทางเทคนิค: สร้างเอกสารประกอบเกี่ยวกับสถาปัตยกรรมทางเทคนิคและการตัดสินใจในการออกแบบ
  • สร้างเอกสารประกอบการสนับสนุน: อัปเดตฐานข้อมูลความรู้ help desk เพื่อรวมข้อมูลเกี่ยวกับวิธีการสนับสนุนโซลูชัน
  • สร้างเอกสารสําหรับผู้สร้างเนื้อหา: สร้างเอกสารเพื่อช่วยผู้สร้างแบบบริการตนเองใช้แบบจําลองข้อมูล อธิบายข้อกําหนดข้อมูลทั่วไปเพื่อปรับปรุงความสอดคล้องของการใช้งาน

เปิดใช้งานการแจ้งเตือน

คุณอาจต้องการแสดงการแจ้งเตือนตามเงื่อนไขเฉพาะในข้อมูลการตรวจสอบ ตัวอย่างเช่น คุณสามารถแจ้งเตือนเมื่อมีคนลบเกตเวย์ หรือเมื่อผู้ดูแลระบบ Power BI เปลี่ยนแปลงการตั้งค่าผู้เช่า

สําหรับข้อมูลเพิ่มเติม ให้ดู การตรวจสอบระดับผู้เช่า

การจัดการอย่างต่อเนื่อง

คุณจําเป็นต้องดําเนินการจัดการอย่างต่อเนื่องของโซลูชันการตรวจสอบทั้งหมด คุณอาจจําเป็นต้องขยายหรือเปลี่ยนแปลงโซลูชันการตรวจสอบของคุณเมื่อ:

  • องค์กรค้นพบข้อกําหนดของข้อมูลใหม่
  • เหตุการณ์การตรวจสอบใหม่จะปรากฏในข้อมูลดิบที่คุณทําจาก Power BI REST API
  • Microsoft ทําการเปลี่ยนแปลง Power BI REST API
  • พนักงานระบุวิธีในการปรับปรุงโซลูชัน

สำคัญ

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

รายการตรวจสอบ - เมื่อวางแผนสําหรับการจัดการโซลูชันการตรวจสอบอย่างต่อเนื่อง การตัดสินใจและการดําเนินการที่สําคัญประกอบด้วย:

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

เนื้อหาที่เกี่ยวข้อง

ใน บทความถัดไปในชุดนี้ เรียนรู้เกี่ยวกับการตรวจสอบระดับผู้เช่า