ハードニングおよびコンプライアンス

Ansible Automation Platform には 3 つのインストール方法があります。

このドキュメントでは、最初の 2 つのインストール方法 (RPM ベースまたはコンテナーベース) のいずれかを使用してインストールした場合に、Ansible Automation Platform をハードニングするためのガイダンスを提供します。さらに、このドキュメントでは、新しくデプロイする場合にはコンテナーベースのインストール方法を使用することを推奨しています。RPM ベースのインストールプログラムが今後のリリースで非推奨になるためです。

詳細は、非推奨の機能 を参照してください。

このドキュメントでは、Operator ベースのデプロイは説明しません。

Ansible Automation Platform は、Automation Controller、プラットフォームゲートウェイ、Automation Hub、Event-Driven Ansible Controller など、相互に接続できる個別のコンポーネントで構成されるモジュール式プラットフォームです。

Ansible Automation Platform 2.5 は、テスト済みのデプロイメントモデル ドキュメントで定義されている、いずれかのテスト済みのデプロイメントリファレンスアーキテクチャーに基づいてインストールしてください。エンタープライズ組織は、最高レベルの稼働時間、パフォーマンス、継続的なスケーラビリティーを確保するために、いずれかのエンタープライズリファレンスアーキテクチャーを実稼働環境に使用することを推奨します。リソースが制限されている組織または環境では、"グロース" リファレンスアーキテクチャーを使用できます。テスト済みのデプロイメントモデル ドキュメントを確認して、要件に最適なリファレンスアーキテクチャーを決定してください。選択したリファレンスアーキテクチャーには、アーキテクチャー図、必要な Red Hat Enterprise Linux サーバーの数、デプロイメントで使用されるネットワークポートとプロトコル、エンタープライズアーキテクチャーのロードバランサー情報などの計画情報が含まれています。

Ansible Automation Platform は、さまざまなインフラストラクチャーリファレンスアーキテクチャーやさまざまな環境構成でインストールできます。Red Hat は、公開されているリファレンスアーキテクチャー以外のアーキテクチャーは、完全にテストしていません。Red Hat では、すべての新規デプロイメントにテスト済みのリファレンスアーキテクチャーを使用することを推奨しており、最小要件を満たすデプロイメントに対して商業的に妥当な範囲でのサポートを提供しています。

次の図は、テスト済みのコンテナーエンタープライズトアーキテクチャーです。

図2.1 リファレンスアーキテクチャーの概要

Ansible Automation Platform に関連するファイアウォールまたはクラウドネットワークセキュリティーグループの設定を計画する際には、テスト済みのデプロイメントモデル で選択したトポロジーの「ネットワークポート」セクションを参照して、ファイアウォールまたはセキュリティーグループで開く必要があるネットワークポートを確認してください。

インターネットに接続されたシステムの場合、「インストール計画」の ネットワークおよびプロトコル セクションに、Ansible Automation Platform で使用するように設定できるサービス (Red Hat Automation Hub、Insights for Ansible Automation Platform、Ansible Galaxy、registry.redhat.io コンテナーイメージレジストリーなど) の送信トラフィック要件が定義されています。

Ansible Automation Platform コンポーネントによって使用されるポートへのアクセスを、保護対象のネットワークとクライアントに制限してください。次の制限を強く推奨します。

Red Hat Ansible Automation Platform は、マシンに対するジョブへのリクエストの認証、インベントリーソースとの同期、バージョン管理システムからのプロジェクトコンテンツのインポートに認証情報を使用します。

Automation Controller は 3 つのシークレットのセットを管理します。

認証情報を侵害から保護するために、特権アクセスまたは認証情報管理ソリューションを実装することを強く推奨します。アクセスおよび権限昇格の使用を監査し、追加のプログラムによる制御を提供する必要があります。

自動化認証情報が一意であることを確認し、Automation Controller にのみ保存することで、自動化認証情報のセキュリティーをさらに強化できます。OpenSSH などのサービスは、特定のアドレスからの接続時にのみ認証情報を許可するように設定できます。自動化には、システム管理者がサーバーにログインするために使用する認証情報とは異なる認証情報を使用してください。直接アクセスは可能な限り制限する必要がありますが、障害復旧やその他の臨時の管理目的に使用できるため、監査が容易になります。

自動化ジョブは、場合によっては、さまざまなレベルでシステムにアクセスする必要があります。たとえば、パッチを適用してセキュリティーベースラインチェックを実行する低レベルのシステム自動化を設定する一方で、アプリケーションをデプロイする高レベルの自動化を設定することが考えられます。自動化の各部分に異なるキーまたは認証情報を使用することにより、1 つのキーの脆弱性の影響が最小限に抑えられます。これにより、ベースライン監査も容易になります。

Ansible Automation Platform 環境では、考慮すべきユーザーアカウントが 2 種類あります。

可視性と分析は、エンタープライズセキュリティーとゼロトラストアーキテクチャーを支える重要な柱です。ロギングは、動作を記録して監査するうえで重要です。Red Hat Enterprise Linux の「セキュリティーの強化ガイド」の システムの監査 セクションで説明されているビルトインの監査サポートを使用して、ロギングと監査を管理できます。Ansible Automation Platform の組み込みのロギングとアクティビティーストリームでは、Red Hat Ansible Automation Platform 内のすべての変更と自動化ログを監査目的で記録します。詳細は、「自動化実行の設定」の ロギングおよびアグリゲーション セクションを参照してください。

Ansible Automation Platform と基盤となる Red Hat Enterprise Linux システムを設定する際には、ログと監査をローカルシステムで確認するのではなく、一元的に収集するように設定することを推奨します。Ansible Automation Platform は、外部ロギングを使用して Ansible Automation Platform サーバー内の複数のコンポーネントからのログレコードを収集するように設定する必要があります。正確なフォレンジック分析を行うには、発生したイベントが時間と関連付けられている必要があります。そのため、Ansible Automation Platform サーバーは、Ansible Automation Platform のターゲットだけでなく、ロギングアグリゲーターサービスでも使用される NTP サーバーを使用して設定する必要があります。時間との関連付けは、業界の一定の許容要件を満たしている必要があります。つまり、ログに記録されたさまざまなイベントのタイムスタンプが x 秒を超えて異なってはならないなど、さまざまな要件が存在する可能性があります。このような機能は外部のロギングサービスで利用できます。

ロギングのもう 1 つの重要な機能は、暗号化を使用してログツールの整合性を保護する機能です。ログデータには、情報システムのアクティビティーを正常に記録するために必要なすべての情報 (ログレコード、ログ設定、ログレポートなど) が含まれます。一般的に、攻撃者はログツールを置き換えたり、既存のツールにコードを挿入したりして、システムアクティビティーをログから隠したり消去したります。このリスクに対処するには、ログツールがいつ変更、操作、または置換されたかを識別できるように、ログツールに暗号で署名する必要があります。ログツールが変更、操作、または置換されていないことを検証する方法としては、たとえば、ツールファイルに対してチェックサムハッシュを使用する方法があります。これにより、ツールの整合性が損なわれていないことが確認されます。

Ansible Automation Platform は、次のような一般的なユースケースに NIST サイバーセキュリティーフレームワークを適用して、セキュリティーポリシー要件を満たすように使用する必要があります。

これは、サイバーセキュリティーフレームワークの 5 つのステップを通じて実行できます。

Ansible Automation Platform のセキュリティーは、基盤となる Red Hat Enterprise Linux サーバーの設定に部分的に依存します。このため、各 Ansible Automation Platform コンポーネントの基盤となる Red Hat Enterprise Linux ホストは、Red Hat Enterprise Linux 8 セキュリティー強化 または Red Hat Enterprise Linux 9 セキュリティー強化 (使用するオペレーティングシステムによって異なります) および組織で使用するセキュリティープロファイル要件 (Center for Internet Security (CIS)、STIG、Health Insurance Portability and Accountability Act (HIPAA) など) に従ってインストールおよび設定する必要があります。このドキュメントでは、すべての新しいデプロイメントに Red Hat Enterprise Linux 9 を推奨しています。コンテナーベースのインストール方法を使用する場合は、Red Hat Enterprise Linux 9 が必要です。

