Lista de pruebas, seguridad, certificación y SLA de plataformas de lotería
Lista práctica para operadores sobre pruebas independientes, evidencias de seguridad, cobertura de certificación y niveles de servicio antes de firmar o lanzar.
Una lista de seguridad y disponibilidad de una plataforma de lotería debe vincular cada requisito con una prueba, un responsable que responda por él y evidencias de la versión que operará. Empiece por el producto previsto, los requisitos aplicables, los acuerdos de pago y el contrato. Encargue el trabajo independiente con antelación suficiente para corregir hallazgos y repetir las pruebas. Después negocie niveles de servicio medibles para todo el recorrido del cliente, no solo para un servidor que responde a una comprobación de estado.
Los informes de RNG, las pruebas de penetración, los certificados y los compromisos de disponibilidad responden a preguntas distintas. Ninguno sustituye a los demás. Utilice la lista de evaluación de proveedores para comparar propuestas y descargue WhiteLotto Operator Decision Pack (XLSX) (archivo en inglés) para registrar requisitos, carencias de pruebas y decisiones.
Separe pruebas, certificación y garantías operativas
Cree una matriz de requisitos: obligación y fuente, componente, versión, entorno, norma exigida, evaluador admisible, requisito previo, entregable y responsable de aceptación. Identifique qué cubren las pruebas del proveedor y qué sigue siendo específico de su despliegue. El control de calidad interno apoya este trabajo, pero no sustituye la evaluación independiente exigida.
| Alcance | Preguntas que comprobar | Pruebas que solicitar |
|---|---|---|
| Juego y RNG | Dónde se utiliza la aleatoriedad: generador, correspondencias, reglas del juego y gestión de resultados. | Informe que identifique componentes probados, versiones, métodos y exclusiones. |
| Plataforma e integraciones | Aceptación de boletos, cierre de ventas, solicitudes duplicadas, liquidación, incorporación de resultados y conciliación. | Resultados de pruebas del sistema para las integraciones configuradas y los casos de fallo. |
| Ciberseguridad | Autenticación, acceso privilegiado, API, configuración, vulnerabilidades y gestión de incidentes. | Evaluación con alcance definido, registro de hallazgos y pruebas independientes de reevaluación. |
| Seguridad de pagos | Flujos de datos de tarjetas, sistemas que afectan a esos flujos y reparto de responsabilidades. | Alcance PCI confirmado y pruebas de validación aplicables. |
| Operación del servicio | Disponibilidad, recuperación, escalada de soporte e integridad de transacciones. | Definiciones del SLA, pruebas de monitorización y resultados de ejercicios de recuperación. |
El catálogo de normas GLI distingue las normas de evaluación de juegos y seguridad. Una entrada en el catálogo no demuestra que un producto concreto esté certificado. Confirme la norma exacta y las pruebas aceptadas para su requisito; no suponga que un certificado cubre toda configuración o uso.
Seleccione proveedores independientes antes de la ventana de lanzamiento
Compruebe competencia pertinente, acreditación o reconocimiento cuando sean necesarios, independencia, conflictos, subcontratistas y disponibilidad. La presentación de un laboratorio no acredita su admisibilidad ni garantiza la aceptación de su informe. Acuerde por escrito alcance, métodos, exclusiones, materiales de entrada, confidencialidad, uso permitido de las conclusiones, tarifas de repetición de pruebas y entregables.
En materia de pagos, PCI SSC describe PCI DSS como protección de datos de cuentas de pago, incluidas entidades que podrían afectar al entorno de datos de titulares de tarjetas. No equipare externalizar el pago con carecer de responsabilidades. Mapee los flujos reales de datos y confirme el alcance y la vía de validación aplicables con la contraparte de pagos pertinente y un evaluador cualificado.
Mantenga los resultados de pruebas vinculados a la versión desplegada
Ingeniería debe mantener un manifiesto de versión que incluya identificadores o hashes de compilación, dependencias, configuración, infraestructura, juegos e integraciones. Registre el entorno de pruebas y explique las diferencias con producción. Dé a los evaluadores acceso limitado en el tiempo y registrado; minimice los datos y utilice canales seguros de transferencia aprobados.
El registro de pruebas debe vincular cada hallazgo con la versión afectada, gravedad, responsable, acción correctiva, control temporal, repetición de pruebas y decisión de cierre. Conserve de forma segura informes y hallazgos adversos, también en los resúmenes para dirección. Seguridad responde de la corrección técnica; cumplimiento comprueba la cobertura de requisitos; gestión de versiones comprueba que el despliegue coincida con las pruebas. Identifique quién puede aceptar el riesgo residual sin anular un requisito externo.
Un hallazgo crítico cerca del lanzamiento
Si una prueba de penetración revela acceso a cuentas privilegiadas, aísle el entorno afectado, evalúe la exposición e implique a los responsables de seguridad, ingeniería, cumplimiento y asuntos jurídicos. Corrija la causa raíz y examine los componentes relacionados. Obtenga pruebas de reevaluación independiente; no reduzca la gravedad para proteger la fecha. Retrase o limite el lanzamiento si no pueden cumplirse las condiciones de aceptación autorizadas.
Reserve tiempo para dudas de alcance, correcciones y repetición de pruebas, no solo para la evaluación inicial. Un cambio posterior en una biblioteca de autenticación puede afectar a sesiones, permisos y notificaciones de pago: evalúe su impacto y pregunte a los especialistas pertinentes si se necesitan pruebas específicas o más amplias.
Convierta las afirmaciones de disponibilidad en un SLA operativo
Un SLA es una definición contractual, no una certificación. Especifique los recorridos cubiertos, periodos de medición, ubicaciones de monitorización, cálculo y exclusiones. La disponibilidad suele calcularse como tiempo computable menos inactividad contabilizada, dividido por el tiempo computable. En un periodo ilustrativo de 30 días, el 99,9 % permite 43,2 minutos de inactividad contabilizada. Ese porcentaje dice poco sobre un fallo justo antes del cierre de ventas de boletos.
| Tema | Pregunte al proveedor |
|---|---|
| Servicio cubierto | ¿Incluye la disponibilidad el inicio de sesión, la confirmación de boletos, las API y el acceso al área de gestión? ¿Cómo se contabilizan los fallos parciales? |
| Dependencias y exclusiones | ¿Cómo se clasifican los fallos de pagos o de la fuente de sorteos? ¿Qué aviso y límites se aplican al mantenimiento? |
| Respuesta a incidentes | ¿Qué gravedad activa la escalada permanente? ¿Son objetivos separados la confirmación de recepción, las actualizaciones y la restauración? |
| Recuperación | ¿Cuáles son los RTO y RPO propuestos para cada servicio crítico? ¿Qué ejercicio los demuestra? |
| Pruebas y compensaciones | ¿Quién recibe las mediciones y los informes de incidentes? ¿Cómo se gestionan disputas, abonos y incumplimientos repetidos? |
El objetivo de tiempo de recuperación (RTO) es el tiempo objetivo para restaurar el servicio; el objetivo de punto de recuperación (RPO) es el límite objetivo de pérdida de datos medido en tiempo. Un calendario de copias de seguridad, por sí solo, no demuestra ninguno. Solicite tiempos de recuperación observados, puntos de datos restaurados, requisitos previos y excepciones. Estas cifras son ejemplos de adquisición, no compromisos de servicio de WhiteLotto. Incluya responsabilidades de pruebas y recuperación en su comparación de precios del software.
Pruebe fallos y restauración, no solo tráfico normal
Se pierde la confirmación del boleto
Un cliente envía un pedido, pero la respuesta agota el tiempo de espera. Compruebe si un reintento reutiliza la identidad de la solicitud, consulta el estado y evita duplicar el boleto o el cobro. Registre la transacción aceptada, la decisión de cierre de ventas y el resultado de conciliación. Una página de inicio que responde no debe ocultar un recorrido de compra averiado.
La restauración de la base de datos funciona, pero los registros no coinciden
Utilice un ejercicio aislado y autorizado para restaurar registros y comparar pedidos, referencias de pago, saldos y estados de boletos. Compruebe eventos ausentes o duplicados, reproducción de integraciones, continuidad de auditoría y trabajo en cola. Verifique que las claves y dependencias estén disponibles sin revelar secretos. Acuerde quién concilia las discrepancias antes de reabrir ventas; no cree transacciones reales de clientes para el ejercicio.
Reúna el paquete de pruebas para el lanzamiento
- Matriz de requisitos y confirmación de admisibilidad del evaluador.
- Arquitectura versionada, flujos de datos, manifiesto de versión y registro de equivalencia con producción.
- Informes de pruebas, certificados, exclusiones de alcance, condiciones de validez y permisos de uso de las conclusiones.
- Hallazgos, correcciones, reevaluaciones independientes y decisiones autorizadas de riesgo residual.
- Definiciones del SLA, contactos de escalada, resultados de recuperación y procedimientos de conciliación.
- Responsables de aceptación de versión, controles continuos y reglas de reevaluación activadas por cambios.
Tras el lanzamiento, controle vencimientos, parches, incidentes y cambios en bibliotecas, RNG, pagos o infraestructura. Evalúe si las pruebas siguen cubriendo la versión, incluso sin una fecha de caducidad impresa. El Marco de Ciberseguridad del NIST apoya la gestión continua del riesgo de ciberseguridad; un certificado no es monitorización continua. Explicite el reparto de responsabilidades al comparar entregas de marca blanca y llave en mano.
Mide el servicio del que realmente depende el operador
Que un servidor responda no demuestra que funcionen aceptación de boletos, acceso al monedero o liquidación de resultados. Define alcance, fuente de medición y periodo de informe antes de comparar compromisos SLA. Numerador y denominador deben describir el mismo servicio acordado.
- Lista los recorridos del usuario e integraciones incluidos en disponibilidad, junto con umbrales de funcionamiento degradado.
- Documenta clasificación de mantenimiento, fallos externos y fallos controlados por el operador; las exclusiones deben ser explícitas, no añadidas después.
- Separa horas de detección, acuse, mitigación y restauración para no confundir una respuesta rápida de soporte con recuperación del servicio.
- Acuerda acceso a evidencias, resolución de disputas y tratamiento de transacciones pendientes durante un incidente.
Conecta estas definiciones con los requisitos de recuperación API y la conciliación de pagos. Solicita un informe de incidente con registros sintéticos para comprobar si la medición puede reproducirse, en lugar de valorar el servicio por una cifra de disponibilidad.
Preguntas frecuentes
¿Demuestra un informe de RNG la seguridad de la plataforma?
No. Aborda el alcance de aleatoriedad que declara, no todas las cuentas, integraciones o controles operativos. No predice sorteos futuros.
¿Puede una promesa de disponibilidad sustituir las pruebas de recuperación?
No. Solicite pruebas de restauración y conciliación probadas junto con objetivos RTO y RPO definidos.
¿Confirma esta lista las certificaciones de WhiteLotto?
No. Solicite pruebas actuales para el alcance propuesto. Esta guía no afirma ninguna certificación de WhiteLotto ni garantiza disponibilidad, tiempo de recuperación o límite de pérdida de datos.
Analice la adecuación técnica
Explore la solución de plataforma WhiteLotto y después contacte con WhiteLotto para hablar de la adecuación técnica. Lleve el alcance del producto, el inventario de integraciones, los requisitos de pruebas y los niveles de servicio propuestos para documentar responsabilidades y preguntas pendientes.
Las pruebas tienen límites y no pueden garantizar seguridad, aprobación ni cumplimiento futuro. La aceptación de las pruebas corresponde a la autoridad o contraparte pertinente; las licencias y el asesoramiento profesional son áreas separadas. Es una guía de adquisición técnica, no asesoramiento jurídico.