管理対象ノード全体でのセキュリティ設定の自動化

はじめに

セキュリティの自動化では、多くの場合、アカウント、所有権、権限、およびエビデンス（証拠）が焦点となります。優れた Playbook は、管理ユーザーのアクセス権を損なうことなく、これらの設定を適用します。

この実験では、ロックされたシステムアカウントの作成、root 所有のセキュリティポリシーファイルのデプロイ、SELinux モードのエビデンス収集を行い、Playbook が冪等（べきとう）であることを証明します。

セキュリティ自動化プロジェクトの作成

このステップでは、LabEx の SSH アクセスや sudo 権限を変更することなく、安全なセキュリティベースラインを構築するためのプロジェクトを作成します。

cd /home/labex/project

mkdir -p rhce-ansible/{inventory,playbooks,reports}

cd rhce-ansible

cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
host_key_checking = False
retry_files_enabled = False
EOF

cat > inventory/hosts <<'EOF'
[managed]
host ansible_connection=local
EOF

この実験では、意図的に labex アカウント、SSH サービス、または sudo アクセスを変更しないようにしています。管理対象のアカウントとポリシーファイルは、隔離された練習用のターゲットです。

セキュリティベースライン変数の定義

このステップでは、Playbook が管理するアカウント、ディレクトリ、およびポリシーファイルを定義します。このステップでコマンドを実行する前に、Ansible プロジェクトディレクトリに戻ってください。これにより、LabEx が各ステップを個別に実行する場合でも、コマンドが安定して動作します。

cd /home/labex/project/rhce-ansible

mkdir -p inventory/group_vars

cat > inventory/group_vars/managed.yml <<'EOF'
audit_user: rhce_audit
security_dir: /etc/rhce-security
security_policy: /etc/rhce-security/policy.conf
EOF

これらの変数は、サービスアカウント名と root 所有のポリシーパスを指定します。変数として保持することで、システムの状態を変更する前にセキュリティベースラインを監査しやすくなります。

cat inventory/group_vars/managed.yml

セキュリティベースライン Playbook の作成

このステップでは、ロックされたシステムアカウント、root 所有のディレクトリ、モード 0600 のポリシーファイル、およびワークスペースのエビデンスレポートを作成する Playbook を作成します。このステップでコマンドを実行する前に、Ansible プロジェクトディレクトリに戻ってください。

cd /home/labex/project/rhce-ansible

cat > playbooks/security-baseline.yml <<'EOF'
---
- name: Apply safe security baseline
  hosts: managed
  become: true
  gather_facts: true
  tasks:
    - name: Ensure locked audit service account exists
      ansible.builtin.user:
        name: "{{ audit_user }}"
        system: true
        shell: /sbin/nologin
        create_home: false
        password_lock: true
        state: present

    - name: Ensure root-owned security directory exists
      ansible.builtin.file:
        path: "{{ security_dir }}"
        state: directory
        owner: root
        group: root
        mode: '0750'

    - name: Deploy root-only security policy
      ansible.builtin.copy:
        dest: "{{ security_policy }}"
        owner: root
        group: root
        mode: '0600'
        content: |
          managed_by=ansible
          selinux_status={{ ansible_selinux.status | default('unknown') }}

    - name: Check current SELinux mode
      ansible.builtin.command: getenforce
      register: selinux_mode
      changed_when: false
      failed_when: false

    - name: Write learner-readable security report
      ansible.builtin.copy:
        dest: /home/labex/project/rhce-ansible/reports/security-report.txt
        owner: labex
        group: labex
        mode: '0640'
        content: |
          audit_user={{ audit_user }}
          policy_mode=0600
          selinux_mode={{ selinux_mode.stdout | default('unknown') }}
EOF

この Playbook は、適用とエビデンス収集を組み合わせたものです。ロックされたシステムアカウントを作成し、root のみがアクセス可能なポリシーファイルを書き込み、タスクを「変更済み」とマークせずに SELinux モードを読み取り、学習者が確認できるレポートをプロジェクト内に書き出します。

ansible-playbook playbooks/security-baseline.yml --syntax-check

実行前に、セキュリティに関わる値（shell: /sbin/nologin、password_lock: true、root 所有権、ポリシーファイルのモード 0600）を確認してください。

セキュリティベースラインの実行と検証

このステップでは、ベースラインを適用し、アカウント、ファイル権限、およびエビデンスレポートを検査します。

cd /home/labex/project/rhce-ansible

ansible-playbook playbooks/security-baseline.yml | tee reports/security-first.txt

初回実行時には、アカウントとポリシーディレクトリが作成されるはずです。以下のチェックにより、Playbook の出力だけでなく、システムの状態を直接確認します。

getent passwd rhce_audit

アカウントのエントリが /sbin/nologin で終わっていることを確認してください。これは、対話型シェルアクセスを目的としていないことを示しています。

sudo stat -c "%U:%G %a %n" /etc/rhce-security /etc/rhce-security/policy.conf

ポリシーファイルが root:root によって所有され、モード 600 になっていることを確認してください。これは root のみがアクセスするポリシーコンテンツとして適切です。

cat reports/security-report.txt

レポートには、管理対象アカウント、期待されるポリシーモード、および観測された SELinux モードが記録されており、迅速に確認できます。

セキュリティベースラインの冪等性の確認

このステップでは、セキュリティベースラインを再度実行します。既存の安全な状態であれば、これ以上の変更は必要ないはずです。

cd /home/labex/project/rhce-ansible

ansible-playbook playbooks/security-baseline.yml | tee reports/security-second.txt

2 回目の実行により、セキュリティベースラインが収束することを確認します。もし再度変更が報告される場合は、どのタスクが変更されたかを確認してください。それは、意図した状態が安定していないことを意味します。

grep -E 'host.*changed=0' reports/security-second.txt

まとめ

LabEx のアクセスパスを変更することなく、ロックされたサービスアカウント、root 所有のセキュリティポリシーファイル、SELinux のエビデンス収集、および冪等性の検証を自動化しました。