diff --git a/i18n/es/_security_assessment/security-assessment/advisories.md b/i18n/es/_security_assessment/security-assessment/advisories.md new file mode 100644 index 0000000..255e012 --- /dev/null +++ b/i18n/es/_security_assessment/security-assessment/advisories.md @@ -0,0 +1,80 @@ +--- +layout: default +title: Avisos de seguridad +nav_order: 5 +translated_from: 6c1cec5253792365347a7303bf545cdb375681fb +--- + +# Avisos de seguridad +{: .no_toc } + +Cada vulnerabilidad publicada, su gravedad y su corrección +{: .fs-6 .fw-300 } + +1. TOC +{:toc} + +--- + +## Avisos publicados + +Leídos de la [pestaña Security del repositorio](https://github.com/ansibleforms/ansibleforms/security/advisories) en cada build de este sitio: + +{% assign af_advisories = site.data.advisories | sort: "published_at" | reverse %} +{% if af_advisories.size > 0 %} + + + + + + + + + + + + + {% for a in af_advisories %} + + + + + + + + + {% endfor %} + +
AvisoGravedadDebilidadAfectadasCorregido enPublicado
+ {{ a.summary | escape }}
+ {{ a.ghsa_id }}{% if a.cve_id %}
{{ a.cve_id }}{% endif %} + 		+ {{ a.severity | capitalize }} + {%- assign af_cvss = a.cvss_severities.cvss_v3 | default: a.cvss -%} + {%- if af_cvss.score %}
CVSS {{ af_cvss.score }}{% endif %} + 		+ {%- for w in a.cwes %}{{ w.cwe_id }}{% unless forloop.last %}
{% endunless %}{% endfor -%} + 		{% for v in a.vulnerabilities %}{{ v.vulnerable_version_range }}{% unless forloop.last %}
{% endunless %}{% endfor %}		{% for v in a.vulnerabilities %}{{ v.patched_versions | default: "-" }}{% unless forloop.last %}
{% endunless %}{% endfor %}		{{ a.published_at | date: "%Y-%m-%d" }}
+{% else %} +No se ha publicado ningún aviso. +{% endif %} + +Cada aviso en GitHub da los detalles: el impacto, las condiciones, el vector CVSS y la corrección. + +--- + +## Qué significa para tu versión + +Un aviso indica las versiones afectadas y la primera versión corregida. La corrección llega a las versiones con soporte, +[7.x y 6.5.x](development.html#supported-versions), y las versiones anteriores no se parchean: la corrección es actualizar. + +Compara la versión de una instancia (**Acerca de** en el menú de ayuda, o `GET /api/v2/version`) con **Afectadas**. + +--- + +## Enterarte de los avisos nuevos + +GitHub notifica a quienes siguen el repositorio cuando se publica un aviso: + +* En [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms), elige **Watch > Custom > Security alerts**. +* El [registro de cambios](../changelog.html) lista cada corrección de seguridad bajo la versión que la incluye. diff --git a/i18n/es/_security_assessment/security-assessment/development.md b/i18n/es/_security_assessment/security-assessment/development.md new file mode 100644 index 0000000..6cb23f2 --- /dev/null +++ b/i18n/es/_security_assessment/security-assessment/development.md @@ -0,0 +1,92 @@ +--- +layout: default +title: Desarrollo seguro +nav_order: 3 +translated_from: b5b66a3ebecfb686b0cf33ed8724fe96622c7d0f +--- + +# Desarrollo seguro +{: .no_toc } + +Cómo se revisan y publican los cambios, y qué tiene soporte +{: .fs-6 .fw-300 } + +1. TOC +{:toc} + +--- + +## El código fuente + +AnsibleForms es código abierto, así que todo lo de esta página puede comprobarse en el propio repositorio: + +* El código, su historial y sus pipelines de build son públicos en [github.com/ansibleforms/ansibleforms](https://github.com/ansibleforms/ansibleforms). +* La [licencia](https://github.com/ansibleforms/ansibleforms/blob/main/LICENSE) es GPL-3.0. +* El [registro de cambios](../changelog.html) lista todos los cambios de cada versión, correcciones de seguridad incluidas. + +--- + +## Cómo se fusiona un cambio + +Todo cambio llega a `main` mediante un pull request, bajo un ruleset que nadie puede saltarse: + +| Regla | Qué significa | +|---|---| +| Pull request obligatorio | No se hace push directo a `main` | +| Comprobaciones obligatorias | El pull request solo se fusiona cuando pasan todas las comprobaciones de abajo | +| Sin force push ni borrado | El historial de `main` no puede reescribirse ni eliminarse | +| Historial lineal | Cada pull request se convierte en un commit, así cada cambio puede rastrearse y revertirse por separado | + +Las comprobaciones que debe pasar un pull request: + +| Comprobación | Qué hace | +|---|---| +| Client, Server | Los tests unitarios de la interfaz web y del servidor | +| CodeQL | El análisis estático de GitHub del código JavaScript y TypeScript, en busca de inyección, cross-site scripting y otras debilidades | +| Public schema is up to date | El esquema de base de datos que espera el código coincide con el que incluye | +| Title, Branch | El pull request sigue las reglas de nombres, así el registro de cambios se mantiene exacto | + +Otras dos se ejecutan en cada pull request e informan sobre él: + +* **Database** prueba el servidor en MySQL y MariaDB, y **Browser** maneja la interfaz en un navegador. +* **Dependency review** bloquea una dependencia nueva con una vulnerabilidad conocida alta o crítica. + +--- + +## Análisis del código y dependencias + +El código y aquello de lo que depende se vuelven a comprobar tras fusionarse: + +* **CodeQL** analiza también cada push a `main` y a las ramas de versión, y todo el código cada semana: + así una regla nueva de CodeQL comprueba también el código fusionado antes de ella. +* **Dependabot** abre un pull request por cada versión nueva de una dependencia: los paquetes npm del servidor y de la + interfaz, los paquetes Python del entorno de ejecución y las GitHub Actions de los pipelines cada semana, y + las imágenes base de los contenedores cada día. +* Las imágenes base se fijan por digest (`node:26-trixie-slim@sha256:...`), así un build usa exactamente la imagen revisada. + Dependabot mueve el digest cuando la imagen se reconstruye en origen. + +--- + +## Versiones e imágenes + +Una versión solo la construye y publica GitHub Actions, nunca la máquina de un desarrollador: + +* Una versión se corta desde `main` (o `release/6.x`), con un registro de cambios generado a partir de sus pull requests. +* Las imágenes las construye el [workflow Publish](https://github.com/ansibleforms/ansibleforms/blob/main/.github/workflows/publish.yml) + y se suben al GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, junto a las imágenes del entorno de + ejecución. El workflow y sus logs son públicos, así que cualquiera puede ver qué entró en una imagen. +* Las imágenes de la aplicación y del entorno de ejecución se ejecutan como el usuario sin privilegios `node` (uid 1000), nunca como root. + +--- + +## Versiones con soporte + +Las correcciones de seguridad van a la versión más reciente de cada línea con soporte: + +| Versión | Recibe correcciones de seguridad | +|---|---| +| 7.x | Sí | +| 6.5.x | Sí | +| Anterior a 6.5 | No: la corrección es actualizar | + +La [guía de actualización](../upgrading/) explica cómo pasar a una versión más reciente, y [Actualizar a la v7](../upgrade-7.html) el paso desde 6.5. diff --git a/i18n/es/_security_assessment/security-assessment/faq.md b/i18n/es/_security_assessment/security-assessment/faq.md new file mode 100644 index 0000000..5604fb9 --- /dev/null +++ b/i18n/es/_security_assessment/security-assessment/faq.md @@ -0,0 +1,86 @@ +--- +layout: default +title: Preguntas de evaluación +nav_order: 6 +translated_from: 731a656c844e6262715e5c8d0a7a291e3b6321f2 +--- + +# Preguntas de evaluación +{: .no_toc } + +Respuestas breves a las preguntas habituales de los cuestionarios +{: .fs-6 .fw-300 } + +1. TOC +{:toc} + +--- + +## Datos y alojamiento + +Dónde están los datos, y quién puede llegar a ellos: + +| Pregunta | Respuesta | +|---|---| +| ¿Dónde se guardan nuestros datos? | En la base de datos MySQL o MariaDB que gestionas tú, y en la carpeta persistente de tu instancia. AnsibleForms es autoalojado, sin ningún servicio en la nube detrás. | +| ¿Envía datos a sus autores? | No. No hay telemetría, ni informes de uso, ni comprobación de actualizaciones. | +| ¿A qué se conecta? | Solo a los sistemas que configura un administrador: consulta [Conexiones salientes](measures.html#outbound-connections). | +| ¿Usa IA o envía datos a un proveedor de modelos? | Solo con el [asistente de chat](../chat/) activado, que está desactivado por defecto. Entonces envía las definiciones de los formularios y los valores que se rellenan al proveedor que configures. | +| ¿Puede funcionar sin acceso a internet? | Sí. La aplicación no necesita acceso a internet; los playbooks necesitan lo que alcancen sus tareas. | + +--- + +## Cifrado + +Qué se cifra, y con qué claves: + +| Pregunta | Respuesta | +|---|---| +| ¿Se cifran los datos en tránsito? | Con [HTTPS](../security/https.html), servido por la aplicación o por tu proxy inverso, y `wss://` entre la aplicación y sus entornos de ejecución. | +| ¿Se cifran los datos en reposo? | Todo secreto guardado lo cifra la aplicación con AES-256. Los trabajos y su salida se guardan tal cual: usa el cifrado en reposo de la propia base de datos. Consulta [Secretos guardados](measures.html#stored-secrets). | +| ¿Quién tiene las claves? | Tú: el [`ENCRYPTION_SECRET`](../security/secrets.html) lo defines tú, queda fuera de las copias de seguridad y puede rotarse. | +| ¿Pueden quedarse los secretos en nuestro almacén? | Sí: [HashiCorp Vault y CyberArk](../secret-stores/) se leen cuando un trabajo los necesita. | + +--- + +## Acceso y responsabilidad + +Quién puede iniciar sesión, qué puede hacer y qué se registra: + +| Pregunta | Respuesta | +|---|---| +| ¿Admite inicio de sesión único? | Sí: LDAP / Active Directory, OpenID Connect y Entra ID. Consulta [Autenticación](../authentication/). | +| ¿Admite autenticación multifactor? | A través del inicio de sesión único: se aplica la MFA de tu proveedor de identidad. Las cuentas locales no tienen MFA propia. | +| ¿Cómo se gestionan los permisos? | Con roles asignados a grupos, que el servidor comprueba en cada petición. Consulta [Permisos](measures.html#permissions). | +| ¿Hay registro de auditoría? | Sí: todo cambio y todo intento denegado, conservado 365 días por defecto y reenviable a syslog. Consulta [Registro de auditoría](measures.html#audit-trail). | +| ¿Hay una contraseña predeterminada? | La primera cuenta admin tiene una contraseña predeterminada pública, que debe cambiarse en el primer inicio de sesión. Consulta [La cuenta admin](../security/hardening.html#the-admin-account). | + +--- + +## Vulnerabilidades y actualizaciones + +Cómo se encuentran, corrigen y anuncian los problemas: + +| Pregunta | Respuesta | +|---|---| +| ¿Se han encontrado vulnerabilidades? | Sí. Todas las publicadas aparecen en [Avisos de seguridad](advisories.html), con la versión que las corrigió. | +| ¿Cómo informamos de una? | En privado, a través de GitHub: consulta [Informar de una vulnerabilidad](reporting.html). | +| ¿Cómo se comprueba el código? | Análisis estático con CodeQL y revisión de dependencias en cada pull request, tests automáticos y actualizaciones de Dependabot. Consulta [Desarrollo seguro](development.html). | +| ¿Qué versiones reciben correcciones de seguridad? | 7.x y 6.5.x. Consulta [Versiones con soporte](development.html#supported-versions). | +| ¿Cómo nos enteramos de un aviso nuevo? | Sigue las alertas de seguridad del repositorio en GitHub. Consulta [Enterarte de los avisos nuevos](advisories.html#being-told-of-new-advisories). | +| ¿Se ha hecho una prueba de penetración? | No se publica ningún informe de prueba de penetración de terceros. El código es público, así que tu propio equipo o auditor puede evaluarlo, y los hallazgos se notifican como se indica arriba. | + +--- + +## Imágenes y cadena de suministro + +De dónde vienen las imágenes, y cómo comprobarlas: + +| Pregunta | Respuesta | +|---|---| +| ¿Dónde se publican las imágenes? | En el GitHub Container Registry, `ghcr.io/ansibleforms/ansibleforms`, construidas por workflows públicos de GitHub Actions. Consulta [Versiones e imágenes](development.html#releases-and-images). | +| ¿Los contenedores se ejecutan como root? | No: como el usuario sin privilegios `node`. | +| ¿Están firmadas las imágenes? | Todavía no. Descárgalas por digest (`@sha256:...`) para asegurarte de ejecutar la imagen que revisaste. | +| ¿Hay un SBOM? | Todavía no se publica ninguno con las imágenes. Un escáner como Trivy o Syft lo genera a partir de la imagen. | +| ¿Se escanean las imágenes en busca de vulnerabilidades? | No en el pipeline de publicación. Sus imágenes base se fijan por digest y Dependabot las mantiene al día; escanea las imágenes en tu propio registry para aplicar tu propia política. | +| ¿Bajo qué licencia está? | GPL-3.0, código abierto, sin garantía. | diff --git a/i18n/es/_security_assessment/security-assessment/index.md b/i18n/es/_security_assessment/security-assessment/index.md new file mode 100644 index 0000000..ea3407b --- /dev/null +++ b/i18n/es/_security_assessment/security-assessment/index.md @@ -0,0 +1,40 @@ +--- +layout: default +title: Resumen +nav_order: 1 +permalink: /security-assessment/ +translated_from: 4357493c88da7b9bbd30f0a5ea185be3e6438abd +--- + +# Evaluación de seguridad +{: .no_toc } + +Para revisiones de seguridad: medidas, desarrollo y avisos +{: .fs-6 .fw-300 } + +--- + +## En resumen + +AnsibleForms ejecuta playbooks y guarda sus credenciales, así que forma parte de tu cadena de confianza: + +* Es **autoalojado**: se ejecuta en tu infraestructura, guarda sus datos en tu base de datos y no envía nada a sus autores. +* Es **código abierto** (GPL-3.0): el código, sus pipelines y todos los avisos son públicos. +* Todo secreto guardado está **cifrado**, todo cambio **auditado**, y los **roles** se comprueban en cada petición. +* Las vulnerabilidades se **notifican en privado**, se corrigen en cada versión con soporte y se **publican**. + +--- + +## En esta sección + +Las páginas responden a las preguntas de una revisión de seguridad, desde el diseño hasta la lista de CVE: + +| Página | Qué cubre | +|---|---| +| [Medidas de seguridad](measures.html) | Inicio de sesión, permisos, secretos guardados, la auditoría, el navegador, el servidor, las conexiones y los contenedores | +| [Desarrollo seguro](development.html) | Cómo se revisa y prueba un cambio, el análisis del código y las dependencias, cómo se construyen las imágenes, las versiones con soporte | +| [Informar de una vulnerabilidad](reporting.html) | Cómo informar de un problema en privado, y qué ocurre después | +| [Avisos de seguridad](advisories.html) | Cada vulnerabilidad publicada, con su CVE, su gravedad y la versión que la corrige | +| [Preguntas de evaluación](faq.html) | Respuestas breves a las preguntas más habituales de los cuestionarios de seguridad | + +Para proteger una instancia en lugar de evaluarla, consulta [Seguridad](../security/) en la guía del administrador. diff --git a/i18n/es/_security_assessment/security-assessment/measures.md b/i18n/es/_security_assessment/security-assessment/measures.md new file mode 100644 index 0000000..5b54dbb --- /dev/null +++ b/i18n/es/_security_assessment/security-assessment/measures.md @@ -0,0 +1,157 @@ +--- +layout: default +title: Medidas de seguridad +nav_order: 2 +translated_from: 1ceeb1a74d9235a43a8600d8bf7e0a39015a124a +--- + +# Medidas de seguridad +{: .no_toc } + +Cómo se protegen el inicio de sesión, los permisos y los secretos +{: .fs-6 .fw-300 } + +1. TOC +{:toc} + +--- + +## Dónde se ejecuta + +AnsibleForms es autoalojado, en tu infraestructura, con sus datos en una base de datos que gestionas tú. + +* No hay ningún servicio en la nube de AnsibleForms ni servidor de licencias, ni telemetría ni comprobación de actualizaciones. +* La interfaz la sirve la propia aplicación y no carga nada de otro sitio. +* La aplicación solo se conecta a los sistemas que configura un administrador, listados en [Conexiones salientes](#outbound-connections). + +Las partes y lo que guarda cada una: + +| Parte | Qué hace | Qué guarda | +|---|---|---| +| Aplicación | La interfaz web, la API REST, el planificador | Ningún dato propio: todo está en la base de datos | +| MySQL o MariaDB | La base de datos de la aplicación | Usuarios, grupos, credenciales (cifradas), trabajos con sus extravars y su salida, el registro de auditoría | +| Entorno de ejecución (RTE) | Ejecuta los playbooks, en su propio contenedor | Los archivos de los trabajos que ejecuta, y los secretos de un trabajo solo mientras se ejecuta | +| Carpeta persistente | La configuración, los formularios, los playbooks y los archivos subidos | Los archivos que usan los formularios y los playbooks | + +Consulta [Cómo funciona](../how-it-works.html) para ver el conjunto, y [RTE](../rte/) para el entorno de ejecución. + +--- + +## Inicio de sesión + +Toda página y llamada a la API que lee o cambia datos necesita un usuario con sesión iniciada. Los pocos endpoints abiertos sin ella sirven el +propio inicio de sesión, la versión, el nombre y el logo de la instancia, la documentación de la API y la configuración de la base de datos del +primer arranque, que [`ALLOW_SCHEMA_CREATION`](../security/hardening.html#the-database)`=0` cierra: + +| Método | Cómo funciona | +|---|---| +| Cuentas locales | Contraseñas con hash bcrypt, una [longitud mínima](../security/hardening.html#sign-in-limits-and-passwords), y la contraseña de admin predeterminada pública debe cambiarse en el primer inicio de sesión | +| LDAP / Active Directory | El directorio comprueba la contraseña, y sus grupos se asignan a roles. Consulta [LDAP](../authentication/ldap.html) | +| OpenID Connect, Entra ID | Inicio de sesión único a través de tu proveedor de identidad, que además aporta su propia autenticación multifactor. Consulta [Autenticación](../authentication/) | + +* Los inicios de sesión fallidos [bloquean la cuenta](../security/hardening.html#sign-in-limits-and-passwords), y el inicio de sesión tiene límite de peticiones. +* Un inicio de sesión devuelve un token de acceso firmado válido 30 minutos y un token de renovación válido 24 horas. +* Los tokens pueden terminarse antes de caducar: cerrar sesión, cambiar la contraseña, bloquear al usuario o revocar un token de API los termina + en todos los nodos a la vez, consulta [Tokens](../security/secrets.html#tokens). +* AnsibleForms no tiene autenticación multifactor propia: usa el inicio de sesión único donde se exija. + +--- + +## Permisos + +Lo que puede hacer un usuario viene de los roles de sus grupos, y el servidor lo comprueba en cada petición: + +* Los roles se definen en [config.yaml](../config/roles.html): qué formularios ve un usuario y qué opciones tiene, + como el diseñador, las páginas de ajustes o los trabajos de otros usuarios. +* El servidor comprueba cada lanzamiento contra las reglas del formulario (sus campos, sus valores y el acceso del usuario), + incluidos los lanzamientos por la API REST, consulta [Validación del lanzamiento](../launch-validation/). +* El rol admin ejecuta cualquier playbook por diseño. Los demás roles solo obtienen lo concedido: un usuario con varios roles + tiene una opción solo si ninguno de esos roles la deniega, así que basta un rol restrictivo para retirarla. + +--- + +## Secretos guardados + +Las contraseñas, los tokens y las claves se cifran antes de escribirse en la base de datos: + +* Todo secreto guardado (credenciales, la contraseña de enlace LDAP, los tokens de runner, los secretos de cliente del inicio de sesión + único, las direcciones de webhook y las claves de API) se cifra con AES-256 y un vector de inicialización aleatorio por valor, con el + [`ENCRYPTION_SECRET`](../security/secrets.html#the-two-master-secrets) que defines tú. +* Ninguna llamada a la API ni página de ajustes muestra un secreto guardado, y las copias de seguridad omiten los secretos maestros. +* Los secretos pueden quedarse en tu almacén: [HashiCorp Vault y CyberArk](../secret-stores/) se leen cuando un trabajo los necesita. +* Los secretos de un trabajo llegan al entorno de ejecución sellados con AES-256-GCM, con una clave derivada de su token. +* Las extravars con nombre de secreto se enmascaran en la vista del trabajo, y los campos de contraseña siempre, consulta [Datos de los trabajos](../security/hardening.html#job-data). + +El resto de la base de datos (los trabajos, sus extravars y su salida) se guarda tal cual: protégelo con el cifrado en reposo y el +control de acceso de la propia base de datos, consulta [La base de datos](../security/hardening.html#the-database). + +--- + +## Registro de auditoría + +Se registra todo cambio, y todo intento denegado: + +* Cada creación, cambio y borrado, por la interfaz o por la API, se escribe en el registro de auditoría con el usuario, su + dirección, la acción, el objeto y el resultado. También se registran las denegaciones y los inicios de sesión, incluidos los fallidos. +* Los valores que parecen secretos se ocultan antes de escribirse. +* El registro se conserva 365 días por defecto, y puede copiarse a syslog por UDP, TCP o TLS. + +--- + +## En el navegador + +La interfaz está protegida contra código inyectado en una página: + +* Una [Content-Security-Policy](../security/hardening.html#the-content-security-policy) solo permite los scripts y marcos de la propia aplicación. +* Toda respuesta lleva cabeceras de protección: nosniff, protección de marcos y HSTS sobre HTTPS. +* El HTML de los formularios, los textos de ayuda y las respuestas del chat se sanea, y la salida de los trabajos se escapa. + +--- + +## En el servidor + +El código que trata la entrada del usuario evita las inyecciones clásicas: + +* Las consultas a la base de datos pasan sus valores como parámetros, nunca como texto pegado a la consulta. +* Los comandos, git incluido, se ejecutan desde una lista de argumentos, nunca un shell, así que los caracteres del shell no hacen nada. +* Las expresiones de servidor pasan un [sanitizador de expresiones](../security/hardening.html#expressions-and-outbound-calls), y sus llamadas REST un filtro de hosts. +* El [servidor MCP](../mcp/), el [asistente de chat](../chat/) y el endpoint de métricas están desactivados hasta que los activas. + +--- + +## Conexiones + +El tráfico desde y hacia AnsibleForms puede cifrarse de extremo a extremo: + +* La aplicación sirve [HTTPS](../security/https.html) ella misma, o se sitúa tras tu proxy inverso. +* Un entorno de ejecución habla con la aplicación por un WebSocket, `wss://` con una dirección HTTPS, y la aplicación + fija el certificado de uno entrante, consulta [Modos de RTE](../rte/modes.html). +* LDAP, el inicio de sesión único, los runners, git, los almacenes de secretos y las llamadas REST de las expresiones comprueban el + certificado del servidor al que llegan, salvo que un administrador desactive la comprobación para un servidor con certificado autofirmado. + +### Conexiones salientes + +AnsibleForms solo se conecta a lo que configura un administrador: + +| Conexión | Cuándo | +|---|---| +| LDAP, OpenID Connect, Entra ID (inicio de sesión de Microsoft y Graph) | Cuando se configura ese método de inicio de sesión | +| AWX / AAP / Ascender, Semaphore, Rundeck, Jenkins | Cuando un formulario se ejecuta en ese runner | +| Servidores git | Cuando se configura un repositorio | +| Servidor de correo, Slack, Teams, Telegram, webhooks | Cuando se configura un canal de notificación | +| HashiCorp Vault, CyberArk | Cuando se configura un almacén de secretos | +| Un proveedor de modelos (Anthropic, OpenAI y otros) | Solo con el [asistente de chat](../chat/) activado, que está desactivado por defecto | +| Hosts y APIs nombrados en los formularios | Cuando las expresiones de un formulario o un playbook los llaman | +| Servidores syslog | Cuando se configura el reenvío de la auditoría o de los logs | + +--- + +## Los contenedores + +Las imágenes se construyen para ejecutarse con el menor privilegio posible: + +* La aplicación y el entorno de ejecución se ejecutan como el usuario sin privilegios `node`, no como root. +* Se basan en imágenes Debian slim fijadas por digest, consulta [Desarrollo seguro](development.html#code-analysis-and-dependencies). +* La aplicación escucha en un solo puerto, el 8000. + +Para los pasos que protegen una instancia nueva, sigue [Bastionado](../security/hardening.html). diff --git a/i18n/es/_security_assessment/security-assessment/reporting.md b/i18n/es/_security_assessment/security-assessment/reporting.md new file mode 100644 index 0000000..a461283 --- /dev/null +++ b/i18n/es/_security_assessment/security-assessment/reporting.md @@ -0,0 +1,66 @@ +--- +layout: default +title: Informar de una vulnerabilidad +nav_order: 4 +translated_from: 382775f2312f05fd6dcd85154cb81c2709000d69 +--- + +# Informar de una vulnerabilidad +{: .no_toc } + +Informar en privado de un problema de seguridad, y qué sigue +{: .fs-6 .fw-300 } + +1. TOC +{:toc} + +--- + +## Infórmalo en privado + +AnsibleForms guarda credenciales y tokens de vault, así que nunca informes de un problema de seguridad en una issue pública: + +1. Abre **[Report a vulnerability](https://github.com/ansibleforms/ansibleforms/security/advisories/new)**: un aviso privado que solo ven los mantenedores. +2. Si esa página no está disponible para ti, abre una issue normal que diga solo que tienes un informe de seguridad y pida + un canal privado: sin detalles, sin reproductor, sin números de versión. Un mantenedor abre un aviso privado y + te invita a él. + +La política completa es el [SECURITY.md](https://github.com/ansibleforms/ansibleforms/blob/main/SECURITY.md) del repositorio. + +--- + +## Qué incluir + +Cuanto más de esto aporte un informe, antes se corrige: + +* Qué gana un atacante: datos de otro usuario, un playbook que no puede ejecutar, el host o derechos de admin. +* La versión, y cómo está desplegada: Docker, Kubernetes o instalada de forma nativa. +* Un reproductor, o la petición que lo provoca. +* Si necesita un usuario con sesión iniciada, y con qué [opciones de rol](../config/roles.html). + +--- + +## Qué ocurre después + +Un informe pasa por el mismo aviso privado desde el primer mensaje hasta la publicación: + +| Paso | Qué recibes | +|---|---| +| Acuse de recibo | Confirmación de que el informe ha llegado, y de si se reproduce | +| Aceptado | Una corrección en la próxima versión de cada [versión con soporte](development.html#supported-versions), y un aviso publicado que te da el crédito, salvo que prefieras no aparecer | +| Rechazado | El razonamiento, normalmente que el comportamiento necesita un permiso que quien informa ya tenía | + +Cuando se publica la corrección, el aviso se publica y aparece en [Avisos de seguridad](advisories.html). + +--- + +## Alcance + +La política traza la línea donde la traza el modelo de roles: + +| Dentro del alcance | Fuera del alcance | +|---|---| +| Todo lo que un usuario con sesión iniciada puede alcanzar más allá de lo que concede su rol | Hallazgos que requieren que la cuenta admin ya esté comprometida: un admin que ejecuta cualquier playbook es el producto | +| Todo lo alcanzable sin iniciar sesión | Informes de escáneres sin impacto demostrado | +| Credenciales guardadas que pasan a ser legibles, o se escriben en un log | | +| Inyección en el shell, la base de datos o el navegador | |