Ansible Automation Platform のインストールプログラムは、Automation Controller などのインフラストラクチャーサーバーの 1 つから、または Ansible Automation Platform のインフラストラクチャーサーバーに SSH アクセスできる外部システムから実行できます。Ansible Automation Platform のインストールプログラムは、インストールだけでなく、バックアップや復元、アップグレードなどのその後の Day 2 オペレーションにも使用されます。インストールと Day 2 オペレーションは、専用の外部サーバー (以降、インストールホストと呼びます) から実行することを推奨します。そうすることで、これらの機能を実行するためにインフラストラクチャーサーバーの 1 つにログインする必要がなくなります。インストールホストは、Ansible Automation Platform の管理にのみ使用してください。インストールホストで他のサービスやソフトウェアを実行しないでください。

インストールホストは、Red Hat Enterprise Linux セキュリティー強化 および組織に関連するセキュリティープロファイル要件 (CIS、STIG など) に従ってインストールおよび設定された Red Hat Enterprise Linux サーバーである必要があります。インストール計画 の説明に従って Ansible Automation Platform インストーラーを入手し、Red Hat Ansible Automation Platform インストーラーのインベントリーファイルの編集 の説明に従ってインストーラーインベントリーファイルを作成します。このインベントリーファイルは、インストールプログラムによるアップグレード、インフラストラクチャーコンポーネントの追加、および Day 2 オペレーションに使用します。そのため、今後の運用に使用できるようにインストール後にファイルを保存してください。

インストールホストへのアクセスは、Ansible Automation Platform インフラストラクチャーの管理を担当する担当者のみに制限する必要があります。インストールホストには、時間の経過とともに、インストールインベントリー (これには Ansible Automation Platform の初期ログイン認証情報が含まれます)、ユーザーが提供した PKI 鍵と証明書のコピー、バックアップファイルなどの機密情報が格納されます。インストールホストは、インフラストラクチャーの管理と保守に必要な場合、SSH 経由で Ansible Automation Platform インフラストラクチャーサーバーにログインするときにも使用する必要があります。

インストールインベントリーファイルは、Ansible Automation Platform インフラストラクチャーのアーキテクチャーを定義し、インフラストラクチャーコンポーネントの初期設定を変更するために使用できる多数の変数を提供します。インストーラーインベントリーの詳細は、インストーラーインベントリーファイルについて を参照してください。

次の表に、RPM ベースのデプロイメントにおけるセキュリティー関連の変数とその推奨値をいくつか示します。

次の表に、コンテナーベースのデプロイメントにおけるセキュリティー関連の変数とその推奨値をいくつか示します。

複数のプラットフォームゲートウェイの手前でロードバランサーを使用するエンタープライズアーキテクチャーでは、SSL クライアント接続をロードバランサーで終端することも、個々の AAP サーバーにパススルーすることもできます。SSL をロードバランサーで終端する場合は、ロードバランサーから個々の Ansible Automation Platform サーバーへのトラフィックを再暗号化することを推奨します。これにより、エンドツーエンドの暗号化が確実に使用されます。このような場合、上記の *_disable_https 変数は、デフォルト値の false に設定します。

デフォルトでは、Ansible Automation Platform は、プラットフォームのインフラストラクチャーコンポーネント用に、自己署名 公開鍵基盤 (PKI) 証明書を作成します。既存の PKI インフラストラクチャーが利用可能な場合は、Automation Controller、Private Automation Hub、Event-Driven Ansible Controller、および postgres データベースサーバー用の証明書を生成する必要があります。証明書ファイルと関連する鍵ファイルを、証明書の検証に使用する CA 証明書とともにインストールプログラムディレクトリーにコピーしてください。

次のインベントリー変数を使用し、新しい証明書を使用してインフラストラクチャーコンポーネントを設定します。

複数のプラットフォームゲートウェイがロードバランサーを使用してデプロイされている場合、gateway_tls_cert と gateway_tls_key は、各プラットフォームゲートウェイによって共有されます。ホスト名の不一致を防ぐには、証明書の共通名 (CN) がロードバランサーで使用する DNS FQDN と一致する必要があります。組織のポリシーでサービスごとに固有の証明書が必要な場合、各証明書には、負荷分散サービスで使用する DNS FQDN と一致する サブジェクト代替名 (SAN) が必要です。各プラットフォームゲートウェイに固有の証明書とキーをインストールするには、インストールインベントリーファイル内の証明書と鍵の変数を、[all:vars] セクションではなく、ホストごとの変数として定義する必要があります。以下に例を示します。

[automationgateway]
gateway0.example.com gateway_tls_cert=/path/to/cert0 gateway_tls_key=/path/to/key0
gateway1.example.com gateway_tls_cert=/path/to/cert1 gateway_tls_key=/path/to/key1

[automationcontroller]
controller0.example.com web_server_ssl_cert=/path/to/cert0 web_server_ssl_key=/path/to/key0
controller1.example.com web_server_ssl_cert=/path/to/cert1 web_server_ssl_key=/path/to/key1
controller2.example.com web_server_ssl_cert=/path/to/cert2 web_server_ssl_key=/path/to/key2

[automationhub]
hub0.example.com automationhub_ssl_cert=/path/to/cert0 automationhub_ssl_key=/path/to/key0
hub1.example.com automationhub_ssl_cert=/path/to/cert1 automationhub_ssl_key=/path/to/key1
hub2.example.com automationhub_ssl_cert=/path/to/cert2 automationhub_ssl_key=/path/to/key2

[automationgateway]
gateway0.example.com gateway_tls_cert=/path/to/cert0 gateway_tls_key=/path/to/key0
gateway1.example.com gateway_tls_cert=/path/to/cert1 gateway_tls_key=/path/to/key1

[automationcontroller]
controller0.example.com web_server_ssl_cert=/path/to/cert0 web_server_ssl_key=/path/to/key0
controller1.example.com web_server_ssl_cert=/path/to/cert1 web_server_ssl_key=/path/to/key1
controller2.example.com web_server_ssl_cert=/path/to/cert2 web_server_ssl_key=/path/to/key2

[automationhub]
hub0.example.com automationhub_ssl_cert=/path/to/cert0 automationhub_ssl_key=/path/to/key0
hub1.example.com automationhub_ssl_cert=/path/to/cert1 automationhub_ssl_key=/path/to/key1
hub2.example.com automationhub_ssl_cert=/path/to/cert2 automationhub_ssl_key=/path/to/key2

インストールインベントリーファイルには、主に Ansible Automation Platform が使用する初期パスワードの設定に使用される機密性の高い変数が多数含まれています。これらの変数は、通常はインベントリーファイル内にプレーンテキストで保存されます。これらの変数の不正な表示を防ぐために、暗号化された Ansible vault に変数を保存できます。これを行うには、インストーラーディレクトリーに移動し、vault ファイルを作成します。

新しい Ansible vault のパスワードの入力を求められます。vault のパスワードは、Day 2 オペレーションやバックアップ手順の実行時など、vault ファイルにアクセスする必要があるたびに必要になるため、紛失しないように注意してください。vault のパスワードは、暗号化されたパスワードマネージャーに保存するか、パスワードをセキュアに保存するための組織のポリシーに従ってセキュリティー保護することができます。

機密性の高い変数を vault に追加します。次に例を示します。

admin_password/controller_admin_password: <secure_controller_password>
pg_password/controller_pg_password: <secure_db_password>
automationhub_admin_password/hub_admin_password: <secure_hub_password>
automationhub_pg_password/hub_pg_password: <secure_hub_db_password>
automationedacontroller_admin_password/eda_admin_password: <secure_eda_password>
automationedacontroller_pg_password/eda_pg_password: <secure_eda_db_password>
-/gateway_admin_password: <secure_gateway_password>
-/gateway_pg_password:<secure_gateway_db_password>

