Documentation

16. 安全性最佳实践

标准 automation controller 设置的安全性适用于自动部署典型的环境。但是,在管理特定操作系统环境、自动化和自动化平台时,可能需要一些额外的最佳实践才能确保其安全性。本文档介绍了在自动化环境中确保安全性的最佳实践。

16.1. 通用最佳实践

应用程序的安全性会受底层系统安全性的影响。为了确保 Red Hat Enterprise Linux 的安全性,请参阅:

16.2. 了解 Ansible 和控制器的架构

Ansible 和 automation controller 的一个通用目的是提供一个自动化平台。这意味着,一旦启动了一个 Ansible playbook(通过控制器,或直接通过命令行),playbook、清单和 Ansible 的凭证将被视为可靠的来源。如果特定的安全政策需要针对特定 playbook 内容、作业定义或清单内容进行外部验证,这些过程必须在自动化操作启动(无论是通过控制器 Web UI 或控制器 API) 之前进行。

使用源控制、分支和强制代码审核是 Ansible 自动化的最佳方法。有很多工具可帮助以这种方式创建使用源控制的进程流。

在更高的级别上,有很多工具允许针对任意工作流创建批准和基于策略的操作,包括自动化。这些工具可通过控制器的 API 来使用 Ansible 执行自动化。

我们建议 automation controller 的所有客户在安装时都选择一个安全的默认管理员密码。如需更多信息,请参阅 更改控制器管理员密码

automation controller 在某些已知端口上公开服务,比如 HTTP 流量使用端口 80,HTTPS 流量使用端口 443。我们建议您不要在开放互联网上公开 automation controller,这会显著降低安装的风险。

16.3. 授予访问权限

授予系统某些部分的访问权限可能会带来安全隐患。请应用以下方法帮助保证访问安全:

16.3.1. 保持管理帐户的最小化

限制对系统管理帐户的访问最小化对维护一个安全系统至关重要。系统管理员/root 用户可以访问、编辑和破坏任何系统应用程序。因此,尽量使具有 root 访问权限的用户和人员保持最少。不要为不信任的用户分配对 rootawx`(控制器用户)的 `sudo 权限。当通过某些机制(如 sudo)为用户提供了受限的管理访问权限时,这些访问权限仍有可能进行大量操作。允许执行 shell 的命令,或可以修改文件的任何命令,都应该视为等同于具有完整的 root 访问权限。

在控制器中,任何控制器 ‘系统管理员’ 或 'superuser' 帐户都可以编辑、修改和更新控制器中的任何清单或自动化定义。这只应该分配给尽量少的、需要进行底层控制器配置和灾难恢复的用户。

16.3.2. 最小化本地系统访问

根据最佳实践方案原则,除了用于管理目的之外,automation controller 不需要进行本地用户访问。非管理员用户不应该具有可以访问控制器所在系统的权限。

16.3.3. 删除用户对凭证的访问

如果自动化凭证仅存储在控制器中,则可进一步加以保护。OpenSSH 等服务可以配置为只允许来自特定地址的连接使用凭证.。自动化使用的凭证可能与系统管理员用于灾难恢复或其他 ad-hoc 管理的凭证不同,以允许更轻松地进行审核。

16.3.4. 强制隔离任务

不同的自动化任务可能需要对一个系统有不同的访问级别。例如,您可能需要进行底层的系统自动化来应用补丁或执行安全检查;也可能需要进行高层的自动化来部署应用程序。通过对不同的自动化操作使用不同的密钥或凭证,可以最小化一个关键安全漏洞对系统的不良影响,同时可简化基准审核。

16.4. 可用资源

控制器和其它地方提供了一些资源来确保安全平台。请考虑使用以下功能:

16.4.1. 审计和日志记录功能

对于任何管理访问,审核和监视都非常关键。对于整个系统来说,可以使用内置的审计功能支持 (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/chap-system_auditing.html) 以及内置的日志功能支持。

automation controller 使用内置的 Activity Stream 支持,它可以记录控制器内的所有更改,以及自动化日志。

最佳实践推荐集中进行日志收集和审核,而不是在本地系统中进行。建议将 automation controller 配置为在您的环境中使用任何 IDS 和/或日志/审核 (Splunk) 标准。automation controller 包括了内置的、针对 Elastic Stack, Splunk, Sumologic, Loggly 和其他系统的日志集成功能。详情请参阅 日志记录和聚合

16.4.2. 现有安全功能

不要禁用 SELinux,也不要禁用控制器中现存的多用户限制机制。使用控制器的角色访问控制 (RBAC) 来代表运行自动化所需的最低级别权限。使用控制器的团队(Team)来为用户组分配权限,而不是单独为用户分配权限。详情请参阅 Automation Controller User Guide 中的 基于角色的访问控制

16.4.3. 外部帐户存储

对于一个大型机构,在控制器中维护完整的用户会非常耗时,且容易出错。Automation controller 支持通过 LDAPSAML 2.0 和特定的:ref:OAuth providers <ag_social_auth> 连接到外部账户源。

16.4.4. Django 密码策略

控制器管理员可以利用 Django 在创建时通过 AUTH_PASSWORD_VALIDATORS 设置密码策略以验证 Tower 用户密码。在 custom.py 文件中(位于控制器实例的 /etc/tower/conf.d),添加以下代码块示例:

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',
    },
]

如需更多信息,除了上面发布的示例外,请参阅 Password management in Django

重启控制器实例以使更改生效。详情请参阅 启动、停止和重启控制器