--- title: "Preparar servidores Ubuntu 24.04 para una auditoría SOC 2" description: "Aplica en Ubuntu 24.04 los controles técnicos que revisa una auditoría SOC 2: acceso con MFA, auditd, logs centralizados, AIDE, parches y evidencias mensuales." category: "Cumplimiento y Auditoría" language: es source: https://cubepath.com/es/docs/cumplimiento-y-auditoría/cumplimiento-soc2-para-servidores-linux updated: 2026-09-25 --- # Preparar servidores Ubuntu 24.04 para una auditoría SOC 2 SOC 2 es un informe de auditoría del AICPA que evalúa los controles de una organización frente a los Trust Services Criteria: seguridad (obligatoria), disponibilidad, integridad del procesamiento, confidencialidad y privacidad. No existe una "configuración SOC 2" oficial: tú defines los controles y el auditor comprueba que existen (Tipo I) y que han funcionado durante un periodo, normalmente de 3 a 12 meses (Tipo II). En este tutorial implementarás en Ubuntu 24.04 los controles técnicos que casi todos los auditores revisan en un servidor Linux y dejarás preparada la recogida automática de evidencias. ## Requisitos previos - Uno o varios servidores con Ubuntu 24.04 LTS, por ejemplo VPS de CubePath. - Un usuario no root con privilegios `sudo` y acceso SSH por clave pública. - Acceso a la consola del servidor por si un cambio de SSH o PAM te deja fuera. - Opcional: un servidor de logs o SIEM que acepte syslog por TCP en la red privada (paso 5). - Políticas escritas de acceso, cambios e incidentes. Esta guía cubre la parte técnica; sin políticas documentadas no hay auditoría que superar. ## Paso 1: Relacionar los criterios con controles técnicos Los criterios comunes (CC) de seguridad son los que más afectan a un servidor. Esta tabla resume qué pedirá el auditor y qué harás en cada paso: | Criterio | Qué exige | Control en esta guía | |----------|-----------|----------------------| | CC6.1 | Acceso lógico restringido y autenticación fuerte | Usuarios nominales, SSH por clave, MFA (pasos 2 y 3) | | CC6.2, CC6.3 | Altas, bajas y revisión periódica de accesos | Revisión de cuentas y sudo (paso 2, evidencia en paso 8) | | CC7.2 | Monitorización de eventos anómalos | auditd, logs centralizados, AIDE (pasos 4 a 6) | | CC7.1 | Detección de vulnerabilidades y configuraciones | Parches automáticos (paso 7) | | CC8.1 | Cambios autorizados y registrados | etckeeper (paso 7) | | A1.2 | Copias de seguridad y recuperación | Fuera del alcance de esta guía: usa tu herramienta de backup y documenta las pruebas de restauración | Crea un directorio donde se guardarán las evidencias, legible solo por root: ```bash sudo install -d -m 700 /var/lib/soc2-evidence ``` ## Paso 2: Revisar cuentas y privilegios SOC 2 pide que cada acceso sea atribuible a una persona. Nada de cuentas compartidas como `deploy` o `admin` con varias personas usando la misma clave. Lista las cuentas humanas (UID 1000 o superior) con shell válida: ```bash awk -F: '$3 >= 1000 && $7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd ``` ```output ana 1000 /bin/bash luis 1001 /bin/bash ``` Comprueba quién tiene `sudo` y que solo root tiene UID 0: ```bash getent group sudo awk -F: '$3 == 0 {print $1}' /etc/passwd ``` ```output sudo:x:27:ana,luis root ``` Revisa también `/etc/sudoers.d/`, donde a veces quedan permisos olvidados: ```bash sudo grep -rv '^#' /etc/sudoers.d/ ``` Cuando alguien deja el equipo, bloquea su cuenta y retira sus claves el mismo día; el auditor comparará la fecha de baja en RR. HH. con la de bloqueo: ```bash sudo usermod --lock --expiredate 1 old_user sudo mv /home/old_user/.ssh/authorized_keys /home/old_user/.ssh/authorized_keys.disabled ``` ## Paso 3: Endurecer SSH y añadir un segundo factor ### Configuración de SSH En Ubuntu 24.04 los ficheros de `/etc/ssh/sshd_config.d/` se leen antes que el resto de `sshd_config` y gana el primer valor encontrado. Usa un número bajo para que tu fichero prevalezca sobre `50-cloud-init.conf`: ```bash sudo nano /etc/ssh/sshd_config.d/10-soc2.conf ``` ```text PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes X11Forwarding no MaxAuthTries 4 LoginGraceTime 60 LogLevel VERBOSE ``` `LogLevel VERBOSE` registra la huella de la clave usada en cada inicio de sesión, lo que permite atribuir cada acceso a una persona concreta. Valida y aplica: ```bash sudo sshd -t sudo systemctl restart ssh ``` ### MFA con TOTP Para que el acceso requiera clave SSH más un código de un solo uso, instala el módulo PAM de Google Authenticator: ```bash sudo apt install libpam-google-authenticator ``` Cada usuario debe generar su secreto con su propia cuenta (no con `sudo`). Escanea el código QR con una app TOTP y guarda los códigos de emergencia: ```bash google-authenticator -t -d -f -r 3 -R 30 -W ``` Edita la configuración PAM de SSH: ```bash sudo nano /etc/pam.d/sshd ``` Comenta la línea `@include common-auth` (para que no se pida también la contraseña) y añade debajo el módulo TOTP: ```text # @include common-auth auth required pam_google_authenticator.so ``` Después indica a SSH que exija ambos métodos, añadiendo estas líneas a `/etc/ssh/sshd_config.d/10-soc2.conf`: ```text KbdInteractiveAuthentication yes AuthenticationMethods publickey,keyboard-interactive ``` > Advertencia: todos los usuarios deben haber ejecutado `google-authenticator` antes de este cambio, o no podrán entrar. Mantén una sesión SSH abierta mientras lo pruebas. ```bash sudo sshd -t sudo systemctl restart ssh ``` Desde otra terminal, conecta de nuevo. Tras aceptar la clave, SSH te pedirá el código: ```output (your_user@your_server_ip) Verification code: ``` ## Paso 4: Registrar eventos de seguridad con auditd auditd registra en el kernel quién cambia usuarios, sudoers o la configuración de SSH, y quién ejecuta comandos como root. Es la base de la evidencia para CC7.2. ```bash sudo apt install auditd audispd-plugins ``` ```bash sudo nano /etc/audit/rules.d/50-soc2.rules ``` ```text ## Identidad y privilegios -w /etc/passwd -p wa -k identity -w /etc/group -p wa -k identity -w /etc/shadow -p wa -k identity -w /etc/sudoers -p wa -k privileges -w /etc/sudoers.d -p wa -k privileges ## Configuración de SSH y PAM -w /etc/ssh/sshd_config -p wa -k sshd -w /etc/ssh/sshd_config.d -p wa -k sshd -w /etc/pam.d -p wa -k pam ## Comandos ejecutados como root por usuarios humanos -a always,exit -F arch=b64 -S execve -F euid=0 -F auid>=1000 -F auid!=unset -k root-commands ``` Carga las reglas: ```bash sudo augenrules --load sudo auditctl -l ``` Por defecto auditd rota a los 8 MB y conserva 5 ficheros, lo que en un servidor activo puede ser menos de un día. Si no envías los logs a un sistema central (paso 5), aumenta la retención en `/etc/audit/auditd.conf`, por ejemplo con `max_log_file = 50` y `num_logs = 20`, y reinicia el servicio: ```bash sudo systemctl restart auditd ``` Comprueba que se registran eventos, por ejemplo los comandos ejecutados con `sudo` en la última hora: ```bash sudo ausearch -k root-commands -ts recent -i | tail -n 5 ``` ## Paso 5: Centralizar los registros Un atacante con root puede borrar los logs locales, por eso los auditores esperan una copia fuera del servidor. rsyslog viene instalado en Ubuntu. Crea una regla de reenvío por TCP con cola en disco, para no perder mensajes si el destino cae: ```bash sudo nano /etc/rsyslog.d/60-forward.conf ``` ```text *.* action(type="omfwd" target="your_log_server" port="514" protocol="tcp" queue.type="LinkedList" queue.filename="fwd_queue" queue.saveOnShutdown="on" action.resumeRetryCount="-1") ``` Sustituye `your_log_server` por la IP privada de tu servidor de logs. Este reenvío va sin cifrar, así que úsalo solo por una red privada o una VPN. Para que los eventos de auditd también lleguen a syslog, activa el plugin correspondiente: ```bash sudo sed -i 's/^active = no/active = yes/' /etc/audit/plugins.d/syslog.conf sudo systemctl restart auditd rsyslog ``` Envía un mensaje de prueba y búscalo en el servidor central: ```bash logger -t soc2-test "Prueba de reenvío desde $(hostname)" ``` ## Paso 6: Vigilar la integridad de ficheros con AIDE AIDE guarda una base de datos con los hashes de binarios y ficheros de configuración y avisa de cualquier cambio. Cubre el requisito de detectar modificaciones no autorizadas. ```bash sudo apt install aide ``` Crea la base de datos inicial. Tarda varios minutos: ```bash sudo aideinit -y -f ``` Lanza una comprobación manual para ver el formato: ```bash sudo aide --config /etc/aide/aide.conf --check ``` ```output AIDE found NO differences between database and filesystem. Looks okay!! ``` El paquete de Ubuntu programa una comprobación diaria. Confírmalo con: ```bash systemctl list-timers | grep -i aide ``` Tras cada cambio legítimo (una actualización, una edición en `/etc`), el informe mostrará diferencias. Revísalas y actualiza la base de datos con `sudo aideinit -y -f`. Esa revisión es justo lo que el auditor quiere ver documentado. ## Paso 7: Parches y control de cambios ### Actualizaciones de seguridad automáticas Ubuntu instala `unattended-upgrades` por defecto. Comprueba que está activo: ```bash cat /etc/apt/apt.conf.d/20auto-upgrades ``` ```output APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; ``` El registro de lo que se ha instalado queda en `/var/log/unattended-upgrades/unattended-upgrades.log`, que sirve como evidencia de gestión de vulnerabilidades. ### Historial de cambios de /etc con etckeeper CC8.1 pide que los cambios de configuración queden registrados. etckeeper guarda `/etc` en un repositorio git y hace un commit automático antes y después de cada `apt`: ```bash sudo apt install etckeeper ``` Tras un cambio manual, haz un commit con el número de ticket de tu sistema de cambios: ```bash sudo etckeeper commit "CHG-1234: endurecer sshd según política de acceso" ``` Consulta el historial: ```bash sudo git -C /etc log --oneline | head ``` ```output 3f1c2ab CHG-1234: endurecer sshd según política de acceso 9a07d11 committing changes in /etc made by "apt install aide" b52e0f4 Initial commit ``` ## Paso 8: Recoger evidencias automáticamente En una auditoría Tipo II te pedirán muestras de varios meses. Un script mensual que capture el estado de los controles evita reconstruirlo a última hora. ```bash sudo nano /usr/local/sbin/soc2-evidence ``` ```bash #!/usr/bin/env bash set -euo pipefail dest="/var/lib/soc2-evidence/$(date +%Y-%m)" install -d -m 700 "$dest" awk -F: '$3 >= 1000 && $7 !~ /(nologin|false)$/' /etc/passwd > "$dest/usuarios.txt" getent group sudo > "$dest/sudo.txt" sshd -T > "$dest/sshd-efectivo.txt" ufw status verbose > "$dest/firewall.txt" 2>&1 || true last -F -n 200 > "$dest/ultimos-accesos.txt" aureport --summary --start this-month > "$dest/auditd-resumen.txt" 2>&1 || true git -C /etc log --since="1 month ago" --stat > "$dest/cambios-etc.txt" grep -h "Packages that will be upgraded" /var/log/unattended-upgrades/unattended-upgrades.log \ > "$dest/parches.txt" 2>/dev/null || true aide --config /etc/aide/aide.conf --check > "$dest/aide.txt" 2>&1 || true sha256sum "$dest"/*.txt > "$dest/SHA256SUMS" ``` El `|| true` es intencionado en los comandos que devuelven un código distinto de cero en situaciones normales (AIDE lo hace cuando encuentra cambios). Hazlo ejecutable y pruébalo: ```bash sudo chmod 750 /usr/local/sbin/soc2-evidence sudo /usr/local/sbin/soc2-evidence sudo ls /var/lib/soc2-evidence/$(date +%Y-%m) ``` Prográmalo con un temporizador de systemd. Primero el servicio: ```bash sudo nano /etc/systemd/system/soc2-evidence.service ``` ```ini [Unit] Description=Recogida mensual de evidencias SOC 2 [Service] Type=oneshot ExecStart=/usr/local/sbin/soc2-evidence ``` Y el temporizador: ```bash sudo nano /etc/systemd/system/soc2-evidence.timer ``` ```ini [Unit] Description=Ejecuta la recogida de evidencias SOC 2 cada mes [Timer] OnCalendar=monthly Persistent=true [Install] WantedBy=timers.target ``` ```bash sudo systemctl daemon-reload sudo systemctl enable --now soc2-evidence.timer systemctl list-timers soc2-evidence.timer ``` Copia periódicamente `/var/lib/soc2-evidence` a un almacenamiento fuera del servidor. ## Solución de problemas **No puedes entrar tras activar MFA.** Entra por la consola y revisa `sudo journalctl -u ssh -n 50`. Lo habitual es que el usuario no tenga `~/.google_authenticator` o que la hora del servidor esté desfasada: comprueba `timedatectl` y que `NTP service` esté `active`. **`auditctl -l` no muestra reglas.** Revisa errores de sintaxis con `sudo augenrules --check` y `sudo journalctl -u auditd -n 30`. **AIDE genera demasiado ruido.** Añade exclusiones para rutas que cambian a menudo y no aportan seguridad (cachés de aplicaciones) en un fichero dentro de `/etc/aide/aide.conf.d/`, y regenera la base de datos. ## Conclusión Tus servidores Ubuntu 24.04 tienen ahora acceso nominal con clave y MFA, auditoría de eventos privilegiados, logs fuera del servidor, control de integridad, parches automáticos, historial de cambios y una recogida mensual de evidencias. Como siguientes pasos, documenta cada control en tu matriz de controles con su responsable, añade la revisión trimestral de accesos a tu calendario y define y prueba tu procedimiento de copias de seguridad y restauración para los criterios de disponibilidad.