PowerShell 和 Exchange 在线安全

黑客。垃圾邮件发送者。网络钓鱼。天啊！ （好吧，这是陈词滥调。）

但严重的是，Exchange Online 面临着大量的攻击、攻击媒介和恶意行为者。随着安全性方面转向云服务，管理员的工作变得更加艰巨。然而，像 Microsoft 这样的公司正在努力减轻这些担忧，并为 Exchange Online 管理员提供处理这些威胁的工具。在本文中，我们将了解如何使用 PowerShell 为 Exchange Online 提供安全性。

身份验证类型

首先，我们有一个身份验证的概念：

基本认证

基本身份验证对与 Exchange Online 中的资源的每次交互使用密码请求/响应。没有实施其他访问要求。如果连接到 Exchange Online 时连接不安全，则密码可能会被拦截。

现代认证

现代身份验证基于使用 OAUTH 2.0 和 ADAL（活动目录身份验证库），使用基于令牌的身份验证，这提供了更高的安全性。
较旧的租户可能会关闭现代身份验证，而较新的租户默认情况下会打开此功能。我们可以通过在 Exchange Online PowerShell 中运行以下一行来检查我们的租户：

Get-OrganizationConfig | Ft OAuth2ClientProfileEnabled

图 1 中所示的输出表明新式身份验证已打开：

图 1 中所示的输出表明现代身份验证已打开：

如果这是 False，Modern Auth 将被关闭，这违反了 Office 365 的最佳实践，也不是一个非常安全的做法。确保此功能已打开。请记住，这不会 不会 阻止基本身份验证客户端连接到 Exchange Online。我们还有其他方法可以做到这一点。接下来，阻止基本身份验证！

认证策略

阻止 Exchange Online 的基本身份验证可以通过至少两种不同的方法来完成。其中一种是条件访问，我们不会探讨它（但可以使用 PowerShell 来完成！），另一种方法是所谓的身份验证策略。身份验证策略允许我们控制 Exchange Online 的哪些方面使用基本身份验证或不能使用基本身份验证。首先，身份验证策略的默认配置是什么？嗯，实际上，没有！

Get-AuthenticationPolicy | fl

好的。那么，如果没有政策，那我们能做什么呢？我们创建一个。使用 PowerShell 或在 M365 管理中心进行更改。我们该怎么做呢？首先，我们需要找到默认的身份验证策略。身份验证策略实际上位于 M365 管理中心的“设置”→“组织设置”→“现代身份验证”下，其中揭示了这一点：

要使该策略显示在 PowerShell 中，我们只需取消选中一项（例如 IMAP），保存设置并等待 15-30 秒。等待之后，我们可以运行：

Get-AuthenticationPolicy | fl

查看所做的更改：

请注意，AllowBasicAuthIMAP 已禁用。要阻止所有这些协议的基本身份验证，我们可以运行以下一行代码：

Set-AuthenticationPolicy -Identity 'BlockBasic637530830181380023' -AllowBasicAuthActiveSync:$False -AllowBasicAuthAutodiscover:$False -AllowBasicAuthImap:$False -AllowBasicAuthMapi:$False -AllowBasicAuthOfflineAddressBook:$False -AllowBasicAuthOutlookService:$False -AllowBasicAuthPop:$False -AllowBasicAuthReportingWebServices:$False -AllowBasicAuthRest:$False -AllowBasicAuthRpc:$False -AllowBasicAuthSmtp:$False -AllowBasicAuthWebServices:$False -AllowBasicAuthPowershell:$FalsengWebServices $False -AllowBasicAuthRpc $False -AllowBasicAuthSmtp $False -AllowBasicAuthWebServices $False -AllowBasicAuthPowershell $False

Get-AuthenticationPolicy | fl

现在，我们已经基本禁用了可用于连接到 Exchange Online 的整个连接类型列表。

协议限制

