适用于 Data Lake Analytics 的 Azure 安全基线

此安全基线将 Azure 安全基准版本 1.0 中的指导应用于 Data Lake Analytics。 Azure 安全基准提供有关如何在 Azure 上保护云解决方案的建议。 内容按“安全控制”分组,这些控制根据适用于 Data Lake Analytics 的 Azure 安全基准和相关指导定义。

可以使用 Microsoft Defender for Cloud 监视此安全基线及其建议。 Azure Policy定义将列在 Microsoft Defender for Cloud 仪表板的“法规合规性”部分中。

当某个部分具有相关的Azure Policy定义时,它们会列在此基线中,以帮助衡量 Azure 安全基准控件和建议的符合性。 某些建议可能需要付费的 Microsoft Defender 计划才能启用某些安全方案。

注意

已排除不适用于 Data Lake Analytics 或 Microsoft 为其责任方的控件。 要查看 Data Lake Analytics 如何完全映射到 Azure 安全基准,请参阅完整的 Data Lake Analytics 安全基线映射文件

网络安全

有关详细信息,请参阅 Azure 安全基线: 网络安全性

1.1:保护虚拟网络中的 Azure 资源

“指导”:使用 Data Lake Analytics 的防火墙设置来限制外部 IP 范围,以允许来自本地客户端和第三方服务的访问。 可以通过门户、REST API 或 PowerShell 配置防火墙设置。

责任:客户

1.4:拒绝与已知恶意的 IP 地址进行通信

“指导”:使用 Data Lake Analytics 的防火墙设置来限制外部 IP 范围,以允许来自本地客户端和第三方服务的访问。 可以通过门户、REST API 或 PowerShell 配置防火墙设置。

责任:客户

日志记录和监视

有关详细信息,请参阅 Azure 安全基线: 日志记录和监视

2.2:配置中心安全日志管理

“指导”:通过 Azure Monitor 引入日志来聚合安全数据,如 Data Lake Analytics“审核”和“请求”诊断。 在 Azure Monitor 中,使用 Log Analytics 工作区查询和执行分析,并使用 Azure 存储帐户进行长期/存档存储(可以选择使用不可变存储和强制保留等安全功能)。

或者,可以启用 Microsoft Sentinel 或第三方系统信息和事件管理解决方案,并在其中加入数据。

责任:客户

2.3:为 Azure 资源启用审核日志记录

“指导”:启用 Data Lake Analytics 的诊断设置以访问审核和请求日志。 其中包括事件源、日期、用户、时间戳和其他有用元素等数据。

责任:客户

Microsoft Defender for Cloud 监视:Azure 安全基准是 Microsoft Defender for Cloud 的默认策略计划,也是构筑各项 Microsoft Defender for Cloud 建议的基础。 Microsoft Defender for Cloud 会自动启用与此控制相关的 Azure Policy 定义。 与此控制相关的警报可能需要相关服务的 Microsoft Defender 计划。

Azure Policy 内置定义 - Microsoft.DataLakeAnalytics

名称
(Azure 门户)
说明 效果 版本
(GitHub)
应启用 Data Lake Analytics 中的资源日志 对启用资源日志进行审核。 这样便可以在发生安全事件或网络受到威胁时重新创建活动线索以用于调查目的 AuditIfNotExists、Disabled 5.0.0

2.5:配置安全日志存储保留期

指南:在 Azure Monitor 中,根据组织的合规性规则设置 Log Analytics 工作区保持期。 将 Azure 存储帐户用于长期存储和存档存储。

责任:客户

2.6:监视和查看日志

“指导”:分析和监视日志中的异常行为,并定期审查 Data Lake Analytics 资源的结果。 使用 Azure Monitor 的 Log Analytics 工作区查看日志并对日志数据执行查询。 或者,可以启用 Microsoft Sentinel 或第三方系统信息和事件管理解决方案,并在其中加入数据。

责任:客户

2.7:针对异常活动启用警报

“指导”:启用 Data Lake Analytics 的诊断设置,并将日志发送到 Log Analytics 工作区。 将 Log Analytics 工作区加入 Microsoft Sentinel,因为它提供了安全业务流程自动响应 (SOAR) 解决方案。 这样便可以创建 playbook(自动解决方案)并用于修正安全问题。

责任:客户

标识和访问控制

有关详细信息,请参阅 Azure 安全基线: 标识和访问控制

3.1:维护管理帐户的清单

指导:Azure Active Directory (Azure AD) 具有必须显式分配且可查询的内置角色。 使用 Azure AD PowerShell 模块执行即席查询,以发现属于管理组成员的帐户。

责任:客户

3.2:在适用的情况下更改默认密码

