A partir de ahora, eso de Gambas Profesional, como que queda pretencioso, así que abriré los temas relativos al proyecto Intriga con ese título "Proyecto Intriga: bla bla bla"

He estado revisando el código y las BD y me surgen multitud de dudas. Así que he decidido empezar por la parte cliente (que es la que rellena las BD) y luego iremos a la parte de administración y del servidor.
Así os presento la primera línea de batalla: El colector de datos. (adjunto programa)

Este pequeño programa tal como está aquí, se ejecuta en cada login del usuario. Se coloca en el ~/.profile y ya está.

No recarga el tiempo de arranque porque se lanza en background. El resto de programas de la empresa lo primero que hacían al ser arrancados era comprobar si el .profile era el correcto y lanzaba este programa. Si no lo era, pudiera ser que el usuario lo hubiese borrado del .profile y/o desinstalado de la máquina, lo volvían a instalar y a modificar en el .profile sin decir nada al usuario, porque se consideraba que era imprescindible dentro de la arquitectura de la empresa.

Y aquí viene la primera duda: En una empresa propietaria de las máquinas, como era la mía, todo esto está muy bien pues "Herramienta de trabajo te doy, que no juguete" era la consigna a todos los trabajadores al incorporarse al sistema, pero puede no ser lo más apropiado si la máquina no pertenece a la empresa y el propietario no desea tanto control. Eso plantea distintas posibilidades:

En cuanto a los datos recogidos:

1) Sin cambiar lo que ahora se recoge o

2) limitando dichos datos a los relativos al hardware

En cuanto a la frecuencia:

a) La actual: en cada login. Lo que controla prácticamente todo el uso de la máquina.

b) En cada conexión a la vpn. Lo que permite que el usuario utilice su máquina sin conocimiento del sistema hasta que entre en él.

Hay otra posibilidad mucho más limitada... o no, opción a discutir, que es no enviar nada e ir almacenando todo esto en una base sqlite en el .config/nombre de la aplicación y sólo cargarla a las bases de datos cuando haya una incidencia o cuando el usuario lo solicite o cuando haya cambios significativos o yo qué sé....

Se abre el debate, oigan.

Saludos.

Archivos adjuntos

---

colector-0.1.tar.gz (Tamaño: 23.96 KB Descargas: 6)

Se abre el debate, oigan.

ok, le eco un vistazo y te digo algo
Saludos.

---

Bien, eche un vistazo
Hay cosas que, como dices, aplican a una empresa propietaria de la computadora que paga al trabajador por su tiempo así que es lógico que controle algunas cosas mas que lo básico.


Luego hay otras cuestiones para mas adelante pero creo que son importantes, como ser la separación entre datos recopilados, sentencias SQL, conexión a la base de datos etc.

Es decir el colector de datos seria algo así como el programa local de Ansible que hace recol¡pilacion de datos pero tambien mantiene actualizado el sistema, es decir hace el mantenimiento que le manda el jefe es decir Ansible.


Saludos.

Ignoro qué es Ansible. Seguro que hace todo esto y lo hace mucho mejor pero lo malo de hacer cosas es que no sueles tener tiempo para mirar a otro lado.
Volviendo al tema, cierto que habría que limitar la información... pero según el servicio que queramos dar al cliente. Vamos por puntos:


(Admin = Desarrollador/es de software / Administrador/es de la empresa
Usuario= Usuarios del software /  Empleados de la empresa, etc)
Pre-requisito importante: el Admin debe ser alcanzable por los usuarios en la Red. Bien por tener IP fija o un nombre de dominio propio o uno tipo DynDNS o lo que sea.

Existen tres escenarios posibles en cuanto al acceso con los usuarios:

A) El Admin está en una ubicación y los usuarios en otra/otras distintas sin VPN ni servidores por medio con IP variables.

     Este es el más limitado y engorroso de mantener por cuanto requiere configurar los router de cada uno de los usuarios abriendo los puertos necesarios (22 y 5900 por defecto) y haciendo NAT a la máquina del usuario, etc.

B) El Admin está en una ubicación y los usuarios en otra/otras distintas con servidores por medio, es decir IP fijas.

     En este escenario se creó el intriga y sólo es necesario configurar el router para tener acceso al servidor de la LAN de los usuarios. Tiene como inconveniente que habrá que establecer el mecanismo de tuneles ssh y demás para acceder a las máquinas individuales dentro de cada LAN, pero es posible y está (si no recuerdo mal) resuelto.

C) El Admin está en una ubicación y los usuarios en otra/otras distintas con una VPN que los une en un servidor.

    Esta es la manera más segura y sencilla de mantener que abarca y simplifica las anteriores. El único inconveniente es que necesita un servidor de VPN, que puede estar en una máquina de la empresa o de la nube. Siendo esto último lo preferido hoy día.

Habría que tener eso en cuenta porque, por ejemplo:

- La IP VPN: si no almacenas la ip VPN no podrás conectar con él para darle teleasistencia vía ssh o VNC. Es un dato necesario en el escenario C.

- La IP Privada: Sólo es necesaria en el escenario B, donde el desarrollador accede al ordenador del usuario a través de un enlace con el servidor de la LAN y desde éste a la máquina del usuario.

- La ip pública sólo es necesaria en un escenario tipo A donde no hay VPN  ni LAN y el acceso se hace directamente de la máquina del desarrollador a la máquina del usuario.

-El Idmaquina  Es un campos que identifican el ordenador. Se compone, creo recordar, del nombre del pc y los dos últimos dígitos de la ip privada, y era útil cuando hacías ssh a su máquina atravesando con un túnel ssh a su servidor local en los tiempos pre-VPN.  pero no es imprescindible.

-El npc no es negociable. Sin él no puedes llevar, por ejemplo, un historial de averías o incidencias, o avisos y alertas, etc. etc.

-El usuariopc no es significativo en escenarios tipo A, donde la máquina y el usuario son casi lo mismo. pero es muy interesante en escenarios tipo B, donde el ordenador está en una ubicación con otros usuarios que también tienen acceso al software y en el tipo C, donde una cosa es el usuario de la vpn y otra el de la máquina

Respecto a los datos físicos de la máquina... en principio sólo son atajos para saber datos concretos, ya que el último campo, que es la salida del comando <inxi -Fox> abarca casi todos ellos. Por velocidad y coherencia, tenía planeado en su día sustituir todo por las distintas opciones del comando inxi, que son muuuuuchas, pero me pilló la jubilación y veo que desde entonces no se ha tocado el código.

Hay un terreno más peliagudo que es el del software:
En escenarios tipo A, el usuario es dueño de su máquina y de sus datos, por lo que sólo nos interesa saber qué programas tiene instalados a efectos de compatibilidad y dependencias con nuestro software.

En escenarios donde la información pertenece a la empresa y no al usuario y las fugas de la misma pueden significar el desastre (desde las multas por la protección de datos hasta el espionaje y robo de clientelas, etc.), interesa mucho la existencia o no en las máquinas de software "sospechoso" o, directamente, "prohibido". Aplicaciones como Dropbox, whatsapp web, Mega, y el mismo correo electrónico son posibles vías de fuga de la información. Hoy día, una empresa normal, no puede asegurar nunca sus datos 100% dada las innumerables maneras de conexión que existen, pero  sí puede defenderse de aquellas que envían información a la nube de manera inintencional. Es decir: poco podemos hacer frente a la intención espúrea, pero sí podemos defendernos de la ignorancia.

Por ejemplo: en mi empresa se puso de moda hace unos años el DropBox y a los "ususaurios" les pareció una maravilla "¿Qué es eso de Dropbox?" preguntaban "Es como un pendrive pero en la nube, no hace falta llevarlo en el bolsillo". Cuando nos enteramos se nos pusieron los pelos de punta. Esos usuarios ignoraban en absoluto con quién estaban compartiendo qué carpetas de dropbox en qué ordenador, si el del trabajo, el de casa, el portátil, el teléfono, etc. etc. Dado que la empresa manejaba datos altamente confidenciales, era un riesgo enorme y se creó aquello del "software prohibido", que levantaba alertas en el correo de los Admin y que era desinstalado sin piedad.

Hay más cosas... pero vale de tocho-ladrillaco por hoy.

Saludos.

Siguiendo con el tema de la estructura del sistema Intriga:

No voy a contemplar, y esta decisión me va a costar mogollón de trabajo extra, otro escenario distinto al de el manejo de Intriga dentro de una VPN. Más arriba ya hablé un poco del tema, pero básicamente se reduce que una VPN tiene tan poco costo para el usuario y el administrador (llámaese empresa, desarrollador o "La parte contratante de la segunda parte") que no vale la pena el esfuerzo de la complejidad que hay que implementar en el programa para que responda a los distintos "Escenarios" que se detallaron en respuestas anteriores. Parte de la decisión la tomo en base al código que ya tengo (tenía, que ya no está en mis manos) implementado, en el cual la seguridad se convierte en una espina clavada en el culo del administrador.

Por ejemplo: Si tienes montada una VPN bien configurada (no como la del ejemplo que estamos usando. Una que tenga, por ejemplo, las BD en una máquina interna de la LAN que no tenga acceso directo desde la red y demás) ya no tienes que preocuparte de intrusiones, de suplantaciones "man in the middle", ni cosas por el estilo, lo que es un alivio inmenso en la estructura de la administración de la empresa. En la época pre-VPN, por ejemplo, manteníamos un usuario de BD por cada usuario del sistema, con sus perfiles de permisos que llegaban, a veces, a nivel de campo concreto de tablas concretas, etc. Con la VPN sabes que si alguien alcanza al servidor es porque se ha certificado de manera segura, es decir, es un usuario legítimo del sistema y puedes simplificar enormemente el asunto. Basta un usuario con todos los permisos posibles que puede tener un usuario (que no un administrador) y la limitación individual a los accesos y consultas se hace sobre el mismo software de Gambas, que es mucho más sencillos de mantener. Esta es al menos, sin ser ni pretenderlo un experto en seguridad, mi experiencia.

Queda el tema de la recolección de datos de las máquinas y de los usuarios. Ahora, con la estructura VPN podemos separar claramente los famosos tres escenarios basándonos en la conexión a la misma, a saber:

A) (Un usuario dueño de su máquina que utiliza software que no es nuestro o que, utilizándolo, no quiere ser monitorizado). Estableceríamos la conexión a la VPN sólo como una manera de comunicación con nosotros. Es decir: Si tiene problemas con su ordenador, se conecta y nos deja un aviso. Nosotros conectamos en remoto, lanzamos el recolector de datos y efectuamos el diagnóstico y solucionamos el problema (si los dioses quieren) en el momento. Si ejecutase algún software nuestro, para lo que necesita conectar a la VPN, no se recogería más dato que el propio del funcionamiento de ese software.

B) y C) (Máquinas pertenecientes a la empresa en una o varias LAN distintas) Pasan a ser ahora el mismo escenario y ahí se aplicaría la politica de "recolección dura" de datos que permite un mantenimiento óptimo de programas, máquinas y recursos compartidos.

Saludos.