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:

Crea un directorio donde se guardarán las evidencias, legible solo por root:

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:

awk -F: '$3 >= 1000 && $7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwd

ana 1000 /bin/bash
luis 1001 /bin/bash

Comprueba quién tiene sudo y que solo root tiene UID 0:

getent group sudo
awk -F: '$3 == 0 {print $1}' /etc/passwd

sudo:x:27:ana,luis
root

Revisa también /etc/sudoers.d/, donde a veces quedan permisos olvidados:

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:

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:

sudo nano /etc/ssh/sshd_config.d/10-soc2.conf

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:

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:

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:

google-authenticator -t -d -f -r 3 -R 30 -W

Edita la configuración PAM de SSH:

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:

# @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:

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.

sudo sshd -t
sudo systemctl restart ssh

Desde otra terminal, conecta de nuevo. Tras aceptar la clave, SSH te pedirá el código:

(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.

sudo apt install auditd audispd-plugins

sudo nano /etc/audit/rules.d/50-soc2.rules

## 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:

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:

sudo systemctl restart auditd

Comprueba que se registran eventos, por ejemplo los comandos ejecutados con sudo en la última hora:

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:

sudo nano /etc/rsyslog.d/60-forward.conf

*.* 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:

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:

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.

sudo apt install aide

Crea la base de datos inicial. Tarda varios minutos:

sudo aideinit -y -f

Lanza una comprobación manual para ver el formato:

sudo aide --config /etc/aide/aide.conf --check

AIDE found NO differences between database and filesystem. Looks okay!!

El paquete de Ubuntu programa una comprobación diaria. Confírmalo con:

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:

cat /etc/apt/apt.conf.d/20auto-upgrades

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:

sudo apt install etckeeper

Tras un cambio manual, haz un commit con el número de ticket de tu sistema de cambios:

sudo etckeeper commit "CHG-1234: endurecer sshd según política de acceso"

Consulta el historial:

sudo git -C /etc log --oneline | head

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.

sudo nano /usr/local/sbin/soc2-evidence

#!/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:

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:

sudo nano /etc/systemd/system/soc2-evidence.service

[Unit]
Description=Recogida mensual de evidencias SOC 2

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/soc2-evidence

Y el temporizador:

sudo nano /etc/systemd/system/soc2-evidence.timer

[Unit]
Description=Ejecuta la recogida de evidencias SOC 2 cada mes

[Timer]
OnCalendar=monthly
Persistent=true

[Install]
WantedBy=timers.target

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.