GoldenCrystal (./5) :
En tout cas, oui, si tu dois héberger et accéder à une base de données tu ferais mieux de ne pas l'exposer à l'air libre sur internet. (C'est pas une question Android du tout en réalité, mais une question d'architecture ^^)

Et la page web, elle n'est pas exposée à l'"air libre"? À mon avis, c'est juste une surcouche de plus qui pourrait être attaquée (à condition que la structure de la BDD soit adaptée à l'accès direct, je vais y venir!).

Il est conseillé de créer une "page web", en général dans l'ère moderne plutôt sous la forme d'une API REST, pour des raisons de sécurité, mais aussi pour des raisons de simplicité. (Ton API peut être utilisée par n'importe quelle autre application autorisée)
Côté sécurité, si tu exposes ta base de données directement sur internet:

• Tu vas également exposer publiquement le compte et le mot de passe que tu utilises pour t'y connecter. (On le trouvera dans le code de ton application)

Donc tu proposes de remplacer un compte et mot de passe pour une BDD par un compte et mot de passe pour une application web? On y a gagné quoi? Et en plus, maintenant, c'est à ton application de réinventer l'authentification alors que la BDD serait déjà capable de le faire pour toi.

• Selon les droits du compte, c'est un peu open-bar avec ta base, et celui qui s'y connectera y fera ce qu'il voudra avec les droits qu'il aura.
• Même si tu utilises un compte "limité" pour accéder à ta base, à part avec un compte en lecture seule, on pourra toujours faire des trucs que tu ne voudrais pas qu'on fasse (au minimum modifier tes données sans ton consentement)

Le cas qu'il décrit, c'est que la BDD est remote pour des raisons de place, pas pour échanger des données entre utilisateurs. Donc tu crées une BDD totalement séparée pour chaque utilisateur et tu ne donnes accès à ce compte qu'à cette BDD. (En principe, tu peux même lui donner ALL PRIVILEGES sur cette BDD, c'est sa BDD, il en fait ce qu'il veut.)

Si on a besoin d'une BDD partagée, alors là oui, il faut un wrapper qui limite l'accès, mais ce wrapper peut aussi être une vue (ou un ensemble de vues) SQL, plus éventuellement des tables privées par utilisateur. Les BDD permettent de donner les permissions de manière assez fine si l'application est conçue convenablement. Mais bien sûr, si tu veux faire un SELECT * FROM all_users where user = "toto@example.com"; depuis l'application client, ça ne va pas aller du tout, on est bien d'accord là!

• Quand bien même, il y aura toujours la possibilité que quelqu'un ne découvre ton mot de passe administrateur et s'y connecte. Et là, il pourra foutre le boxon dans ta base comme bon lui semblera.

Si ton compte administrateur MariaDB est root@localhost, il a beau avoir le mot de passe, il ne pourra pas se connecter depuis une machine extérieure. Le compte admin peut être restreint à localhost même quand tous les autres comptes sont ouverts au monde. Et puis faut pas utiliser des mots de passe trop simples pour les comptes admin. Ça vaut aussi pour le compte root du système d'exploitation, le compte admin de la webapp s'il y en a un, etc.

• Sincèrement, "personne" ne fait ça. (Non, j'ai pas été vérifier partout, mais vraiment…) C'est une incitation au crime. Particulièrement chez les développeurs, si on peut analyser la composition d'une application on hésitera pas.

Là encore, ça dépend de comment est structurée la BDD et quelles requêtes sont envoyées. Une fois de plus: Je suis entièrement d'accord qu'une API qui permet d'accéder aux données privées des autres utilisateurs est totalement inacceptable, quel que soit le niveau d'obfuscation par dessus. S'il suffit de modifier l'application client pour avoir des accès qu'on ne devrait pas avoir, la sécurité est totalement foireuse, même si c'est une application closed-source! Donc soit on a une BDD (ou un ensemble de tables, ou un schéma dans les BDDs comme PostgreSQL qui ont ce niveau de subdivision supplémentaire) par utilisateur, soit on travaille avec des vues.

Voir quelqu'un se connecter à une base de données à travers internet, ça titille vraiment. En plus, il y aura forcément un mot de passe visible en clair quelque part.

MariaDB et PostgreSQL permettent de te connecter en TLS (le protocole qui a remplacé SSL, souvent appelé incorrectement "SSL" par habitude), avec vérification du certificat. Donc non seulement aucun mot de passe n'est visible en clair, mais en plus un attaquant ne voit même pas que c'est un accès à une BDD (sauf éventuellement à travers le numéro de port si on utilise le port par défaut).

• Tu peux probablement compter sur le fait que les protocoles de base de données ne soient pas sécurisés (certains le sont, c'est pas obligatoire, et chez ceux qui le font, c'est peut-être payant)

MariaDB ne coûte pas un sou, et si tu utilises les connecteurs du projet MariaDB plutôt que ceux du projet MySQL (donc MariaDB Connector/C, MariaDB Connector/J et/ou MariaDB Connector/ODBC), les bibliothèques client sont sous LGPL, donc utilisables gratuitement dans n'importe quelle application. Et TLS fait partie des fonctionnalités de base.

PostgreSQL est aussi entièrement gratuit (sous une licence style BSD) et propose aussi le TLS.

En dehors de l'aspect sécurité, tu peux pratiquement être certains que les protocoles d'accès aux bases de données ne sont pas optimisés pour la latence d'internet.

Ça oui, mais on s'en sort quand-même, et wrapper les accès sous encore une surcouche ne va pas les accélérer.

De fait, ce que "tu dois" faire (tu es libre, mais c'est vivement conseillé), c'est effectivement te créer une petite interface HTTP accessible sur le web. (Là tu peux te documenter un peu sur les API RESTful / JSON de manière plus générale que l'exemple succint donné dans ton lien. Mais j'ai conscience que ça va faire un peu lourd )L'idée c'est que le code que tu va héberger sur le serveur web ne sera accessible qu'à toi (puisque tu es le seul à pouvoir modifier son contenu), et même s'il contient les mots de passe d'accès à la base (si possible pas le mot de passe admin, quand même), personne ne pourra les voir.

Mais comme tu le dis après, il devra quand-même introduire des comptes et mots de passe pour les utilisateurs de l'application, sinon il n'y a aucune sécurité. Où est la différence?

Maintenant, on peut faire plus sécurisé… C'est de bon goût de ne pas laisser n'importe qui utiliser à ta petite API/base de données… Et si tu peux, c'est bien d'avoir un genre de gestion d'utilisateurs (encore via API du coup ) qui te permettre au niveau de ton API d'autoriser ou de refuser les requêtes. C'est même plutôt obligatoire si tu comptes aussi accéder à ta base en écriture.

C'est clair! Et du coup tu as réinventé l'authentification de ta BDD.

Bref, je résume: Une surcouche est nécessaire si et seulement si la structure de la BDD est telle qu'on ne peut pas permettre, à travers les contrôles d'accès natifs de la BDD, l'accès aux données de l'utilisateur sans permettre aussi l'accès aux données d'autres utilisateurs. Et si c'est le cas, les vues peuvent éventuellement contourner ce problème nativement dans la BDD, mais font évidemment que l'application doit être conçue pour (SELECT * FROM user31337_view; plutôt que SELECT * FROM everything WHERE user_id=31337;, parce que le compte user31337 ne doit avoir accès qu'à user31337_view et en aucun cas à la vraie table everything!). Une surcouche simple ne fait que réinventer les vues. Mais je concède que si le développeur est incapable de garantir la sécurité avec les mécanismes natifs de la BDD (que ce soit la faute de l'utilisation prévue, du développeur ou de la BDD, peu importe!), il vaut mieux faire une surcouche qui garantit la sécurité que proposer une API (accès direct à la BDD avec des permissions trop larges) facilement hackable à des fins malicieux!