admin_password/controller_admin_password: <secure_controller_password>
pg_password/controller_pg_password: <secure_db_password>
automationhub_admin_password/hub_admin_password: <secure_hub_password>
automationhub_pg_password/hub_pg_password: <secure_hub_db_password>
automationedacontroller_admin_password/eda_admin_password: <secure_eda_password>
automationedacontroller_pg_password/eda_pg_password: <secure_eda_db_password>
-/gateway_admin_password: <secure_gateway_password>
-/gateway_pg_password:<secure_gateway_db_password>

これらの変数がインストールインベントリーファイルにも含まれていないことを確認してください。新しい Ansible vault をインストールプログラムで使用するには、コマンド ./setup.sh -e @vault.yml — --ask-vault-pass を使用してプログラムを実行します。

多くの環境では、セキュリティー制御が適用されている Red Hat Enterprise Linux システムに Ansible Automation Platform をインストールする必要があります。その目的は、CIS Critical Security Controls、Payment Card Industry/Data Security Standard (PCI/DSS)、DISA STIG などのコンプライアンスプロファイルの要件を満たすためです。このような環境では、Ansible Automation Platform を適切に実行するために、特定のセキュリティー制御セットを変更する必要がある場合があります。インストール前に、Ansible Automation Platform に使用されている Red Hat Enterprise Linux サーバーにコンプライアンスプロファイルの制御を適用してください。その後、必要に応じて以下のセキュリティー制御を変更します。

これらの制御が必要な環境では、セキュリティー監査担当者と制御の免除を検討してください。

Red Hat Community of Practice は、Ansible Automation Platform インフラストラクチャーと設定をコードとして管理するために、コレクションを通じて利用できる自動化コンテンツセットを作成しました。これにより、Configuration as Code (CaC) を通じてプラットフォーム自体の自動化が可能になります。このアプローチの多くの利点は明白ですが、一方で考慮すべきセキュリティー上の影響もあります。

以下の Ansible コンテンツコレクションは、Infrastructure as Code 手法を使用した Ansible Automation Platform コンポーネントの管理に利用できます。これらはすべて Ansible Automation Hub にあります。

多くの組織では、CI/CD プラットフォームを使用してパイプラインを設定するか、その他の方法を使用してこの種のインフラストラクチャーを管理しています。一方、Ansible Automation Platform をネイティブで使用すると、Git ベースのリポジトリーにネイティブにリンクするように Webhook を設定できます。そのため、Ansible は Git イベントに応答してジョブテンプレートを直接トリガーできます。これにより、このプロセス全体から外部の CI コンポーネントが不要になるため、攻撃対象領域が減少します。

これらのプラクティスにより、すべてのインフラストラクチャーと設定のバージョン管理が可能になります。Git のベストプラクティスを適用して、適切なコード品質検査を実現してから、Ansible Automation Platform に同期してください。関連する Git のベストプラクティスには次のようなものがあります。

CaC では、外部 vault システムの使用も推奨しています。これにより、機密データをリポジトリーに保存したり、必要に応じてファイルを個別に vault に保存する必要がなくなります。これは、Ansible Automation Platform の設定をソースコードリポジトリーに保存する場合に特に重要です。Automation Controller の認証情報と Event-Driven Ansible の認証情報は、ソースリポジトリーにコミットすべきでないコレクション変数に、プレーンテキストで指定する必要があるためです。外部の認証情報 vault システムの使用に関する詳細は、このガイドの 外部の認証情報 vault に関する考慮事項 セクションを参照してください。

一元的なロギングは、システムセキュリティーの監視と大規模なログ分析の実行を支援するために不可欠です。機密性、完全性、可用性 (CIA) の 3 要素は、米国軍と政府のアイデアの組み合わせから生まれたもので、適切なセキュリティーシステムの開発とベストプラクティスの基盤となるモデルです。一元的なロギングは、完全性の側面に該当し、データまたはシステムが改ざんされたかどうかを特定するのに役立ちます。一元的なシステムへのロギングを使用すると、すべてのログを 1 カ所に収集して複数のシステムにわたるトラブルシューティングを自動化できます。これにより、特に複雑な Ansible Automation Platform のデプロイメントで、問題の特定、傾向の分析、さまざまなサーバーからのイベントの相関関係の分析が容易になります。一元化されていない場合、個々のマシンを手動でチェックするのに長い時間がかかります。そのため、この機能はセキュリティーのベストプラクティスを満たすだけでなく、デバッグにも役立ちます。これにより、システム全体の健全性と安定性が確保され、潜在的なセキュリティーの脅威を特定しやすくなります。ロギングの設定に加えて、ストレージ容量、ハードウェア障害、高可用性アーキテクチャーによるロギングの失敗も考慮する必要があります。

他にも次のような利点があります。

ロギングアグリゲーターサービスは、以下の監視またはデータ分析システムと連携します。

一元的なロギングのために、ロギングをいずれかのアグリゲータータイプに設定するには、次の手順に従います。

次の手順で LDAP ロギングを有効にします。

LDAP のロギングを有効にするには、次の手順に従います。

次の例はコンプライアンス要件への対応例です。一部は米国国防総省の Security Technical Implementation Guide からのものですが、完全性とセキュリティーのベストプラクティスに立ち返ることが重要です。

Automation Controller は、改ざんや否認を防止するために、保護された独立したリポジトリーでユーザーアクティビティーログを収集できる外部ログプロバイダーを使用する必要があります。Automation Controller は、外部ロギングを使用してサーバー内の複数のコンポーネントからのログレコードを収集するように設定する必要があります。正確なフォレンジック分析を行うために、発生したイベントが時間と関連付けられている必要があります。さらに、この関連付けは特定の許容基準を満たす必要があります。

このセキュリティー制御を実装するには、次の手順を実行します。

Automation Controller は、ログレコード用のストレージ容量を割り当て、ログ障害の発生時にデフォルトでシャットダウンする必要があります (可用性が最優先事項である場合を除く)。システムがログの処理に失敗するリスクがある場合、それを検出して障害を軽減するための措置を講じることが不可欠です。ログ処理の障害には、ソフトウェア/ハードウェアエラー、ログキャプチャーメカニズムの障害、ログストレージ容量の到達または超過などがあります。アプリケーションサーバーが高可用性システムの一部である場合を除き、障害発生時にシャットダウンするようにアプリケーションサーバーを設定する必要があります。可用性が最優先事項である場合、ログ障害への対応として承認されるその他のアクションは次のとおりです。

Automation Controller は適切なログレコードを生成する必要があります。Automation Controller の Web サーバーが、トラブルシューティング、デバッグ、およびフォレンジック分析をサポートするために、ユーザーセッションに関連するすべての詳細をログに記録する必要があります。データのロギング機能がないと、組織はイベント調査のための重要な監査および分析ツールを失うことになります。

システム管理者としてこのセキュリティー制御を実装するには、各 Automation Controller ホストに対して次の手順を実行します。

Automation Controller のログファイルには、明示的に定義された権限でアクセスできる必要があります。Automation Controller のログファイルの機密性が失われると、通常は入手できないシステムに関する重要な情報を攻撃者が特定し、昇格やラテラルムーブメントに必要な情報をさらに列挙できるようになります。

このセキュリティー制御を実装するには、次の手順を実行します。

Automation Controller は、ログサブシステムに障害が発生した場合に別のシステムにフェイルオーバーするように設定する必要があります。Automation Controller ホストは、アプリケーションログ処理の障害検出時に、アプリケーションおよびロギング機能を処理できる別の Automation Controller ホストにフェイルオーバーできる必要があります。これにより、ユーザーの操作の中断やログデータの損失を最小限に抑えながら、アプリケーションとロギング機能の継続的な運用が可能になります。

