แชร์ผ่าน


เอกสารทางเทคนิคเรื่องความปลอดภัยของ Power BI

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

ผู้เขียน: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sidyadevan, Sidyadevan, โรนัลด์ ช้าง, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay Yariv Maimon, Crivat บูกดาน

ผู้ตรวจสอบทางเทคนิค: คริสเตียน ปิโตเลสคู, Amir Netz, Sergei Gundorov

นําไปใช้กับ: Power BI SaaS, Power BI Desktop, Power BI Premium, การวิเคราะห์ Power BI Embedded, Power BI บนมือถือ

หมายเหตุ

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

บทนำ

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

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

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

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

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

ทุกอย่างเริ่มต้นจากรากฐาน หลังจากช่วงเวลาที่ไม่คร่าวๆในช่วงต้นปี 2000, Microsoft ลงทุนอย่างมากเพื่อจัดการกับช่องโหว่ด้านความปลอดภัยและในหลายทศวรรษต่อมาสร้างสแต็คความปลอดภัยที่แข็งแกร่งซึ่งจะลึกลงไปลึกถึงเคอร์เนล BIOS บนชิปและขยายประสบการณ์การใช้งานของผู้ใช้ทั้งหมด การลงทุนอย่างลึกซึ้งเหล่านี้ยังคงดําเนินต่อไป และวันนี้วิศวกรของ Microsoft มากกว่า 3,500 คนมีส่วนร่วมในการสร้างและปรับปรุงสแต็คความปลอดภัยของ Microsoft และจัดการกับภูมิทัศน์ภัยคุกคามที่เปลี่ยนแปลงตลอดเวลา ด้วยคอมพิวเตอร์นับพันล้านคนการเข้าสู่ระบบและ zettabytes ของข้อมูลที่นับไม่ถ้วนที่มอบหมายให้กับการคุ้มครองของ Microsoft บริษัท ตอนนี้มีกองซ้อนความปลอดภัยขั้นสูงที่สุดในอุตสาหกรรมเทคโนโลยีและมองว่าเป็นผู้นําทางระดับโลกในการต่อสู้กับนักแสดงที่เป็นอันตราย

Power BI สร้างขึ้นจากพื้นฐานที่แข็งแกร่งนี้ ใช้สแต็คความปลอดภัยเดียวกันกับที่ได้รับสิทธิ์ของ Azure ในการให้บริการและปกป้องข้อมูลที่ละเอียดอ่อนที่สุดในโลก และรวมกับเครื่องมือการปกป้องข้อมูลและการปฏิบัติตามข้อบังคับที่ทันสมัยที่สุดของ Microsoft 365 นอกจากนี้ ยังมอบความปลอดภัยผ่านมาตรการรักษาความปลอดภัยแบบหลายชั้น ซึ่งส่งผลให้การปกป้องแบบครบวงจรออกแบบมาเพื่อจัดการกับความท้าทายเฉพาะของยุคคลาวด์

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

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

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

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

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

สถาปัตยกรรมของ Power BI

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

WFE และ Back End

คลัสเตอร์เว็บ front-end (WFE)

คลัสเตอร์ WFE ให้เบราว์เซอร์ของผู้ใช้มีเนื้อหาหน้า HTML เริ่มต้นในการโหลดไซต์ และตัวชี้ไปยังเนื้อหา CDN ที่ใช้ในการแสดงไซต์ในเบราว์เซอร์

คลัสเตอร์ WEF

คลัสเตอร์ WFE ประกอบด้วยเว็บไซต์ ASP.NET ที่ทํางานอยู่ในสภาพแวดล้อมของบริการแอป Azure เมื่อผู้ใช้พยายามเชื่อมต่อกับบริการของ Power BI บริการ DNS ของไคลเอ็นต์อาจสื่อสารกับ Azure Traffic Manager เพื่อค้นหาศูนย์ข้อมูลที่เหมาะสมที่สุด (มักใกล้เคียงที่สุด) กับการปรับใช้ Power BI สําหรับข้อมูลเพิ่มเติมเกี่ยวกับกระบวนการนี้ ดูวิธีการกําหนดเส้นทางการรับส่งข้อมูลประสิทธิภาพสําหรับ Azure Traffic Manager

แหล่งข้อมูลแบบคงที่ เช่น *.js, *.css และไฟล์รูปภาพส่วนใหญ่จะถูกจัดเก็บไว้บนเครือข่ายจัดส่งเนื้อหา Azure (CDN) และเรียกใช้โดยตรงโดยเบราว์เซอร์ โปรดทราบว่า การปรับใช้คลัสเตอร์ Sovereign Government เป็นข้อยกเว้นสําหรับกฎนี้ และด้วยเหตุผลการปฏิบัติตามกฎระเบียบจะไม่ใช้ CDN และใช้คลัสเตอร์ WFE จากภูมิภาคที่สอดคล้องสําหรับการโฮสต์เนื้อหาแบบคงที่แทน

คลัสเตอร์ Back-end ของ Power BI (BE)

คลัสเตอร์ back-end เป็นแกนหลักของฟังก์ชันการทํางานทั้งหมดที่พร้อมใช้งานใน Power BI ซึ่งประกอบด้วยจุดสิ้นสุดบริการหลายจุดที่ใช้โดยไคลเอ็นต์ Web Front End และ API ตลอดจนบริการการทํางานพื้นหลัง ฐานข้อมูล แคช และคอมโพเนนต์อื่น ๆ

ส่วนหลังมีให้บริการในภูมิภาค Azure ส่วนใหญ่ และมีการปรับใช้ในภูมิภาคใหม่เมื่อพร้อมใช้งาน ภูมิภาค Azure เดียวโฮสต์คลัสเตอร์ back-end หนึ่งตัวหรือมากกว่าที่อนุญาตให้ปรับมาตราส่วนของบริการของ Power BI แนวนอนไม่จํากัดเมื่อขีดจํากัดการปรับมาตราส่วนแนวตั้งและแนวนอนของคลัสเตอร์เดียวหมดลง

คลัสเตอร์ back-end แต่ละคลัสเตอร์จะ stateful และโฮสต์ข้อมูลทั้งหมดของผู้เช่าทั้งหมดที่กําหนดให้กับคลัสเตอร์นั้น คลัสเตอร์ที่ประกอบด้วยข้อมูลของผู้เช่าเฉพาะจะเรียกว่าคลัสเตอร์บ้านของผู้เช่า บริการส่วนกลาง และใช้โดย Web Front End เพื่อกําหนดเส้นทางการร้องขอไปยังคลัสเตอร์หน้าแรกของผู้เช่า

คลัสเตอร์ back-end แต่ละตัวประกอบด้วยเครื่องเสมือนหลายเครื่องที่รวมเป็นชุดสเกลแบบปรับขนาดได้หลายชุดที่ปรับแต่งสําหรับการทํางานเฉพาะทรัพยากรที่เฉพาะเจาะจง เช่น ฐานข้อมูล SQL, บัญชีเก็บข้อมูล, บัสบริการ, แคช และคอมโพเนนต์คลาวด์ที่จําเป็นอื่น ๆ

