Seguridad
Esta página tiene una regla: ninguna afirmación sin su mecanismo. Si algo aquí no se puede sostener en una llamada técnica, sobra. Al final está lo que todavía no tenemos, que es la parte que hace creíble al resto.
Cómo se cifra: sobre, no candado
Cada documento se cifra con su propia clave, no con una clave general. Esa clave se guarda a su vez cifrada por una clave maestra que vive en AWS KMS y que nunca sale de ahí: nosotros pedimos que descifre, no nos la llevamos.
Lo que eso compra es concreto. Destruir un documento no es borrar un fichero: es destruir su clave. La fila conserva la prueba de qué clave había —para poder acreditarlo después— y pierde el material con el que se abría. La base lo impone con una restricción, no con una convención: una clave marcada como destruidano puede conservar material, y una que conserva materialno puede estar marcada como destruida.
El proveedor de KMS se elige con una variable explícita y nunca por el entorno. Arrancar producción con el KMS de desarrollo no es un aviso: es un arranque que falla.
Quién puede leer, y quién no
La aplicación no entra en la base como administrador. Hay cinco roles distintos y cada uno puede hacer una cosa: migrar el esquema, servir la aplicación, purgar, auditar y resolver enlaces. Ninguno de los cinco puede saltarse el aislamiento —los cinco tienen NOBYPASSRLS—, y eso incluye al que atiende cada petición del panel.
Los permisos son parte del diseño y no configuración suelta. El rol que sirve la aplicación, por ejemplo, no puede borrar de la auditoría. No es que la aplicación no lo intente: es que la base no se lo permitiría.
Un despacho no ve lo de otro, y no depende de que el código acierte
El aislamiento entre despachos no lo hace la aplicación: lo hace la base de datos, con FORCE ROW LEVEL SECURITY. La diferencia importa. Si el aislamiento fuera un WHERE en el código, bastaría una consulta nueva escrita con prisa para que se filtrara. Aquí, una consulta que se olvide del filtro devuelve cero filas, no las de otro.
33 de 43 tablas con RLS forzada
58 políticas activas
9 pruebas de aislamiento, en cada cambio
Contado contra la base de producción, no estimado. «Forzada» quiere decir que alcanza también al propietario de la tabla: sin esa palabra, el dueño se salta sus propias políticas.
Qué le pasa a un fichero cuando entra
Nada se guarda donde se sirve. El fichero entra en un bucket de cuarentena, se examina, y solo entonces pasa al bucket de documentos. Son dos sitios distintos, no dos carpetas.
El control que más protege no es mirar la extensión, es rehacer el fichero. Las imágenes se reencodifican, y eso destruye cualquier contenido activo que llevaran dentro tenga o no firma conocida. Los PDF se rechazan si traen contenido activo, si vienen cifrados, si su estructura no se puede leer, si pasan de 300 páginas o si el tipo real no es el que dice el nombre. Se guarda el hash de lo recibido y el de lo almacenado, porque cuando se reencodifica no son el mismo fichero y conviene poder demostrar cuál es cuál.
Sobre el escaneo por firmas, hay algo que decir y está más abajo.
El enlace que recibe tu cliente
Un enlace por correo o WhatsApp es, por definición, algo que puede acabar reenviado. Por eso el enlace no basta: pide además un código de un solo uso al canal del destinatario. Hasta que ese código no se verifica, la sesión no puede subir nada — no es que la interfaz lo esconda, es que el permiso no existe.
El número de envíos de código está limitado en la propia base, así que agotar códigos a fuerza bruta tampoco es una vía.
Una auditoría que no te pide fe
Cada acción queda registrada, y el registro está sellado por segmentos encadenados: cada segmento lleva su hash y el del anterior, de forma que alterar un evento viejo rompe todo lo que vino después. No es un registro que se pueda «corregir» sin que se note.
Y hay un paso más, que es el que quita el «confía en nosotros»: el sello se ancla fuera, en una cuenta distinta y en un proveedor distinto del que guarda los documentos. Puedes recalcular la cadena y contrastarla contra ese testigo externo sin preguntarnos nada. Si nosotros y el testigo discrepamos, el que miente somos nosotros.
Cuando toca destruir
La supresión termina en un certificado de destrucción, y ese certificado se guarda en el almacén inmutable — si se pudiera reescribir, no probaría nada.
El certificado dice también algo que casi nadie pone por escrito: cuánto tarda de verdad. El material de clave envuelto sobrevive en las copias de seguridad hasta que esas copias caducan, y eso son siete días. Ese número no es un detalle interno: viaja dentro del certificado que se entrega, porque un certificado que dice «destruido» y omite la ventana de las copias es un certificado que engaña.
Dónde viven los datos, y quién más los toca
Los datos no están en Perú. Lo decimos primero porque es lo que más se pregunta y lo que peor sienta descubrir tarde. La base y los documentos están en Estados Unidos (US East), y el servidor de aplicación está en la misma región a propósito.
Estos son los subencargados, con nombre y país:
- Neon (EE. UU.) — la base de datos.
- Cloudflare R2 (EE. UU.) — los documentos, en dos cuentas separadas: una para operar y otra, distinta, para el ancla de auditoría.
- Amazon Web Services (EE. UU.) — la clave maestra (KMS), el testigo externo de la auditoría y el envío de correo.
- Contabo (EE. UU.) — el servidor de aplicación.
Que el ancla viva en una cuenta distinta de los documentos no es orden: es que quien pudiera entrar en una no puede tocar la otra.
Las copias, y cómo sabemos que existen
La base se copia a diario, cifrada con una clave pública: la máquina que escribe las copias no puede leerlas. Quien entre en ese servidor se lleva ficheros que no puede abrir.
Y hay tres cosas vigilando, porque cubren fallos distintos: una avisa de lo que falla, otra avisa de que el proceso ha dejado de responder —un proceso muerto no puede denunciar su propia muerte—, y una tercera mira el almacén desde fuera, con una credencial de solo lectura, por si algún día el proceso dice que sí y no es verdad.
Lo que todavía no tenemos
Esto está aquí a propósito. Un producto de custodia que enumera sus límites es más fiable que uno que los omite, y sobre todo no se cae en la primera pregunta difícil.
No hay antivirus por firmas
El flujo de cuarentena es real y el sanitizado también, pero el motor de firmas conectado hoy solo detecta el fichero de prueba estándar: sirve para comprobar que la tubería funciona, no para detectar malware real. Lo que de verdad protege ahora mismo es el reencodificado, que neutraliza contenido activo sin depender de conocer la firma. Conectar un motor real no cambia el diseño —entra por el mismo sitio—, pero hasta que se haga, no digas que escaneamos.
No hay ISO 27001 ni SOC 2
Ninguna certificación, ni en curso. Lo que hay son mecanismos que se pueden auditar uno a uno, que es distinto y más barato de verificar, pero no es un sello.
Un solo servidor
La aplicación corre en una única máquina. Si se cae, el servicio deja de estar disponible hasta que vuelva. No se pierden documentos —viven en el almacén, no en ese disco— ni se pierde la base, que está fuera y tiene copias; lo que no hay es continuidad automática.
El almacén principal no tiene bloqueo de objetos
Comprobado contra la cuenta real: nuestro proveedor de almacenamiento no implementa el bloqueo por retención que sí ofrece S3. Por eso el testigo externo de la auditoría vive en otro proveedor. No es una segunda defensa: es la única, y preferimos que se sepa.
La facturación electrónica está en curso
La homologación ante SUNAT no está terminada. Se puede usar el producto; lo que no podemos todavía es emitir el comprobante electrónico por esa vía.
Y esto no es cifrado de extremo a extremo
Nosotros podemos descifrar los documentos: hace falta para examinarlos, mostrarlos en el panel y destruirlos cuando toca. Un producto de extremo a extremo real no podría hacer nada de eso. Lo que sí está acotado es quién puede, y cada vez que ocurre queda en la auditoría sellada.
¿Falta algo que necesitas para decidir? Pregúntanoslo y te contestamos con el mecanismo, no con un adjetivo.