VTOL CD AR - Guía de implementación 3.8.1.0 - Multiempresa

 

1. Objetivo

El objetivo de este documento es ofrecer una guía completa del proceso de implementación del producto VTOL 3.8.1.0
Asimismo, esta guía cuenta con un detalle de información y recomendaciones para el cumplimiento de los estándares PCI S3 (Payment Card Industry Secure Software Standard).

2. Alcance

RS-VTOL Crédito Débito.

3. Referencias

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

3.1 Índice de documentos

Se menciona la serie de documentos que acompañan al producto:

• VTOLCR-DB-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-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.

4. Introducción

4.1 Qué es RS-VTOL CR/DB?

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 dos componentes:

• VTOL Server (conformado por VTOL Admin y VTOL Engine)
• EMV Kit

4.1.1 VTOL Server

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

4.1.2 EMV KIT

EMV KIT es el componente encargado de capturar los datos de las tarjetas a través del pinpad e iniciar el proceso de autorización contra VTOL Server. Los datos que captura son los siguientes:

• tarjeta mediante ingreso manual
• tarjeta mediante ingreso por MSR
• tarjeta mediante ingreso por CHIP
• Código de seguridad, CVV o CVV2
• Fecha de vencimiento
• Últimos 4 dígitos de la tarjeta
• PIN

Es una aplicación Java del tipo Stand Alone; es decir, no requiere de ningún servidor de aplicación para poder ejecutarse ni tampoco tiene una interfaz gráfica de usuario, que se encontrará configurada en cada máquina donde se ejecuta la aplicación de punto de venta.
Este componente expone una API de integración del tipo TCPIP bajo el protocolo llamado "protocolo VTOL". A través de esta API, las aplicaciones de punto de venta pueden iniciar una transacción de: venta, devolución, anulación, etc.

Arquitectura de EMV KIT

4.2 Acerca de este manual

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.
En caso de que sólo desee instalar VTOL Server, omitir los apartados que hacen referencia a EMV KIT.

4.3 Recomendaciones

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.

4.4 Flujo de implementación

En este apartado se explicará la secuencia o los pasos para instalar de cero, configurar e iniciar VTOL Server:

1. Verificar y cumplir con los pre-requisitos del sistema, tanto de software como de hardware (apartado 5. Pre-requisitos del sistema)
   
   
2. Efectuar la instalación completa mediante el asistente gráfico de instalación (apartado 7.1.1 Instalación de cero de VTOL 3.8)
   
   
3. Crear la base de datos y ejecutar los script de base de datos (apartado 7.3.1 Creación de la base de datos)
   
   
4. Iniciar VTOL Engine como proceso o servicio (apartado 9.1 Iniciar / detener la aplicación VTOL Engine)
   
   
5. Iniciar VTOL Admin como proceso o servicio (apartado 9.2 Iniciar / detener la aplicación VTOL Admin)
   
   
6. Acceder a la consola web de administración (apartado 10. Acceso administrativo a VTOL)
   
   
7. Iniciar sesión en la consola web de administración (apartado 11.1 Primer inicio de sesión)
   
   
8. Configurar las propiedades y las variables iniciales que utilizará VTOL, como por ejemplo "VTOL Core Habilitado" (apartado 11.2 Configuración de la aplicación VTOL)
   
   
9. Administrar la seguridad del usuario (apartado 12.1 Administración de usuarios para acceso administrativo WEB)

Una vez efectuado el flujo de implementación, dirigirse al documento "VTOL CD AR - Manual de usuario" para conocer cómo operar con el producto VTOL.

5. Pre-Requisitos del sistema

5.1 VTOL Server

A continuación se detallarán los pre-requisitos para realizar la instalación de VTOL Server en el sistema.

5.1.1 Plataformas Soportadas

• Windows 32/64 bits
  • Windows 7 o superior
  • Windows Server 2012 R2 o superior
• Linux 32/64 bits
  • Cent OS v7 o superior

5.1.2 Requerimientos de Hardware

• Memoria RAM:
  • VTOL Engine: 2GB (mínimo disponible para la aplicación)
  • VTOL Admin: 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

5.1.3 Requerimientos de Software

• Java Development Kit (JDK) 1.8 - release jdk1.8.0_251 o superior (32/64bits acorde al SO)
  • Link de descarga: http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html
• Servidor de aplicaciones: JBoss Wildfly 18.0.1.Final
• Motor de base de datos:
  • MS SQL Server 2012 Service Pack 3 o superior
  • Oracle 11.2 o superior

5.2 EMV KIT

A continuación se detallarán los pre-requisitos para realizar la instalación de EMV KIT en el sistema.

5.2.1 Plataformas Soportadas

• Windows 32/64 bits
• Linux 32/64 bits

5.2.2 Requerimientos de Hardware

• Memoria RAM: 64MB disponibles
• CPU: 2 núcleos de 1.6 GHZ o superior
• Capacidad de almacenamiento en Disco Rígido: 150MB o superior

5.2.3 Requerimientos de Software

• Java Virtual Machine (JDK) 1.6.x/1.7.x/1.8.x (32/64 bits acorde con el sistema operativo)
• Conexión a VTOL Server por red TCP/IP

6. Consideraciones generales

6.1 Esquema general de una red VTOL

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.

En el siguiente diagrama se muestra cómo es la arquitectura general y la comunicación entre los componentes de VTOL:

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 EMV KIT. É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.

