Seguridad de datos en una app: lo básico bien hecho

La seguridad de datos en una app no es una función que se enciende: es un conjunto de decisiones repartidas por todo el proyecto, desde cómo viajan los datos hasta cuánto tiempo se conservan. Ninguna app es invulnerable, y quien lo prometa exagera. Lo razonable es aplicar medidas básicas bien hechas, reducir lo que se guarda y tener un plan para cuando algo falle. Esta página lista esas medidas y qué conviene preguntar al encargar el desarrollo.

Datos en tránsito: que viajen cifrados

Toda comunicación entre la app y el servidor debería usar HTTPS, que cifra la información en el camino y evita que alguien en la misma red wifi la lea o la modifique. Es una práctica estándar y, en las plataformas móviles actuales, prácticamente esperada. Lo mismo vale para el panel web y para las conexiones entre servidores. Se complementa con certificados vigentes y una renovación automática, porque un certificado vencido corta el servicio.

Contraseñas: nunca en texto legible

Una app que guarda contraseñas tal cual las escribe el usuario es un riesgo grave: si se filtra la base, se filtran todas las claves, y como mucha gente repite contraseñas, el daño se extiende a otros servicios. La práctica correcta es almacenar solo un hash, es decir, una transformación irreversible hecha con algoritmos pensados para contraseñas y con un valor aleatorio propio de cada usuario. Para evitar manejar contraseñas directamente, a veces conviene apoyarse en proveedores de identidad, tema que se discute en login y autenticación.

Permisos mínimos

El principio es simple: cada persona y cada componente debería poder hacer solo lo que necesita. Un empleado de mostrador no necesita exportar toda la base de clientes; el servicio que envía correos no necesita borrar pedidos. Aplicarlo implica definir niveles de acceso (ver roles y permisos) y que el servidor verifique cada pedido, sin confiar en que la app «oculte» botones. También aplica a la app móvil: pedir al sistema solo los permisos del dispositivo que realmente usa.

Copias de seguridad

Las copias protegen frente a errores humanos, fallas del proveedor y ataques que destruyen datos. Para que sirvan, hay que resolver varias cosas:

• Qué se copia y con qué frecuencia, según cuánto trabajo se tolera perder.
• Dónde se guardan, separado del sistema principal.
• Quién puede acceder a ellas, porque una copia también contiene datos sensibles.
• Que se hagan pruebas de restauración. Una copia que nunca se probó es una suposición, no una garantía.

Qué datos conviene no guardar

El dato que no se guarda no se puede filtrar. Antes de agregar un campo, preguntate si realmente se usa. Algunos ejemplos:

• Números completos de tarjeta y códigos de seguridad: los procesadores de pago existen justamente para que no pasen por tu sistema.
• Documentos o fotos de identidad que solo se necesitaron para una validación puntual.
• Historiales más antiguos de lo que el negocio o la ley requieren conservar.
• Datos sensibles, como salud u orientación, salvo que la función lo exija; en ese caso, con mayor cuidado y fundamento.

La Ley 25.326 de Protección de Datos Personales rige en Argentina y fija principios como finalidad, proporcionalidad y consentimiento. Está desarrollada con más detalle en la guía sobre datos personales; ante dudas legales, consultá con un profesional del derecho.

Otras prácticas de base

• Validar toda entrada en el servidor, para evitar que datos maliciosos lleguen a la base.
• Mantener actualizadas las bibliotecas y el sistema del servidor, porque las vulnerabilidades conocidas se explotan masivamente.
• Proteger las claves de servicios externos: no se incluyen dentro de la app, que puede ser inspeccionada.
• Registrar accesos y acciones sensibles, para poder investigar si algo ocurre.
• Limitar intentos de acceso para frenar adivinación automática de contraseñas.

Lo que no podemos prometer

Seguir buenas prácticas reduce el riesgo, pero no lo elimina. Tampoco equivale a una certificación: si tu rubro o tus clientes exigen una norma o auditoría específica, es un requisito aparte que hay que identificar desde el inicio, porque cambia el alcance. Conviene desconfiar de cualquier propuesta que garantice «seguridad total».

Impacto en el alcance y el costo

Parte de la seguridad es esfuerzo incluido en un desarrollo bien hecho. Lo que suma trabajo adicional son los requisitos específicos: auditorías, registros detallados de cambios, autenticación en dos pasos, cifrado de campos concretos, políticas de retención y procedimientos de recuperación documentados. Y después del lanzamiento hay trabajo continuo de actualización, que se menciona en la guía de mantenimiento.

Qué preguntar antes de incluirla

1. ¿Qué datos personales o sensibles va a manejar la app?
2. ¿Existe alguna exigencia legal, contractual o de clientes sobre ellos?
3. ¿Cuánto tiempo hay que conservarlos y cuándo se borran?
4. ¿Qué pasa si hay una filtración: quién se entera, quién avisa, cómo se responde?
5. ¿Quién tiene acceso al servidor y a las copias, y cómo se revoca ese acceso?

Siguiente paso

Si tu app va a manejar datos de clientes, hablemos de qué guardar y cómo protegerlo antes de diseñar. Podés escribirnos desde el formulario de contacto; trabajamos desde Rosario.