Quiz: Testear conocimientos sobre seguridad y buenas prácticas

Tipo de lección: Quiz

Introducción al Quiz de Seguridad y Buenas Prácticas

Este cuestionario no es una simple evaluación de conceptos teóricos. Es una herramienta de diagnóstico diseñada para validar tu comprensión práctica y operacional de los mecanismos que mantienen un ecosistema de microservicios basado en gRPC seguro, resiliente y observable. En un entorno de producción, la seguridad no es un feature, es la base. Los errores no son excepciones, son eventos manejables. Y los interceptores no son opcionales, son la columna vertebral del control transversal.

Las siguientes secciones presentan escenarios, preguntas y problemas que reflejan decisiones de arquitectura reales. No busques respuestas de memorización; busca aplicar principios. Cada bloque de código es funcional y representa un patrón o anti-patrón común. Tu objetivo es identificar fortalezas, debilidades y, lo más importante, el razonamiento detrás de cada implementación. Prepárate para cuestionar supuestos y pensar como un ingeniero que despliega y mantiene sistemas críticos.

Concepto Clave: La Triada de Seguridad y Control en gRPC

Imagina un edificio de alta seguridad (tu microservicio). La autenticación es el guardia que verifica tu identificación y biometría en la entrada. La autorización es el sistema que, una vez dentro, determina a qué pisos y salas tienes acceso específico (¿puedes entrar al servidor de pagos o solo al de catálogo?). Finalmente, los interceptores son las cámaras de seguridad, los sensores de movimiento y los registros de acceso que monitorean cada movimiento en los pasillos, capaces de detener una acción sospechosa o simplemente registrarla para una auditoría posterior.

Esta triada funciona en capas. La autenticación suele resolverse en el nivel de conexión (TLS con certificados mutuos, tokens JWT en metadatos). La autorización, a menudo implementada dentro de un interceptor, decide si una identidad autenticada puede ejecutar un método RPC específico. El manejo de errores y la observabilidad, también habilitados por interceptores, son el sistema de alertas y el cuadro de mandos del edificio, que te permiten saber si un guardia (interceptor) rechazó a alguien, o si hay un incendio (error interno) en la cocina (servicio).

Tip Crítico: Nunca confíes en la autenticación a nivel de servicio sin TLS. Sin cifrado de transporte, las credenciales pueden ser interceptadas, haciendo inútil todo tu esquema de seguridad. En producción, TLS es no negociable.

Cómo Funciona en la Práctica: Flujo de una Llamada Segura

Vamos a desglosar el viaje paso a paso de una llamada gRPC en un entorno seguro. Primero, el cliente establece una conexión usando TLS, presentando su certificado cliente (autenticación mutua). Una vez la conexión está cifrada y autenticada, el cliente adjunta un token JWT portador en los metadatos de la llamada específica. Este token contiene afirmaciones (claims) sobre el usuario o servicio cliente.

Al recibir la llamada, el primer interceptor en el servidor es el de logging y métricas, que registra el intento. Luego, el interceptor de autenticación/autorización entra en acción: extrae el token JWT de los metadatos, lo valida criptográficamente, verifica su firma y expiración, y decodifica sus claims. Con la identidad verificada, consulta una política (por ejemplo, basada en roles - RBAC) para determinar si esa identidad tiene permiso para invocar el método `PaymentService.ProcessTransaction`. Si tiene éxito, la llamada fluye al manejador del servicio. Cualquier error en este camino (token inválido, permiso denegado) es capturado, transformado en un estado gRPC apropiado (UNAUTHENTICATED, PERMISSION_DENIED) y devuelto al cliente, siendo también registrado por el interceptor de logging.

Finalmente, un interceptor de manejo de errores global puede capturar cualquier excepción no controlada que surja en el manejador del servicio, evitar que detalles internos sensibles se filtren al cliente, y transformarla en un error genérico `INTERNAL` mientras registra el stack trace completo internamente para depuración. Este flujo coordinado es lo que separa una implementación robusta de una vulnerable.

Código en Acción: Interceptor de Autorización y Manejo de Errores

El siguiente código muestra un interceptor de servidor completo que implementa autorización basada en roles (RBAC) y un wrapper para el manejo centralizado de errores. Presta atención a cómo se estructuran los errores y cómo se evita la fuga de información.

package main

import (
    "context"
    "errors"
    "fmt"
    "log"
    "strings"

    "github.com/golang-jwt/jwt/v5"
    "google.golang.org/grpc"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/metadata"
    "google.golang.org/grpc/status"
)

