Guía de Implementación
VTOL CD MX 3.8.0.0
Cambios por revisiones
Fecha | Revisión | Cambios – Motivo |
07/05/2018 | 1.0 | Creación del documento |
Índice
Índice |
---|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
El objetivo de este documento es ofrecer una guía completa del proceso de implementación del producto VTOL 3.8.
Asimismo, esta guía cuenta con un detalle de información y recomendaciones para el cumplimiento de los estándares PCI DSS (Payment Card Industry Data Security Standard) y PA DSS (Payment Application Data Security Standard).
Nota |
---|
Nota: Los puntos detallados en este documento son absolutamente necesarios para el cumplimiento de las normas PCI DSS y PA DSS. |
Âncora | ||||
---|---|---|---|---|
|
RS-VTOL Crédito Débito.
Âncora | ||||
---|---|---|---|---|
|
Los siguientes documentos fueron utilizados para la confección del manual de implementación:
- PCI DSS versión 3.2
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2_3_es-LA.pdf
- PA DSS versión 3.2
https://www.pcisecuritystandards.org/documents/PA-DSS_v3-2_3_es-LA.pdf
Âncora | ||||
---|---|---|---|---|
|
Se menciona la serie de documentos que acompañan al producto:
- VTOLCR-DB-MX-Guía de implementación
Este manual.
- VTOLCR-DB-Manual de actualización de material criptográfico
Explica cómo es el uso de las claves de encriptación del sistema indicando el mantenimiento que debe realizarse al material criptográfico.
- VTOLCR-DB-MX-Manual de usuario
Manual del usuario que explica la operatoria completa de VTOL CR/DB.
- VTOL-CORE-Manual de usuario
Manual del usuario que explica la operatoria completa de VTOL Core.
- Manual Borrado Seguro Windows
Manual donde se explica cómo realizar el borrado seguro de datos en Windows.
- Manual Borrado Seguro Linux
Manual donde se explica cómo realizar el borrado seguro de datos en Linux.
- F28 - CheckList Puesta en producción
Pasos a seguir para realizar una actualización del sistema en laboratorio y pasarlo a un ambiente productivo.
- Manual de gestión de entregas
Manual donde se explica cómo obtener la entrega desde el repositorio seguro y validación de la misma.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
RS-VTOL CR/DB es un validador de transacciones en línea, especializado en la industria del Retail y sus operaciones financieras.
Funciona como un gateway multipropósito que conduce transacciones electrónicas desde y hacia diferentes participantes (tiendas físicas y virtuales, banca, proveedores) a través de redes heterogéneas en forma rápida, segura y eficiente.
Algunas de las funcionalidades que ofrece RS-VTOL Crédito Débito son:
- validar transacciones de autorizaciones con tarjetas de crédito y débito
- centralizar los pagos con tarjetas
- reconocer los proveedores de las tarjetas utilizadas y encaminar las autorizaciones de las transacciones al centro autorizador correspondiente según la configuración del sistema
- abstraer a los puntos de venta de múltiples protocolos de comunicación
- facilitar la integración de pago con tarjetas a los puntos de ventas
- abstraer a la aplicación de punto de venta el manejo y la integración con el pinpad
- proveer un mecanismo de sincronización de transacciones entre los diferentes componentes con el fin de evitar transacciones perdidas o cargos duplicados
- auditoría transaccional
El producto VTOL está formado por los siguientes componentes:
- VTOL Server
- VTOL Engine
- VTOL Client
Âncora | ||||
---|---|---|---|---|
|
VTOL Server es una aplicación desarrollada íntegramente en el lenguaje de programación Java, que la hace independiente del sistema operativo a emplearse.
Posee una capa de persistencia que permite abstraerse del motor de base de datos a utilizar.
Hay diversos componentes de comunicación que permiten comunicar a la aplicación bajo diferentes protocolos de comunicación, como ser TCPIP, X25, PR1000, HTTP, etc.
Existe una capa de interpretación que se encarga de interpretar los mensajes entrantes y salientes de la aplicación. Esta característica permite manejar diferentes protocolos, algunos operando bajo ciertos estándares y otros del carácter propietarios.
Una vez pasada la capa de interpretación, existe un módulo denominado VTOL Core. Este componente se encarga de realizar la auditoría de transacciones bajo lo que denominamos "tercer mensaje". Este protocolo permite tener sincronizado el punto de venta con VTOL de forma tal de evitar la pérdida de transacciones o la duplicidad de las mismas.
Por último, cada transacción es derivada por el VTOL Core al módulo crédito débito, el cual, bajo ciertas reglas de negocio, envía las autorizaciones financieras a los diversos centros autorizadores para su aprobación.
Las transacciones son persistidas en la base de datos, respetando las normas de seguridad de la norma PCI para su posterior explotación, como ser reportes, cierres de lotes, conciliación de transacciones, monitoreos, etc.
El producto cuenta con una consola WEB de administración centralizada a través de la cual se puede: configurar la aplicación, obtener diversos reportes, monitorear el sistema, definir alertas, administrar la seguridad, acceder a la auditoría, etc. Esta consola de administración presenta un nivel de seguridad de acceso por usuario y contraseña.
A nivel de arquitectura, la aplicación está soportada sobre el servidor de aplicaciones JBOSS, el cual brinda diferentes servicios que son utilizados por VTOL, como ser por ejemplo la configuración de datasources.
Arquitectura de VTOL Server
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
En este manual encontrará toda la información necesaria para instalar el producto RS-VTOL CR/DB.
Se explicarán cada uno de los pasos de implementación, los requerimientos de hardware y software, las propiedades a ser configuradas como así también todos los aspectos necesarios para cumplir con el estándar de seguridad PA-DSS.
Âncora | ||||
---|---|---|---|---|
|
Se recomienda una lectura inicial de todo el documento antes de comenzar con el procedimiento de implementación de la aplicación.
Además es recomendable tener los conocimientos mínimos del software de base requerido por VTOL para una mejor comprensión de los temas tratados en este documento.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
A continuación se detallarán los pre-requisitos para realizar la instalación de VTOL Server en el sistema.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
- Windows 32/64 bits
- Windows 7 o superior
- Windows Server 2012 R2 o superior
- Linux 32/64 bits
- Cent OS v7 o superior
Âncora | ||||
---|---|---|---|---|
|
- Memoria RAM: 2GB (mínimo disponible para la aplicación)
- CPU: cuádruple procesador de al menos 2.6 GHZ
- Capacidad de almacenamiento en Disco Rígido: 20GB o superior
- 1 placa de red de 100Mb o 2 placas de red de 100Mbits para instalación en clúster
Nota |
---|
Nota: Los requerimientos de hardware dependerán en gran parte del volumen de transacciones a procesar por el sistema. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
- Java Virtual Machine (JDK) 1.8.x (32/64bits acorde al SO)
- Servidor de aplicaciones: J2EE Compliant. Debe encontrarse instalado JBoss Wildfly 10.1.0
- Motor de base de datos:
- MS SQL Server 2012 Service Pack 3 o superior
- Oracle 11.2 o superior
- DB2 9.5 o superior
Nota |
---|
Nota: El software de base debe tener instalados todos los parches de seguridad que el fabricante haya liberado hasta el momento. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Previa instalación de la aplicación VTOL, es importante tener en cuenta el entorno en el cual se instalará la aplicación. Este conocimiento facilitará la comprensión de la infraestructura y la interacción de los componentes involucrados en la solución completa.
A continuación se detalla un diagrama de red de una aplicación típica de pago:
Los indicadores del tipo señalan un componente determinado dentro del diagrama.
Los indicadores del tipo señalan la secuencia de una autorización normal de una transacción de venta que involucra datos de tarjeta de crédito/débito.
Como se observa en la figura, VTOL está instalado de forma centralizada dentro de la red DMZ. Los puntos de venta están instalados en las sucursales de la empresa comunicándose con VTOL mediante el protocolo TCPIP, en cada punto de venta se encuentra VTOL Client. Éste luego se comunica con los centros autorizadores o Cas mediante una red MPLS (ésta podrá variar según normativa de los mismos).
A continuación se explica en forma de caso de uso los flujos de datos que suceden en el esquema general de red, el mismo sirve para todos los tipos de transacciones: venta, devolución, anulación, etc.
Caso de Uso: Autorización de una transacción |
|
|
|
Orden | Componente | Acción | Comunicación |
1 | C1 | El POS (ubicado en la tienda dentro de la WAN de la empresa) inicia una transacción de venta, anulación o devolución contra VTOL Client especificando el monto y las cuotas. | TCPIP |
2 | C2 | Los datos de la autorización pasan por el Firewall principal (ubicado entre la WAN y la LAN de la empresa). Este los deja pasar ya que el puerto 3000 de VTOL Server está habilitado. | TCPIP |
3 | C3 | VTOL Server recibe la petición de autorización originada por VTOL Client, por medio de un socket server junto con los datos sensibles de la tarjeta. | TCPIP |
4 | C4 | VTOL Server graba la transacción de autorización en la base de datos ubicada en la LAN de la empresa. Los datos sensibles son almacenados encriptados con 3DES utilizando un mecanismo de administración dinámica y aleatoria de llaves. | TCPIP |
5 | C3 | Una vez grabada la transacción en la base de datos, VTOL envía la petición al centro autorizador (VISA, POSNET, AMEX, cual corresponda) por el protocolo de comunicación TCPIP utilizando el formato definido por la norma ISO8583 para las autorizaciones financieras. | TCPIP |
6 | C5 | La trama enviada por VTOL Server al centro autorizador pasa a través del firewall anterior a la red MPLS que se utiliza normalmente para enlazar a los centros autorizadores. | TCPIP |
7 | C6 | El centro autorizador (VISA, POSNET, AMEX, cual corresponda) recibe la petición de autorización desde la red MPLS y aprueba la transacción emitiendo la respuesta por el mismo medio (la red MPLS). Entonces la respuesta, en formato ISO8583, es enviada por el mismo enlace hacia VTOL Server. | TCPIP |
8 | C3 | El proceso VTOL (ubicado en la DMZ) recibe la respuesta de la autorización por medio del enlace TCPIP establecido al iniciar la comunicación y procede a validarla y procesarla. | TCPIP |
9 | C4 | El proceso VTOL (ubicado en la DMZ) graba la transacción de respuesta en la base de datos por medio del driver correspondiente usando el estándar JDBC y el protocolo de comunicación TCPIP. | TCPIP |
10 | C3 | El proceso VTOL envía la respuesta a VTOL Client, ubicado en el POS, por medio del mismo socket que el POS creó en su momento usando TCPIP al puerto 3000. | TCPIP |
11 | C2 | El firewall (ubicado entre la red DMZ y la red WAN de la empresa) recibe la respuesta y la rutea al POS originador. | TCPIP |
12 | C1 | El POS (ubicado en una tienda de la empresa) recibe la respuesta a la petición de autorización y emite el voucher correspondiente. | TCPIP |
Caso de Uso: Acceso WEB |
|
| |
Orden | Componente | Acción |
|
1 | C9 | El usuario desde una PC accede a la consola WEB de VTOL (utilizando HTTPS) para realizar diferentes tareas: monitoreo, configuración, etc. |
|
2 | C3 | VTOL recibe la petición HTTPS y muestra la pantalla de LOGIN para que el usuario se identifique con usuario y contraseña. |
|
3 | C9 | Opera normalmente hasta finalizar sesión o se haya superado el tiempo máximo de inactividad de sesión. |
|
Nota |
---|
Nota: Para conocer el diagrama de flujo de datos que muestra todo el proceso de autorización visite el anexo 17.9 Flujograma del Proceso de Autorización. |
En el siguiente diagrama se muestra cómo es la arquitectura general y la comunicación entre los componentes de VTOL:
Diagrama General
Âncora | ||||
---|---|---|---|---|
|
Es fundamental que los datos de la aplicación (información de transacciones, etc.) no sean almacenados en un entorno el cual sea accesible desde Internet. Si la aplicación debe ser accedida desde Internet, la base de datos debe estar en una LAN fuera del acceso remoto. Una zona desmilitarizada (DMZ) o red perimetral, es una red local que se ubica entre la red interna de una organización y una red externa, generalmente Internet.
Esto permite que los equipos (hosts) de la DMZ puedan dar servicios a la red externa a la vez que protegen la red interna en el caso de que intrusos comprometan la seguridad de los equipos (host) situados en la zona desmilitarizada. Para cualquiera de la red externa que quiera conectarse ilegalmente a la red interna, la zona desmilitarizada se convierte en un callejón sin salida.
Esto se puede visualizar con mayor claridad en el gráfico de topología de red de una instalación típica de VTOL del apartado 6.1 Esquema general de una red VTOL.
La aplicación VTOL en sí no requiere acceso remoto desde internet, pero en caso de que el cliente quiera implementarlo deberá hacerlo a través de alguna funcionalidad segura utilizando como mínimo dos factores de autenticación, ya sea a través de un usuario/contraseña, token, etc., lo importante es que la conexión sea lo más segura posible. Ver apartado 6.4 Acceso remoto a la aplicación.
La comunicación entre DMZ y la red interna es mediante el puerto 3003 (puerto SSL de VTOL Server).
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Se sugiere controlar el acceso a cualquier computadora, servidor y base de datos que se encuentre involucrado en la aplicación de pagos y/o posea datos de titulares de tarjetas, por medio de un identificador único de usuario (usuarios nominales) y una autentificación segura. La autenticación segura debe implementar el método de autenticación de múltiples factores (por ejemplo: dispositivo token, tarjetas inteligentes, clave públicas, etc).
Nota |
---|
Nota: Synthesis sólo sugiere la implementación de autenticación de múltiples factores para el acceso remoto. El cliente será responsable de configurar los accesos remotos y realizar la autenticación correcta de múltiples factores. En VTOL, no se requiere ninguna configuración para admitir la autenticación de varios factores. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Es posible que sea necesario acceder remotamente a una computadora, un servidor o una base de datos que se encuentre involucrado en la aplicación de pagos y/o posea datos de titulares de tarjetas.
Âncora | ||||
---|---|---|---|---|
|
Cualquier acceso remoto que se haga al ambiente donde reside el sistema de pagos (servidor, base de datos, etc) debe hacerse de forma segura, utilizando para la conexión una dirección específica.
El mecanismo típico de acceso remoto por consola es el siguiente:
- Establecer una conexión VPN (que provee encriptación)
- Establecer una sesión de escritorio remoto a la máquina específica de red del cliente
Nota |
---|
Nota: Se deberán aplicar las medidas de seguridad listadas en "6.4.3 Consideraciones generales de seguridad". |
Âncora | ||||
---|---|---|---|---|
|
Si los sistemas del cliente donde reside la aplicación de pago o la base de datos utilizada por esta permiten el acceso remoto de administración "sin consola", el mismo debe realizarse de manera segura.
Para brindar el acceso administrativo sin consola debe utilizarse alguna tecnología o protocolo seguro como los que se presentan a continuación:
- SSH
- VPN
- SSL/TLS
En particular, no deben utilizarse protocolos que envíen información utilizando un cifrado débil o en "texto plano" como:
- telnet
- Rlogin
Nota |
---|
Nota: Se deberán aplicar las medidas de seguridad listadas en "6.4.3 Consideraciones generales de seguridad". |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Las siguientes medidas de seguridad son necesarias si se permite el acceso remoto a la aplicación de pago o al ambiente del mismo:
- Cambiar la configuración por defecto en la aplicación de acceso remoto (por ejemplo, cambiar las contraseñas por defecto y utilizar identificadores de usuarios únicos)
- Permitir la conexión solo a las direcciones IP/MAC específicas y pertenecientes a los administradores (restricciones de acceso)
- Utilizar autenticación robusta y contraseñas complejas para el realizar el login al sistema remoto
- Asignar a todos los usuarios un identificador único (usuario nominal)
- Implementar VPN para permitir que usuarios que accedan remotamente a la red, por medio de un firewall, que además autentique a los usuarios utilizando un esquema de autenticación de dos factores. Se recomienda implementar el doble factor de autenticación utilizando alguna de las siguientes tecnologías:
- Autenticación remota y servicio de dial-in (RADIUS)
- TACACAS (Terminal Access Controller Access Control System) con token
- VPN (basado en SSL/TLS o IPSEC) con certificados individuales
- Habilitar la transmisión de datos encriptados según lo indicado en el punto PCI DSS 12.1
- Habilitar la función de "logging", de manera que registre todas las acciones tomadas por los usuarios y los intentos de login fallidos
- Las cuentas de usuario y las contraseñas deben cumplir con los requerimientos indicados en PCI:
- Deben ser habilitadas solo por el lapso en que se requiera el acceso remoto, luego deben ser deshabilitadas
- No utilizar cuentas ni contraseñas genéricas
- Cambiar la contraseña de usuario al menos una vez cada 90 días
- Requerir una contraseña alfanumérica de al menos 7 caracteres
- Requerir una contraseña que contenga caracteres alfabéticos y numéricos
- Activar el historial de contraseñas, de manera tal que el sistema no permita que el usuario establezca una contraseña idéntica a las últimas 4 contraseñas utilizadas
- Si el usuario realiza más de 6 intentos de login fallidos, el sistema debe bloquear la cuenta, por un lapso mínimo de 30 minutos o hasta que el administrador lo desbloquee
- Si una sesión se mantuvo inactiva durante más de 15 minutos, el sistema debe cerrarla y obligar al usuario a iniciar sesión nuevamente
- El o los equipos que se conecten por VPN deben disponer de un firewall personal y un antivirus actualizado instalados
Nota |
---|
Nota: El incumplimiento de uno de los puntos de esta sección llevará al incumplimiento de las normas PCI. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
En el caso de instalar la aplicación en un ambiente de redes inalámbricas, y los datos de las tarjetas habientes se trasmitan por estas redes, se deberán tener en cuenta los siguientes puntos para que de esta manera, sea una instalación segura y no afecte el cumplimiento de la norma PCI:
- El cliente deberá instalar un firewall para controlar el tráfico de entrada/salida de la red inalámbrica. De esta manera se debe denegar cualquier acceso no autorizado desde el entorno inalámbrico hacia el entorno de la aplicación
- Las redes inalámbricas deben operar encriptadas (utilizando un mecanismo de encriptación fuerte, como WPA2 Enterprise (802.11i))
- La configuración por defecto del protocolo SNMP (Protocolo simple de administración de red) que se encuentra en los dispositivos inalámbricos deberá cambiarse
- Las contraseñas por defecto en los puntos de acceso inalámbrico o los dispositivos que conectan a los dispositivos de comunicación inalámbrica entre sí para formar una red inalámbrica, deben ser cambiadas
- El firmware de los dispositivos inalámbricos debe actualizarse periódicamente para soportar las últimas tecnologías de encriptación.
- Bajo ningún punto de vista, utilizar WEP (Wired Equivalent Privacy). Sistema de cifrado del estándar IEEE 802.11 como protocolo para redes Wi-Fi, ya que no es seguro para redes inalámbricas
- Utilizar claves de 128 bits (104 bit para la clave de encriptación y 24 bits de inicialización)
- La aplicación es usada en conjunto con SSL/TLS
- Las claves deben ser cambiadas antes de la implementación de la red, cada 90 días o cuando se cambie el personal (por ejemplo: rotación de personal, el empleado abandona su puesto de trabajo, etc) o cuando existan compromisos de las mismas (por ejemplo, el empleado renunció)
- El acceso es restringido por MAC
Aviso |
---|
Importante: Esto es totalmente necesario para realizar una transmisión inalámbrica bajo las normas especificadas por PCI. Cualquier modificación a la configuración, la aplicación quedará fuera del alcance de lo especificado por PCI. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Entre el POS o Punto de Venta y VTOL se trasmiten transacciones o autorizaciones que contienen información sensible de las tarjetas, por lo tanto se deben tomar ciertos recaudos al momento de comunicar ambos sistemas (POS-VTOL).
Existen dos posibilidades de configuración de la red que se usará para comunicar ambos sistemas:
- Red privada
- Red pública (Ejemplo: Internet, etc)
Si bien VTOL no restringe ninguna de las dos posibilidades, es necesario configurar la comunicación de ambos sistemas tal como se indica en el presente documento.
En el caso de que los POS se comuniquen con VTOL por medio de una Red Pública se deberá establecer un vínculo seguro utilizando tecnología VPN que implemente alguno de los siguientes protocolos seguros:
- IPSEC
- SSL/TLS
Nota |
---|
Nota: Aunque VTOL utiliza SSL, por razones de seguridad se recomienda utilizar una VPN. |
Estos protocolos permiten establecer un vínculo seguro (por ejemplo, una VPN genera un túnel encriptado) entre dos extremos de una comunicación.
De esta manera, los datos trasmitidos entre ambos sistemas tendrán un nivel más de seguridad y quedarán encriptados.
Los datos sensibles que se trasmiten por estos enlaces, entre el POS y VTOL, son los siguientes:
- Track I
- Track II
- PAN
- CVC
- Fecha de vencimiento
Hay otros datos que se transmiten (como ser el monto, las cuotas, etc) pero no son sensibles.
Como se observa, los datos requieren si o si ser trasmitidos de forma segura y encriptados, sobre todo, en caso de estar posicionados en una red pública.
La aplicación predeterminada utiliza la comunicación SSL para el intercambio de información entre VTOL Client y VTOL Server. Es necesario configurar el keystore durante la instalación. Visite la sección "7.4 Instalación de certificados para el protocolo HTTPS".
Nota |
---|
Nota: El incumplimiento del punto descrito anteriormente podría invalidar el cumplimiento de PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
Para comprobar que la aplicación solo acepta certificados de confianza se debe acceder a la página de configuración en la consola Web y verificar que las propiedades SSL referencien al almacén de claves que forma parte de la instalación de la aplicación: synthesis.keystore
Para utilizar versiones e implementaciones seguras de los protocolos de seguridad, acceder a la página de configuración en la consola Web y definir el valor TLSv1.2 para la propiedad SSL: Protocolo SSL/TLS, que indica el protocolo a utilizar.
La aplicación solo permite utilizar protocolos TLS: TLSv1.1 y TLSv1.2 en la propiedad SSL: Protocolo SSL/TLS. Si se cambia a una versión de SSL, por ejemplo SSL3, la aplicación deja de funcionar.
Para poder utilizar la solidez del cifrado adecuadamente se deben configurar la propiedad SSL: Protocolo SSL/TLS con el valor TLSv1.2 y la propiedad SSL: Paquetes de cifrados habilitados, que indica que algoritmo de cifrados utilizar para que solamente soporte los más robustos. Por ejemplo:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, Etc.
Âncora | ||||
---|---|---|---|---|
|
El único mecanismo existente para la actualización de la aplicación de pago VTOL que Synthesis provee, es por medio de la conexión a un SFTP y las indicaciones serán facilitadas por el área de Servicio de Atención al Cliente de Synthesis.
El área de Servicio al Cliente de Synthesis notificará al cliente las nuevas actualizaciones o parches por correo electrónico. Los parches se entregarán a través de un SFTP y se indicarán cuando el cliente desee realizar la actualización.
Synthesis no realiza actualizaciones del aplicativo de forma remota, por lo tanto nunca solicitará acceder de forma remota para realizar dicha tarea. Si el cliente necesita ayuda para instalar la nueva actualización, se pondrá en contacto con el área de Atención al Cliente de Synthesis que le ayudará por correo electrónico o teléfono.
Los clientes corroborarán la integridad de la entrega de archivos de SFTP comprobando la suma de la comprobación con el valor de suma de la comprobación entregado por Synthesis. En este proceso se utiliza la herramienta "Quick Hash" y el algoritmo utilizado es el "SHA512". Para conocer el proceso en detalle y saber cómo realizar la validación, dirigirse al documento "Manual de gestión de entregas.pdf".
Âncora | ||||
---|---|---|---|---|
|
A continuación se listan los componentes de software relacionados con la aplicación VTOL:
Componente | Versión | Objetivo |
JBOSS | JBoss Wildfly 10.1.0 o EAP 7 | Servidor de aplicaciones. Brinda servicio de páginas web, motor de colas JMS y conexiones a la base datos |
JVM | 8 | Máquina virtual que permite iniciar la aplicación JAVA |
JSF | 1.2 | Estándar de manejo de páginas web definido por SUN Microsystems |
JTDS | 1.2.x | Driver de conexión a la base de datos |
Hibernate | 2.1.8 y 3.2.0 | Tecnología que permite abstraer el acceso a la base de datos |
Jasper Report | 5 | Motor de reportes que brinda soporte a los reportes definidos en VTOL |
Quartz | 1.5.2 | Componente de planificación de tareas repetitivas en VTOL |
Âncora | ||||
---|---|---|---|---|
|
El producto VTOL nombra las versiones de la siguiente manera:
A.B.C.D
Donde "A", "B", "C" y "D" son números enteros y están divididos por un punto.
Los cambios producidos en desarrollos de VTOL dan como resultado un cambio en el valor incremental de la versión:
- "A" corresponde a cambios severos que afectan a la arquitectura de la solución.
Como ser cambios en el framework, codificar la aplicación en otro lenguaje, etc.
- "B" corresponde a cambios importantes en la funcionalidad y tiene un gran impacto en la seguridad de la aplicación (cambios importantes que afectan a la seguridad).
Por ejemplo, cambio de VTOL 3.6.C.D (no PCI Compliance) a 3.7.C.D (PCI Compliance).
- "C" corresponde a cambios menores en la funcionalidad e influencian con menor impacto en la seguridad de la aplicación (cambios menores que afectan a la seguridad).
Por ejemplo, un campo nuevo en la mensajería de un tipo de transacción.
- "D" corresponde a cambios muy pequeños o correcciones de errores detectados, no tienen impacto en la funcionalidad o la seguridad.
Por ejemplo, corregir un error en el reintento de un reverso o un error a nivel de informe.
El elemento comodín es la posición D, y sólo se utiliza para correcciones de errores y nunca se utilizará para representar un cambio que afecte a la seguridad de la aplicación. En forma concisa, el comodín no se utiliza para indicar los cambios PCI PA-DSS o los cambios que afectan a la seguridad.
Por lo tanto, la versión con el comodín será A.B.C.X, donde X es el elemento comodín.
Cuando se realiza una nueva entrega de VTOL, la versión incrementará un valor en el elemento correspondiente de acuerdo al tipo de impacto que tuvo la aplicación.
Las entregas tienen un archivo de texto llamado "ChangeLog.txt" que incluye notas de la versión con las actualizaciones que tuvo de la aplicación. Mediante estos archivos, se puede conocer la versión instalada de VTOL y los cambios realizados en la aplicación entre versión y versión. Para más detalles, consulte la sección "17.3 Obtención de la versión de VTOL instalada".
Además, cuando se entrega una versión, Synthesis informará por correo electrónico los cambios que la versión incluye y los impactos que tienen (tanto en la integración como en las operaciones).
Nota |
---|
Nota: Los cambios en la aplicación se realizan según el procedimiento escrito en el documento "PA 26 Procedimiento de desarrollo de soluciones.pdf" y el proceso de entrega de una versión se detalla en el documento "PA 23 Procedimiento de entrega de versiones.pdf". |
Nota |
---|
Nota: Las versiones internas de VTOL, por ejemplo las entregadas en el área de QA, difieren teniendo el título "snapshot" en lugar de "rc" (release candidate). Este texto es el que diferencia la versión interna de la externa. |
La metodología de control de versiones que Synthesis utiliza tanto para versiones internas como externas es la misma.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Existen diferentes escenarios al momento de instalar VTOL.
A continuación se listan los distintos escenarios y posteriormente se explica en detalle cómo es cada uno de ellos.
Escenarios posibles:
- Instalación de cero de VTOL 3.8
Es el caso cuando se quiere instalar por primera vez VTOL y no existe ninguna instalación del mismo en el sistema
2. Migración de VTOL 3.8 en Laboratorio a Producción
Es el caso cuando se encuentra instalado VTOL en un entorno de prueba y se quiere migrar al entorno de producción
3. Migración de VTOL 3.7 Productivo a VTOL 3.8 Productivo
Es el caso cuando se encuentra instalada la versión 3.7 de VTOL en un entorno de producción y se desea cambiar a la versión 3.8
4. Actualización de VTOL 3.8 Productivo
Es el caso cuando se encuentra instalada la versión 3.8 de VTOL en un entorno de producción y se desea ejecutar una actualización
Nota |
---|
Notas: 1. Cualquier otro escenario que no esté detallado en esta sección correrá el riesgo de que algún punto no sea considerado, pudiendo afectar a la seguridad de la aplicación y la información y, por ende, al no complimiento de las normas PCI. 2. Cuando se nombra VTOL 3.7 y 3.8 quiere decir que esas versiones cumplen con el estándar PCI, así como cualquier versión superior. La versión VTOL 3.6 (o inferiores) no cumple con el estándar. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
La instalación de cero se refiere a instalar VTOL por primera vez en el sistema. Dado que no existe una instalación previa, no existe información sensible de tarjetas en logs o en base de datos. Por lo tanto, este procedimiento, no constituye un riesgo de seguridad sobre la información sensible de las tarjetas que puede estar almacenada.
Se ofrecen dos escenarios para instalar de cero VTOL:
- la forma completa y recomendada (explicada en el punto "7.1.1.1 Instalación completa")
- la forma avanzada y manual (indicada en el punto "7.1.1.2 Instalación avanzada")
7.1.1.1 Instalación completa
La instalación completa de VTOL se realiza gracias al uso de un asistente gráfico de configuración. Esta forma de instalar VTOL es la recomendada por su facilidad.
Para ello se deben seguir los siguientes pasos:
- Verificar la existencia de la base de datos que usará la aplicación VTOL.
- Iniciar sesión en el sistema operativo donde se instalará la aplicación VTOL con un usuario con permisos de administrador.
- Iniciar el instalador de la aplicación VTOL ejecutando la siguiente sentencia en la línea de comandos:
java –jar INSTALADOR.jar
Por ejemplo:
java –jar rs-vtol-cd-ha-mx-installer-3.8.0.0-rc16-04-2018 .jar
Nota |
---|
Verificar tener seteada correctamente la variable JAVA_HOME. En caso de no tenerla, setearla a la carpeta de instalación de la JVM. Para esto verificar la carpeta de instalación, ejemplo: C:\Java\jdk1.8.0_25\ |
4. Se presentará la pantalla de bienvenida del instalador.
5. Al pasar a la siguiente pantalla se mostrarán los términos y condiciones de uso de la aplicación de software para ser leídos y posteriormente aceptados para poder continuar con la instalación.
Nota |
---|
Nota: La opción "Only VTOL Components" se utiliza cuando se tiene que realizar una instalación de cero de forma manual o una actualización de VTOL. Para instalar de cero manualmente VTOL, ir al punto "7.1.1.2 Instalación avanzada". |
8. Seleccionar mediante el desplegable la versión del Jboss instalado.
En el sector de ingreso "Directory" debe ingresarse la ruta donde está alojado el Jboss.
Por último, en "'rsvtol' Server Configuration" ingresar el nombre de la carpeta la cual va a crearse, dentro de Jboss, e instalarse VTOL.
Oprimir el botón "Próxima".
9. Indicar el motor de base de datos que se utilizará y presionar "Próxima".
10. Ingresar los datos vinculados a la base de datos a emplearse:
- La versión del motor de base de datos seleccionado
- La conexión URL
- El host de la base de datos
- El nombre de la base de datos que fue creada previamente para VTOL
- Y las credenciales (usuario y contraseña) para la autenticación del motor de base de datos
Una vez completados los datos, presionar el botón "Próxima".
11. Seleccionar si se desea habilitar el boletín offline. Presionar "Próxima".
12. Seleccionar para cada canal el tipo de conexión correspondiente que se empleará y presionar "Próxima".
13. Completar otros datos de configuración.
Si no desea utilizar la modalidad Clúster, haga clic en "Próxima", de lo contrario configure el resto de las propiedades:
- El identificador del nodo dentro del clúster
- La descripción del nodo del clúster. Esta descripción se visualizará en la consola de administración
- El nombre de la partición
- La dirección IP de la interfaz. IP que tiene asignada la placa de red que servirá como interface entre los nodos del clúster
- La zona horaria en la cual se está instalando la aplicación
- El directorio donde la aplicación VTOL almacenará la llave maestra (si no existe, se le ofrecerá crearlo)
Aviso |
---|
Importante: Un clúster es un grupo o un conjunto que agrupa nodos. Los nodos, dentro del mismo clúster, trabajarán en conjunto para una misión en común. Dentro del mismo clúster no debe haber nodos iguales. Entonces, si se desea instalar VTOL's independientes, basta con que el nombre de la partición sea distinto entre ellos, sin importar el nombre de nodo del clúster. En cambio, si se quiere instalar varios VTOL trabajando en conjunto o clúster, es requisito fundamental que el nombre de partición sea el mismo y que cada instancia de VTOL tenga un nombre de nodo de clúster distinto. Para mayor conocimiento del funcionamiento en clúster referirse al punto 17.4 Esquema instalación en clúster. |
14. Presionar "Install" para que se ejecute la instalación.
Se podrá observar información detallada de la instalación presionando el botón "Enseñar detalles". Al hacer esto se mostrarán dos solapas:
- En la solapa "Salida" podrá observar el progreso de la instalación visualizando las tareas ejecutadas por el instalador
- En la solapa "Errores" se presentan las fallas que tuvieron lugar durante la instalación
15. La finalización de la instalación se informa mediante un mensaje de "Terminado". Oprimir "Aceptar".
16. Presionar el botón "Salir" para salir del instalador.
17. Dentro del directorio wildfly-10.1.0.Final se creó la carpeta con la nueva versión instalada de VTOL.
A continuación, lo que se debe realizar es ejecutar los scripts en la base de datos. Ver el apartado 7.3.1 Creación de la base de datos.
Âncora | ||||
---|---|---|---|---|
|
Esta instalación está pensada para usuarios especialistas y se realiza de forma manual.
Primero se deben realizar todos los pasos indicados en el anexo 17.6 Configuración del Servidor de Aplicaciones JBOSS.
Posteriormente, se deben ejecutar los pasos del apartado 7.2 Pre-Instalación de la aplicación.
Âncora | ||||
---|---|---|---|---|
|
Es común que VTOL sea instalado en un laboratorio con el fin de poder realizar pruebas de integración con los sistemas externos (POS por ejemplo), probar el hardware, el software de soporte, etc.
En estas pruebas de laboratorio se suelen utilizar datos de pruebas, tanto en las transacciones, como en el acceso administrativo de la aplicación.
Nota |
---|
Nota: Como datos de pruebas no se deben utilizar datos reales, como ser números de tarjetas, nombres de usuarios, etc ya que incumpliría con PCI. Las tarjetas a utilizar no deben ser productivas. |
Una vez finalizadas las pruebas en laboratorio es común querer pasar el servidor de laboratorio con VTOL instalado a un ambiente productivo.
Esta acción hace que los datos antes utilizados, como datos de pruebas, signifiquen un riesgo para la seguridad de la aplicación y lleven al no cumplimiento de las normas de seguridad de PCI.
Por lo tanto, para realizar esta acción es necesario cumplir con una determinada cantidad de pasos que se enumeran en el documento "F28 - CheckList Puesta en producción.pdf".
Los objetivos de este documento son:
- Indicar como borrar el material criptográfico (se recomienda ver el documento "VTOLCR-DB-Manual de actualización de material criptográfico.pdf")
- Borrado de información sensible histórica
- Borrado de logs
- Migración de versiones anteriores
Nota |
---|
Nota: El seguimiento de los pasos descriptos en este documento garantiza el cumplimiento de las normas de seguridad PCI. Cualquier incumplimiento de uno de los puntos podría invalidar el cumplimiento de PCI DSS. |
Posterior a la ejecución de los pasos antes mencionados, se puede continuar con la puesta en producción de la aplicación.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Cuando la instalación de VTOL 3.8 se haga sobre una instalación de VTOL 3.7, se deberán seguir los siguientes pasos:
- Detener la aplicación o servicio de VTOL
- Se debe verificar que se borre de forma segura los logs de VTOL 3.7. Para ello, dirigirse al apartado "17.2 Herramienta para el borrado seguro de datos"
- Para saber dónde se están almacenando los logs referirse a "13.1 Archivos de log"
- Realizar una copia de seguridad de la base de datos utilizada por la aplicación VTOL. Es importante tener en cuenta que no se almacenan datos en texto plano. Los mismos son almacenados encriptados dentro de la misma base de datos
- Instalar VTOL 3.8 siguiendo los pasos indicados en ésta guía
- Iniciar en el paso "7.1.1 Instalación de cero de VTOL 3.8"
- Dado que la base de datos ya existe, no ejecutar el paso de creación de base de datos "7.3.1 Creación" dentro de "7.3 Configuración de la base de datos". En cambio, sí se debe ejecutar la actualización de la base de datos detallado en el paso "7.3.2 Actualización"
- Cambio de clave de almacenamiento de datos sensibles
- Como medida de seguridad es necesario actualizar el material criptográfico utilizado para encriptar los datos sensibles de tarjetas en la base de datos. Para realizar esta actualización se debe seguir el procedimiento descripto en el manual "VTOLCR-DB-Manual de actualización de material criptográfico.pdf". En este procedimiento se describe el uso de una herramienta que automáticamente renueva el material criptográfico para cumplimiento de las normas PCI: Cryptool es la herramienta responsable de cambiar o quitar el material criptográfico de la aplicación VTOL (es posible elegir entre cambiar o eliminar material criptográfico). Debe utilizarse en cada cambio de versión de la aplicación. Las funcionalidades que cubre la aplicación son la actualización clave, la actualización de datos sensibles y la eliminación de material criptográfico.
Una nueva clave maestra se genera automáticamente en una base de datos donde se utiliza para cifrar la nueva clave operativa, también creada automáticamente. Con este último, los datos sensibles almacenados en las tablas transaccionales se vuelven a cifrar. Al final de la operación, se quitan las claves antiguas, quedando sólo las claves recién creadas y permaneciendo los datos confidenciales cifrados con la nueva clave operativa. Para realizar el proceso es necesario detener VTOL, comprobar la existencia de todos los índices y ejecutar Cryptool. Para obtener el detalle completo, consulte la sección "Instalación y ejecución" del documento anterior mencionado
7. Si la instalación fue exitosa:
- Realizar el borrado seguro de la instalación de VTOL 3.7
- Se deberá borrar el contenido entero de la copia de seguridad del punto 5, asegurándose la eliminación segura de cualquier dato sensible almacenado en el sistema de archivos
8. Si la instalación no fue exitosa (rollback de la versión):
- Realizar el borrado seguro de la instalación de VTOL 3.8 recién instalada.
- Restaurar la base de datos con la copia de seguridad generada en el punto 5. La operatoria corresponde a una restauración general en MSSQL Server u Oracle, según corresponda. Luego, eliminar la copia de seguridad de forma segura
Nota |
---|
Nota: Para realizar el borrado seguro referirse a 17.2 Herramienta para el borrado seguro de datos. |
Âncora | ||||
---|---|---|---|---|
|
Cuando la instalación de VTOL 3.8 se haga sobre una instalación anterior a VTOL 3.8 se deberán seguir los siguientes pasos:
- Detener la aplicación o servicio de VTOL
- Borrar de forma segura los logs de VTOL 3.8. Para saber dónde se están almacenando los logs referirse a "13.1 Archivos de log"
- Realizar una copia de seguridad de la instalación actual de VTOL 3.8
- Hacer una copia de seguridad de la siguiente carpeta:
Jboss/rsvtol
- Hacer una copia de seguridad de la siguiente carpeta:
4. Realizar una copia de seguridad de la base de datos de VTOL
5. Instalar VTOL 3.8 siguiendo los pasos indicados en esta guía:
- Comenzar en el paso "7.2 Pre-Instalación de la aplicación". Mucha de la configuración detallada en el apartado "17.6 Configuración del Servidor de Aplicaciones JBOSS" puede no ser requerida, debido a que se puede reutilizar la configuración existente en el server JBoss
- Dado que la base de datos ya existe, no ejecutar el paso de creación de base de datos sino que se debe ejecutar la actualización detallada en el paso "7.3.2 Actualización".
6. Cambiar la clave de almacenamiento de datos sensibles
- Utilizar la aplicación CrypTool para el cambio de la clave de encripción de información sensible en la base de datos y para que posteriormente se puedan administrar las claves por medio de la consola de administración
- Para mayor información sobre el uso de la herramienta CrypTool, verificar el documento "VTOLCR-DB-Manual de actualización de material criptográfico.pdf"
7. Si la instalación fue exitosa: realizar el borrado seguro de la copia de seguridad de la instalación de VTOL 3.8
- Se deberá borrar el contenido entero de las copias de seguridad de los puntos 3 y 4, asegurándose la eliminación segura de cualquier dato sensible almacenado en el sistema de archivos
8. Si la instalación no fue exitosa(rollback de la versión):
- Realizar el borrado seguro de la instalación de VTOL 3.8 recién instalada
- Restaurar el contenido de la copia de seguridad y borrar tal copia de forma segura
- Restaurar la base de datos con la copia de seguridad generada en el punto 4. La operatoria corresponde a una restauración general en MSSQL Server u Oracle, según corresponda. Luego, eliminar la copia de seguridad de forma segura.
Nota |
---|
Nota: Esta instalación se realiza solo para cambios en la aplicación, mejoras, parches, etc. Se debe tener en cuenta para realizar el borrado seguro de datos el manual de 17.2 Herramienta para el borrado seguro de datos. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
RS-VTOL CR/DB cuenta con un instalador gráfico que guía a través del proceso de pre-instalación de la aplicación. Primero solicita al usuario el ingreso de los parámetros de configuración requeridos y luego efectúa la pre-instalación del producto, la cual consiste en el armado de una estructura de directorios que contiene los componentes de la aplicación, como ser los scripts de base de datos, archivos de configuración, etc.
Para comenzar con la pre-instalación de la aplicación es requerido primero cumplimentar con los pasos indicados en el anexo 17.6 Configuración del Servidor de Aplicaciones JBOSS.
Âncora | ||||
---|---|---|---|---|
|
A continuación se describen los pasos para realizar la instalación de la aplicación:
Para ello se deben seguir los siguientes pasos:
- Verificar la existencia de la base de datos que usará la aplicación VTOL.
- Iniciar sesión en el sistema operativo donde se instalará la aplicación VTOL con un usuario con permisos de administrador.
- Iniciar el instalador de la aplicación VTOL ejecutando la siguiente sentencia en la línea de comandos:
java –jar INSTALADOR.jar
Por ejemplo:
java –jar rs-vtol-cd-ha-mx-installer-3.8.0.0-rc16-04-2018 .jar
Nota |
---|
Verificar tener seteada correctamente la variable JAVA_HOME. En caso de no tenerla, setearla a la carpeta de instalación de la JVM. Para esto verificar la carpeta de instalación, ejemplo: C:\Java\jdk1.8.0_25\ |
4. Se presentará la pantalla de bienvenida del instalador.
5. Al pasar a la siguiente pantalla se mostrarán los términos y condiciones de uso de la aplicación de software para ser leídos y posteriormente aceptados para poder continuar con la instalación.
8. Seleccionar mediante el desplegable la versión del Jboss instalado.
En el sector de ingreso "Directory" debe ingresarse la ruta donde está alojado el Jboss.
Por último, en "'rsvtol' Server Configuration" ingresar el nombre de la carpeta la cual va a crearse, dentro de Jboss, e instalarse VTOL.
Oprimir el botón "Próxima".
9. Indicar el motor de base de datos que se utilizará y presionar "Próxima".
10. Seleccionar si se desea habilitar el boletín offline. Presionar "Próxima".
11. Seleccionar para cada canal el tipo de conexión correspondiente que se empleará y presionar "Próxima".
12. Completar otros datos de configuración.
Si no desea utilizar la modalidad Clúster, haga clic en "Próxima", de lo contrario configure el resto de las propiedades:
- El identificador del nodo dentro del clúster
- La descripción del nodo del clúster. Esta descripción se visualizará en la consola de administración
- El nombre de la partición
- La dirección IP de la interfaz. IP que tiene asignada la placa de red que servirá como interface entre los nodos del clúster
- La zona horaria en la cual se está instalando la aplicación
- El directorio donde la aplicación VTOL almacenará la llave maestra (si no existe, se le ofrecerá crearlo)
Aviso |
---|
Importante: Un clúster es un grupo o un conjunto que agrupa nodos. Los nodos, dentro del mismo clúster, trabajarán en conjunto para una misión en común. Dentro del mismo clúster no debe haber nodos iguales. Entonces, si se desea instalar VTOL's independientes, basta con que el nombre de la partición sea distinto entre ellos, sin importar el nombre de nodo del clúster. En cambio, si se quiere instalar varios VTOL trabajando en conjunto o clúster, es requisito fundamental que el nombre de partición sea el mismo y que cada instancia de VTOL tenga un nombre de nodo de clúster distinto. Para mayor conocimiento del funcionamiento en clúster referirse al punto 17.4 Esquema instalación en clúster. |
13. Presionar "Install" para que se ejecute la instalación.
Se podrá observar información detallada de la instalación presionando el botón "Enseñar detalles". Al hacer esto se mostrarán dos solapas:
- En la solapa "Salida" podrá observar el progreso de la instalación visualizando las tareas ejecutadas por el instalador
- En la solapa "Errores" se presentan las fallas que tuvieron lugar durante la instalación
14. La finalización de la instalación se informa mediante un mensaje de "Terminado". Oprimir "Aceptar".
15. Presionar el botón "Salir" para salir del instalador.
16. Dentro del directorio wildfly-10.1.0.Final se creó la carpeta con la nueva versión instalada de VTOL.
A continuación, lo que se debe realizar es ejecutar los scripts incrementales en la base de datos. Ver el apartado 7.3.2 Actualización de la base de datos.
Âncora | ||||
---|---|---|---|---|
|
Finalizada la pre-instalación se visualizarán los componentes dentro de la carpeta 'rsvtol' de la siguiente forma:
Carpeta | Descripción |
bin | Contiene los archivos de inicio y de detención de la aplicación como proceso de Windows y de Linux |
configuration | Esta carpeta contiene toda la configuración del Application Server adaptada para que la aplicación VTOL funcione correctamente |
deployments | En esta carpeta se encuentra el EAR de la aplicación |
dist | Posee dos carpetas importantes en su interior:
|
lib | Reservado para uso futuro para que puedan almacenarse librerías |
tmp | Carpeta de temporales del servidor de aplicaciones |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Los scripts, para crear e inicializar la base de datos que emplea la aplicación, se encuentran en la carpeta "scripts" dentro del directorio de instalación del producto. Los scripts se encuentran separados en carpetas según el motor de base de datos al que corresponden y se deben ejecutar en una secuencia determinada según sea necesario crear o actualizar una base de datos de VTOL.
En las siguientes secciones se explica con mayor detalle cada una de las posibilidades.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Los scripts de base de datos existentes deberán ser ejecutados, con el usuario administrador de base de datos.
Cada archivo contiene, como inicio de su nombre, un número que indica la secuencia en que debe ser corrido.
Los scripts se encuentran ubicados en la ruta Jboss/rsvtol/dist/scripts.
Primero se deben ejecutar los script de VTOL CORE, ubicados en:
Jboss/rsvtol/dist/scripts/core/nombreMotorBD
, en el siguiente orden:
- "1-CONSOLE-SCHEMA.sql"
- "2-CORE-SCHEMA.sql"
- "3-CORE-POPULATE.sql"
Por último, se deben ejecutar los scripts del módulo Crédito Débito, ubicados en
Jboss/rsvtol/dist/scripts/cd-mx/nombreMotorBD
, en el siguiente orden:
- "1-CD-MX-SCHEMA.SQL"
- "2-CD-MX-POPULATE.SQL"
Dónde:
- rsvtol
- es el directorio dentro del Jboss donde se instalaron los componentes de VTOL.
- nombreMotorBD
- corresponde al nombre del motor de base de datos
- mssql – Motor de base de datos MS SQL Server
- oracle – Motor de base de datos Oracle
- db2 – Motor de base de datos DB2
- corresponde al nombre del motor de base de datos
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Cuando la instalación se trate de una actualización de versión y no una instalación de cero, es posible que se deba actualizar la base de datos pre-existente.
Para este caso existen scripts de actualización de la base de datos. Estos se identifican por el comienzo con INC en su nombre (Incremental). Por ejemplo: "INC-1.1.0-TO-1.1.1.sql"
Los mismos se encuentran en los siguientes directorios:
Scripts correspondientes a VTOL CORE
{VTOL_Server}/dist/scripts/core/nombreMotorBD
Scripts correspondientes a Módulo Crédito Débito
{VTOL_Server}/dist/scripts/cd-mx/nombreMotorBD
Dónde:
- {VTOL_Server}
- es el directorio donde se instalaron los componentes de VTOL
- nombreMotorBD
- corresponde al nombre del motor de base de datos
- mssql – Motor de base de datos MS SQL Server
- oracle – Motor de base de datos Oracle
- db2 – Motor de base de datos DB2
- corresponde al nombre del motor de base de datos
La secuencia de ejecución estará asociada a la versión actual de VTOL (para saber que versión está instalada ver apartado 17.3 Obtención de la versión de VTOL instalada).
Es decir se deberán correr los scripts incrementales comprendidos entre el número de versión instalada y la que deseamos instalar. A continuación se muestra un ejemplo:
INC-3.7.3.3-TO-3.7.3.5.sql
INC-3.7.3.5-TO-3.7.3.6.sql
INC-3.7.3.6-TO-3.7.3.7.sql
INC-3.7.3.7-TO-3.8.0.0.sql
Los script enumerados anteriormente deben ejecutarse para actualizar la versión 3.7.3.3 a la 3.8.0.0.
Nota |
---|
Nota: Podría haber saltos en el versionado de los scripts (como ser INC-3.7.3.3-TO-3.7.3.5.sql), esto se debe a que se generarán versiones sin actualización de scripts. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
El monitoreo y la administración de la aplicación VTOL se hace por medio de una consola WEB. Por cuestiones de seguridad, el acceso a esta se hace por medio del protocolo seguro HTTPS (protocolo HTTP sobre canal encriptado). Para que este protocolo funcione correctamente hay que instalar un certificado válido.
A continuación se explica qué es un certificado digital, cómo se gestiona y cómo se instala.
Âncora | ||||
---|---|---|---|---|
|
HTTPS es la implementación segura de HTTP. Si bien existen varios protocolos y versiones solo algunos son seguros (no se ha podido demostrar lo contrario):
- TLSv1.1
- TLSv1.2 (recomendado y por defecto en la aplicación)
Por lo tanto se aconseja usar TLSv1.2.
Âncora | ||||
---|---|---|---|---|
|
La utilización de HTTPS implica el uso de certificados digitales.
Ilustración de un certificado digital
Un certificado digital está compuesto por:
- Datos del propietario del certificado
- Clave pública
- Clave privada
- Datos del certificado
La aplicación VTOL hace uso de los certificados Los certificados son documentos digitales que dan fe de la vinculación entre una clave pública y un individuo o entidad.mediante la utilización de un "keystore" de java. Un "keystore" es un almacén o base de datos de java, que almacena claves y certificados.
Los certificados pueden estar certificados por una entidad CA Autoridad Certificadora o Certification Authority. Ejemplo: Verisign, Trustwave habilitada o bien pueden estar auto-firmados, es decir, tener un CA propio.
Si se usa un certificado auto-firmado, el cliente WEB emitirá una alerta ya que no puede validar el certificado con una entidad CA válida.
Nota: Se recomienda utilizar un certificado emitido por una entidad habilitada.
Âncora | ||||
---|---|---|---|---|
|
A continuación se detalla cual es la secuencia para instalar un certificado digital emitido por una CA en la aplicación VTOL.
En caso de instalar el certificado auto-firmado, ejecutar el "Paso 1" y luego continuar con el "Paso 4".
Paso 1
En este paso se creará un nuevo KeyStore con su clave privada y su certificado auto-firmado. El comando a utilizar es el siguiente:
keytool -genkey -alias vtol -keyalg RSA -sigalg "SHA256withRSA" -keystore synthesis.keystore -validity 90 -storepass changeit -keysize 2048
Nota: cambiar la clave "changeit" del KeyStore
Este comando pedirá información para poder generar el certificado.
Finalizado este paso se habrá creado un archivo "synthesis.keystore" que corresponde al nuevo KeyStore que se usará en la aplicación.
Paso 2
Una vez creado el KeyStore hay que crear un CSR (Certificate Signing Request o Requerimiento de forma del certificado) para enviar al CA.
keytool -certreq -keyalg RSA -alias vtol -file certreq.csr -keystore synthesis.keystore -storepass changeit
Este comando generará un archivo llamado "certreq.csr" que será requerido por la CA.
Paso 3
Una vez que la CA generó el certificado digital hay que incorporarlo al KeyStore previamente creado.
Para ello ejecutar el siguiente comando:
keytool -import -alias vtol -keystore synthesis.keystore -storepass changeit -trustcacerts -file certificado.cer
Donde "certificado.cer" corresponde al nombre del certificado otorgado por la CA.
Paso 4
Ubicar el archivo "synthesis.keystore", correspondiente al nuevo KeyStore, dentro de:
Jboss/rsvtol/configuration
Luego abrir el archivo:
Jboss/rsvtol/configuration/standalone.xml
Y configurar:
<security-realm name="ApplicationRealm">
<server-identities>
<ssl>
<keystore path="synthesis.keystore" relative-to="jboss.server.config.dir" keystore-password="changeit" key-password="changeit" generate-self-signed-certificate-host="localhost"/>
</ssl>
</server-identities>
<authentication>
<local default-user="$local" allowed-users="*" skip-group-loading="true"/>
<properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
</authentication>
<authorization>
<properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
</authorization>
</security-realm>
donde:
- changeit – corresponde a la contraseña utilizada en el paso 1
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Por cuestiones de seguridad y para cumplimiento de las normas PCI es necesario auditar todo acceso o acción sobre los dominios manejados por la aplicación VTOL como ser:
- Configuración
- Binarios
- Logs
- Base de datos
- Material criptográfico
A continuación se dan indicaciones de cuáles son éstos dominios, donde están y que requerimientos mínimos de auditoria son necesarios.
Âncora | ||||
---|---|---|---|---|
|
Para los siguientes directorios es necesario activar el registro de auditoria nativo del sistema operativo para las acciones señaladas por la columna "Auditar".
Ubicación | Auditar |
JBOSS_HOME | Borrado y modificación |
VTOL_LOG | Borrado y lectura |
VTOL_DB (Archivo del motor de base de datos) | Borrado |
VTOL_SECURITY | Borrado, modificación, lectura, creación |
Âncora | ||||
---|---|---|---|---|
|
Para las siguientes tablas es necesario activar el registro de auditoria nativo del motor de base de datos para las acciones señaladas por la columna "Auditar".
Tabla | Auditar | Descripción |
RS_AUDIT | DELETE; UPDATE; DROP | En esta tabla se registra toda la actividad de los usuarios llevada a cabo en consola de administración web de VTOL. |
RS_USER | SELECT; DELETE; UPDATE; DROP | Se registran los usuarios de la consola de administración web de VTOL |
RS_USER_GROUP | SELECT; DELETE; UPDATE; DROP | Se registran los grupos de permisos que tienen asignados los usuarios de la consola de administración web de VTOL |
RS_USER_ROLE | SELECT; DELETE; UPDATE; DROP | Se registran los permisos que tienen asignados los usuarios de la consola de administración web de VTOL |
EncryptedPassword | SELECT; DELETE; UPDATE; DROP | Se registran las claves de encriptación de datos sensibles Maestra y Operativa |
FinancialTransaction | SELECT; DELETE; UPDATE; DROP | Se registran las transacciones procesadas por VTOL en el corriente día. |
ClosedFinancialTransaction | SELECT; DELETE; UPDATE; DROP | Se registran las transacciones procesadas luego del cierre de transacciones diario |
Otras | DELETE; UPDATE; DROP | El resto de las tablas de VTOL |
Nota |
---|
Nota: la activación del registro de auditoria en las tablas de la base de datos es requisito para cumplir con las normas PCI. |
Âncora | ||||
---|---|---|---|---|
|
La aplicación VTOL trabaja con distintos puertos de comunicación a conocer y a tener en cuenta a la hora de configurar los sistemas aledaños como ser routers, firewalls, antivirus, etc.
Entonces para el correcto funcionamiento de la aplicación, es necesario que los puertos señalados a continuación no sean bloqueados.
Puerto | Tipo | Componente | Descripción |
8080 | Entrada | JBOSS-WEB | Puerto http sin seguridad. Se puede acceder a la consola Web referenciando este puerto, pero la aplicación redirecciona automáticamente al puerto seguro. |
8443 | Entrada | JBOSS-WEB | Puerto http seguro. Al acceder en este puerto se establece un enlace cliente-servidor seguro utilizando tecnologías SSL/TLS |
3000 | Entrada | VTOL | Puerto utilizado por VTOL para recibir las transacciones provenientes de los distintos puntos de venta |
1099 | Local | JBOSS | Puerto local utilizado para publicar y acceder el directorio nativo de java llamado JNDI |
1100 | Entrante | JBOSS | Puerto local y remoto accedido por los distintos nodos del cluster de VTOL. Solo son accedidos entre las instancias del cluster. |
1433 | Saliente | BD | Puerto utilizado por VTOL para establecer la conexión con la base de datos. |
7894 | Saliente | VTOL | Puerto de comunicación utilizado por VTOL para comunicarse con el centro autorizador American Express. |
8888 | Saliente | VTOL | Puerto de comunicación utilizado por VTOL para comunicarse con el centro autorizador POSNET. |
7777 | Saliente | VTOL | Puerto de comunicación utilizado por VTOL para comunicarse con el centro autorizador VISA. |
5555 | Saliente | VTOL | Puerto de comunicación utilizado por VTOL para comunicarse con el centro autorizador SHOPPING. |
5979 | Saliente | VTOL | Puerto de comunicación utilizado por VTOL para comunicarse con el centro autorizador GE o General Electric. |
Donde,
- Si un puerto es de Entrada, significa que un sistema externo se comunicará con el componente señalado
- Si un puerto es Local, significa que el componente señalado lo usa de forma local.
- Si un puerto es Saliente, significa que el componente señalado lo usa como destino del sistema externo.
Nota |
---|
Nota: Todos los puertos no listados anteriormente deben ser cerrados en los respectivos sistemas aledaños a la aplicación con el fin de asegurar el sistema y cumplir con las normas establecidas por PCI |
Âncora | ||||
---|---|---|---|---|
|
Se mencionan los números de puertos que se utilizan en un entorno VTOL:
- POS - VTOL Client: 3500 (VTOL Client escucha ese puerto)
- VTOL Client - VTOL Server: 3000 (VTOL server escucha ese puerto con conexión SSL)
- VTOL Server - Base de datos: 1433
- VTOL Server - Autorizador / Procesador de pago: Los puertos son dinámicos y el Autorizador puede cambiarlo. Por defecto son:
- AMEX: 7894
- POSNET: 8888
- Visa: 7777
- Shopping: 5555
- General Electric: 5979
- Consola VTOL - Base de datos: 1433 (Es el mismo de VTOL Server - Base de datos)
- Consola VTOL - Usuario: 8443 (https) puerto de acceso a la consola web
7.7 VTOL Engine
VTOL Engine es un componente standalone (no requiere de un servidor) que se encarga de la gestión del backend de la aplicación, recibiendo peticiones SOAP o REST desde aplicaciones que necesitan consumir los servicios ofrecidos por éste. Los servicios ofrecidos son mensajería, administración, reportes, etc.
Âncora | ||||
---|---|---|---|---|
|
Nota |
---|
Para instalar e integrar VTOL Client MX, dirigirse al documento de integración POS - LIB FULL MX. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
9.1 VTOL Engine
Una vez instalada la aplicación hay que iniciar VTOL Engine. La misma puede ser iniciada de dos maneras:
- Como proceso
- Como servicio (recomendado)
Âncora | ||||
---|---|---|---|---|
|
Para iniciarlo como proceso:
- Iniciar sesión en el sistema operativo
- Ejecutar uno de los archivos startVTOLEngine.cmd (Windows) o startVTOLEngine.sh (Linux)
Âncora | ||||
---|---|---|---|---|
|
Posterior inicio de VTOL Engine, hay que iniciar la aplicación VTOL Server. La misma puede ser iniciada de dos maneras:
- Como proceso
- Como servicio (recomendado)
Âncora | ||||
---|---|---|---|---|
|
Para iniciar RS-VTOL CR/DB como proceso:
- Iniciar sesión en el sistema operativo
- Ejecutar uno de los archivos start.bat, start.cmd (Windows) o start.sh (Linux)
- Para detener la aplicación, se debe ejecutar uno de los siguientes archivos: stop.cmd, stop.bat (Windows) o stop.sh (Linux)
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Luego de realizada la instalación de VTOL, es recomendado que sea iniciada como servicio del sistema operativo.
De esta manera se podrá levantar VTOL al encender el servidor o poder desloguear usuarios sin verse afectada la operatoria.
De esta manera se podrá garantizar que el servicio esté disponible siempre que el servidor lo esté sin depender de la intervención de un usuario.
9.2.2.1 Servicio de Windows
Para realizar esta instalación se utiliza una herramienta llamada WRAPPER. La misma se obtiene desde aquí: http://wrapper.tanukisoftware.com/doc/english/download.jsp
La ejecución del servicio deberá ser realizada por un usuario con permisos de administrador y deberá tener permisos de lectura y escritura sobre la carpeta de instalación de VTOL.
9.2.2.1.1 Modificar el archivo de configuración
Al descomprimir la aplicación WRAPPER se crearan varias carpetas y se deberá ingresar en la llamada "\wrapper\conf" y editar el archivo "wrapper.conf" para realizar la configuración necesaria:
#********************************************************************
# TestWrapper Properties
#********************************************************************
Aquí se debe especificar la ubicación del comando a utilizar para levantar la JVM. Si no se especifica un path específico, Wrapper buscará un comando java en el directorio raíz.
# Java Application
wrapper.java.command=%JAVA_HOME%/bin/java
Aquí se especifica la clase a ejecutar cuando wrapper levanta la aplicación. El valor de este campo depende del tipo de método de integración que se haya seleccionado. En la mayoría de los casos esta NO es la main class de nuestra aplicación.
En nuestro caso este campo no se modifica y debe especificarse como se detalla a continuación.
# Java Main class.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp
Aquí se deben especificar los ClassPath que se van a usar cuando se levante la aplicación (siempre deben estar presentes "tools.jar" y "wrapper.jar" que son necesarios para el wrapper).
Para cada classpath que se desee agregar se debe empezar con la línea "wrapper.java.classpath."
seguido de un numero entero secuencial con la línea anterior, el cual debe empezar desde 1. Es OBLIGATORIA la secuencialidad de los números, no pueden existir números ausentes.
En nuestro caso agregaremos solo el classpath donde está ubicado el "run.jar" además de los predeterminados para el wrapper.
# Java Classpath (include wrapper.jar) Add class path elements as
# needed starting from 1
wrapper.java.classpath.1= %JAVA_HOME%/tools.jar
wrapper.java.classpath.2= D:/wrapper_win32_3.1.1/lib/wrapper.jar
wrapper.java.classpath.3=%JBOSS_HOME%/bin/run.jar
Aquí se deben especificar todos los LibraryPath que se utilicen, dicho path especifica una lista de directorios en donde se puede recurrir para la búsqueda de cualquier librería JNI usada por la aplicación.
Es OBLIGATORIA la inclusión del archivo Wrapper.dll (para Windows) o libWrapper.so (para Linux) en alguno de los directorios especificados.
Para cada path que se desee agregar, se debe empezar con la línea "wrapper.java.library.path." seguido de un número entero secuencial con la línea anterior, el cual debe empezar desde 1. Es OBLIGATORIA la secuencialidad de los números, no pueden existir números ausentes.
# Java Library Path
wrapper.java.library.path.1= D:/wrapper_win32_3.1.1/lib
Aquí se deben especificar los parámetros que se desean pasar a la JVM para su inicio. Es importante destacar que NO son parámetros para nuestra aplicación propiamente dicha.
Por cada parámetro que se desee agregar se debe empezar con la línea "wrapper.java.additional." seguido de un número entero secuencial con la línea anterior, el cual debe empezar desde 1. Es OBLIGATORIA la secuencialidad de los números, no pueden existir números ausentes. Cada parámetro no puede contener espacios por lo tanto si se desea incluir parámetros con espacios lo que se debe hacer es particionarlo, ejemplo para el parámetro –x –y se deben escribir 2 líneas secuenciales, una para –x y otra para –y.
En nuestro caso no se utiliza dicha propiedad por lo tanto se deja comentada.
# Java Additional Parameters
#wrapper.java.additional.1=
Aquí se especifica la cantidad de memoria (en MB) que se debe reservar para el inicio de la JVM. Si se deja en cero, Wrapper utilizará la cantidad predeterminada de la JVM para ser levantada.
Este valor impactará en el tiempo que insume el inicio de la aplicación. Este tiempo es óptimo cuando se especifica un valor cercano al necesario por la aplicación una vez que esta ha sido iniciada.
En nuestro caso especificaremos un valor de 512 MB.
# Initial Java Heap Size (in MB)
wrapper.java.initmemory=512
Aquí se especifica la máxima cantidad de memoria (en MB) que la JVM tiene permitido utilizar. Si se deja en cero, wrapper utilizará la cantidad predeterminada de la JVM para ser usada.
En nuestro caso especificaremos un valor de 1024 MB.
# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=2048
Aquí se deben especificar los parámetros que se desean pasar a la aplicación para su inicio.
Por cada parámetro que se desee agregar se debe empezar con la línea "wrapper.app.parameter." seguido de un número entero secuencial con la línea anterior, el cual debe empezar desde 1. Es OBLIGATORIA la secuencialidad de los números, no pueden existir números ausentes.
Cuando se especifica como mainClass el valor "org.tanukisoftware.wrapper.WrapperSimpleApp" el primer parámetro que se debe especificar es la clase que contiene nuestro método principal.
Cada parámetro no puede contener espacios por lo tanto si se desea incluir parámetros con espacios lo que se debe hacer es particionarlo, ejemplo para el parámetro –x –y se deben escribir 2 líneas secuenciales, una para –x y otra para –y.
En nuestro caso se deberán especificar las siguientes líneas siendo SERVER el nombre de la aplicación propia a ejecutar (ejemplo VTOLC/D)
# Application parameters. Add parameters as needed starting from 1
wrapper.app.parameter.1=org.jboss.Main
wrapper.app.parameter.2=-Dvtol.startup.conf.path=C:/Jboss/rsvtol/dist/config
wrapper.app.parameter.3=-Dframework.factory.impl=com.synthesis.vtol.core.module.ModuleFrameworkFactory
wrapper.app.parameter.4=-Dreport.vtol.module.cd.dir=C:/Jboss/rsvtol/dist/config/modules/cd-mx/reports
wrapper.app.parameter.5=-c
wrapper.app.parameter.6=default
wrapper.app.parameter.7=-b
wrapper.app.parameter.8=0.0.0.0
wrapper.app.parameter.9=-u 230.0.0.4
wrapper.app.parameter.10=-Djgroups.bind_addr=www.xxx.y.z
Aquí deberán configurarse los parámetros de la aplicación. El ejemplo es válido y solo deberán modificarse los valores de:
- Punto 2: Se deberá parametrizar el path correcto de la instalación hasta la carpeta config de la aplicación.
- Punto 4: Se deberá parametrizar el path correcto de la instalación hasta la carpeta reports incluida.
- Punto 8: Se deberá parametrizar la dirección IP donde se realizara el bind.
- Punto 10: al igual que para el caso anterior se debe definir la IP donde se realizará el bind.
#********************************************************************
# Wrapper Logging Properties
#********************************************************************
Aquí se debe especificar el formato de salida del logueo de consola.
# Format of output for the console.
wrapper.console.format=PM
Aquí se debe especificar el nivel de logueo que se desea obtener de la consola.
# Log Level for console output.
wrapper.console.loglevel=NONE
Aquí se especificar el path y el archivo destinatario en donde se almacenarán los logs de la aplicación.
# Log file to use for wrapper output logging.
wrapper.logfile==Jbos/rsvtol/log/XXX.log
Aquí se debe especificar el formato del archivo de logueo de la aplicación.
# Format of output for the log file.
wrapper.logfile.format=LPTM
Aquí se debe especificar el nivel de logueo que se desea almacenar en el archivo.
# Log Level for log file output. (See docs for log levels)
wrapper.logfile.loglevel=NONE
Aquí se debe especificar el crecimiento máximo que pueda llegar a tener el archivo de logueo. El tamaño se debe especificar en bytes, abreviando con k (cuando es Kbytes) y con m (cuando es MegaBytes).
# Maximum size that the log file will be allowed to grow.
wrapper.logfile.maxsize=0
Aquí se debe especificar el número de archivos cíclicos de logueo que se permite como máximo antes del comienzo de depuración de los más viejos.
El valor en cero implica que no tiene límites.
# Maximum number of rolled log files.
wrapper.logfile.maxfiles=0
#********************************************************************
# Wrapper NT Service Properties
#********************************************************************
NO modificar esta sección si se encuentra una aplicación, que utiliza este archivo de configuración, instalada como servicio. Se debe desinstalar como primer paso y luego realizar las modificaciones deseadas.
Aquí se debe especificar el nombre del servicio a instalar.
# Name of the service
wrapper.ntservice.name=VTOL CD
Aquí se debe especificar el nombre que deseamos que se muestre por pantalla.
# Display name of the service
wrapper.ntservice.displayname=VTOLC/D
Aquí se debe especificar una breve descripción del servicio a instalar.
# Description of the service
wrapper.ntservice.description=VTOLC/D
Aquí se debe especificar el modo de ejecución del servicio a instalar Automático (AUTO_START), Manual (DEMAND_START).
# Mode in which the service is installed.
wrapper.ntservice.starttype=AUTO_START
9.2.2.1.2 Aplicar la configuración e instalar servicio
Luego de realizada la configuración del Wrapper, se deberá ingresar en la carpeta "\wrapper\bin" y ejecutar, utilizando un usuario que tenga permisos para poder crear servicios pero que no sea el administrador del sistema operativo, el archivo "InstallTestWrapper-NT.bat" para lograr la creación del servicio de VTOL.
9.2.2.1.3 Desinstalar el servicio de VTOL
Si se desea desinstalar el servicio anteriormente creado de VTOL, se deberá ingresar en la carpeta "\wrapper\bin" y ejecutar el archivo "UninstallTestWrapper-NT.bat". Esto eliminará de la lista de servicios de Windows la aplicación.
En caso de modificación en la parametrización del servicio (archivo "wrapper.conf") para que el cambio se aplicado primero se deberá desinstalar el servicio como lo explica este punto y luego volver a instalarlo según lo indicado en el punto anterior.
9.2.2.2 Servicio de Linux
Para lograr que la aplicación inicie cuando el servidor Linux inicia es necesario configurar un servicio en Linux, estos servicios son llamados Daemons.
Este procedimiento describe como crear un Daemon en Linux basado en la distribución Debian o que manejen el procedo iniciador denominado init (proceso que se ejecuta ni bien termina de cargar el Kernel del SO).
9.2.2.2.1 Creación de Daemon
El procedimiento para crear un Daemon se detalla a continuación:
- Instalar o detener la aplicación RSVTOL.
- Cambiar a usuario "root". Es necesario ser "root" para poder crear un daemon. Ejecutar el comando:
su root
3. Situarse en el directorio
cd /etc/init.d/
4. Ejecutar el siguiente comando para crear un enlace (puente a un fichero)
ln -s Jboss/rsvtol/bin/start.sh /etc/init.d/vtol.d
5. Verificar que la aplicación funciona ejecutando. Esto se puede hacer accediendo a la consola WEB y/o verificando el log del sistema. Ejecutar:
./vtol.d
6. Registrar el daemon en los run level. Ejecutar el siguiente comando:
update-rc.d vtol.d defaults
7. Reinicar el servidor Linux. Ejecutar el siguiente comando o reiniciar desde consola/escritorio.
shutdown -r now
8. Una vez que haya reiniciado el servidor Linux, verificar que el daemon se haya ejecutado. Esto se puede hacer accediendo a la consola WEB y/o verificando el log del sistema.
9.2.2.2.2 Detener la aplicación
Para poder detener la aplicación cuando esta es iniciada por un Daemon es necesario seguir los siguientes pasos:
- Loguearse como root.
Su root
2. Situarse en el directorio:
cd Jboss/rsvtol/bin
3. Ejecutar el comando para detener la aplicación.
./stop.sh
9.2.2.2.3 Eliminación del Daemon
En caso de querer eliminar el Daemon seguir los siguientes pasos:
- Loguerase como root
su root
2. Ubicarse en el directorio:
cd /etc/init.d/
3. Ejecutar el siguiente comando para des-registrar el daemon
update-rc.d -f vtol.d remove
4. Eliminar el enlace creado con anterioridad.
rm vtol.d
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
La aplicación VTOL provee una consola WEB, por la cual se pueden realizar distintas funciones entre las cuales se destacan las más importantes:
- Administración de usuarios
- Administración de claves de encriptación de datos
- Configuración de reglas de negocio
- Generación de reportes
- Administración de alertas
- Acceso a pistas de auditoría
- Monitoreo
- Etc
Debido a las características inherentes a un servicio WEB, la administración del sistema se puede realizar de manera remota.
Para acceder a la consola WEB de VTOL se debe utilizar el siguiente enlace:
http://IP-SERVER:8080/rs-console
Donde IP-SERVER es la dirección IP o nombre del server donde se está ejecutando el servidor VTOL.
Este es el único acceso administrativo que la aplicación provee y al accederlo automáticamente se re-direcciona al puerto 8443 utilizando el protocolo HTTPS. Este protocolo es considerado seguro ya que encripta la comunicación entre el servidor y el explorador WEB utilizado. La encriptación sucede mediante un intercambio de llaves definido por el protocolo HTTPS.
Una vez realizado este intercambio, el explorador es re-dirigido a la siguiente URL:
https://IP-SERVER:8443/rs-console/frames/main.faces
Como se observa ya se utiliza HTTPS.
Definición: HTTPS, Hypertext Transfer Protocol Secure (ó HTTPS). Se emplea para lograr conexiones más seguras en la WWW, fundamentalmente para transacciones de pagos o cada vez que se intercambie información sensible (por ejemplo, claves) en Internet.De esta manera la información sensible, en el caso de ser interceptada por un ajeno, estará cifrada.
Para cumplir con el estándar PCI-DSS se utiliza un certificado como se indica en el punto 7.4 Instalación de certificado para protocolo HTTPS.
Nota |
---|
Nota: Si el usuario cambiara de protocolo de transmisión, la misma podría incumplir con la norma PCI-DSS. |
Âncora | ||||
---|---|---|---|---|
|
No podrán existir dos sesiones activas de un mismo usuario en páginas/navegadores paralelos.
Âncora | ||||
---|---|---|---|---|
|
A continuación se detallan una serie de pasos que se deben seguir cuando se trate de una instalación nueva luego de haber completado el capítulo "7.1.1 Instalación de cero de VTOL 3.8".
De tratarse de una re-instalación, este capítulo se puede omitir.
Âncora | ||||
---|---|---|---|---|
|
El sistema VTOL por defecto trae una cuenta de acceso a la consola de administración WEB que debe ser cambiada. Esto se efectúa ingresando a la consola de administración web por primera vez.
Para ingresar a la consola web referirse al capítulo 10. Acceso administrativo a VTOL.
Al ingresar por primera vez, como se indicó más arriba, el formulario de Login solicitará los datos de la cuenta por defecto, a saber:
- Nombre de usuario: suser
- Clave de acceso: suser123
Luego, el sistema pedirá ingresar un usuario nuevo y su contraseña. Este usuario nuevo pasará a tener los permisos necesarios para poder gestionar los usuarios del sistema y el usuario "suser" será eliminado del mismo.
Nota |
---|
Nota: Un usuario activo en la consola de administración no tiene permitido editar sus propios permisos. La asignación de permisos o de grupos lo deberá efectuar otro usuario con permisos de administrador. |
Las credenciales se registran en la tabla rs_user; el campo name almacena el nombre de usuario y el campo password la contraseña, la cual se encuentra encriptada con SHA-512.
Para conocer todas las opciones que se pueden realizar desde la consola de administración WEB, referirse a los manuales: "VTOL-CORE-Manual de usuario.pdf" y "VTOLCR-DB-Manual de usuario.pdf".
Nota |
---|
Nota: En la aplicación VTOL no existe el usuario administrador como tal, sino que se dice que un usuario tiene la capacidad de "administrador" cuando posee al menos todos los permisos que le posibilitan administrar el resto de las cuentas del sistema, como por ejemplo, agregar, editar y eliminar usuario y sus permisos. |
Los permisos mínimos que se requieren para ser considerado "administrador" son los siguientes:
1-"Acceso a la aplicación"
2-"Acceso a la consola de Administración de Usuarios, grupos y permisos"
3-"Creación, modificación y eliminación de usuarios, grupos y permisos"
Âncora | ||||
---|---|---|---|---|
|
En esta sección se presentan todas las variables de configuración de VTOL. Por cada variable se indica:
- su nombre
- tipo
- descripción
- y si el sistema debe o no ser reiniciado para que la modificación tenga efecto
Estas variables son configurables a través de la página de configuración presente en la consola de administración WEB del producto. Para ingresar a la misma referirse al capítulo 10. Acceso administrativo a VTOL.
Se debe disponer de los siguientes permisos:
- "Acceso Consola"
- "Configuración del sistema"
Una vez logueado en el sistema, se deberá ingresar dentro de "Herramientas Administrativas" a la opción "Configuración", tal como se muestra en la siguiente figura:
Pantalla de Configuración
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
La primera variable a configurar es la que se lista a continuación. La misma permite continuar la carga del sistema en su totalidad. De encontrarse en False, algunos de los componentes del sistema no podrán operar.
Propiedad | Tipo | Descripción | Requiere reiniciar? |
VTOL Core habilitado | True / false | De encontrarse en false, al iniciarse VTOL CR / DB no iniciarán las reglas de negocio pero sí la consola. Se emplea en los casos de actualización del sistema, cuando se incorporan nuevas propiedades de configuración a la aplicación. En este escenario la propiedad se encuentra en false y una vez que se terminaron de configurar las nuevas propiedades, se cambia su valor a true para que VTOL CR / DB inicie por completo. | NO |
A continuación se listan más propiedades disponibles para configurar en el sistema.
Propiedad | Tipo | Descripción | Requiere reiniciar? |
Dialecto de hibernate | Cadena de caracteres | Idioma de SQL usado por hibernate para comunicarse a la base de datos. | SI |
Timeout para eco | Entero | Tiempo de espera máximo en milisegundos para la recepción de la respuesta de un mensaje de eco. | NO |
Timeout para autorización | Entero | Tiempo de espera máximo en milisegundos para la recepción de la respuesta de una transacción de autorización. | NO |
Timeout para reverso | Entero | Tiempo de espera máximo en milisegundos para la recepción de la respuesta de un reverso. | NO |
Depuración información de operación de VTOL CR/DB habilitada | True / false | Habilita (true) / Deshabilita (false) la depuración de las transacciones de las tablas de operación de la aplicación. | NO |
Días conservación de información de operación de VTOL CR/DB | Entero | Cantidad de días que se desea mantener la información de transacciones en las tablas de operaciones antes de ser depuradas. | NO |
IP del CA XX XX hace referencia al nombre del centro autorizador. | Cadena de caracteres | Dirección IP del centro autorizador para la conexión #C4. En el caso de una instalación sin cluster, la configuracion corresponde a la que aparece con el nombre NODO 1. En caso de instalación con cluster, la configuracion dependerá de la cantidad de nodos del cluster. | SI |
Puerto de comunicación CA XX3 #C4 | Entero | Puerto del centro autorizador para la conexión #C4, por el cual se establecerá la comunicación. Para el caso de una instalación sin cluster, la configuracion corresponde a la que aparece con el nombre NODO 1. En caso de instalación con cluster, la configuracion dependerá de la cantidad de nodos del cluster. | SI |
Generación de interfaz por fecha habilitada | True / false | Indica si las interfaces se generan o no por fecha. | NO |
Puerto de comunicación no encriptada POS - VTOL | Entero | Puerto para la comunicación sin encriptar entre el POS y VTOL CR / DB. | SI |
Comunicación no encriptada POS - VTOL habilitada | True / false | Indica si se encuentra habilitada la comunicación no encriptada entre el POS y VTOL CR / DB. | SI |
Puerto de comunicación SSL/TLS POS - VTOL | Entero | Puerto para la comunicación SSL/TLS entre el POS y VTOL (3003). | SI |
Comunicación SSL/TLS POS - VTOL habilitada | True / false | Indica si se encuentra habilitada la comunicación SSL/TLS entre el POS y VTOL. | SI |
Almacén de certificados del servidor | Alfanumérico | Archivo que contiene los certificados del servidor para la comunicación segura SSL/TLS entre POS y VTOL. | NO |
Contraseña del almacén de certificados del servidor | Alfanumérico | Contraseña de acceso al archivo que contiene los certificados del servidor para la comunicación segura SSL/TLS entre POS y VTOL. | NO |
Almacén de confianza del servidor | Alfanumérico | Archivo que contiene los certificados de confianza del servidor para la comunicación segura SSL/TLS entre POS y VTOL. | NO |
Contraseña del almacén de confianza del servidor | Alfanumérico | Contraseña de acceso al archivo que contiene los certificados de confianza del servidor para la comunicación segura SSL/TLS entre POS y VTOL. | NO |
Adiciona contenido en log del sistema | True / false | Si se encuentra en false (desactivado), al reiniciarse VTOL se sobrescribirá el archivo log activo. Si se encuentra en true (activado), se continuará la escritura en el archivo log activo sin sobrescribir los contenidos previos. Esta configuración aplica al archivo log del sistema. | NO |
Tamaño máximo del log del sistema | Entero | Tamaño máximo del archivo de logueo. Superado este tamaño se crea un nuevo archivo. Esta configuración aplica al archivo log del sistema. | NO |
Tamaño máximo de índice del log del sistema | Entero | Cantidad de archivos de logueo que se mantienen. Superada esta cantidad, el nuevo archivo generado sobrescribirá al más antiguo. Esta configuración aplica al archivo log del sistema. | NO |
Timeout de respuesta de transacción | Entero | Tiempo de espera máximo en milisegundos para la recepción de la respuesta de la transacción. Se refiere a la respuesta que envía el módulo al componente Core de VTOL. | NO |
Largo del código de caja | Entero | Longitud del código que identifica a una caja (punto de venta) en VTOL CR / DB. Tener en cuenta que si el valor de esta propiedad se modifica existiendo ya cajas cargadas en la base de datos nodos, VTOL CR / DB no será capaz de identificar a las mismas. Una vez definida no se recomienda cambiarla. | NO |
Largo del código de local | Entero | Longitud del código que identifica a un local en VTOL CR / DB. Tener en cuenta que si el valor de esta propiedad se modifica existiendo ya locales cargados en la base de datos nodos, VTOL CR / DB no será capaz de identificar a los mismos. Una vez definida no se recomienda cambiarla. | NO |
Código de caja es numérico | True/ false | Indica si el código de caja es numérico (true) o alfanumérico (false) | NO |
Código de local es numérico | True / false | Indica si el código de local es numérico (true) o alfanumérico (false) | NO |
Umbral de inactividad de local | Numérico | Umbral, expresado en milisegundos, que indica el tiempo máximo tolerable sin que VTOL reciba transacciones de un local. Superado este umbral el local se considera inactivo. | NO |
Todos los números de comercio son requeridos | True/False | De encontrarse activado (true) indica que se requiere ingresar todos los números de comercio para cada local dado de alta. | NO |
MailManager Servidor SMTP | Cadena de caracteres | Dirección IP o nombre del servidor SMTP para envío de mails. | NO |
Deshabilitar búsqueda de TRX originales | True/False | De encontrarse activado (True) en una operación de Refund (Devolución) se comprobará si la fecha de la TRX original está en el rango válido | NO |
Fecha que limita la búsqueda de TRX Originales | Cadena de caracteres | Debe respetar el formato "dd/MM/yyyy" y sirve junto a la propiedad anterior para determinar si se debe o no buscar la TRX original. Si la propiedad anterior está en true y la fecha original es anterior a la configurada en esta propiedad, la trx original no debe buscarse en la BD. | NO |
JNDI Remoto | Cadena de caracteres | JNDI Remoto de la consola para obtener datos. | NO |
Timeout de transacciones off-line | Entero | Tiempo de espera máximo en milisegundos para la recepción de la respuesta de una transacción off-line. | NO |
Timeout de transacción de cierre | Entero | Tiempo de espera máximo en milisegundos para la recepción de la respuesta de una transacción de cierre. | NO |
Timeout de transacción batch upload | Entero | Tiempo de espera máximo en milisegundos para la recepción de la respuesta de una transacción de batch upload. | NO |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Para que el sistema sea seguro y cumpla con las normas PCI, es requisito mantener una correcta configuración de la depuración de los datos del sistema.
Debido a la importancia de una eliminación segura de los datos sensibles involucrados en una transacción con tarjeta de débito/crédito, el sistema VTOL dispone de un "proceso de ejecución automática", el cuál depura datos históricos que puedan existir en el sistema.
Se llama datos históricos, a las transacciones que VTOL va almacenando día a día en su base de datos. Los datos almacenados sirven para:
- Generación de reportes
- Validación de transacciones
- Conciliaciones de transacciones
- Etc
Aviso |
---|
Importante: El único dato sensible que se guarda es el PAN, ya que el resto (TrackI, TrackII, CVC, etc) son eliminados automáticamente por el sistema una vez finalizada la transacción. Solamente se almacena en la base de datos de VTOL y no en el sistema operativo. |
Nota |
---|
Nota: Cumpliendo con el objetivo de seguir la norma, el proceso de depuración se encuentra configurado por defecto con los valores sugeridos por PCI, por esta razón no es conveniente que el usuario utilice este proceso de forma manual, ya que saliendo de los parámetros definidos en VTOL, se estaría incumpliendo con las normas PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Para el borrado de datos históricos de la base de datos, existe un proceso de depuración configurable mediante la consola de administración de VTOL. La configuración que se encuentra definida por defecto en VTOL, será ejecutada automáticamente. Por defecto, este proceso se ejecuta una vez por día, durante todos los días, siempre y cuando esté activado.
Nota: Es requisito para cumplir con las normas PCI que este proceso se encuentre activo.
De igual manera, desde la consola de administración, el usuario tendrá la posibilidad de modificar los datos de dicha configuración.
El proceso permite la siguiente configuración:
- Días de conservación de la información
- Activación de la depuración
- Planificación de la ejecución en el tiempo
Âncora | ||||
---|---|---|---|---|
|
11.3.1.1 Días de conservación de información de operación de VTOL CR-DB
El usuario tendrá acceso a este ítem a través del menú "Herramientas administrativas", "Configuración".
La depuración automática debe estar habilitada y configurada bajo las normas PCI, para seguir con este cumplimiento, por defecto, VTOL conserva los datos por un máximo de 90 días. La cantidad de días de conservación puede ser redefinida según las necesidades del cliente.
Nota |
---|
Nota: Para cumplir con PCI DSS debe definirse un máximo de conservación de los datos. |
Esta configuración representa la cantidad de días hacia atrás que se quiere conservar la información en la base de datos, a partir del día de la fecha, por ejemplo, si se lo configura con el valor 100, entonces se logrará limpiar la base conservando los últimos 100 días de datos.
La alteración de estos valores de configuración deja registro de cuándo y quién lo cambió como un registro de auditoría de usuario.
En el caso que el usuario desee editar el máximo de días de conservación, deberá presionar la opción "Modificar" de la grilla, y el sistema mostrará en pantalla el formulario para su edición. Solo deberá ingresar la cantidad de días en "Valor Nuevo".
Âncora | ||||
---|---|---|---|---|
|
El usuario tendrá acceso a este ítem a través del menú "Herramientas administrativas", "Configuración".
Para cumplir con las normas PCI el ítem "Depuración información de operación de VTOL CR-DB habilitada" deberá tener el valor "true". En el caso que el usuario desee modificar este valor, deberá presionar la opción "Modificar" de la grilla.
El sistema mostrará en pantalla los valores que se muestran en la imagen, que podrán ser seleccionados por el usuario.
El valor de este parámetro indica si el proceso que se ejecuta todos los días y depurada la base de datos está activado o no.
Nota |
---|
Nota: El desactivar este proceso llevará a que la aplicación deje de ser compatible con PA DSS. |
Âncora | ||||
---|---|---|---|---|
|
La planificación del proceso de depuración de datos históricos permite cambiar el momento y la periodicidad de ejecución del mismo.
La configuración por defecto, ejecuta el proceso una vez por día, todos los días a la media noche.
El usuario tendrá acceso a este ítem a través del menú "Herramientas administrativas", "Planificación".
Debe modificarse el proceso "DataBaseMaintenanceJob", con el valor deseado (ver el botón ayuda para más información de cómo configurarlo).
Una vez seleccionado el ítem de la lista, el usuario debe presionar el botón "Buscar", el sistema pasará los datos del ítem seleccionado a la grilla.
Si el usuario desea modificar el valor del ítem "DataBaseMaintenanceProcess", deberá presionar el botón "Modificar", y el sistema mostrará en pantalla los datos para que el usuario modifique la configuración.
Nota |
---|
Nota: Una vez logrado el limpiado de los datos, los parámetros antes modificados deben ser vueltos a sus valores anteriores u originales para no alterar el normal funcionamiento de la aplicación, esto es debido a que la configuración por defecto es requerida para la depuración normal de la base de datos. Es de suma importancia que se cumpla con este proceso, ya que de otra forma no se estaría cumpliendo con los requerimientos de PA DSS y PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
La depuración incluirá la eliminación de datos de las siguientes tablas de la base de datos
- CreditDebitOperationRequest
- CreditDebitOperationResponse
- ClosedFinancialTransaction
- FinancialTransaction
Adicionalmente, se depura la tabla encargada de almacenar las claves de encriptación de los datos sensibles cuando ya no están en uso.
- EncryptedPassword
La depuración de las tablas se realiza de manera automática por el sistema. Por default, la depuración automática se ejecuta diariamente a las 12:00 hs.
Nota |
---|
Nota: Es importante remarcar que los datos serán borrados por el motor de base de datos utilizando sentencias inherentes al motor y a SQL, como por ejemplo: DELETE |
Nota |
---|
Nota: Además, para asegurarse de haber cumplido con los requisitos de PCI, borre los logs en modo debug de forma segura (17.2 Herramienta para el borrado seguro de datos). |
Âncora | ||||
---|---|---|---|---|
|
VTOL permite la administración de los siguientes usuarios y sus contraseñas:
- Administración de usuario para acceso administrativo WEB
- Administración de claves para el almacenamiento de datos sensibles.
A continuación se explicarán con más detalle cada una de las diferentes opciones.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Para el acceso a la consola de administración vía WEB, se debe poseer un usuario y una contraseña válidos y otorgados por el administrador del sistema.
Entonces para poder crear cuentas del sistema se debe:
- Iniciar sesión en la consola de administración web.
- El usuario debe tener los siguientes permisos
- "Acceso a la aplicación"
- "Acceso a la consola de Administración de Usuarios, grupos y roles"
- "Creación, modificación y eliminación de usuarios, grupos y permisos"
- Referirse al capítulo 10. Acceso administrativo a VTOL
- El usuario debe tener los siguientes permisos
- Ir a la sección "Seguridad Usuarios"
- Administrar las cuentas de usuarios
- Las mismas deben seguir las políticas señaladas en el anexo 17.1 Políticas generales de usuario y contraseñas
- A continuación se muestra una figura de la pantalla de administración de cuentas
Para más información sobre cómo realizar esta tarea, verificar los capítulos "
Âncora | ||||
---|---|---|---|---|
|
Nota |
---|
Nota: El sistema por defecto está configurado siguiendo las mejoras prácticas de la normas PCI. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
A partir del procesamiento de transacciones que hace VTOL, se van guardando datos sensibles de tarjetas en la base de datos (los datos y tablas participantes se pueden ver en la sección 14.1 Base de datos).
Estos datos son almacenados en la base de datos de forma encriptada utilizando algoritmos simétricos con llaves de encriptación donde la administración de las mismas es realizada automáticamente por el sistema.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Los datos se encriptan utilizando el algoritmo simétrico 3DES con llaves de 192bits.
Estos datos se encriptan con una jerarquía de llaves que se describe a continuación:
Existe una clave fija en el código de la aplicación. Con ésta se encripta una clave "Maestra" que reside en el sistema de archivos. Con la llave maestra se encripta la llave "operativa" y con ésta última se encriptan los datos sensibles que se guardan en la base de datos.
Clave | Lugar de residencia | Tipo generación |
Fija | Código | Fija |
Maestra | Sistema de archivos, carpeta VTOL_SECURITY. Se graba un archivo con nombre "master.key" | automática y aleatoriamente utilizando el generador nativo de Java denominado SecureRandom |
Operativa | Base de datos, tabla EncryptedPassword | automática y aleatoriamente utilizando el generador nativo de Java denominado SecureRandom |
El archivo "master.key" posee el siguiente formato:
Clave | valor | Comentario |
id | Numérico | referenciado en la tabla de operation key, EncryptedPassword |
key | Clave maestra | Llave "maestra" de encriptación 3DES encriptada con llave de encriptación fija por código. VALOR=función3DES("llave fija", "llave maestra") |
creator | Nombre de nodo | Nombre del nodo del cluster que creó la llave maestra |
creationDate | Fecha de creación | Fecha de creación de la llave maestra con formato yyyyMMddHHmmss |
Ejemplo de archivo "master.key":
#Master Key File
#Wed Dec 17 16:06:49 GMT-03:00 2014
creationDate=20141217160649
key=Nhg9K/JhOID4BGjpQ0X1hUrlr9O1ubGJqA+R0HrCXgk\=
creator=Node01
id=1418843209445
Nota |
---|
Nota: cada clave maestra nueva o cambio en la misma será distribuido automáticamente por la aplicación VTOL entre cada uno de los miembros del cluster utilizando el sistema de mensajería JMS propio del servidor de aplicaciones en cuestión. |
Âncora | ||||
---|---|---|---|---|
|
Funcionalmente la aplicación posee los siguientes mecanismos donde se realiza alguna gestión de las claves de encriptación:
- Administración automática por el sistema en operatoria normal
- Administración forzada por un custodio
- Administración forzada por un custodio usando la herramienta de renovación de material criptográfico.
Un custodio es un usuario del sistema VTOL que tiene los permisos de administrar las claves de encriptación.
Nota |
---|
Nota: La norma PCI recomienda la existencia de uno o más custodios encargados de administrar las claves del sistema. |
12.2.2.1 Administración automática por el sistema en operatoria normal
El sistema VTOL, en condiciones normales se encarga automáticamente de la gestión de las llaves.
Esto se puede observar en el siguiente gráfico:
Por defecto (en una instalación desde cero) el sistema no cuenta ni con la llave maestra ni con la llave operativa. Entonces, al iniciar, el sistema se encarga de crear automáticamente la llave Maestra y la llave Operativa. Para su generación se base en el uso de generador de llaves SecureRandom nativo de Java.
Una vez que el sistema posee las llaves creadas ya puede procesar transacciones y encriptar los datos sensibles que se guardarán en la base de datos como se mencionó anteriormente.
Las claves poseen una vigencia, es decir, que luego de 90 días de uso éstas deben ser renovadas para garantizar la seguridad del sistema. Esta renovación se realiza automáticamente por el sistema. El sistema verifica diariamente si las llaves aún son vigentes, si no lo son se vuelven a generar y automáticamente quedan en uso por el sistema.
Esto se puede apreciar en el gráfico anterior.
Nota |
---|
Nota: Si bien el proceso de administración de claves de encriptación es automático, en ciertas ocasiones (por ejemplo, puesta en compromiso de la seguridad de la base de datos, del sistema, renovación de personal afín de la seguridad del sistema, etc) puede ser necesario el forzado de la renovación del material criptográfico. Esto se explicará en las siguientes secciones. |
Âncora | ||||
---|---|---|---|---|
|
Si bien el sistema se encarga de administrar las claves de encriptación automáticamente, hay casos donde puede ser necesario forzar la generación de claves de encriptación nuevas. Esta generación también es automática y difiere con la operatoria normal en que no es lanzado por un vencimiento sino forzado un custodia.
Algunos de los casos donde esto puede ocurrir son los siguientes:
- El custodia deja de ser efectivo en la empresa
- El custodia deja o cambia de puesto dentro de la empresa
- Etc
Nota |
---|
Nota: El anexo "17.8 Formulario de Clave Custodio de VTOL" proporciona el formulario de custodio para que se reconozca que entienden y aceptan sus responsabilidades. |
A continuación se describe el procedimiento para forzar la creación de claves de encriptación nuevas
- Acceder a la consola de administración web. Para mayor referencia ver 10. Acceso administrativo a VTOL
- Acceder a la opción "Herramientas administrativas" "Claves de Encriptación" como se muestra en la figura:
- Los permisos que se requieren a nivel sistema VTOL son los siguientes:
- "Acceso a la administración de contraseñas encriptadas"
- "Agregar una nueva contraseña encriptada"
- Los permisos que se requieren a nivel sistema VTOL son los siguientes:
Nota |
---|
Nota: La foto es ilustrativa. El usuario puede no tener algún permiso por lo que verá más o menos entradas en el menú. |
3. El sistema presentará la siguiente pantalla:
4. Presionar el botón "crear".
5. El sistema habrá generado las claves de encriptación nuevas que serán utilizadas por VTOL.
Nota |
---|
Nota: Cuando se genera una nueva clave de encripción, se genera un registro de auditoría en la tabla rs_audit de la base de datos. Para más información, ver el apartado 13.2 Auditoría en base de datos. |
12.2.2.3 Administración forzada por un custodio usando la herramienta de renovación de material criptográfico
Si bien el sistema se encarga de administrar las claves de encriptación automáticamente, hay casos donde puede ser necesario forzar la generación de claves de encriptación nuevas. Esta generación también es automática y difiere con la operatoria normal en que no es lanzado por un vencimiento sino forzado un custodio.
Algunos de los casos donde esto puede ocurrir son los siguientes:
- Se puso en compromiso la seguridad de la base de datos
- Se requiere renovar el material criptográfico de la aplicación
- Se está haciendo una re-instalación de la aplicación
- Se está pasando de laboratorio a producción
- Etc
Llegado el caso de que éste procedimiento sea necesario, entonces referirse a la guía detallada "VTOLCR-DB-Manual de actualización de material criptográfico.pdf".
A modo de resumen, se utilizará una herramienta suministrada por la aplicación llamada "CyptTool" que se ejecuta por línea de comando cuando VTOL está detenido o apagado.
La herramienta solicitará las credenciales del custodio y a continuación renovará todo el material criptográfico de la aplicación, esto es:
- Generación de clave maestra nueva
- Generación de clave operativa nueva
- Re-encriptación de todos los datos del sistema encriptados previamente utilizando las claves nuevas recientemente creadas.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Durante el funcionamiento del sistema se generan registros o eventos de auditoría.
El sistema genera éstos registros en 2 lugares a saber:
- Sistemas de archivos
- Base de datos
Los logs de auditoría de un usuario están habilitados por defecto. Los logs no se deben desactivar, hacerlo resultará un incumplimiento de PCI DSS.
Todas las acciones administrativas se registran en la tabla de bases de datos RS_AUDIT, los campos de la tabla RS_AUDIT se mencionan en la sección "Formato 13.2.1".
Los pasos para configurar los objetos de nivel de sistema se mencionan en las secciones "17.7.2 Registros de auditoría" y "17.7.3 Auditoría de base de datos".
Para el cumplimiento de las normas PCI se recomienda que éstos registros, que genera la aplicación, se centralicen en un sistema concentrador de logs, permitiendo a administradores y auditores el monitoreo centralizado de eventos y la rápida detección de eventos que pueden afectar la operatoria o seguridad de la aplicación.
A continuación se da más detalle del formato en que la aplicación genera éstos registros y se instruye como implementar la centralización.
Nota: VTOL no audita el borrado de archivos de log o de los registros de auditoría de la base de datos cuando se hace por fuera de la aplicación, como ser a través del sistema operativo o del motor de base de datos. Por lo tanto, la auditoría de estos eventos queda bajo responsabilidad del cliente. Para mayor referencia de las características de auditoría que se deben activar en los sistemas referirse a 7.5 Configuración de auditoría de software base
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Cuando la aplicación VTOL se encuentra activa va generando pistas de log en un archivo de texto. De ahora en más este archivo se denominará "archivo de log".
Una vez instalada la aplicación, por defecto el archivo de log se creará en:
Jboss/rsvtol/log
De requerir cambiar la ubicación de logueo de la aplicación editar el siguiente archivo:
rsvtol/deployments/rs-vtol.ear/META-INF/log4j.xml
Dentro de este archivo de configuración editar la siguiente propiedad:
<param name="File" value=" ${jboss.server.log.dir}/server.log"/>
Donde:
- rsvtol indica el path donde está instalado el Jboss
- ${jboss.server.log.dir} indica el path completo del Jboss donde se instaló VTOL.
Âncora | ||||
---|---|---|---|---|
|
Nota |
---|
Nota: Des-habilitar el logueo de la aplicación incumple con las normas PCI-DSS. |
Âncora | ||||
---|---|---|---|---|
|
Los archivos tendrán el nombre:
server.log o server.log.X
Donde X es el número de rotación del archivo de logueo. Cuando llega a un máximo de MegaBytes se van rotando e incrementando este número hasta un máximo, luego se eliminan los más antiguos.
Los archivos de log tienen el siguiente formato:
Wiki Markup |
---|
yyyyMMdd HH:mm:ss,SSS LLLLL \[component\] \[Thread_name\] description |
Donde:
- "yyyy" corresponde al año
- "MM" corresponde al mes
- "dd" corresponde al día
- "HH" corresponde a la hora formato 24hs
- "ss" corresponde a los segundos
- "SSS" corresponde a los milisegundos
- "LLLL" a la prioridad de logeo. Valores posibles
- DEBUG: Muestra información más detallada de los procesos, sin contener datos sensibles
- INFO: Muestra información general del funcionamiento de los procesos
- ERROR: Informa un error manejado dentro de la aplicación
- FATAL: Advierte de estados o errores que no tienen incidencia al funcionamiento de la aplicación
- WARN: Advierte sobre estados indebidos dentro de la aplicación
- "component" corresponde al componente interno de la aplicación que efectúa el logueo
- "thread_name" corresponde al nombre y/o número de hilo que se está ejecutando
- "description" corresponde la descripción del evento que está ocurriendo.
A continuación se da un ejemplo:
2014-10-10 13:44:16,351
DEBUG vtol
ReverseSenderProcess #Reverse: 0 Excluded terminals in process: []
2014-10-10
13:44:17,126 INFO communication RSFMK.AsyncCommWorker-4 CrDb
Thread: RSFMK.AsyncCommWorker-4: MONITOR: DISCONNECTED
2014-10-10
13:44:17,205 INFO communication RSFMK.AsyncCommWorker-2 CrDb
Thread: RSFMK.AsyncCommWorker-2: MONITOR: DISCONNECTED
2014-10-10
13:44:17,220 INFO communication RSFMK.AsyncCommWorker-1 CrDb
Thread: RSFMK.AsyncCommWorker-1: MONITOR: DISCONNECTED
2014-10-10
13:44:17,266 INFO communication Temp_RSFMK.AsyncCommWorker-2 CrDb
Thread: Temp_RSFMK.AsyncCommWorker-2: MONITOR: DISCONNECTED
2014-10-10
13:44:17,266 INFO communication RSFMK.AsyncCommWorker-3 CrDb
Thread: RSFMK.AsyncCommWorker-3: MONITOR: DISCONNECTED
2014-10-10
13:44:17,376 INFO communication Temp_RSFMK.AsyncCommWorker-1 CrDb
Thread: Temp_RSFMK.AsyncCommWorker-1: MONITOR: DISCONNECTED
2014-10-10
13:44:17,376 INFO communication
RSFMK.AsyncCommWorker-5 CrDb Thread: RSFMK.AsyncCommWorker-5: MONITOR:
DISCONNECTED
2014-10-10
13:44:18,139 ERROR communication
RSFMK.AsyncCommWorker-4 Connect failed:
ProvencredClientCommunication(127.0.0.1:66660). Retry is set forever. Error
Message: Connection refused: connect
Âncora | ||||
---|---|---|---|---|
|
La aplicación almacena el log de auditoría en la base de datos en formato aceptable universal. Las herramientas centralizadas se pueden configurar para buscar el log de la base de datos. También se registran objetos de nivel de sistema en el evento Windows.
Los pasos para configurar los objetos de nivel de sistema se mencionan en las secciones "17.7.2 Registro de auditoría" y "17.7.3 Auditoría de base de datos".
Nota |
---|
Nota: Es importante la centralización de los eventos y auditoria para el cumplimiento dela norma PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Por razones de seguridad, todo acceso y/o acción efectuada por un usuario en la consola de administración web de VTOL produce registros de auditoria en la tabla RS_AUDIT de la base de datos actual de VTOL.
Por medio de esta funcionalidad es posible conocer qué operaciones fueron efectuadas, fecha y hora de su realización, así como también los usuarios que las realizaron y donde se originó el evento.
Âncora | ||||
---|---|---|---|---|
|
La tabla RS_AUDIT posee la siguiente información con el siguiente formato:
Campo | Tipo | Descripción |
audit_event_id | Entero | Clave primaria del registro |
date_time | Fecha y hora | Fecha y hora |
logon_name | Caracteres(50) | Nombre de usuario que efectuó la acción |
description | Texto(variable) | Descripción detallada del evento |
hostAddress | Caracteres(50) | Dirección IP desde donde se realizó la acción que generó el evento |
hostName | Caracteres(100) | Dirección lógica desde donde se realizó la acción que generó el evento |
state | Caracteres(20) | Si la acción que generó el evento se debe a una acción correcta o fallida. Valores posibles:
|
details | Texto(variable) | Detalle de la acción únicamente cuando state="FAIL" |
type | Caracteres(16) | Tipo de evento. Valores posibles:
|
source | Caracteres(64) | Fuente que produjo el evento |
Âncora | ||||
---|---|---|---|---|
|
La centralización de la información de ésta tabla está sujeta a las herramientas que dispone el cliente.
Una opción posible es la activación de un "trigger por inserción" de base de datos que actúa cuando el sistema graba un registro nuevo en la tabla. Por medio de éste trigger se puede enviar el detalle del registro.
Los registros que son más importantes desde el punto de vista de la seguridad son los siguientes:
Campo | Valor a observar | Descripción | |
Type | Error | Todos los registros del tipo error pueden significar un riesgo para la aplicación. Se recomienda el análisis del resto de los campos que ofrece el registro de auditoría. | |
Type | Warning | Los registros Warning, no necesariamente son errores, pero pueden significar un intento de ataque a la aplicación. Se recomienda el análisis del resto de los campos que ofrece el registro de auditoría. | |
State | Fail | El estado de falla significa que la acción llevada por el usuario terminó fallando, por lo tanto es importante evaluar éstos registros para detectar posibles operaciones no permitidas por distintos usuarios. | |
Source | VTOL CD Console - Report | Son los eventos de usuarios que acceden a los reportes de transacciones de la aplicación. Es importante registrar éstos eventos e incluso analizar si es correcto que el usuario señalado pueda acceder a dicho módulo. | |
Source | Security | Los eventos provenientes del módulo de seguridad tienen que ver con la actividad de la administración de usuarios: creación, edición, eliminación asignación de roles, etc, sobre los usuario con acceso a la consola de administración web de VTOL. | |
Source | Framework - JBossMod | Los eventos provenientes del módulo del JBOSS tienen que ver con la actividad de inicio de sesión, error de inicio de sesión, cambios de perfil de un usuario, etc. Es importante monitorear éstos registros para evitar accesos no deseados al sistema. | |
Source | Audit | Eventos de la actividad de usuario sobre la pantalla de acceso a los registros de auditoría. | |
logon_name | zzzzzz | Donde zzzz pude ser un acceso de un usuario no deseado al sistema. Se recomienda analizar caracteres inválidos o caracteres usualmente utilizados para ataques como ser SQL inyection, code inyection, JS, etc. Por ejemplo "{_}'"\'\"); | ]*{{_}" |
logon_name | htixsnob (unknown user) | Donde xxxx. Por ejemplo "-1' or '67'='67 (unknown user)" | |
Description | Login Failed | Indica el login fallido de un usuario. Este registro puede ser normal, pero en ciertos casos, como cuando ocurren en cortos período de tiempos, pueden indicar el intento de acceso a la aplicación sin poermisos. | |
Description | User 'uuu' created. | Donde 'uuu' es el usuario creado. | |
Description | iiiiiii | Donde 'iiii' es la descripción. | |
Description | Audit info requested. | Evento que indica que un usuario solicitó información sobre la página de auditoria. | |
Description | Error processing the following request URI: uuu | Donde 'uuu' es la URL de la aplicación. | |
Description | Account not enabled | Evento que indica que un usuario intentó iniciar sesión en la consola de administración web y la cuenta no estaba habilitada. |
Nota |
---|
Nota: Es importante la centralización de los eventos y auditoria para el cumplimiento dela norma PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
La presente sección tiene la intención de comunicar al usuario/administrador de la aplicación los lugares donde VTOL puede o almacena información sensible de tarjetas.
A modo de resumen, esto se hace en:
- Base de datos
- Archivos de logs
- Reporte de transacciones
Nota |
---|
Nota: La aplicación únicamente almacena información sensible en los lugares indicados en éste apartado. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
El sistema registra información de tarjetas en su base de datos. Estos datos se almacenan encriptados utilizando el mecanismo de encriptación descripto en la sección 12.2.1 Descripción técnica de la encriptación de datos
Todos los datos sensible de las tarjetas que se detallan a continuación son almacenadas de forma encriptada utilizando el algoritmo de encriptación Triple DES o 3DES con clave de encripción administrable automáticamente por el sistema (no requiere intervención del usuario).
Aviso |
---|
Importante: Si un dato es temporal significa que será eliminado automáticamente por VTOL al finalizar la transacción. |
Si no es un dato temporal, el número de la tarjeta enmascarada y la fecha de caducidad, permanecerá en la base de datos hasta que el proceso de depuración automático no lo depure (máximo de 90 días, período de retención definido por el cliente). Para saber cómo configurar el proceso completo, visite el punto "11.3 Configuración para la depuración de datos".
El tiempo de espera y los datos de transacción fallidos se eliminan mediante un script que se ejecuta cada 5 segundos.
Tabla | Campos | Temporal |
CreditDebitOperationRequest | cardNumber | NO |
| expirationDate | NO |
| cvc | SI |
| track1 | SI |
| track2 | SI |
| chipTockens | SI |
FinancialTransaction | expirationDate | NO |
| cardNumber | NO |
ClosedFinancialTransaction | expirationDate | NO |
| cardNumber | NO |
EMVAdviceEntry | chipTockens | SI |
Nota |
---|
Nota: Es muy importante que no se deba almacenar datos de titulares de tarjetas en sistemas a los que se pueda acceder desde Internet (por ejemplo, el servidor web y el servidor de la base de datos no deben estar en el mismo servidor). Cualquier incumplimiento de uno de los puntos podría invalidar el cumplimiento de PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
El archivo de log de la aplicación VTOL no almacena datos sensibles de tarjetas. Lo único que almacena es el número de tarjeta de forma enmascarada según norma PCI (primero 6 y últimos 4 dígitos en texto plano).
En ciertas ocasiones de soporte técnico, es necesario activar el modo DEBUG de la aplicación que sí almacena datos sensibles de la tarjeta como ser PAN, CVC, TRACKS, etc.
Estos datos son guardados de forma encriptada utilizando 3DES y podrán ser desencriptados únicamente por personal calificado de servicios de atención a del cliente de Synthesis Retail Solutions. Para mayor información acerca del proceso, referirse a 15. Guía de resolución de problemas, especialmente en la sección 15.3 Activación del modo DEBUG.
Nota |
---|
Nota: En caso de activar el modo DEBUG se recomienda realizar el borrado seguro utilizando las herramientas suministradas junto con la aplicación. Para mayor información referirse a 17.2 Herramienta para el borrado seguro de datos. |
Âncora | ||||
---|---|---|---|---|
|
Desde la consola de administración web de VTOL se puede acceder a la generación de reportes de transacciones, sin embargo, estos reportes no visualizan ningún tipo de información sensible de tarjetas más allá de número de PAN que se encuentra enmascarado según normas PCI (primero 6 y últimos 4 dígitos en texto plano), estos reportes se pueden exportar.
VTOL oculta el PAN de forma de forma predeterminada en todas las vistas, sin embargo, un usuario con los siguientes permisos pudiera acceder a información sensible de las tarjetas a través del "reporte de movimiento de tarjetas":
- "Acceso a la aplicación"
- "Acceso al reporte de movimientos de tarjetas"
- "Acceso a los reportes del módulo CR-DB con visualización de números de tarjetas de créditos"
Nota |
---|
Nota: Para instrucciones de cómo asignar permisos a un usuario, por favor dirigirse al apartado "Seguridad" del documento "VTOL-CORE-Manual de usuario.pdf". |
Teniendo dicho acceso un usuario puede acceder al número completo del PAN de las tarjetas que se listen en el reporte, pero el sistema limitará automáticamente el resultado hasta un máximo de 5 registros e in-habilitará la exportación del reporte a otro formato de archivo (EXCEL, CSV, PDF, etc). Están características están enfocadas en garantizar la seguridad del sistema.
Esta característica está orientada a la búsqueda de transacciones en ocasiones donde existe un reclamo de un cliente o una entidad financiera y no se pueda resolver utilizando los reportes de manera normal.
Aviso |
---|
Importante: Se recomienda fuertemente, y es responsabilidad del cliente, tomar las medidas de seguridad apropiadas para evitar el envío de datos sensibles a través de mensajería de usuario final (por ejemplo: mensaje de texto, mail, etc). En caso de que esto sea necesario deberá cifrar (utilizando algoritmos de encriptación robustos) u ofuscar el contenido o el documento entero antes del envío. |
Nota |
---|
Nota: Se recomienda que los permisos otorgados al usuario para acceder a información sensible sean otorgados por un lapso de tiempo acotado para garantizar la seguridad del sistema. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
En caso de que se presente un problema en la aplicación VTOL se deberá seguir el procedimiento descrito en éste capítulo.
Âncora | ||||
---|---|---|---|---|
|
Para la resolución de incidentes en VTOL, la aplicación genera un archivo de log. En él se van registrando las transacciones que se procesan en el sistema junto con el detalle de las decisiones que tomó el sistema.
Entonces para efectuar cualquier tipo de diagnóstico sobre la aplicación, se recomienda acceder a éste archivo.
Para saber cómo localizar el archivo de log referirse a 13.1 Archivos de log.
Tener en cuenta que la locación del archivo de log está restringida a ciertos usuarios. Si usted no cuenta con un usuario del sistema operativo válido contáctese con el administrar de sistemas.
Nota |
---|
Nota: Es importante resaltar que el acceso y la recolección de los logs se debe limitar solo cuando exista algún problema en la aplicación y que si fuese necesario acceder a dicha información, solo se utilice la información mínima y necesaria para solución el problema. En funcionamiento normal de la aplicación no se registran datos sensibles. |
Âncora | ||||
---|---|---|---|---|
|
A continuación se detalla el procedimiento que se debe seguir en caso de requerir analizar/diagnosticar/soluciones un inconveniente.
A modo de resumen, un operador analiza el archivo de log de VTOL. Si puede diagnosticar el problema, aplica solución.
Si no puede se contacta con atención al cliente de Synthesis Retail Solutions.
Un técnico especializado tratará de diagnosticar el problema y brindar una solución. Si no puede solicitará el envío del archivo de log al SFTP de Synthesis. Con éste archivo analizará con más detalle y el problema. Si puede solucionarlo, brindará la solución. Si no puede y cree necesario, puede requerir la activación del modo debug (referirse a 15.3 Activación del modo DEBUG) y enviar el log nuevamente. Ya con el archivo de log en DEBUG y la información previamente recolectada procede al diagnóstico del problema y brinda una solución. Si no pudiera solucionar el problema, entonces internamente se elevará un ticket a soporte de producto para su posterior resolución.
Considerar que:
- Los archivos de logs son generados según la configuración de 13.1 Archivo de log
- Los usuarios que podrán acceder a dicha carpeta deben tener permisos como se indica en "usuarios del sistema operativo" o bien contactar al administrador de sistemas
- El SFTP de Synthesis están en la dirección IP 200.59.130.99 puerto 22. El usuario y contraseña de acceso al mismo serán suministradas una vez establezca contacto con Servicios al Cliente al igual que el periodo de validez del mismo.
Nota |
---|
Nota: Es importante destacar que en funcionamiento normal del sistema no es necesario acceder a los archivos de logs y que además estos no generan ningún tipo de información sensible. Cuando si sea necesario accederlos se recomienda que la recolección de información sea la mínima y necesaria para resolver el problema con fin de garantizar la seguridad del sistema y el cumplimiento de las normas PCI DSS. |
Aviso |
---|
IMPORTANTE: Inmediatamente después de finalizar el diagnóstico del problema es necesario efectuar el borrado seguro de los archivo de logs de la aplicación utilizando las herramientas de borrado seguro suministradas junto a la entrega de la aplicación VTOL con el fin de garantizar la seguridad del sistema y el cumplimiento de las normas PCI DSS. Para mayor información referirse al anexo 17.2 Herramienta para el borrado seguro de datos. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
En el caso de que NO se pueda detectar el problema por medio de la lectura del archivo de logueo de la aplicación, puede ser necesario habilitar el modo "DEBUG" por el cual la aplicación comenzará a registrar líneas adicionales de logueo de manera encriptada que servirán para brindar más información a la hora de analizar el inconveniente y cuando sea necesario resolver un problema específico.
Este modo debe activarse solo en caso de que Servicios al Cliente de Synthesis así lo indique, por ejemplo:
- Datos inválidos
- Error de lectura de tarjeta
- etc
Nota |
---|
Nota: Es importante remarcar que en este modo se cifra todo el mensaje, no solo los datos de información sensible. |
El procedimiento para llevar a cabo tal acción es el siguiente:
- Un usuario con los siguiente permisos accede a la consola de administración web de VTOL
- "Acceso a la aplicación"
- "Configuración del sistema"
- Configurar la aplicación para que comience a loguear información sensible encriptada. Para ello se deberá acceder a la sección Herramientas administrativas > Configuración y habilitar (colocar en true) el parámetro 'Habilitación del logueo de información sensible' como muestra la siguiente figura:
3. Una vez realizado el punto 1, la aplicación comenzará a loguear de manera encriptada para las próximas 8 transacciones o durante 20 minutos, lo que se cumpla primero. El archivo que registrará esta información será "server_DEBUG.log".
4. Se debe recolectar el archivo de log que contiene todos los datos enviado por el POS hacia VTOL, de VTOL al CA, del CA a VTOL y de VTOL al POS. Entre ellos podemos encontrar los siguientes:
- PAN
- Track I
- Track II
- CVC
- Fecha de expiración
- Importe
- Cuotas
- Plan
- Tienda
- Terminal
- Moneda, etc
Por defecto, el archivo de log en Debug será creado en el directorio:
Jboss/rsvtol/log
Para mayor información de donde se encuentra el archivo de log ver 13.1 Archivos de log.
El log debe ser almacenado en el lugar específico mencionado y debe tener acceso limitado, que será otorgado por el cliente.
5. Luego el cliente deberá contactarse con el Especialista de Synthesis, que lo guiará para proceder al envío del log de manera segura al SFTP, provisto por Synthesis.
6. Una vez finalizado el envío del log al SFTP de Synthesis, se deberá dejar la aplicación sin loguear información sensible. Para ello, se deberá deshabilitar el parámetro (colocar en false) 'Habilitación del logueo de información sensible' de forma inversa al punto 1 (si en el análisis se alcanzaron a ejecutar 8 transacciones o los 20 minutos, la deshabilitación será realizada automáticamente y este paso podrá omitirse). El log debug reúne sólo una cantidad limitada de datos necesarios para resolver un problema específico.
7. Por último es muy importante borrar los logs de modo seguro (ver sección del manual 17.2 Herramienta para el borrado seguro de datos.).
Nota |
---|
Nota: Es importante remarcar que si el logueo no es el indicado en el manual la aplicación incumplirá con PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
A modo de resumen se da una lista de todas las consideraciones a tener en cuenta, en lo que refiere a la configuración de VTOL, para que el producto este de acuerdo a las normas de seguridad PCI:
- Limpiado de datos históricos de versiones no PCI.
- Tratamiento de problemas:
- Recolección de datos solo cuando sea indispensable
- Almacenamiento de información con acceso restringido
- Recolección solo de información imprescindible
- Mantener información encriptada
- Borrar en forma segura la data recolectada
- Mantenimiento y borrado del material criptográfico (proceso automático)
- Creación de usuarios únicos, no compartidos.
- Autenticación segura: validación en el ingreso de contraseñas.
- Creación de contraseñas alfanuméricas de 7 caracteres
- Tiempo de vida de contraseñas no mayor a 90 días
- Mantener un histórico de contraseñas de 4 valores como mínimo.
- Expiración de sesión después de 15 minutos de inactividad.
- No usar cuentas administrativas predeterminadas.
- Uso de contraseñas acordes con 3DES (24 caracteres, con patrones de 8 no repetidos).
- Mantener deshabilitadas las consolas de administración propias del servidor de aplicaciones (WEB-console y JMX-console)
- Implementación de firewall para entornos inalámbricos.
- Usar DMZ cuando la aplicación sea accedida desde Internet.
- Utilizar autenticación de dos factores si se decide implementar el acceso remoto a la aplicación
- Tomar recaudos al enviar información sensible por medios públicos (IPSEC, VPN o SSL/TLS).
- Usar canales encriptados para el envío de información de tarjetas por redes públicas.
- Usar solo protocolos seguros para el acceso administrativo remoto (HTTPS)
- Revisiones anuales de actualización y mantenimiento, sobre el sistema y documentación con el objetivo de que sean consistentes con el producto y con los requerimientos requeridos por PCI.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Para el cumplimiento de las normas PCI se recomienda el cumplimiento de las siguientes políticas de usuario y contraseñas en el sistema tanto para la aplicación VTOL como para el resto de los sistemas intervinientes, como ser base de datos, sistema operativo, etc.
Configuración de usuarios:
- Características Usuarios
- Los usuarios creados en el sistema deben ser individuales y no compartibles entre ellos.
- Los usuarios deben utilizar una contraseña para su autenticación en el sistema. La misma debe cumplir con las características abajo mencionadas.
- El usuario utilizado no sea el creado por defecto por el sistema operativo (Ej: administrador, admin, sa, root, etc).
- Características contraseñas
- Las contraseñas de usuario deben tener una vigencia de 90 días como máximo permitidos por PCI. De esta manera el sistema obligará al usuario a cambiar la contraseña al menos una vez cada dicho período.
- La contraseña debe tener un mínimo de 7 (siete) caracteres,
- Debe ser alfanumérica; compuesta por letras y números (por lo menos un carácter y un número y puede incluir caracteres especiales).
- Características funcionales (cuando apliquen)
- La cantidad de reintentos de logueo fallidos permitidos es un máximo de 6 (seis). En caso de alcanzar esta cantidad el usuario quedará bloqueado y no podrá acceder al sistema. La habilitación del acceso al sistema deberá ser realizado por un usuario con los privilegios de administrador de usuarios.
- La configuración del tiempo de expiración de sesión de un usuario, la cual se realiza desde el lado del servidor, deberá tener un valor máximo de 15 minutos.
- Las contraseñas que se creen luego su expiración, no deberán coincidir con las 4 últimas creadas.
- Las contraseñas deben de ser almacenadas de forma segura utilizando un algoritmo de encriptación fuerte con el fin de que su almacenamiento sea ilegible.
- Los usuarios que dejen de estar en uso (cambio de puesto, no trabaja más en la empresa, periodo de inactividad, etc) deben de ser deshabilitados tanto por el administrador o automáticamente por el sistema.
Nota |
---|
Nota: Si la configuración difiere de lo especificado anteriormente, se incumplirá con PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Como complemento de la aplicación VTOL, se utilizará una herramienta que se encarga de realizar el borrado seguro de datos que se hayan almacenado en el sistema de archivos del sistema operativo.
Dependiendo del sistema operativo en el que esté instalado el sistema o se esté trabajando utilizar:
- en sistemas Linux: "Manual Borrado Seguro Linux.pdf"
- en sistemas Windows: "Manual Borrado Seguro Windows.pdf"
La herramienta se utiliza con el fin de complementar el sistema VTOL en la eliminación de datos sensibles que puedan surgir de su utilización, como CVC, PIN, PAN, etc.
La utilización de ésta herramienta sirve para cumplir con las normas PCI DSS en cuanto al borrado de datos sensibles.
Nota |
---|
Nota: Consulte los documentos "Manual Borrado Seguro" que se informaron anteriormente para realizar el proceso de borrado seguro. Además, estos documentos contienen instrucciones para eliminar de manera segura los datos del titular de la tarjeta cuando ya no se requieren por fines legales, reglamentarios o comerciales. Si la herramienta de borrado seguro no fuera utilizada en forma conjunta con VTOL, se puede invalidar el cumplimiento de PCI DSS. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
La aplicación VTOL posee unos archivos de texto plano denominados "ChangeLog.txt". Por medio de estos archivos se puede acceder mediante cualquier editor de texto y conocer:
- Cómo se cambió el número de versión
- La versión instalada de VTOL y sus componentes
- Las actualizaciones efectuadas en la aplicación
- El detalle de los cambios realizados y el impacto ocasionado entre versión y versión
El "ChangeLog" de VTOL CORE es el siguiente:
Jboss/rsvtol/dist/config/ChangeLog.txt
El "ChangeLog" del Módulo Crédito Débito es el siguiente:
Jboss/rsvtol/dist/config/modules/cd-mx/ChangeLog.txt
Ejemplo de un "ChangeLog":
---------------------------------------------------------------------------
VERSION: 3.7.9.9
---------------------------------------------------------------------------
* MEJORA o CAMBIO 1
* MEJORA o CAMBIO 2
---------------------------------------------------------------------------
VERSION: 3.8.0.0
---------------------------------------------------------------------------
* MEJORA o CAMBIO 3
* MEJORA o CAMBIO 4
Como puede observarse, se reflejan en el documento los cambios entre versión y versión y la versión actual de la aplicación se encuentra al final del archivo.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
RS-VTOL permite la instalación en clúster brindando un entorno de alta disponibilidad del servicio.
Para ello a continuación se muestra un esquema que clarifica cual es la distribución de los componentes y su relación para un mejor entendimiento y configuración.
Esquema instalación en cluster
Como se observa, si se decide realizar una instalación en alta disponibilidad, donde haya 2 o más RS-VTOL instalados, también será requerida la instalación de balanceador de carga que se encargue de distribuir uniformemente las transacciones y sepa detectar cuando un miembro o nodo del clúster esté fuera de servicio.
La solución en conjunto garantiza la disponibilidad del servicio ante fallas o mantenimiento de los servidores.
Para que RS-VTOL pueda funcionar en clúster es importante poder configurar las IP de las placas de red del server para que RS-VTOL las pueda utilizar correctamente.
Principalmente son dos, una es la IP de la placa de red denominada "Clúster Interface". Por medio de esta placa de red el clúster de RS-VTOL se comunicará para lograr la alta disponibilidad. Es importante que este enlace sea dedicado y en lo posible, una conexión directa entre servers para lograr un enlace sumamente seguro, ya que de perder conexión se pueden obtener resultados no esperados.
Luego es importante configurar cual será la placa de red que se destinará para recibir el tráfico de red perteneciente a la actividad realizada por la consola de administración que RS-VTOL posee. Esta placa de red "WEB Interface" debe estar conectada a la red empresarial ya que de lo contrario su acceso desde diferentes locaciones será limitado o incluso podría no funcionar. Por lo general esta placa de red será la misma por la cual el RS-VTOL recibe el tráfico de red relacionado a las transacciones de negocio.
Si bien se puede acceder a la consola de administración WEB por medio de cualquier de los VTOL, internamente solo se usará los servicios de uno de ellos, por lo cual el mismo requiere estar activo. Para saber el servicio de que RS-VTOL se está utilizando, mirar la variable "JNDI Remoto".
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
En los casos donde el usuario y/o la contraseña utilizados por la aplicación VTOL cambien, se deberá seguir el siguiente procedimiento:
- Detener la aplicación VTOL
- referirse a 9. Iniciar / detener la aplicación
- Configurar los datasources de la aplicación
- referirse a la sección 17.6.2 Configuración de Datasources
- Iniciar de nuevo la aplicación VTOL
- referirse a 9. Iniciar / detener la aplicación
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
La aplicación VTOL funciona dentro del contenedor de aplicaciones JBOSS. Para que funcione correctamente, el JBOSS debe ser configurado adecuadamente.
Por ejemplo y, a modo de resumen, VTOL utiliza los siguientes servicios del JBOSS:
- Conexiones a base de datos o DataSources
- Login
- Servidor Web
- Etc
En este apartado se describen los pasos a seguir para configurar correctamente el JBOSS y todos sus componentes.
Aviso |
---|
Importante: Si el JBOSS ya se encuentra configurado, por tratarse de una re-instalación, este anexo puede ser salteado o ser utilizado como una guía de verificación. |
Nota |
---|
Nota: Por cuestiones de seguridad y cumplimiento de las normas PCI se recomienda que el setup del servidor de aplicaciones esté realizado según las normas de alta seguridad aceptadas en la industria del Center for Internet security (CIS), la National Security Agency (NSA), la Defense Information Systems Agency (DISA) y el National Institute of Standards and Technology (NIST).
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Para el funcionamiento de VTOL, se requiere realizar una copia de la carpeta 'standalone' y renombrarla.
A partir de aquí, dicha carpeta copiada y renombrada se denominará en este documento 'rsvtol'.
Nota |
---|
Nota: En caso de existir una instalación previa de VTOL 3.8 sobre JBOSS 7, se puede reutilizar la configuración del server existente. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Los datasources son las conexiones a la base de datos que utilizará VTOL.
Se debe modificar el archivo standalone.xml ubicado en la carpeta generada en el apartado "17.6.1 Copia de la configuración del server Standalone":
Jboss/rsvtol/configuration/standalone.xml
Se deben ingresar las siguientes líneas de datasource en el archivo standalone.xml dentro del <subsystem xmlns="urn:jboss:domain:datasources:4.0">:
<datasource jndi-name="java:/jdbc/RSConsole" pool-name="RSConsole" enabled="true" use-java-context="true" use-ccm="true"> |
Donde:
- MotorBBDD: podrá ser 'mssql' u 'oracle'
- URLConexion para MS SQL Server será:
jdbc:jtds:sqlserver://IPServer/NombreBBDD;selectMethod=Cursor
- URLConexion para Oracle será:
jdbc:oracle:thin:@ServerId
Drivers
También, en el archivo standalone.xml y en el <subsystem xmlns="urn:jboss:domain:datasources:4.0"> sección <drivers>, se debe ingresar el driver correspondiente al motor de base de datos a utilizar:
MS SQL Server:
<driver name="mssql" module="synthesis.dependencies.mssql"> |
Oracle:
<driver name="oracle" module="synthesis.dependencies.oracle"> |
Se debe proceder a instalar los driver en la siguiente ruta:
Jboss/modules/system/layers/base/synthesis/dependencies/motorBBDD/main
Donde:
- A partir de 'synthesis' se deberá generar la estructura de directorios
- 'motorBBDD' podrá ser mssql, oracle o db2
Synthesis proveerá los archivos respectivos a cada motor de base de datos.
Es obligatorio la definición de los nombres JNDI especificados.
Security Domain
Por norma de seguridad se recomienda no definir el nombre de usuario y contraseña de la base de datos en el datasource ya que quedarían en texto plano. En su lugar se utiliza el dominio de seguridad EncryptDBPassword, el cual se definirá dentro del archivo standalone.xml del server creado para RS-VTOL de manera encriptada.
Se debe agregar la siguiente application-policy dentro de la sección <subsystem xmlns="urn:jboss:domain:security:1.2">:
<security-domain name="EncryptDBPassword" cache-type="default"> |
Donde:
- jdbcusername: es el usuario de base datos
- jdbcpassword: es la contraseña encriptada
Para obtener el valor encriptado de la contraseña se debe correr el siguiente comando desde el home del JBoss 7:
set JAVA_HOME=C:\Java\jdk1.8.0_25\bin |
Donde contraseña es la clave que se desea encriptar.
El resultado obtenido debe ser configurado en el lugar jdbcpassword de la EncryptDBPassword.
Nota: Es recomendable por cuestiones de seguridad y cumplimiento con las normas PCI que se realice una VPN entre el servidor VTOL y la base de datos para que la contraseña se transmita por un canal seguro y evitar cualquier tipo de vulnerabilidad externa. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Para permitir el login de la aplicación utilizando su propio modelo de seguridad se debe actualizar el archivo del server creado:
Jboss/rsvtol/configuration/standalone.xml
La actualización consiste en agregar el siguiente security-domain de nombre rs-console dentro del subsistema <subsystem xmlns="urn:jboss:domain:security:1.2">:
<security-domain name="rs-console" cache-type="default"> |
Âncora | ||||
---|---|---|---|---|
|
Cookies de Seguridad HTTPOnly y Secure
Se debe ingresar la siguiente línea en el archivo standalone.xml dentro del <subsystem xmlns="urn:jboss:domain:undertow:3.1">:
<subsystem xmlns="urn:jboss:domain:undertow:3.1"> |
Ocultamiento de Información del Contenedor Web
Se deben quitar las siguientes líneas del archivo standalone.xml dentro del <subsystem xmlns="urn:jboss:domain:undertow:3.1">:
<filter-ref name="server-header"/> |
Nota |
---|
Nota: El servidor de aplicaciones Jboss posee sitios web por defecto. Se recomienda por seguridad y cumplimiento de las normas PCI que los accesos web deben ser asegurados o eliminados. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Previamente se debe generar el keystore "synthesis.keystore" (ver apartado 7.4.3 Instalación de certificado).
Configurar el Almacén de llaves para SSL
Posteriormente se procede a editar el archivo standalone.xml haciendo que el tag keystore del security-realm "ApplicationRealm" debe quedar de la siguiente manera:
<ssl> |
Donde:
- path: nombre de almacén de llaves que se encuentra dentro de la carpeta configuration
- keystore-password: contraseña para acceder al almacén de llaves
- key-password: contraseña para acceder a la llave
- changeit: contraseña usada en el keystore
Âncora | ||||
---|---|---|---|---|
|
Tras haber configurado el servidor de aplicaciones e instalado VTOL, se debe crear una nueva carpeta dentro del directorio 'rsvtol', nombrándola como "bin", agregar los archivos de inicio y de detención de VTOL para el sistema operativo correspondiente.
17.6.6.1 Archivos de Inicio
Windows
start.bat
set JAVA_OPTS= %JAVA_OPTS% -Dvtol.startup.conf.path=C:Jboss/rsvtol/dist/config |
Linux
start.sh
JAVA_OPTS="-Xms512m -Xmx1512m -XX:MaxPermSize=512m -Dvtol.startup.conf.path=C:Jboss/rsvtol/dist/config -Dframework.factory.impl=com.synthesis.vtol.core.module.ModuleFrameworkFactory -Dreport.vtol.module.cd.dir=C:Jbossrsvtol/dist/config/modules/cd-mx/reports -Djava.net.preferIPv4Stack=true -Djgroups.udp.mcast_port=45500 -Djgroups.udp.mcast_addr=228.1.2.3" |
Donde:
- IPServer es la IP privada del servidor donde está instalado VTOL
- Jboss es la carpeta del servidor de aplicaciones
- rsvtol es la carpeta donde se instaló VTOL
17.6.6.2 Archivos de Detención
Windows
stop.bat
cd C:Jboss/bin |
Linux
stop.sh
cd C:Jboss/bin |
Donde:
- Jboss es la carpeta del servidor de aplicaciones
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Tras haber configurado el servidor de aplicaciones e instalado VTOL, se procede a modificar el archivo log4j.xml ubicado en la ruta:
C:\Jboss\rsvtol\deployments\rs-vtol.ear\META-INF
Se debe definir un FileAppender con una clase propia, que responde a lo establecido por la norma PCI.
File Appender
La siguiente configuración debe realizarse para el appender "File". En la misma se define una clase propia para el Rolling, que genera registros de auditoria cada vez que se cambia el archivo de log, el mismo cicla por defecto cada 20MB prevaleciendo siempre como server.log el archivo más actualizado.
Como puede verse, para registrar la auditoria en base de datos se hace referencia al nombre JNDI del datasource de la aplicación.
<appender name="FILE" class="com.synthesis.fwk.logging.log4j.RollingFileAppender">
</layout> </appender> |
Por otro lado, se debe modificar el Root, comentando la referencia al appender CONSOLE y agregando la priority INFO, como se puede ver en la siguiente figura
Nota |
---|
Nota: Deshabilitar el log o cambiar la configuración señalada en esta sección llevará al incumplimiento de las normas PCI-DSS. |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
17.7.1.1 Deshabilitar la configuración de restauración del sistema
17.7.1.1.1 Desactivar la restauración del sistema – Windows 7 (Workstations)
- Ir a las "Propiedades" del sistema
- Seleccionar la pestaña "System Protection". Aparecerá la siguiente pantalla:
3. Seleccionar "Configure". Aparecerá la siguiente pantalla:
4. Seleccionar "Turn off system protection"
5. Click Apply, y click OK para cerrar la ventana
6. Click OK para cerrar la ventana System Properties
7. Reiniciar la computadora
17.7.1.1.2 Desactivar la restauración del sistema – Windows Server 2012 R2 (Servers)
Windows Server 2012 no incluye la característica de restauración del sistema.
17.7.1.2 Cifrar el archivo PageFile.sys del sistema
17.7.1.2.1 Cifrar PageFile.sys – Windows 7 (Workstations)
Para realizar esta operación, el disco duro debe formatearse mediante NTFS.
1. En la barra de tareas de Windows, haga clic en el "Orb" de Windows y en el cuadro de búsqueda en "cmd"
2. Haga clic con el botón derecho en cmd.exe y seleccione Ejecutar como administrador
3. Para cifrar el archivo de página, escriba el comando siguiente: "fsutil behavior set EncryptPagingFile 1"
4. Para verificar la configuración, escriba el siguiente comando: " fsutilbehaviorquery EncryptPagingFile"
5. Si la encriptación está habilitada, EncryptPagingFile = 1 debe aparecer
6. En caso de que necesite deshabilitar el cifrado de PageFile, escriba el siguiente comando: "fsutil behavior set EncryptPagingFile 0"
7, Para verificar la configuración, escriba el siguiente comando: "fsutil behavior query EncryptPagingFile"
8. Si el cifrado está deshabilitado, debe aparecer EncryptPagingFile = 0
17.7.1.2.2 Cifrar PageFile.sys – Windows Server 2012 R2 (Servers)
Esta sección, método o tarea contiene pasos que indican cómo modificar el registro. Sin embargo, pueden producirse problemas graves si modifica el registro incorrectamente. Por lo tanto, asegúrese de que sigue estos pasos cuidadosamente. Para mayor protección, haga una copia de seguridad del registro antes de modificarlo. A continuación, puede restaurar el registro si se produce un problema.
Para determinar si el archivo de paginación del sistema está cifrado o no, siga estos pasos:
1. Haga clic en Inicio, escriba regedit en el cuadro Iniciar búsqueda y, a continuación, presione ENTRAR. Si se le pide una contraseña de administrador o confirmación, escriba la contraseña o haga clic en Continuar
2. Busque y haga clic en la siguiente subclave del Registro: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ FileSystem
Busque el valor de la entrada de registro NtfsEncryptPagingFile. Si este valor se establece en 1, el archivo de paginación es cifrado.
17.7.1.3. Borrar el Pagefile.sys del sistema al cerrar
17.7.1.3.1 Eliminación del System PageFile.sys al cerrar – Windows 7 (Workstations)
Windows tiene la capacidad de borrar el PageFile.sys al cerrar el sistema. Esto eliminará todos los datos temporales del PageFile.sys (los datos temporales pueden incluir contraseñas del sistema y de la aplicación, datos del titular de la tarjeta (PAN / Track), etc.).
Activar esta función puede aumentar el tiempo de apagado de Windows.
1. Haga clic en el Windows "Orb" y en el cuadro de búsqueda en "regedit"
2. Haga clic derecho en regedit.exe y seleccione Ejecutar como administrador
3. Navegue hasta HKLM \ System \ CurrentControlSet \ Control \ Session Manager \ Memory Management
4. Cambie el valor de 0 a 1
5. Haga clic en Aceptar y cierre Regedit
6. Si el valor no existe, agregue lo siguiente:
Nombre del valor: ClearPageFileAtShutdown
Tipo de valor: REG_DWORD
Valor: 1
17.7.1.3.2 Eliminación del System PageFile.sys al cerrar – Windows Server 2012 R2 (servers)
Esta sección, método o tarea contiene pasos que indican cómo modificar el registro. Sin embargo, pueden producirse problemas graves si modifica el registro incorrectamente. Por lo tanto, asegúrese de que sigue estos pasos cuidadosamente. Para mayor protección, haga una copia de seguridad del registro antes de modificarlo. A continuación, puede restaurar el registro si se produce un problema.
Estos pasos deben ser ejecutados:
1. Inicie el Editor del Registro (Regedt32.exe).
2. Cambie el valor de datos del valor ClearPageFileAtShutdown en la siguiente clave del registro a un valor de 1: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Session Manager \ Memory Management
Si el valor no existe, agregue el siguiente valor:
Nombre del valor: ClearPageFileAtShutdown
Tipo de valor: REG_DWORD
Valor: 1
Este cambio no tendrá efecto hasta que reinicie el equipo.
17.7.1.4 Desactivar la gestión del sistema de Pagefile.sys
17.7.1.4.1 Desactivación del sistema PageFile.sys – Windows 7 (Workstations) & Windows Server 2012 R2 (Servers)
- Haga clic con el botón derecho en Equipo y seleccione Propiedades
- Seleccione Configuración avanzada del sistema en la lista superior izquierda. La siguiente pantalla aparecerá:
3. En Rendimiento, seleccione Configuración y haga clic en la pestaña Opciones avanzadas. La siguiente pantalla aparecerá:
4. Seleccione Cambiar en Memoria virtual. En la siguiente pantalla aparecerá:
5. Desactive la opción Automatically manage page file size for all drives
6. Seleccione Custom Size
7. Introduzca lo siguiente para las selecciones de tamaño:
- Initial Size – como una buena regla de oro, el tamaño debe ser equivalente a la cantidad de memoria en el sistema.
- Maximum Size – como una buena regla general, el tamaño debe ser equivalente a 2x la cantidad de memoria en el sistema.
8. Click OK tres veces. Se le pedirá que reinicie su computadora.
17.7.1.5 Desactivar Windows Error Reporting
17.7.1.5.1 Desactivación de Windows Error Reporting – Windows 7 (Workstations)
- Abra el Panel de control
- Abra el Centro de Acción
- Seleccione Cambiar la configuración del centro de acción
4. Seleccione Configuración de informes de problemas
5. Seleccione Nunca buscar soluciones
17.7.1.5.2 Desactivación de Windows Error Reporting – Windows Server 2012 R2 (Servers)
En Windows Server 2012 R2, puede deshabilitar Windows Error Reporting en cualquiera de las siguientes maneras:
- Para deshabilitar el Informe de errores de Windows mediante la ventana Tareas de configuración inicial
- Para deshabilitar Windows Error Reporting mediante Server Manager
También puede habilitar o deshabilitar Windows Error Reporting configurando su comportamiento mediante la directiva de grupo. Utilice el Editor de directiva de grupo local cuando edite Directiva de grupo local o utilice la consola de Administración de directivas de grupo cuando edite la directiva de grupo basada en dominio. Puede encontrar estas opciones de directiva en Plantillas administrativas / Componentes de Windows / Informes de errores de Windows.
Para deshabilitar Windows Error Reporting utilizando tareas de configuración inicial:
- Si la ventana Tareas de configuración inicial no está abierta, puede abrirla haciendo clic en Inicio, en Ejecutar, escribiendo oobe en el cuadro de texto y haciendo clic en Aceptar.
- Haga clic en Habilitar actualización automática y retroalimentación en el área Actualizar este servidor.
- En el cuadro de diálogo Habilitar actualización automática y retroalimentación, haga clic en Configurar manualmente la configuración.
- En el área Informe de errores de Windows del cuadro de diálogo Configurar manualmente configuración, haga clic en Cambiar configuración.
- En el cuadro de diálogo Configuración de informes de errores de Windows, seleccione una de las opciones siguientes y, a continuación, haga clic en Aceptar.
- No quiero participar y no volver a preguntarme Esta opción deshabilita el Informe de errores de Windows y evita que le solicite que envíe información sobre fallos de aplicaciones a Microsoft.
- Pregúntame sobre el envío de informes cada vez que se produzca un error Esta opción deshabilita el Informe de errores de Windows, pero le permite solicitar que envíe información sobre fallos de aplicaciones a Microsoft siempre que se produzca un error.
- En el cuadro de diálogo Configurar manualmente Configuración, haga clic en Cerrar.
Para deshabilitar Windows Error Reporting mediante Server Manager:
- Abra el Administrador de servidores haciendo clic en Inicio, seleccione Herramientas administrativas ya continuación, haga clic en Administrador de servidores.
- En la página de inicio de Server Manager, expanda el área Recursos y soporte si aún no está abierto.
- Haga clic en Configurar informes de errores de Windows.
- En el cuadro de diálogo Configuración de informes de errores de Windows, seleccione una de las opciones siguientes y, a continuación, haga clic en Aceptar.
- No quiero participar y no volver a preguntarme Esta opción deshabilita el Informe de errores de Windows y evita que le solicite que envíe información sobre fallos de aplicaciones a Microsoft.
- Pregúntame sobre el envío de informes cada vez que se produzca un error Esta opción deshabilita el Informe de errores de Windows, pero le permite solicitar que envíe información sobre fallos de aplicaciones a Microsoft siempre que se produzca un error.
17.7.1.6 Desactivar los volcados de memoria
17.7.1.6.1. Desactivación de volcados de memoria– Windows 7 (Workstations)
- Haga clic con el botón derecho en Mi PC > Propiedades > Configuración avanzada del sistema
2. En la ficha Avanzadas > Inicio y recuperación > Botón Configuración.
3. Fallo del sistema > Escribir información de depuración > desplegable seleccione Ninguno.
4. Click en OK
17.7.1.6.2 Desactivación de volcados de memoria – Windows Server 2012 R2 (Servers)
El procedimiento para deshabilitar los volcados de memoria en Windows Server 2012 R2 es el mismo que el de Windows 7.
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
17.7.2.1 Linux
Para Linux es necesario instalar el paquete de auditoría (2.6 Kernel Audit System)
El paquete de auditoría contiene las utilidades de espacio de usuario para almacenar y buscar los registros de auditoría generados por el subsistema de auditoría en el kernel Linux 2.6. CentOS incluye el paquete rpm de auditoría. Utilice el comando yum o up2date para instalar el paquete
# yum install audit
o
# up2date install audit
Inicio automático del servicio auditd en el arranque
# ntsysv
o
# chkconfig auditd on
Ahora inicie el servicio:
# /etc/init.d/auditd start
Los directorios de Linux que se supervisarán:
/usr/bin
/usr/sbin
/bin
/etc
/boot
/Jboss/rsvtol
/Jboss/rsvtol/log
El comando para supervisar los directorios:
auditctl -w /directory/to/be/monitored/ -k %keyword-for-search% -p rawx r=read; a=access; w=write; x=execute
-k is used to easily search through logs
Ejemplo: auditctl /root/AuditDir/ -k AuditDir -p rw
Para buscar a través del uso de auditoría:
ausearch
Compruebe su uso. Ejemplos:
Filter by user:ausearch -ui %user%
Filter by keyword::ausearch -k AuditDir
Los registros de auditoría de Linux se almacenan en:
/var/log/audit/audit.log
17.7.2.2 Windows
Para sistemas basados en Windows:
1. Haga clic derecho en las unidades (C: \ etc)
2. Seleccione Propiedades
3. Seleccione la pestaña Seguridad
4. Elija Avanzado
5. Seleccione Ficha de auditoría y haga clic en Editar
6. Marque 'Reemplazar todas las entradas de auditoría heredables existentes' y haga clic en Añadir
7. Como el usuario elige a todos (o lo que es necesario)
8. Eliminar todo tipo de auditoria
9. Aplicar a la carpeta y subcarpetas
Directorio de Windows que se va a auditar:
C:\Windows\ C:\Program Files\
C:\Jboss\rsvtol
C:\Jboss\rsvtol\log
A continuación, en cada carpeta que desea auditar:
1. Haga clic derecho en él
2. Seleccione Propiedades
3. Seleccione la pestaña Seguridad
4. Elija Avanzado
5. Seleccione la pestaña de auditoría, haga clic en Editar, desmarque las dos opciones en la parte inferior y haga clic en Agregar
6. Elija Usuario (todos)
7. Elija lo que desea auditar (Eliminar, Crear, etc)
8. Aplicar a la carpeta y subcarpetas.
9. Repita para todas las carpetas según sea necesario.
Luego
Inicio > Panel de control > Sistema > Derechos administrativos > Política de seguridad local > Configuración avanzada de la directiva de auditoría > Acceso a objetos > Sistema de archivos de auditoría > Seleccione Suceso o Fallo o ambos
Los registros de auditoría de Windows se almacenan en:
C:\Windows\System32\winevt\Logs\
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
17.7.3.1 SQL Server
El objeto Audit de SQL Server recopila una sola instancia de acciones de servidor o de nivel de base de datos y grupos de acciones para supervisar. La auditoría se realiza en el nivel de instancia de SQL Server.
17.7.3.1.1 Visión general del uso de la auditoría de SQL Server
Puede utilizar SQL Server Management Studio o Transact-SQL para definir una auditoría. Una vez creada y habilitada la auditoría, el destino recibirá las entradas.
El proceso general para crear y usar una auditoría es el siguiente:
1. Cree una auditoría y defina el destino.
2. Cree una especificación de auditoría de servidor o especificación de auditoría de base de datos que se correlaciona con la auditoría. Habilitar la especificación de auditoría.
3. Habilitar la auditoría.
4. Lea los eventos de auditoría utilizando el Visor de sucesos de Windows, el Visor de archivos de registro o la función fn_get_audit_file.
17.7.3.1.2 Permisos
Cada característica y comando para SQL Server Audit tiene requisitos de permisos individuales.
Para crear, modificar o eliminar una auditoría de servidor o una especificación de auditoría de servidor, los mandatos de servidor requieren el permiso ALTER ANY SERVER AUDIT o CONTROL SERVER. Para crear, modificar o eliminar una especificación de auditoría de base de datos, los principios de base de datos requieren el permiso ALTER ANY DATABASE AUDIT o el permiso ALTER o CONTROL en la base de datos. Además, los principales deben tener permiso para conectarse a la base de datos, o ALTER NINGÚN permiso de SERVER AUDIT o CONTROL SERVER.
El permiso VIEW ANY DEFINITION proporciona acceso para ver las vistas de auditoría de nivel de servidor y VIEW DEFINITION proporciona acceso para ver las vistas de auditoría de nivel de base de datos. La denegación de estos permisos, reemplaza la capacidad de ver las vistas de catálogo, incluso si el principal tiene los permisos ALTER ANY SERVER AUDIT o ALTER ANY DATABASE AUDIT.
17.7.3.1.3 Utilización de SQL Server Management Studio
Para crear una auditoría de servidor
1. En el Explorador de objetos, expanda la carpeta Seguridad.
2. Haga clic con el botón derecho en la carpeta Auditorías y seleccione Nueva Auditoría...
3. Cuando haya terminado de seleccionar las opciones, haga clic en Aceptar.
Para crear una especificación de auditoría a nivel de base de datos
1. En el Explorador de objetos, expanda la base de datos rsvtol para crear una especificación de auditoría.
2. Expanda la carpeta Seguridad.
3. Haga clic con el botón secundario en la carpeta Especificaciones de auditoría de base de datos y seleccione Nueva especificación de auditoría de base de datos....
Las siguientes opciones están disponibles en el cuadro de diálogo Crear especificación de auditoría de base de datos.
Name El nombre de la especificación de auditoría de la base de datos. Esto se genera automáticamente cuando se crea una nueva especificación de auditoría de servidor pero se puede editar.
Audit El nombre de una auditoría de base de datos existente. Escriba el nombre de la auditoría o selecciónelo en la lista.
Audit Action Type Especifica los grupos de acciones de auditoría a nivel de base de datos y las acciones de auditoría para capturar.
Object Schema Muestra el esquema del nombre de objeto especificado.
Object Name El nombre del objeto a auditar. Esto sólo está disponible para las acciones de auditoría; no se aplica a los grupos de auditoría.
Ellipsis (…) Abre el cuadro de diálogo Seleccionar objetos para buscar y seleccionar un objeto disponible, en función del tipo de acción de auditoría especificado.
Principal Name La cuenta para filtrar la auditoría para el objeto que se está auditando.
Ellipsis (…) Abre el cuadro de diálogo Seleccionar objetos para buscar y seleccionar un objeto disponible, basado en el nombre de objeto especificado.
Cuando haya terminado de seleccionar la opción, haga clic en Aceptar.
Nota |
---|
Nota: Para obtener más información, visite la página web oficial de SQL Server Audit: https://docs.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-database-engine |
17.7.3.2 Oracle
17.7.3.2.1 Activar o desactivar la pista de auditoría estándar
- Iniciar Control de base de datos.
- Inicie sesión como SYS y conéctese con el privilegio SYSDBA.
- Nombre de usuario: SYS
- Contraseña: Ingrese su contraseña.
- Conectarse como: SYSDBA
- Haga clic en Servidor para mostrar la subpágina Servidor.
- En la sección Configuración de base de datos, haga clic en Parámetros de inicialización. Aparece la página Parámetros de inicialización.
- Haga clic en SPFile para mostrar la subpágina SPFile. Si la pestaña SPFile no se muestra en su instalación, no instaló Oracle Database utilizando un archivo de parámetros de servidor. Vaya al siguiente paso.
- En el campo Nombre, escriba audit_trail para buscar el parámetro de inicialización AUDIT_TRAIL y, a continuación, haga clic en Ir. Puede introducir los primeros caracteres del parámetro, por ejemplo, AUDIT_. Alternativamente, puede desplazarse por la lista de parámetros para encontrar el parámetro AUDIT_TRAIL.
- En el campo Valor, seleccione uno de los siguientes valores:
- DB: Permite la auditoría de la base de datos y dirige los registros de auditoría estándar a la pista de auditoría de la base de datos (SYS.AUD $), excepto para los registros que siempre se escriben en la pista de auditoría del sistema operativo. (Este valor es el predeterminado si creó la base de datos utilizando Database Configuration Assistant. De lo contrario, el valor predeterminado es NONE)
- OS: Habilita la auditoría de la base de datos y dirige todos los registros de auditoría a un archivo del sistema operativo. Escribir el seguimiento de auditoría en los archivos del sistema operativo es mejor para el rendimiento en lugar de enviar los registros de auditoría a la tabla SYS.AUD $. Si el auditor es distinto del administrador de la base de datos, debe utilizar la configuración del sistema operativo. Cualquier información de auditoría almacenada en la base de datos es visible y modificable por el administrador de la base de datos.
- NONE: Desactiva la auditoría estándar.
- DB, EXTENDED: Realiza todas las acciones de la configuración AUDIT_TRAIL = DB y también rellena las columnas de tipo SQL y CLOB del texto SQL de la tabla SYS.AUD $, cuando están disponibles. (Estas dos columnas se rellenan sólo cuando se especifica este parámetro)
- XML: Escribe en el archivo de registro de auditoría del sistema operativo en formato XML. Imprime todos los elementos del nodo AuditRecord excepto Sql_Text y Sql_Bind al archivo de auditoría XML del sistema operativo. Este archivo .xsd representa la definición de esquema del archivo de auditoría XML. Un esquema XML es un documento escrito en el lenguaje XML Schema.
- EXTENDED: Especifica XML, EXTENDED, que realiza todas las acciones de XML y también rellena las columnas de tipo SQL y CLOB del texto SQL de la tabla SYS.AUD $, siempre que sea posible. (Estas columnas se rellenan sólo cuando se especifica este parámetro)
- Click en Aplicar.
- Reinicie la instancia de Oracle:
- Haga clic en el vínculo Instancia de base de datos.
- Haga clic en Inicio para ver la página principal de Control de bases de datos.
- Haga clic en Apagar.
- Luego ingrese sus credenciales.
- Una vez finalizada la desconexión, haga clic en Inicio.
Nota |
---|
Nota: Para obtener más información, visite la web oficial de Oracle Audit: https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50522 |
17.7.3.3 DB2
Nota |
---|
Nota: Para obtener información, visite la web oficial de DB2 Audit: https://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0002072.html |
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Formulario de Clave Custodio
<<< Empresa Cliente >>>
Como empleado de <<< Empresa Cliente >>> con responsabilidades sobre la seguridad criptográfica de datos confidenciales, con autorización para acceder a las claves de cifrado de VTOL Server, se requiere que usted firme este documento para reconocer dichas responsabilidades.
El firmante de este documento tendrá acceso a los dispositivos de administración de claves, software y/o equipo, y por la presente acepta que:
1. ha leído y entendido las políticas y procedimientos asociados con la administración de claves y acuerda cumplir con ellos de la mejor manera posible,
2. ha tenido la oportunidad de formular preguntas sobre esta política y se han respondido sus preguntas,
3. se compromete a no divulgar a ninguna parte no autorizada las prácticas de la gestión de claves o cualquier sistema de seguridad relacionado, contraseñas, procesos u otros secretos asociados con los sistemas de la empresa,
4. acuerda informar sin demora a la gerencia de cualquier actividad sospechosa, incluyendo a un compromiso o robo del sistema o clave.
Estoy de acuerdo con lo anterior en su totalidad y entiendo mis responsabilidades como se indicó anteriormente.
Nombre: ____________________________________________________
Firma: ____________________________________________________
Fecha: ____________________________________________________
Testigo
Nombre: ____________________________________________________
Firma: ____________________________________________________
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Âncora | ||||
---|---|---|---|---|
|
Diagrama de Flujo de Datos de Autorización
Quien inicia el flujo es el punto de venta o POS cuando una venta se decide pagar con tarjeta de crédito o débito. En tal caso, la aplicación de punto de venta, inicia una transacción (venta, anulación, devolución) en VTOL Client.
VTOL Client, a través del Pinpad, captura los datos de la tarjeta de crédito/débito. El ingreso de los datos se podrá hacer por chip, banda magnética o manual.
Dependiendo el modo de ingreso de la tarjeta, se solicitarán ingresar uno u otros datos propios de la tarjeta, como ser el código de seguridad, la fecha de vencimiento, etc.
Una vez que VTOL Client haya capturado todos los datos del tarjetahabiente, se procede a enviar la transacción de autorización a VTOL Server. La transacción de autorización tendrá asociado un tipo de transacción (venta, devolución, anulación) el cual dependerá del tipo de acción que se realice en el punto de venta.
VTOL Server, al recibir los datos, valida que los mismos sean correctos para el tipo de transacción seleccionada por el POS. Si algún dato es inválido, VTOL Server finaliza la transacción y devuelve el control al POS indicando el error.
Si los datos son correctos, se procede a la ejecución de las reglas de negocio asociadas al tipo de transacción y posterior autorización de la transacción con el centro autorizador correspondiente (Visa, Amex, etc.).
Entre las reglas de negocio que se ejecutan se encuentran las siguientes:
- Se reconoce el tipo de tarjeta (VISA, MasterCard, Amex, etc.)
- Se valida que esté permitida la opción de pago (combinación cuotas, plan, moneda, tarjeta)
- Se obtiene qué centro autorizador será el encargado de autorizar la transacción (Visa, Posnet, etc.)
- Se valida que el estado del canal esté correcto
- Etc.
Si las reglas de negocio son correctas, entonces se envía la autorización al centro autorizador correspondiente.
Una vez que se recibe la autorización, la misma junto con los datos originales se graban en la base de datos de VTOL Server. Es importante mencionar que el único dato que se conserva es el PAN del tarjetahabiente y que este es almacenado de manera cifrada, utilizando algoritmos de encriptación sólidos.
Finalizada la misma, se responde a VTOL Client los datos de autorización.
El POS procede a imprimir el voucher de la tarjeta quién da por finalizada la transacción, lo que implica enviar un mensaje adicional a VTOL Server indicando que la transacción ha finalizado (tercer mensaje: commit).
Si por una cuestión particular la transacción falla, por ejemplo no se puede imprimir voucher, entonces el POS envía un mensaje adicional a VTOL Server indicando que la transacción ha fallado y se debe deshacer (tercer mensaje: rollback). En este caso VTOL Server inicia un proceso donde deshace la transacción realizada anteriormente.
Âncora | ||||
---|---|---|---|---|
|
Diagrama de e-commerce
Diagrama de Flujo de Datos de Autorización
Una persona compra los productos seleccionados en el comercio electrónico e ingresa los datos de su tarjeta en la plataforma web.
El e-commerce procede a enviar la transacción de autorización con un importe específico a VTOL Server (tipo de transacción: venta).
VTOL Server, al recibir los datos, valida que sean correctos para el tipo de transacción seleccionada por el comercio electrónico. Si cualquier dato no es válido, VTOL Server finaliza la transacción y devuelve el control al comercio electrónico indicando el error.
Si los datos son correctos, procede a la ejecución de las reglas de negocio asociadas al tipo de transacción que se ejecutan, entre las que se encuentran las siguientes:
- Se reconoce el tipo de tarjeta (VISA, MasterCard, Amex, etc.)
- Valida si se permite la opción de pago (combinación de pago, plan, moneda, tarjeta)
- Se obtiene el centro de autorización que se encargará de autorizar la transacción (Visa, Posnet, etc.)
- Valida si el estado del canal es correcto
- Etc.
Si las reglas del negocio son correctas, la autorización se envía al centro de autorización correspondiente (Visa, Amex, etc.).
Una vez que se recibe la autorización, la misma junto con los datos originales se registra en la base de datos de VTOL Server. Es importante mencionar que el único dato que se conserva es el PAN del titular de la tarjeta y se almacena de forma encriptada, utilizando algoritmos de cifrado sólidos.
Una vez completado el mismo, los datos de autorización se responden al comercio electrónico.
El comercio electrónico procede a finalizar la transacción, lo que implica enviar un mensaje adicional a VTOL Server indicando que la transacción ha finalizado (tercer mensaje: commit).
Si la transacción falla debido a un problema en particular, el comercio electrónico envía un mensaje adicional a VTOL Server indicando que la transacción ha fallado y que debe deshacerse (tercer mensaje: rollback). En este caso, VTOL Server inicia un proceso donde deshace la transacción anterior.
Âncora | ||||
---|---|---|---|---|
|
Palabra | Significado |
3DES | Algoritmo de encriptación, donde encripta 3 veces usando el algoritmo de encriptación DES. |
Clave o llave | Los valores secretos usados como "llave" para una encriptación se denominan "clave" |
Contraseña | Las "contraseñas" sirven para autenticar usuarios |
DMZ | Una zona desmilitarizada (DMZ) o red perimetral es una red local que se ubica entre la red interna de una organización y una red externa, generalmente Internet |
OWASP | Acrónimo de Open Web Application Security Project, en inglés 'Proyecto de seguridad de aplicaciones web abiertas' |
PA-DSS | Payment Application – Data Security Standard, significa aplicación de pago de seguridad de datos. |
PCI-DSS | Payment Card Industry Data Security Standard, significa Estándar de Seguridad de Datos para la Industria de Tarjeta. |
SFTP | SSH File Transfer Protocol, protocolo de red utilizado para la transferencia segura de archivos |
VPN | Red Privada Virtual |
WPA | Wi-Fi Protected Access - Acceso Protegido Wi-Fi |
startVTOLEngine