Desarrollo bajo buenas practicas de seguridad!... que herramientas usar??

tu post debería decir "queremos desarrollar bajo buenas prácticas de seguridad pero no sabemos cuáles son"

Les recomiendo que lean Secrets & Lies de Bruce Schneier, y los dos de Kevin Mitnick Art of Intrusion y Art of Deception (sobre todo el primero, porque el segundo es más de ingeniería social y contra eso sólo puedes poner procedimientos, no tecnología).

Yo seguí la técnica de Schneier del paisaje de vulnerabilidad, para identificar los puntos donde estás más vulnerable, o donde un ataque puede causar mayor daño, y enfocarme a reforzar la seguridad ahí.

De manera general, primero tienes que poner políticas de qué cosas tu sistema debe permitir a los usuarios. Y todo lo que no está explícitamente permitido debe estar prohibido. De esa manera tienes que diseñar el sistema. Considerar que si haces una app web, asegurarte que las páginas que sólo deben ser visibles para usuarios validados realmente sólo las puedan ver usuarios validados y que si pegas el URL de una página interna en un browser sin ser usuario validado, no te debe aparecer la página ni marcarte un error ni nada de eso.

El cifrado de datos es para evitar ataques internos de gente que tiene acceso a la base de datos, pero ahí viene una bronca que alguien ya había puesto hace tiempo aquí. Si vas a guardar passwords, no los cifres, guarda una digestión. De ese modo no tienes manera de saber el password de un usuario, pero no lo podrán recuperar, sino que el procedimiento en caso de que olviden su password deberá ser distinto.

Para datos como de tarjeta de crédito y cosas así, que tu aplicación tiene que poder leer, pues conviene guardarlos cifrados, la bronca es que alguien con acceso a la base de datos probablemente tenga acceso a la aplicación y por ahí se encuentre la llave que se usa. Entonces el manejo de llaves se vuelve muy complicado y tienes que ser muy estricto en separar la gente que puede ver la base de datos de la gente que puede ver y modificar el ambiente donde corre la aplicación. Los que tienen acceso a las llaves no deben tener acceso a la base de datos y los que tienen acceso a la base de datos no deben tener acceso a las llaves. Y para cada usuario debes usar una llave distinta, no sirve de nada que cifres toda la info de la base de datos con la misma llave.

En fin, no está nada fácil, pero lo más importante es que están empezando y que la seguridad debe ser un aspecto que deben integrar al diseño y desarrollo de la aplicación, no solamente algo que quieran meterle al final como si fuera un plugin porque así no funciona. Y cuando resuelvan un problema de seguridad, asegúrense de que su solución es efectiva y no que solamente da la impresión de ser seguro.

Estoy empezando con el análisis para el desarrollo del proyecto, y si tienes razón así debería de llamarse el post, aun mi experiencia es joven y sobre todo en la seguridad de un sistema, Y es precisamente lo que queremos lograr un sistema que no simplemente luzca seguro, si no que de verdad tenga un análisis de seguridad para resolver el tema!.
Gracias por la recomendación de los libros los tomare muy en cuenta.

Muy buen panorama acabas de plantear,!! y si como comentas voy empezando con el proyecto y es un punto que quiero cubrir desde un principio.

Hola:

Tengo entendido que se sugiere que no se mantenga una tabla de aplicación con las contraseñas de los usuarios, ni encriptada ni nada (claro que puedo estar en un error); lo que se sugiere es que se utilicen usuarios propios de la bd para acceder a la información desde la aplicación.

De ser correcto lo anterior, tengo una (muchas) duda:

También tengo entendido que el pool de conexiones se crea con un único usuario de la bd... Creo que eso ya se vuelve incompatible ¿no? ¿Cómo se puede hacer para que la conexión se realice con cada usuario de la bd usando un pool?

Ojalá puedas responderme o indicarme en dónde encontrar información. Te lo agradeceré enormemente.

No hay balas de plata en esto de la seguridad. Todo depende del tipo de aplicación.

Una aplicación interna de una empresa, con unos cuantos usuarios (digamos menos de 100), pues sí, se puede administrar el acceso pidiendo login al usuario y validándolo directo en la base de datos. De esa manera el DBA tiene que crear los usuarios con los privilegios mínimos necesarios para que puedan operar. La bronca es que si el DBA no está o no tiene tiempo de crear usuarios nuevos o le da flojera estarles poniendo permisos y a todos los deja hacer todo, pues ya no sirvió el esquema.

Si tienes una aplicación web que potencialmente puede tener miles de usuarios, se vuelve impráctico tener tantos usuarios en la base de datos. En ese caso es mejor manejar solamente un usuario para la aplicación, tener como dices un pool de conexiones, y manejar el control de acceso de los usuarios desde la aplicación en vez de aventarle la bronca a la base de datos. En esos casos lo mejor es que los passwords se guarden digeridos (no cifrados) utilizando algun dato del usuario como su email junto con el password que ponen, para que la digestión del mismo password con dos usuarios distintos se vea diferente en la base de datos.