Diagnóstico inicial sin costo para evaluar tu proyecto

¡Consultar ahora!
Infraestructura

¿Qué implica el certificado SSL para mi sitio

Descubre, paso a paso, qué sucede después de la entrega de tu proyecto: responsabilidades, mantenimiento y cómo proteger tus copias de seguridad en Perú

Kovensa 4 min de lectura

Foto de Nicolas Foster en Pexels

Al cerrar el contrato y recibir el software, la tranquilidad suele ser breve: la verdadera prueba comienza cuando el sistema ya está en producción. En este artículo verás qué ocurre después de la entrega, qué debes exigir y cómo evitar sorpresas que pongan en riesgo tus datos y tu certificado SSL.

Lo que empieza el día de la entrega

  • El checklist que nadie menciona: la mayoría de los proveedores entregan el código, la documentación y, en algunos casos, la configuración del servidor. Lo que rara vez se incluye es un plan detallado de pruebas de continuidad, validación de copias de seguridad fuera de sitio y la confirmación de que el certificado SSL para mi sitio está correctamente instalado y renovado.
  • Plazo de transición: en Perú, la normativa de la SUNAT exige que cualquier cambio que afecte la facturación electrónica esté operativo en un máximo de 15 días hábiles. Por lo tanto, la entrega debe ir acompañada de un calendario que indique cuándo se realizará la validación final y la puesta en marcha definitiva.
  • Acceso inicial: se entregan credenciales de administrador, pero sin un procedimiento de hand‑over (entrega formal) el equipo interno puede quedarse sin saber quién tiene los derechos de gestión del certificado ni dónde se guardan los archivos de respaldo.
  • Primeros logs: el día de la entrega se generan los primeros registros de actividad. Es fundamental que el cliente reciba acceso a esos logs y a una herramienta de monitoreo para detectar cualquier anomalía antes de que el tráfico real aumente.

Quién responde cuando algo falla

Responsabilidades contractuales

  1. Proveedor: debe garantizar la disponibilidad del software según el SLA acordado (por ejemplo, 99,5 % de uptime). En caso de caída del sitio por una mala configuración del SSL, la responsabilidad recae en el proveedor hasta que se corrija la causa raíz.
  2. Cliente: es responsable de mantener actualizados los certificados y de informar al proveedor cualquier cambio en la infraestructura (migración a otro datacenter, cambios de DNS, etc.).

Tiempos de respuesta

  • Incidente crítico (pérdida de disponibilidad total): respuesta máxima de 1 hora y solución o plan de mitigación en 4 horas.
  • Incidente medio (problemas de rendimiento o alertas de seguridad): respuesta en 4 horas, solución en 24 horas.
  • Incidente menor (consultas de documentación o ajustes de configuración): respuesta en 12 horas, solución en 72 horas.

Qué exigir por escrito

  • Acuerdo de nivel de servicio (SLA) que detalle los tiempos antes mencionados y las penalizaciones por incumplimiento.
  • Procedimiento de escalamiento con contactos directos, horarios y canales (correo, ticket, teléfono).
  • Informe de auditoría de seguridad que incluya la revisión del certificado SSL para mi sitio, su cadena de confianza y la fecha de vencimiento.
  • Plan de recuperación que indique cómo restaurar los datos desde la última copia de seguridad fuera de sitio y cuánto tiempo tomará volver a estar operativos.

Mantenimiento: qué es y qué no

Lo que sí es mantenimiento

  • Actualizaciones de seguridad: parches del sistema operativo, de la base de datos y de los componentes de la aplicación. En el contexto peruano, esto incluye la actualización de los módulos de facturación electrónica para cumplir con los últimos requisitos de la SUNAT.
  • Renovación del certificado SSL: el certificado suele tener una vigencia de 12 meses. El proveedor debe notificar al menos 30 días antes del vencimiento y encargarse de la reinstalación sin downtime.
  • Revisión de copias de seguridad: pruebas trimestrales de restauración desde la ubicación fuera de sitio para confirmar la integridad de los datos.

Lo que no es mantenimiento

  • Desarrollo de nuevas funcionalidades: cualquier requerimiento que implique crear módulos o integrar nuevos procesos se considera un proyecto aparte.
  • Re‑arquitectura completa: si el cliente decide migrar a otra plataforma (por ejemplo, pasar de un servidor propio a la nube), eso escapa al alcance del mantenimiento estándar.
  • Soporte a usuarios finales: la capacitación y el soporte de primer nivel a los usuarios deben estar cubiertos por un contrato de soporte separado.

Cómo evitar quedar atrapado

  • Falta de acceso a los certificados. Sin la clave privada del SSL, nadie puede renovar ni reinstalar el certificado si el proveedor desaparece.
  • Documentación incompleta. La ausencia de manuales de operación y de los scripts de backup deja a tu equipo sin referencia para actuar rápidamente.
  • Propiedad del código y de los datos. Si el contrato no especifica que el cliente es dueño del código fuente y de las bases de datos, el proveedor puede negar el acceso.

Accesos

  • Credenciales de administrador: deben entregarse en un documento encriptado y con fecha de expiración.
  • Llave privada del certificado SSL: guarda una copia en un almacén seguro (por ejemplo, un HSM o un gestor de contraseñas corporativo) y comparte el acceso con al menos dos responsables de TI.

Copias de seguridad

  • Frecuencia: al menos una copia diaria completa y una incremental cada 4 horas.
  • Ubicación: una copia en la infraestructura local y otra fuera de sitio (por ejemplo, en un bucket de AWS o Azure) para cumplir con la regla de copias de seguridad fuera de sitio.
  • Retención: conserva al menos 30 días de históricos para poder reconstruir cualquier escenario de pérdida.

Documentación y propiedad

  • Manual de operación: incluye pasos para renovar el certificado SSL, restaurar datos y ejecutar scripts de monitoreo.
  • Plan de contingencia: define quién toma decisiones, qué canales se usan y qué métricas se monitorizan durante una interrupción.
  • Cláusula de transferencia: asegura que, al término del contrato, el proveedor entregue todo el código fuente, la base de datos y los certificados sin coste adicional.

Conclusión

Después de la entrega, la verdadera gestión comienza con la claridad sobre responsabilidades, tiempos de respuesta y un plan de mantenimiento bien definido. Exigir la documentación del certificado SSL para mi sitio, asegurar copias de seguridad fuera de sitio y mantener la propiedad total del código y de los datos son pasos esenciales para que tu empresa no quede atrapada ante la primera incidencia. Con estos mecanismos en marcha, tu inversión en software a medida se traduce en continuidad operativa y cumplimiento de la normativa peruana, sin sorpresas desagradables.

  • #copias de seguridad para empresas
  • #seguridad informática para pymes
  • #certificado ssl
Compartir:

Seguir leyendo

Otros artículos