¿Puede esta aplicación autoalojada respaldar su proceso de aprobación? Un marco práctico de evaluación

Por qué una función de aprobación no equivale a un proceso de aprobación controlado

Muchas aplicaciones pueden marcar un elemento como aprobado, restringir un cambio de estado o notificar a un colega para que lo revise. Esto puede ser útil, pero no proporciona automáticamente un proceso controlado para una compra, un gasto, una solicitud de acceso, un cambio en datos de clientes o una decisión de publicación.

Un proceso de aprobación controlado necesita más que una acción en pantalla. Necesita una decisión definida, responsables de decisión elegibles, reglas que indiquen cuándo aplica su autoridad, un registro de lo que decidieron y salvaguardas para evitar que las personas cambien o eludan el proceso posteriormente. La pregunta correcta no es «¿Esta aplicación tiene aprobaciones?», sino «¿Podemos configurar y operar esta aplicación de modo que nuestras decisiones requeridas se tomen, se apliquen y queden respaldadas por evidencia?».

NIST SP 800-53 considera que los controles son flexibles y personalizables dentro de un proceso de gestión de riesgos que abarca toda la organización. Aplique el mismo principio aquí: traduzca sus propios requisitos de negocio, políticas y riesgos en pruebas observables. Una etiqueta de función genérica no sustituye ese trabajo.

• Considere una función como un punto de partida, no como prueba de control.
• Diferencie las revisiones por conveniencia de las decisiones que generan compromisos financieros, legales, de seguridad o con impacto en clientes.
• Documente qué requisitos son obligatorios, cuáles son deseables y cuáles deben gestionarse fuera de la aplicación.

Comience por la decisión del mundo real

Comience por el evento de negocio, no por la configuración del software. Describa un tipo de aprobación a la vez. «Compras» suele ser demasiado amplio: aprobar la renovación recurrente de un proveedor de bajo valor puede implicar evidencia, autoridad y riesgo distintos de los necesarios para aprobar un nuevo compromiso de alto valor con un proveedor.

Para cada decisión, identifique al solicitante, el registro sobre el que se decide, la evidencia requerida, los posibles resultados y la acción que puede producirse únicamente después de la aprobación. Identifique también la consecuencia de una aprobación incorrecta. Esto determina cuánto control, visibilidad y revisión necesita el flujo de trabajo.

• ¿Qué se está aprobando: una solicitud, un documento, un cambio de registro, un pago, una publicación, un permiso de acceso o una acción sobre datos de clientes?
• ¿Quién puede solicitarlo y qué campos o adjuntos deben estar completos antes del envío?
• ¿Quién puede aprobar, rechazar, devolver para cambios o cancelar?
• ¿Qué umbrales, categorías de riesgo, departamentos, ubicaciones o clasificaciones de datos modifican la ruta?
• ¿Qué acción pasa a estar permitida tras la aprobación y quién la realiza?
• ¿Durante cuánto tiempo deben conservarse el registro de decisión y la evidencia de respaldo?

Trace el flujo de trabajo mínimo antes de evaluar el software

Redacte el flujo de trabajo completo más pequeño en lenguaje claro y, a continuación, haga que cada paso sea comprobable en la aplicación. Una referencia útil es: solicitud, revisión, decisión, notificación, ejecución y conservación de registros. Si una herramienta propuesta no puede representar un paso requerido o conservar la información necesaria, identifique explícitamente el control compensatorio en lugar de asumir que los usuarios lo recordarán.

Mantenga la decisión de aprobación diferenciada de la ejecución posterior. Por ejemplo, un aprobador puede autorizar una compra, mientras que otra persona crea el pedido. Esta distinción es importante para la responsabilidad y la separación de funciones.

• Solicitud: crear un elemento con identificador único y recopilar los datos y la evidencia requeridos.
• Revisión: poner el elemento a disposición del revisor o revisores correctos.
• Decisión: registrar la aprobación, el rechazo o la devolución para retrabajo con la identidad responsable.
• Notificación: informar al solicitante y a la siguiente parte responsable de lo ocurrido.
• Ejecución: permitir o activar la acción posterior autorizada solo cuando se cumplan las condiciones.
• Conservación: preservar el registro de decisión, los adjuntos y el historial durante el período requerido.

Evalúe estados y transiciones, incluidos los cambios posteriores a la aprobación

Un flujo de trabajo se define por sus estados y las transiciones permitidas entre ellos. Como mínimo, pruebe borradores, elementos enviados, elementos aprobados y elementos rechazados. En muchos procesos, también necesita estados de devuelto para cambios, cancelado, vencido, sustituido o ejecutado.

La prueba más reveladora es un cambio sustancial después de la aprobación. Si cambian el importe, el proveedor, el alcance, el adjunto, el nivel de acceso o la finalidad de los datos de clientes, ¿la aplicación bloquea el registro, invalida la aprobación, crea una nueva revisión o simplemente conserva una aprobación anterior junto a contenido modificado? Su proceso debe indicar qué cambios requieren una nueva aprobación, y la aplicación debe dejar claro ese resultado.

Pruebe también quién puede mover cada estado. Un solicitante puede poder editar un borrador, pero no necesariamente debería poder marcarlo como enviado, aprobado o ejecutado sin las condiciones requeridas.

• ¿Pueden los usuarios ver el estado actual y el historial completo de estados anteriores?
• ¿Las transiciones están restringidas por función, asignación o condiciones del flujo de trabajo?
• ¿Los elementos rechazados se cierran, pueden editarse para reenviarse o se devuelven para corrección?
• ¿Un cambio posterior a la aprobación activa una nueva aprobación cuando la política lo requiere?
• ¿Puede cancelarse un elemento aprobado y se conservan el motivo de cancelación y la identidad?
• ¿Pueden los usuarios distinguir un registro aprobado de uno pendiente, revisado o sustituido?

Pruebe las reglas de autoridad, no solo la asignación de aprobadores

Un aprobador designado es fácil de entender, pero puede ser frágil. Una evaluación sólida comprueba si la aplicación puede reflejar el modelo de autoridad que realmente utiliza: revisores basados en roles, umbrales, rutas condicionales y más de una etapa de aprobación. No dé por hecho que un gerente asignado es siempre la persona autorizada para cada decisión.

Utilice casos representativos. Pruebe una solicitud rutinaria, una solicitud justo por debajo y otra justo por encima de un umbral monetario, una solicitud de alto riesgo, una solicitud que abarca dos departamentos y una solicitud que requiere revisión legal, de seguridad o financiera. Registre si el enrutamiento es automático, si puede modificarse y qué pueden ver los usuarios cuando no son el revisor actual.

• Autoridad nominativa: ¿puede aprobar una persona responsable concreta?
• Autoridad basada en roles: ¿puede aprobar quien actualmente ocupa un rol empresarial autorizado?
• Autoridad por umbral: ¿cambia la ruta en el importe o nivel de riesgo requerido?
• Autoridad de varios pasos: ¿pueden actuar los revisores requeridos en el orden correcto?
• Autoridad paralela: cuando se requieren varias revisiones, ¿deben aprobar todas o basta una?
• Autoridad condicional: ¿pueden variar los revisores requeridos según departamento, tipo de datos, país, proyecto o categoría de solicitud?

Compruebe la segregación de funciones y el acceso privilegiado

La separación de funciones implica más que asignar etiquetas diferentes a las personas. El control AC-5 de NIST exige una separación de funciones definida, una separación documentada y autorizaciones de acceso que la respalden. Convierta este principio en pruebas directas: ¿puede un solicitante aprobar su propia solicitud, modificar un registro aprobado, elegir un aprobador no elegible o eludir a un revisor requerido?

Evalúe por separado los roles ordinarios de la aplicación y el acceso operativo. En una implementación autoalojada, las personas con amplio acceso a la implementación o al host pueden alterar el funcionamiento, los datos o la configuración de la aplicación fuera del flujo de negocio. Docker documenta que su modelo de autorización estándar es de todo o nada para los usuarios a quienes se permite acceder al daemon de Docker: esos usuarios pueden ejecutar comandos del cliente Docker. Incluya este acceso en su modelo de amenazas y en el diseño de gobernanza.

Los complementos de autorización de Docker pueden tomar decisiones de permitir o denegar basadas en la autenticación y el contexto del comando, pero Docker también documenta límites en su ámbito de aplicación. Si pretende basarse en tales controles, pruebe su alcance frente a las acciones administrativas relevantes para su proceso. No deduzca que las restricciones del flujo de trabajo en el nivel de la aplicación limiten por sí solas a los administradores de infraestructura.

• Utilice cuentas de prueba separadas para solicitante, aprobador, ejecutor, administrador de aplicaciones y administrador de infraestructura.
• Intente la autoaprobación, la aprobación por un rol no autorizado y la aprobación después de una reasignación.
• Intente editar campos clave y adjuntos después de la aprobación.
• Identifique quién puede modificar las reglas del flujo de trabajo, los roles, la configuración de auditoría, los almacenes de datos, los contenedores y las copias de seguridad.
• Defina quién revisa el acceso privilegiado y con qué frecuencia.
• Asegúrese de que el proceso reconozca el riesgo residual cuando un equipo técnico pequeño necesariamente dispone de un amplio acceso operativo.

Evalúe la delegación, las ausencias y el trabajo vencido sin perder la responsabilidad

Los flujos de aprobación a menudo fallan en circunstancias normales: un aprobador está de baja, ha cambiado de rol o simplemente no actúa. Un proceso viable necesita una ruta deliberada para la delegación, la reasignación y la escalada. El objetivo es mantener la continuidad sin ocultar quién tenía autoridad y quién tomó la decisión final.

Pruebe si la aplicación registra al asignado original, la persona o regla que reasignó el trabajo, la decisión del delegado y el momento de cada evento. Si la delegación se gestiona fuera de la aplicación, decida cómo se documentará esa instrucción y cómo se verificará la autoridad del nuevo aprobador.

• ¿Puede un aprobador delegar solo dentro de un rol o nivel de autoridad permitido?
• ¿El sistema conserva al asignado original y el historial de delegación?
• ¿Puede el propietario del proceso reasignar un elemento vencido y queda registrado el motivo?
• ¿Los recordatorios y las escaladas son suficientemente configurables para el tiempo de respuesta requerido?
• ¿Qué ocurre si se deshabilita o elimina la cuenta de un aprobador mientras hay trabajo pendiente?
• ¿Existe una vía de emergencia documentada, con revisión posterior, para decisiones que no pueden esperar?

Evalúe la evidencia de aprobación y los registros de auditoría

El registro de decisión debe responder preguntas básicas sin depender de la memoria de alguien: qué ocurrió, cuándo y dónde ocurrió, qué o quién lo causó, cuál fue el resultado y qué identidades estuvieron asociadas. Estos elementos se alinean con los elementos de registros de auditoría del control AU-3 de NIST.

Para cada decisión, inspeccione el resultado realmente conservado en lugar de basarse en un panel. Determine si incluye la versión de la solicitud, la decisión, la fecha y hora, la identidad del aprobador, los comentarios, la evidencia adjunta, las asignaciones y todos los cambios significativos. Después, pruebe si un usuario puede exportar o recuperar la evidencia en una forma que siga siendo comprensible fuera de la aplicación.

La evidencia solo es útil si sigue siendo confiable. NIST AU-9 aborda la protección de la información de auditoría y la restricción de la gestión de las funciones de registro a un subconjunto adecuado de usuarios privilegiados. Pregunte quién puede modificar, eliminar, deshabilitar o sustituir los registros y logs de aprobación, y cómo se detectan o revisan esas acciones.

• Identificador de solicitud y versión o revisión aprobada.
• Tipo de evento, hora, origen o ubicación relevante, resultado e identidades asociadas.
• Comentarios de decisión, motivos de rechazo y adjuntos vinculados cuando sean necesarios.
• Un historial completo de asignaciones, delegaciones y cambios de estado.
• Procedimientos de conservación, exportación y recuperación que hayan sido probados.
• Controles de acceso sobre registros de aprobación y registro de auditoría, incluida la gobernanza de usuarios privilegiados.