Discussion :

[Cabos]

Bonjour à toutes et tous,

J'aurai une question, ne connaissant WinDev mobile que de nom, et encore...

Je développe en Access une application distribuée sur des tablettes pour nos commerciaux. Cette appli comprend une base frontale (les fonctions) et une dorsale (les bases en elles mêmes).

En l'absence de VPN SSL chez nous, cette dorsale est donc déployée pour chaque commercial, sur sa propre tablette.

Mon problème est le suivant : les bases sont exécutées en mode Runtime, et tant qu'il en est ainsi, pas de trifouillage du code sur la frontale, ni de modification (voire de piratage) des données sur la dorsale. Mais il suffit de modifier l'extension d'ACCDR en ACCDB pour pouvoir ouvrir tranquillement ces bases sous ACCESS et visualiser tous les objets.

Bien sûr on peut mettre un mot de passe, mais cela implique que quelque part, ce mot de passe est instruit, ce qui représentera toujours une faille de sécurité.

Est-ce que sous WinDev Mobile (je prends cette version parlant de tablette, en espérant ne pas me tromper de section) gère tout ceci plus facilement ?

Sans entrer dans les détails (n'ayant pas le produit, je n'y comprendrais pas grand chose !), vous qui en avez l'usage, est-il simple de dire : je veux que les utilisateurs utilisent (!), pas qu'ils puissent voir les coulisses de ce qu'ils utilisent...

Bien sûr, utilisateurs comme importuns mal intentionnés...

Merci de vos lumières.

[Cabos]

Bonjour,

Vue l'absence de réaction, j'en déduis que le sujet n'inspire pas grand monde. Question mal posée, ou peu d'utilisateurs de WinDev mobile ?

Je ferme le sujet, pour ne pas laisser de message en plan. Si quelqu'un tombe sur ce post et souhaite me faire part d'une expérience, réflexion à ce propos, il peut toujours le faire sur mon profil, en l'en remerciant par avance.

Note aux administrateurs : ceci n'est pas un up, simplement une clôture (je trouve cela plus correct...)

[laurent30s]

Bonjour

Je ne sais pas si ça répond à ta demande mais pour communiquer avec des appareils nomades nous utilisons des webservices.
- C'est sécurisé, il n'y pas d'accès direct au serveur
- Tu peux limiter l'info embarquée sur l'appareil nomade
- Si le volume d'info à communiquer reste raisonnable, c'est performmant
- ...

en espérant t'être utile...

[DelphiManiac]

D'après ce que j'ai compris, Cabos parle de l'accès que peut avoir une personne au source de son application.

Concernant Access, pour ne plus avoir accès au source de l'application, il faut convertir le accdb en accde (pas le renommer hein).

Par contre cette façon de faire implique toujours que la base dorsale soit accessible par un partage réseau, ce qui est toujours un problème de sécurité.

En windev, le développement d'une application génère sous windows un exe, donc un fichier non modifiable. Sous mobile, windev génère l'équivalent d'un exe pour la plateforme cible (un apk sous android).

Concernant la possibilité de modification des données de la dorsale, ceci est toujours possible si la base dorsale n'est pas protégé par un mot de passe. Il suffit d'avoir Access d'installer et d'ouvrir la dorsale, voir pire de copier le fichier et ainsi de "voler" toutes les données sensibles de l'entreprise.

Laurent30s indique qu'il utilise des webservices pour accèder aux données. C'est une possibilité parmi d'autres, mais quel que soit la méthode d'accès aux données, si celle ci ne sont pas protégées par un mot de passe, toute modification et consultation hors de l'application reste possible.

[Cabos]

Merci à tous les deux d'avoir réagi,

DelphiManiac, tu me parles de .accde, mais si je ne me trompe, ce format nécessite l'installation d'Access sur le poste pour fonctionner ? Là je parle de postes qui n'ont pas Access, et sur lesquels on implante une runtime.

Les bases runtime sont exécutées en .accdr, pour lesquelles il suffit malheureusement de changer l'extension en .accdb (manuellement !) afin d'accéder à tous les objets.

Cette "protection" n'en est donc pas une du tout, et je me demandais si WinDev répondait mieux à cette attente.

Ta réponse concernant la création d'un exécutable m'indique qu'effectivement, cela protégerait le code. Mais ce n'est pas ce que je cherche à cacher en priorité. Ce sont les données, qui, en l'absence de connexion au LAN de l'entreprise, doivent être locales.

Donc, si je suis bien ce que tu me dis : WinDev permet de créer une dorsale locale protégée par un mot de passe lui même fourni par un .exe non lisible. Et ça résiste bien ? Je veux dire, si quelqu'un de mal intentionné veut lire les bases, tenter de casser le mot de passe de la base, ou fouiller les tripes de l'exécutable, tu classerais la difficulté à quel niveau ?

