AMS 高级版中的标准控件 - AMS 高级用户指南

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

AMS 高级版中的标准控件

以下是 AMS 中的标准控件：

以下是 001-标记配置的标准控件。

  1. AMS 团队出于运营和管理目的所需的所有 AWS 资源都必须具有以下键值对。

    • AppId= AMSInfrastructure

    • 环境= AMSInfrastructure

    • AppName = AMSInfrastructure

    • AMSResource=没错

  2. 除了先前列出的标签外，AMS 团队要求的所有标签都必须具有 AMS 前缀列表中提到的前缀（参见注意）。

  3. AMS 团队（AppId、环境和 AppName）要求的标签值可以根据您的更改请求在您创建的任何资源上进行更改。

  4. 不得根据您的更改请求删除 AMS 要求的堆栈上的任何标签。

  5. 如第 2 点所述，您不能对基础设施使用 AMS 标签命名约定。

  6. 您可以在 AMS 所需的资源中创建自定义标签（通常用于账单和成本报告用例）。如果资源是通过堆栈更新而不是通过更新模板来更新的，则会保留自定义标签。

注意

AMS 前缀列表

  1. ams-*

  2. AWSManaged服务*

  3. /ams/ *

  4. 上午*

  5. 上午*

  6. Ams*

  7. mc*

  8. MC*

  9. 麦克*

  10. 哨兵*

  11. 哨兵*

  12. 托管服务*

  13. Newams*

  14. AWS_*

  15. 啊*

  16. VPC_*

  17. CloudTrail*

  18. Cloudtrail *

  19. /aws_reserved/

  20. 摄取*

  21. EPSDB*

  22. MMS*

  23. TemplateId*

  24. StackSet-ams*

  25. StackSet-AWS 着陆区

  26. IAMPolicy*

  27. 客户-mc-*

  28. 根*

  29. LandingZone*

  30. StateMachine*

  31. 代码部署服务角色

  32. 管理主机

  33. sentinel.int。

  34. eps

  35. UnhealthyInServiceBastion

  36. ms-