“指导”:Data Lake Analytics 没有默认密码的概念,因为身份验证随 Azure Active Directory (Azure AD) 提供,并且受 Azure 基于角色的访问控制 (Azure RBAC) 保护。

责任:客户

3.3:使用专用管理帐户

指南:围绕专用管理帐户的使用创建标准操作程序。

还可以通过使用 Azure Active Directory (Azure AD) Privileged Identity Management 和 Azure 资源管理器来启用即时访问权限。

责任:客户

3.4:使用 Azure Active Directory 单一登录 (SSO)

指导:请尽可能使用 Azure Active Directory (Azure AD) SSO,而不是为每个服务配置单个独立凭据。 使用 Microsoft Defender for Cloud 的标识和访问建议。

责任:客户

3.5:对所有基于 Azure Active Directory 的访问使用多重身份验证

指导:启用 Azure Active Directory (Azure AD) 多重身份验证,并按照 Microsoft Defender for Cloud 标识和访问管理建议操作,以帮助保护 Data Lake Analytics 资源。

责任:客户

3.6:对所有管理任务使用专用计算机(特权访问工作站)

指导:对于需要提升的权限的管理任务,请使用安全的 Azure 托管工作站(也称为特权访问工作站,简称 PAW)。

责任:客户

3.7:记录来自管理帐户的可疑活动并对其发出警报

指导:当环境中出现可疑或不安全的活动时,请使用 Azure Active Directory (Azure AD) 安全报告来生成日志和警报。 使用 Microsoft Defender for Cloud 监视标识和访问活动。

责任:客户

3.8:仅从批准的位置管理 Azure 资源

指导:使用 Azure Active Directory (Azure AD) 命名位置,仅允许从 IP 地址范围或国家/地区的特定逻辑分组进行访问。

责任:客户

3.9:使用 Azure Active Directory

指导:使用 Azure Active Directory (Azure AD) 作为中心身份验证和授权系统。 Azure 基于角色的访问控制 (Azure RBAC),用于精细地控制客户端对 Data Lake Analytics 资源的访问权限。

责任:客户

3.10:定期审查和协调用户访问

指导:Azure Active Directory (Azure AD) 提供日志来帮助发现过时的帐户。 此外,请使用 Azure AD 标识和访问评审来有效管理组成员身份、对企业应用程序的访问以及角色分配。 可以定期评审用户的访问权限,确保只有适当的用户才持续拥有访问权限。

责任:客户

3.11:监视尝试访问已停用凭据的行为

“指导”:为 Data Lake Analytics 和 Azure Active Directory (Azure AD) 启用诊断设置,将所有日志都发送到 Log Analytics 工作区。 在 Log Analytics 中配置所需警报(例如尝试访问禁用的机密)。

责任:客户

3.12:针对帐户登录行为偏差发出警报

“指导”:使用 Azure Active Directory (Azure AD) 的风险和标识保护功能,对检测到的与 Data Lake Analytics 资源相关的可疑操作配置自动响应。 应当通过 Microsoft Sentinel 启用自动响应,以实现组织的安全响应。

责任:客户

数据保护

有关详细信息,请参阅 Azure 安全基线: 数据保护

4.1:维护敏感信息的清单

“指导”:使用标记可以帮助跟踪存储或处理敏感信息的 Data Lake Analytics 资源。

责任:客户

4.2:隔离存储或处理敏感信息的系统

“指导”:使用单独的订阅、管理组对各个安全域(例如环境、数据敏感度)实施隔离。 你可以限制 Data Lake Analytics,以控制对应用程序和企业环境所需 Data Lake Analytics 资源的访问级别。 配置防火墙规则后,仅通过指定网络集请求数据的应用程序才能访问你的 Data Lake Analytics 资源。 可以通过 Azure 基于角色的访问控制 (Azure RBAC) 来控制对 Azure Data Lake Analytics 的访问。

责任:客户

4.3:监视和阻止未经授权的敏感信息传输

“指导”:数据丢失防护功能尚不可用于 Azure Data Lake Analytics 资源。 如果需要出于合规性目的使用这些功能,请实施第三方解决方案。

对于 Microsoft 管理的基础平台,Microsoft 会将所有客户内容视为敏感数据,并全方位防范客户数据丢失和泄露。 为了确保 Azure 中的客户数据保持安全,Microsoft 已实施并维护一套可靠的数据保护控制机制和功能。

责任:客户

4.4:加密传输中的所有敏感信息

“指导”:默认情况下,Microsoft Azure 资源将协商 TLS 1.2。 确保连接到 Data Lake Analytics 的任何客户端都可以使用 TLS 1.2 或更高版本进行协商。

责任:共享

4.5:使用有效的发现工具识别敏感数据