1 - Mission impossible (bon, ça m'étonnerait quand même !...)

2 - Faut vraiment être un pro et y mettre les moyens

3 - Google est ton ami et en cherchant bien, tu trouves...

4 - Ma fille de 3 ans y arriverait (attention, elle est super maline...)

Laurent30s, il y a quelque chose que je ne comprends pas. Tu parles de webservices (progra en ....?) et tu me dis "pas d'accès direct au serveur". Comment cela ? Tu veux dire "pas de lien en dur sur le poste mobile indiquant à quelle adresse il récupère les infos" ? C'est cela ?

Merci encore de votre temps et de vos réflexions.

[nico78]

A l'époque, sur les anciens fichiers access .mde protégés par un mot de passe, il était possible de retouver celui-ci par un petit programme trouvé sur le web, (j'ai du le faire, car là où j'etais en prestation, il avait perdu le mot de passe, c'est un peu con)

Apres au niveau WinDev, tu peux au niveau de la base :
-mettre un mot de passe
-crypter la base

Tu peux en plus ajouter une protection supplémentaire qui est de crypter ( avec AES) les valeurs qui sont dans la base, donc, si on arrive a trouver le mot de passe, et ouvrir la base, les données sont elles mêmes cryptées, il faut casser le code (c'est ce que j'ai fait pour une de mes applis). La seul chose, c'est que cela complique énormément l'affichage de ces valeurs dans les composants WinDev (tableau, liste, etc) car elles sont cryptées

Il y a 1 chose qui joue en ta faveur, WinDev est pas tres connu, donc il y a peu de bidouilleur de base hyperfile, même s'il doit en exister qlq uns

Après, tout dépend de la valeur de tes données, si tes données valent 1M, qlq un peut toujours mettre une équipe de chinois ou de russes sur le coup

Tout cela pour dire que :
- tout peut etre piraté
- c'et uniquement une question de temps, et de moyen

Mais bon, c'est plus proche d'un pro que de ma fille de 3 ans ...

[courdi95]

Pour compléter l'information précédente, il est effectivement possible de crypter les fichiers hyperfile. Toutefois, si les tablettes sont sous Android, il faudra une version d'Android > 3.x, car l'accès natif HF n'est dispo chez Windev Mobile que pour un Android récent. Pour un Android plus ancien, le seul format de base est Sqlite.

Pour Windows Mobile, Windows Phone, etc, on n'a pas ce souci de version. Cela fonctionne. Et visiblement en IOS aussi :

http://doc.windev.com/fr-FR/?3044108...passe_fonction

Hpasse :
Fixe le mot de passe utilisé pour créer ou pour ouvrir un fichier de données. Le mot de passe est stocké et sera utilisé lors de l'ouverture ou de la création du fichier de données, si aucun mot de passe n'est spécifié.

Attention : Il est nécessaire de définir un mot de passe pour réaliser un cryptage des données. Le cryptage des données doit être configuré lors de la description du fichier de données dans l'éditeur d'analyses (Onglet "Détail").

Remarque : Ce mot de passe peut aussi être spécifié directement dans les fonctions de création (HCréation, HCréationSiInexistant) et d'ouverture du fichier de données (HOuvre).

Java Accès par JDBC : Cette fonction n'est pas disponible pour les bases de données accédées par JDBC.

Versions 17 et supérieures
WinDev Mobile iPhone/iPad Cette fonction est désormais disponible pour les applications iPhone/iPad.

Versions 18 et supérieures
WinDev Mobile Widget Android Cette fonction est désormais disponible en mode Widget Android.
WinDev WinDev Mobile Windows Store apps Cette fonction est désormais disponible en mode Windows Store apps.
WinDev Mobile Android Cette fonction est désormais disponible pour les applications Android (pour les fichiers de données HyperFileSQL).
WinDev Java Cette fonction est désormais disponible pour les applications Java.

[DelphiManiac]

...
Ta réponse concernant la création d'un exécutable m'indique qu'effectivement, cela protégerait le code. Mais ce n'est pas ce que je cherche à cacher en priorité. Ce sont les données, qui, en l'absence de connexion au LAN de l'entreprise, doivent être locales....

La protection des données est un vaste problème. Comme l'as dit un intervenant précédent, rien ne peut être réellement protégé, tout est une question de temps et de volonté.

Même si la base est protégé par mot de passe et crypté, il suffit de réaliser un programme qui pilote l'application qui accède à la base et qui affiche les données pour pouvoir ainsi lire les données qui sont affichées dans les formulaires et les stocker de nouveau.

Pour refaire rapidement une synthèse, je par du principe que les postes clients sont Windows, vu que tu utilises Access actuellement.

+ Il est possible de développer un exe (équivalent de la l'application frontale Access) qui accède à des données stockés sur un serveur.
+ Le déploiement de cet exe est globalement pus simple qu'avec Access et sa myriade de dll nécessaire (runtime). De plus, plus aucun problème d'incompatibilité entre le runtime d'access et un éventuel office déjà installé sur le poste en version différente.
+ Tu peux protéger la base par un accès avec mot de passe et la base peut être crypté. (la protection par mot de passe ne me semble pas être ni plus ni moins solide que celle d'Access, je ne parle pas ici de la protection simple par mot de passe, mais de la protection par "groupe de travail")
+ La mise en place de cette protection est plus simple que la mise en place du groupe de travail sous Access.
+ La sécurité n'est pas facilement cassable, mais avec la méthode indiqué plus haut et à partir du moment ou les données sont affichées sur un terminal, il n'y aucune protection fiable.

Cette liste correspond à des fonctionnalités disponible sous Windows, concernant Android et IOS, certaines limitations existe et Courdi95 en a déjà parlé.

Par contre tu parles de fonctionnement en mode déconnecté. Utilises tu actuellement la réplication des bases de données lorsque l'utilisateur n'a pas accès au réseau ?
- Si oui, gère tu la réplication toi même ou utilises tu les fonctionnalités d'Access.
- D'autre part, toujours si oui, la protection des données devient vraiment problématique. Si un gars part avec la le PC et la base de données répliqués, tu vas avoir beaucoup de mal pour empêcher le "vol" de ces données.

Essaye de nous en dire un peu plus sur le niveau de protection que tu veux obtenir.

[Cabos]

Bonjour Messieurs,

Bon, en fait, je n'en suis pas à intéresser les Russes, même s'ils ont franchement tort, étant donné que si ça se trouve, ça pourrait être important... Bon, ça l'est pas, mais ils peuvent pas savoir...

Plus sérieusement :

- Je travaille sous VBA Access parce que l'entreprise est équipée Windows, que les premières applis développées en interne ont été à destination de l'entreprise, et que Excel, c'est bien, mais quand il s'agit de gérer un entrepôt de +5000 références, tu en arrives vite fait à trouver plus utile un système de gestion de base de données, avec formulaires et tout et tout, le tout un peu prémâché (même s'il faut se faire à la logique Access...)

- Dernièrement, l'entreprise, qui reste une PME, se décide à mettre en œuvre un embryon d'outil d'aide à la vente pour ses commerciaux, toujours sur la base d'un développement interne. Donc : Access

- Dans cet outil, se pose rapidement la question de savoir si on doit inclure les prix des marchandises ou non. Le débat tourne alors sur la sécurisation des données. Les commerciaux n'ayant aucun lien direct avec notre LAN (pas de réplication des données : il s'agit de fichiers Excel qu'ils importent par lien FTP, et intègrent directement à la base "dorsale" (qui ne l'est donc que de nom)), les infos se trouvent forcément sur leur poste de travail.

Actuellement, nous avons décidé de ne pas donner les informations valorisées. Mais je réfléchis à l'acquisition d'un autre outil de programmation, à destination de nos équipements mobiles. D'où ma question sur la sécurité de WinDev.

Vous m'avez apporté de nombreux éléments de réponse, et je vous en remercie. J'en retiens que si aucune système n'est imparable (je vous rassure, j'en étais déjà bien convaincu), les protections apportées par WinDev sont quand même plus massives que celles offertes par Access (à moins d'être un pro du produit, et je sais qu'il y en a sur ce site...).

On est donc bien plus dans le domaine du "craquable par des pros équipés et motivés", que dans le simple domaine de "Google est ton ami, et le premier noob de 15 ans venu fait voler en éclat ta protection ridicule, te faisant passer pour un con, alors que t'as 3 fois son âge, et que s'il était en face de toi, il moufterait pas...".

Merci de votre temps, et très bonne continuation à tous.

[laurent30s]

Laurent30s, il y a quelque chose que je ne comprends pas. Tu parles de webservices (progra en ....?) et tu me dis "pas d'accès direct au serveur". Comment cela ? Tu veux dire "pas de lien en dur sur le poste mobile indiquant à quelle adresse il récupère les infos" ? C'est cela ?

En fait je voulais dire pas d'accès direct à la base de donnée sur le serveur.

Le concept de web-service veut simplement dire qu'un serveur propose des fonctions (des "services") qu'on peut invoquer à distance à travers le web afin de déclencher un traitement sur le serveur distant et/ou obtenir une information de ce serveur.
Ces appels de procédures à distance se font comme des appels de page web, c'est à dire sur le protocole HTTP. Je demande un service, je reçois une réponse. L'avantage de passer par HTTP est de ne pas nécessiter l'ouverture de ports spécifiques sur les firewalls.
Les webservices utilises des XML pour décrire les appels de fonctions distantes et les données échangées.

Dans l'aide de windev les webservices sont définis ainsi http://doc.pcsoft.fr/fr-FR/?3086002
"Un Webservice est constitué d'un ensemble de fonctions SANS interface. En effet, étant donné que ce type de module s'exécute sur un serveur, il n'y a aucune interface utilisateur à réaliser. Le webservice sera donc constitué de fonctions en WLangage organisées dans des collections de procédures. Ces fonctions peuvent manipuler une base de données."

Concrètement :
- Tu fais 1 projet de type webservice qui va accueillir tous les services
- Tu va programmer des traitements dans des procédure globales. Aucune fenêtre ne peut être ouverte, ce ne sont que des traitements.
en principe il a 3 étapes :
1- on parse le xml reçu lors de la demande de service
2- on effectue le traitement
3- on construit le xml de la réponse
- Au moment de la compilation, la liste des procédure est présentée, il suffit de cocher celles qui peuvent être appeler à distance pour définir les services mis à dispositions.

Côté utilisateur distant la consommation d'un service passe par
- la construction d'un xml avec des données pour personnaliser la demande de traitement
- l'appel d'une URL en passant un login/mot de passe et le xml de la demande
- la lecture du xml de la réponse pour récupérer les données

Pour en revenir à la connexion, l'utilisateur distant n'a pas d'accès direct à la base de donnée, il a un accès à des webservices qui sont sur le serveur. Ce sont les webservices qui accèdes à la base de donnée.

Donc les appareils nomades ne contiennent pas d'information pour accéder à la base de donnée.
Par contre ils contiennent des informations qui permettent d'accéder aux webservices mais :
- les actions de malveillance sont limitées aux actions faites par les webservices (donc pas de possibilité d'importer massivement des données ou de détruire des fichiers)
- si les appareils sont identifiés et qu'à chaque appel de service on communique l'identifiant de l'appareil appelant, avant de faire le traitement on peut s'assurer que l'appareil est toujours autorisé à appeler le service. On limite le risque dans le temps : entre le moment où l'appareil est dérobé et le moment ou on désactive l'appareil
Je pense qu'en utilisant des webservices on réduit fortement les possibilités de malveillance sur les données du serveur à partir des éléments qui sont sur les appareils nomades.

Un autre problème est la confidentialité des données sauvegardées sur les appareils nomades.
Je rejoint les conseils de mettre un login/mot de passe pour l'accès aux fichiers
Surtout ne met pas le mot de passe dans un fichier texte pour paramètre la connexion. Met le en dur dans l'appli.
Tu peux réfléchir à limiter les données embarquées, seulement celles qui sont indispensables, non sensibles...

Tu évoques la crainte de laisser des tarifs sur les appareils nomades.
Si tes commerciaux n'évolue que sur des zones ou le réseau passe bien.
- Tu peux embarquer sur l'appareil la liste des articles sans tarif
- Tu fais un webservice qui renvoi les tarifs d'une liste d'article à la demande

Imagine le scénario :
Ton commercial est avec un client, il rempli une liste d'articles qui peut intéresser le client, il appui sur un bouton qui appelle le webservice et le liste se complète avec les tarifs du serveur.
Il fait un devis, pareil, il rempli une liste d'article, il appui sur un bouton qui appelle le webservice et le devis se complète avec les tarifs du serveur.
Les tarifs ne sont qu'en table mémoire, ils ne sont pas enregistrés sur l'appareil.
Le commercial valide le devis en cliquant sur un bouton qui appelle un webservice pour l'enregistre des devis sur le serveur auquel est envoyé les données de la table mémoire.
etc...

C'est un exemple de réflexion qui peut être mené.
Maintenant je pense qu'en matière sécurité il faut être sérieux, ne pas faire n'importe quoi, limiter les risques. Mais il faut répondre de manière proportionnée aux risques par rapport à la probabilité de survenance et la dangerosité...

Comme disait Chirac : "il faut raison garder"

[Cabos]

Un grand merci pour cette longue réponse détaillée. Elle confirme de façon très claire les propos tenus précédemment, et illustre une réponse qui me parait tout à fait adaptée.

Vraiment, c'est exactement le genre d'argumentaire que je cherchais pour ma direction.

Encore une fois, un grand merci, et bonne continuation à toi.