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


このガイドでは、Ansible Automation Platform のセキュリティー体制のハードニングについて、実践的なアプローチを採用しています。デプロイメントの計画とアーキテクチャーのフェーズから始めて、インストールフェーズの具体的なガイダンスを取り上げます。このガイドでは、Red Hat Enterprise Linux 上で実行される Ansible Automation Platform を特に説明しているため、Automation Platform のコンポーネントに影響する Red Hat Enterprise Linux のハードニングガイダンスも取り上げます。

2.1. プランニングに関する考慮事項

Red Hat Ansible Automation Platform は、次の主要コンポーネントで構成されています。

  • Automation Controller
  • 自動化メッシュ
  • Private Automation Hub
  • Event-Driven Ansible Controller

PostgreSQL データベースも提供されていますが、ユーザーが提供する PostgreSQL データベースも使用できます。Red Hat では、追加の操作不要ですべての機能を使用できるように、Ansible Automation Platform のすべてのコンポーネントを常にデプロイすることをお客様に推奨しています。

詳細は、Red Hat Ansible Automation Platform アーキテクチャー を参照してください。

2.1.1. Ansible Automation Platform のデプロイメントトポロジー

Ansible Automation Platform 2.6 は、テスト済みのデプロイメントモデル ドキュメントで定義されている、いずれかのテスト済みのデプロイメントリファレンスアーキテクチャーに基づいてインストールしてください。エンタープライズ組織は、最高レベルの稼働時間、パフォーマンス、継続的なスケーラビリティーを確保するために、いずれかのエンタープライズリファレンスアーキテクチャーを実稼働環境に使用することを推奨します。リソースが制限されている組織または環境では、"グロース" リファレンスアーキテクチャーを使用できます。テスト済みのデプロイメントモデル ドキュメントを確認して、要件に最適なリファレンスアーキテクチャーを決定してください。選択したリファレンスアーキテクチャーには、アーキテクチャー図、必要な 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 コンポーネントによって使用されるポートへのアクセスを、保護対象のネットワークとクライアントに制限してください。次の制限を強く推奨します。

  • 他の Ansible Automation Platform コンポーネントサーバー (Automation Controller、Automation Hub、Event-Driven Ansible Controller) にのみアクセスを許可するように、データベースサーバーの PostgreSQL データベースポート (5432) を制限します。
  • SSH アクセスを、Ansible Automation Platform サーバーへのメンテナンスアクセスに使用する インストールホスト およびその他の信頼できるシステムから Ansible Automation Platform サーバーへのアクセスに制限します。
  • HTTPS アクセスを、信頼できるネットワークおよびクライアントから Automation Controller、Automation Hub、および Event-Driven Ansible Controller へのアクセスに制限します。

2.1.2. DNS、NTP、およびサービスの計画

Ansible Automation Platform をインストールする場合、正常なデプロイと適切な操作のために、DNS と NTP の設定が重要です。

2.1.2.1. DNS

Ansible Automation Platform をインストールするとき、インストールプログラムスクリプトは、特定のインフラストラクチャーサーバーがインストーラーのインベントリー内で 完全修飾ドメイン名 (FQDN) を使用して定義されていることを確認します。すべての Ansible Automation Platform インフラストラクチャーノードに、ルーティング可能な IP アドレスに解決される有効な FQDN を DNS で定義し、この FQDN をインストーラーインベントリーファイルで使用することを推奨します。

2.1.2.2. DNS とロードバランシング

デプロイメントトポロジーで説明されているように、Ansible Automation Platform でロードバランサーを使用する場合は、ロードバランサーに追加の FQDN が必要です。たとえば、aap.example.com などの FQDN をロードバランサーに使用すると、ロードバランサーはインストールインベントリーで定義されている各プラットフォームゲートウェイコンポーネントにトラフィックを送信します。

2.1.2.3. NTP

Ansible Automation Platform インフラストラクチャー内の各サーバーを、Network Time Protocol (NTP) プールまたは組織の NTP サービスと時刻を同期するように設定します。これにより、Ansible Automation Platform によって生成されたイベントのログと監査に正確なタイムスタンプが付けられ、Automation Controller から実行されるスケジュールされたジョブが正しい時刻に実行されます。また、Ansible Automation Platform 内のシステム間の通信で、タイムアウトに基づくメッセージの拒否を回避することもできます。

