Red Hat Ansible Automation Platform ハードニングガイド

Ansible Automation Platform は、Automation Controller、Automation Hub、Event-Driven Ansible Controller、および Insights for Ansible Automation Platform を含むモジュール式プラットフォームです。

可用性に関する要件がある大規模な実稼働環境の場合は、Red Hat Enterprise Linux 上の Red Hat Ansible Automation Platform の リファレンスアーキテクチャー ドキュメントの手順を使用して、このガイドのセクション 2.1 で説明されているコンポーネントをデプロイすることを推奨します。特定の技術要件に合わせて若干の変更を加えることも妥当な選択ですが、リファレンスアーキテクチャーに従うと、サポート対象の実稼働環境が実現します。

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

Event-Driven Ansible は、Ansible Automation Platform 2.4 の新機能です。この機能は、「図 1: リファレンスアーキテクチャーの概要」で詳しく説明されているリファレンスアーキテクチャーを初めて作成したときには提供されていませんでした。現在、サポートされる構成は、単一の Automation Controller、単一の Automation Hub、および外部 (インストーラー管理) データベースを備えた単一の Event-Driven Ansible Controller ノードです。Event-Driven Ansible に関心をお持ちの場合は、Ansible Automation Platform インストールガイド に記載されている設定に従ってインストールすることを推奨します。このドキュメントでは、Event-Driven Ansible 固有のハードニング設定が必要な場合の追加の説明を提供します。

完全なリファレンスアーキテクチャーが必要ない小規模な実稼働環境の場合は、専用の PostgreSQL データベースサーバー (インストーラーによって管理されるか、外部で提供されるもの) を使用して Ansible Automation Platform をデプロイすることを推奨します。

Ansible Automation Platform は、外部の補助サービスを統合し、ホスト、他のネットワークデバイス、アプリケーション、クラウドサービスなどのターゲット環境とリソースを管理するために、ネットワークへのアクセスを必要とします。「Ansible Automation Platform 計画ガイド」の ネットワークポートおよびプロトコル のセクションでは、次の図に示すように、Ansible Automation Platform コンポーネントがネットワーク上でどのように対話するか、またどのポートとプロトコルが使用されるかについて説明しています。

図2.2 Ansible Automation Platform のネットワークポートおよびプロトコル

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

ロードバランサーの使用方法の詳細と、Ansible Automation Platform と互換性のあるサービスの送信トラフィック要件については、Red Hat ナレッジベースの記事 What ports need to be opened in the firewall for Ansible Automation Platform 2 Services? を参照してください。この記事では、インターネットに接続されたシステムに関して、Ansible Automation Platform が使用するように設定できるサービス (Ansible Automation Hub、Red Hat Insights for Red Hat Ansible Automation Platform、Ansible Galaxy、registry.redhat.io コンテナーイメージレジストリーなど) の送信トラフィック要件も定義しています。

この記事では、インターネットに接続されたシステムに関して、Ansible Automation Platform が使用するように設定できるサービス (Ansible Automation Hub、Insights for Red Hat Ansible Automation Platform、Ansible Galaxy、registry.redhat.io コンテナーイメージレジストリーなど) の送信トラフィック要件も定義しています。

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

Ansible Automation Platform ユーザーインターフェイスまたは API へのアクセスを計画する際、ユーザーアカウントは、ローカルのものを使用することも、LDAP などの外部認証ソースにマップすることもできます。可能であれば、すべての主なユーザーアカウントを外部認証ソースにマップすることを推奨します。外部アカウントソースを使用すると、このコンテキストで権限を操作する際のエラーの原因が排除され、Ansible Automation Platform 内ですべてのユーザーを維持するのに費やされる時間が最小限に抑えられます。これには、個人に割り当てられたアカウントだけでなく、外部アプリケーションの統合に使用されるサービスアカウントなど、個人以外のエンティティーに割り当てられたアカウントも含まれます。デフォルトの "admin" アカウントなどのローカル管理者アカウントは、外部認証メカニズムが利用できない緊急アクセスや "緊急時" のシナリオ用に予約しておきます。

Ansible Automation Platform サービスを実行する Red Hat Enterprise Linux サーバー上のユーザーアカウントの場合は、組織のポリシーに従って、個々のユーザーアカウントをローカルにするか、外部認証ソースからのものにするかを決定します。Ansible Automation Platform コンポーネント自体でメンテナンスタスクを実行する必要があるユーザーのみに、基盤となる Red Hat Enterprise Linux サーバーへのアクセスを許可する必要があります。サーバーには暗号化キーやサービスパスワードなどの機密情報が含まれる設定ファイルがあるためです。このようなユーザーには Ansible Automation Platform サービスを維持するために特権アクセスを付与する必要があるため、基盤となる Red Hat Enterprise Linux サーバーへのアクセスを最小限に抑えることが重要です。root アカウントまたはローカルの Ansible Automation Platform サービスアカウント (awx、pulp、postgres) への sudo アクセスを信頼できないユーザーに付与しないでください。

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

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

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

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

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