对于 Exchange Online，Microsoft 提供了许多协议供最终用户连接到其邮箱。我们有 IMAP、POP、ActiveSync、ECP、MAPI、OWA 等。通常，我们希望阻止 IMAP4 和 POP3 等不太安全的协议，以便用户不会使用这些协议连接邮箱。我们可以使用 CasMailboxPlan cmdlet 控制这些连接。通常，Exchange Online 中有四种主要的 CAS 邮箱计划，但此数量可能会根据您的许可模式而有所不同。

对于我们的示例，我们有一个具有 E3 或 E5 许可的 Exchange Online 租户。如果我们运行 Get-CasMailboxPlan | Ft Name，我们看到这些计划：

1. 无办公桌
2. 常规的
3. 企业和
4. 必需品

我们可以通过运行以下 cmdlet 查看这些计划之一可用：

Get-CASMailboxPlan ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a | Fl *Enabled

现在，如果我们需要关闭协议，IMAP 和 POP 是主要候选者，我们可以这样做：

Set-CASMailboxPlan -Identity ExchangeOnlineEnterprise-a198b3f1-d047-49ed-b00d-b9ae84d0390a -IMAPEnabled $False -POPEnabled $False

我们可以使用以下一行代码一次性对所有计划进行更改：

Get-CASMailboxPlan | Set-CASMailboxPlan -IMAPEnabled $False -POPEnabled $False

通过这样做，我们现在减少了 Exchange Online 邮箱访问的攻击角度。

OWA 离线模式

Web 邮件经常被忽视的功能之一（称为 OWA）是离线模式功能。此功能会在您的设备上留下最近 500 封电子邮件的未加密副本，以便您在未连接时轻松访问。该理论认为，经常出差的人将能够处理他们最近的电子邮件、创建回复并使用他们最近的电子邮件中包含的信息。然而，缺乏加密是该设置的致命弱点。

我们可以使用 PowerShell 查看 OWA 邮箱策略，如下所示：

Get-OwaMailboxPolicy | Ft AllowOfflineOn

我们看到它确实打开了。现在我们如何关闭它？好吧，我们为AllowOfflineOn 提供了三个选项——PrivateComputersOnly、NoComputers 或AllComputers。我们需要的值是“NoComputers”，因此关闭此功能需要策略名称和AllowOfflineOn参数：

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -AllowOfflineOn NoComputers

如果我们有多个 OWA 邮箱策略，我们可以一次性将其关闭：

Get-OwaMailboxPolicy | Set-OwaMailboxPolicy -AllowOfflineOn NoComputers

用户现在无法使用 OWA 的离线模式，并且他们的电子邮件更加安全。

邮件流 - Office 365 的 EOP 和 Defender（以前称为 ATP）

根据 Exchange Online 中启用的许可和功能，EOP 和 Defender for Office 365 可以提供针对恶意电子邮件的分层防御。这些层包括反垃圾邮件、反网络钓鱼等。

为了首先评估我们所处的位置，我们可以使用名为 ORCA 的 PowerShell 模块来查找差距。 ORCA 是“Office 365 ATP 推荐配置分析器报告”的缩写，它是在 Microsoft 更改其产品的整个命名方案之前命名的。

更准确地说，此脚本现在将检查您的 Defender for Office 365 配置。我们可以通过打开 Windows PowerShell 窗口并输入以下代码来安装此模块：

Install-Module ORCA

Get-ORCAReport

我们还可以在安全与合规中心看到类似的功能，称为“配置分析器”。值得注意的是，修复这里的任何问题完全可以在 GUI 中完成。由于进行了大量的验证检查（超过 60 次），大多数管理员无法使用脚本解决方案来解决这些问题。此 PowerShell 模块应用于对当前保护状态进行单一或自动报告。由于配置的复杂性以及完成此任务所需的功能/PowerShell cmdlet 的范围，通过 PowerShell 进行修复不属于本文的讨论范围。

如果由于某种原因，租户没有 Defender for Office 365 许可，则应进行功能评估来判断产品的价值。我们可以在安全与合规中心→威胁管理→策略→评估Defender for Office 365中开启评估模式

该演示的有效期最长为 90 天，报告包含在评估中，应审查评估的有效性。

基于角色的访问控制 (RBAC)

