Transmisión y almacenamiento seguros de datos

Probablemente, la mejor forma de responder a su pregunta será contratar a un asesor de seguridad para realizar una evaluación de seguridad de su enfoque. Parece que no tienes muchos conocimientos de seguridad, por lo que probablemente no estarás en una posición ideal para responder la pregunta por tu cuenta.

Probablemente no nos ha proporcionado suficiente información para que podamos realizar una evaluación de seguridad completa para usted. Los riesgos de seguridad de su enfoque dependerán en gran medida de todos los detalles de cómo funciona su sistema y cómo está configurado y desplegado. Hay muchos detalles que no menciona, pero que son relevantes para la seguridad.

Estos son algunos ejemplos de riesgos de seguridad que pueden ser relevantes para usted, dependiendo de su situación específica:

• Ingeniería social. Pedir a los usuarios que descarguen y ejecuten un programa ejecutable es una idea dudosa, desde una perspectiva de seguridad. Capacita a los usuarios para ejecutar ejecutables de sitios web que no son de confianza, es decir, los entrena para que se comporten de una manera insegura. Es posible que no tenga la intención de ofrecerles un programa malicioso desde su sitio, pero ¿qué sucede si los usuarios van a algún otro sitio y descargan y ejecutan un programa? Si le pide a los usuarios que hagan esto rutinariamente cada vez que quieran usar su aplicación, les está enseñando que esta práctica es correcta.

• Ataques de intermediario. No dice si su sitio usa HTTP o HTTPS (es decir, si usa encriptación SSL / TLS). Si se accede a través de HTTP, es vulnerable a los ataques de intermediarios, como los que se pueden realizar a través de Wifi abierto.

  La mejor defensa es garantizar que su sitio use SSL en todo el sitio (debe ser accesible solo a través de HTTPS; cualquier intento de visitar a través de HTTP debe redirigirse inmediatamente al sitio de HTTPS, o su servidor nunca debe responder a través de HTTP). También debe habilitar HTTP Strict Transport Security en su servidor, para que los clientes sepan que solo deben conectarse mediante HTTPS.

• Control de acceso. No nos ha dicho cómo limita quién puede cargar nuevas versiones de la aplicación a su sitio. Obviamente, la seguridad del sitio es tan buena como la protección de esa funcionalidad.

• Seguridad del servidor. Si alguien puede piratear su servidor, puede violar la seguridad de su sitio y de sus clientes. Por lo tanto, debe bloquear el servidor, para que no esté ejecutando ningún otro servicio más allá de lo que se necesita para esta aplicación. Debe habilitar un servidor de seguridad para garantizar que nadie de la Internet pública pueda acceder a ningún servicio que no sea el servicio web, y posiblemente un servidor SSH bien protegido para el acceso administrativo. (Para SSH, recomiendo permitir solo el acceso de clave pública y deshabilitar la autenticación mediante contraseña).

• Seguridad del software. Deberá asegurarse de que no haya vulnerabilidades en su software personalizado. Esto significa que es importante que los desarrolladores estén capacitados en el desarrollo de software seguro. Es posible que también quieran usar herramientas de análisis estático u otro tipo de soporte para ayudar a detectar cualquier error de seguridad restante que pueda pasar.

• Actualizaciones. Debes asegurarte de mantener tu software actualizado con las últimas actualizaciones de seguridad y parches. Una forma de hacerlo es configurar Ubuntu para que actualice automáticamente su software, por ejemplo, verificando e instalando actualizaciones automáticamente una vez al día o una vez a la semana.

En términos generales, no es probable que obtenga una respuesta definitiva de que "está seguro", al igual que no hay garantía de que la próxima vez que cruce la calle no sea atropellado por un automóvil. En su lugar, los profesionales de seguridad identifican posibles riesgos / amenazas, evalúan las mitigaciones / defensas que ha implementado, evalúan si su sistema reduce el riesgo a un nivel aceptable e identifican algunos pasos posibles que podría tomar para reducir el riesgo si es así. elegir.

Además de la respuesta de @DW, debe tener en cuenta que un atacante puede aplicar ingeniería inversa a su ejecutable para ver cómo maneja la comunicación con su servidor. Si confía en que el ejecutable envíe instrucciones válidas, un atacante podría usar esto de manera malintencionada al crear instrucciones.

¿Seguro contra quién?

Si el atacante previsto es un tercero que puede espiar la red y posiblemente alterar los datos en tránsito, entonces su configuración es segura si (y solo si ) las conexiones entre su servidor y el La máquina del usuario está protegida con un protocolo apropiado, que es SSL / TLS (conocido como "HTTPS" en un contexto web ). Esto se aplica no solo a los canales entre la aplicación en la máquina del usuario y sus servidores, sino también a la distribución de la propia aplicación; de lo contrario, el villano podría alterar el código de la aplicación en tránsito, por ejemplo. para agregar algo de carga maliciosa que, cuando se ejecuta, registra todo lo que sucede en la máquina del usuario. Si hay HTTP simple en cualquier parte de tu configuración, has perdido. Con HTTPS, buscaría que sea factible (aún necesita hacerlo bien, y eso no es fácil, vea la respuesta de @DW).

Si el atacante previsto es el propio usuario , entonces estás condenado. No puede haber un código confiable que se ejecute en el propio sistema del atacante. Los editores de videojuegos han intentado hacer eso durante años y han fallado repetidamente; el éxito (limitado) se logró solo cuando el sistema del usuario está cerrado (es decir, no es una PC, sino una consola de juegos que se niega rotundamente, a un nivel de hardware íntimo, a ejecutar cualquier código que no haya sido debidamente autorizado a través de firmas digitales) ).