Martes, 27 de octubre de 2026

Lo más relevante del hosting en el mundo, en español · ehost.ec →

Automation DISA STIG para AlmaLinux OS 9 ya disponible en ComplianceAsCode

TuxCare contribuyó un perfil automatizado DISA STIG para AlmaLinux OS 9 y los mantenedores de ComplianceAsCode lo integraron el 20 de octubre de 2026; ahora OpenSCAP puede auditar sistemas AlmaLinux 9 contra ese STIG.

Por Equipo ehost3 min de lecturaFuente: Blog on AlmaLinux
Automation DISA STIG para AlmaLinux OS 9 ya disponible en ComplianceAsCode
Imagen ilustrativa generada con inteligencia artificial.

El proyecto ComplianceAsCode incorpora un perfil DISA STIG específico para AlmaLinux OS 9, creado y aportado por TuxCare, lo que permite ejecutar auditorías automatizadas con OpenSCAP sobre sistemas AlmaLinux 9. La entrada se fusionó en el repositorio el 20 de octubre de 2026 y quedará incluido en la próxima versión pública del proyecto.

Qué incluye el perfil DISA STIG para AlmaLinux 9

El perfil traduce el documento STIG (Security Technical Implementation Guide) en controles automatizados legibles por OpenSCAP. Según la contribución, la versión del STIG cubierta lista cientos de requisitos: la gran mayoría dispone de comprobaciones automáticas; solo un pequeño número exige revisión manual o no aplica porque algunas paquetes no existen en AlmaLinux 9.

ComplianceAsCode genera tanto las comprobaciones como remediaciones en varios formatos: reglas SCAP, scripts Bash y playbooks Ansible. Esos artefactos facilitan repetir auditorías, aplicar correcciones y volver a escanear para validar cambios.

Qué cambia y a quién afecta

Antes de esta contribución, las opciones libres para evaluar un AlmaLinux 9 frente al STIG eran limitadas o requerían trabajo manual. Con el perfil disponible en ComplianceAsCode, administradores de sistemas, equipos de seguridad y responsables de cumplimiento pueden:

  • Ejecutar OpenSCAP contra un sistema AlmaLinux 9 y obtener un informe detallado de qué requisitos STIG se cumplen o fallan.
  • Usar los scripts y playbooks generados para automatizar remediaciones repetibles.
  • Integrar las comprobaciones en procesos de auditoría y pipelines de CI/CD que usen contenedores o imágenes del sistema.

La novedad beneficia especialmente a organizaciones que adoptan estándares estrictos de configuración (como los que exige DISA) y a cualquier operador que quiera un punto de referencia de endurecimiento completo, aunque no trabaje para el gobierno de EE. UU., ya que los STIG son de acceso público.

Limitaciones y precauciones prácticas

No todos los requisitos del STIG se automatizan completamente: algunas comprobaciones requieren revisión humana y otras reglas pueden no aplicar según los paquetes instalados en la máquina. Además, varias remediaciones incluidas son intrusivas (por ejemplo, cambios en la autenticación o restricciones SSH) y pueden bloquear el acceso si se aplican en sistemas de producción sin precauciones.

Por ello se recomienda:

  • Probar las remediaciones en máquinas virtuales o entornos de ensayo antes de aplicarlas en servidores en producción.
  • Leer las descripciones de las remediaciones y comprender el impacto (por ejemplo, métodos de acceso alternativos antes de cambiar la autenticación).
  • Usar la opción de OpenSCAP que descarga recursos remotos para comprobar actualizaciones y parches cuando el sistema tenga acceso a Internet.

Disponibilidad y próximos pasos

El perfil ya está en la rama principal del proyecto ComplianceAsCode y quedó asignado a la próxima versión pública del contenido. Mientras tanto, los administradores pueden construir el perfil desde el código fuente en un sistema AlmaLinux 9 para ejecutar escaneos de forma inmediata.

La comunidad puede colaborar abriendo issues o pull requests en el repositorio de ComplianceAsCode si detecta falsos positivos, reglas que no encajan con AlmaLinux o errores tipográficos. Las semanas previas al lanzamiento oficial son el mejor momento para proponer correcciones.

Advertencia práctica: pasar todas las comprobaciones del STIG no depende solo del perfil: algunos requisitos nombran componentes específicos o dependencias (por ejemplo, paquetes o repositorios de actualizaciones firmadas). En entornos que ya no reciben soporte estándar, la ausencia de paquetes o repositorios específicos puede impedir obtener un resultado de “aprobado” sin usar repositorios de soporte extendido o paquetes validados.

Lee también:

Fuente: Blog on AlmaLinux

Compartir