使用 PowerShell 报告敏感度标签设置

记录敏感度标签的多种设置

组织开始使用敏感度标签后，记录每个标签设置的任务就开始了。 Microsoft 稳步增强了敏感度标签的功能，以满足信息保护（例如添加对会议的支持）和容器管理（例如控制 SharePoint Online 网站的共享权限或 Teams 会议模板对它们的使用）的需求。基本标签操作也发生了改进，例如添加颜色以突出标签的功能。关键是敏感度标签现在有很多设置，将来还会有更多设置。

Microsoft Purview 合规中心在其信息保护部分列出了敏感度标签，但不包含导出标签及其设置详细信息的选项。不过，Get-Label cmdlet 是可用的，它可以显示构建报告所需的所有内容。

除了作为一种更方便的方式来检查标签设置和检测可能的不一致之外，报告也是备份标签设置的好方法，以防将来有人在更新标签时出错。如果发生这种情况，您可以查阅上次报告以了解问题所在，并调整回上次已知的正确值。考虑到所有这些，让我们讨论如何创建报告。

按需迁移

使用一种全面的 Office 365 租户到租户迁移解决方案迁移所有工作负载和 Active Directory。

检索灵敏度标签设置

Get-Label cmdlet 在名为 LabelActions 的属性中返回敏感度标签设置。该信息采用 JSON 格式，可转换为数组，以便更轻松地使用 PowerShell 进行操作。我们的数组如下所示：

$LabelActions = (Get-Label -Identity $Label.ImmutableId).LabelActions | Convertfrom-JSON
$LabelActions

