Consideraciones al elaborar un plan de continuidad de negocio para las Instituciones de Financiamiento Colectivo (crowdfunding)

La tecnología ha habilitado la creación de diferentes modelos de negocio, entre ellos las “Fintech”, empresas que ofrecen servicios financieros mediante tecnología. En México, el sector Fintech está conformado por dos tipos regulados por la CNBV:

• Las Instituciones de Fondos de Pago Electrónico (IFPES), comúnmente conocidas como wallets.
• Las Instituciones de Financiamiento Colectivo (IFC) o comúnmente conocidas como crowdfunding

El presente blog se enfocará en las IFC. El Título III capítulo V de las Disposiciones de Carácter General Aplicables a Instituciones de Tecnología Financiera incluye requerimientos para la continuidad negocio de las IFCs. En los artículos 60 y 61 se menciona que las IFCs deben cumplir con lo establecido en el Anexo 10 para desarrollar su plan de continuidad del negocio (BCP por sus siglas en inglés Business Continuity Plan). En este blog presentaremos algunas estrategias y servicios de AWS pueden contribuir a cubrir los requerimientos estipulados en el Anexo 10, hablaremos sobre la sección I que trata de la elaboración de un análisis de impacto y la sección III que estipula los puntos mínimos que debe incluir el BCP. Las estrategias mencionadas estarán alineadas al Well-Architected Framework de AWS. Considerar que las recomendaciones mencionadas dependerán de cómo sus cargas de trabajo estén implementadas y de su estrategia para dar cumplimiento a la regulación que le aplique.

Sección I: Análisis de impacto

En esta sección del anexo se describe que se debe desarrollar un análisis de impacto (BIA por sus siglas en ingles Buisness Impact Analysis). Realizar este análisis previo al BCP es de gran importancia ya que ayudará a las IFCs a determinar todo aquel escenario que puede detener o degradar el servicio ofrecido a sus inversores y solicitantes.

Escenarios de contingencias y ubicación geográfica

Una evaluación de riesgos del tipo de desastre y el impacto geográfico junto con información general sobre la implementación técnica de la carga de trabajo determinará la probabilidad de que se produzca una interrupción. Para cargas de trabajo muy criticas como aquellas que manejan las transacciones monetarias pueden considerar la alta disponibilidad redundando la carga en una ubicación alterna.

AWS tiene el concepto de una región, es importante mencionar que dentro de la industria no existe una definición estándar del concepto de región y por lo tanto cada service provider posee una. Dentro de AWS, una región es una ubicación geográfica en el mundo donde se agrupan centros de datos. Llamamos a cada grupo de centros de datos “zona de disponibilidad” (AZ por sus siglas en inglés Availability Zone). Cada región de AWS consta de un mínimo de tres AZs físicamente separadas dentro de un área geográfica. Los centros de datos de cada AZ cuentan con sistemas de alimentación de energía, refrigeración y seguridad física redundantes e independientes que se conectan entre si por medio de enlaces redundantes de ultrabaja latencia. Los clientes de AWS centrados en la alta disponibilidad pueden diseñar sus aplicaciones para que se ejecuten en múltiples zonas de disponibilidad y lograr una mayor tolerancia a errores. Las regiones de infraestructura de AWS cumplen con los niveles más altos de seguridad, cumplimiento y protección de datos.

Antes de elegir una ubicación, AWS realiza evaluaciones ambientales y geográficas iniciales. Las ubicaciones de los centros de datos se seleccionan cuidadosamente para mitigar los riesgos ambientales, como las inundaciones, los fenómenos meteorológicos extremos y la actividad sísmica. Nuestras AZs están diseñadas para operar de forma independiente unas de otras y están físicamente distantes dentro de la región a distancias de hasta por 100Kms.

Para conocer más sobre la infraestructura en AWS y como beneficia sus cargas de trabajo invitamos a revisar la página de cumplimiento de AWS y el blog de patrones de diseño con resiliencia.

