介绍
Power BI是微软提供的一款在线软件服务(也称作SaaS,即软件即服务)。通过它,用户能够便捷迅速地制作自助商业智能仪表板、报告、语义模型和可视化效果。使用Power BI,用户可以连接到众多不同的数据源,整合和处理这些数据源的数据,随后创建可以与他人分享的报告和仪表板。
背景
随着越来越多的公司完成向云计算的转型,这个过程已从最初的小规模逐渐发展成为一股强大的潮流。与此同时,随着更多新的表层领域被开放,公司们越发关心他们在云中的数据安全问题:我的数据在云中如何保持安全?如何利用端到端的保护措施来防止敏感数据泄露?对于那些经常处理着企业中一些极具战略意义信息的BI(商业智能)平台来说,这些问题尤其重要。说到底,就是关于如何让用户仅仅看到他们应该看到的数据(防止用户看到他们不应该看到的数据)。本篇文章我将讨论安全性的各种“层次”。
Power BI 体系结构
Power BI服务架构基于两个集群——Web前端(WFE)集群和后端集群。WFE集群管理与Power BI服务的初始连接和认证,一旦认证通过,后端集群处理所有后续的用户交互。Power BI使用Azure Active Directory(AAD)来存储和管理用户身份(在Azure Blob中),并管理数据和元数据的存储(在Azure SQL数据库中),两者都使用休眠状态下的加密(您可以带来自己的密钥)。
Azure Traffic Manager
Power BI还利用 Azure Traffic Manager(ATM)基于客户端的DNS记录,将流量引导至最近的WFE,用于认证过程和下载静态内容及文件。Power BI使用Azure内容交付网络(CDN)高效地向用户分发基于地理位置的必要静态内容和文件(见Power BI安全性)。
用户认证:
Power BI使用AAD来认证登录Power BI服务的用户,并反过来,每当用户尝试访问需要认证的任何资源时,必须使用Power BI登录凭据(用户名和密码,即用户使用建立Power BI账户时的电子邮件地址登录Power BI服务)来获得访问权限。
Power BI工作区和应用程序:
您可以将内容从Power BI desktop(桌面版)发布到Power BI Service的Workspace工作区,这是一个包含仪表板、报告、工作簿、数据集和数据流的集合。 然后,您可以向工作区添加安全组、分发列表、Office 365组或个人,并分配用户他们的角色和权限,作为观众、贡献者、成员或管理员。您可以选择将这个集合打包成一个称为应用程序的整洁包,并将其分发/发布给整个组织,或特定的人或群体。只有仪表板、报告和工作簿是打包的一部分,您可以选择通过“包含在应用中”选项发布哪些内容。 您还可以允许应用程序用户通过给予他们构建权限来连接到应用程序的底层数据集。他们在搜索共享数据集时会看到这些数据集。 您通常在工作区内开始创建应用程序的过程,在那里您可以与同事合作处理Power BI内容,然后将完成的应用程序发布给组织内的大量人员。应用程序使管理这些集合上的权限变得更容易。将工作区视为用于组成Power BI应用内容的暂存区和容器。
行级安全(RLS):
通过行级安全(RLS),您可以向用户发布单一报告,但对每个人展示不同的数据。所以,与其为了限制数据而创建同一报告的多个副本,不如只创建一个报告,只显示登录用户被允许看到的数据。这是通过过滤器完成的,过滤器在行级别限制数据访问,您在角色内定义过滤器。例如,创建一个名为“美国”的角色,过滤表中区域 = “美国”的数据。然后将只能看到美国数据的成员(用户、安全组或分发列表)添加到“美国”角色中(角色的成员分配只能在Power BI服务内完成)。如果一个用户不应该访问某个报告,那么就不要将该人包括在任何该报告的角色中,这样他们将始终看到一个空白报告。
Audit审计:
了解谁在您的Power BI租户中对哪个项目采取了什么行动,可能对帮助您的组织满足其要求至关重要,比如满足监管合规性和记录管理。使用Power BI,您有两种跟踪用户活动的选项:Power BI活动日志和统一的Office 365审计日志(区别在这里列出)。这些日志都包含了Power BI审计数据的完整副本,因此您可以查看所有Power BI活动的详尽日志。审计日志只保留多达90天的数据,因此您可能需要存储数据并通过Power BI进行报告(见从存储在Azure Blob存储中的审计日志创建Power BI报告)。
Data Sources – Import
通过数据源直接导入,当数据在Power BI桌面中被导入时,Power BI使用当前用户在Power BI桌面的凭据或作为配置定期刷新的一部分定义的凭据连接到数据源。在发布和共享此类报告时,小心只与允许看到相同数据的用户共享,或定义数据集的行级安全。
DirectQuery:
理想情况下,因为DirectQuery总是查询底层数据源,这种配置将允许应用底层源中的任何安全性。然而,在发布到Power BI服务后,Power BI总是使用与导入时相同的固定凭据连接到底层源。请注意,发布DirectQuery报告后,需要立即配置将被使用的用户凭据。在您配置凭据之前,打开Power BI服务上的报告将导致错误。一旦提供了用户凭据,那么无论哪个用户打开报告,都将使用这些凭据。这方面,它与导入数据完全相同。除非定义了报告的行级安全,否则每个用户看到的数据都是相同的。如果底层源中定义了任何安全规则,则在共享报告时必须同样注意。在Power BI允许报告消费者的身份传递到底层源之前,DirectQuery对数据源安全没有优势。参见关于在Power BI中使用DirectQuery。
标签:Power,报告,BI,用户,Azure,权限,数据 From: https://blog.51cto.com/u_9857984/8844793