NTP と同期するように chrony サービスを設定する方法の詳細は、Red Hat Enterprise Linux ドキュメントの chrony の使用 を参照してください。

2.1.3. Ansible Automation Platform の認証情報管理の計画

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

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

  • Ansible Automation Platform ローカルユーザー のユーザーパスワード。
  • Ansible Automation Platform の 運用に使用 するシークレット (データベースのパスワード、メッセージバスのパスワードなど)。
  • 自動化に使用 するシークレット (SSH 鍵、クラウドの認証情報、外部パスワード Vault の認証情報など)。

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

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

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

2.1.3.1. Ansible Automation Platform の運用上のシークレット

Ansible Automation Platform は、運用上、いくつかのシークレット (パスワード、キーなど) を使用します。これらのシークレットは、各コンポーネントサービスが起動時に読み取る必要があるため、さまざまな Ansible Automation Platform サーバーに暗号化されずに保存されます。ファイルはすべて Unix 権限によって保護されており、root ユーザーまたは適切なサービスアカウントユーザーに制限されています。これらのファイルは定期的に監視して、不正なアクセスや変更が行われていないことを確認する必要があります。

2.1.3.1.1. RPM ベースのインストール環境のシークレット

次の表は、Ansible Automation Platform の RPM ベースのインストール環境におけるこれらのシークレットの場所を示しています。

Expand
表2.1 Ansible Automation Platform の運用上のシークレット

Automation Controller のシークレット

ファイルパス

説明

/etc/tower/SECRET_KEY

データベース内の自動化シークレットを暗号化するために使用するシークレットキー。SECRET_KEY が変更された場合や不明な場合は、データベース内の暗号化されたフィールドにアクセスできなくなります。

/etc/tower/tower.cert

/etc/tower/tower.key

Automation Controller Web サービスの SSL 証明書と鍵。

デフォルトでは自己署名の cert/key がインストールされますが、適切な証明書と鍵をローカルで提供することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/tower/conf.d/postgres.py

Automation Controller がデータベースに接続するために使用するパスワードが含まれます (データベース接続に TLS 認証を使用する場合を除く)。

/etc/tower/conf.d/channels.py

Automation Controller が WebSocket ブロードキャストに使用するシークレットが含まれます。

/etc/tower/conf.d/gateway.py

Automation Controller がプラットフォームゲートウェイと状態を同期するために使用するキーが含まれます。

プラットフォームゲートウェイのシークレット

ファイルパス

説明

/etc/ansible-automation-platform/gateway/SECRET_KEY

データベース内の自動化シークレットを暗号化するために使用するシークレットキー。SECRET_KEY が変更された場合や不明な場合、プラットフォームゲートウェイはデータベース内の暗号化されたシークレットにアクセスできません。

/etc/ansible-automation-platform/gateway/gateway.cert

プラットフォームゲートウェイ Web サービスの SSL 証明書。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/ansible-automation-platform/gateway/gateway.key

プラットフォームゲートウェイ Web サービスの SSL 鍵。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/ansible-automation-platform/gateway/cache.cert

プラットフォームゲートウェイが使用する Redis キャッシュとの相互 TLS (mTLS) 認証に使用される SSL 証明書。

/etc/ansible-automation-platform/gateway/cache.key

プラットフォームゲートウェイが使用する Redis キャッシュとの相互 TLS (mTLS) 認証に使用される SSL 鍵。

/etc/ansible-automation-platform/gateway/settings.py

プラットフォームゲートウェイがデータベースに接続するために使用するパスワードが含まれます (データベース接続に TLS 認証を使用する場合を除く)。また、プラットフォームゲートウェイが使用する Redis キャッシュに接続するために使用されるパスワードも含まれます。

Automation Hub のシークレット

ファイルパス

説明

/etc/pulp/settings.py

Automation Hub がデータベースに接続するために使用するパスワードが含まれます (データベース接続に TLS 認証を使用する場合を除く)。Automation Hub Web サービスで使用される Django シークレットキーが含まれます。