Ansible Automation Platform と基盤となる Red Hat Enterprise Linux システムを設定する際には、ログと監査をローカルシステムで確認するのではなく、一元的に収集するように設定することを推奨します。Automation Controller は、外部のロギングを使用して、Controller サーバー内の複数のコンポーネントからのログレコードを収集するように設定する必要があります。正確なフォレンジック分析を行うには、発生したイベントが時間と関連付けられている必要があります。そのため、Controller サーバーは、Controller のターゲットだけでなく、ロギングアグリゲーターサービスでも使用される 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 セキュリティー強化 (使用するオペレーティングシステムによって異なります) および組織で使用するセキュリティープロファイル要件 (CIS、STIG、HIPAA など) に従ってインストールおよび設定する必要があります。

STIG または他のセキュリティープロファイルから特定のセキュリティー制御を適用すると、Ansible Automation Platform のサポート要件と競合する可能性があることに注意してください。Automation Controller STIG に関する考慮事項 セクションにいくつかの例が挙げられていますが、これは完全なリストではありません。サポート対象の設定を維持するために、セキュリティー監査者とそのような競合について必ず相談し、Ansible Automation Platform の要件について理解と承認を得てください。

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 サーバーである必要があります。Automation Platform 計画ガイド の説明に従って Ansible Automation Platform インストーラーを入手し、Automation Platform インストールガイド の説明に従ってインストーラーインベントリーファイルを作成します。このインベントリーファイルは、インストーラーによるアップグレード、インフラストラクチャーコンポーネントの追加、および Day 2 運用に使用されるため、今後の運用に使用できるようにインストール後にファイルを保存してください。

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

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

次の表に、いくつかのセキュリティー関連の変数と、インストールインベントリーの作成に推奨される値を示します。

複数の Controller または Hub でロードバランサーを使用するリファレンスアーキテクチャーのようなシナリオでは、SSL クライアント接続をロードバランサーで終了することも、個々の Ansible Automation Platform サーバーにパススルーすることもできます。SSL をロードバランサーで終了する場合は、エンドツーエンドの暗号化が確実に使用されるように、ロードバランサーから個々の Ansible Automation Platform サーバーへのトラフィックを再暗号化することを推奨します。このようなシナリオでは、表 2.3 にリストされている *_disable_https 変数は、デフォルト値の "false" のままにします。

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

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

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

[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

[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

[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: <secure_controller_password>
pg_password: <secure_db_password>
automationhub_admin_password: <secure_hub_password>
automationhub_pg_password: <secure_hub_db_password>
automationhub_ldap_bind_password: <ldap_bind_password>
automationedacontroller_admin_password: <secure_eda_password>
automationedacontroller_pg_password: <secure_eda_db_password>

admin_password: <secure_controller_password>
pg_password: <secure_db_password>
automationhub_admin_password: <secure_hub_password>
automationhub_pg_password: <secure_hub_db_password>
automationhub_ldap_bind_password: <ldap_bind_password>
automationedacontroller_admin_password: <secure_eda_password>
automationedacontroller_pg_password: <secure_eda_db_password>

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

組織全体のセキュリティー戦略の一部として米国国防情報システム局 (DISA) の Security Technical Implementation Guides (STIG) を使用している場合は、Ansible Automation Platform Automation Controller 向け STIG を利用できるようになりました。現時点では、STIG は Ansible Automation Platform の Automation Controller コンポーネントにのみ対応しています。STIG を Automation Controller に適用する場合、留意すべき考慮事項がいくつかあります。

Automation Controller STIG の概要ドキュメントには、Red Hat Enterprise Linux 8 の STIG と組み合わせて使用することを想定していると記載されています。このバージョンの Automation Controller STIG は、Red Hat Enterprise Linux 9 の STIG が利用可能になる前にリリースされたため、Automation Controller STIG を適用する場合は、基盤となるホスト OS として Red Hat Enterprise Linux 8 を使用する必要があります。Red Hat Enterprise Linux 8 STIG の一部のコントロールは、Ansible Automation Platform のインストールおよび操作と競合します。ただし、これは次のセクションで説明するように軽減することができます。

Red Hat Community of Practice は、Ansible Automation Platform インフラストラクチャーと設定をコードとして管理するために、コレクションを通じて利用できる自動化コンテンツセットを作成しました。これにより、Infrastructure as Code (IaC) または 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 のベストプラクティスには次のようなものがあります。

IaC では、外部 vault システムの使用も推奨しています。これにより、機密データをリポジトリーに保存したり、必要に応じてファイルを個別に vault に保存する必要がなくなります。外部 vault システムの使用の詳細は、このガイドのセクション 2.3.2.3 外部の認証情報 vault に関する考慮事項 を参照してください。

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

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

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

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

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

ロール階層、アクセス継承、ビルトインロール、権限、ペルソナ、ロール作成などの詳細は、Role-Based Access Controls を参照してください。

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

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

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

Automation Hub で作成されるグループは、内部コレクションの管理、ユーザーアクセスの設定、リポジトリー管理を担当するシステム管理者から、内部で開発されたコンテンツを整理して 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 以降も必要です。