Privacidad en un SaaS

¿Se os ocurre cómo conseguir privacidad en un SaaS?

Estamos pensando un modelo SaaS en que la empresa no conozca ningún dato relevante del cliente, es decir, ni email, ni teléfono, ni nombre …

Dos grandes retos a solucionar:

  1. ¿cómo creas un sistema de registro y de recuperación de cuenta?

Se puede crear un sistema basado en usuario y contraseña… pero, ¿cómo crearías un sistema para recuperar la cuenta si no te puedo “mandar nada” a ningún sitio para recuperarla? Y tampoco serviría poner preguntas secretas, porque también se te podrían olvidar.

  1. ¿cómo gestionarías los pagos?
    La única solución que me viene a la cabeza es Bitcoin, pero, obviamente, es algo muy muy muy poco popular y pocos podrían pagar. ¿De que forma se podrían gestionar pagos sin que la empresa tenga realmente los datos de esa persona?

¿Creéis que se puede hacer algo así? ¿O siempre estamos abocados a “tener que pedir datos personales” a los clientes para trabajar con ellos?

Hola @dantart,

Aunque yo obviamente no domino la parte técnica a ese nivel, sí se me ocurre que ciertos servicios permiten “proteger los datos” que recoges en ciertas llamadas / acciones / integraciones, de forma que la privacidad siempre se mantenga.

Un ejemplo que se me ocurre es Integromat (Integromat - Achieve more in less time with fewer people). Yo lo utilizo para automatizar algunas segmentaciones y acciones de marketing o con wordpress, y al crear la automatización, tiene una opción que permite proteger los datos, de forma que yo como admin solo veo los kbs de transferencia, pero no el dato personal de ese usuario.

Esto no es una solución “elegante” o “robusta” de cara a un SaaS per sé quizá, pero muchos SaaS utilizan Integromat, y las posibilidades para integrar APIs, 3rd parties, etc son bastante extensas, así que si le echas imaginación se pueden crear muchos escenarios donde todo esté protegido. Habría que testear las acciones, triggers, etc que permite usar para Wordpress (si lo estáis haciendo en wordpress), u otros CMS, backend, etc.

Por supuesto, es solo un ejemplo para ilustrarlo. Seguro que hay otras aplicaciones que permiten esa misma protección de los datos individuales de cada usuario. Obviamente sí que se hace un tratamiento de los datos y todo el tema RGPD tiene que estar en regla, y el usuario aceptar la política de privacidad de datos, etc, pero tú como empresa es cierto que no ves esos datos concretos.

Eso al menos para el tema registro / cuentas / etc. Para el tema pagos…ahí sí que no se me ocurre nada, porque por ley, protección de datos, consumo, etc, hay una recogida de datos que es necesaria sí o sí, al menos en Europa que yo sepa.

Espero que ayude aunque sea un poco!

Actualizo con una captura de a lo que me refería:

No me expliqué bien … cómo le creas una CUENTA en tu SaaS a un usuario del que NO quieres saber ni email ni teléfono, y que él pueda recuperar su acceso si lo pierde.

Que te parece la combinación User/password de toda la vida y que la pregunta de recuperación sea la fecha de nacimiento? Esa respuesta no se olvida, creo yo… de hecho para confirmarla desde tu sistema puedes haberle pedido ese y otros datos al usuario en el onboarding tras el registro básico.
Y ya simplificándolo del todo: user + keyword en el que esta última sea obligatoriamente la fecha de nacimiento (tienes que explicarle al usuario porque lo haces al principio)… y si no la recuerda, que la pregunta de recuperación sea esa misma otra vez, ¿cuál es la fecha de nacimiento que indicaste en tu registro?

Demasiado fácil de hackear … la fecha de nacimiento es de lo más fácil de sacar de alguien

Vale! No lo entendí bien yo entonces.

Lo que dice @JoseAlbertoG me parece buena idea y elegante en cuanto a complejidad, aunque es verdad que la fecha es demasiado fácil de adivinar. Quizá dándole una vuelta (una pregunta secreta que aunque pueda olvidarse, sea personalizada para el usuario).

De todas formas, me gustaría saber (si se puede decir) ¿por qué no queréis ni siquiera saber el email? ¿Cuál es la razón detrás de no querer tener ningún dato del usuario? ¿Este SaaS se va a monetizar? Porque según la respuesta a esas preguntas, se pueden dar otras alternativas (por ejemplo, que directamente no haga falta crear una cuenta, y todo ocurra en modo “guest” siempre).