6.2 Acceso desde Internet

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).

6.3 Control de Acceso

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, claves públicas, etc).

6.4 Acceso remoto a la aplicación

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.

6.4.1 Acceso remoto por consola

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

6.4.2 Acceso administrativo sin consola

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

6.4.3 Consideraciones generales de seguridad

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 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

6.5 Protección para transmisiones inalámbricas

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

6.6. Envío seguro de información por medios públicos

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:

1. Red privada
2. 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

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 EMV KIT 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".

6.6.1 Configuración en VTOL

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.

6.7 Actualizaciones remotas

El único mecanismo existente para la actualización de la aplicación de pago VTOL que Napse 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 Napse.
El área de Servicio al Cliente de Napse 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.
Napse 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 Napse 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 Napse. 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".

6.8 Componentes de software

A continuación, se listan los componentes de software relacionados con la aplicación VTOL:

6.9 Versionado

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 S3 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, Napse 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).

La metodología de control de versiones que Napse utiliza tanto para versiones internas como externas es la misma.

7. Instalación de VTOL Server

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:

1. Instalación de cero de VTOL 3.8.1.X
   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.1.X 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.8.X Productivo a VTOL 3.8.1.X Productivo
Es el caso cuando se encuentra instalada la versión 3.8.X de VTOL en un entorno de producción y se desea cambiar a la versión 3.8.1.X

7.1 Escenarios de instalación

7.1.1 Instalación de cero de VTOL 3.8.1.X

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:

1. Verificar la existencia de la base de datos que usará la aplicación VTOL.
2. Iniciar sesión en el sistema operativo donde se instalará la aplicación VTOL con un usuario con permisos de administrador.
3. 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-ar-installer-3.8.1.X.jar

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.

6. A continuación se deben aceptar los términos y condiciones de uso (si no se aceptan los términos y condiciones, la instalación no se completará). Además, se deben ingresar los datos de licencia del producto.

1. 1. Nombre completo del usuario que realiza la instalación.
   2. Correo electrónico del usuario que realiza la instalación.
   3. Código de compañía generado por el Gestor de Licencias de Napse. Este código será entregado por Napse a la compañía que realiza la instalación. Si se ingresa un código no autorizado por Napse, luego no se podrá activar la licencia del producto.
   4. Entorno de instalación. Permite seleccionar las siguientes opciones: Production, PreProduction, Development, Test.

7. En la siguiente pantalla se deja seleccionada la opción "Complete Installation" y se pasa a la siguiente pantalla presionando el botón "Próxima".

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:

1. 1. La versión del motor de base de datos seleccionado
   2. La conexión URL
   3. El host de la base de datos
   4. El nombre de la base de datos que fue creada previamente para VTOL
   5. 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 para cada canal el tipo de conexión correspondiente que se empleará y presionar "Próxima".

1. 1. Para el caso del canal de AMEX por defecto viene activo el protocolo AMEXV4 (Global). Para utilizar el protocolo AMEX tradicional, se debe cambiar el combo de AMEXV4 a NOT Enabled, y activar el protocolo AMEX en una de sus opciones.
   2. En caso de elegir el protocolo AMEX, se podrá elegir la versión de la mensajería a instalar. Para el caso de nuevos clientes se deberá elegir la opción con versión 1.03. Para el caso de instalaciones de clientes que no tengan certificada dicha versión de la mensajería, se deberá seleccionar la opción que solo dice AMEX.
   3. El tipo de conexión puede variar entre las siguientes opciones:
      1. TCP/IP X 1: Utilizado cuando existe una única conexión con el centro autorizador sobre protocolo TCP/IP.
      2. TCP/IP X 2: Utilizado cuando existen dos conexión con el centro autorizador sobre protocolo TCP/IP.
      3. TCP/IP PR1000 X 1: Utilizado cuando el cliente cuenta con el router PR1000 para establecer una única conexión (X25) con el centro autorizador.
      4. TCP/IP PR1000 X 2: Utilizado cuando el cliente cuenta con el router PR1000 para establecer dos conexiónes (X25) con el centro autorizador.
      5. Not Enabled: Esta opción es utilizada para deshabilitar el uso del canal seleccionado.
      6. X25 Protocol: Utilizado cuando la conexión con el centro autorizador es via X25 utilizando una placa para tal fin en el servidor.
      7. TCP/IP With Echo X 1: Opción utilizada exclusivamente en el caso de VISA para realizar una única conexión TCP/IP con Echo.
      8. TCP/IP With Echo X 2: Opción utilizada exclusivamente en el caso de VISA para establecer dos conexiones TCP/IP con Echo.

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:

1. 1. El identificador del nodo dentro del clúster
   2. La descripción del nodo del clúster. Esta descripción se visualizará en la consola de administración
   3. El nombre de la partición
   4. 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
   5. La zona horaria en la cual se está instalando la aplicación
   6. El directorio donde la aplicación VTOL almacenará la llave maestra (si no existe, se le ofrecerá crearlo)
      
      

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-18.0.1.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. 

7.1.1.2 Instalación avanzada

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.

7.1.1.3 Instalación en Linux

1. Verificar que el usuario con que se ejecuta la instalación y ejecuta los archivos .sh de VTOL tenga permiso de lectura, escritura y ejecución.
Comando Linux: ls -l

2. Verificar que el usuario con que se ejecuta los archivos .sh de VTOL tenga permiso de lectura, escritura y ejecución de la carpeta temporal de java. “/tmp”.
Comando Linux: ls -l