ID 技术标准
1.0 超时持续时间
1.1 联邦用户的默认超时会话为一小时，最多可以增加到四小时。
1.2 默认堆栈访问时间为 12 小时。
2.0 AWS 主账号使用情况
2.1 如果出于任何原因使用了根账户，则 GuardDuty 必须将 Amazon 配置为生成相关调查结果。
2.2 对于单账户着陆区 (SALZ) 账户和多账户着陆区 (MALZ) 管理账户（以前称为账户），根用户 Master/Billing 账户必须启用虚拟 MFA，并且在账户注册期间丢弃 MFA 软令牌，这样 AMS 和客户都无法以 root 身份登录。必须与 AMS 云服务交付管理器 (CSDM) 一起执行标准的 AWS root 密码丢失流程。此配置必须在 AMS 托管账户的生命周期内保留。
2.3 您不得为 root 账户创建访问密钥。
3.0 用户创建和修改
3.1 无需任何时间限制策略即可创建 users/roles 具有编程访问权限和只读权限的 IAM。但是，不允许读取账户中所有 Amazon Simple Storage Service 存储桶中的对象（例如 S3:GetObject）的权限。
3.1.1 可以使用时间限制策略（最长 180 天）创建用于控制台访问和只读权限的 IAM 人类用户，而时间限制策略将生成风险通知。removal/renewal/extension但是，不允许读取账户中所有 S3 存储桶中的对象（例如 S3:GetObject）的权限。
3.2 在不接受风险的情况下，不得在客户账户中创建具有任何基础架构变更权限（写入和权限管理）的 IAM 用户和用于控制台和编程访问的角色。S3 对象级写入权限存在例外情况，只要特定的存储桶在范围内，并且对非 AMS 相关标签进行标记操作，则无需接受风险即可使用这些权限。
3.3 无需任何时间限制政策，即可创建具有编程访问权限、已命名customer_servicenow_user并customer_servicenow_logging_user需要 ServiceNow 集成到 SALZ 或 MALZ 应用程序账户以及*核心账户*的 IAM 用户。
3.4 可以创建具有编程访问权限、在 SALZ customer_cloud_endure_policy 和 MALZ 账户中 CloudEndure 集成所需的和customer_cloud_endure_deny_policy（具有只读访问权限）的 IAM 用户，但需要在计划迁移期间制定有时间限制的策略。时间限制最长可为 180 天，无需任何 RA。SCP还被授权更改MALZ账户，以允许这些政策在规定的期限内发挥作用。您可以根据需要定义适当的迁移窗口，并根据需要进行调整。
4.0 政策、行动和 APIs
4.1 您在 SALZ 账户中的所有 IAM 用户和角色都必须附加默认的客户拒绝政策 (CDP)，以保护 AMS 基础设施免受意外或故意损坏。
4.2 SCPs 必须在 MALZ 的所有 AMS 托管账户中启用 AMS。
4.3 能够对 KMS 密钥执行管理操作（例如PutKeyPolicyScheduleKeyDeletion、和）的身份必须仅限于 AMS 操作员和自动化主体。
4.4 在不接受风险的情况下，策略不得向管理员提供等同于 “效果”：“允许” 和 “操作”：“*” 而不是 “资源”：“*” 的语句。
4.5 IAM 策略不得包含任何包含在不接受风险的情况下对任何存储桶执行 “允许 S3: ***” 操作的操作。
4.6 不得允许针对客户 IAM 策略中的 AMS 基础设施密钥的 KMS 密钥策略进行 API 调用。
4.7 不得允许绕过变更管理流程 (RFC) 的操作，例如启动或停止实例、创建 S3 存储桶或 RDS 实例等。
4.8 不得允许对 Amazon Route 53 中的 AMS 基础设施 DNS 记录进行更改的操作。
4.9 按照正当程序创建的具有控制台访问权限的 IAM 人类用户，除了信任策略、代入角色和限时策略外，不得直接附加任何策略。
4.10 可以在同一账户中创建对特定密钥或命名空间具有读取 AWS Secrets Manager 权限的 Amazon EC2 实例配置文件。
4.11 可以将 AWS Managed Services 变更管理 (AMSCM) 或 AWS Managed Services 服务知识管理系统 (AMSSKMS) 权限添加到任何角色（可以打开）。SR/Incident/RFC
4.12 IAM 策略不得包含任何包含在任何 AMS Amazon 日志组上的 “允许日志:DeleteLogStream ” DeleteLogGroup 和 “日 CloudWatch 志:” 操作的操作。
4.13 不得允许创建多区域密钥。
4.14 要提供对您的账户中尚未创建 ARNs 的 S3 存储桶的访问权限，请使用特定于服务的 S3 条件密钥s3:ResourceAccount来指定账号。
4.15 您可以对自定义控制面板拥有查看、创建、列出和删除权限，但只能在 Amazon 控制面板上查看和列 CloudWatch 出。
4.15.1 您可以查看、创建、列出和删除您的 S3 存储镜头自定义仪表板。
4.16 可以授予与 SQL Workbench 相关的完全权限， roles/users 允许其使用 Amazon Redshift 数据库。
4.17 可以将任何 AWS CloudShell 权限授予客户角色作为 CLI 的替代方案。
4.18 以可信委托人 AWS 服务 为的 IAM 角色也必须符合 IAM 技术标准。
4.19 服务关联角色 (SLRs) 不受 AMS IAM 技术标准的约束，因为它们由 IAM 服务团队构建和维护。
4.20 IAM 策略不得允许对账户中所有存储桶的 Amazon S3 存储桶对象（例如 Amazon S3:GetObject）进行不受限制的读取权限：

  • 在开发者模式账户中：违规行为会导致风险通知

  • 在非开发者模式账户中：违规行为需要接受风险

4.21 可以向客户授予资源类型 “savingsplan” 的所有 IAM 权限。
4.22 AMS 工程师不得在任何数据存储服务（例如 Amazon S3、Amazon Relational Database Service、Amazon DynamoDB 等）或操作系统文件系统中手动复制或移动客户数据（文件、S3 对象、数据库）。
4.23 不得修改 SCP 策略以允许任何 AMS 托管账户中的任何其他访问权限。
4.24 不得允许对 SCP 政策进行任何可能破坏 AMS 基础设施或管理能力的更改。（注意：AMS 资源带有标签AppId= AMSInfrastructure，紧随其后的是 AMS 受保护的命名空间）。
4.25 AMS 自动 IAM 配置功能必须作为可选功能在您的账户中启用。
4.26 AMS 人工扮演的角色或用户不得访问客户在 S3、RDS、DynamoDB、Redshift、Elasticache、Elasticache、EFS 和中的内容。 FSx此外，在操作员角色中，必须明确拒绝访问其他 AWS 服务 人 APIs 发布的已知新内容，且授予客户内容访问权限。
5.0 联合身份验证
5.1 必须在 AMS 托管账户中使用联合身份验证进行配置。
5.2 从 AMS AD 到您的活动目录只能存在单向传出信任（AMS AD 信任本地 AD）。
5.3 AMS 托管应用程序账户中不得存在用于向 AMS 进行身份验证的身份存储。
6.0 跨账户政策
6.1 根据客户记录，可以配置属于同一客户的 AMS 账户之间的 IAM 角色信任策略。
6.2 只有当非 AMS 账户由同一 AMS 客户拥有时，才必须配置 AMS 账户和非 AMS 账户之间的 IAM 角色信任策略（通过确认他们属于同一个 AWS Organizations 账户或将电子邮件域名与客户的公司名称进行匹配）。
6.3 如果不接受风险，则不得配置 AMS 账户和第三方账户之间的 IAM 角色信任策略。
6.4 可以配置跨账户策略，以便在同一客户的 AMS 账户 CMKs 之间访问任何客户管理的账户。
6.5 可以配置跨账户策略，通过 AMS 账户访问非 AMS 账户中的任何 KMS 密钥。
6.6 在不接受风险的情况下，不得允许第三方账户访问AMS账户内的任何 KMS 密钥的跨账户政策。
6.6.1 只有当非 AMS 账户由同一 AMS 客户拥有时，才能配置跨账户策略，允许非 AMS 账户访问 AMS 账户内的任何 KMS 密钥。
6.7 可以配置跨账户策略，用于访问可在同一客户的 AMS 账户之间存储数据的任何 S3 存储桶数据或资源（例如 Amazon RDS、Amazon DynamoDB 或 Amazon Redshift）。
6.8 可以配置跨账户策略，从具有只读访问权限的 AMS 账户访问可在非 AMS 账户中存储数据的任何 S3 存储桶数据或资源（例如 Amazon RDS、Amazon DynamoDB 或 Amazon Redshift）。
6.9 只有在非 AMS 账户归同一 AMS 客户所有（通过确认他们属于同一个账户或将电子邮件域名与客户匹配）的情况下，才必须配置跨账户策略，才能访问任何 S3 存储桶数据或可以存储数据的资源（例如 Amazon RDS、Amazon DynamoDB 或 Amazon Redshift），并拥有从 AMS 到非 AMS 账户（或非 AMS 到 AMS 账户）的写入权限的公司名称）。 AWS Organizations
6.10 可以配置跨账户策略，从具有只读权限的 AMS 账户访问第三方账户中可以存储数据的任何 S3 存储桶数据或资源（例如 Amazon RDS、Amazon DynamoDB 或 Amazon Redshift）。
6.11 不得配置跨账户策略，用于从具有写入权限的 AMS 账户访问第三方账户中可以存储数据的任何 S3 存储桶数据或资源（例如 Amazon RDS、Amazon DynamoDB 或 Amazon Redshift）。
6.12 未经风险接受，不得配置第三方账户用于访问 AMS 客户 S3 存储桶或可以存储数据的资源（例如 Amazon RDS、Amazon DynamoDB 或 Amazon Redshift）的跨账户策略。
7.0 用户组
7.1 允许具有只读权限和非变异权限的 IAM 群组。
8.0 基于资源的策略
8.1 必须通过附加基于资源的策略来保护 AMS 基础设施资源，使其免受未经授权的身份的管理。
8.2 除非您明确指定不同的策略，否则您的资源必须使用基于资源的最低权限策略进行配置。
9.0 自助配置服务 (SSP)
9.1 无论是否接受任何风险，都不得修改 AMS 默认 IAM 角色或策略（包括实例配置文件、SSP、模式）。信任策略允许例外（不接受风险）。默认 SSP 角色还允许对角色、策略或用户更改进行标记。
9.3 除默认角色外，Systems Manager Automation 控制台角色的 SSP 策略不能附加到任何自定义角色。只有在确保将策略关联到自定义角色不会为默认 SSP 服务的预期设计之外提供额外权限之后，才能将其他 SSP 策略附加到自定义 IAM 角色。