Type                SubType Settings
----                ------- --------
applycontentmarking header  {@{Key=disabled; Value=true}}
applycontentmarking footer  {@{Key=disabled; Value=false}, @{Key=fontsize; Value=8}, @{Key=text; Value=Sensitivity: ...
applywatermarking           {@{Key=disabled; Value=true}}
encrypt                     {@{Key=disabled; Value=false}, @{Key=protectiontype; Value=template}, @{Key=aiptemplates...
endpoint                    {@{Key=disabled; Value=true}}
protectgroup                {@{Key=privacy; Value=unspecified}, @{Key=allowemailfromguestusers; Value=false}, @{Key=...
protectsite                 {@{Key=allowfullaccess; Value=false}, @{Key=allowlimitedaccess; Value=true}, @{Key=block...
protectteams                {@{Key=disabled; Value=false}, @{Key=islobbyrestrictionenforced; Value=true}, @{Key=ispr...

如您所见，数组分为一组部分（类型），每个部分都包含一个哈希表，其中保存该部分的相关设置。例如，加密部分保存有关当有人将标签应用于消息或文件时调用的权限管理保护的信息，而protectsite部分保存以下内容的容器管理设置： SharePoint Online 网站。通过选择某个部分并展开设置，您可以更好地查看该部分中的设置。由于信息位于哈希表中，因此它的结构为一组键和值：

$LabelActions | Where-Object {$_.Type -eq "encrypt"} | Select-Object -ExpandProperty Settings

Key                               Value
---                               -----
disabled                          false
protectiontype                    template
aiptemplatescopes                 ["All"]
templateid                        2707d5c0-a112-45e3-9925-522a34bee048
templatearchived                  False
linkedtemplateid                  2707d5c0-a112-45e3-9925-522a34bee048
contentexpiredondateindaysornever Never
offlineaccessdays                 -1
rightsdefinitions                 [{"Identity":"office365itpros.onmicrosoft.com","Rights":"VIEW,VIEWRIGHTSDATA,OBJ...

解释权

现在我们知道如何检索敏感度标签设置，我们可以考虑如何报告我们发现的内容。最简单的方法是创建一个简单的设置列表，但我决定从报告中提取更多价值。这让我开始考虑敏感度标签中分配的权利。

加密（保护）内容的敏感度标签可以使用预先分配的权限或用户定义的权限。预分配的权限意味着标签包含一组身份以及分配给这些身份的权限。用户定义的权限是指用户在保护文档或消息时分配权限。

预分配身份的有效类型是：

• 个人用户由其主 SMTP 地址标识。
• 团体。该分配使用组的主 SMTP 地址。该组的任何成员都可以获得分配的权限。
• 主机组织中的任何用户或组。
• 任何经过身份验证的用户。任何可以通过 Azure AD 进行身份验证或拥有 Microsoft 服务帐户的人都可以打开受该标签保护的 Office 文档。使用联合社交提供商或可以使用一次性密码的人可以访问受该标签保护的电子邮件，但他们无法进行身份验证以访问受保护的文档。
• 域中的任何人。

敏感度标签将身份与一组权利配对，这些权利规定受让人可以对受保护的内容执行哪些操作。为了方便起见，标签将权限集捆绑到共同作者和读者等角色中。当您向标签中的受让人分配权限时，通常会分配一个角色。但是，您还可以分配一组自定义权限来满足特定要求。以下是敏感度标签分配的一组权限的样子。分配给经过身份验证的用户和拥有 Microsoft.com 电子邮件地址的任何人的权限相当于查看者角色。分配给 Office365itpros.com 中任何人的权利相当于审阅者角色。尽管在本例中分配的是服务域，但您可以使用它或默认域来标识主机组织的成员。

Identity                          Rights
--------                          ------
AuthenticatedUsers                VIEW,VIEWRIGHTSDATA,OBJMODEL
microsoft.com                     VIEW,VIEWRIGHTSDATA,OBJMODEL
office365itpros.onmicrosoft.com VIEW,VIEWRIGHTSDATA,OBJMODEL,DOCEDIT,EDIT,REPLY,REPLYALL,FORWARD

没有人谈论的是，除非管理员花时间验证权限集以删除不必要的权限或调整分配给受让人的权限集，否则权限仍保留在标签中分配。例如，如果单个用户获得权利，然后离开公司，因此他们的电子邮件地址不再使用，Purview 不会定期检查电子邮件地址以确保它们仍然有效，并且标签可能会将权利分配给完成不再需要的域。

出现这种情况的原因是可以理解的。如果您从敏感度标签中删除身份，则依赖所分配权限的用户将无法访问受该标签保护的内容。如果微软删除了它认为无效的身份并导致人们无法访问重要文档，客户将会强烈抱怨。因此，最好将权利维护的责任留给拥有敏感标签的租户。

但是，这并不意味着报告无法检查敏感度标签中分配的权限来标记管理员应考虑检查的权限，这正是我的脚本中发生的情况。图 1 显示了脚本生成的 HTML 报告中显示的敏感度标签属性的示例。该报告突出显示了分配给单个电子邮件地址的权利，因为该地址不再有效。同样，如果脚本发现分配给 Outlook.com 或 gmail.com 等消费者电子邮件域的权限，它会标记该权限以进行检查，因为允许对大量电子邮件域的权限并不是保护信息的好方法。

验证权利

验证权限的代码并不是很复杂：

• 不可能检查任何经过身份验证的用户，因此身份通过无需进一步评论。
• 如果分配了权限的单个用户或组的电子邮件地址属于主机租户拥有的域，则脚本将运行 Get-ExoRecipient cmdlet 以查看该地址是否可以找到电子邮件收件人。如果不能，脚本会发出警告。它还会警告外部电子邮件地址，以突出显示该地址以供管理员检查。
• 如果域接收权限，脚本将使用此处说明的技术来验证该域是否使用 Azure AD（它是托管域）。如果不是，或者该域是消费者域，则脚本会标记该域以供后续处理。由于某些奇怪的原因，代码认为 Microsoft.com 不是托管域。

在脚本末尾，它会生成 HTML 报告和 CSV 文件。如果注意到任何警告，它会摘要报告它们：

You should check these warnings flagged for rights assignments

Label    : Intellectual Property
Applies  : File, Email
Priority : 12
Value    : [email protected] rights: VIEW,VIEWRIGHTSDATA,DOCEDIT,EDIT,REPLY,REPLYALL,FORWARD,OBJMODEL (Warning:
           Rights assigned to unverified holder)
           [email protected] rights: VIEW,VIEWRIGHTSDATA,DOCEDIT,EDIT,REPLY,REPLYALL,FORWARD,OBJMODEL
           outlook.com rights: VIEW,VIEWRIGHTSDATA,OBJMODEL (Warning: consumer domain)
           office365itpros.com rights: VIEW,VIEWRIGHTSDATA,REPLY,REPLYALL,OBJMODEL
           [email protected] rights: VIEW,VIEWRIGHTSDATA,OBJMODEL (Warning: Rights assigned to unverified holder)
           [email protected] rights: VIEW,VIEWRIGHTSDATA,DOCEDIT,EDIT,REPLY,REPLYALL,FORWARD,OBJMODEL (Warning: Rights
           assigned to unverified holder)

您可以从 GitHub 下载完整的脚本。

维护敏感度标签中分配的权利

当我开始编写脚本时，我认为我的租户中定义的敏感度标签集状态良好。但过去五年左右测试不同场景的影响意味着一些标签没有得到很好的配置。至少，我可以做出改进。当谈到权利分配时，我发现了很多差距，现在我已经修复了。此练习证明，偶尔查看 Microsoft 365 对象是一种很好的做法，并展示了 PowerShell 在以有用的格式提取和呈现信息方面的有用性。

Active Directory 的网络安全风险管理

了解如何通过这些网络安全风险管理解决方案预防 AD 攻击并从中恢复。