// Claims define la estructura esperada en nuestro JWT.
type CustomClaims struct {
    jwt.RegisteredClaims
    Roles []string `json:"roles"`
    UserID string `json:"uid"`
}

// policyMap define qué roles pueden ejecutar qué métodos.
var policyMap = map[string][]string{
    "/payment.PaymentService/ProcessTransaction": {"admin", "finance"},
    "/payment.PaymentService/GetBalance":         {"admin", "finance", "user"},
    "/catalog.ProductService/DeleteProduct":      {"admin"},
}

// AuthInterceptor es un interceptor de servidor para autenticación y autorización.
type AuthInterceptor struct {
    jwtSecret []byte
}

func (ai *AuthInterceptor) authorize(ctx context.Context, method string) error {
    // 1. Extraer metadatos y token.
    md, ok := metadata.FromIncomingContext(ctx)
    if !ok {
        return status.Error(codes.Unauthenticated, "metadatos no encontrados")
    }

    authHeaders := md.Get("authorization")
    if len(authHeaders) == 0 {
        return status.Error(codes.Unauthenticated, "cabecera de autorización faltante")
    }

    tokenString := strings.TrimPrefix(authHeaders[0], "Bearer ")

    // 2. Validar y parsear el JWT.
    token, err := jwt.ParseWithClaims(tokenString, &CustomClaims{}, func(token *jwt.Token) (interface{}, error) {
        if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
            return nil, fmt.Errorf("método de firma inesperado: %v", token.Header["alg"])
        }
        return ai.jwtSecret, nil
    })

    if err != nil {
        log.Printf("Error validando JWT: %v", err)
        return status.Error(codes.Unauthenticated, "token inválido o expirado")
    }

    claims, ok := token.Claims.(*CustomClaims)
    if !ok || !token.Valid {
        return status.Error(codes.Unauthenticated, "reclamaciones de token inválidas")
    }

    // 3. Aplicar políticas de autorización (RBAC).
    allowedRoles, ok := policyMap[method]
    if !ok {
        // Método no listado en políticas, denegar por defecto (principio de menor privilegio).
        return status.Error(codes.PermissionDenied, "método no autorizado por política")
    }

    hasRole := false
    for _, userRole := range claims.Roles {
        for _, allowedRole := range allowedRoles {
            if userRole == allowedRole {
                hasRole = true
                break
            }
        }
        if hasRole {
            break
        }
    }

    if !hasRole {
        log.Printf("Intento de acceso no autorizado. Usuario: %s, Método: %s, Roles: %v", claims.UserID, method, claims.Roles)
        return status.Error(codes.PermissionDenied, "permisos insuficientes para este método")
    }

    // 4. Inyectar información del usuario en el contexto para el manejador.
    ctx = context.WithValue(ctx, "userID", claims.UserID)
    // Nota: En un caso real, usarías un tipo de clave propio, no un string.
    return nil
}