Estipulación de tiempos de recuperación (RTO y RPO)

Para empresas como las IFCs que manejan información crítica financiera es de suma importancia plantear el objetivo de tiempo de recuperación (RTO por sus siglas en inglés Recovery Time Objective) y el objetivo de punto de recuperación (RPO por las siglas en inglés de Recovery Point Objective).

• El RTO es tiempo máximo aceptable entre la interrupción del servicio y su restablecimiento.
• El RPO es el periodo de tiempo máximo aceptable desde el último punto de recuperación de datos (el último respaldo).

Dentro del anexo 10 se menciona que el RTO no debe exceder dos horas. Mientras que, para el RPO, se debe considerar que las operaciones ya efectuadas no pueden perderse y que se debe poder conocer el estado que tenía cada operación celebrada al momento en que se presentó la contingencia operativa.

Las estrategias de recuperación de desastres (DRP por sus siglas en inglés) disponibles en AWS se pueden clasificar en términos generales en cuatro enfoques, que van desde complejidades y costos menores mediante el realizar copias de seguridad hasta estrategias más complejas que utilizan varias regiones en activo-activo. Es importante que previo a definir la estrategia, la IFC tenga un entendimiento de cuáles son sus procesos críticos. Así como, de acuerdo con las necesidades del negocio y la regulación cuáles son los RTO y RPO para cada proceso.

AWS Well-Architected Tool es una herramienta disponible en la consola basada en el AWS Well-Architected Framework la cual está diseñada para revisar el estado de sus cargas de trabajo según las prácticas recomendadas y esta dividido sobre 6 pilares. Uno de estos pilares que en particular puede apoyar en la selección del plan de desastres es el de fiabiliad.

Sección III: Desarrollo del BCP

Una vez realizado el BIA, la IFC puede redactar el BCP, el cual acorde al anexo 10 deber comprender las actividades de prevención, contención, restauración y evaluación de contingencias.

Prevención

Reducción de vulnerabilidades

En cuestión de resiliencia, AWS Resilience Hub es una herramienta que ayuda a centralizar los procesos de validación y seguimiento de la resiliencia en las cargas de trabajo sobre AWS. Resilience Hub le permite definir sus objetivos de resiliencia, evaluar su postura de resiliencia en relación con esos objetivos e implementar recomendaciones de mejora basadas en el marco de AWS Well-Architected Framework.

Para apoyar a este proceso es importante implementar herramientas que brinden observabilidad del estado actual de las cargas, así como también diseñar una arquitectura que restrinja el acceso a recursos a personas no autorizadas y además incorporar un sistema que sea capaz de alertar al equipo correspondiente ante una anomalía. Recomendamos para trabajar buenas prácticas revisar el pilar de seguridad del Well-Architected Framework en especial los puntos 5 y 6 que tratan sobre cómo proteger recursos de red y como proteger los recursos informáticos respectivamente y para fiabilidad los puntos 2 y 4 que tratan de como diseñar la topología de red y como diseñar interacciones en un sistema distribuido.

•  AWS Security Hub tiene la capacidad de centralizar las prácticas de seguridad recomendadas en un solo sitio y permitir agregar alertas y en conjunto con otros servicios de AWS se puede automatizar la remediación de vulnerabilidades.
• Amazon Inspector ayuda a escanear cargas de trabajo y los escanea para encontrar vulnerabilidades de software y exposición involuntaria de red.
• Por defecto todos los clientes cuentan con AWS Shield en su versión estándar que apoya frente a los ataques DDoS más comunes y frecuentes sobre capa de red y transporte.

Establecimiento de programa anual de pruebas y registro de sus hallazgos

Las IFCs deben probar su BCP y DRP. Recomendamos revisar el pilar de fiabilidad en particular el punto 12 que trata sobre cómo poner a prueba los sistemas, en él se menciona AWS Fault Injection Service, un servicio para ejecutar experimentos controlados de inyección de fallas, simplifica la capacidad de probar el correcto funcionamiento de las estrategias de resiliencia.

Contingencia y Restauración

Para las IFCs es importante definir los procesos que se seguirán en el momento que sucede una contingencia, así como regresar al estado original después de su remediación. Recomendamos implementar runbooks, es decir, procedimientos definidos para realizar acciones concretas. Estos mismos runbooks a veces comienzan como tareas manuales y van evolucionando hasta su ejecución automática. Tratamos 2 puntos del anexo dentro de esta sección ya que en AWS varias herramientas contemplan 2 fases, la detección de una contingencia (denominado failover) y el regreso al estado original (denominado failback).

• Elastic Load Balancer distribuye las solicitudes entre varias instancias de Amazon EC2 que pueden vivir en diferentes AZs, de esta forma, si existe una degradación sobre una AZ el sistema podrá continuar con operaciones en las demás zonas donde esté dispersado el servicio. Al recobrarse la AZ, puede apoyarse de los grupos de auto escalado para proveer el cómputo nuevamente y de forma automática. Para más detalle revisar el apartado de como diseñar cargas siguiendo el pilar de fiabilidad.
• AWS Route 53 el servicio para administración de dominios de AWS incluye la capacidad de redirigir el tráfico a un destino secundario una vez que se detecta alguna falla en el destino primario mediante el uso de una comprobación de estado (health check).
• AWS Elastic Disaster Recovery (AWS DRS) es una herramienta de recuperación escalable y rentable que permite la realización y recuperación de sistemas OnPrem, en AWS o en otras nubes. Permite implementar estrategias de luz piloto (Pilot Light).
•  AWS Shield posee una versión Advanced que incluye capacidades adicionales a la estándar como la asignación de un equipo de respuesta (SRT) capaz de actuar proactivamente ante ataques DDoS, protección de costos, administración centralizada, protección de capa de aplicación, firewall de aplicación (WAF) sin costo, entre otras.

Para más información revisar las sección 13 del pilar de fiabilidad en los apartados que trata sobre como redirigir la configuración a un sitio de recuperación de desastres y sobre la automatización de la recuperación.

Evaluación

Como última fase, el BCP debe comprender lo relativo a la recopilación y análisis de la información obtenida durante una contingencia. Esto con el fin de que las IFCs puedan aprender de los incidentes y retroalimentar el BCP.

•  Amazon CloudWatch, concentra la observación y monitoreo de aplicaciones sobre AWS, la capacidad de lanzar alertas y de crear tableros.
• Cloud Trail es un servicio de registro de actividad de los usuarios de AWS, es posible mandar estos registros a un almacenamiento duradero para complementar el análisis de una contingencia.
• Security Hub se puede integrar con servicios que ayudan a hacer análisis forense como:
  • Amazon Detective simplifica el proceso de investigación para los equipos de seguridad
  • Audit manager se usa con el fin de mantener controles para identificar requisitos de conformidad.
  •  Security Lake centraliza todos los datos de seguridad con el fin de poder integrar herramientas de analytics y machine learning.

Conclusiones

Con los servicios recomendados, las IFCs tendrán herramientas que ayudarán en la elaboración de los requerimientos del anexo 10. La selección de que servicios utilizar dependerá en gran medida de como cada empresa haya implementado sus cargas de trabajo, si se desea guía adicional, invitamos al lector acercarse con el equipo de expertos en AWS México y a revisar las recomendaciones sobre respuesta a incidentes de seguridad y plan de desastres en AWS.

Mas acerca del tema:

Diseño y controles de los centros de datos de AWS: https://thinkwithwp.com/es/compliance/data-center/controls/ 

AWS Compliance Center México – https://thinkwithwp.com/es/financial-services/security-compliance/compliance-center/mx/ 

Normatividad Inclusión financiera – https://www.gob.mx/cnbv/acciones-y-programas/normatividad-58345

Anexo 10 – https://www.cnbv.gob.mx/Anexos/Anexo%2010%20Fintech.pdf

Sobre los autores

Revisores