Re: Informacion encriptada

Jaime Casanova escribió:
> 2013/8/2 Edwin Quijada <listas_quijada(at)hotmail(dot)com>:
> > Me presento ante un problema que mas tecnico digamos que es de procedimiento
> > y quería saber algunas ideas de ustedes o si se han enfrentado algo asi.
> >
> > Estoy desarrollando una aplicación para el gobierno y por lo delicado de la
> > información, incluso estará en la nube y después de estos lios de Snowden,
> > el primer requisito ha sido que la información, ya que es muy sensible,
> > necesita estar encriptada y ya sabemos a donde va esto.
>
> En Ecuador la ley prohibe poner información del gobierno en la nube,
> de hecho no puede estar alojada fuera del país. Lo normal es que cada
> institución aqui tenga sus propios servidores o, en el peor de los
> casos, que dos instituciones compartan al menos storage

A mí me parece una prohibición razonable. Poner servicios de datos en
otro país significa que van a estar regulados por una legislación
ajena a la tuya, y en caso de conflicto de intereses un organismo
gubernamental de otro país podría exigirle a quien hospeda que entregue
los datos, etc. Esto no es hipotético, ya ha ocurrido varias veces.

Poner datos sensibles en "la nube" me parece un error muy serio.

> > Lo que me preocupa es la velocidad de busqueda de esta información
> > encriptada si tengo primero que desencriptar o hacer la busqueda de igual
> > forma, claro no sera toda la BD que estara encriptada sino varios campos
> > como textos pero habra mucha información sin encriptar como fechas, ID,
> > códigos, atributos de relaciones,etc.

> Es simple: mas seguridad = menos rendimiento.
> Y si, ya he sufrido las idioteces de los asesores...

Depende de la funcionalidad que quieras exponer a los usuarios.
Claramente no puedes ofrecer búsqueda de texto con TEXT SEARCH porque
eso expondría la información sin cifrar.

Ojo que el cifrado asimétrico es **lento**. Yo creo que deberías
considerar usar cifrado simétrico (digamos, algoritmo AES o similar), y
las llaves sólo las tiene el usuario, nunca se almacenan en la BD.
Para guardar nuevos datos, tienes dos opciones: el usuario te los da ya
cifrados (la BD/framework nunca ven los datos en claro) o bien el
usuario te entrega la clave en forma temporal, te pasa los datos, luego
los cifras y almacenas y te olvidas de la llave. El primer caso es más
inconveniente porque necesitas más código al lado del cliente, pero
obviamente es más seguro porque nunca tienes copia de la llave.

Si mal no recuerdo hace mucho tiempo miré un proyecto que estaban
desarrollando unos colegas, de este mismo tipo, y la idea para permitir
búsquedas era almacenar prefijos cortos, sin cifrar.

Otro tema es el de los identificadores numéricos. En un proyecto donde
la confidencialidad de datos es importante, a veces no quieres siquiera
filtrar cuántos ID tienes en una tabla. Para esconder esta información
es importante no usar secuencias. Puedes usar por ej. UUIDs, o bien
mapeando números enteros usando algo como esto:
https://wiki.postgresql.org/wiki/Pseudo_encrypt

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda