第3章 管理対象ノードの設定
Ansible Automation Platform は、自動化タスクを実行するために、管理対象のデバイス (管理対象ノード) へのリモート接続を利用するエージェントレステクノロジーです。
この章では、Ansible Automation Platform と管理対象ノード間のリモート接続など、Ansible Automation Platform によって自動化された管理対象ノードのセキュリティー体制を改善するための推奨事項を示します。
管理対象ノードの設定は、オペレーティングシステム、コンプライアンスプロファイル、設定、組織のポリシーなどの要因によって大きく異なる場合があることに注意してください。
ここで示す管理対象ノードの設定に関する推奨事項は、実装前に徹底的にテストおよびレビューして、組織のポリシーと要件を満たしていることを確認する必要があります。
3.1. Red Hat Enterprise Linux 管理対象ノードの設定 リンクのコピーリンクがクリップボードにコピーされました!
次のセクションでは、Red Hat Enterprise Linux (RHEL) の管理対象ノードに関するガイダンスを提供します。ただし、他の Linux ディストリビューションにも同じ概念が当てはまる可能性があります。
RHEL 管理対象ノードの手動設定を例として提供しています。この手順は、Ansible Automation Platform を使用して自動化することも、Red Hat Insights の Image Builder などのツールを使用して作成した 標準運用環境 (SOE) または "ゴールデンイメージ" に追加することもできます。
3.1.1. アクセス制限付きの専用サービスアカウントの作成 リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform は、管理対象ノードに接続するために、さまざまなユーザーまたはアカウントを使用するように設定できます。
このガイドでは、この目的のために単一の専用サービスアカウントを作成することを推奨しています。外部認証メカニズムに障害が発生した場合でも自動化ジョブを継続して実行するために、このサービスアカウントは各管理対象ノード上のローカルアカウントである必要があります。この推奨事項は、組織のポリシーで一元管理されたサービスアカウントが必須とされていない限り適用されます。サービスアカウントには、その目的を明確に示す名前を付ける必要があります (例: ansible
、aapsvc
)。
このセクションで後述する例では、ローカルサービスアカウントの仮の名前として "ansible" を使用します。
ローカルサービスアカウントは次のように設定します。
- 必要な自動化ジョブを実行するのに十分な特権を付与します。
- SSH 鍵認証だけに制限します。パスワード認証を禁止します。
Ansible Automation Platform {ControllerNames} および実行ノードから行われた接続にのみアクセスを許可します。
注記Ansible Playbook またはジョブテンプレート内のタスクをサービスアカウント以外のユーザーとして実行するには、
become
およびbecome_user
キーワードを使用してください。別のユーザーとして管理対象ノードに接続する必要はありません。-
useradd
コマンドを使用して、ローカルサービスアカウントを作成できます。以下に例を示します。
sudo useradd ansible \ --system --create-home \ --comment "Ansible Automation Platform service account"
sudo useradd ansible \
--system --create-home \
--comment "Ansible Automation Platform service account"
3.1.1.1. サービスアカウントの sudo 特権を設定する リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントには、管理対象ノードで現在または将来の自動化ジョブを実行するための十分な特権が必要です。このセクションでは sudo
の使用について説明しますが、他の特権昇格方法も利用できます。
Ansible Automation Platform は、Linux ベースの管理対象ノードでは、デフォルトで ansible.builtin.sudo
become plugin を使用します。そのため、サービスアカウントには、sudo コマンドを使用して RHEL 管理対象ノードで任意のコマンドを実行する権限を与える必要があります。
これを設定するには、次の手順を使用します。
手順
ファイル
/etc/sudoers.d/ansible
を作成し、次の内容を含めます。Rules for the ansible service account
# Rules for the ansible service account ansible ALL=(ALL) NOPASSWD: ALL
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルに制限的な権限を設定します。
sudo chmod 600 /etc/sudoers.d/ansible
ファイルが適切な構文を使用していることを確認します。
sudo visudo -cf /etc/sudoers.d/ansible
3.1.1.2. サービスアカウントに対して SSH 鍵認証を必須とする リンクのコピーリンクがクリップボードにコピーされました!
サービスアカウントには、管理対象ノードへの SSH 接続でパスワード認証を使用することを許可してはなりません。
次の手順を使用して SSH デーモンを設定してください。
手順
ファイル
/etc/sshd/sshd_config.d/60-ansible.conf
を作成し、次の内容を含めます。sshd config applied to the ansible service account
# sshd config applied to the ansible service account Match User ansible PasswordAuthentication no Match all
Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルが適切な構文を使用していることを確認します。
sudo sshd -t
SSH デーモンを再起動します。
sudo systemctl restart sshd.service
パスワード認証を禁止する場合、少なくとも 1 つの SSH 公開鍵をサービスアカウントの authorized_keys ファイル (通常は /home/ansible/.ssh/authorized_keys
にあります) に追加する必要があります。
これらの公開鍵は、Ansible Automation Platform でマシン認証情報を確立するために使用される秘密鍵と対応している必要があります。なぜなら、この認証情報が RHEL 管理対象ノードへの接続を可能にするものだからです。
このガイドでは、管理対象 RHEL ノードへの接続に 1 つのサービスアカウントを使用することを推奨しています。ただし、すべてのノードで 1 つの SSH 鍵を使用する必要があるわけではありません。大規模な組織では、RHEL サーバーを管理する個々のチームが、Ansible Automation Platform 内で各自のマシン認証情報を生成する場合があります。各チームは、対応するキーを特定の RHEL サーバー上の許可されたキーファイルに追加できます。この方式であれば、共通のサービスアカウントを使用することで、組織全体で管理対象ノードへの一貫したアクセスを確保すると同時に、各チームが割り当てられたノードの認証情報を個別に管理できます。
3.1.1.3. サービスアカウントの pam_access 制御を有効にして設定する リンクのコピーリンクがクリップボードにコピーされました!
次の手順を使用して、Ansible Automation Platform の Automation Controller および実行ノードから行われた接続にリモートログインアクセスを制限し、サービスアカウントが Ansible Automation Platform によって排他的に使用されるようにします。
手順
Automation Controller および実行ノードの FQDN を使用して、次の内容を
/etc/security/access.conf
ファイルに追加します。その際に、コントローラーノードと実行ノードの FQDN を使用します。allow the ansible service account to log in from local sources and the hybrid controller or execution nodes, and deny all other sources
# allow the ansible service account to log in from local sources and # the hybrid controller or execution nodes, and deny all other sources +:ansible:LOCAL controller1.example.com controller2.example.com en1.example.com -:ansible:ALL
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 現在の authselect プロファイルで
with-pamaccess
機能を有効にします。この機能は、RHEL にデフォルトで含まれているすべての authselect プロファイルに存在します。sudo authselect enable-feature with-pamaccess
3.1.2. コンプライアンスプロファイルに関する考慮事項 リンクのコピーリンクがクリップボードにコピーされました!
多くの環境では、CIS、PCI/DSS、DISA STIG などのコンプライアンスプロファイルの要件を満たすために、管理対象 RHEL ノードにセキュリティー制御が適用されているシステムを、Ansible Automation Platform を使用して管理できます。次のセクションでは、このような環境で Ansible Automation Platform で RHEL ノードを適切に管理するために変更する必要がある特定のセキュリティー制御セットについて詳しく説明します。
3.1.2.1. 管理対象 RHEL ノード上の fapolicyd リンクのコピーリンクがクリップボードにコピーされました!
Ansible Automation Platform ジョブが RHEL 管理対象ノードに対して実行されるとき、ほとんどのタスクは Python コードを管理対象ノードにコピーし、それをローカルで実行することによって実行されます。管理対象ノードで fapolicyd
サービスが有効な場合、RHEL に付属するデフォルトのルールセットによってこの Python コードの実行が阻止されるため、ジョブが失敗します。
この問題の発生を防ぐには、次のいずれかの方法を使用します。
- 方法 1: fapolicyd サービスを permissive モードに設定する
- 方法 2: カスタムの fapolicyd ルールを作成する
3.1.2.2. 方法 1: fapolicyd サービスを permissive モードに設定する リンクのコピーリンクがクリップボードにコピーされました!
fapolicyd サービスは "permissive" モードに設定できます。設定すると、fapolicyd ルールが適用されずに、ルール違反がログに記録されるだけになります。
fapolicyd の permissive モードを設定するには、次の手順を使用します。
手順
-
ファイル
/etc/fapolicyd/fapolicyd.conf
を編集し、"permissive = 1" を設定します。 -
systemctl restart fapolicyd.service
を実行して、fapolicy
サービスを再起動します。
必要なコンプライアンスプロファイルまたはローカルポリシーがこの設定によって満たされない可能性がある環境では、関連するセキュリティー制御の免除について、セキュリティー監査担当者と相談してください。
3.1.2.3. 方法 2: カスタムの fapolicyd ルールを作成する リンクのコピーリンクがクリップボードにコピーされました!
fapolicyd
サービスによってルールを適用する必要がある場合は、Ansible Automation Platform が Python コードを実行できるように、カスタムのルールセットを作成することを検討してください。
次の手順の例では、"ansible" サービスアカウントを信頼できるエンティティーとして扱い、サービスアカウントがローカルの Ansible 一時ディレクトリー (デフォルトでは $HOME/.ansible/tmp
) 内のコンテンツを実行できるようにします。
手順
次の内容を含むファイル
/etc/fapolicy/rules.d/50-ansible.rules
を作成します。allow perm=any uid=ansible trust=1 : dir=/home/ansible/.ansible/tmp/
fapolicyd サービスを再起動します。
sudo systemctl restart fapolicyd.service
このルールの例は、管理対象 RHEL ノード上に存在する他の fapolicyd
ルールと連携するように、変更する必要がある可能性があります。実稼働環境に導入する前に、セキュリティー監査担当者による十分なテストと承認を受ける必要があります。