14. 安全最佳实践¶

Ansible Tower 在开箱即用时以安全的方式部署，以用于自动执行典型环境。但是，管理某些操作系统环境、自动化和自动化平台可能需要一些额外的最佳实践来确保安全性。本文档描述了以安全方式自动执行的最佳实践。

14.1. 一般最佳实践¶

应用程序的安全性与基础系统一样。要保护 Red Hat Enterprise Linux，请从适合版本的安全性指南开始

对于 Red Hat Enterprise Linux 7：https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/
对于 Red Hat Enterprise Linux 8：https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/index

14.2. 了解 Ansible 和 Tower 的架构¶

Ansible 和 Ansible Tower 包含一个通用、声明式自动化平台。这意味着一旦 Ansible 剧本启动（通过 Tower 或直接在命令行上），提供给 Ansible 的剧本、清单和凭据被认为是事实来源。如果需要围绕特定剧本内容、作业定义或清单内容的外部验证制定策略，则必须在启动自动化之前（无论是通过 Tower Web UI 还是 Tower API）执行这些过程。

这些可以采取多种形式。使用源代码控制、分支和强制代码审查是 Ansible 自动化的最佳实践。有许多工具可以帮助在使用源代码控制时创建流程流。

在更高层次上，许多工具允许围绕任意工作流（包括自动化）创建审批和基于策略的操作；这些工具然后可以使用 Tower 的 API 通过 Ansible 执行自动化。

我们建议所有 Ansible Tower 客户在安装时选择安全的默认管理员密码。有关更多信息，请参见剧本设置。

Ansible Tower 在某些众所周知的端口上公开服务，例如端口 80 用于 HTTP 流量，端口 443 用于 HTTPS 流量。我们建议您不要在开放互联网上公开 Ansible Tower，这将大大减少安装的攻击面。

14.3. 授予访问权限¶

授予对系统某些部分的访问权限会带来安全风险。应用以下做法来帮助保护访问权限

14.3.1. 将管理帐户降至最低 ¶

将对系统管理帐户的访问权限降至最低对于维护安全系统至关重要。系统管理员/root 用户可以访问、编辑和破坏任何系统应用程序。请尽可能将具有 root 访问权限的人员/帐户数量限制在最小的范围内。不要向不可信用户授予对 root 或 awx（Tower 用户）的 sudo 权限。请注意，通过 sudo 等机制限制管理访问权限时，限制为特定命令集可能仍然会提供广泛的访问权限。任何允许执行 shell 或任意 shell 命令，或可以更改系统上文件的命令，在根本上等同于完全的 root 访问权限。

在 Tower 上下文中，任何 Tower 的“系统管理员”或“超级用户”帐户都可以编辑、更改和更新 Tower 中的任何清单或自动化定义。将此限制为尽可能少的用户组，以仅用于低级别 Tower 配置和灾难恢复。

14.3.2. 将本地系统访问权限降至最低 ¶

Ansible Tower 在与最佳实践一起使用时，除了管理目的外，不应要求本地用户访问权限。非管理员用户不应访问 Tower 系统。

14.3.3. 从用户中删除对凭据的访问权限 ¶

如果自动化凭据仅存储在 Tower 中，则可以进一步保护它。OpenSSH 等服务可以配置为仅允许来自特定地址的连接上的凭据。自动化使用的凭据可以不同于系统管理员用于灾难恢复或其他临时管理的凭据，从而更易于审核。

14.3.4. 强制职责分离 ¶

不同的自动化部分可能需要以不同的级别访问系统。例如，您可能拥有应用补丁和执行安全基线检查的低级系统自动化，而更高级的自动化部分则部署应用程序。通过为每个自动化部分使用不同的密钥或凭据，可以将任何一个密钥漏洞的影响降到最低，同时还可以轻松进行基线审核。

14.4. 可用资源¶

Tower 和其他地方存在多个资源，以确保平台安全。请考虑利用以下功能

14.4.1. 审计和日志记录功能 ¶

对于任何管理访问权限，审计和监视操作至关重要。对于整个系统，可以通过内置的审计支持 (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html) 和内置的日志记录支持来完成。

对于 Ansible Tower，这可以通过内置的活动流支持（记录 Tower 中的所有更改）以及自动化日志来实现。

最佳实践要求集中收集日志记录和审计信息，而不是在本地系统上查看。建议将 Ansible Tower 配置为使用您的环境中的标准 IDS 和/或日志记录/审计（Splunk）。Ansible Tower 包含 Elastic Stack、Splunk、Sumologic、Loggly 等的内置日志集成。有关更多信息，请参阅 Tower 日志记录和聚合。

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator',
        'OPTIONS': {
            'min_length': 9,
        }
    },
    {
        'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator',
    },
    {
        'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator',
    },
]

有关更多信息，请参阅 Django 文档中的密码管理以及上面的示例。

请确保重新启动 Tower 实例以使更改生效。有关详细信息，请参阅启动、停止和重新启动 Tower。