/etc/pulp/certs/token_public_key.pem

Automation Hub EE トークン認証用の PEM 形式の OpenSSL 公開鍵。デフォルトでは、token_private_key.pem ファイルから生成されます。

/etc/pulp/certs/token_private_key.pem

Automation Hub EE トークン認証用の PEM 形式の OpenSSL 秘密鍵。これはデフォルトで生成されますが、ユーザーは pulp_token_auth_key インストールインベントリー変数を使用して独自の秘密鍵を指定することもできます。

/etc/pulp/certs/pulp_webserver.crt

Automation Hub Web サービスの SSL 証明書。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/pulp/certs/pulp_webserver.key

Automation Hub Web サービスの SSL 鍵。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/pulp/certs/database_fields.symmetric.key

Automation Hub データベーステーブル内の機密フィールドを暗号化するために使用されるキー。

キーが変更された場合や不明な場合、Automation Hub はデータベース内の暗号化されたフィールドにアクセスできません。

Event-Driven Ansible のシークレット

ファイルパス

説明

/etc/ansible-automation-platform/eda/SECRET_KEY

Event-Driven Ansible Controller データベーステーブル内のフィールドを暗号化するために使用されるシークレットキー。

SECRET_KEY が変更された場合や不明な場合、Event-Driven Ansible Controller はデータベース内の暗号化されたフィールドにアクセスできません。

/etc/ansible-automation-platform/eda/settings.yaml

Event-Driven Ansible ゲートウェイがデータベースに接続するために使用するパスワードが含まれます (データベース接続に TLS 認証を使用する場合を除く)。

Event-Driven Ansible Controller が使用する Redis キャッシュに接続するために使用されるパスワードが含まれます。

Event-Driven Ansible Controller がプラットフォームゲートウェイと状態を同期するために使用するキーが含まれます。

/etc/ansible-automation-platform/eda/server.cert

Event-Driven Ansible Controller Web サービスの SSL 証明書。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/ansible-automation-platform/eda/server.key

Event-Driven Ansible Controller Web サービスの SSL 鍵。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/ansible-automation-platform/eda/cache.cert

Event-Driven Ansible Controller が使用する Redis キャッシュとの相互 TLS (mTLS) 認証に使用される SSL 証明書

/etc/ansible-automation-platform/eda/cache.key

Event-Driven Ansible Controller が使用する Redis キャッシュとの相互 TLS (mTLS) 認証に使用される SSL 鍵

/etc/ansible-automation-platform/eda/websocket.cert

Event-Driven Ansible Controller の WebSocket エンドポイントの SSL 証明書。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

/etc/ansible-automation-platform/eda/websocket.key

Event-Driven Ansible Controller の WebSocket エンドポイントの SSL 鍵。

デフォルトでは自己署名証明書がインストールされますが、ユーザーが提供する証明書と鍵のペアを使用することもできます。

詳細は、ユーザー提供の PKI 証明書を使用したインストール を参照してください。

Redis のシークレット

ファイルパス

説明

/etc/ansible-automation-platform/ca/ansible-automation-platform-managed-ca-cert.crt

インストールプログラムが各コンポーネントサービスのデフォルトの自己署名証明書を生成するために使用する、内部自己署名認証局の SSL 証明書。

/etc/ansible-automation-platform/ca/ansible-automation-platform-managed-ca-cert.key

インストールプログラムが各コンポーネントサービスのデフォルトの自己署名証明書を生成するために使用する、内部自己署名認証局の SSL 鍵。

注記

前述したファイルの場所の一部は、Automation Controller の以前の製品名 (以前は Ansible Tower と呼ばれていました) を反映しています。

2.1.3.1.2. コンテナーベースのインストール環境のシークレット

RPM ベースのインストール環境用として記載されているシークレットは、コンテナーベースのインストールでも使用されます。ただし、保存方法が異なります。Red Hat Ansible Automation Platform のコンテナーベースのインストール環境では、Podman シークレットを使用して運用上のシークレットを保存します。これらのシークレットは、podman secret list コマンドを使用してリスト表示できます。

