Auditoría Atlassian — NovaMed SaaS

100

Risk Score

Estado Actual: CRÍTICO

La instancia de Jira/Confluence de NovaMed presenta vulnerabilidades de alto impacto. Se detectaron 3 hallazgos críticos, incluyendo permisos de borrado sin restricción sobre datos clínicos sensibles y un usuario ex-empleado con acceso activo de administrador en todos los proyectos.

✕ Calificación: POOR 3 Críticos 11 Altos 12 Medios 3 Info

Críticos

Altos

Medios

Total Hallazgos

📊 Puntuación por Proyecto

4 proyectos

HCE Historia Clínica Electrónica

Crítico

Alto

Medio

Info

⚠ Contiene datos clínicos sensibles — PRIORIDAD MÁXIMA

BILL Facturación & Cobros

Crítico

Alto

Medio

Info

⚠ Ex-empleado con 3 permisos directos activos

INFRA Infraestructura & DevOps

Crítico

Alto

Medio

Info

⚠ sre-team tiene system_admin + administer_jira

MKTG Marketing & Growth

Crítico

Alto

Medio

Info

✓ Menor superficie de riesgo — tratar después

🔍 Hallazgos Críticos y Altos

14 hallazgos

#	Severidad	Regla	Esquema / Alcance	Descripción
01	CRÍTICO	admin_access_warning	HCE	Grupo jira-admins tiene acceso `system_admin` y `administer_jira` activo sobre datos clínicos.
02	CRÍTICO	admin_access_warning	INFRA	Grupo sre-team tiene system/Jira admin + 7 permisos sensibles. Membresía sin auditoría reciente.
03	CRÍTICO	unrestricted_delete	HCE	Permiso `delete_issues` concedido al grupo jira-users (todos los usuarios). Riesgo de borrado masivo de historias clínicas.
04	ALTO	direct_user_permission	HCE BILL INFRA	Usuario jmolina@novamed.io (ex-CTO, cuenta activa) con `administer_project`, `administer_jira`, `delete_issues` en 3 proyectos.
05	ALTO	over_permissioned_group	HCE	Grupo jira-admins acumula 6 permisos sensibles: administer_jira, administer_project, delete_all_attachments, delete_all_comments, delete_issues, system_admin.
06	ALTO	over_permissioned_group	INFRA	Grupo sre-team acumula 7 permisos sensibles incluyendo bulk_change, manage_group_filter_subscriptions.
07	ALTO	over_permissioned_group	BILL	Grupo finance-admins tiene modify_reporter en proyecto de facturación — riesgo de manipulación de registros.
08	ALTO	too_many_direct_users	HCE	6 usuarios con permisos directos (alopez, cmartin, psanz, rgarcia, mfernandez, jmolina). Dificulta offboarding y auditorías.
09	ALTO	dev_team_bulk_change	HCE	Grupo dev-team tiene bulk_change — permite modificaciones masivas sin aprobación sobre datos sensibles.

🚨 Checklist Urgente: Deprovisioning ex-CTO

jmolina@novamed.io

Ex-CTO · Cuenta activa · Último acceso desconocido

Riesgo CRÍTICO

Auditar issues asignados a jmolina en los 4 proyectos GET /rest/api/3/search?jql=assignee=jmolina@novamed.io AND project in (HCE,BILL,INFRA,MKTG)

Reasignar issues abiertos al nuevo CTO o leads de proyecto Jira → Issues → Bulk change → Reassign assignee

Auditar espacios Confluence de su propiedad GET /wiki/rest/api/user/{accountId}/property · Reasignar space admin

Revocar permisos directos en HCE, BILL e INFRA (3 proyectos) Jira Settings → Projects → [HCE|BILL|INFRA] → People → Remove jmolina

Eliminar de todos los grupos: jira-admins, sre-team, dev-team admin.atlassian.com → User management → jmolina → Groups → Remove all

