Si tuviéseis que desarrollar una aplicación que almacenase y tratase datos sensibles de empresas, y cada una de esas empresas tuviera un acceso para tratar esa información (sólo la de su empresa), haríais una instalación distinta por empresa (distinto espacio, distinta BD) o centralizaríais todo en el mismo sistema (mismo host, mismo espacio, misma BD)?
#15211 No hay nada de malo en hacerlo todo centralizado. Sencillamente tienes que implementar una política de acceso/seguridad correcta (permisos, privilegios, contraseñas, accesos, logs, etc...).
#15211 Yo tengo 12 clientes en la misma bd, no veo donde está el problema, que si me revientan la bd tienen los datos de mis clientes?
Si, pero que cambia tener los datos de uno que de todos? Además si te entran en uno siempre vas a tener la duda si entraron en los otros y vas a tenerles que avisar de que sus datos están comprometidos igualmente.
#15211 Yo pondria una caja en la mesa del sysadmin y que metienesen ahi todos docuementos y ya que el sysadmin se encargase.
#15214 Es algo que tienes que decidir, puedes no hacer eso y dedicar un host para cada cliente, pero eso supone más recursos. De la otra manera es más trabajo configurar la seguridad como toca, pero terminas ahorrando, reduces el mantenimiento a un único host, parches, etc...
Si ya estás en modo paranoic-mode, las tablas críticas, encriptas su contenido en RCA/AES. Teniendo en cuenta el breve impacto en el rendimiento si tu host no soporta RCA/AES por hardware.
Supongo que al final dependerá de los datos tambien, no?
Si tienes 30 clientes y, cada cliente, almacena 100millones de registros en la misma tabla, no es lo mismo despues hacer querys a una tabla con 3mil millones de registros que con 100m.
De la misma manera, si vas a guardar el nombre, el email y la hora, pues haz una misma tabla y protege correctamente las querys, los users, etc..
Además, tambien tienes que tener en cuenta el aspecto legal detrás, si vosotros os vais a encargar de los datos, por cada bbdd, host, etc.. tendriais que comentarlo a la LOPD, mientras que si lo teneis todo en el mismo sitio, aunque sean de distintos clientes, con declararlo una sola vez a la LOPD debería de bastar.
#15219 10/10, lo que pasa que si tienes datos que son muy peligrosos como tarjetas de crédito o cuentas bancarias de facturas lo mejor es que cada cierto tiempo, migres los datos a una base de datos baúl encriptada y sólo dejes los datos "vivos" en la base de datos accesible por la aplicación.
Quién hace esto? Naaaadie, pero es que te puedes ir a la cárcel si haces el capullo xD
#15221 Como no almaceno esos datos, no tengo mucha idea, pero juraria que en la LOPD, viene un sistema bastante restrictivo de lo que mencionas en segun que casos ( por ejemplo datos médicos, datos políticos, me suena algo tambien para los datos bancarios.. ) Hasta el punto de que te obligaban a cumplir segun que medidas en el servidor, en el personal que accede, cambios obligatorios de contraseñas cada X tiempo... Más alla de cambiar los datos de sitio, esto creo que no lo cumple practicamente nadie xD
Las cuentas bancarias de facturas no creo que ocasione más problema que recibir de repente una factura o un cargo por algo, que puedes revertir en el propio banco sin problema ( y tienes hasta 6 meses si no hay un acuerdo SEPA, en cuyo caso son 2 meses máx creo ). Tambien tienen el riesgo de que un principe nigeriano ingrese 2 millones de euros, pero te toca ir a la policía y declararlo si no quieres ser complice de 'blanqueo de capitales' xD
En lo referente a las tarjetas, nunca hay que guardar todos los datos de la tarjeta para que el usuario siempre esté obligado a meter el típico CV2, y en lo referente a tener tarjetas 'antiguas', en el momento en el que expiran, hay que eliminarlas del sistema.
En el caso de que vayas a hacer cargos recursivos, el banco tiene un método ( al menos los q son tipo sermepa/redsys si no recuerdo mal ), que en la primera request le indicas que van a ser pagos recursivos, cuantos, de que cantidad y con que duración (máximo 1 o 2 años creo) y lo que te dan es un código único de operación que es el que tienes que utilizar al hacer los cargos que está asociado ya a tu banco y cosas del estilo ( por lo que no hay pq guardar nº de tarjetas tampoco en este caso ).
Vaya tochaco más 'bueno' para un viernes xD
#15223 Pues no lo sabía, en mi caso es obligatorio guardar las tarjetas de crédito cuando se mueve tanta pasta porque en Alemania si investigan a alguien por blanqueo de dinero o movidas raras puede venir la policia a pedirte los datos y tienes que saber exactamente con que tarjeta de crédito pagó y a qué banco, en Espana seguramente le echamos la culpa de todo al banco y la policia lo acepta, pero aquí te metes en un follón guapo.
Las cuentas bancarias es un problema porque pueden usarlas para registrarse en muchos sitios con datos reales de otras personas, si es una cuenta bancaria destinada a ser de conocimiento público no hay problema pero a veces son cuentas bancarias internas de la empresa y si tienen que cambiarlas es un trabajo.
Ostias es viernes?
Push a prod en breves.
#15224 Tambien depende del proceso de pago, ya que existen varias posibilidades de afrontar los pagos con tarjeta. En españa, creo que hay 2 que son los más extendidos (si quitamos paypal y demás, hablamos de cobrar directamente a la tarjeta) y la utilización de uno u otro depende de lo 'grande' que sea la empresa y del dinero que quiera invertir en ello, como siempre..
Por un lado, estamos ante el tipico pago via TPV Online, donde el usuario mete sus datos en la pasarela del banco y el banco se encarga de todo. En este caso se puede seguir obteniendo el código que te comento para pagos recursivos ( o para simplificar el pago del usuario y que no tenga que volver a meter sus datos de tarjeta en la pasarela del banco ). Además, hay una modificación de este paso, en la que el usuario mete sus datos de tarjeta en tu web, y se los envias en la petición al banco, para que tampoco los tenga q meter el usuario allí ( pero no los guardas tu para nada )
Esta es la opcion 'barata' o la que tiene la mayoría de gente, para que te hagas a la idea, ni siquiera te piden un HTTPS (ya que la pasarela del banco si lo tiene)
La otra opcion, es aquella en la que tu te encargas de gestionar todas las tarjetas y datos ( guardando el nº de tarjeta y fecha caducidad en la ddbb ) y se hace una petición al banco por detras (que no ve el usuario) en la que solo se le pasa el importe y el CV2 mismamente. Para esta opción, el banco te debería de pedir unas medidas de seguridad en condiciones por manejar información sensible ( de ahí que sea más cara de implementar o requiera una infraestructura mucho mejor ), Esta es la que manejan páginas como Justeat y parecidas, q te guardan la tarjeta y te piden el CV2 para completar el pago.
De la misma manera, a nivel de LOPD, en la primera creo que te quedas en el nivel básico, mientras que en la segunda, ya creo que estás algo por encima y te toca alguna medida adicional, aunque no me he molestado en leerlo nunca porque nunca me ha tocado almacenar esa información 
EDIT: Siento los tochacos, me he dejado para el viernes algo tranquilo como es analizar unas funcionalidades y hacer un presupuesto y hoy tengo la vena escritora xD
#15211 depende de tu infraestructura, de tu equipo de desarrollo, de tu numero de clientes, etc.
Una arquitectura multi-tenant tiene sus pros y contras, la principal diferencia es que es mas tedioso securizar una app de esas caracteristicas y no todo el mundo lo sabe hacer xd
google: Multi-tenant vs Multi-instance
#15234 Quitando los brackets del lateral, hijo... Al estar el código indentado parece un poco python.
#15235 El codigo siempre esta indentado.
P.D Los de FE estan tocandome la moral y estoy de mal humor, asi que todo que digas voy a ladrarte.
#15216 Hombre... pues es una buena basura.
Se te puede joder con una migracion, tener que hacer rollback, se te joden los indices y afectas a otros clientes..
Que tiene de bueno?
