Cómo armar tu diagrama siendo una startup y sin morir en el intento
El diagrama de infraestructura es una de las tareas más comunes que reciben los líderes técnicos y este es un mapa visual de la tecnología que facilita su escalabilidad.
Aunque puede ser tentador dejar esta tarea al final del backlog, a medida que la empresa va creciendo y evolucionando, se vuelve esencial diseñarla, sobre todo para administrar adecuadamente los cambios, mejoras y/o problemas que pudieran surgir en la infraestructura tecnológica.
De hecho, este es el gran beneficio del diagrama de infraestructura: te permite identificar potenciales puntos débiles y solucionarlos con mayor facilidad para mantener los datos protegidos y cumplir con estándares internacionales de seguridad.
Si esta es tu primera vez que armando un diagrama de infraestructura, llegaste al lugar ideal: en esta guía ejemplificada está pensada para ti y para que puedas crearlo en simples pasos.
¿Qué es un diagrama de infraestructura?
El diagrama de infraestructura es un mapa visual que muestra cómo interactúan, hacia adentro y hacia afuera, los componentes de una infraestructura tecnológica.
Generalmente, en este mapeo se incluyen puntos de acceso, sistemas, aplicaciones, redes, bases de datos, máquinas virtuales, contenedores y cualquier medida de seguridad que se haya implementado en la infraestructura (como VPC o segmentación de redes, VPN, WAF, Firewalls, canales cifrados, etc.).
Si todavía no has implementado este tipo de medidas de protección, puede sonar un poco abrumador, pero no te preocupes, explicamos los aspectos básicos en Cómo comenzar a proteger tus entornos de staging.
¿Para qué sirve un diagrama de infraestructura?
Un diagrama de infraestructura es esencialmente la columna vertebral de tu área TI. Ayuda a los ingenieros y profesionales de TI a comprender mejor la infraestructura para que la puedan administrar, mejorar y mantener segura.
Así como un maestro mayor de obra necesita un plano para saber dónde colocar los materiales, las empresas con una base tecnológica deben tener un mapeo que les permita identificar con precisión los errores, tomar decisiones de mejora informadas y solucionar los problemas eficientemente.
Incluso, en las pequeñas empresas o startups (donde la infraestructura es pequeña) la diagramación también abarca la representación de los contenidos de un producto digital y las relaciones entre esos contenidos.
Debido a esto, suele ser un documento obligatorio para cumplir con normativas de seguridad como ISO 27001, PCI DSS y regulaciones como la Ley Fintech de México y la RAN 20-10 de Chile.
Herramientas para hacer un diagrama de infraestructura
En nuestra experiencia, hemos encontrado un par de opciones que te pueden facilitar el trabajo. Estas son algunas alternativas que te recomendamos:
- Lucidchart tiene varias opciones de diagramas de arquitectura tecnológica en su biblioteca. En su modelo freemium tienes hasta 3 documentos, acceso a 100 plantillas prediseñadas y protección de datos.
- Cacoo es un software basado en la web y es recomendable para cuando quieres compartir tu diagrama y editarlo al mismo tiempo con tu equipo. Tiene un plan gratuito que incluye usuarios ilimitados, 6 hojas, plantillas, edición en tiempo real y chat de video en la aplicación.
- Draw.io es una de las herramientas gratuitas más completas que hemos encontrado para diseñar flujos y diagramas. Tiene más de 50 plantillas predefinidas para comenzar en varias categorías.
¿Cómo hacer un diagrama de infraestructura?
Una vez que hayas encontrado la herramienta que mejor le funcione a tu equipo, debes saber que existen distintos tipos de iconos y símbolos para cada artefacto.
La notación gráfica está pensada para diseñar de lo general a lo específico, es decir, sigue el principio de la simplificación de representación (a partir de cajas y flechas) para que la comunicación de la arquitectura de información sea fácil y comprensible para todos.
Paso 1. Elegir software de modelado y graficación
Nosotros nos acomodamos mejor usando Draw.io, ya que cuenta con varias plantillas predeterminadas.
En tu caso, solo debes elegir la que corresponda con la nube de tu empresa o la que más se ajuste a lo que necesitas.
Paso 2. Identificar componentes y conexiones
Identifica los componentes de tu infraestructura por capas:
- Los que están en capas de alto nivel: componentes que están más cerca de proveedores y clientes.
- Los que están en capas de bajo nivel: componentes que están más cerca a las operaciones internas de tus aplicaciones.
De esta misma manera puedes identificar las conexiones entrantes y salientes al ecosistema de tu empresa.
Por ejemplo, podemos enlistar:
- Clientes (pueden haber clientes finales o intermediarios).
- Proveedores.
- Entidades bancarias (si eres una Fintech debes colocarlas).
- Conexiones expuestas a internet.
- Conexiones con entidades externas mediante webservices , apis y/o integraciones.
- Conexiones VPN.
- Conexiones cifradas, mediante certificados SSL/SSH, versiones TLS.
- Comunicaciones de puerto HTTPS o SFTP.
- Conexiones con filtro de proxies o IPs.
- Canales de conexión vía web y/o mobile.
- Firewalls.
- Web Application Firewall.
- Front end y Back office
- Autoscaling, balanceadores de carga, zonas de disponibilidad.
- Contenedores, máquinas virtuales.
- Base de datos y repositorio de resguardos.
- Aplicaciones de analítica de datos (si es necesario).
Al hacer esta lista no te preocupes del orden de los componentes, es simplemente para que repases e identifiques lo que tiene tu infraestructura. Luego iremos agrupando y aplicando cada componente o artefacto en su lugar.
Paso 3. Diagramar
En este ejemplo agregaremos varios componentes AWS para que puedas comprender cómo diagramar tu infraestructura, pero probablemente tu empresa maneje otro tipo de tecnologías: si usas Azure o Google Cloud, recuerda utilizar las notaciones de cada componente.
Comenzaremos por las interacciones externas y separando lo externo con lo interno de la empresa.
1. VPC, regiones y subnets
Dentro del cubo de la empresa, coloca todas las VPC por región, así como también la productiva y la de otros ambientes como desarrollo y staging.
Te recomendamos, como medida de seguridad, que cada entorno viva en una nube privada virtual (VPC) separada, de esta forma cada una estará aislada lógicamente dentro de una cuenta de AWS, tal como explicamos en la pequeña guía de 3 medidas básicas para proteger tus entornos.
Si cuentas con subnets, también debes plasmarlas, así sean públicas o privadas.
Ten en cuenta que cada VPC define una red virtual con su propio espacio de direcciones IP y con sus propias reglas para aquello que puede entrar o salir de esa red. Las direcciones IP dentro de cada VPC se dividen en varias subredes que controlan el enrutamiento de su dirección IP.
Por otro lado, si bien las subredes públicas son accesibles desde la Internet pública, a las subredes privadas solo deberían acceder desde la VPC.
2. Canales de contacto con clientes y proveedores (y su seguridad en la comunicación)
Ahora pensemos en cómo interactúan los clientes con la empresa, es decir, mediante qué canales y métodos de seguridad lo hacen. En este paso podemos incluir todas las medidas que ayudan a proteger las primeras capas de la infraestructura.
Si te fijas, en el ejemplo de arriba, incluimos las siguientes:
- Web Application Firewall (WAF)
- Firewall
- Protocolo SFTP
- Certificado SSL y protocolo TLS 1.3
Si tu empresa tiene más herramientas de networking como Route 53, CloudFront (en el caso de AWS), API Gateway, conexiones por VPN y filtros por Elastic IP (IP elástica) también debes incluirlas. Recuerda, lo importante es demostrar que tus ingresos están seguros.
Si no tienes estas medidas de seguridad, puedes comenzar por implementar un firewall de redes internas y externas, y un WAF.
Hackmetrix Insight: En Hackmetrix encontramos una relación precio-calidad bastante decente para WAFs con Cloudflare y Zone Lockdown de Cloudflare.
3. Esquemas de virtualización o Serverless
Si tienes varias zonas de disponibilidad (o Availability Zone) ahora es momento de agregarlas y de ver cómo están conectadas o segregadas.
Lo mismo si cuentas con Internet Gateway: es conveniente plasmarlo en las conexiones que van desde el WAF y/o el Route 53, en el caso de Amazon, hacia las zonas de disponibilidad.
Si quieres reflejar los endpoints con mayor detalle puedes hacerlo en este paso. Por otro lado, es importante incluir aquí los balanceadores de carga y cómo se comportan con los servicios de autoescalamiento. Puede suceder que la infraestructura sea Serveless y tengamos funciones (como Lambda en AWS) en lugar de máquinas virtuales o contenedores.
El balanceador de carga ejecuta varias copias de la aplicación para lograr escalabilidad y alta disponibilidad. No es accesible para el público, sino que se utiliza como una forma sencilla de realizar el descubrimiento de servicios: cada servicio de backend se registra con el balanceador de carga en una ruta en particular y todos los servicios saben enviar solicitudes a este balanceador de carga para hablar con otros servicios.
Hackmetrix Insight: Uno de los más utilizados es Application Load Balancer (ALB), administrado por AWS y diseñado para enrutar el tráfico HTTP y HTTPS. ¿Su mayor ventaja? Se encarga de la tolerancia a fallas, la seguridad y del escalado automático del balanceador de carga.
4. Bases de datos y buckets
Una vez hecho esto, continuamos con las conexiones a base de datos y buckets (o las herramientas que utilices para el storage y database).
Identifica qué tipo de bases de datos tienes: SQL, Postgre SQL, DynamoDB, RDS, etc. Lo mismo con los buckets: identifica si tiene uno o varios buckets y refléjalos en tu diagrama.
Recuerda que toda la información que se guarde en la base de datos o en los buckets debe estar cifrada o, al menos, la información más importante y sensible (en el diagrama de ejemplo lo representamos con un icono de archivo cifrado/candado).
Por último, en este paso también es importante plasmar la ubicación del backup.
5. Contenido estático
Ahora es momento de agregar los componentes relacionados con el contenido estático (imágenes, CSS, JS).
En nuestro ejemplo, se almacena en buckets de Amazon S3 y se sirve a través de CloudFront CDN. Esto le permite descargar todo el trabajo de servir contenido estático desde su servidor de aplicaciones y, generalmente, reduce la latencia para sus usuarios.
6. Monitoreo y gestión de logs
Ahora es tiempo de incluir las herramientas de monitoreo cloud que tengamos en la infraestructura: estas herramientas son clave para garantizar la seguridad de los sistemas ya que recogen datos de múltiples sistemas y analizan esos datos para detectar comportamientos anormales o posibles ciberataques.
Los que usamos en este ejemplo son AWS CloudTrail y AWS CloudWatch que, aunque parezcan similares, son diferentes en su utilidad:
- CloudWatch es el ¿qué está sucediendo en AWS?, registra todos los eventos de un servicio o aplicación en particular.
- CloudTrail es el ¿quién hizo qué en AWS? y la API llama al servicio o recurso.
Concretamente, ambos ayudarán a:
- Supervisar la VPC: supervisar los recursos, dispositivos, conexiones y rendimiento de la VPC.
- Monitorear máquinas virtuales: infraestructura de virtualización y máquinas virtuales individuales.
- Monitorear bases de datos: procesos de monitoreo, consultas, disponibilidad y consumo de recursos de bases de datos en la nube.
- Monitorear almacenamiento en la nube: recursos de almacenamiento y sus servicios, bases de datos y aplicaciones.
Si tienes también otras herramientas de este tipo (o SIEM) es conveniente incorporarlas en este paso.
7. Administración de la seguridad de la infraestructura
Llegamos al punto en donde reflejamos la administración de la seguridad de la infraestructura. Principalmente nos centraremos en reflejar componentes de:
- Manejo de identidades o accesos
- IDS/IPS
- Manejo de claves
Estos componentes son tres medidas que ayudarán a administrar y controlar la VPC en su totalidad.
En este ejemplo utilizamos, AWS IAM, AWS Inspector y AWS KMS para cada caso, pero existen otras opciones como AWS GuardDuty (para IDS o antimalware), Cognito (para manejo de identidades o accesos) y Secrets Manager (para manejo de claves) que también pueden sustentar la seguridad.
8. Desarrollo
Los repositorios de código o herramientas de integración continua no deben ser olvidados en este tipo de diagramas. Veamos cómo incluirlos claramente en esta visión de la infraestructura.
En el ejemplo de arriba, colocamos el componente Repositorio Code GIT, pero si tus repositorios son Github, Gitlab, Bitbucket u otro, coloca el logo que corresponda para identificarlo fácilmente.
Las flechas de conexión suelen ir a la VPC de la región principal, tal como se muestra en la imagen.
Ahora procede de la misma forma con Integración Continua (IC), coloca el logo que corresponda a tu herramienta (Travis, AWS CodePipeline, Gitlab CI). En nuestro ejemplo usamos Jenkins.
9. VPC Staging
Al representar las VPC (o ambientes) de Staging solamente será hacer una réplica en espejo de los componentes que tenemos en el ambiente de Producción.
Ten en cuenta que solamente debes hacer réplica de componentes y estructura, no de la base de datos. Lo mismo sucede con las credenciales de ingresos a la VPC de Staging, no deben ser iguales a las de la VPC Productiva.
El objetivo es demostrar que ambos existen, aunque no necesariamente tengamos los mismos componentes.
Por otro lado, aunque generalmente no se monitoreen los logs de la VPC Staging por un asunto de costos y porque es más importante inspeccionar los de Producción, aún así, debes mantenerlo seguro: por ejemplo a través del uso de canales internos seguros, segregaciones correctas con grupos de seguridad y aislamiento de VPC para evitar exposiciones a internet.
10. Región alternativa
Llegamos al final de la historia: las regiones alternativas se grafican dependiendo de nuestras estrategias de recuperación, las cuales generalmente se plantean en un plan de recuperación ante desastres o DRP. Veamos cuáles son los posibles escenarios de réplica de ambientes:
- Réplica parcial de ambientes: replicar la VPC de producción en otra región de la misma nube para asegurar la continuidad del negocio crítico.
- Réplica total de ambientes: mantener ambos sitios y/o regiones espejados (esta opción suele ser la más costosa y, generalmente, la menos usada).
- Réplica parcial de ambientes en otra nube: por ejemplo, Google Cloud o Azure. Esta opción, también, suele ser muy adoptada.
- Réplica de las bases de datos y almacenamiento en la misma nube, pero en distinta región: para aquellos servicios que suelen ser menos críticos y tienen mayor amplitud de tiempos para recuperar sus sistemas luego de un incidente (una métrica conocida como RTO).
En el diagrama de arriba mostramos el primer caso de réplica parcial en la misma nube (AWS), donde la principal es Virginia y la secundaria Sao Paulo.
Si fuera el caso 2, entonces, el cubículo de región alternativa se tendrá que graficar abarcando ambas VPC o bien hacer una copia igual de ambos y disponerlos al lado.
En el caso 3, la réplica debiese ser otro cubículo que contenga los componentes y/o vpc catalogada con el nombre de la nube alternativa.
En el caso 4, la réplica se mostrará al lado solamente disponibilizando región y componente replicado, es decir, la base de datos y almacenamiento. Añadiendo a esta conexión el protocolo usado para hacer el envío de una región a otra.
Finalmente, así es cómo queda el diagrama de infraestructura:
Ahora tiene más sentido, ¿no?
Tips finales
- Documenta las formas que vas a utilizar: así evitarás confusiones o malas interpretaciones y mantendrás una notación constante en todo momento. Recuerda que los significados de las formas varían de un diagrama a otro.
- Agrega información a las flechas para evitar ambigüedades: las flechas indican flujos de datos y dependencias, pero pueden representar relaciones diferentes dependiendo el caso, por ejemplo, en una podría representar una dependencia y, en otra, una implementación. Recuerda: solo porque tu equipo conoce cierto acrónimo, no significa que otras partes interesadas lo conozcan.
Conclusión
El diagrama de infraestructura es una representación visual de cómo interactúan y se disponen los componentes de una infraestructura TI.
Con esta guía, los ingenieros y profesionales de TI pueden administrar, mejorar y asegurar la infraestructura. Pero además es un documento clave para cumplir con ISO 27001, PCI DSS y otras regulaciones de seguridad como Ley Fintech y la RAN 20-10.
Al mismo tiempo, para las empresas pequeñas, este documento incluso puede cubrir gran parte de lo que es el diagrama de arquitectura (estructura y componentes de una aplicación). Es por ello que crear un diagrama de infraestructura también facilita la creación del de arquitectura.
Aunque hay varias herramientas que te ayudarán a crearlo, en Hackmetrix te recomendamos Lucidchart, Cacoo o Draw.io ya que te permiten diseñar sin instalar ningún software y usar algunas funciones de forma gratuita.
Si sigues estos pasos y ejemplos podrás crear tu propio diagrama en muy poco tiempo.
En caso de que te quedes con dudas sobre cómo elaborar este o cualquier otro documento de seguridad, contáctanos para que te guiemos paso a paso.
