database - publicidad - programa para crear aplicaciones android gratis

¿Cómo creo una aplicación web en la que no tengo acceso a los datos? (12)

¿El escenario 3 no expondría todos los datos al sitio web mágico? Esto no parece un problema solucionable (al menos no puedo pensar en una solución).

Premisa : los requisitos para un próximo proyecto incluyen el hecho de que nadie, excepto los usuarios autorizados, tienen acceso a ciertos datos. Esto generalmente está bien, pero esta circunstancia no es habitual. Los requisitos establecen que no hay forma de que incluso el programador o cualquier otro empleado de TI pueda acceder a esta información. (Quieren que lo guarde sin poder verlo, nunca).

En todos los escenarios que he encontrado, siempre puedo encontrar una manera de acceder a los datos. Déjame describir algunos de ellos.

Escenario I: Restringir la tabla en la base de datos activa para que solo el administrador SQL pueda acceder a ella directamente.
Hack 1: despliegue un cambio que envía los datos a una tabla diferente para su posterior visualización. Además, el administrador de SQL puede ver los datos, lo que rompe el requisito.

Escenario II: Cifre los datos para que se requiera una contraseña para descifrar. Esta contraseña solo sería conocida por los usuarios. Se requerirá cada vez que se cree un nuevo registro y cada vez que se recuperen los datos de un registro anterior. El cifrado / descifrado ocurriría en JavaScript, de modo que la contraseña nunca se enviaría al servidor, donde podría registrarse o inhalarse.
Hack II: despliegue un cambio que registre las pulsaciones de teclas en javascript y las registre en el servidor para que pueda recuperar la contraseña. O bien, despliegue un cambio que simplemente almacene los datos no cifrados en un campo oculto que pueda publicarse en el servidor para su posterior visualización.

Escenario III: Haga lo mismo que en el Escenario II, excepto que el cifrado / descifrado ocurre en un sitio web que no controlamos. Este sitio web mágico permitiría a un usuario ingresar una contraseña y los datos encriptados o de texto plano, luego usar javascript para descifrar o encriptar esos datos. Luego, el usuario podría simplemente copiar el texto encriptado y ponerlo en el campo para nuevos registros. También tendrían que usar este sitio para ver el texto sin formato para los registros antiguos.
Hack III: Además de instalar un registrador de teclas completo en su sistema, no sé cómo romperlo.

Entonces, el Escenario III parece prometedor, pero es engorroso para los usuarios. ¿Hay alguna otra posibilidad que pueda estar pasando por alto?

Creo que les diré que tienen que confiar en que algunos de nosotros tengamos acceso (y no lo veamos) o que no obtienen un proyecto.

Gracias por las respuestas. Siéntase libre de publicar más pensamientos si los tiene.

Creo que todavía puedes crear la aplicación de la siguiente manera:

Crea una base de datos de desarrollo y configura un usuario para ella.
Pregúnteles: el tipo de datos, el tamaño y el nombre de cada campo que debe estar en la pantalla.
Configure las pantallas, cree columnas en la base de datos que acepten el tipo de datos y el tamaño que especifiquen.
Implemente la aplicación en producción, conectada a una base de datos vacía. Obtenga a alguien con permiso (no usted) para ingresar y establecer la contraseña en el usuario de la base de datos y establecer la contraseña para el usuario de la base de datos en la aplicación web.
Los usuarios autorizados pueden hacer lo que quieran y nunca vieron cómo se veían los datos.

¡Por supuesto, mantener la aplicación y la depuración va a ser una perra!

- En respuesta a los comentarios:

Ok, entonces después de configurar la contraseña para el nombre de usuario en la base de datos y en la configuración de la aplicación web, escriba un programa que se conecte a la base de datos, establezca una contraseña aleatorizada y luego escriba la misma contraseña aleatorizada para la configuración web.
Evite cualquier paquete saliente de la máquina, excepto a un conjunto de estaciones de trabajo autorizadas, para que no pueda instalar su spyware.
A continuación, establezca la contraseña de administrador en ambos servidores con la misma contraseña aleatoria, luego elimine todos los demás usuarios en los servidores, elimine el programa y elimine el código fuente del programa.
Limpie los discos duros de las máquinas reveladoras con el algoritmo DOD y luego agréguelos a una trituradora industrial.

10. Si el servidor alguna vez necesita depuración, tírelo a la basura, compre uno nuevo y comience de nuevo en el n. ° 1.

Pero en serio, este es un problema insoluble. La mejor respuesta a esto realmente es:

Diles que no pueden tener una aplicación. Escribe tus cosas en papel. Ponlo en una carpeta. Bloquéalo en una bóveda. Empuje, repita.

Debo decir que realmente no me gusta la idea de usar JavaScript en el cliente para descifrar los datos. Eso es un gran agujero ya que cualquier script (hacker, GreaseMonkey, IE7Pro, etc.) puede acceder al DOM y sacar datos de la página.

Además, es muy difícil evitar el problema de los registradores de trazos clave. Si los agrega a la mezcla, entonces sus opciones son limitadas. En ese momento, necesita un FOB de seguridad como RSA (comúnmente utilizado con VPN corporativas) para generar PIN verdaderamente aleatorios. Eso probablemente sea costoso, y es doloroso, y solo lo he visto usar con VPN pero supongo que también podría funcionar con sitios web.