เมตาดาต้าผู้เช่าและข้อมูลจะถูกจัดเก็บไว้ภายในขีดจํากัดคลัสเตอร์ ยกเว้นการจําลองข้อมูลไปยังคลัสเตอร์ back-end รองในภูมิภาค Azure จับคู่ในภูมิศาสตร์ Azure เดียวกัน คลัสเตอร์ back-end รองทําหน้าที่เป็นคลัสเตอร์เฟลโอเวอร์ในกรณีของภูมิภาคหยุดทํางาน และเป็น passive ในเวลาอื่น ๆ

ฟังก์ชัน Back-end ให้บริการโดย micro-services ที่ทํางานบนเครื่องอื่นภายในเครือข่ายเสมือนของคลัสเตอร์ที่ไม่สามารถเข้าถึงได้จากภายนอก ยกเว้นสองคอมโพเนนต์ที่สามารถเข้าถึงได้จากอินเทอร์เน็ตสาธารณะ:

  • บริการเกตเวย์
  • การจัดการ API ของ Azure

คลัสเตอร์ back-end

โครงสร้างพื้นฐานของ Power BI Premium

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

ความจุ Power BI Premium ถูกโฮสต์อยู่ในคลัสเตอร์ back-end ที่เป็นอิสระจากส่วนหลังของ Power BI ปกติ – ดูด้านบน) ซึ่งให้การแยกที่ดีกว่า การปันส่วนทรัพยากร การสนับสนุน การแยกความปลอดภัย และความปรับขนาดของข้อเสนอแบบพรีเมียม

แผนภาพต่อไปนี้แสดงให้เห็นถึงสถาปัตยกรรมของโครงสร้างพื้นฐานของ Power BI Premium:

Power BI พรีเมียม

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

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

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

มีทรัพยากรโดยรอบจํานวนมากเพื่อให้แน่ใจว่าโครงสร้างพื้นฐานมีความปลอดภัยและเชื่อถือได้: ตัวปรับสมดุลการโหลด เครือข่ายเสมือน กลุ่มความปลอดภัยเครือข่าย บัสบริการ ที่เก็บข้อมูล และอื่น ๆ ข้อมูลลับ คีย์ และใบรับรองใดๆ ที่จําเป็นสําหรับ Power BI Premium ได้รับการจัดการโดย Azure Key Vault โดยเฉพาะ การรับรองความถูกต้องใด ๆ จะดําเนินการผ่านการรวมกับ Microsoft Entra ID โดยเฉพาะ

คําขอใด ๆ ที่มาถึงโครงสร้างพื้นฐานของ Power BI Premium จะไปที่โหนด front-end ก่อน – ซึ่งเป็นโหนดเดียวที่พร้อมใช้งานสําหรับการเชื่อมต่อภายนอก ส่วนที่เหลือของทรัพยากรถูกซ่อนอยู่เบื้องหลังเครือข่ายเสมือน โหนด front-end จะรับรองความถูกต้องของคําขอ จัดการ หรือส่งต่อไปยังทรัพยากรที่เหมาะสม (ตัวอย่างเช่น โหนดส่วนหลัง)

โหนด Back-end ให้ความสามารถและคุณลักษณะของ Power BI Premium ส่วนใหญ่

Power BI Mobile

Power BI บนมือถือ คือคอลเลกชันของแอปที่ออกแบบมาสําหรับแพลตฟอร์มอุปกรณ์เคลื่อนที่หลักสามแพลตฟอร์ม: Android, iOS และ Windows (UWP) ข้อควรพิจารณาด้านความปลอดภัยสําหรับแอป Power BI บนมือถือจะแบ่งออกเป็นสองประเภท:

  • การติดต่อสื่อสารของอุปกรณ์
  • โปรแกรมประยุกต์และข้อมูลบนอุปกรณ์

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

ตารางต่อไปนี้แสดงการสนับสนุนการรับรองความถูกต้องตามใบรับรอง (CBA) สําหรับ Power BI บนมือถือโดยยึดตามแพลตฟอร์มอุปกรณ์เคลื่อนที่:

ฝ่ายสนับสนุน CBA iOS Android หน้าต่าง
Power BI (ลงชื่อเข้าใช้บริการ) รองรับ รองรับ ไม่รองรับ
ภายในองค์กรของ SSRS ADFS (เชื่อมต่อกับเซิร์ฟเวอร์ SSRS) ไม่รองรับ รองรับ ไม่รองรับ
พร็อกซีแอป SSRS รองรับ รองรับ ไม่รองรับ

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

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

  • Microsoft Entra ID และรีเฟรชโทเค็นจะถูกเก็บไว้ในกลไกการรักษาความปลอดภัยบนอุปกรณ์ โดยใช้หน่วยวัดความปลอดภัยมาตรฐานอุตสาหกรรม
  • ข้อมูลและการตั้งค่า (คู่ค่าคีย์สําหรับการกําหนดค่าผู้ใช้) จะถูกแคชไว้ในที่เก็บข้อมูลบนอุปกรณ์และสามารถเข้ารหัสลับโดยระบบปฏิบัติการ ใน iOS การดําเนินการนี้จะดําเนินการโดยอัตโนมัติเมื่อผู้ใช้ตั้งค่ารหัสผ่าน ใน Android สิ่งนี้สามารถกําหนดค่าในการตั้งค่า ใน Windows สามารถทําได้โดยใช้ BitLocker
  • สําหรับแอป Android และ iOS ข้อมูลและการตั้งค่า (คู่ค่าคีย์สําหรับการกําหนดค่าผู้ใช้) จะถูกแคชไว้ในที่เก็บข้อมูลบนอุปกรณ์ใน Sandbox และที่เก็บข้อมูลภายในที่สามารถเข้าถึงได้เฉพาะแอปเท่านั้น สําหรับแอป Windows ผู้ใช้ (และผู้ดูแลระบบ) สามารถเข้าถึงข้อมูลได้เท่านั้น
  • ตำแหน่งทางภูมิศาสตร์ถูกเปิดใช้งานหรือปิดใช้งานโดยผู้ใช้อย่างชัดเจน หากเปิดใช้งาน ข้อมูลตำแหน่งทางภูมิศาสตร์จะไม่ถูกบันทึกบนอุปกรณ์และจะไม่แชร์กับ Microsoft
  • การแจ้งเตือนถูกเปิดใช้งานหรือปิดใช้งานโดยผู้ใช้อย่างชัดเจน หากเปิดใช้งาน Android และ iOS จะไม่สนับสนุนข้อกําหนดที่อยู่ข้อมูลทางภูมิศาสตร์สําหรับการแจ้งเตือน

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

แอป Windows ยังสนับสนุน Windows Information Protection (WIP) อีกด้วย

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

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

Power BI บนมือถือไม่สามารถเข้าถึงโฟลเดอร์แอปพลิเคชันหรือไฟล์อื่น ๆ บนอุปกรณ์ได้

แอป Power BI สําหรับ iOS และ Android ช่วยให้คุณปกป้องข้อมูลของคุณโดยการกําหนดค่าการระบุเพิ่มเติม เช่น ให้ Face ID, Touch ID หรือรหัสผ่านสําหรับ iOS และข้อมูลทางชีวมิติ (Fingerprint ID) สําหรับ Android เรียนรู้เพิ่มเติมเกี่ยวกับการระบุเพิ่มเติม

การรับรองความถูกต้องไปยังบริการของ Power BI

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

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

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

  1. ผู้ใช้เริ่มต้นการเชื่อมต่อไปยังบริการของ Power BI จากเบราว์เซอร์ โดยพิมพ์ใน Power BI ที่อยู่ในแถบที่อยู่ หรือ โดยการเลือกลงชื่อเข้าใช้จากหน้าการตลาด Power BI (https://powerbi.microsoft.com) สร้างการเชื่อมต่อโดยใช้ TLS และ HTTPS และการสื่อสารที่ตามมาทั้งหมดระหว่างเบราว์เซอร์และบริการของ Power BI ใช้ HTTPS

  2. Azure Traffic Manager จะตรวจสอบระเบียน DNS ของผู้ใช้เพื่อกําหนดศูนย์ข้อมูลที่เหมาะสมที่สุด (โดยปกติใกล้ที่สุด) ที่มีการปรับใช้ Power BI และตอบสนองต่อ DNS ด้วยที่อยู่ IP ของคลัสเตอร์ WFE ที่ผู้ใช้ควรส่ง

  3. WFE จะส่งกลับหน้า HTML ไปยังไคลเอ็นต์เบราว์เซอร์ ซึ่งประกอบด้วยการอ้างอิงไลบรารี MSAL.js ที่จําเป็นเพื่อเริ่มต้นโฟลว์การลงชื่อเข้าใช้

  4. ไคลเอ็นต์เบราว์เซอร์จะโหลดหน้า HTML ที่ได้รับจาก WFE และเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าลงชื่อเข้าใช้บริการออนไลน์ของ Microsoft

  5. หลังจากผู้ใช้ได้รับการรับรองความถูกต้องหน้าลงชื่อเข้าใช้จะเปลี่ยนเส้นทางผู้ใช้กลับไปยังหน้า Power BI WFE ด้วยรหัสการรับรองความถูกต้อง

  6. ไคลเอ็นต์เบราว์เซอร์จะโหลดหน้า HTML และใช้รหัสการรับรองความถูกต้องเพื่อร้องขอโทเค็น (การเข้าถึง ID รีเฟรช) จาก Microsoft Entra ID

  7. ID ผู้เช่าของผู้ใช้ถูกใช้โดยไคลเอ็นต์เบราว์เซอร์เพื่อคิวรีบริการส่วนกลางของ Power BI ซึ่งเก็บรักษารายการของผู้เช่าและตําแหน่งที่ตั้งคลัสเตอร์ส่วนหลังของ Power BI ของพวกเขา บริการส่วนกลางของ Power BI จะกําหนดว่าคลัสเตอร์บริการส่วนหลังของ Power BI ตัวใดที่ประกอบด้วยผู้เช่าของผู้ใช้ และส่งกลับ URL คลัสเตอร์ Back-end ของ Power BI กลับไปยังไคลเอ็นต์

  8. ไคลเอ็นต์สามารถสื่อสารกับ POWER BI back-end cluster URL API โดยใช้โทเค็นการเข้าถึงในส่วนหัวการตรวจสอบสําหรับคําขอ HTTP โทเค็นการเข้าถึง Microsoft Entra จะมี การตั้งค่าวันหมดอายุตามนโยบาย Microsoft Entra และเพื่อรักษาเซสชันปัจจุบัน Power BI Client ในเบราว์เซอร์ของผู้ใช้จะทําให้การร้องขอเป็นระยะ ๆ เพื่อต่ออายุโทเค็นการเข้าถึงก่อนที่จะหมดอายุ

แผนภาพที่แสดงลําดับการรับรองความถูกต้องของไคลเอ็นต์

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

ที่เก็บข้อมูล

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

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

Multiple Geographies (multi-geo)

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

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

ดู กําหนดค่าการสนับสนุน Multi-Geo สําหรับ Power BI Premium สําหรับข้อมูลเพิ่มเติมเกี่ยวกับการสร้างและจัดการการปรับใช้ Power BI ที่ครอบคลุมหลายภูมิศาสตร์ Azure

ภูมิภาคและศูนย์ข้อมูล

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

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

การจัดการข้อมูล

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

ข้อมูลขณะจัดเก็บ

Power BI ใช้ชนิดทรัพยากรของพื้นที่จัดเก็บข้อมูลหลักสองชนิด:

  • ที่จัดเก็บข้อมูล Azure
  • ฐานข้อมูล SQL ของ Azure

ในสถานการณ์ส่วนใหญ่ Azure Storage จะถูกใช้เพื่อยืนยันข้อมูลของวัตถุ Power BI ในขณะที่ฐานข้อมูล Azure SQL ถูกใช้เพื่อคงเมตาดาต้าของอาร์ทิแฟกต

ข้อมูลทั้งหมดที่มีอยู่โดย Power BI จะถูกเข้ารหัสลับตามค่าเริ่มต้นโดยใช้คีย์ที่จัดการโดย Microsoft ข้อมูลลูกค้าที่จัดเก็บไว้ในฐานข้อมูล SQL Azure ถูกเข้ารหัสลับเต็มรูปแบบโดยใช้ เทคโนโลยีโปร่งใสเข้ารหัสข้อมูล (TDE) ของ Azure SQL ข้อมูลของลูกค้าที่จัดเก็บไว้ในที่เก็บข้อมูล Azure Blob ถูกเข้ารหัสลับโดยใช้ การเข้ารหัสลับที่เก็บข้อมูล Azure

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

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

โหมดแบบจําลองความหมาย (ชนิด) ข้อมูลยังคงอยู่ใน Power BI
นำเข้า ใช่
DirectQuery ไม่
เชื่อมต่อแบบสด ไม่
คอม โพ สิต ถ้า ประกอบด้วยแหล่งข้อมูลนําเข้า
สต รีม มิ่ง ถ้ากําหนดค่าให้คงอยู่

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

กำลังประมวลผลข้อมูล

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

ข้อมูลระหว่างทาง

Power BI จําเป็นต้องมีการรับส่งข้อมูล HTTP ขาเข้าทั้งหมดเพื่อเข้ารหัสลับโดยใช้ TLS 1.2 หรือสูงกว่า คําขอใดๆ ที่พยายามใช้บริการกับ TLS 1.1 หรือต่ํากว่าจะถูกปฏิเสธ

การรับรองความถูกต้องไปยังแหล่งข้อมูล

เมื่อเชื่อมต่อกับแหล่งข้อมูล ผู้ใช้สามารถเลือกนําเข้าสําเนาของข้อมูลลงใน Power BI หรือเชื่อมต่อโดยตรงไปยังแหล่งข้อมูล

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

ถ้ามีการเชื่อมต่อแหล่งข้อมูลโดยตรงโดยใช้ข้อมูลประจําตัวที่กําหนดไว้ล่วงหน้า ข้อมูลประจําตัวที่กําหนดค่าไว้ล่วงหน้าจะถูกใช้เพื่อเชื่อมต่อกับแหล่งข้อมูลเมื่อผู้ใช้ใด ๆ ดูข้อมูล ถ้ามีการเชื่อมต่อแหล่งข้อมูลโดยตรงโดยใช้การลงชื่อเข้าระบบครั้งเดียว ข้อมูลประจําตัวของผู้ใช้ปัจจุบันจะถูกใช้เพื่อเชื่อมต่อกับแหล่งข้อมูลเมื่อผู้ใช้ดูข้อมูล เมื่อใช้กับการลงชื่อเข้าระบบครั้งเดียว การรักษาความปลอดภัยระดับแถว (RLS) และ/หรือการรักษาความปลอดภัยระดับวัตถุ (OLS) สามารถใช้ได้บนแหล่งข้อมูล ซึ่งช่วยให้ผู้ใช้สามารถดูเฉพาะข้อมูลที่พวกเขามีสิทธิ์เข้าถึง เมื่อการเชื่อมต่อไปยังแหล่งข้อมูลในระบบคลาวด์ การรับรองความถูกต้องของ Microsoft Entra จะถูกใช้สําหรับลงชื่อเข้าระบบครั้งเดียว สําหรับแหล่งข้อมูลภายในองค์กร Kerberos Security Assertion Markup Language (SAML) และ Microsoft Entra ID ได้รับการสนับสนุน

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

คุณลักษณะพรีเมียม

สถาปัตยกรรมกระแสข้อมูล

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

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

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

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

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

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

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

รายงานที่ถูกแบ่ง

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

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

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

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

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

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

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

เพื่อสนับสนุนคุณลักษณะต่าง ๆ เช่น แผนที่ Bing หรือการโทรไปยังฟังก์ชัน Azure Sandbox สามารถเข้าถึงอินเทอร์เน็ตได้

การวิเคราะห์แบบฝังตัวของ Power BI

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

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

ในสถานการณ์การ ฝังตัวสําหรับลูกค้า ของคุณ ISV มักเป็นเจ้าของผู้เช่า Power BI และรายการ Power BI (แดชบอร์ด รายงาน แบบจําลองความหมาย และอื่น ๆ) เป็นความรับผิดชอบของบริการ back-end ของ ISV ในการรับรองความถูกต้องผู้ใช้ปลายทาง และตัดสินใจว่าวัตถุใดและระดับการเข้าถึงใดที่เหมาะสมสําหรับผู้ใช้ปลายทางนั้น การตัดสินใจเกี่ยวกับนโยบาย ISV จะถูกเข้ารหัสลับใน โทเค็น ฝังตัวที่สร้างขึ้นโดย Power BI และส่งผ่านไปยัง ISV back-end เพื่อแจกจ่ายให้กับผู้ใช้ปลายทางเพิ่มเติมตามตรรกะทางธุรกิจของ ISV ผู้ใช้ปลายทางที่ใช้เบราว์เซอร์หรือแอปพลิเคชันไคลเอ็นต์อื่น ๆ ไม่สามารถถอดรหัสหรือปรับเปลี่ยนโทเค็นแบบฝังตัวได้ SDK ฝั่งไคลเอ็นต์ เช่น Power BI Client API ผนวกโทเค็นฝังตัวที่เข้ารหัสลับเข้ากับคําขอ Power BI เป็น การรับรองความถูกต้อง: ส่วนหัว EmbedToken โดยอัตโนมัติ Power BI จะบังคับใช้นโยบายทั้งหมด (เช่น การเข้าถึงหรือ RLS) อย่างแม่นยําตามที่ระบุโดย ISV ในระหว่างการสร้าง โดยอิงตามส่วนหัวนี้

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

การวิเคราะห์แบบฝังตัวของ Power BI และ REST API รองรับความสามารถในการแยกเครือข่าย Power BI ทั้งหมดที่อธิบายไว้ในบทความนี้: เช่น แท็ก บริการและ ลิงก์ส่วนตัว

คุณลักษณะ AI

ปัจจุบัน Power BI รองรับฟีเจอร์ AI ที่หลากหลายสองประเภทในผลิตภัณฑ์วันนี้: การเสริมสร้างวิชวล AI และ AI คุณลักษณะ AI ระดับวิชวลประกอบด้วยความสามารถเช่น ผู้ทรงอิทธิพลหลัก โครงข่ายของข้อมูลแบบต้นไม้ Smart-Narrative การตรวจจับความผิดปกติ วิชวล R วิชวล Python การคลัสเตอร์ การคาดการณ์ Q&A ข้อมูลเชิงลึกด่วน เป็นต้น ความสามารถในการเสริมสร้าง AI รวมถึงความสามารถต่าง ๆ เช่น AutoML, Azure Machine Learning, CognitiveServices, การแปลง R/Python เป็นต้น

ฟีเจอร์ส่วนใหญ่ที่กล่าวถึงข้างต้นได้รับการสนับสนุนในพื้นที่ทํางานทั้งแบบใช้ร่วมกันและแบบพรีเมียมในปัจจุบัน อย่างไรก็ตาม AutoML และ CognitiveServices ได้รับการสนับสนุนเฉพาะในพื้นที่ทํางานแบบพรีเมียมเท่านั้น เนื่องจากข้อจํากัด IP วันนี้ด้วยการรวม AutoML ใน Power BI ผู้ใช้สามารถสร้างและฝึกแบบจําลอง ML แบบกําหนดเอง (ตัวอย่างเช่น การคาดการณ์ การจัดประเภท การถดถอย ฯลฯ) และนําไปใช้เพื่อรับการคาดการณ์ขณะโหลดข้อมูลลงในกระแสข้อมูลที่กําหนดไว้ในพื้นที่ทํางาน Premium นอกจากนี้ ผู้ใช้ Power BI สามารถใช้ CognitiveServices API หลายรายการ เช่น TextAnalytics และ ImageTagging เพื่อแปลงข้อมูลก่อนที่จะโหลดลงในแบบจําลองกระแสข้อมูล/ความหมายที่กําหนดไว้ในพื้นที่ทํางานแบบพรีเมียม

ฟีเจอร์การเสริมความสมบูรณ์ของ Premium AI สามารถดูได้ดีที่สุดในฐานะคอลเลกชันของฟังก์ชัน/การแปลงข้อมูล AI ที่ไม่สะดุดซึ่งผู้ใช้ Power BI สามารถใช้ในไปป์ไลน์การรวมข้อมูลของพวกเขาที่ใช้โดยแบบจําลองความหมาย Power BI หรือกระแสข้อมูล โปรดทราบว่าฟังก์ชันเหล่านี้สามารถเข้าถึงได้จากกระแสข้อมูล/แบบจําลองความหมายปัจจุบันที่สร้างสภาพแวดล้อมในบริการ Power BI และ Power BI Desktop ฟังก์ชัน/การแปลง AI เหล่านี้จะทํางานในพื้นที่ทํางาน/ความจุแบบพรีเมียมเสมอ ฟังก์ชันเหล่านี้จะแสดงใน Power BI เป็นแหล่งข้อมูลที่จําเป็นต้องมีโทเค็น Microsoft Entra สําหรับผู้ใช้ Power BI ที่กําลังใช้ฟังก์ชัน AI แหล่งข้อมูล AI เหล่านี้มีความพิเศษเนื่องจากไม่ได้แสดงข้อมูลใด ๆ ของตนเองและให้เฉพาะฟังก์ชัน/การแปลงเหล่านี้เท่านั้น ในระหว่างการดําเนินการ คุณลักษณะเหล่านี้จะไม่เรียกใช้ขาออกใด ๆ ไปยังบริการอื่น ๆ เพื่อส่งข้อมูลของลูกค้า ลองมาดูสถานการณ์ Premium ทีละสถานการณ์เพื่อทําความเข้าใจรูปแบบการสื่อสารและรายละเอียดที่เกี่ยวข้องกับความปลอดภัยที่เกี่ยวข้อง

สําหรับการฝึกและการใช้แบบจําลอง AutoML, Power BI ใช้ Azure AutoML SDK และเรียกใช้การฝึกอบรมทั้งหมดในความจุ Power BI ของลูกค้า ในระหว่างการทําซ้ําการฝึก Power BI จะเรียกใช้บริการ Azure Machine Learning รุ่นทดลองเพื่อเลือกแบบจําลองที่เหมาะสมและพารามิเตอร์หลายมิติสําหรับการทําซ้ําในปัจจุบัน ในการเรียกใช้ขาออกนี้ เฉพาะเมตาดาต้าการทดลองที่เกี่ยวข้องเท่านั้น (ตัวอย่างเช่น ความแม่นยํา อัลกอริทึม ml พารามิเตอร์อัลกอริทึม ฯลฯ) จากการทําซ้ําก่อนหน้านี้ถูกส่งไป การฝึก AutoML จะสร้างแบบจําลอง ONNX และข้อมูลรายงานการฝึกอบรมที่ถูกบันทึกไว้ในกระแสข้อมูล ต่อมา ผู้ใช้ Power BI สามารถนําแบบจําลอง ML ที่ได้รับการฝึกมาใช้เป็นการแปลงเพื่อดําเนินการแบบจําลอง ML ตามกําหนดเวลา สําหรับ TextAnalytics และ ImageTagging API, Power BI ไม่ได้เรียกใช้ API ของบริการ CognitiveServices โดยตรง แต่ใช้ SDK ภายในเพื่อเรียกใช้ API ในความจุ Power BI Premium วันนี้ API เหล่านี้ได้รับการสนับสนุนทั้งในกระแสข้อมูล Power BI และแบบจําลองความหมาย ในขณะที่เขียนแบบจําลองข้อมูลใน Power BI Desktop ผู้ใช้สามารถเข้าถึงฟังก์ชันการทํางานนี้ได้เฉพาะเมื่อพวกเขามีสิทธิ์เข้าถึงพื้นที่ทํางาน Power BI แบบพรีเมียม ดังนั้นลูกค้าจะได้รับพร้อมท์ให้ใส่ข้อมูลประจําตัว Microsoft Entra ของพวกเขา

การแยกเครือข่าย

ส่วนนี้สรุปคุณลักษณะการรักษาความปลอดภัยขั้นสูงใน Power BI บางคุณลักษณะมีข้อกําหนดสิทธิ์การใช้งานเฉพาะ ดูส่วนด้านล่างสําหรับรายละเอียด

แท็กการบริการ

แท็กบริการแสดงถึงกลุ่มของที่อยู่ IP คํานําหน้าจากบริการ Azure ที่ระบุ ซึ่งช่วยลดความซับซ้อนของการปรับปรุงที่ใช้บ่อยสําหรับกฎความปลอดภัยของเครือข่าย ลูกค้าสามารถใช้แท็กบริการเพื่อกําหนดตัวควบคุมการเข้าถึงเครือข่ายบน กลุ่ม ความปลอดภัยเครือข่ายหรือ ไฟร์วอลล์ Azure ได้ ลูกค้าสามารถใช้แท็กบริการแทนที่อยู่ IP เฉพาะเมื่อสร้างกฎความปลอดภัย ด้วยการระบุชื่อแท็กบริการ (เช่น PowerBI) ในเขตข้อมูลต้นทางหรือปลายทางที่เหมาะสม (สําหรับ API) ของกฎ ลูกค้าสามารถอนุญาตหรือปฏิเสธการรับส่งข้อมูลสําหรับบริการที่เกี่ยวข้อง Microsoft จัดการคํานําหน้าที่อยู่ที่ครอบคลุมโดยแท็กบริการ และอัปเดตแท็กบริการเป็นการเปลี่ยนแปลงที่อยู่โดยอัตโนมัติ

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

การเชื่อมโยงส่วนตัวช่วยให้แน่ใจว่าผู้ใช้ Power BI ใช้แกนกลางเครือข่ายส่วนตัวของ Microsoft เมื่อไปยังแหล่งทรัพยากรในบริการของ Power BI

การใช้ลิงก์ส่วนตัวกับ Power BI มีประโยชน์ดังต่อไปนี้:

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

ดู ลิงก์ส่วนตัวสําหรับการเข้าถึง Power BI สําหรับข้อมูลเพิ่มเติม

การเชื่อมต่อ VNet

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

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

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

  1. บริการคลาวด์ Power BI (หรือบริการคลาวด์ที่ได้รับการสนับสนุนอื่น ๆ) เริ่มต้นจากคิวรีและส่งคิวรี รายละเอียดแหล่งข้อมูล และข้อมูลประจําตัวไปยังบริการ Power Platform VNet (PP VNet)

  2. จากนั้นบริการ PP VNet จะใส่คอนเทนเนอร์ที่ใช้งานเกตเวย์ VNet ลงในเครือข่ายย่อยอย่างปลอดภัย คอนเทนเนอร์นี้สามารถเชื่อมต่อกับบริการข้อมูลที่สามารถเข้าถึงได้จากภายในเครือข่ายย่อยนี้

  3. จากนั้นบริการ PP VNet ส่งคิวรี รายละเอียดแหล่งข้อมูล และข้อมูลประจําตัวไปยังเกตเวย์ VNet

  4. เกตเวย์ VNet รับคิวรีและเชื่อมต่อกับแหล่งข้อมูลด้วยข้อมูลประจําตัวเหล่านั้น

  5. คิวรีจะถูกส่งไปยังแหล่งข้อมูลสําหรับการดําเนินการ

  6. หลังจากการดําเนินการ ผลลัพธ์จะถูกส่งไปยังเกตเวย์ VNet และ PP VNet service พุชข้อมูลจากคอนเทนเนอร์ไปยังบริการคลาวด์ของ Power BI ได้อย่างปลอดภัย

บริการหลัก

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

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

Microsoft Purview สําหรับ Power BI

การป้องกันข้อมูลของ Microsoft Purview

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

เมื่อเปิดใช้งานการป้องกันข้อมูลใน Power BI:

  • ข้อมูลที่ละเอียดอ่อนทั้งในบริการของ Power BI และใน Power BI Desktop สามารถจัดประเภทและติดป้ายชื่อโดยใช้ป้ายชื่อระดับความลับเดียวกับที่ใช้ใน Office และใน Azure
  • นโยบายการกํากับดูแลสามารถบังคับใช้เมื่อมีการส่งออกเนื้อหา Power BI ไปยังไฟล์ Excel, PowerPoint, PDF, Word หรือ .pbix เพื่อช่วยให้มั่นใจได้ว่าข้อมูลจะได้รับการป้องกันแม้ว่าข้อมูลจะออกจาก Power BI ก็ตาม
  • เป็นเรื่องง่ายที่จะจัดหมวดหมู่และปกป้อง ไฟล์ .pbix ใน Power BI Desktop เช่นเดียวกับที่ทําในแอปพลิเคชัน Excel, Word และ PowerPoint ไฟล์สามารถติดแท็กได้อย่างง่ายดายตามระดับความลับ นอกจากนี้ พวกเขายังสามารถเข้ารหัสลับได้หากพวกเขาประกอบด้วยข้อมูลที่เป็นความลับทางธุรกิจ เพื่อให้แน่ใจว่าเฉพาะผู้ใช้ที่ได้รับอนุญาตเท่านั้นที่สามารถแก้ไขไฟล์เหล่านี้ได้
  • เวิร์กบุ๊ก Excel จะสืบทอดป้ายชื่อระดับความลับโดยอัตโนมัติเมื่อพวกเขาเชื่อมต่อกับ Power BI (ตัวอย่าง) ทําให้สามารถรักษาการจัดประเภทแบบครอบคลุมและใช้การป้องกันเมื่อมีการวิเคราะห์แบบจําลองความหมายของ Power BI ใน Excel
  • ป้ายชื่อระดับความลับที่นําไปใช้กับรายงาน Power BI และแดชบอร์ดสามารถมองเห็นได้ในแอป Power BI ระบบ iOS และ Android
  • ป้ายชื่อระดับความลับยังคงอยู่เมื่อมีการฝังรายงาน Power BI ใน Teams, SharePoint หรือเว็บไซต์ที่ปลอดภัย ซึ่งช่วยให้องค์กรรักษาการจัดประเภทและป้องกันเมื่อส่งออกเมื่อฝังเนื้อหา Power BI
  • การสืบทอดป้ายชื่อเมื่อสร้างเนื้อหาใหม่ในบริการของ Power BI ทําให้แน่ใจว่าป้ายชื่อที่นําไปใช้กับแบบจําลองความหมายหรือ datamarts ในบริการของ Power BI จะถูกนําไปใช้กับเนื้อหาใหม่ที่สร้างขึ้นที่ด้านบนของแบบจําลองความหมายและดาต้ามาร์ทเหล่านั้น
  • การสแกนผู้ดูแลระบบ Power BI API สามารถแยกป้ายชื่อระดับความลับของรายการ Power BI ช่วยให้ผู้ดูแลระบบ Power BI และ InfoSec สามารถตรวจสอบการติดป้ายกํากับในบริการของ Power BI และสร้างรายงานผู้บริหาร
  • API ผู้ดูแลระบบ Power BI ช่วยให้ทีมส่วนกลางสามารถใช้ป้ายชื่อระดับความลับของข้อมูลกับเนื้อหาในบริการของ Power BI ได้โดยทางโปรแกรม
  • ทีมส่วนกลางสามารถสร้างนโยบายป้ายชื่อที่บังคับเพื่อบังคับใช้ป้ายชื่อสําหรับเนื้อหาใหม่หรือเนื้อหาที่แก้ไขแล้วใน Power BI
  • ทีมส่วนกลางสามารถสร้างนโยบายป้ายชื่อเริ่มต้นเพื่อให้แน่ใจว่ามีการใช้ป้ายชื่อระดับความลับกับเนื้อหา Power BI ใหม่หรือที่เปลี่ยนแปลงทั้งหมด
  • การติดป้ายชื่อระดับความลับแบบดาวน์สตรีมอัตโนมัติในบริการของ Power BI ช่วยให้แน่ใจว่าเมื่อมีการใช้หรือการเปลี่ยนแปลงป้ายชื่อในแบบจําลองความหมายหรือ datamart ป้ายชื่อจะถูกนําไปใช้หรือเปลี่ยนแปลงในเนื้อหาปลายทางทั้งหมดที่เชื่อมต่อกับแบบจําลองความหมายหรือดาต้ามาร์ทโดยอัตโนมัติ

สําหรับข้อมูลเพิ่มเติม โปรดดู ป้ายชื่อระดับความลับใน Power BI

นโยบาย การป้องกันการสูญหายของข้อมูลของ Microsoft Purview (DLP) สําหรับ Power BI

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

เมื่อมีการตั้งค่านโยบาย DLP สําหรับ Power BI:

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

สําหรับข้อมูลเพิ่มเติม ดูนโยบายการป้องกันการสูญหายของข้อมูลสําหรับ Fabric Power BI

Microsoft Defender สําหรับ Cloud Apps สําหรับ Power BI

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

ด้วย Defender สําหรับแอป Cloud องค์กรสามารถรับความสามารถ DLP ต่อไปนี้:

  • ตั้งค่าตัวควบคุมแบบเรียลไทม์เพื่อบังคับใช้เซสชันผู้ใช้ที่มีความเสี่ยงใน Power BI ตัวอย่างเช่น ถ้าผู้ใช้เชื่อมต่อกับ Power BI จากภายนอกประเทศหรือภูมิภาค ของพวกเขา สามารถตรวจสอบเซสชันได้โดยตัวควบคุม Defender for Cloud Apps แบบเรียลไทม์ และการดําเนินการที่มีความเสี่ยง เช่น การดาวน์โหลดข้อมูลที่ติดแท็กด้วยป้ายชื่อระดับความลับ "ความลับสูงสุด" สามารถบล็อกได้ทันที
  • ตรวจสอบกิจกรรมของผู้ใช้ Power BI ด้วยบันทึกกิจกรรม Defender สําหรับ Cloud Apps บันทึกกิจกรรมของ Defender for Cloud Apps มีกิจกรรมของ Power BI ตามที่รวบรวมไว้ในบันทึกการตรวจสอบ Office 365 ซึ่งประกอบด้วยข้อมูลเกี่ยวกับกิจกรรมของผู้ใช้และผู้ดูแลระบบทั้งหมด ตลอดจนข้อมูลป้ายชื่อระดับความลับสําหรับกิจกรรมที่เกี่ยวข้อง เช่น นําไปใช้ เปลี่ยน และลบป้ายกํากับ ผู้ดูแลระบบสามารถใช้ประโยชน์จาก Defender สําหรับ Cloud Apps ตัวกรองขั้นสูงและการดําเนินการด่วนสําหรับการตรวจสอบปัญหาที่มีประสิทธิภาพ
  • สร้างนโยบายแบบกําหนดเองเพื่อแจ้งเตือนกิจกรรมของผู้ใช้ที่น่าสงสัยใน Power BI คุณลักษณะนโยบายกิจกรรมของ Defender for Cloud Apps สามารถใช้ประโยชน์เพื่อกําหนดกฎแบบกําหนดเองของคุณเองเพื่อช่วยให้คุณตรวจสอบพฤติกรรมของผู้ใช้ที่ไม่สนใจบรรทัดฐานและอาจดําเนินการโดยอัตโนมัติหากดูเหมือนว่าเป็นอันตรายเกินไป
  • ทํางานกับ Defender สําหรับ Cloud Apps การตรวจหาความผิดปกติที่มีอยู่ภายใน นโยบายการตรวจจับความผิดปกติของ Defender for Cloud Apps มอบการวิเคราะห์พฤติกรรมของผู้ใช้แบบนอกกรอบและการเรียนรู้ของเครื่องเพื่อให้คุณพร้อมตั้งแต่จุดเริ่มต้นไปจนถึงการเรียกใช้การตรวจหาภัยคุกคามขั้นสูงทั่วทั้งสภาพแวดล้อมระบบคลาวด์ของคุณ เมื่อนโยบายการตรวจจับความผิดปกติระบุพฤติกรรมที่น่าสงสัยจะมีการทริกเกอร์การแจ้งเตือนความปลอดภัย
  • บทบาทผู้ดูแลระบบ Power BI ในพอร์ทัล Defender สําหรับ Cloud Apps Defender สําหรับ Cloud Apps มีบทบาทผู้ดูแลระบบเฉพาะแอปที่สามารถใช้เพื่อให้สิทธิ์แก่ผู้ดูแลระบบ Power BI เฉพาะที่พวกเขาจําเป็นต้องเข้าถึงข้อมูลที่เกี่ยวข้องกับ Power BI ในพอร์ทัลเท่านั้น เช่น การแจ้งเตือน ผู้ใช้ที่มีความเสี่ยง บันทึกกิจกรรม และข้อมูลอื่น ๆ ที่เกี่ยวข้องกับ Power BI

ดู การใช้ Microsoft Defender สําหรับตัวควบคุม Cloud Apps ใน Power BI สําหรับรายละเอียดเพิ่มเติม

แสดงตัวอย่างคุณลักษณะการรักษาความปลอดภัย

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

นําการวิเคราะห์รายการบันทึกของคุณเองมาใช้ (BYOLA)

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

คําถามและคําตอบด้านความปลอดภัยของ Power BI

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

วิธีที่ผู้ใช้เชื่อมต่อ และเข้าถึงแหล่งข้อมูลในขณะที่ใช้ Power BI

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

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

    สําหรับรายงานที่เชื่อมต่อกับ DirectQuery แหล่งข้อมูลเชื่อมต่อโดยตรงโดยใช้ข้อมูลประจําตัวที่กําหนดไว้ล่วงหน้า ข้อมูลประจําตัวที่กําหนดไว้ล่วงหน้าจะถูกใช้เพื่อเชื่อมต่อกับแหล่งข้อมูลเมื่อผู้ใช้ใดดูข้อมูล ถ้ามีการเชื่อมต่อแหล่งข้อมูลโดยตรงโดยใช้การลงชื่อเข้าระบบครั้งเดียว ข้อมูลประจําตัวของผู้ใช้ปัจจุบันจะถูกใช้เพื่อเชื่อมต่อกับแหล่งข้อมูลเมื่อผู้ใช้ดูข้อมูล เมื่อใช้ด้วยการลงชื่อเข้าระบบครั้งเดียว การรักษาความปลอดภัยระดับแถว (RLS) และ/หรือการรักษาความปลอดภัยระดับวัตถุ (OLS) สามารถใช้บนแหล่งข้อมูลได้ และสิ่งนี้ช่วยให้ผู้ใช้สามารถดูข้อมูลที่พวกเขามีสิทธิ์เข้าถึง เมื่อการเชื่อมต่อไปยังแหล่งข้อมูลในระบบคลาวด์ การรับรองความถูกต้องของ Microsoft Entra จะถูกใช้สําหรับลงชื่อเข้าระบบครั้งเดียว สําหรับแหล่งข้อมูลภายในองค์กร Kerberos, SAML และ Microsoft Entra ID ได้รับการสนับสนุน

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

    ถ้าแหล่งข้อมูลคือ Azure Analysis Services หรือ Analysis Services ภายในองค์กรและ Row Level Security (RLS) และ/หรือกําหนดค่าการรักษาความปลอดภัยระดับวัตถุ (OLS) บริการของ Power BI จะใช้การรักษาความปลอดภัยระดับแถวนั้น และผู้ใช้ที่ไม่มีข้อมูลประจําตัวเพียงพอที่จะเข้าถึงข้อมูลเบื้องต้น (ซึ่งอาจเป็นคิวรีที่ใช้ในแดชบอร์ด รายงาน หรือวัตถุข้อมูลอื่นๆ) จะไม่เห็นข้อมูลที่ผู้ใช้ไม่มีสิทธิ์เพียงพอ

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

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

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

ข้อมูลถูกถ่ายโอนไปยัง Power BI ได้อย่างไร?

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

Power BI แคชรายงาน แดชบอร์ด หรือแบบจําลองข้อมูลได้อย่างไรและมีความปลอดภัยหรือไม่

ไคลเอ็นต์แคชข้อมูลเว็บเพจภายในเครื่องหรือไม่

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

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

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

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

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

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

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

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

  • คําตอบของคําถามนี้อย่างละเอียดอยู่ในลิงก์ต่อไปนี้: พอร์ตเกตเวย์

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

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

    ผู้สร้างคีย์ (RSA และ AES) จะถูกจัดเก็บในไฟล์ที่อยู่บนเครื่อง ยังมีการเข้ารหัสลับไฟล์นั้น เนื้อหาของไฟล์สามารถเท่านั้นสามารถถอดรหัสลับ โดยเครื่อง Windows ที่เฉพาะเจาะจง และเท่านั้นที่บัญชีบริการเกตเวย์เฉพาะ

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

โพรโทคอลติดต่อสื่อสารใดที่ใช้โดยเกตเวย์ข้อมูลภายในองค์กร และวิธีการรักษาความปลอดภัย

  • เกตเวย์สนับสนุนโพรโทคอลติดต่อสื่อสารสองทางต่อไปนี้:

    • AMQP 1.0 – TCP + TLS: โพรโทคอลนี้ต้องการพอร์ต 443, 5671-5672 และ 9350-9354 เพื่อเปิดสําหรับการสื่อสารขาออก โพรโทคอลนี้เป็นสิ่งจําเป็น เนื่องจากมีค่าใช้จ่ายการติดต่อสื่อสารน้อยกว่า

    • HTTPS – WebSockets over HTTPS + TLS: โพรโทคอลนี้ใช้พอร์ต 443 เท่านั้น WebSocket เริ่มต้นโดยข้อความการเชื่อมต่อ HTTP เดียว เมื่อช่องสําเร็จ สื่อสารได้โดยหลัก ๆ แล้ว TCP + TLS คุณสามารถบังคับให้เกตเวย์ใช้โพรโทคอลนี้ โดยการปรับเปลี่ยนการตั้งค่าที่อธิบายไว้ใน บทความเกตเวย์ภายในองค์กรได้

บทบาทของ CDN Azure ใน Power BI คืออะไร

  • Power BI ใช้ Azure Content Delivery Network (CDN) เพื่อแจกจ่ายเนื้อหาแบบคงที่ที่จําเป็นได้อย่างมีประสิทธิภาพและบันทึกเป็นไฟล์ไปยังผู้ใช้ตามตําแหน่งที่ตั้งทางภูมิศาสตร์ เมื่อต้องไปลงในรายละเอียดเพิ่มเติม บริการของ Power BI ใช้หลาย CDNs การแจกจ่ายเนื้อหาแบบคงจําเป็นและไฟล์ไปยังผู้ใช้ผ่านอินเทอร์เน็ตสาธารณะได้อย่างมีประสิทธิภาพ ไฟล์คงที่เหล่านี้รวมถึงไฟล์ดาวน์โหลดผลิตภัณฑ์ (เช่น Power BI Desktop เกตเวย์ข้อมูลภายในองค์กร หรือแอป Power BI จากผู้ให้บริการอิสระต่าง ๆ) ไฟล์การกําหนดค่าเบราว์เซอร์ที่ใช้เพื่อเริ่มต้นและสร้างการเชื่อมต่อใด ๆ ในเวลาต่อมาด้วยบริการของ Power BI ตลอดจนการรักษาความปลอดภัยเริ่มต้นสําหรับหน้าลงชื่อเข้าใช้ Power BI

    ยึดตามข้อมูลที่มีอยู่ในระหว่างการเชื่อมต่อเริ่มต้นไปยังบริการของ Power BI เบราว์เซอร์ของผู้ใช้ที่ติดต่อ Azure CDN ที่ระบุ (หรือสําหรับไฟล์บางไฟล์ WFE) เพื่อดาวน์โหลดคอลเลกชันของไฟล์ทั่วไปที่เฉพาะซึ่งจําเป็นต้องเปิดใช้งานการโต้ตอบของเบราว์เซอร์กับบริการของ Power BI หน้าเบราว์เซอร์แล้วมีโทเค็น Microsoft Entra ข้อมูลเซสชัน ตําแหน่งที่ตั้งของคลัสเตอร์ back-end ที่เกี่ยวข้อง และคอลเลกชันของไฟล์ที่ดาวน์โหลดจากคลัสเตอร์ WFE และ Azure CDN สําหรับระยะเวลาของเซสชันเบราว์เซอร์บริการของ Power BI

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

  • ไม่ใช่ ความรับผิดชอบของลูกค้าเพื่อตรวจสอบและกําหนดว่าควรใช้รหัสวิชวลแบบกําหนดเองหรือไม่ โค้ดวิชวลแบบกําหนดเองทั้งหมดจะดําเนินการในสภาพแวดล้อมแบบ Sandbox เพื่อให้รหัสผิดพลาดใด ๆ ในวิชวลแบบกําหนดเองไม่ส่งผลกระทบต่อส่วนเหลือของบริการของ Power BI

มีวิชวล Power BI อื่น ๆ ที่ส่งข้อมูลภายนอกเครือข่ายของลูกค้าหรือไม่

  • ได้ Bing Maps และวิชวล ESRI ส่งข้อมูลออกจากบริการของ Power BI สําหรับวิชวลที่ใช้บริการเหล่านั้น

สําหรับแอปเทมเพลต Microsoft ดําเนินการรักษาความปลอดภัยหรือการประเมินความเป็นส่วนตัวของแอปเทมเพลตก่อนที่จะเผยแพร่รายการแกลเลอรีหรือไม่

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

มีแอปแม่แบบที่สามารถส่งข้อมูลภายนอกเครือข่ายลูกค้าหรือไม่

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

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

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

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

วิธีไม่ Microsoft ถือว่าเชื่อมต่อสําหรับลูกค้าที่มีการสมัครใช้งาน Power BI Premium หรือไม่ การเชื่อมต่อเหล่านั้นแตกต่างจากที่สร้างขึ้นสําหรับบริการของ Power BI ที่ไม่ใช่ Premium หรือไม่

  • การเชื่อมต่อที่สร้างขึ้นสําหรับลูกค้าด้วยการสมัครใช้งาน Power BI Premium ใช้ กระบวนการอนุญาตของ Microsoft Entra business-to-business (B2B) โดยใช้ Microsoft Entra ID เพื่อเปิดใช้งานการควบคุมการเข้าถึงและการรับรองความถูกต้อง Power BI จัดการการเชื่อมต่อจาก Power BI Premium สมาชิกไปยังแหล่งข้อมูล Power BI Premium เหมือนกับผู้ใช้ Microsoft Entra อื่น ๆ

การรับรองความถูกต้องฝั่งเซิร์ฟเวอร์ทํางานอย่างไรใน WFE

  • การรับรองความถูกต้องทางด้านบริการลําดับการรับรองความถูกต้องผู้ใช้เกิดขึ้นตามที่อธิบายไว้ในขั้นตอนต่อไปนี้ ซึ่งแสดงในรูปที่ตามมา
  1. ผู้ใช้เริ่มต้นการเชื่อมต่อไปยังบริการของ Power BI จากเบราว์เซอร์ โดยพิมพ์ใน Power BI ที่อยู่ในแถบที่อยู่ หรือ โดยการเลือกลงชื่อเข้าใช้จากหน้าการตลาด Power BI (https://powerbi.microsoft.com) สร้างการเชื่อมต่อโดยใช้ TLS 1.2 และ HTTPS และการสื่อสารที่ตามมาทั้งหมดระหว่างเบราว์เซอร์และบริการของ Power BI ใช้ HTTPS

  2. Azure Traffic Manager จะตรวจสอบระเบียน DNS ของผู้ใช้เพื่อกําหนดศูนย์ข้อมูลที่เหมาะสมที่สุด (โดยปกติใกล้ที่สุด) ที่มีการปรับใช้ Power BI และตอบสนองต่อ DNS ด้วยที่อยู่ IP ของคลัสเตอร์ WFE ที่ผู้ใช้ควรส่ง

  3. WFE เปลี่ยนเส้นทางผู้ใช้ไปยังหน้าลงชื่อเข้าใช้บริการออนไลน์ของ Microsoft แล้ว

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

  5. คลัสเตอร์ WFE ตรวจสอบด้วยรหัส Microsoft Entra เพื่อรับโทเค็นการรักษาความปลอดภัยของ Microsoft Entra โดยใช้รหัสการรับรองความถูกต้อง เมื่อ Microsoft Entra ID ส่งกลับการรับรองความถูกต้องที่สําเร็จของผู้ใช้ และส่งกลับโทเค็นความปลอดภัย Microsoft Entra คลัสเตอร์ WFE ปรึกษา Power BI Global Service ซึ่งเก็บรายการของผู้เช่าและตําแหน่งที่ตั้งของคลัสเตอร์ Back-end ของ Power BI และกําหนดคลัสเตอร์บริการปลายสุดของ Power BI ที่ประกอบด้วยผู้เช่าของผู้ใช้ คลัสเตอร์ WFE แล้วส่งกลับหน้าแอปพลิเคชันไปยังเบราว์เซอร์ของผู้ใช้ด้วยเซสชัน การเข้าถึง และข้อมูลการกําหนดเส้นทางที่จําเป็นสําหรับการดําเนินการ

  6. ตอนนี้ เมื่อเบราว์เซอร์ของไคลเอ็นต์ต้องการข้อมูลลูกค้า ก็จะส่งคําขอไปยังที่อยู่คลัสเตอร์ back-end ด้วยโทเค็นการเข้าถึง Microsoft Entra ในส่วนหัว Authorization คลัสเตอร์ Power BI back-end อ่านโทเค็นการเข้าถึง Microsoft Entra และตรวจสอบลายเซ็นเพื่อให้แน่ใจว่า ข้อมูลประจําตัวสําหรับคําขอถูกต้อง โทเค็นการเข้าถึง Microsoft Entra จะมี การตั้งค่าวันหมดอายุตามนโยบาย Microsoft Entra และเพื่อรักษาเซสชันปัจจุบัน Power BI Client ในเบราว์เซอร์ของผู้ใช้จะทําให้การร้องขอเป็นระยะ ๆ เพื่อต่ออายุโทเค็นการเข้าถึงก่อนที่จะหมดอายุ

แผนภาพที่แสดงลําดับการรับรองความถูกต้อง WFE

แหล่งข้อมูลเพิ่มเติม

สําหรับข้อมูลเพิ่มเติมเกี่ยวกับ Power BI โปรดดูทรัพยากรต่อไปนี้