// UnaryInterceptor es el método que implementa grpc.UnaryServerInterceptor.
func (ai *AuthInterceptor) UnaryInterceptor(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (interface{}, error) {
    // Llamar a la lógica de autorización.
    if err := ai.authorize(ctx, info.FullMethod); err != nil {
        return nil, err // El error ya es un status gRPC.
    }

    // Wrapper de manejo de errores para el manejador principal.
    resp, err := ai.handleWithErrorLogging(ctx, req, info, handler)
    return resp, err
}

func (ai *AuthInterceptor) handleWithErrorLogging(ctx context.Context, req interface{}, info *grpc.UnaryServerInfo, handler grpc.UnaryHandler) (resp interface{}, err error) {
    // Defer para capturar pánicos y errores.
    defer func() {
        if r := recover(); r != nil {
            log.Printf("PANIC recuperado en método %s: %v", info.FullMethod, r)
            err = status.Error(codes.Internal, "un error interno ocurrió")
        }
        // Si el handler ya devolvió un error, podemos loguearlo aquí.
        if err != nil {
            // Convertir error genérico a status gRPC si no lo es ya.
            if _, isStatus := status.FromError(err); !isStatus {
                log.Printf("Error no manejado en método %s: %v", info.FullMethod, err)
                // Enmascarar el error real para el cliente.
                err = status.Error(codes.Internal, "operación fallida")
            } else {
                // Es un error gRPC ya creado (como PERMISSION_DENIED), lo logueamos a nivel INFO/WARN.
                log.Printf("Error de negocio/seguridad en método %s: %v", info.FullMethod, err)
            }
        }
    }()

    resp, err = handler(ctx, req)
    return resp, err
}

// Ejemplo de uso al crear el servidor:
func main() {
    interceptor := &AuthInterceptor{jwtSecret: []byte("secreto-super-seguro-y-largo")}
    server := grpc.NewServer(
        grpc.UnaryInterceptor(interceptor.UnaryInterceptor),
        // También podrías agregar un StreamInterceptor aquí.
    )
    // ... Registrar servicios (paymentPb.RegisterPaymentServiceServer, etc.)
    log.Println("Servidor gRPC seguro iniciado...")
}

Errores Comunes y Cómo Evitarlos

En la implementación de seguridad y manejo de errores, ciertos patrones defectuosos se repiten. Identificarlos es clave para construir sistemas robustos.

1. Loguear Información Sensitiva: Registrar tokens JWT completos, cuerpos de solicitudes con datos personales (PII) o detalles internos de errores en logs accesibles. Cómo evitarlo: Configura tus logs para enmascarar o hash de campos sensibles. En el interceptor, loguea solo metadatos no sensibles (method, userID, timestamp, código de error). Nunca loguees el `error` crudo de una base de datos.

2. Autorización en el Handlers, no en Interceptores: Poner la lógica de `if user.Role != "admin"` dentro de cada función del servicio. Esto viola el principio de responsabilidad única, es propenso a inconsistencias y difícil de auditar. Cómo evitarlo: Centraliza la autorización en un interceptor dedicado, usando un mapa de políticas declarativas como se mostró en el código. Esto asegura que toda llamada pase por el mismo punto de control.

3. Devolver Errores Internos al Cliente: Cuando una consulta SQL falla, propagar el mensaje de error de la base de datos (`pq: duplicate key value violates unique constraint`) al cliente. Esto revela detalles de tu esquema de datos y tecnología. Cómo evitarlo: Usa un interceptor de recuperación y manejo de errores que capture todas las excepciones, las loguee internamente con detalle, y devuelva al cliente un estado gRPC genérico (`INTERNAL`) con un mensaje amigable y no revelador ("No se pudo completar la operación").

4. Falta de Rate Limiting o Timeouts: No limitar la cantidad de peticiones por cliente o no establecer timeouts adecuados en el contexto. Esto abre la puerta a ataques de denegación de servicio (DoS) y a que un servicio lento afecte a toda la cadena. Cómo evitarlo: Implementa un interceptor de rate limiting (usando, por ejemplo, un bucket token) y propaga timeouts de manera explícita usando `context.WithTimeout` en el cliente, asegurándote de que se cancelen las llamadas de larga duración.

5. Validación de Tokens sin Verificar la Firma o la Expiración: Confiar ciegamente en un token JWT decodificado sin verificar criptográficamente su firma con la clave secreta o certificado correcto, o sin revisar la claim `exp`. Cómo evitarlo: Usa siempre una librería JWT madura (como `github.com/golang-jwt/jwt`) y su método `ParseWithClaims`, que valida firma y expiración automáticamente. Nunca decodifiques un JWT con `base64` manualmente para "inspeccionarlo".

Checklist de Dominio

Antes de considerar que tu implementación de seguridad y manejo de errores en gRPC está lista para producción, verifica que cumples con los siguientes puntos. Este checklist es tu línea de base.

• TLS está habilitado y configurado para todas las comunicaciones entre servicios, preferiblemente con autenticación mutua (mTLS) para verificación cliente-servidor.
• Existe un interceptor de autenticación/autorización centralizado que valida tokens (JWT, etc.) y aplica políticas de acceso (RBAC/ABAC) antes de llegar al handler del servicio.
• Los errores nunca exponen detalles internos (stack traces, nombres de tablas, queries SQL) al cliente externo. Se loguean internamente con detalle y se devuelven mensajes genéricos.
• Se ha implementado un interceptor de logging estructurado que captura métricas clave por cada llamada RPC: método, duración, código de estado gRPC, identidad (sin datos sensibles).
• Los timeouts y deadlines están configurados de manera explícita en el contexto de las llamadas cliente y se propagan correctamente a través de los servicios.
• Existe un mecanismo de rate limiting o throttling por cliente/llamada para proteger los servicios de picos abusivos o ataques DoS.
• Las claves secretas y certificados (JWT secret, TLS certs) no están hardcodeadas en el código, sino gestionadas a través de variables de entorno o un sistema de secretos (Vault, K8s Secrets).
• Se han definido y probado casos de error comunes (token expirado, permiso denegado, servicio no disponible) y se asegura que devuelven los códigos de estado gRPC correctos (UNAUTHENTICATED, PERMISSION_DENIED, UNAVAILABLE).