3. Ejecutar el instalador de VTOL y seguir el paso a paso detallado en 7.1.1.
Java -jar instalador.jar

4. Ejecutar los script de base de datos que se encuentran en dist\scripts

5. Ejecutar los archivos VTOLEngine-Start.sh y VTOLAdmin-Start.sh
./ VTOLEngine-Start.sh
./ VTOLAdmin-Start.sh

En caso que el usuario no cuente con los permisos necesarios, se deben utilizar los siguientes comandos para otorgarlos:

• Otorgar permisos
chmod -R 777 directorio

• Establecer owner del directorio o archivo
Chown -R usuario directorio

Otros comandos:

• Verificar ejecución de los procesos java
ps -fea | grep java

• Eliminar proceso
Kill -9 numeroDeProceso

7.1.2 Migración de VTOL 3.8.1.X en Laboratorio a Producción

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.

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 VTOL - CR/DB Manual de implementación de material criptográfico - Napse - Draft - Linx Share.
• Borrado de información sensible histórica
• Borrado de logs
• Migración de versiones anteriores

Posterior a la ejecución de los pasos antes mencionados, se puede continuar con la puesta en producción de la aplicación.

7.1.3 Migración de VTOL 3.8.0.X Productivo a VTOL 3.8.1.X Productivo

Cuando la instalación de VTOL 3.8.1.X se haga sobre una instalación de VTOL 3.8.X, se deberán seguir los siguientes pasos:

1. Detener la aplicación o servicio de VTOL
2. Se debe verificar que se borre de forma segura los logs de VTOL 3.8.X. Para ello, dirigirse al apartado "17.2 Herramienta para el borrado seguro de datos"
3. Para saber dónde se están almacenando los logs referirse a "13.1 Archivos de log"
4. 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
5. Instalar VTOL 3.8.1.X siguiendo los pasos indicados en esta guía
   1. Iniciar en el paso "7.1.1 Instalación de cero de VTOL 3.8.1.X"
   2. 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"
6. Cambio de clave de almacenamiento de datos sensibles
   1. 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:

1. 1. Realizar el borrado seguro de la instalación de VTOL 3.8.X
   2. 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):

1. 1. Realizar el borrado seguro de la instalación de VTOL 3.8.1.X recién instalada.
   2. 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

7.2 Pre-Instalación de la aplicación

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.

7.2.1 Comienzo de la pre-instalación

A continuación, se describen los pasos para realizar la instalación de la aplicación:

1. Verificar la creación de la base de datos que usará la aplicación VTOL. En caso de que la base de datos ya exista por tratarse de una actualización, saltear este paso.
2. Iniciar sesión en el sistema operativo donde se instalará la aplicación VTOL con un usuario con permisos de administrador.
3. 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-ar-installer-3.8.1.X.jar

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. Seleccionar la opción "Only VTOL Components".
Presionar el botón "Próxima".

5. 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 que se copió de la configuración del server Standalone (anexo 17.6.1)
Oprimir el botón "Próxima".

6. Indicar el motor de base de datos que se utilizará y presionar "Próxima".

7. Seleccionar para cada canal (conexión al centro autorizador o CA) el tipo de conexión que se empleará y presionar "Próxima".

1. 1. Para el caso del canal de AMEX por defecto viene activo el protocolo AMEXV4 (Global). Para utilizar el protocolo AMEX tradicional, se debe cambiar el combo de AMEXV4 a NOT Enabled, y activar el protocolo AMEX en una de sus opciones.
   2. En caso de elegir el protocolo AMEX, se podrá elegir la versión de la mensajería a instalar. Para el caso de nuevos clientes se deberá elegir la opción con versión 1.03. Para el caso de instalaciones de clientes que no tengan certificada dicha versión de la mensajería, se deberá seleccionar la opción que solo dice AMEX.
   3. El tipo de conexión puede variar entre las siguientes opciones:
      1. TCP/IP X 1: Utilizado cuando existe una única conexión con el centro autorizador sobre protocolo TCP/IP.
      2. TCP/IP X 2: Utilizado cuando existen dos conexiones con el centro autorizador sobre protocolo TCP/IP.
      3. TCP/IP PR1000 X 1: Utilizado cuando el cliente cuenta con el router PR1000 para establecer una única conexión (X25) con el centro autorizador.
      4. TCP/IP PR1000 X 2: Utilizado cuando el cliente cuenta con el router PR1000 para establecer dos conexiónes (X25) con el centro autorizador.
      5. Not Enabled: Esta opción es utilizada para deshabilitar el uso del canal seleccionado.
      6. X25 Protocol: Utilizado cuando la conexión con el centro autorizador es via X25 utilizando una placa para tal fin en el servidor.
      7. TCP/IP With Echo X 1: Opción utilizada exclusivamente en el caso de VISA para realizar una única conexión TCP/IP con Echo.
      8. TCP/IP With Echo X 2: Opción utilizada exclusivamente en el caso de VISA para establecer dos conexiones TCP/IP con Echo.

8. 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:

1. 1. El identificador del nodo dentro del clúster
   2. La descripción del nodo del clúster. Esta descripción se visualizará en la consola de administración
   3. 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
   4. La zona horaria en la cual se está instalando la aplicación
   5. El directorio donde la aplicación VTOL almacenará la llave maestra. En una re-instalación se debe seleccionar el directorio existente de la instalación previa.