Exchange 是最早采用基于角色的访问控制概念的产品之一，其中我们通过角色组和管理角色授予 Exchange 中的操作和功能。

管理角色是访问 Exchange 功能（例如日记、合法保留等）所涉及的更精细的权限。而角色组是这些管理角色的分组，用于逻辑上创建某人可以履行的工作职能或角色，以完成 Exchange 中的合法任务。现在，这些相同的概念已从 Exchange 转移到 Exchange Online。

Write-Host " Role Group Members "
Write-Host "----------------------"
$RoleGroup = Get-RoleGroup
Foreach ($Group in $RoleGroup) {
$Name = $Group.Name
$Members = Get-RoleGroupMember -Identity $Name
If ($Null -ne $Members) {
Write-Host "$Name"+": "
Foreach ($Member in $Members) {
$MemberName = $Member.Name
write-Host " - $MemberName"
}
Write-Host ''
} Else {
Write-Host "** $Name has no members."
Write-Host ''}}

运行时，这组代码将帮助我们分析是否有太多用户分配了高权限角色：

对于此租户，角色组中没有任何组拥有超过三个用户，对于大多数场景来说，这是一个很好的使用数字。

运行报告后，应评估每个组的有效帐户以及用户是否仍需要位于该角色组中。如果不是，则应删除帐户。此外，对这些任务的审查应与其他安全审查一起定期进行。

使用 PowerShell 自动化和委派 Exchange/O365 管理任务

您在 Exchange/Exchange Online 的日常操作中是否有频繁重复的任务？立即了解如何：

• 安全地委派基于 PowerShell 的邮箱管理任务
• 允许用户运行某些 PowerShell 脚本而不授予他们管理权限
• 轻松管理、重复和监控 PowerShell 脚本
• 使用 ScriptRunner 的 ActionPack for Exchange Online 中的免费 PowerShell 脚本

免费观看网络研讨会 >

多重身份验证

在 Office 365 中，我们还可以通过多种方式为租户中的用户启用 MFA。我们可以使用条件访问、安全默认值或单独分配它们。在本文中，我们将介绍如何通过单独分配来执行此操作，作为我们如何保护租户中用户的示例。首先，在深入研究之前，让我们回顾一下为什么应该使用多重身份验证：

• 增强安全性——恶意行为者更难危害用户帐户
• 威胁减少 99% 以上

Microsoft 在这方面拥有大量资源， 有关多重身份验证 (MFA) 的 Microsoft 安全页面是一个不错的起点。

为了在用户级别启用 MFA，我们首先需要通过 PowerShell 模块连接到 MSOL 服务。如果您没有安装此软件，请通过运行以下命令来纠正此问题：

Install-Module MSOnline

Connect-MsolService

$st = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$st.RelyingParty = "*"
$st.State = "Enabled"
$sta = @($st)

Set-MsolUser -UserPrincipalName [email protected] -StrongAuthenticationRequirements $sta

(Get-MsolUser -UserPrincipalName [email protected]).StrongAuthenticationRequirements | Fl

现在我们只需要对所有需要 MFA 的用户进行冲洗和重复。完成后，我们可以使用以下代码验证哪些用户拥有此设置：

Get-MsolUser -All | Where {$_.StrongAuthenticationRequirements -ne $Null} |ft DisplayName, UserPrincipalName,StrongAuthenticationRequirements

我们看到我们启用的用户：

这样我们就可以验证我们的用户是否在每个用户的基础上启用了 MFA。

结论

回顾上面执行的配置设置，我们可以得出一些关于安全性、PowerShell 和 Exchange Online 的结论：

• 这可能很复杂
• Microsoft 提供针对多种攻击媒介的分层防御
• 我们可以在 PowerShell 中完成所有这些

为了更全面地了解上述 PowerShell 以及所执行的安全态势，请务必阅读有关每个主题的 Microsoft 文档页面。使用本文以及文档页面，您将能够处理上述任务，并有信心为您的租户配置它们。安全性是 Exchange Online 的关键，因此请确保将上述功能应用于您的租户。