このセキュリティー制御を実装するには、次の手順を実行します。

シークレット管理は、Automation Platform のセキュリティーを維持するために不可欠なコンポーネントです。次のシークレット管理プラクティスを推奨します。

管理者は、プラットフォームゲートウェイに組み込まれている ロールベースのアクセス制御 (RBAC) を使用して、サーバーインベントリー、組織などへのアクセスを委譲できます。管理者はさまざまな認証情報の管理を一元化することもできます。管理を一元化することで、エンドユーザーが必要なシークレットをエンドユーザー自身に表示することなく使用できるようになります。RBAC コントロールを使用すると、Ansible Automation Platform でセキュリティーを強化し、管理を効率化できます。

RBAC は、ユーザーまたはチームにロールを付与する方法です。RBAC は、ロールの観点から考えるのが最も簡単です。ロールは、特定の機能が設定されている “オブジェクト” を、誰または何が参照、変更、または削除できるかを正確に定義したものです。

Ansible Automation Platform の RBAC 設計に関して、理解しておくべき主要な概念は、ロール、リソース、ユーザーです。ユーザーはロールのメンバーになることができます。これにより、そのロールに関連付けられたリソース、または “子孫” ロールに関連付けられたリソースへの特定のアクセスが許可されます。

ロールは実質的には機能の集合です。ユーザーには、割り当てられているロール、またはロール階層を通じて継承したロールを通じて、これらの機能および Controller のリソースへのアクセスが許可されます。

ロールは、機能のグループをユーザーのグループに関連付けます。機能はすべて、ロール内のメンバーシップから得られます。ユーザーは、割り当てられているロールを通じて、またはロール階層を通じて継承したロールを通じてのみ機能を受け取ります。ロールのすべてのメンバーは、そのロールに付与されたすべての機能を持ちます。組織内において、ロールは比較的一定ですが、ユーザーと機能は両方とも多数あり、短期間で変更されることがあります。ユーザーは多くのロールを持つことができます。

ロール階層、アクセス継承、組み込みロール、権限、ペルソナ、ロール作成などの詳細は、Managing access with Role-Based access controls を参照してください。

以下は、ロールとリソース権限を使用する組織の例です。

図2.2 Automation Controller 内の RBAC ロールのスコープ

ユーザーアクセスは、特定のユーザーへの権限の個別割り当てではなく、システムオブジェクト (ユーザー、グループ、名前空間) に対する権限の管理に基づいています。権限は、作成するグループに割り当てることができます。グループを作成したら、グループにユーザーを割り当てることができます。グループ内の各ユーザーは、そのグループ内に割り当てられた権限を持つことになります。

Automation Hub で作成されるチームは、内部コレクションの管理、ユーザーアクセスの設定、リポジトリー管理を担当するシステム管理者から、内部で開発されたコンテンツを整理して Automation Hub にアップロードするためのアクセス権を持つグループまで多岐にわたります。

表示専用アクセスを有効にすると、Private Automation Hub のロックダウンをさらに強化できます。表示専用アクセスを有効にすると、Private Automation Hub のコレクションまたは名前空間をログイン不要で表示できる権限をユーザーに付与できます。表示専用アクセスを使用すると、ソースコードの表示またはダウンロードだけにユーザーの能力を制限して、Private Automation Hub 上で編集する権限を与えることなく、権限のないユーザーとコンテンツを共有できます。Red Hat Ansible Automation Platform インストーラーにあるインベントリーファイルを編集して、Private Automation Hub の表示専用アクセスを有効にします。

すべてのアップグレードは、現在アップグレード先のメジャーバージョンより 1 つまたは 2 つ下のバージョンである必要があります。たとえば、Automation Controller 4.3 にアップグレードするには、バージョン 3.8.x 以前からの直接アップグレードパスがないため、まずバージョン 4.1.x にする必要があります。詳細は、Upgrading to Ansible Automation Platform を参照してください。Automation Controller 4.3 を実行するには、Ansible 2.12 以降も必要です。