9. 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

10. La finalización de la instalación se informa mediante un mensaje de "Terminado".
Oprimir "Aceptar".

11. Presionar el botón "Salir" para salir del instalador.

7.2.2 Componentes instalados

Finalizada la pre-instalación se visualizarán los componentes dentro de la carpeta 'rsvtol' de la siguiente forma:

7.3 Configuración de la base de datos

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.

7.3.1 Creación

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. "1-CONSOLE-SCHEMA.sql"
2. "2-CORE-SCHEMA.sql"
3. "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-ar/nombreMotorBD
, en el siguiente orden:

1. "1-CD-AR-SCHEMA.SQL"
2. "2-CD-AR-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

Cuando el motor de base de datos sea MSSQL, tiene que estar activo el isolation level “READ_COMMITTED_SNAPSHOT”. Para activarlo se debe ejecutar el siguiente comando:

ALTER DATABASE [nombre_bbdd] SET READ_COMMITTED_SNAPSHOT On;

Donde nombre_bbdd es el nombre de la base de datos.

Nota: Para que el cambio surja efecto, no debe haber conexiones activas salvo la indicada anteriormente.

7.3.2 Actualización

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-ar/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
      

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.

7.3.3 Permisos en Base de Datos

Asegurarse que el usuario de la Base de datos de VTOL, tenga el siguiente permiso, para el motor SQL SERVER:

• VIEW SERVER STATE

Este permiso es requerido para la correcta ejecución del proceso de depuración de transacciones.

7.4 Instalación de certificado para protocolo HTTPS

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.

7.4.1 Definición y Norma

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.

7.4.2 Uso de certificados

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.

7.4.3 Instalación de certificado

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

7.5 Configuración de auditoría de software base

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.

7.5.1 Auditoria aplicación

Para los siguientes directorios es necesario activar el registro de auditoria nativo del sistema operativo para las acciones señaladas por la columna "Auditar".

7.5.2 Auditoria base de datos

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".

7.6 Aseguramiento de puertos

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.

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.

7.6.1 Puertos

Se mencionan los números de puertos que se utilizan en un entorno VTOL:

• POS - EMV KIT: 3500 (EMV KIT escucha ese puerto)
• EMV KIT - 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.6.2 Modificar el puerto http de consola en wildfly

Para cambiar el puerto http de las consolas en wildfly se debe editar el archivo ../configuration/standalone.xml en la sección:

<socket-binding-group name="standard-sockets"

Editar los puertos http:

<socket-binding name="http" port="${jboss.http.port:8080}"/>

<socket-binding name="https" port="${jboss.https.port:8443}"/>

Por ejemplo para que tome los puertos 8282 y 8445 respectivamente:

<socket-binding name="http" port="${jboss.http.port:8282}"/>

<socket-binding name="https" port="${jboss.https.port:8445}"/>

Además se debe cambiar la propiedad de conexión remota en base de datos en la tabla rs_system_property. Siguiendo el ejemplo debería quedar de la siguiente manera:

Property_key: remoteJDNI.environment(java.naming.provider.url)

new_value: remoting://localhost:8282

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.

8. Instalación de EMV KIT

EMV KIT posee la siguiente estructura de directorios:

8.1 Configuración de EMV KIT

Para que EMV KIT funcione correctamente se deben configurar los siguientes archivos:

9. Iniciar / detener la aplicación

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

9.1.1 Iniciar VTOL Engine como proceso

Para iniciarlo como proceso:

1. Iniciar sesión en el sistema operativo
2. Ejecutar uno de los archivos VTOLEngine-Start.cmd (Windows) o VTOLEngine-Start.sh (Linux)

9.1.2 Iniciar VTOL Engine como servicio

Para iniciarlo como servicio:

1. Iniciar sesión en el sistema operativo
2. 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.
3. Ejecutar el archivo VTOLEngine-add-service (Windows)
4. Se creará el servicio llamado: NapseVTOLEngineCrDb

Para eliminar el servicio:

1. Ejecutar el archivo VTOLEngine-remove-service.cmd (Windows)
2. 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 VTOL Admin

Una vez instalada la aplicación hay que iniciar la aplicación VTOL Server. La misma puede ser iniciada de dos maneras:

• Como proceso
• Como servicio (recomendado)

9.2.1 Iniciar/Detener VTOL Admin como proceso

Para iniciar RS-VTOL CR/DB como proceso:

1. Iniciar sesión en el sistema operativo
2. Ejecutar uno de los archivos VTOLAdmin-Start.cmd (Windows) o VTOLAdmin-Start.sh (Linux)

Para detenerlo como proceso:

1. Ejecutar uno de los siguientes archivos: VTOLAdmin-Stop.bat (Windows) o VTOLAdmin-Stop.sh (Linux)

9.2.2 Iniciar VTOL Admin como servicio

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. También 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 instalar el servicio:

1. Iniciar sesión en el sistema operativo
2. 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.
3. Ejecutar el archivo VTOLAdmin-add-service (Windows)
4. Se creará el servicio llamado: NapseVTOLAdminCrDb

Para eliminar el servicio:

1. Ejecutar el archivo VTOLAdmin-remove-service.cmd (Windows)
2. 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.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:

1. Instalar o detener la aplicación RSVTOL.
2. 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:

1. 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:

1. 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

9.3 EMV KIT

Una vez configurado EMV KIT, se debe iniciar. Este componente puede ser iniciado de dos maneras:

• Como proceso
• Como servicio (recomendado)

9.3.1 Iniciar EMV KIT como proceso

Para iniciar EMV KIT como proceso, ejecutar uno de los archivos start.cmd (Windows) o start.sh (Linux).

9.3.2 Iniciar EMV KIT como servicio

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 

10. Acceso administrativo a VTOL

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 S3 se utiliza un certificado como se indica en el punto 7.4 Instalación de certificado para protocolo HTTPS.

No podrán existir dos sesiones activas de un mismo usuario en páginas/navegadores paralelos.

11. Configuración inicial del sistema

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.

11.1 Primer inicio de sesión

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.

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".

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"

11.2 Configuración de la aplicación VTOL

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:

1. "Acceso Consola"
2. "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

11.2.1 Configuración de variables del sistema

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.

A continuación se listan más propiedades disponibles para configurar en el sistema.

11.3 Configuración para la depuración de datos

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

11.3.1 Pasos para la Configuración

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

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.

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".

11.3.1.2 Depuración información de operación de VTOL CR-DB habilitada

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.

11.3.1.3 Planificación proceso de depuración de datos históricos

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.

11.3.1.4 Depuración de tablas

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.

12. Administración de usuarios y claves de la aplicación

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.

12.1 Administración de usuarios para acceso administrativo WEB

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:

1. Iniciar sesión en la consola de administración web.
   1. El usuario debe tener los siguientes permisos
      1. "Acceso a la aplicación"
      2. "Acceso a la consola de Administración de Usuarios, grupos y roles"
      3. "Creación, modificación y eliminación de usuarios, grupos y permisos"
   2. Referirse al capítulo 10. Acceso administrativo a VTOL
2. Ir a la sección "Seguridad  Usuarios"
3. Administrar las cuentas de usuarios
   1. Las mismas deben seguir las políticas señaladas en el anexo 17.1 Políticas generales de usuario y contraseñas
   2. 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 "usuarios" y "GRUPOS" del documento "VTOL-CORE-Manual de usuario.pdf".

12.2 Administración de claves para el almacenamiento de datos sensibles

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.

12.2.1 Descripción técnica de la encriptación de datos

Los datos se encriptan utilizando el algoritmo AES con llaves de 256 bits.
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.

El archivo "master.key" posee el siguiente formato:

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

12.2.2 Descripción funcional de la encriptación de datos

Funcionalmente la aplicación posee los siguientes mecanismos donde se realiza alguna gestión de las claves de encriptación:

1. Administración automática por el sistema en operatoria normal
2. Administración forzada por un custodio
3. 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.

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.

12.2.2.2 Administración forzada por un custodio

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

A continuación se describe el procedimiento para forzar la creación de claves de encriptación nuevas

1. Acceder a la consola de administración web. Para mayor referencia ver 10. Acceso administrativo a VTOL
2. Acceder a la opción "Herramientas administrativas" > "Claves de Encriptación" como se muestra en la figura:
   1. Los permisos que se requieren a nivel sistema VTOL son los siguientes:
      1. "Acceso a la administración de contraseñas encriptadas"
      2. "Agregar una nueva contraseña encriptada"

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.

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.

13. Auditoria y eventos del sistema

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 S3.
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

13.1 Archivos de log

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.

VTOL Server generará 3 archivos de log:

• boot.log
• console.log
• server.log

13.1.1 Formato

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:

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

13.1.2 Centralización

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".

13.1.3 Activar log de VTOL Admin en modo debug

A continuación, se explica como activar el log de VTOL Admin (Consola VTOL Server) en modo DEBUG, a fin de contar con más información para el análisis de incidentes.

• Detener el servicio de VTOL Admin (consola VTOL Server).
• Hacer una copia de seguridad del archivo log4j.xml:
  
  • <directorio Instalación VTOL>\deployments\rs-vtol.ear\META-INF\log4j.xml
• Editar el archivo log4j.xml agregando la siguiente configuración en la "sección" CORE Categories:

    <category name="com.synthesis.vtol.core.rest">
		<priority value="DEBUG"/>
		<appender-ref ref="FILE"/>
	</category>

	<category name="org.apache.http">
		<priority value="DEBUG"/>
		<appender-ref ref="FILE"/>
	</category>

• Iniciar el servicio de VTOL Admin (consola VTOL Server).

Ejemplo de la configuración final, luego de edtiar el archivo:

    <!-- Cambiar a DEBUG para chequear publicacion del MBean HASingleton que determina el nodo maestro -->
    <category name="com.synthesis.vtol.core.cluster.member">
        <priority value="INFO"/>
    </category>
    
    <category name="com.synthesis.vtol.core.utils.LogSensitiveInfo">
   			<priority value="DEBUG" />
        <appender-ref ref="SensitiveDataFile"/>
    </category>

    <category name="com.synthesis.vtol.console.action" additivity="false">
        <priority value="DEBUG"/>
        <appender-ref ref="FILE"/>		
    </category> 

    <category name="com.synthesis.vtol.core.rest">
		<priority value="DEBUG"/>
		<appender-ref ref="FILE"/>
	</category>

	<category name="org.apache.http">
		<priority value="DEBUG"/>
		<appender-ref ref="FILE"/>
	</category>

13.2 Auditoría en base de datos

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.

13.2.1 Formato

La tabla RS_AUDIT posee la siguiente información con el siguiente formato:

