Management en Salud: Redes Virtuales Privadas para Salud Digital

Buenas tardes, en este segundo capítulo de la serie Arquitectura de Sistemas Seguros para Aplicaciones Web en Salud Digital explicaré el funcionamiento y uso de las Redes Virtuales Privadas (VPCs por sus siglas en inglés), componente fundamental en todos los principales proveedores de computación en la nube y para todo prestador de salud que desee implementar una solución tecnológica en la nube. Este capítulo también será indispensable para los siguientes.

¿Qué es una Red Virtual Privada?

Las Redes Virtuales Privadas son el componente principal del networking de una aplicación web, y de todo sistema que se encargue de proveer servicios de computación en la nube por medio de alguno de los principales proveedores. Aprovechamos de mencionar que se hará énfasis en Amazon Web Services y que se desplegarán recursos mediante servicios de este proveedor, sin embargo tanto Microsoft Azure, como Google Cloud e IBM Cloud poseen servicios y conceptos equivalentes para el alcance de este capítulo.

Para facilitar la comprensión de las VPCs se realizará una metáfora entre éstas y sus componentes con la infraestructura de una empresa. Para empezar una VPC sería un único establecimiento de una empresa en un lugar geográfico, es decir si se desea que la empresa esté en otros países o regiones de un país es necesario crear otro establecimiento en ese lugar (i.e. una nueva VPC).

Se recomienda no ubicar recursos en distintas VPCs innecesariamente con el objetivo de que los recursos se comuniquen más rápidamente entre sí y los medios de seguridad sean más fáciles de administrar. Sin embargo en el caso de que se busque que los usuarios en distintas zonas geográficas accedas con menor latencia a la aplicación, los recursos de ésta pueden ser replicados en otras VPCs en regiones más cercanas a los distintos grupos de usuarios.

1. ¿Cuales son los componentes principales de una VPC?

2. En primer lugar las Internet Gateways (IG, portal a internet) son componentes indispensables de toda aplicación o sistema que desee disponibilizar sus servicios a internet. Las Internet Gateways son como la puerta de (un establecimiento de) una empresa. A menos que el establecimiento sólo provea de servicios internamente a otra empresa u organización, ésta necesitará tener una puerta de entrada para el público i.e. una IG.

3. En segundo lugar están las Subnets (subredes), las que son como los departamentos de una VPC. Aquí aparece el concepto de IPs privadas, donde su cantidad al interior de una VPC constituye el tamaño de ésta. En este contexto, las Subnets se definen como subconjuntos disjuntos (sin superposición) de IPs privadas del conjunto total de IPs de la VPC.

· Es importante reservar una cantidad suficiente de IPs en cada Subnet, de manera que todos los recursos (e.g. bases de datos) deseados que requieran IPs (i.e. que ocupen espacio, como una oficina al interior del departamento) puedan ser desplegados en ellas.

· También es importante emplear Subnets privadas, es decir sin acceso a internet (sin conexión directa a una IG) para recursos que no lo necesiten. Por ejemplo una base de datos puede estar en una Subnet privada y estar conectada a una servidor web que esté en una Subnet pública.

Para especificar la conexión entre 2 recursos se requieren Route Tables, las que pasamos a explicar en el siguiente punto.

4. Cada Subnet tiene asociado una Route Table (Tabla de ruteo), la que especifica las direcciones de los recursos con los que se pueden conectar los recursos al interior de la Subnet. Por ejemplo, para que una Subnet sea pública (pueda acceder a servicios y ser accedida usuarios a través de internet) necesita tener una entrada en su tabla de ruteo que apunte a una Internet Gateway.

5. Por otro lado, las Route Tables por defecto poseen una regla no eliminable que especifica las IPs de todos los recursos al interior de la VPC, por lo que cualquier recurso en una Subnet privada puede comunicarse con recursos en cualquier Subnet pública y viceversa. Las Route Tables pueden verse como los caminos que conectan a todos los recursos en un departamento con recursos en otros departamentos o servicios en otras direcciones.

6. Que existan los caminos no significa que estos estén permitidos. Los Security Groups (SGs, grupos de seguridad) especifican qué direcciones pueden acceder a los recursos pertenecientes a esos grupos, y también a qué direcciones pueden acceder estos recursos, aunque lo más común y en general de forma segura basta con especificar las direcciones que pueden ingresar.

Por ejemplo, un servidor web puede estar al interior de un Security Group A que especifique que cualquier dirección IPv4 puede ingresar (i.e. 0.0.0.0/0), mientras que una base de datos puede estar al interior de un Security Group B que especifique que sólo las direcciones al interior de A pueden ingresar. Los Security Groups son como los permisos asociados a las puertas de seguridad al interior de una organización, y como tales son esenciales para alcanzar cualquier nivel de seguridad aceptable.

Demostración

Ahora procederemos a desplegar una VPC con una Subnet pública (i.e. con una Route Table con una ruta a una Internet Gateway) y un servidor web Apache al interior de un Grupo de seguridad que permite el acceso desde cualquier IPv4.

El despliegue se realizará mediante un único archivo de configuración vpc.yml el que es subido al servicio Cloudformation de Amazon Web Services en la región del Norte de Virginia (us-east-1) dado que la imagen de apache empleada corresponde a aquella región. Este archivo es muy simple y contiene únicamente los recursos mencionados y algunos de soporte para emplear estos recursos en la práctica. Para realizar esta prueba es necesario poseer una cuenta en Amazon Web Services pero para fines de este Capítulo basta con entender los pasos realizados en esta demostración y el objetivo de los distintos comandos empleados en el archivo vpc.yml.

→ Archivo vpc.yml

Una vez en la consola de Cloudformation, subimos el archivo y optativamente podemos analizarlo mediante el Designer de Cloudformation como muestra la Imagen 1. Al interior del Designer (Imagen 2) podemos ver los recursos especificados al interior del archivo vpc.yml. Este archivo agrega a los recursos ya explicados el de Elastic IP, el que añade una IP pública al Servidor Web creado para poder accederlo a través de internet.

Imagen 1

Imagen 2

Luego de verificar que todo está en orden, regresamos y procedemos a desplegar a crear el stack de Cloudformation con los recursos especificados. Una vez creado el stack (Imagen 3) podemos ir a la consola de EC2 y ver el servidor web desplegado (Imagen 4). Si accedemos a la IP pública señalada en la imagen nos encontraremos con la Imagen 5 que muestra que efectivamente el servidor web ha sido desplegado y está ofreciendo sus servicios a través de internet.

Imagen 3