En cuanto al sitio web, me quedaría con HTTPS y encontraría una forma de encriptar / descifrar a través del servidor web en lugar de depender de JavaScript. El tráfico SSL no es muy propenso a olfatear (muy difícil de descifrar), por lo que permite que la encriptación y el descifrado se realicen en el lado del servidor, que (IMHO) es más seguro.

Mire los escenarios bancarios y otras instituciones financieras para un punto de partida, y luego vaya desde allí. Intenta no complicarte demasiado si es posible.

No puede garantizar que no piratee los datos siempre que tenga acceso al servidor en el que vive. Así que dígale al empleador que tiene que alojar los datos en otro lugar y otorgar acceso al navegador del cliente a través de una conexión segura HTTPS.

Puede diseñar su página web para cargar dinámicamente una secuencia de datos XML de forma segura y formatearla en una página web utilizando un script XSLT en el cliente.

Ver http://www.w3schools.com/xsl/xsl_client.asp para ejemplos

De esta forma, produces el código, pero nunca tienes acceso a los datos. Solo el usuario tiene acceso a sus propios datos.

En cuanto a la forma en que el empleador va a alojar los datos sin otorgar acceso a ninguna persona de TI, ese es su problema. Es un requisito tonto.

Nunca puede tener el 100% de seguridad, y la seguridad adicional tiene un costo de velocidad / precio / conveniencia, etc.

Supongamos que toma el escenario 3: uno de sus programadores puede usar ingeniería social para obtener la contraseña de uno de los usuarios. Adiós a la seguridad.

No tiene sentido tener una puerta de hierro de alta seguridad como puerta de entrada si las personas pueden simplemente caminar alrededor de ella. Simplemente implemente un nivel de seguridad decente.

Pídale al cliente que le proporcione un Acuerdo de no divulgación para que lo firme, lo firme y luego busque tantos datos como desee.

Lo que me pregunto es, ¿qué será exactamente capaz de hacer con los datos encriptados de todos modos ? Casi todas las aplicaciones requieren que filtres los datos, ya sea moverlos a un lugar requerido, modificarlos, desinfectarlos o mostrarlos. De lo contrario, solo eres un tubo glorificado, y no tienes que hacer ningún trabajo.

La única forma en que puedo pensar que no miraría los datos o haría algo con ellos sería un mapeo simple de tabla a tabla con las opciones de CRUD. Si sabe en qué formato estarán ingresando los datos, ya que debería poder implementar algo con RoR, un aspecto simple, poner SSL en la mezcla y desplegarlo. Pruebe con datos ficticios en el mismo formato y ya está configurado.

De hecho, ¿su cliente no puede suministrar datos ficticios para las pruebas? Si pueden, entonces su vida es simple, ya que todo lo que hacen es proporcionar un "instalable" y decirles cómo editar un archivo de configuración.

Si esto es realmente un requisito, la única forma de protegerse contra esto es contratando una empresa externa para auditar el código antes de lanzar el software, y eso va a ser muy costoso.

Si puede tener javascript en la página, entonces no creo que haya nada que pueda hacer. Si puede verlo en un navegador, significa que está en el DOM, lo que significa que puede escribir un script para obtenerlo y enviárselo después de que haya sido descifrado.

¿Estos problemas usualmente no se resuelven mediante controles?

Todos los programadores necesitan un cierto nivel de aprobación y verificación de antecedentes
Están entrenados para comprender que el despliegue del código para acceder a los datos es un delito inutilizable o peor.
Cada cambio en ciertas áreas necesita algún tipo de firma

Por ejemplo, sin JavaScript en la página sin firma.

Si puede agregar cualquier código que desee, siempre hay una forma, IMO.

Vaya con la solución que le resulte más fácil de implementar, creo que los requisitos muestran que el cliente no comprende el desarrollo de software, por lo que debería ser fácil vender cualquier enfoque que tome.

(Quieren que lo guarde sin poder verlo, nunca).

Oye, la industria discográfica quiere que la gente pueda escuchar su música, pero no copiarla. ¡Parece que deberían juntarse alguna vez!

Su idea no funcionará por el mismo motivo por el que DRM no funciona: la cadena de confianza está intrínsecamente comprometida. Los ejemplos de encriptación a menudo usan Alice, Bob y Charlie, donde Alice intenta comunicarse con Bob sin que Charlie los escuche. Con DRM, la cadena de confianza se ve comprometida porque Bob y Charlie son la misma persona. Con su situación, Charlie es el tipo que escribe el software que Alice y Bob usan para comunicarse. Hay una confianza implícita, porque si no confías en Charlie, tampoco puedes confiar en el software de Charlie.

Esa es la raíz del problema: confianza. Si no pueden confiar en el programador, el juego termina antes de que comience.

Hay muchas opciones basadas en lo que realmente es su objetivo, pero estoy confundido por su paranoia, er, intento:

¿Es este su (y el usuario final) de datos que desean mantener los datos privados o del usuario final para mantenerlos privados de todos?
¿Es solo que su compañía (o cualquier compañía contratada) es sospechosa?
¿Temen el espionaje por cable?
¿Temen el acceso DOM a través de JavaScript o complementos de navegador?

¿Están planeando la implementación por etapas? En ese caso, usted trabaja en el servidor de prueba / revelador sin datos reales, pero no tiene acceso al servidor de producción con los datos reales, y las reglas de registro y / o firewall de DNS impiden que todos sus hacks funcionen sin ser detectados.

En última instancia, si los datos están almacenados en un DB, entonces el programador y el administrador de DB pueden, trabajando juntos, obtenerlo. Período. Una buena auditoría debería descubrir eso, sin embargo.