Acceso a bases de datos y Kubernetes a través del Monopam Gateway
Qué ha cambiado
Cada actualización del contenido se versiona. Seleccione una versión para compararla con la anterior.
Versión 8 → 9
ActualizaciónNuevo módulo sobre la operación del proxy de base de datos: la entrega de políticas tras activarlo, los huecos de enmascarado, las aprobaciones de sentencias y la consola del navegador. El módulo incluye ahora diagramas y, al final, una lista de qué comprobar primero.
1 lección actualizadaduración
Actualización de contenido. Se notificó a los estudiantes inscritos.
La duración cambió de 17 a 18 minutos.
El proxy de base de datos se sitúa entre el cliente del usuario y la base de datos y juzga cada sentencia. Tres situaciones aparecen en casi todos los despliegues.
### "Todo está bloqueado" justo después de activar el proxy
El proxy no guarda su propia copia de las políticas. Monopam se las envía por el puerto de administración del proxy. Hasta que ese primer envío tiene éxito, el proxy **falla en cerrado**: toda sentencia de todo usuario se bloquea con el motivo `no policies loaded`.
Así que, cuando un proxy recién activado lo bloquea todo, las Database Rules probablemente están bien. El sospechoso es el camino de entrega. Compruebe que la configuración del gateway apunta a la dirección correcta de Monopam y que el `Admin Token` coincide. Cuando el envío tiene éxito, las sentencias se juzgan con normalidad. Fallar en cerrado es el valor seguro: un proxy que lo permitiera todo sin política sería una puerta abierta en cada reinicio.
### Un número de teléfono que se escapa del enmascarado
El enmascarado tiene dos fuentes.
| Fuente | Cómo decide | Fortaleza | Límite |
| --- | --- | --- | --- |
| Detección automática de PII | Por el nombre de la columna (correo, teléfono, tarjeta y similares) y por la forma del valor | Cubre esquemas que nadie ha documentado | La detección por forma es estricta a propósito, para evitar falsos positivos |
| Regla de enmascarado explícita | Usted nombra la columna y el transformador | Exacta, y siempre gana a la detección automática | Hay que conocer la columna |
Un ejemplo del límite: el detector de teléfonos que mira los valores espera una serie ininterrumpida de dígitos. Un valor guardado como `+90 532 123 45 67`, con espacios, no coincide. Si la columna se llama `phone`, el nombre lo atrapa igualmente. Si se llama `contact_info`, ninguna de las dos pruebas salta y el número se devuelve en claro.
La respuesta no es desear un detector más laxo. Añada una regla de enmascarado explícita para esa columna. Trate la detección automática como red de seguridad y las reglas explícitas como el control para toda columna que ya sabe que contiene datos personales.
### Sentencias que necesitan aprobación
Una Database Rule con el efecto Approval no ejecuta la sentencia. Para un usuario con un cliente nativo como psql o DBeaver ocurre lo siguiente:
1. El proxy rechaza la sentencia y abre automáticamente una solicitud de aprobación.
2. Si el usuario reintenta mientras la solicitud está abierta, los reintentos se asocian a la **misma** solicitud. Los aprobadores no reciben una avalancha.
3. La solicitud tiene una ventana por defecto de 60 minutos. Si nadie decide, caduca.
4. El siguiente intento después abre una solicitud **nueva**.
Por eso un aprobador que llega a la mañana siguiente puede ver una solicitud caducada de la tarde anterior y una reciente de hoy. Ambas son del mismo usuario y la misma sentencia, y solo la reciente puede decidirse todavía. Una aprobación cubre exactamente la sentencia para la que se abrió.
::diagram pam-statement-approval
### La consola del navegador no es una puerta lateral
A veces los equipos suponen que la consola SQL del navegador es más débil que un cliente nativo porque es "solo una página web". Es lo contrario de un atajo: la consola envía sus sentencias por el mismo proxy, así que se aplican las mismas reglas, el mismo enmascarado, los mismos límites de frecuencia y la misma auditoría, y la credencial de la base de datos nunca llega al navegador. Elegir entre la consola y un cliente nativo es cuestión de comodidad, no de control.
### Qué comprobar primero
| Síntoma | Compruebe primero |
| --- | --- |
| Todas las sentencias se bloquean con `no policies loaded` | La dirección de Monopam en la configuración del gateway y el `Admin Token` |
| Un valor personal vuelve sin enmascarar | El nombre de la columna y el formato almacenado. Después añada una regla de enmascaramiento explícita para la columna |
| Un aprobador ve una solicitud caducada y otra nueva para la misma sentencia | Decida la nueva. Solo esa puede decidirse todavía |