Introdução
A automação de segurança geralmente foca em contas, propriedade, permissões e evidências. Um bom playbook aplica essas configurações sem enfraquecer o acesso do usuário de gerenciamento.
Neste laboratório, você criará uma conta de sistema bloqueada, implantará arquivos de política de segurança de propriedade do root, coletará evidências do modo SELinux e provará que o playbook é idempotente.
Criar um Projeto de Automação de Segurança
Nesta etapa, você criará um projeto para uma linha de base de segurança segura que evita alterar o acesso SSH ou sudo do LabEx.
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
Este laboratório evita deliberadamente alterar a conta labex, o serviço SSH ou o acesso sudo. A conta gerenciada e os arquivos de política são alvos de prática isolados.
Definir Variáveis da Linha de Base de Segurança
Nesta etapa, você definirá a conta, o diretório e o arquivo de política que o playbook irá gerenciar. Antes de executar os comandos nesta etapa, retorne ao diretório do projeto Ansible. Isso mantém os comandos estáveis, mesmo quando o LabEx executa cada etapa separadamente.
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
As variáveis nomeiam a conta de serviço e o caminho da política de propriedade do root. Mantê-las em variáveis torna a linha de base de segurança mais fácil de auditar antes que ela altere o estado do sistema.
cat inventory/group_vars/managed.yml
Escrever o Playbook da Linha de Base de Segurança
Nesta etapa, você escreverá um playbook que cria uma conta de sistema bloqueada, um diretório de propriedade do root, um arquivo de política com modo 0600 e um relatório de evidências no espaço de trabalho.
Antes de executar os comandos nesta etapa, retorne ao diretório do projeto Ansible. Isso mantém os comandos estáveis, mesmo quando o LabEx executa cada etapa separadamente.
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
O playbook combina aplicação e evidência. Ele cria uma conta de sistema bloqueada, grava arquivos de política acessíveis apenas pelo root, lê o modo SELinux sem marcar a tarefa como alterada e grava um relatório legível pelo aluno de volta no projeto.
ansible-playbook playbooks/security-baseline.yml --syntax-check
Revise os valores sensíveis à segurança antes de executar: shell: /sbin/nologin, password_lock: true, propriedade do root e modo 0600 no arquivo de política.
Executar e Inspecionar a Linha de Base de Segurança
Nesta etapa, você aplicará a linha de base e inspecionará a conta, as permissões de arquivo e o relatório de evidências.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-first.txt
A primeira execução deve criar a conta e o diretório de política. As verificações abaixo confirmam o estado do sistema diretamente, em vez de confiar apenas na saída do playbook.
getent passwd rhce_audit
A entrada da conta deve terminar com /sbin/nologin, mostrando que não se destina ao acesso interativo via shell.
sudo stat -c "%U:%G %a %n" /etc/rhce-security /etc/rhce-security/policy.conf
O arquivo de política deve ser de propriedade de root:root e usar o modo 600, o que é apropriado para conteúdo de política acessível apenas pelo root.
cat reports/security-report.txt
O relatório registra a conta gerenciada, o modo de política esperado e o modo SELinux observado para revisão rápida.
Confirmar a Idempotência da Linha de Base de Segurança
Nesta etapa, você executará a linha de base de segurança novamente. O estado seguro existente não deve precisar de mais alterações.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-second.txt
A segunda execução verifica se a linha de base de segurança converge. Se ela relatar alterações novamente, inspecione qual tarefa foi alterada, pois isso significa que um estado desejado não estava estável.
grep -E 'host.*changed=0' reports/security-second.txt
Resumo
Você automatizou uma conta de serviço bloqueada, arquivos de política de segurança de propriedade do root, coleta de evidências do SELinux e validação de idempotência sem alterar o caminho de acesso do LabEx.