以下是 003-网络安全的标准控件：

ID 技术标准
联网
1.0 只能通过堡垒主机、堡垒主机 VPC CIDR 范围或同一 EC2 实例 VPC CIDR 范围通过 SSH 或 RDP 访问所有实例。
2.0 允许在 EC2 实例上使用弹性 IP
3.0 必须使用 AMS 控制平面，进而在数据平面中使用 TLS 1.2+。
4.0 所有出口流量都必须使用账户 IGW 或 TGW 通过。
5.0 如果安全组未按照 9.0 连接到负载均衡器，则其入站规则中不得将源设置为 0.0.0.0/0
6.0 未经风险接受，不得将 S3 存储桶或对象公开。
7.0 服务器管理端口 SSH/22 或 SSH/2222（不是 SFTP/2222）、TELNET/23、RDP/3389、winRM/5985-5986、VNC/ 5900-5901 TS/CITRIX/1494 或 1604、LDAP/389 或 636 以及 RPC/135、NETBIOS/137-139 上的访问权限。
8.0 不得允许公共端口（mySQL/3306、PostgreSQL/5432、Oracle/1521、MSSQL/1433）或自定义端口进行数据库管理访问，不得允许未通过 DX、vpc-Peer 或通过安全组通过 VPC 路由到 VPC 的公共端口。 IPs
8.1 任何可以存储客户数据的资源都不应直接暴露在公共互联网上。
9.0 仅允许负载均衡器通过端口 HTTP/80、HTTPS/8443 和 HTTPS/443 直接访问应用程序，但不允许直接访问任何计算资源，例如实例、容器等。 EC2 ECS/EKS/Fargate
10.0 可以允许应用程序通过端口 HTTP/80 和 HTTPS/443 从客户私有 IP 范围进行访问。
11.0 未经风险接受，不得允许对控制 AMS 基础设施访问权限的安全组进行任何更改。
12.0 每次请求将安全组附加到实例时，AMS Security 都会参考这些标准。
13.0 只有通过 DX、vpc-Peer 或 VPN 路由到 VPC 的私有 IP 范围才能允许客户通过端口 3389 和 22 访问堡垒。
14.0 只有当非 AMS 账户由同一 AMS 客户（通过确认他们属于同一 AWS 组织账户或通过将电子邮件域与客户的公司名称进行匹配）时，才必须使用内部工具配置私有托管区域与 VPCs 从 AMS 到非 AMS 账户（或非 AMS 到 AMS 账户）的跨账户关联。
15.0 可以允许属于同一客户的账户之间的 VPC 对等连接。
16.0 只要两个账户均归同一个客户所有（通过确认他们属于同一个账户，或者将电子邮件域名与客户的公司名称进行匹配）， AMIs 即可使用内部工具与非 AMS AWS Organizations 账户共享 AMS 库。
17.0 未经风险认可，不得在任何安全组中配置 FTP 端口 21。
18.0 只要所有账户均归客户所有，则允许通过公交网关进行跨账户网络连接。
19.0 不允许将私有子网设为公有子网
20.0 不得允许与第三方账户（不归客户所有）的 VPC 对等连接。
21.0 不得允许使用第三方账户（不归客户所有）连接 Transit Gateway。
22.0 AMS 向客户提供服务所需的任何网络流量都不得在客户网络出口点被屏蔽。
23.0 允许与同一客户共享由同一客户 AWS 账户 拥有的解析规则，并附上风险通知
19.0 ICMP
19.1 EC2 从买家基础设施向 Amazon 发出的入库 ICMP 请求需要风险通知。
19.2 允许通过安全组通过 DX、vpc-Peer 或 VPN 从公共 IPs 路由到 Amazon VPC 的入站请求。
19.3 来自公众的入站请求 IPs 如果未通过 DX、vpc-Peer 或 VPN 通过安全组路由到 Amazon VPC，则需要接受风险。
19.4 允许从 Amazon EC2 向任何目的地发出出站 ICMP 请求。
20.0 安全组共享
20.1

如果安全组符合此安全标准，则可以在同一个账户和同一组织 VPCs 中的账户之间共享该安全组。

20.2

如果安全组不符合此标准，并且此安全组以前需要接受风险，则 VPCs 在不接受新的 VPC 或账户风险的情况下，不允许在同一账户之间或同一组织中的账户之间使用安全组共享功能。