デフォルトでは、Podman は、コンテナー化された Red Hat Ansible Automation Platform サービスをインストールおよび実行したユーザーのホームディレクトリーにデータを保存します。Podman シークレットは、base64 でエンコードされた文字列としてファイル $HOME/.local/share/containers/storage/secrets/filedriver/secretsdata.json に保存されます。そのため、プレーンテキストではありませんが、値が難読化されているだけです。

Podman シークレットに保存されているデータは、コマンド podman secret inspect --showsecret <secret> を使用して表示できます。

このファイルを定期的に監視して、不正なアクセスや変更が行われていないことを確認する必要があります。

2.1.3.2. 自動化に使用するシークレット

Automation Controller は、自動化に使用するシークレットや、自動化の結果であるさまざまなシークレットをデータベースに保存します。自動化に使用するシークレットには、次のものがあります。

  • すべての認証情報タイプの全シークレットフィールド (パスワード、シークレットキー、認証トークン、シークレットクラウド認証情報)。
  • Automation Controller 設定で定義された外部サービスのシークレットトークンとパスワード。
  • “password” タイプのサーベイフィールドのエントリー。

実際に認証情報をユーザーに公開せずに、ユーザーとチームにこれらの認証情報を使用する権限を付与できます。そのため、ユーザーが別のチームに異動したり、組織を離れたりした場合も、すべてのシステムのキーを再設定する必要はありません。

Automation Controller は、SSH (または Windows の同等のもの) を使用してリモートホストに接続します。鍵を Automation Controller から SSH に渡すには、鍵を復号化してから名前付きパイプに書き込む必要があります。Automation Controller はそのパイプを使用してキーを SSH に送信します (キーがディスクに書き込まれることはありません)。パスワードが使用されている場合、Automation Controller はパスワードプロンプトに直接応答し、パスワードを復号化してからプロンプトに書き込むことでパスワードを処理します。

スーパーユーザーアクセス権を持つ管理者は、YAML/JSON のような定義を使用して標準形式でカスタム認証情報タイプを定義し、ジョブやインベントリー更新に新しい認証情報タイプを割り当てることができます。これにより、既存の認証情報タイプと同様の方法で機能するカスタム認証情報タイプを定義できます。たとえば、サードパーティー Web サービスの API トークンを環境変数に挿入するカスタム認証情報タイプを作成し、Playbook またはカスタムインベントリースクリプトで使用できます。

Ansible Automation Platform は、シークレットフィールドを暗号化するために、256 ビットキーを使用した Cipher Block Chaining (CBC) モードの Advanced Encryption Standard (AES) を暗号化に使用します。また、Public-Key cryptography Standard (PKCS7) パディングと、SHA256 を使用した Hash-Based Message Authentication Code (HMAC) を認証に使用します。暗号化/復号化プロセスでは、SECRET_KEY、モデルフィールドのフィールド名、およびデータベースによって割り当てられた自動増分レコード ID から AES-256 ビット暗号化キーが導出されます。したがって、キー生成プロセスで使用される属性が変更された場合、Ansible Automation Platform はシークレットを正しく復号化できません。Ansible Automation Platform の設計上、Ansible Automation Platform が起動する Playbook は SECRET_KEY を読み取ることができません。つまり、これらのシークレットを Ansible Automation Platform ユーザーが読み取ることはできません。また、どのシークレットフィールドの値も Ansible Automation Platform REST API を通じては利用できません。Playbook でシークレット値が使用されている場合は、誤ってログに記録されないように、タスクで no_log を使用する必要があります。詳細は、Protecting sensitive data with no log を参照してください。

2.1.3.3. no_log による機密データの保護

Ansible の出力をログに保存すると、パスワードやユーザー名などのシークレットデータが Ansible の出力に表示されます。機密情報をログに記録しないようにするには、機密情報を表示するタスクに no_log: True 属性をマークします。ただし、no_log 属性はデバッグ出力には影響しないため、実稼働環境で Playbook をデバッグしないように注意してください。

2.1.4. ユーザー認証の計画

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

  • インフラストラクチャーアカウント: Ansible Automation Platform サービスを実行する RHEL サーバー上のユーザーアカウント。
  • アプリケーションアカウント: Ansible Automation Platform の Web UI および API のユーザーアカウント。

2.1.4.1. インフラストラクチャーサーバーアカウントの計画

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

注記

ローカルのサービスアカウントの中には、RPM ベースのインストールプログラムによって作成および管理されるものもあります。基盤となる RHEL ホスト上のこのような特定のアカウントは、外部認証ソースから取得することはできません。

2.1.4.2. Ansible Automation Platform アカウントの計画

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

  • LDAP
  • SAML
  • TACACS+
  • Radius
  • Azure Active Directory
  • Google OAuth
  • 汎用 OIDC
  • Keycloak
  • GitHub
  • GitHub 組織
  • GitHub チーム
  • GitHub Enterprise
  • GitHub Enterprise 組織
  • GitHub Enterprise チーム

組織の認証ポリシーに準拠している認証メカニズムを選択し、アクセス管理と認証 を参照して、関連する認証メカニズムの前提条件を確認してください。使用する認証メカニズムは、Ansible Automation Platform と認証バックエンド間の認証関連トラフィックがパブリックまたはセキュアでないネットワーク上で発生した場合に、トラフィックを確実に暗号化するものである必要があります (LDAPS または LDAP over TLS、OAuth2 および SAML プロバイダーの HTTPS など)。

Ansible Automation Platform UI では、どの “システム管理者” アカウントでも、インベントリーまたは自動化の定義を編集、変更、更新できます。このようなアカウント権限は、可能な限り、低レベルの Automation Controller 設定および障害復旧用の最小限のユーザーだけに制限してください。

注記

Ansible Automation Platform 2.6 では、次のすべてのプラットフォームコンポーネントで使用される新しい一元的な認証メカニズムが導入されています。

  • Automation Controller
  • Private Automation Hub
  • Event-Driven Ansible Controller

2.6 より前では、これらの各コンポーネントに独自の認証設定がありました。

2.1.5. ロギングとログキャプチャー

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

2.1.6. 監査とインシデント検出

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

  • Red Hat Enterprise Linux 上の Web サーバーで HTTPS を必須にする。
  • Red Hat Enterprise Linux 上の Web サーバーとデータベースサーバー間の内部通信で TLS 暗号化を必須にする。
  • ポリシーが適切にデプロイされていることを示すレポートを生成する。
  • ポリシーに違反するドリフトを監視する。
  • ポリシー違反の修正を自動化する。

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

識別
セキュリティーポリシーに従って実装すべき要件を定義します。
防御
要件を Ansible Playbook として実装して適用します。
検知
ドリフトを監視し、監査レポートを生成します。
対応
インシデントが検出されたときに実行できるアクションを検討します。
復旧
Ansible を使用して、システムを既知の正常な設定に復元します。

2.1.7. Red Hat Enterprise Linux ホストの計画

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 が必要です。

2.1.7.1. Ansible Automation Platform と追加のソフトウェア

Ansible Automation Platform コンポーネントを Red Hat Enterprise Linux サーバーにインストールする場合、Red Hat Enterprise Linux サーバーはその用途専用にする必要があります。Ansible Automation Platform の他に追加のサーバー機能をインストールすることは避けてください。これはサポート対象外の設定であり、Ansible Automation Platform ソフトウェアのセキュリティーとパフォーマンスに影響を与える可能性があります。

同様に、Ansible Automation Platform を Red Hat Enterprise Linux ホストにデプロイすると、nginx Web サーバー、Pulp ソフトウェアリポジトリー、PostgreSQL データベースサーバー (ユーザー提供の外部データベースを使用する場合を除く) などのソフトウェアがインストールされます。このソフトウェアを変更することや、一般的な方法で使用することは避けてください (たとえば、nginx を使用して追加の Web サイトコンテンツを提供したり、PostgreSQL を使用して追加のデータベースをホストしたりしないでください)。これはサポート対象外の設定であり、セキュリティーとパフォーマンスに影響を与える可能性があります。このソフトウェアの設定は Ansible Automation Platform のインストールプログラムによって管理されます。アップグレードを実行すると、手動による変更が元に戻される可能性があります。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat