第2章 Ansible Automation Platform のハードニング

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

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

View larger image

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 のネットワークポートおよびプロトコル

View larger image

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 の要件について理解と承認を得てください。