以下是 004-渗透测试的标准控件

  1. AMS 不支持 pentest 基础架构。这是客户的责任。例如，Kali 不是 AMS 支持的 Linux 发行版。

  2. 客户需要遵守渗透测试。

  3. 如果客户想在账户内进行基础设施渗透测试，则应提前 24 小时预先通知 AMS。

  4. AMS 将根据客户在变更请求或服务请求中明确说明的客户要求提供客户渗透测试基础设施。

  5. 客户渗透测试基础设施的身份管理由客户负责。

以下是 005 的标准控件- GuardDuty

  1. GuardDuty 必须始终在所有客户账户中启用。

  2. GuardDuty 来自 MALZ 客户托管应用程序账户 (CMA) 的调查结果不会给运营团队带来警报。

  3. GuardDuty 警报必须存储在同一账户或同一组织下的任何其他托管账户中。

  4. GuardDuty 不得使用的 “可信 IP 列表” 功能。相反，可以将自动存档用作替代方案，这对于审计目的很有用。

  5. GuardDuty 不得在 MALZ 中启用管理员委派，因为委派的管理员可以在不接受风险的情况下执行高权限操作，例如 GuardDuty 在其他账户中禁用。

  6. GuardDuty 自动存档过滤器应使用最小范围来获得最大回报。例如，如果 AMS IPs 在不同的 CIDR 区块中看到多个不可预测的，并且有适合使用的公司 ASN，则使用 ASN。但是，如果您可以将范围缩小到特定范围或 /32 地址，则可以将范围缩小到这些范围或 /32 地址。

以下是 006-主机安全的标准控件

  • 必须始终在所有 EC2 实例上运行防病毒代理。 （例如，趋势科技 DSM）。

  • 必须启用防恶意软件模块。

  • EPS 代理必须包含所有要扫描的目录和文件。

  • 通过防病毒解决方案隔离的文件可以按需与您共享。

  • 不应安装第三方端点安全解决方案。

  • 必须将防病毒签名更新频率设置为每天至少更新一次。

  • 必须将计划扫描频率设置为每月至少一次。

  • 必须启用实时（按访问时）扫描并始终处于运行状态。

  • AMS 不得在您的实例上执行任何非 AMS 拥有或创作的自定义脚本。（注意：您可以通过堆栈管理员访问权限 CT 使用堆栈管理员访问权限或使用AWS Systems Manager 自动化 (AMS SSP) 来实现。

  • 不得在 Windows 主机上禁用网络级身份验证 (NLA)。

  • 根据配置的补丁周期，主机操作系统必须安装最新的安全补丁。

  • AMS 托管账户的账户中不得有非托管实例。

  • 不得允许 AMS 在您的实例上创建本地管理员账户。

  • EC2 不得在开启时创建密钥对。

  • 您不得使用声明为寿命终止 (EOL) 的操作系统，也不得使用供应商或第三方不提供进一步安全支持的操作系统。

以下是 007-Logging 的标准控件