13.2.2 Centralización

La centralización de la información de esta 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:

14. Información de datos sensibles

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

14.1 Base de datos

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 sensibles de las tarjetas que se detallan a continuación son almacenados de forma encriptada utilizando el algoritmo de encriptación AES-256 con clave de encripción administrable automáticamente por el sistema (no requiere intervención del usuario).

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.

14.2 Archivos de log

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 AES-256 y podrán ser desencriptados únicamente por personal calificado de servicios de atención a del cliente de Napse. 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.

14.3 Reportes de transacciones

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"

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.

15. Guía de resolución de problemas

En caso de que se presente un problema en la aplicación VTOL se deberá seguir el procedimiento descrito en éste capítulo.

15.1 Introducción

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.

15.2 Procedimiento

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 Napse.
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 Napse. 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 Napse 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.

15.3 Activación del modo DEBUG

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 Napse así lo indique, por ejemplo:

• • Datos inválidos
  • Error de lectura de tarjeta
  • etc

El procedimiento para llevar a cabo tal acción es el siguiente:

1. Un usuario con los siguiente permisos accede a la consola de administración web de VTOL
   1. "Acceso a la aplicación"
   2. "Configuración del sistema"
2. 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 enviados 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 Napse, que lo guiará para proceder al envío del log de manera segura al SFTP, provisto por Napse.

6. Una vez finalizado el envío del log al SFTP de Napse, 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.).

16. Guía de configuración conforme a PCI

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 AES (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.

17. Anexos

17.1 Políticas generales de usuario y contraseñas

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.

17.2 Herramienta para el borrado seguro de datos

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:

1. en sistemas Linux: "Manual Borrado Seguro Linux.pdf"
2. 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 S3 en cuanto al borrado de datos sensibles.

17.3 Obtención de la versión de VTOL instalada

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-ar/ChangeLog.txt

Ejemplo de un "ChangeLog":

---------------------------------------------------------------------------

VERSION: 3.8.X

---------------------------------------------------------------------------
* MEJORA o CAMBIO 1
* MEJORA o CAMBIO 2
---------------------------------------------------------------------------
VERSION: 3.8.1.X

---------------------------------------------------------------------------
* 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.

17.4 Esquema instalación en clúster

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".

17.4.1 Configuración de protocolos para iniciar VTOL en cluster

VTOL Server por defecto está configurado para iniciar el Cluster utilizando el protocolo UDP. Pero soporta también la utilización del protocolo TCP. A continuación, se detalla cómo configurar el uso de cada uno de ellos.

17.4.1.1 Utilizando protocolo UDP

Este es el protocolo utilizado por defecto. Permite que los nodos se incorporen dinámicamente al cluster a medida que van iniciando, sin necesidad de que se conozcan previamente.

La configuración de JGroup se encuentra en el archivo /dist/config/udp.xml. Además, es necesario tener configuradas las siguientes propiedades de sistema:

Ejemplo de configuración extraído del archivo de inicio de VTOL start.bat:

set JAVA_OPTS= %JAVA_OPTS% -Djgroups.udp.mcast_port=45500 
set JAVA_OPTS= %JAVA_OPTS% -Djgroups.udp.mcast_addr=228.1.2.3

17.4.1.2 Utilizando protocolo TCP

En entornos donde los paquetes UDP se pierden suele ser necesario configurar la aplicación para que inicie el Cluster utilizando el protocolo TCP. El cual se requiere que se conozcan las IP de cada uno de los nodos y que se configuren de manera estática antes de iniciar el Cluster.

Para configurar el uso del protocolo TCP se deben seguir los siguientes pasos:

• Editar el archivo /dist/config/vtol-core-spring-conf.xml asignando el valor tcp.xml a la propiedad jgroupFileName del bean ClusterManager:

<!-- ClusterManager object definition -->
       <bean id="ClusterManager" class="com.synthesis.vtol.core.cluster.ClusterManager" init-method="initialize" scope="singleton" >
             <property name="clusterAbstractFactory">
                    <ref bean="VTOLClusterFactory"/>
             </property>
             <property name="mbeanNameResolver">
                    <ref bean="VtolCoreMBeanNameResolver"/>
             </property>
             <property name="jgroupFileName" value="tcp.xml"/>
       </bean>

• Editar el archivo /dist/config/tcp.xml configurando el atributo initial_hosts con los valores de IP y puertos de los servidores o nodos para habilitar la conexión de cluster. La lista tiene el formato: IP1[puerto1],IP2[puerto2],…,IPn[puerton].

<TCPPING async_discovery="true"
        initial_hosts="${jgroups.tcpping.initial_hosts:cluster.nodes}" 
		port_range="2"/>

Ejemplo:

Si el Cluster tuviera 2 nodos con los siguientes datos:

La configuración en el archivo tcp.xml quedaría de la siguiente manera:

<TCPPING async_discovery="true"

initial_hosts="${jgroups.tcpping.initial_hosts:10.14.4.1[7800],10.14.4.2[7800]}"

port_range="2"/>

Aclaración:

• No debe haber espacios intermedios
• El orden de las IP no afecta la formación del Cluster

• Al igual que el protocolo UDP, TCP también requiere que en cada nodo se configuren dos propiedades de sistema. Estas propiedades van a indicar justamente cual es la IP y puerto sobre la que se habilita la conexión de Cluster

• En el archivo de inicio de VTOL start.bat eliminar las propiedades:
  • -Djgroups.udp.mcast_port
  • -Djgroups.udp.mcast_addr

y agregar las propiedades:

• • -Djgroups.bind_port=7800
  • -Djgroups.bind_addr= IP server

set JAVA_OPTS= %JAVA_OPTS% -Djgroups.bind_port=7800 
set JAVA_OPTS= %JAVA_OPTS% -Djgroups.bind_addr=10.4.14.1

17.4.2 Pruebas de la funcionalidad en Cluster

Al iniciar la aplicación se puede verificar en log la existencia de mayor información sobre el Cluster y cuál nodo inicia como Maestro. Al iniciar otro nodo, en el log se debe visualizar que se convierte en un miembro del Cluster, iniciando como esclavo.

También se puede verificar el estado del Cluster a través de la consola Web, más precisamente en la página de Monitoreo General del Sistema, donde se puede observar la siguiente información:

17.4.3 Desactivar funcionalidad de Cluster

Para desactivar la funcionalidad de cluster, se debe configurar un solo nodo por TCP, es decir la ip local + puerto local.

La recomendación es que la IP definida para clustering coincida con la IP de Bindeo que se define en el parámetro -b, al iniciar la aplicación. Si este parámetro tiene una IP explicita, la configuración de clustering debería hacerse sobre la misma IP.

Por ejemplo si en el archivo de inicio de la aplicación se encuentra la siguiente configuración:

cd C:\wildfly-18.0.1.Final/bin
start standalone.bat -b 10.4.3.1 -Djboss.server.base.dir=C:\wildfly-18.0.1.Final/rsvtol -Dorg.jboss.boot.log.file=${jboss.server.log.dir}/boot.log

 Entonces la configuración de la IP a utilizar para clustering debe ser 10.4.3.1

17.5 Cambio de usuario y/o contraseña de base de datos

En los casos donde el usuario y/o la contraseña utilizados por la aplicación VTOL cambien, se deberá seguir el siguiente procedimiento:

1. Detener la aplicación VTOL
   1. referirse a 9. Iniciar / detener la aplicación
2. Configurar los datasources de la aplicación
   1. referirse a la sección 17.6.2 Configuración de Datasources
3. Iniciar de nuevo la aplicación VTOL
   1. referirse a 9. Iniciar / detener la aplicación

17.6 Configuración del Servidor de Aplicaciones JBOSS

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:

1. Conexiones a base de datos o DataSources
2. Login
3. Servidor Web
4. Etc

En este apartado se describen los pasos a seguir para configurar correctamente el JBOSS y todos sus componentes.

17.6.1 Copia de la configuración del server Standalone

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'.

17.6.2 Configuración de Datasources

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">:

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:

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 u oracle

Napse 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">:

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:

Donde contraseña es la clave que se desea encriptar.
El resultado obtenido debe ser configurado en el lugar jdbcpassword de la EncryptDBPassword.

17.6.3 Login

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">:

17.6.4 Seguridad Consola Web

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">:

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">:

17.6.5 Configuración de Contenedor Web

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:

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

17.6.6 Archivos Carpeta bin

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

Linux
start.sh

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

Linux
stop.sh

Donde:

• Jboss es la carpeta del servidor de aplicaciones

17.6.7 Configuración del Log

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.

<param name="ConversionPattern" value="%d %-5p \[%-20.20c\{1\}\] \[%t\] %m%n"/>

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

17.7 Configuraciones del sistema operativo y base de datos

17.7.1 Archivos del sistema

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)

1. Ir a las "Propiedades" del sistema
2. 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)

1. Haga clic con el botón derecho en Equipo y seleccione Propiedades
2. 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:

1. • 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)

1. Abra el Panel de control
2. Abra el Centro de Acción
3. 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:

1. 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.
2. Haga clic en Habilitar actualización automática y retroalimentación en el área Actualizar este servidor.
3. En el cuadro de diálogo Habilitar actualización automática y retroalimentación, haga clic en Configurar manualmente la configuración.
4. En el área Informe de errores de Windows del cuadro de diálogo Configurar manualmente configuración, haga clic en Cambiar configuración.
5. 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.
6. En el cuadro de diálogo Configurar manualmente Configuración, haga clic en Cerrar.

Para deshabilitar Windows Error Reporting mediante Server Manager:

1. Abra el Administrador de servidores haciendo clic en Inicio, seleccione Herramientas administrativas ya continuación, haga clic en Administrador de servidores.
2. En la página de inicio de Server Manager, expanda el área Recursos y soporte si aún no está abierto.
3. Haga clic en Configurar informes de errores de Windows.
4. 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)

1. 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.

17.7.2 Registros de auditoría

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\

17.7.3 Auditoría de base de datos

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.

Asegurarse que el usuario de la Base de datos de VTOL, tenga el siguiente permiso, para el motor SQL SERVER:

• VIEW SERVER STATE

Este permiso es requerido para la correcta ejecución del proceso de depuración de transacciones.

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.

17.7.3.2 Oracle

17.7.3.2.1 Activar o desactivar la pista de auditoría estándar  

1. Iniciar Control de base de datos.
2. 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
3. Haga clic en Servidor para mostrar la subpágina Servidor.
4. 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.
5. 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.
6. 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.
7. 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)
8. Click en Aplicar.
9. Reinicie la instancia de Oracle:
   1. Haga clic en el vínculo Instancia de base de datos.
   2. Haga clic en Inicio para ver la página principal de Control de bases de datos.
   3. Haga clic en Apagar.
   4. Luego ingrese sus credenciales.
   5. Una vez finalizada la desconexión, haga clic en Inicio.