“指导”:数据标识功能尚不可用于 Azure Data Lake Analytics 资源。 如果需要出于合规性目的使用这些功能,请实施第三方解决方案。

责任:客户

4.6:使用 Azure RBAC 控制对资源的访问

指导:使用 Azure 基于角色的访问控制 (Azure RBAC) 来控制用户与服务交互的方式。

责任:客户

4.8:静态加密敏感信息

指导:数据存储在默认 Data Lake Storage Gen1 帐户中。 对于静态数据,Data Lake Storage Gen1 支持“默认启用”透明加密。

责任:共享

4.9:记录对关键 Azure 资源的更改并对此类更改发出警报

指导:将 Azure Monitor 与 Azure 活动日志结合使用,以在 Azure Data Lake Analytics 资源生产实例发生更改时创建警报。

责任:客户

漏洞管理

有关详细信息,请参阅 Azure 安全基线: 漏洞管理。

5.1:运行自动漏洞扫描工具

指导:请按照 Microsoft Defender for Cloud 关于确保 Azure Data Lake Analytics 资源安全的建议操作。

Microsoft 对支持 Azure Data Lake Analytics 的基础系统执行漏洞管理。

责任:客户

5.5:使用风险评级过程来确定已发现漏洞的修正措施的优先级

指南:使用通用风险评分程序(例如通用漏洞评分系统)或第三方扫描工具提供的默认风险评级。

责任:客户

清单和资产管理

有关详细信息,请参阅 Azure 安全基线: 清单和资产管理

6.1:使用自动化资产发现解决方案

“指导”:使用 Azure Resource Graph 来查询和发现订阅中的所有资源(如计算、存储、网络、端口和协议等)。 确保租户中具有适当的(读取)权限,并枚举所有 Azure 订阅以及订阅中的资源。

尽管可以通过 Azure Resource Graph 浏览器发现经典 Azure 资源,但我们强烈建议你今后创建并使用 Azure 资源管理器资源。

责任:客户

6.2:维护资产元数据

指导:将标记应用到 Azure资源,以便有条理地将元数据组织成某种分类。

责任:客户

6.3:删除未经授权的 Azure 资源

“指导”:在适用的情况下,请使用标记、管理组和单独的订阅来组织和跟踪 Azure Data Lake Analytics 资源。 定期核对清单,确保及时地从订阅中删除未经授权的资源。

此外,使用 Azure Policy 对可使用以下内置策略定义在客户订阅中创建的资源类型施加限制:

  • 不允许的资源类型

  • 允许的资源类型

访问所引用的链接可获得更多信息。

责任:客户

6.5:监视未批准的 Azure 资源

指导:在 Azure Policy 中使用以下内置策略定义,对可以在客户订阅中创建的资源类型施加限制:

  • 不允许的资源类型

  • 允许的资源类型

此外,请使用 Azure Resource Graph 来查询/发现订阅中的资源。

责任:客户

6.9:仅使用已批准的 Azure 服务

指南:在 Azure Policy 中使用以下内置策略定义,对可以在客户订阅中创建的资源类型施加限制:

  • 不允许的资源类型
  • 允许的资源类型

访问所引用的链接可获得更多信息

责任:客户

6.11:限制用户与 Azure 资源管理器进行交互的能力

指南:配置 Azure 条件访问,使其通过为“Microsoft Azure 管理”应用配置“阻止访问”,来限制用户与 Azure 资源管理器进行交互的能力。

责任:客户

安全配置

有关详细信息,请参阅 Azure 安全基线: 安全配置

7.1:为所有 Azure 资源建立安全配置

“指导”:使用“Microsoft.DataLakeAnalytics”命名空间中的 Azure Policy 别名创建自定义策略,以审核或强制实施 Azure Data Lake Analytics 服务的配置。 你还可以使用与 Azure Data Lake Analytics 相关的内置策略定义,例如:

  • 应启用 Data Lake Analytics 中的诊断日志

访问所引用的链接可获得更多信息

责任:客户

7.3:维护安全的 Azure 资源配置

指导:使用 Azure Policy“[拒绝]”和“[不存在则部署]”效果对不同的 Azure 资源强制实施安全设置。

责任:客户

7.5:安全存储 Azure 资源的配置

指导:使用 Azure Repos 安全地存储和管理代码,如自定义 Azure 策略、Azure 资源管理器模板、Desired State Configuration 脚本等。若要访问在 Azure DevOps 中管理的资源,可以向特定用户、内置安全组或 Azure Active Directory (Azure AD)(如果与 Azure DevOps 集成)中定义的组或 Azure AD(如果与 TFS 集成)授予或拒绝授予权限。

责任:客户

7.9:为 Azure 资源实施自动配置监视