ID 技术标准
1.0 日志类型
1.1 操作系统日志：所有主机都必须记录最少的主机身份验证事件、所有使用提升权限的访问事件以及访问和权限配置的所有更改的访问事件，包括成功和失败。
1.2 AWS CloudTrail：必须启用并配置 CloudTrail 管理事件日志以将日志传送到 S3 存储桶。
1.3 VPC 流日志：必须通过 VPC 流日志记录所有网络流量日志。
1.4 Amazon S3 服务器访问日志：AMS 强制存储日志的 S3 存储桶必须启用服务器访问日志记录。
1.5 AWS Config 快照： AWS Config 必须记录所有区域中所有受支持资源的配置更改，并且每天至少将配置快照文件传送到 S3 存储桶一次。
1.6 端点保护系统 (EPS) 日志：必须启用并配置 EPS 解决方案日志记录，才能将日志传送到 CloudWatch 日志日志组。
1.7 应用程序日志：客户有权在其应用程序中启用日志记录并存储在 CloudWatch 日志日志组或 S3 存储桶中。
1.8 S3 对象级日志记录：客户有权在其 S3 存储桶中启用对象级日志记录。
1.9 服务日志：客户可以像任何核心服务一样启用和转发 SSP 服务的日志。
1.10 Elastic Loa Classic/Application Load Balancer/Network d Balancing（Load Balancer）日志：访问和错误日志条目必须存储在 AMS 2.0 托管的 S3 存储桶中。
2.0 访问控制
2.1 您不得拥有存储日志和日志; CloudWatch 日志组的 AMS 要求的 S3 存储桶中的写入或删除权限。
2.2 您必须对账户中的所有日志具有只读访问权限。
2.3 作为存储桶策略中的原则，AMS 规定的存储日志的 S3 存储桶不得允许第三方账户用户使用。
2.4 未经您的授权安全联系人明确批准，不得删除来自 CloudWatch 日志日志组的日志。
3.0 日志保留
3.1 AMS 规定的 CloudWatch 日志日志组的日志保留期必须至少为 90 天。
3.2 AMS 规定的用于存储日志的 S3 存储桶的日志保留期必须至少为 18 个月。
3.3 AWS Backup 在支持的资源上，快照应至少保留 31 天。
4.0 加密
4.1 必须在 AMS Teams 要求的存储日志的所有 S3 存储桶中启用加密。
4.2 从客户账户向任何其他账户转发的任何日志都必须经过加密。
5.0 完整性
5.1 必须启用日志文件完整性机制。必须在 AMS 团队要求的 AWS CloudTrail 跟踪中配置 “日志文件验证”。
6.0 日志转发
6.1 任何日志都可以从一个 AMS 账户转发到同一客户的另一个 AMS 账户。
6.2 只有当非 AMS 账户由同一 AMS 客户拥有时，才能将任何日志从 AMS 转发到非 AMS 账户。
6.3 不得将客户账户中的任何日志转发到第三方账户（该账户不归客户所有）。

以下是 008-AMS-MAD 的标准控件

ID 技术标准
1.0 访问控制
1.1 只有具有交互式登录和自动化任务的 AMS 特权用户才能登录管理主机，以管理客户账户中的托管 AD。
1.2 AD 管理员只能拥有委派的管理员权限（AMS 委派管理员组）。
1.3 登录客户 AD 环境（管理主机或实例）的工程师必须具有有时限的访问权限。
1.4 客户在 EC2 实例中使用远程服务器管理员工具对 AD 对象具有只读访问权限。
1.5 不得允许活动目录用户或组拥有管理权限。
1.6 AWS 允许与同一客户 AWS 账户 拥有的目录共享，并附有风险通知。
2.0 服务账号
2.1 必须在应用程序支持的地方使用群组托管服务帐户 (GMSA)，而不是标准服务帐户。
2.2 所有其他服务账户都必须在风险接受流程之后创建。
2.3 除非客户明确要求，否则不得重复使用 AD 安全组。应创建新的 AD 组。必须将请求访问服务帐户的计算机对象添加到新的安全组中。
2.4 必须在 “托管服务账户” 组织单位 (OU) 下添加任何 GMSA 服务帐户。
2.5 必须在 “用户→服务帐户” OU下添加任何非GMSA服务帐户。
3.0 组策略对象 (GPO)
3.1 如果 “Windows 设置 > 安全设置” GPO 下的任何设置以任何方式降低了当前状态下的帐户安全状况，则不得对其进行修改。
3.2 在 MALZ 中，从申请创建 GPO 的应用程序账户 RFCs 提交，GPO 必须关联到与应用程序账户对应的 OU。任何 GPOs 影响所有帐户的内容都必须来自共享服务帐户。
3.3 必须将 Active Directory 域下所有服务器的默认 RDP 空闲会话超时设置为 15 分钟。
4.0 活动目录信任
4.1 如果条件转发器通过 DX、vpc-Peer 或 VPN 路由到 VPC，则允许单向出站信任（AMS 托管目录到客户目录）。 IPs
5.0 其他
5.1 必须启用日志文件完整性机制。必须在 AMS 团队要求的 AWS CloudTrail 跟踪中配置 “日志文件验证”。
6.0 日志转发
6.1 客户用户、群组、计算机对象、OU 或其他实体不得按照 AMS 命名惯例使用 AMS 命名惯例。
6.2 所有这些都 OUs 必须由 AMS 管理。

以下是 009-杂项的标准控件

  • 如果在资源、对象、数据库或文件系统中启用了加密，则不得将其禁用。