La mejor manera sin duda alguna de reducir el ámbito de aplicación de PCI-DSS sobre cualquier sistema que trate datos de tarjeta, resulta tan eficaz como obvia:
no usar datos de tarjeta.
Lamentablemente, no siempre es posible, por lo que una buena aproximación puede ser la tokenización de estos datos de tarjeta; otra sería el cifrado, del cual podemos hablar en otro artículo si algún lector está interesado.
En este artículo trataremos el tema de la tokenización en relación a PCI-DSS, repasando los conceptos básicos de la tokenización, hasta mostrar un diseño básico de implementación de un tokenizador para las tarjetas de pago empleando los servicios en la nube de Amazon Web Services.
Hemos dividido el artículo en dos partes:
Definiciones y conceptos previos:
Acquirer: también se lo conoce como "banco adquirente" o "institución financiera adquirente", es la entidad bancaria que ofrece al comercio el procesado de sus transacciones de tarjetas de pago, y por lo tanto existirá un contrato entre el adquiriente y el comercio para la prestación de dichos servicios. El adquiriente está reconocido por una marca de pago como tal (Visa los denomina como “Visa Europe member”), y se encuentran sujetos a las reglas y procedimientos de las marcas de pago con respecto al cumplimiento del comerciante.
Issuer: También se lo conoce como "banco emisor" o "entidad financiera emisora", es la entidad bancaria responsable o que respalda la emisión de las tarjeta bancarias a su titular junto con el PIN, o que presta servicios de emisión relacionados (p.ejem. servicio de autenticación de las transacciones).
Processing: operaciones entre una o varias redes de pagos que incluye los servicios de:
Nota aclaratoria: En España, tenemos una casuística un poco especial, ya que en la práctica los adquirientes no realizan el procesado de las transacciones, esa función la delegan en sus procesadores de pago (Redsys o Cecabank ), que prestan el servicio en su nombre de manera trasparente para el comercio (son denominados “member agent” por Visa), las cuales a su vez están conectadas a redes de pagos para operativas internacionales (Visa,Mastercard, UnionPay, AMEX, etc.) y nacionales (por un lado ServiRed y Sistema 4B , dependientes de Redsys, y por otro euro6000 , dependiente de Cecabank); cómo ver una red de pago de forma simplificada, como un procesador junto con varias entidades bancarias adheridas. La fusión entre las diversas redes de pago nacionales fue aprobada por la CNMV el pasado 1 de febrero del 2018.
Datos sensibles de autenticación: son los datos correspondientes a la banda magnética o datos equivalentes en chip de la tarjeta, el CAV2/CVC2/CVV2/CID, o el PINs/PIN blocks.
Pre-authorizatoin: también abreviado como “pre-auth”, en esta operación únicamente existe un flujo de información, no se lleva a cabo ningún flujo contable. Típicamente, cuando un comercio recaba los datos de tarjeta para un pago pero no va a procesarlo hasta pasado un tiempo, p.ejem. al generar las reservas en hoteles, cuyo cobro muchas veces no se realiza hasta el check-out, o en el alquiler de vehículos, se lanza una pre-autorización con el objetivo único de validar que la tarjeta existe, se encuentra activa y tiene fondos suficientes (nunca puede ser con un importe superior al total final). Ésta “pre-auth” expirará normalmente en los siguientes 7 días para MASTERCARD o en 30 días para VISA en caso de que finalmente no se acabe realizando la “authorization” por la totalidad del importe (estos periodos suelen variar en cada marca de tarjeta según el Merchant Category Code (MCC) asignado a la entidad. En el caso de tarjetas de crédito, esta “reserva” se suele visualizar como un decremento en el límite de crédito en la cuenta destino; en el caso de las de débito, de suele observar como un asiento contable temporal.
Pregunta: ¿A qué nos referimos con tokenización en el mundo PCI-DSS?
Respuesta corta: PCI-DSS aplica sobre los datos de tarjeta, si en su lugar tenemos un token…. quizás pueda evitar que me aplique PCI-DSS.
Respuesta larga: La idea subyacente de la tokenización es simple: transmutar algo valioso y útil como es un PAN en algo que no vale nada por sí mismo, como es un identificador formado por una secuencia de dígitos y/o caracteres que llamaremos token, y que solo puede ser usado para iniciar una transacción dentro de un contexto determinado (una aplicación, sistema, etc.). Para saber identificar si estamos realizando una adecuada implantación de nuestro sistema de tokenización debemos tener presente en todo momento esta máxima; en el momento en que un atacante pudiese darle valor a ese token en otros contextos no autorizados (i.e. emplearlo para realizar una transacción cuando y donde quiera, p.ejem. en otros comercios), nuestra solución dejará de ser viable, al menos para el propósito de reducir el alcance de PCI-DSS.
Pregunta: ¿qué datos puedo tokenizar?
Respuesta corta: según el requerimiento 3.2 de PCI-DSS, todo dato de tarjeta es tokenizable salvo los datos sensibles de autenticación (banda magnética o datos equivalentes en chip, CAV2/CVC2/CVV2/CID, y PINs/PIN blocks)
Respuesta larga: en caso de que llegásemos a generar un token a partir de estos datos sensibles antes de realizar la “Authorization”, deberá ser tratado tal y como se haría con el dato en claro, debiendo ser igualmente borrado una vez se haya recibido la autorización de la transacción , cuya única excepción será en caso de que seamos un emisor de tarjetas o participemos en la emisión de las mismas. En este sentido, es importante tener claro el concepto de “pre-authorization” frente al de “authorization” de una transacción que describimos en el apartado inicial “Definiciones y conceptos previos”. Mientras dure la “pre-authorization”, los datos sensibles de autenticación o el token generado en su lugar, podrán ser almacenados.
Pregunta: ¿Qué tipos de tokens existen? ¿aplica PCI-DSS sobre todos ellos?
Respuesta corta: Varios, incluso podemos tener diferentes formas de clasificarlos, dependiendo de quién los genera y emite, con qué límites se pueden emplear (en qué contexto o si puede ser empleada más de una vez); cada uno tiene sus ventajas e inconvenientes y sobre algunos no aplica PCI-DSS.
Respuesta larga:
Según PCI-DSS, tenemos los siguientes tipos de tokens:
Respuesta corta: como la mayoría de las cosas en la vida, depende y mucho, y en este aspecto el PCI SSC no concreta más de lo estrictamente necesario, dejándolo a criterio de las marcas de pago y adquirientes según cada caso.
Respuesta larga: de manera muy resumida, tenemos dos grandes opciones si decidimos aplicar tokenización para reducir el alcance de PCI-DSS (mostradas de mayor reducción del entorno a menos, y dejando de lado otras soluciones híbridas que habría que analizar en cada caso concreto):
Opción 1) Contratar los servicios de un proveedor de tokenización de manera que únicamente almacenemos, procesemos o trasmitamos tokens en nuestros sistemas. En este escenario, dependerá de cómo integremos en nuestros sistemas la pasarela del proveedor de tokenización, a modo ilustrativo y no limitativo, podríamos tener que:
Opción 2) Montar nuestro propio tokenizador (estaríamos generando los llamados “acquiring tokens”), de manera que al menos una parte de nuestro entorno única y exclusivamente tenga acceso a los tokens, no esté conectado el sistema o red directamente a la zona del tokenizador y no tenga acceso a la obtención de los PANs o funciones/API que devuelvan el PAN a partir de los datos que posea.
En este escenario, por norma general, sobre el entorno que procese/almacene o transmita únicamente los tokens, podríamos dejarlo fuera del alcance de PCI-DSS (en caso de duda, siempre se deberá acudir a un PCI-DSS QSA debidamente acreditado, el cual valorará esta exclusión del alcance).
Finalmente, se nos presenta un dilema cuando revisamos la guía emitida por el PCI SSC relativa a la generación de “acquiring tokens” que lleva por título “ Information Supplement - PCI DSS Tokenization Guidelines” (importante notar que, al fin y al cabo, son eso: “guías”, no se consideran parte de la norma), en su página 20 nos presenta lo que llama “ high-value tokens”, que al parecer son todos aquellos tokens que permitan iniciar una transacción por sí mismos, en cuyo caso, serán consideramos como si fuesen PANs en claro y les aplicarán los mismos requerimientos de PCI-DSS.
En este sentido, y como opinión personal después de que tras años de la aparición de dicha guía, aún no se haya especificado nada más concreto y clarificador de qué es un “ high-value token”, es necesario una evaluación detallada de cada implementación por un PCI-DSS QSA, con el fin de determinar si ese token es o no de este tipo en base a: cómo se genera, en qué contexto se puede usar, cual es el riesgo real de fraude, etc.
En el siguiente capítulo…
En el próximo capítulo, Diseño básico de una solución en AWS, presentaremos el código básico y diseño de la arquitectura serverless que pretendemos desplegar a modo de prueba de concepto en nuestra cuenta de Amazon Web Services ( https://aws.amazon.com), empleando, entre otros, los servicios de AWS API Gateway, AWS Lamda, etc…
Autor: Ero Rodríguez Losada - CISA, CRISC, PCI QSA, PCIP, ISO 22301 L.A., ITILF
Dpto. Consultoría
Lamentablemente, no siempre es posible, por lo que una buena aproximación puede ser la tokenización de estos datos de tarjeta; otra sería el cifrado, del cual podemos hablar en otro artículo si algún lector está interesado.
En este artículo trataremos el tema de la tokenización en relación a PCI-DSS, repasando los conceptos básicos de la tokenización, hasta mostrar un diseño básico de implementación de un tokenizador para las tarjetas de pago empleando los servicios en la nube de Amazon Web Services.
Hemos dividido el artículo en dos partes:
- Capítulo 1: Tokenización, ¿qué, por qué y para qué?
- Capítulo 2: Diseño básico de una solución en AWS
Capítulo 1. Tokenización, ¿qué, por qué y para qué?
Antes de entrar en materia, esta primera parte la dedicaremos a clarificar algunas preguntas frecuentes que suelen surgir al respecto de la tokenización así como algunas confusiones o interpretaciones poco precisas que suelen traer de cabeza a aquellas organizaciones que deciden emprender un proyecto de tokenización en sus servicios.Definiciones y conceptos previos:
Acquirer: también se lo conoce como "banco adquirente" o "institución financiera adquirente", es la entidad bancaria que ofrece al comercio el procesado de sus transacciones de tarjetas de pago, y por lo tanto existirá un contrato entre el adquiriente y el comercio para la prestación de dichos servicios. El adquiriente está reconocido por una marca de pago como tal (Visa los denomina como “Visa Europe member”), y se encuentran sujetos a las reglas y procedimientos de las marcas de pago con respecto al cumplimiento del comerciante.
Issuer: También se lo conoce como "banco emisor" o "entidad financiera emisora", es la entidad bancaria responsable o que respalda la emisión de las tarjeta bancarias a su titular junto con el PIN, o que presta servicios de emisión relacionados (p.ejem. servicio de autenticación de las transacciones).
Processing: operaciones entre una o varias redes de pagos que incluye los servicios de:
- «Authorization» (autorización): garantizar que la transacción sea válida
- «Clearing» (compensación): garantizar la disponibilidad de fondos
- «Settlement» (liquidación): garantizar que el importe se abone y cargue de forma apropiada.
Nota aclaratoria: En España, tenemos una casuística un poco especial, ya que en la práctica los adquirientes no realizan el procesado de las transacciones, esa función la delegan en sus procesadores de pago (Redsys o Cecabank ), que prestan el servicio en su nombre de manera trasparente para el comercio (son denominados “member agent” por Visa), las cuales a su vez están conectadas a redes de pagos para operativas internacionales (Visa,Mastercard, UnionPay, AMEX, etc.) y nacionales (por un lado ServiRed y Sistema 4B , dependientes de Redsys, y por otro euro6000 , dependiente de Cecabank); cómo ver una red de pago de forma simplificada, como un procesador junto con varias entidades bancarias adheridas. La fusión entre las diversas redes de pago nacionales fue aprobada por la CNMV el pasado 1 de febrero del 2018.
Datos sensibles de autenticación: son los datos correspondientes a la banda magnética o datos equivalentes en chip de la tarjeta, el CAV2/CVC2/CVV2/CID, o el PINs/PIN blocks.
Pre-authorizatoin: también abreviado como “pre-auth”, en esta operación únicamente existe un flujo de información, no se lleva a cabo ningún flujo contable. Típicamente, cuando un comercio recaba los datos de tarjeta para un pago pero no va a procesarlo hasta pasado un tiempo, p.ejem. al generar las reservas en hoteles, cuyo cobro muchas veces no se realiza hasta el check-out, o en el alquiler de vehículos, se lanza una pre-autorización con el objetivo único de validar que la tarjeta existe, se encuentra activa y tiene fondos suficientes (nunca puede ser con un importe superior al total final). Ésta “pre-auth” expirará normalmente en los siguientes 7 días para MASTERCARD o en 30 días para VISA en caso de que finalmente no se acabe realizando la “authorization” por la totalidad del importe (estos periodos suelen variar en cada marca de tarjeta según el Merchant Category Code (MCC) asignado a la entidad. En el caso de tarjetas de crédito, esta “reserva” se suele visualizar como un decremento en el límite de crédito en la cuenta destino; en el caso de las de débito, de suele observar como un asiento contable temporal.
Pregunta: ¿A qué nos referimos con tokenización en el mundo PCI-DSS?
Respuesta corta: PCI-DSS aplica sobre los datos de tarjeta, si en su lugar tenemos un token…. quizás pueda evitar que me aplique PCI-DSS.
Respuesta larga: La idea subyacente de la tokenización es simple: transmutar algo valioso y útil como es un PAN en algo que no vale nada por sí mismo, como es un identificador formado por una secuencia de dígitos y/o caracteres que llamaremos token, y que solo puede ser usado para iniciar una transacción dentro de un contexto determinado (una aplicación, sistema, etc.). Para saber identificar si estamos realizando una adecuada implantación de nuestro sistema de tokenización debemos tener presente en todo momento esta máxima; en el momento en que un atacante pudiese darle valor a ese token en otros contextos no autorizados (i.e. emplearlo para realizar una transacción cuando y donde quiera, p.ejem. en otros comercios), nuestra solución dejará de ser viable, al menos para el propósito de reducir el alcance de PCI-DSS.
Pregunta: ¿qué datos puedo tokenizar?
Respuesta corta: según el requerimiento 3.2 de PCI-DSS, todo dato de tarjeta es tokenizable salvo los datos sensibles de autenticación (banda magnética o datos equivalentes en chip, CAV2/CVC2/CVV2/CID, y PINs/PIN blocks)
Respuesta larga: en caso de que llegásemos a generar un token a partir de estos datos sensibles antes de realizar la “Authorization”, deberá ser tratado tal y como se haría con el dato en claro, debiendo ser igualmente borrado una vez se haya recibido la autorización de la transacción , cuya única excepción será en caso de que seamos un emisor de tarjetas o participemos en la emisión de las mismas. En este sentido, es importante tener claro el concepto de “pre-authorization” frente al de “authorization” de una transacción que describimos en el apartado inicial “Definiciones y conceptos previos”. Mientras dure la “pre-authorization”, los datos sensibles de autenticación o el token generado en su lugar, podrán ser almacenados.
Pregunta: ¿Qué tipos de tokens existen? ¿aplica PCI-DSS sobre todos ellos?
Respuesta corta: Varios, incluso podemos tener diferentes formas de clasificarlos, dependiendo de quién los genera y emite, con qué límites se pueden emplear (en qué contexto o si puede ser empleada más de una vez); cada uno tiene sus ventajas e inconvenientes y sobre algunos no aplica PCI-DSS.
Respuesta larga:
Según PCI-DSS, tenemos los siguientes tipos de tokens:
- Acquiring tokens: son tokens generados por el adquiriente, un comercio o un proveedor a partir del PAN original facilitado por el titular de la tarjeta. No sigue ningún estándar o norma, generándose según criterios y formatos que la entidad desee ya que generalmente es solo para su propio uso. Una vez generados, este tipo de tokens no pueden ser empleados para posteriores autorizaciones , a menos que sea para procesar pagos recurrentes ya autorizados (es importante tener en cuenta que para los pagos recurrentes no es necesario conservar los datos sensibles de autenticación una vez ya se ha realizado la primera autorización), o bien si ofrecemos al usuario la posibilidad de almacenar sus PAN para futuras compras, conocido como “card-on-file” por PCI-DSS (en este caso, será necesario solicitar de nuevo al titular los datos sensibles de autenticación para poder autorizar la transacción).
Este tipo de tokens serán los que podremos generar como comercio o proveedor de servicios y será el objeto de nuestro diseño de tokenizador. - Issuer tokens: llamados también electronic-only PANs, Virtual Credit Card (VCC) por VISA o Virtual Card Number (VCN) por MASTERCARD, son generados por los emisores del pago y son indistinguibles de un PAN real. Son ampliamente usados por el sector turístico (p.ejem. Online Travel Agencies (OTA) como Booking.com o Expedia.com, y Global Distribution System (GDS) como Amadeus) en su modalidad “single-use o one-time” ya que una vez empleadas para trasferir el pago a algún comercio como un hotel (entendiéndose el concepto de “empleadas” por el hecho concreto de que ya se ha realizado la autorización de la transacción), no pueden volver a ser usadas para futuras transacciones sin ser rechazadas.
Sobre estos últimos tokens, cuyo acrónimo es SU-VCC/VCN (Single-use Virtual Credit Card/Number), cada una de las marcas de pago determina si le aplica PCI-DSS o no y bajo qué circunstancias; en el caso concreto de VISA y MASTERCARD, a fecha de este artículo, nos indican expresamente que no es necesario protegerlos bajo PCI-DSS (si solo tratamos este tipo de tokens en nuestros sistemas, podríamos no aplicar PCI-DSS sobre éstos). En el caso de VISA matiza una excepción: solo estaremos exentos de aplicar PCI-DSS sobre los mismos si somos el receptor del token (el caso habitual si somos un comercio), pero no si lo emitimos o participamos de algún modo en la emisión de los mismos.
En el caso de que tratemos con MU-VCC/VCN (Multi-use Virtual Credit Card/Number), i.e. tarjetas válidas para más de una transacción, siempre nos aplicará PCI-DSS. - Payment tokens: también llamados EMVCo Payment Tokens, son emitidos a los propios titulares de la tarjeta, así como a los merchants que empleen sus servicios, por los proveedores de tokenización (TSP) registrados bajo el esquema EMVCo Technical Framework y que deben cumplir a su vez con la norma PCI TSP. El titular del token lo puede usar en un comercio como si de una tarjeta real se tratase, y es muy habitual en los pagos “1-Clic” en comercios online donde se busca evitar que el usuario tenga que volver a introducir sus datos de tarjeta. En este escenario, el titular de la tarjeta únicamente emplea el token para realizar el pago, y el comercio únicamente recibe ese token para iniciar la transacción.
Un par de ejemplos típicos en comercio online lo encontramos en Paypal, empleado directamente por el titular de la tarjeta o ApplePay; en el caso del comercio en venta presencial, lo podemos encontrar en tarjetas empleadas por compañías de alquiler de vehículos por horas, donde realizamos el pago de combustible con tarjetas físicas con un token en formato chip.
Cualquier comercio o proveedor que únicamente trate en sus sistemas EMV Payment Tokens, no está obligado a implementar PCI-DSS.
Respuesta corta: como la mayoría de las cosas en la vida, depende y mucho, y en este aspecto el PCI SSC no concreta más de lo estrictamente necesario, dejándolo a criterio de las marcas de pago y adquirientes según cada caso.
Respuesta larga: de manera muy resumida, tenemos dos grandes opciones si decidimos aplicar tokenización para reducir el alcance de PCI-DSS (mostradas de mayor reducción del entorno a menos, y dejando de lado otras soluciones híbridas que habría que analizar en cada caso concreto):
Opción 1) Contratar los servicios de un proveedor de tokenización de manera que únicamente almacenemos, procesemos o trasmitamos tokens en nuestros sistemas. En este escenario, dependerá de cómo integremos en nuestros sistemas la pasarela del proveedor de tokenización, a modo ilustrativo y no limitativo, podríamos tener que:
- Aplicar los requerimientos relativos a un SAQ A/ROCA si somos un comercio o los análogos dentro de un SAQ-DA o ROCA si somos un proveedor, cuando integramos la plataforma del tokenizador en una redirección o iframe donde el titular de la tarjeta introduzca sus datos en una web ajena a la nuestra.
- Aplicar los requerimientos relativos a un SAQ A-EP/ROCA-EP si somos un comercio o los análogos dentro de un SAQ-DA-EP o ROCA-EP si somos un proveedor, cuando integramos la plataforma del tokenizador empleando un formulario de captura de datos del titular de la tarjeta generado por nosotros mediante métodos y acciones Javascript, o una API/Webhook (también llamado “Direct Post”).
- Aplicar los requerimientos relativos a un SAQ D/ROC si capturamos y enviamos los datos de tarjeta vía XML, JSON, otros…
Opción 2) Montar nuestro propio tokenizador (estaríamos generando los llamados “acquiring tokens”), de manera que al menos una parte de nuestro entorno única y exclusivamente tenga acceso a los tokens, no esté conectado el sistema o red directamente a la zona del tokenizador y no tenga acceso a la obtención de los PANs o funciones/API que devuelvan el PAN a partir de los datos que posea.
En este escenario, por norma general, sobre el entorno que procese/almacene o transmita únicamente los tokens, podríamos dejarlo fuera del alcance de PCI-DSS (en caso de duda, siempre se deberá acudir a un PCI-DSS QSA debidamente acreditado, el cual valorará esta exclusión del alcance).
Veamos un clásico ejemplo de mal diseño…
Supongamos que soy un comercio y despliego una solución capaz de tokenizar mis datos de tarjeta (PANs), y qué como resultado, mi solución me devuelve el token más un hash de la tarjeta, los cuales almacenaré en una base de datos que yo, a priori, considero fuera de alcance de PCI-DSS, ya que teóricamente no hay ningún dato de tarjeta…
PAN original: 1111 2222 3333 4444
Token generado: 1111 22ab cdef 4444
Hash: 62530E41812B2028A7B0415237A10DA8475EB5739F36529734C3BB777083E26
En este ejemplo, el algoritmo hash empleado no tiene mayor importancia.
¿y dónde está el problema?
Fijémonos que cualquiera que acceda al token y al hash, podría de manera trivial encontrar por fuerza bruta en un corto tiempo cuales son los valores truncados ya que sólo hay 10^6 combinaciones posibles, y eso sin descartar aquellas combinaciones que no cumplan el algoritmo de Luhn. Por todo esto, podemos llegar a valorar que allá donde se almacene el token más el hash, será equivalente en cuanto a los requerimientos de PCI-DSS aplicables, a tener el PAN en claro almacenado.
Supongamos que soy un comercio y despliego una solución capaz de tokenizar mis datos de tarjeta (PANs), y qué como resultado, mi solución me devuelve el token más un hash de la tarjeta, los cuales almacenaré en una base de datos que yo, a priori, considero fuera de alcance de PCI-DSS, ya que teóricamente no hay ningún dato de tarjeta…
PAN original: 1111 2222 3333 4444
Token generado: 1111 22ab cdef 4444
Hash: 62530E41812B2028A7B0415237A10DA8475EB5739F36529734C3BB777083E26
En este ejemplo, el algoritmo hash empleado no tiene mayor importancia.
¿y dónde está el problema?
Fijémonos que cualquiera que acceda al token y al hash, podría de manera trivial encontrar por fuerza bruta en un corto tiempo cuales son los valores truncados ya que sólo hay 10^6 combinaciones posibles, y eso sin descartar aquellas combinaciones que no cumplan el algoritmo de Luhn. Por todo esto, podemos llegar a valorar que allá donde se almacene el token más el hash, será equivalente en cuanto a los requerimientos de PCI-DSS aplicables, a tener el PAN en claro almacenado.
Finalmente, se nos presenta un dilema cuando revisamos la guía emitida por el PCI SSC relativa a la generación de “acquiring tokens” que lleva por título “ Information Supplement - PCI DSS Tokenization Guidelines” (importante notar que, al fin y al cabo, son eso: “guías”, no se consideran parte de la norma), en su página 20 nos presenta lo que llama “ high-value tokens”, que al parecer son todos aquellos tokens que permitan iniciar una transacción por sí mismos, en cuyo caso, serán consideramos como si fuesen PANs en claro y les aplicarán los mismos requerimientos de PCI-DSS.
En este sentido, y como opinión personal después de que tras años de la aparición de dicha guía, aún no se haya especificado nada más concreto y clarificador de qué es un “ high-value token”, es necesario una evaluación detallada de cada implementación por un PCI-DSS QSA, con el fin de determinar si ese token es o no de este tipo en base a: cómo se genera, en qué contexto se puede usar, cual es el riesgo real de fraude, etc.
En el siguiente capítulo…
En el próximo capítulo, Diseño básico de una solución en AWS, presentaremos el código básico y diseño de la arquitectura serverless que pretendemos desplegar a modo de prueba de concepto en nuestra cuenta de Amazon Web Services ( https://aws.amazon.com), empleando, entre otros, los servicios de AWS API Gateway, AWS Lamda, etc…
Autor: Ero Rodríguez Losada - CISA, CRISC, PCI QSA, PCIP, ISO 22301 L.A., ITILF
Dpto. Consultoría