[brainstorming mode ON]

1 - Yo exploraría algún dato biométrico que se comporte como identificador único. Te haría de usuario y contraseña, y salvo que lo cruzaras con una base de datos externa, para ti como SaaS sería completamente imposible de identificar quién está detras de la cuenta (e.j. la huella dactilar, pros: es única y sería fácil de capturar en un smartphone; contra: la gente pensaría que es fácil que alguien, como la policía o el CNI, lo cruzaran con sus bases de datos; alternativas: pupila, timbre de voz, combinación de un par de ellas). Y creo que resolverias el tema de la recuperación de la cuenta, salvo si el usuario la palmaba! :slight_smile:

2 - El tema pago, si quieres mantener ese nivel de privacidad, te vas a ver obligado a pasar por crypto sí o sí. Y aún y todo, muchas plataformas o wallets acaban teniendo datos de la persona pq las cuentas están conectadas a cuentas fiat… Es decir, salvo que tu SaaS sea un generador de cash y a la vez un colocador de cash, lo tienes chungo. Pero yo trabajaría sobre esa idea. Tu core, el de tu SaaS, completamente privado, un % de usuarios que “vive” dentro de tu SaaS, completamente privados, y algunos grandes players o external customers o service provides (p.e. corporaciones que no buscan esa misma privacidad) en semi-privado. Es decir, un privado q corre el riesgo de ser trackeado fuera de tu SaaS, pero en relación a las transacciones en el mismo.

3 Likes

Hola @dantart.
Para el problema 1 se me ocurre esto:
El usuario introduce la contraseña y email que quiere usar en el registro en la web .

Con esta información en el servidor se configura y compila un ejecutable que contiene la información del usuario, un hash unico para ese programa para verificar su autenticidad y relacionarlo con la informacion de la aplicación a la que puede acceder y se lo descarga.

Cuando quiera recuperar la contraseña, o hacer login usará ese programa que se generó y que tiene en su ordenador/móvil.

Si pierde todas las copias de ese programa, no podrá acceder a su cuenta ni volver a entrar ni recuperar la información. Un gran poder conlleva una gran responsabilidad.

El flujo mas o menos sería:

  1. Entro en el registro web pongo mi email y contraseña.
  2. Se genera la app
  3. La descargo
  4. La ejecuto, pongo mi usuario y contraseña y entro
  5. Aquí habría dos opciones que el frontal de la app web estuviese dentro del ejecutable y se ejecutase en un navegador embebido dentro del ejecutable, o que abra una web en un navegador con una cookie que le de acceso a su información.

Como la información comprometida está en el programa del usuario y tu no la almacenas en ningún sitio no sabes quien tiene que información. Solo que la app x puede acceder a la información con id 1234.

Para el 2, los pagos deberían ser también a través de la app que se descarga el usuario, tu como empresa solo sabras que la app x ha pagado pero no el número de cuenta o el email desde el que lo ha hecho.

Un saludo.

2 Likes

Hola @Pablo
Efectivamente, la generación de una “llave - archivo” podría ser una solución. Me da miedo que se pierda o que el usuario no se acuerde de donde está.
Pero como bien dices “Un gran poder conlleva una gran responsabilidad.”

1 Like

En sistemas Zero-Knowledge, en los que el proveedor no tiene acceso a la información, la posibilidad de pérdida de la clave de cifrado por parte del usuario es un problema serio.

Yo he tratado de resolverlo enviándole un fichero de recuperación (la propia clave) a las redes sociales que indique, por mensaje privado, sin mencionar la utilidad que tiene el fichero. Lo que guardo en mi base de datos es a qué alias de qué redes sociales lo envié, y en qué fecha. El usuario debería poder encontrarlo después con mis indicaciones. . El alias de quien envía debería ser anónimo y cambiante.

“Ve a Mensajes de Facebook, busca un mensaje procedente de de SAAS1234567 de tal fecha”

No se si ayuda…

1 Like

Es una forma muy original, sin duda… y algo enrevesada :wink:
GRACIAS @Jmarnaiz

1 Like

:crazy_face: si encuentras algo mejor, coméntamelo. :weary: