Razonamiento y patrones para modelos S5 - JohannPaezU/MISW4501-MediSupply GitHub Wiki
| Táctica aplicada | Consiste en | Razonamiento sobre las decisiones de arquitectura |
|---|---|---|
| #1: Detección de fallas (Monitor) | • Un componente dedicado (Monitor) que recibe los estados y eventos operativos de los demás servicios. • No interviene en el negocio: solo observa y registra; su única función es visibilidad y alerta. |
• Observabilidad centralizada: Concentrar en un único componente la recolección de estados reduce la dispersión de métricas y agiliza el diagnóstico. • No intrusivo: El Monitor consume sin acoplarse a los flujos; así no agrega latencia ni se convierte en cuello de botella. • Continuidad de información: Al llegarle los eventos por un canal común, se facilita reconstruir el contexto (qué falló, cuándo y en qué dominio) y acortar el tiempo de recuperación. • Gobernanza operativa: Un solo punto para generar alertas y tableros facilita acordar umbrales y reglas de notificación a operación. |
| #2: Múltiples copias de computación (manejo de recursos) | • Varias réplicas de la base de datos (primaria y secundarias) distribuidas en distintos nodos. • La base de datos primaria recibe las escrituras; las réplicas asumen funciones de solo lectura o pueden ser promovidas a primarias en caso de falla. |
• Alta disponibilidad: Una réplica puede ser promovida a primaria ante una caída, reduciendo el tiempo de inactividad. • Distribución de carga: Consultas de lectura se redirigen a las réplicas, reduciendo presión sobre la instancia principal. • Escalabilidad horizontal: Agregar nuevas réplicas permite crecer en capacidad sin modificar la lógica de los servicios consumidores. |
| Táctica aplicada | Consiste en | Razonamiento sobre las decisiones de arquitectura |
|---|---|---|
| #1: Autenticación (Autenticar actores) | • Los usuarios solicitan acceso al Authorizator, que emite un Authorization Token. • El API Gateway valida el token antes de enrutar peticiones a los dominios internos. |
• Control en el perímetro: El Gateway evita que tráfico no autenticado alcance servicios internos. • Separación de responsabilidades: El Authorizator independiente permite escalar, auditar, rotar claves y cambiar políticas sin afectar el enrutamiento. • Política uniforme: Un único punto de validación asegura reglas consistentes (expiración, scopes) en todo el ecosistema. |
| #2: Certificación (Certificados digitales entre servicios) | • El API Gateway solicita/recibe certificados del Certificator. • Esos certificados habilitan confianza y cifrado en las comunicaciones internas. |
• Confianza de servicio a servicio: Los certificados autentican componentes y previenen suplantación. • Ciclo de vida centralizado: El Certificator estandariza emisión, renovación y revocación, reduciendo riesgos operativos y complejidad en cada dominio. |
| Táctica aplicada | Consiste en | Razonamiento sobre las decisiones de arquitectura |
|---|---|---|
| #1: Resisitir Ataques (Autenticación) | • El Cloud Load Balancing y el API Gateway actúan como el perímetro de seguridad. • El API Gateway delega el proceso de verificación de identidad a un servicio centralizado (Identity Platform), que implementa el flujo estándar OAuth2/OIDC. Ninguna petición no autenticada puede acceder a la lógica de negocio. |
• Punto Único de Control (Perímetro): Centralizar la autenticación en el API Gateway asegura que se aplique una política de seguridad uniforme y obligatoria a todas las peticiones entrantes. Esto reduce la superficie de ataque y simplifica la auditoría. • Separación de Responsabilidades: Los microservicios de negocio no necesitan implementar lógica de autenticación. Pueden confiar en que cualquier petición que reciben ya ha sido verificada, lo que reduce la complejidad y el riesgo de errores de implementación de seguridad en cada servicio. |
| #2: Control de Acceso (Autorización) | • Una vez que un usuario es autenticado, el API Gateway consulta a un componente dedicado (Autorizador). • Este servicio valida el token de acceso (JWT) para determinar si el usuario tiene los permisos necesarios para ejecutar la acción solicitada. |
• Principio de Mínimo Privilegio: La autenticación establece quién es el usuario, mientras que la autorización define qué puede hacer. Un autorizador centralizado asegura que los usuarios solo puedan acceder a los recursos y operaciones permitidos por su rol, previniendo escaladas de privilegios. • Gestión Centralizada de Políticas: Las reglas de acceso (RBAC/ABAC) se gestionan en un solo lugar. Esto permite modificar permisos de forma ágil y consistente para todo el sistema sin necesidad de redesplegar los microservicios. |
| #3: Seguridad Basada en Certificados | • Se utiliza un componente Certificador para gestionar el ciclo de vida de los certificados digitales. • Seguridad Externa: La comunicación desde los clientes hasta el Cloud Load Balancing y API Gateway está cifrada con TLS. • Seguridad Interna: La comunicación entre los microservicios dentro del clúster de GKE está asegurada mediante mTLS (TLS mutuo), como se indica en la nota del diagrama. |
• Confidencialidad e Integridad: El cifrado TLS en el perímetro protege los datos en tránsito de los usuarios contra escuchas o manipulaciones en redes públicas. • Confianza Cero (Zero Trust Network): El uso de mTLS internamente garantiza que solo los servicios verificados y autorizados puedan comunicarse entre sí. Un servicio debe presentar un certificado válido para conectar con otro, previniendo movimientos laterales de atacantes que pudieran haber penetrado el perímetro de la red. Esto crea un entorno interno seguro por defecto. |
| Táctica aplicada | Consiste en | Razonamiento sobre las decisiones de arquitectura |
|---|---|---|
| #1: Detección de Fallas (Monitor) | • Un conjunto de servicios dedicados a la observabilidad (Servicios de Observabilidad (Monitor)) que centraliza la recolección de métricas, logs y trazas de todos los componentes de la infraestructura (GKE, API Gateway, Capa de Datos). • El monitoreo es un proceso pasivo que no interfiere con las operaciones; su función es proporcionar visibilidad en tiempo real y alertar sobre anomalías. |
• Diagnóstico Rápido y Centralizado: Concentrar toda la telemetría en un único punto (Cloud Monitoring, Cloud Logging) reduce drásticamente el tiempo necesario para identificar la causa raíz de un problema (MTTR), ya que no es necesario consultar cada servicio individualmente. • Detección Proactiva: Permite configurar alertas automáticas basadas en umbrales de rendimiento (latencia, tasa de errores) o consumo de recursos (CPU, memoria), lo que posibilita actuar antes de que una falla impacte a los usuarios finales. • Gobernanza Operativa: Facilita una visión unificada del estado del sistema, permitiendo a los equipos de operaciones tomar decisiones informadas sobre escalabilidad, mantenimiento y optimización de recursos. |
| #2: Múltiples Copias de Computación (Manejo de Recursos) | • A Nivel de Servicio: Cada microservicio se despliega en el clúster de GKE con una configuración de HPA >= 2, garantizando un mínimo de dos réplicas activas. • A Nivel de Infraestructura: Los nodos del clúster de GKE se distribuyen en al menos dos zonas de disponibilidad distintas dentro de la región primaria. • A Nivel de Datos: Se mantiene una réplica de lectura de la base de datos (Cloud SQL Replica) en una región geográfica separada (us-east1) para la recuperación ante desastres (DR). |
• Resiliencia ante Fallas de Aplicación: Si una réplica de un microservicio falla, el tráfico es redirigido automáticamente a las réplicas saludables sin interrupción del servicio. El HPA se encarga de levantar una nueva réplica para mantener el estado deseado. • Resiliencia ante Fallas de Infraestructura Zonal: La distribución de nodos en múltiples zonas protege contra la caída de un centro de datos completo. La aplicación sigue funcionando desde las zonas operativas. • Continuidad del Negocio (DR): La réplica de base de datos en otra región es la pieza clave para la recuperación ante un desastre que afecte a toda la región primaria. Permite restaurar el servicio en la región de DR, minimizando la pérdida de datos y el tiempo de inactividad (RTO/RPO bajos). |
| Táctica aplicada | Consiste en | Razonamiento sobre las decisiones de arquitectura |
|---|---|---|
| Monitor (Detección de fallas) | • Un componente dedicado (Monitor) que recibe los estados y eventos operativos de los servicios a través de un canal asíncrono (Event Emitter). • No participa en la lógica de negocio: su único propósito es visibilidad y alerta. |
• Observabilidad centralizada: Centralizar la recolección de métricas y eventos en un único punto reduce la dispersión de información y facilita el diagnóstico. • No intrusivo: Consume eventos sin intervenir en flujos síncronos; no agrega latencia ni se convierte en cuello de botella. • Continuidad de información: Recibir todos los eventos por un canal común permite reconstruir el contexto y acortar tiempos de recuperación (MTTR). • Gobernanza operativa: Facilita la creación de tableros y alertas estandarizados con umbrales claros. |
| Táctica aplicada | Consiste en | Razonamiento sobre las decisiones de arquitectura |
|---|---|---|
| Autenticación (Autenticar actores) | • Los usuarios solicitan acceso al Authorization Service, que emite un Authorization Token. • El API Gateway valida el token antes de permitir acceso a servicios internos. |
• Control en el perímetro: Verificar identidad en el Gateway evita que tráfico no autenticado alcance el backend. • Separación de responsabilidades: Mantener un servicio de autorización independiente facilita escalar, auditar y modificar políticas sin afectar el enrutamiento. • Política uniforme: Un único punto de validación asegura consistencia de reglas (expiración, scopes) en todo el ecosistema. |
| Certificación (Confianza servicio a servicio) | • El API Gateway solicita y recibe certificados del Certification Service para habilitar cifrado y autenticación mutua (mTLS) en comunicaciones internas. | • Confianza interna: Los certificados autentican servicios y evitan suplantación dentro de la red. • Gestión centralizada: El ciclo de vida (emisión, renovación, revocación) de certificados se estandariza, reduciendo riesgos operativos. • Seguridad de extremo a extremo: Integrar la certificación en el perímetro refuerza la protección desde el cliente hasta cada microservicio. |