> Si tu imposes une bonne politique dans la définition des mots de passes a tes utilisateurs,
> que tu sait configurer et maintenir un apache SSL et
> sécuriser un serveur connecté au net
Ca fait beaucoup de "si" tout ça. Au final on est donc plutôt d'accord.
Et personnellement les 3 trucs qui me gènent sont :
1) les mots de passe bidons choisis par les utilisateurs
2) le serveur web avec la base de données en frontal sur le web : entre Apache, SSL, PHP et le serveur SQL ça en fait tout un tas de trucs à suivre et à mettre à jour en permanence, surtout quand on connaît l'historique de ces logiciels (PHP par exemple a un lourd passé de failles diverses)
3) l'application elle-même (OBM commence à avoir une taille conséquente en terme de lignes de code - il y a surement des trous de sécurité dedans)
Si un seul de ces trois trucs foire (et sécuriser ces 3 axes est _très_ lourd à gérer sur le long terme), alors le système d'information de l'entreprise est accessible. Bref on a une probabilité (que quelqu'un accède de façon malveillante aux informations du serveur) élevée, associée à un impact important (accès aux informations confidentielles de l'entreprise) ce qui en fait un risque majeur. D'où mes réticences à mettre une telle architecture avec des infos confidentielles sur un serveur public (même "sécurisé") sous prétexte de faciliter les accès distants.
Sinon le "ha ha ha" c'est une référence aux personnes qui mettent SSL + authentification L/P et qui sont persuadés d'être hyper sécurisés, alors que les cohortes d'utilisateurs ont pour mot de passe "toto" ou "azerty" ou, pire ont enregistré le L/P dans les préférences du navigateur.
[^] # Re: OBM : Application de gestion de contact / entreprise en GPL
Posté par Amaury . En réponse à la dépêche OBM : Application de gestion de contact / entreprise en GPL. Évalué à 3.
> que tu sait configurer et maintenir un apache SSL et
> sécuriser un serveur connecté au net
Ca fait beaucoup de "si" tout ça. Au final on est donc plutôt d'accord.
Et personnellement les 3 trucs qui me gènent sont :
1) les mots de passe bidons choisis par les utilisateurs
2) le serveur web avec la base de données en frontal sur le web : entre Apache, SSL, PHP et le serveur SQL ça en fait tout un tas de trucs à suivre et à mettre à jour en permanence, surtout quand on connaît l'historique de ces logiciels (PHP par exemple a un lourd passé de failles diverses)
3) l'application elle-même (OBM commence à avoir une taille conséquente en terme de lignes de code - il y a surement des trous de sécurité dedans)
Si un seul de ces trois trucs foire (et sécuriser ces 3 axes est _très_ lourd à gérer sur le long terme), alors le système d'information de l'entreprise est accessible. Bref on a une probabilité (que quelqu'un accède de façon malveillante aux informations du serveur) élevée, associée à un impact important (accès aux informations confidentielles de l'entreprise) ce qui en fait un risque majeur. D'où mes réticences à mettre une telle architecture avec des infos confidentielles sur un serveur public (même "sécurisé") sous prétexte de faciliter les accès distants.
Sinon le "ha ha ha" c'est une référence aux personnes qui mettent SSL + authentification L/P et qui sont persuadés d'être hyper sécurisés, alors que les cohortes d'utilisateurs ont pour mot de passe "toto" ou "azerty" ou, pire ont enregistré le L/P dans les préférences du navigateur.