Revocar acceso a productos (Jira Software, Confluence, Bitbucket) admin.atlassian.com → Products → [product] → Access → Remove user

Desactivar cuenta de Atlassian DELETE /rest/api/3/user?accountId={accountId} · Verificar: "active": false

Revocar tokens API activos admin.atlassian.com → Security → API token controls → Revoke for jmolina

Invalidar sesiones OAuth en integraciones (GitHub, Slack, Salesforce) Revocar OAuth grants asociados a su cuenta en cada integración

Documentar deprovisioning en Confluence (sección Audit Log) Registrar: fecha, responsable, acciones tomadas, verificación final

🛠 Plan de Remediación Priorizado

1

Deprovisioning urgente de jmolina@novamed.io
Desactivar cuenta del ex-CTO antes de fin de jornada. Reasignar contenido, revocar accesos directos en HCE, BILL e INFRA y eliminar de todos los grupos admin.

P1 · Hoy
2

Eliminar delete_issues de jira-users en HCE
Restringir permisos de borrado exclusivamente al grupo project-leads. Los datos de historias clínicas no deben ser borrables por todos los usuarios bajo ningún concepto.

P1 · Hoy
3

Auditar membresía de jira-admins y sre-team
Limitar a 2–3 personas por grupo. Documentar quién pertenece y por qué. Requerir MFA para todos los miembros: admin.atlassian.com → Security → Authentication policies → Require 2FA.

P1 · 48h
4

Activar SCIM con Okta para provisioning automático
admin.atlassian.com → User provisioning → Okta → Enable SCIM. Esto garantiza que futuras bajas se propagan automáticamente, eliminando el riesgo de cuentas zombi como jmolina.

P2 · 1 semana
5

Migrar 6 permisos directos en HCE a grupos funcionales
Crear grupos hce-developers, hce-viewers y hce-contractors. Añadir usuarios y revocar permisos individuales. Aplicar igual en BILL (3 usuarios directos).

P2 · 1 semana
6

Estandarizar esquemas de permisos
Los 4 esquemas difieren en 8–10 permisos entre sí. Crear una plantilla base (basada en permission_scheme_template.json), documentar desviaciones intencionales en Confluence.

P3 · 2 semanas
7

Establecer ciclo trimestral de access review
Exportar usuarios: GET /admin/v1/orgs/{orgId}/users · Revisar roles · Eliminar inactivos · Documentar en Confluence. Programar como tarea recurrente en Jira (componente: Governance).

P3 · 1 mes

🔐 Recomendaciones SSO/SCIM y Gobernanza

SCIM no configurado — Riesgo Inmediato

Sin SCIM activo, las bajas de empleados requieren deprovisioning manual. El caso de jmolina@novamed.io es evidencia directa de este riesgo. Activar: admin.atlassian.com → Security → User provisioning → Okta → Enable SCIM. Mapear grupos de Okta a grupos Atlassian (ej. okta:engineering → jira:dev-team).

SSO activo pero sin política de enforcement

Okta SSO está configurado pero no enforced — los usuarios pueden seguir usando contraseña. Activar: admin.atlassian.com → Security → Authentication policies → Enforce SSO. Confirmar que todos los admins tienen MFA antes de hacer el enforcement.

Política de API tokens recomendada

Activar controles de API token: Security → API token controls → Restrict token creation. Establecer expiración máxima de 90 días. Auditar tokens activos mensualmente vía GET /admin/v1/orgs/{orgId}/directory/users/{userId}/api-tokens.

Data Residency — Cumplimiento GDPR

Con datos clínicos (Historia Clínica Electrónica), verificar data residency EU: admin.atlassian.com → Data residency → Pin products → European Union. Revisar audit log export para SOC 2 — retención mínima recomendada: 7 años.

Auditoría de Permisos Atlassian

Estado Actual: CRÍTICO

SCIM no configurado — Riesgo Inmediato

SSO activo pero sin política de enforcement

Política de API tokens recomendada

Data Residency — Cumplimiento GDPR