Principes de sécurité applicative (APP) dans un contexte d’extension d’une solution CRM ou ERP

La sécurité en informatique est une nécessité. Nul ne peut nier cette affirmation. Toutefois, se lancer dans le développement d’une application (APP) dans un contexte d’extension d’une solution CRM ou ERP, peut amener une entreprise à sortir de sa zone de confort à plusieurs égards. Ce billet présente quelques principes permettant justement d’éviter que la sécurité fasse partie d’une zone d’inconfort.

Tout d’abord, se protéger

Le premier réflexe de tout inventeur ou concepteur d’une application (APP) est de vouloir protéger le fruit de son travail, ainsi que les données qui y sont associées. Techniquement, il suffit de signer son application afin de s’assurer de son intégrité, affichant ainsi que nous en sommes les concepteurs – cela nous protège contre l’usurpation de la propriété intellectuelle de notre application. L’autre protection qui apparait évidente, et qui est quasi universelle, est le recours à une clé d’encryptage pour circonscrire l’application dans un environnement où l’on contrôle les droits d’utilisation de l’application en question.

Ceci dit, les considérations de sécurité vont bien au-delà de ces 2 prémisses largement connues que nous venons d’introduire.

Assurer la confidentialité du client utilisateur

Une application (APP) récolte très fréquemment un certain nombre de données appartenant à l’utilisateur. L’éthique avec laquelle nous les recueillons est très importante. Il faut les sélectionner judicieusement et être extrêmement rigoureux dans la stratégie de sécurité que l’on utilisera pour la conservation de cette information. La sauvegarder dans un endroit relativement sécuritaire – généralement chez le fournisseur – dans une zone protégée, non accessible à tout le monde. Une architecture sécuritaire sera également utilisée, c’est-à-dire le transport de l’information cryptée, afin d’éviter l’interception des communications et les modifications possibles des données. La consultation de l’information appartenant au client sera faite de façon très restreinte, filtrée et sécurisée.

À quel niveau doit-on assurer l’habilitation ?

Par la suite, une décision doit être prise quant au niveau de l’habilitation ou de l’authentification en vue de l’utilisation de l’application (APP) du côté client. Deux options sont envisageables.

1. Nous pouvons prendre la décision que la sécurité appliquée à l’APP soit celle de son parent. Par exemple, que le périphérique utilisé reposera sur la sécurité de verrouillage du périphérique d’accès. Il s’agit là de la décision qui permet la productivité la plus élevée et la plus simple car il n’y a pas de gestion d’authentification à l’APP. Un peu comme la sécurité du service de courriels Outlook relève de son parent, le système d’exploitation Windows.
2. La seconde option consiste à lui appliquer sa propre gestion d’authentification, ou gestion de l’habilitation. Par exemple, on peut saisir un identifiant « mot de passe » ou une authentification multi-facteurs, mais on y perd en productivité. Par contre, si le système contient de l’information hautement sensible, on préfère surement éviter d’exposer une porte d’accès qui pourrait être compromise par un périphérique n’ayant pas de code de verrouillage, comme un téléphone. Dans un tel cas, nous intégrerons l’authentification à notre APP, qui fera en sorte qu’elle puisse mémoriser – ou pas – le mot de passe. Par exemple, les applications bancaires interdisent la mémorisation de mot de passe.

En conclusion, retenez que ces principes de sécurité pourtant simples requièrent une rigueur dans leur implantation au sein de votre équipe de développement. Ne sous-estimez pas cette mise en garde car il n’est pas rare de voir des failles dans les processus de développement des organisations de toutes tailles.

La sécurité est pour toujours !