Re: Seguridad de la informacion

----- Original Message -----
From: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
To: "Edwin Quijada" <listas_quijada(at)hotmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Friday, January 04, 2008 10:26 AM
Subject: Re: [pgsql-es-ayuda] Seguridad de la informacion

> Edwin Quijada escribió:
>>
>> Estoy metido en un nuevo proyecto para un callcenter y obviamente he
>> seleccionado a Postgres como motor de bases de datos, lo impuse a la
>> fuerza :), pero me asalta una duda con respecto a ciertas
>> informaciones sensitivas que se manejaran dentro de mi base de datos
>> como tarjetas de credito, informaciones medicas , ID SS, y otras cosas
>> mas que son sensibles.
>>
>> El cleinte me ha pedido que tanta seguridad hay en poder ver esta
>> informacion. Ellos tienen un conjunto de personas que trabajan desde
>> la BD y no desde las app pero ellos no quieren que esta informacion la
>> esten viendo ellos . Obviamente tenemos la cuestion de los permisos
>> pero quieren ir un poco mas alla y encriptar la informacion he pensado
>> en Pgcrypto para esto pero no estoy muy seguro sobre ello, debo
>> confesar que nunca la he usado, por lo que pido, si alguien ha tenido
>> alguna, experiencia con este tipo desarrollo de manejar la informacion
>> encriptada me pueda recomendar algo sobre por donde empezar.
>>
>> la idea es que los programdores no puedan tener acceso a esta
>> informacion no se algo como encriptacion con dos claves donde ellos
>> tenga una y otra sea privada o no se algo asi soy neofito en esto.
>
> Es complicado el tema del cifrado ("encriptacion"). De partida porque
> en alguna parte hay que descifrar, y para eso necesitas la llave -- pero
> si tienes la llave para descifrar y el texto cifrado, entonces es lo
> mismo que si tuvieras el texto sin cifrar. Por lo tanto, lo de cifrar
> no te da ninguna seguridad, a menos que puedas esconder la llave.
>
> Otro elementos a considerar es quienes tendran acceso como superusuarios
> a la BD. Porque si tienes varios superusuarios, ellos posiblemente
> podran ver todo el contenido de la BD. _A menos_ que tengas la
> informacion cifrada, y que el descifrado se haga fuera de la BD. Pero
> en ese caso, la gente que haga la aplicacion va a tener la clave de
> descifrado, y te encuentras en la situacion del parrafo anterior.
>
> En resumidas cuentas, _primero_ tienes que establecer de que estas
> tratando de protegerte (en detalle). Eso es lo mas dificil. Una vez
> que has hecho eso, escoger e implementar un modelo de seguridad no es
> tan complicado.
>
> Si lo de los permisos (GRANT/REVOKE) no es suficiente como modelo de
> seguridad, las cosas se ponen _muy_ cuesta arriba.
>

No se si aplica, pero tal ves se podría hacer un mix ... tener los datos
"inseguros" en una DB/Schema con permisos flexibles y visible a "todos" y
los datos "seguros" en otra DB/Schema con permisos restrictivos a nivel del
motor. Para aquellos que interactuan directamente con la DB tendrán un
usuario que les permite visualizar toda la información insegura y SOLO la
aplicación tendrá acceso a los datos "seguros" y se encargará de asociarlos
dentro de la aplicación. Esta solución implica un esfuerzo adicional dentro
de la aplicación para conectarse a dos origenes de datosy luego juntar la
información insegura + segura. Lo ideal es que sea a nivel de Schemas porque
si es a nivel de DB implica el uso de "dblink" volviendo el acceso lento y
complejo.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

> Con respecto a las tarjetas de credito, la recomendacion tipica es que
> si no eres un experto en seguridad, NO LAS ALMACENES. Tarde o temprano
> te las van a robar y vas a estar en un problema muy gordo. Las
> informaciones medicas y otras pueden ser muy privadas tambien, pero si
> no puedes conseguir dinero facilmente con ellas entonces es menos
> posible que te las ataquen.
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> PostgreSQL Replication, Consulting, Custom Development, 24x7 support
> --
> TIP 7: no olvides aumentar la configuración del "free space map"