Controles tecnológicos y continuidad de servicios
Dependencias que permiten confiar en la operación digital y recuperar el servicio.
1. Información, aplicación e infraestructura
Un control automatizado funciona sobre reglas, datos y condiciones técnicas. Distingue controles de aplicación —validación de campos, duplicados o cálculos— de las condiciones generales sobre accesos, cambios y operación. Si una persona puede alterar reglas o datos sin trazabilidad, una validación correcta en pruebas no asegura el mismo comportamiento durante el periodo.
El análisis comienza por el servicio: qué actividades dependen del sistema, qué información utilizan, qué interfaces intervienen y quién decide. Evita clasificar cualquier problema como «de informática». La autorización del monto de una beca puede corresponder al proceso gestor, aunque su regla esté implementada en software.
2. Accesos y funciones incompatibles
Define altas, cambios y bajas de usuarios por responsabilidad; revisa privilegios, cuentas compartidas y accesos de proveedores. El acceso autorizado al iniciar un empleo puede dejar de ser adecuado al cambiar de puesto. La revisión debe contrastar permisos reales con funciones y conservar el tratamiento de diferencias.
Una combinación crítica permite crear beneficiarios, cambiar cuentas y liberar pagos. El sistema puede separar pantallas y aun así permitir a la misma persona completar las tres funciones mediante varias cuentas. La comprobación necesita identificar personas y privilegios efectivos, además del rol nominal.
3. Cambios y pruebas
Conserva solicitud, autorización, pruebas, versión, paso a producción y posibilidad de recuperación. Examina cambios urgentes y posteriores regularizaciones. La separación entre desarrollo y producción ayuda a limitar modificaciones no autorizadas; una excepción requiere justificación y medidas de contraste, no una cuenta privilegiada permanente sin revisión.
Prueba entradas correctas e incorrectas, extremos, duplicación, reenvíos, fallas de interfaz y excepciones autorizadas. Conserva resultado esperado y observado. Si se modifica la regla después de la prueba, identifica qué necesita repetirse.
4. Integridad de interfaces y bitácoras
Compara cantidades, importes y estados entre origen y destino. Un reenvío puede producir duplicación; una desconexión puede dejar una transacción en estado incierto. Un identificador de operación permite analizar si el mismo evento se procesó dos veces. Una bitácora necesita controles sobre acceso, conservación y alteración; su sola existencia no acredita integridad.
5. Recuperación y continuidad
El respaldo es una copia de datos; la recuperación comprende devolver información y capacidades a una condición utilizable. La continuidad considera cómo prestar el servicio cuando la operación normal falla. Define dependencias, responsables, alternativas, criterios y pruebas.
En el análisis se utilizan objetivos de tiempo de recuperación y de punto de recuperación: cuánto tiempo de interrupción se pretende tolerar y qué pérdida de datos se acepta bajo los supuestos definidos. Deben relacionarse con el servicio, recursos y obligaciones. Establecerlos en un documento no demuestra capacidad para alcanzarlos.
6. Ejemplo resuelto
El portal recibe 200 solicitudes diarias. Su respaldo nocturno podría dejar sin copia hasta el intervalo desde el último respaldo satisfactorio. Si el objetivo de recuperación de datos fuera una hora, una copia nocturna por sí sola no demuestra cumplirlo. Se requiere una estrategia compatible, pruebas y reconciliación de solicitudes. Tampoco una restauración rápida garantiza que se restablezcan accesos, interfaces y atención.
Una prueba completa registra escenario, servicios afectados, último dato recuperable, tiempos reales, diferencias y decisión sobre brechas. Las solicitudes recibidas por un canal alterno deben incorporarse sin duplicarse al recuperar el portal. El cierre atiende resultados y responsabilidades, no únicamente el mensaje «copia completada».
Fundamento local: NCI, 4.4 y capítulo V. Los ejemplos de accesos, cambios y recuperación desarrollan procedimientos de análisis sobre esas necesidades; no atribuyen una arquitectura tecnológica universal a la norma. Ampliación conceptual: NIST SP 800-34 Rev. 1, planificación de contingencia.