Introducción
La automatización de la seguridad suele centrarse en las cuentas, la propiedad, los permisos y la evidencia. Un buen playbook aplica estos ajustes sin debilitar el acceso del usuario de gestión.
En este laboratorio, creará una cuenta de sistema bloqueada, desplegará archivos de política de seguridad propiedad de root, recopilará evidencia del modo SELinux y demostrará que el playbook es idempotente.
Crear un proyecto de automatización de seguridad
En este paso, creará un proyecto para una línea base de seguridad segura que evite modificar el acceso SSH o sudo de 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 laboratorio evita deliberadamente cambiar la cuenta labex, el servicio SSH o el acceso sudo. La cuenta gestionada y los archivos de política son objetivos de práctica aislados.
Definir variables de la línea base de seguridad
En este paso, definirá la cuenta, el directorio y el archivo de política que gestionará el playbook. Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto de Ansible. Esto mantiene los comandos estables incluso cuando LabEx ejecuta cada paso por separado.
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
Las variables nombran la cuenta de servicio y la ruta de la política propiedad de root. Mantenerlas en variables facilita la auditoría de la línea base de seguridad antes de que cambie el estado del sistema.
cat inventory/group_vars/managed.yml
Escribir el playbook de la línea base de seguridad
En este paso, escribirá un playbook que crea una cuenta de sistema bloqueada, un directorio propiedad de root, un archivo de política con modo 0600 y un informe de evidencia del espacio de trabajo.
Antes de ejecutar los comandos en este paso, regrese al directorio del proyecto de Ansible. Esto mantiene los comandos estables incluso cuando LabEx ejecuta cada paso por separado.
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
El playbook combina la aplicación de políticas y la recopilación de evidencia. Crea una cuenta de sistema bloqueada, escribe archivos de política solo para root, lee el modo SELinux sin marcar la tarea como modificada y escribe un informe legible para el usuario en el proyecto.
ansible-playbook playbooks/security-baseline.yml --syntax-check
Revise los valores sensibles a la seguridad antes de ejecutar: shell: /sbin/nologin, password_lock: true, propiedad de root y modo 0600 en el archivo de política.
Ejecutar e inspeccionar la línea base de seguridad
En este paso, aplicará la línea base e inspeccionará la cuenta, los permisos de archivo y el informe de evidencia.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-first.txt
La primera ejecución debería crear la cuenta y el directorio de políticas. Las comprobaciones a continuación confirman el estado del sistema directamente en lugar de confiar únicamente en la salida del playbook.
getent passwd rhce_audit
La entrada de la cuenta debe terminar en /sbin/nologin, lo que indica que no está destinada al acceso interactivo por shell.
sudo stat -c "%U:%G %a %n" /etc/rhce-security /etc/rhce-security/policy.conf
El archivo de política debe ser propiedad de root:root y usar el modo 600, lo cual es apropiado para contenido de política exclusivo de root.
cat reports/security-report.txt
El informe registra la cuenta gestionada, el modo de política esperado y el modo SELinux observado para una revisión rápida.
Confirmar la idempotencia de la línea base de seguridad
En este paso, ejecutará la línea base de seguridad nuevamente. El estado seguro existente no debería requerir más cambios.
cd /home/labex/project/rhce-ansible
ansible-playbook playbooks/security-baseline.yml | tee reports/security-second.txt
La segunda ejecución verifica que la línea base de seguridad converja. Si informa cambios nuevamente, inspeccione qué tarea cambió, ya que eso significa que un estado deseado no era estable.
grep -E 'host.*changed=0' reports/security-second.txt
Resumen
Ha automatizado una cuenta de servicio bloqueada, archivos de política de seguridad propiedad de root, la recopilación de evidencia de SELinux y la validación de idempotencia sin cambiar la ruta de acceso de LabEx.