指导:使用“Microsoft.DataLakeAnalytics”命名空间中的 Azure Policy 别名创建自定义策略,以对系统配置发出警报、进行审核和强制实施。 使用 Azure Policy 的“[审核]”、“[拒绝]”和“[不存在则部署]”效果自动强制实施 Azure Data Lake Analytics 资源的配置。

责任:客户

7.13:消除意外的凭据透露

指南:实施凭据扫描程序来识别代码中的凭据。 凭据扫描程序还会建议将发现的凭据转移到更安全的位置,例如 Azure Key Vault。

责任:客户

恶意软件防护

有关详细信息,请参阅 Azure 安全基线: 恶意软件防护

8.2:预先扫描要上传到非计算 Azure 资源的文件

“指导”:在支持 Azure 服务(例如 Azure Data Lake Analytics)的底层主机上已启用 Microsoft 反恶意软件,但是,该软件不会针对客户内容运行。

预扫描上传到 Azure 资源的任何内容,如应用服务、Data Lake Analytics、Blob 存储等。Microsoft 无法访问这些实例中的数据。

责任:客户

数据恢复

有关详细信息,请参阅 Azure 安全基线: 数据恢复

9.1:确保定期执行自动备份

“指导”:Data Lake Analytics 作业日志和数据输出存储在底层 Data Lake Storage Gen1 服务中。 可以使用各种方法来复制数据,包括 ADLCopy、Azure PowerShell 或 Azure 数据工厂。 你还可以使用 Azure 自动化来定期自动备份数据。

责任:客户

9.2:执行完整系统备份,并备份客户管理的所有密钥

“指导”:Data Lake Analytics 作业日志和数据输出存储在底层 Data Lake Storage Gen1 服务中。 可以使用各种方法来复制数据,包括 ADLCopy、Azure PowerShell 或 Azure 数据工厂。

责任:客户

9.3:验证所有备份,包括客户管理的密钥

指导:定期对备份数据执行数据恢复,以测试数据的完整性。

责任:客户

9.4:确保保护备份和客户管理的密钥

“指导”:默认情况下,Data Lake Analytics 备份存储于 Data Lake Storage Gen1 或 Azure 存储支持加密,且无法关闭。 你应将备份视为敏感数据,并应用相关的访问和数据保护控制作为此基线的一部分。

责任:客户

事件响应

有关详细信息,请参阅 Azure 安全基线: 事件响应

10.1:创建事件响应指导

指南:为组织制定事件响应指南。 确保在书面的事件响应计划中定义人员职责,以及事件处理/管理从检测到事件后审查的各个阶段。

责任:客户

10.2:创建事件评分和优先级设定过程

指导:Microsoft Defender for Cloud 可以为每个警报分配严重性,以帮助你优先处理应先调查的警报。 严重性取决于 Microsoft Defender for Cloud 在发出警报时所依据的检测结果或分析结果的置信度,以及导致发出警报的活动背后的恶意企图的置信度。

此外,使用标记清楚地标记订阅(例如生产、非生产)并创建命名系统来对 Azure 资源进行明确标识和分类,特别是处理敏感数据的资源。 你的责任是根据发生事件的 Azure 资源和环境的关键性确定修正警报的优先级。

责任:客户

10.3:测试安全响应过程

指导:定期执行演练来测试系统的事件响应功能,以帮助保护 Azure 资源。 查明弱点和差距,并根据需要修改你的响应计划。

责任:客户

10.4:提供安全事件联系人详细信息,并针对安全事件配置警报通知

指导:如果 Microsoft 安全响应中心 (MSRC) 发现数据被某方非法访问或未经授权访问,Microsoft 会使用安全事件联系信息联系用户。 事后审查事件,确保问题得到解决。

责任:客户

10.5:将安全警报整合到事件响应系统中

指导:使用连续导出功能导出 Microsoft Defender for Cloud 警报和建议,以帮助确定 Azure 资源的风险。 使用连续导出可以手动导出或者持续导出警报和建议。 可以使用 Microsoft Defender for Cloud 数据连接器将警报流式传输给 Microsoft Sentinel。

责任:客户

10.6:自动响应安全警报

指导:使用 Microsoft Defender for Cloud 的工作流自动化功能,通过“逻辑应用”自动触发对安全警报和建议的响应,以保护 Azure 资源。

责任:客户

渗透测试和红队练习

有关详细信息,请参阅 Azure 安全基线: 渗透测试和红队演练

11.1:定期对 Azure 资源执行渗透测试,确保修正所有发现的关键安全问题

指导:请遵循 Microsoft 云渗透测试互动规则,确保你的渗透测试不违反 Microsoft 政策。 使用 Microsoft 红队演练策略和执行,以及针对 Microsoft 托管云基础结构、服务和应用程序执行现场渗透测试。

责任:共享

后续步骤