17.8 Formulario de Clave Custodio de VTOL

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: ____________________________________________________

17.9 Flujograma del Proceso de Autorización

17.9.1 Punto de venta

Diagrama del proceso de Autorización de Datos (Punto de Venta) de alto nivel

 Diagrama del proceso de Autorización de Datos (Punto de Venta) de bajo nivel

A continuación, se detalla el flujo con cada una de las actividades que realizan los diferentes actores en el proceso de Autorización de datos: 

1. El flujo inicia desde el punto de venta o POS cuando se selecciona el tipo de transacción (venta, anulación o devolución) y el medio de pago ya sea tarjeta de crédito o débito. Para este caso del medio de pago tarjeta, la aplicación del punto de venta avanza con la solicitud de transacción en EMV KIT.
2. EMV KIT, a través del terminal de captura o 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 solicita ingresar uno u otros datos propios de la tarjeta, como es el código de seguridad, la fecha de vencimiento, entre otro.
3. Una vez que EMV KIT haya capturado todos los datos del tarjetahabiente procesa los datos de la tarjeta, y luego procede a enviar a VTOL Server la transacción para autorizar, la cual tendrá asociado un tipo de transacción (venta, devolución, anulación) el cual dependerá del tipo de acción que se realiza en el punto de venta.
4. VTOL Server, al recibir los datos, valida que los mismos sean correctos para el tipo de transacción seleccionada por el POS, en donde se puede presentar lo siguiente:
   1. Si algún dato es inválido, VTOL Server finaliza la transacción y devuelve el control al POS indicando el error.
   2. 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.
5. Luego de validar que la información de las reglas de negocio en la base de datos sea correcta, entonces se envía el mensaje de requerimiento al Centro Autorizados correspondiente.
6. El Centro Autorizador recibe el requerimiento y le envía la respuesta de la autorización a VTOL Server.
7. Vtol Server guarda en la base de datos la respuesta del Centro autorizador y le comunica a EMVKIT el mensaje de respuesta con los datos. 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.
8. El POS recibe los datos de la transacción, en donde se pueden presentar los siguientes casos:

1. 1. Si la transacción está aprobada, entonces se continua con la impresión de Voucher y se confirma la transacción. VTOL Server recibe esta información del tercer mensaje del POS en donde deberá borrar los datos encriptados y se finaliza el proceso en el POS.
   2. Si la transacción no está aprobada, entonces el POS valida el error y cancela la transacción. VTOL Server recibe en el tercer mensaje del POS la cancelación de la transacción, se borran los datos encriptados que fueron anteriormente guardados, le solicita el reverso al Centro Autorizador y se finaliza el proceso en el POS.

En ambos casos del punto 8. se finaliza el proceso en el POS.

17.9.2 E-commerce

Diagrama de E-commerce de Alto Nivel

Diagrama de proceso Autorización de datos (E-commerce) de Bajo Nivel

A continuación, se detalla el flujo con cada una de las actividades que realizan los diferentes actores en el proceso de Autorización de datos: 

1. El proceso inicia cuando el usuario realiza la compra de los productos seleccionados en el comercio electrónico e ingresa los datos de su tarjeta en la plataforma web.
2. 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).
3. VTOL Server, al recibir los datos, valida que sean correctos para el tipo de transacción seleccionada por el comercio electrónico, en donde se puede presentar lo siguiente: AQUI
   1. Si cualquier dato no es válido, VTOL Server finaliza la transacción y devuelve el control al comercio electrónico indicando el error.
   2. Si los datos son correctos, se procede a la ejecución de las reglas de negocio asociadas al tipo de transacción que se ejecutan y se envía la autorización al centro autorizador correspondiente (Visa, Amex, etc.), entre las reglas de negocio 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.

4. 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 cifrados sólidos. Una vez completado el mismo, los datos de autorización se responden al comercio electrónico.
5. 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).
6. 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.

18. Cambio de carpeta de log para la aplicación

La siguiente configuración permite cambiar la carpeta donde se registran los logs de VTOL.

La manera más transparente de realizar el cambio de la carpeta de logs es cambiar las siguientes variables de sistema para la aplicación:

• jboss.server.log.dir: representa la ruta donde se registran los logs de la aplicación iniciada a través de JBoss. En nuestro caso los logs boot.log y console.log de VTOL Admin. Cambiando esta variable ya no se debe tocar ninguna configuración adicional de standalone.xml, ni el log4j.xml del ear.

Configuración: En el archivo de inicio VTOLAdmin-Start.cmd se debe agregar la configuración de la variable de la siguiente manera:

set JAVA_OPTS= %JAVA_OPTS% -Djboss.server.log.dir=[new_log_path]

• log4j.logPath: representa la ruta donde se registrarán los logs de VTOL Engine: server.log, conciliation.log y sysout.log. Configurando esta variable, automáticamente funcionará la descarga de log de la aplicación, ya que se utiliza en dicha funcionalidad.

Configuración: En el archivo de inicio VTOLEngine-Start.cmd se debe agregar la configuración de la variable de la siguiente manera:

set JAVA_OPTS= %JAVA_OPTS% -Dlog4j.logPath=[new_log_path]

19. Glosario