Lorsque qu’une application est cantonnée à être utilisée par un ensemble de machines sagement localisées dans un intranet et toutes contrôlées par un domaine unique sous la supervision d’un Antivirus d’entreprise, la sécurité de l’application ne concerne que son contenu et reste sous sa propre responsabilité.
Mais dès lors que l’on une application offre des accès extérieurs, que ce soit la simple légitimité du client, comme la confiance que l’on peut lui accorder, ou bien encore la sécurisation des échanges et la protection des identifiants, et évidemment la capacité de résistance de l’application à une agression directe, tout se complique.
Prenons donc les éléments point par point :
Les équipements acceptés
Je ne relancerai pas une fois de plus le débat BYOD / CYOD / COPE etc. L’équipement à gérer est celui qui se présente, le débat n’est plus là. Il faut s’adapter !
On doit donc considérer que le système doit accepter des systèmes divers, des tailles diverses, probablement des langues diverses et surtout des puissances et des débits divers. Mais nous aurons l’occasion d’y revenir aux chapitres fonctionnels et ergonomie
La légitimité du client
On entend par là, la volonté de contrôler qui se connecte à notre application, nous ne sommes plus dans un réseau fermé donc par définition n’importe qui peut tenter d’utiliser votre service, de votre PDG à un hacker nord-coréen ou un simple concurrent, il est nécessaire d’arbitrer qui passe ou ne passe pas.
On peut diffuser et exiger un certificat client, mais cela va limiter le potentiel d’utilisation puisque qu’il faudra activer chaque équipement, on peut aussi imposer des VPN pour reconstituer un pseudo réseau d’entreprise, mais outre la complexité apportée, le but n’est pas forcément de prédire à priori qui va tenter d’utiliser l’application mais surtout d’en maîtriser l’usage.
Ce qui est important est donc :
La confiance dans le client
Même si l’accès est sécurisé, rien n’empêche l’équipement d’être corrompu et de rediffuser des données souvent d’ailleurs à l’insu de l’utilisateur. On doit donc s’assurer qu’il respecte un minimum de règles de sécurité (antivirus, système sans backdoor – suivez mon regard tourné vers l’est lointain). On ne peut pas, par contre garantir une innocuité totale, il faut maximiser autant la sécurité des échanges et que limiter la saisie de données sensibles telles que l’identifiant et le mot de passe.
La sécurité de l’échange
Une fois que le client est considéré comme fiable, il faut s’assurer que ses échanges sont sécurisés, autant cela se gère simplement au niveau des données en utilisant SSL qui garantit le chiffrement des données sur tout le transfert, autant c’est un peu plus complexe pour la saisie et notamment la partie connexion des utilisateurs.
Identifier l’utilisateur
L’idée est d’éviter que des identifiants soient saisis et éventuellement stockés directement sur les équipements mobiles, pour cela la bonne idée est de mettre en œuvre des mécaniques SSO similaires à celles qui existent entre machines et domaines locaux. Suivant vos possibilités, vous pourrez utiliser Google, Azure, LinkedIn ou France Connect, ou bien mettre en place un portail ADFS si vous avez de nombreuses applications.
Protéger son application
Le dernier point est de protéger l’application contre des attaques directes, que ce soit du déni de service ou des tentatives d’accès, la réponse est dans la combinaison d’un firewall et d’une application suffisamment testée.
Et bien sûr cela va sans dire, investir dans l’éducation des utilisateurs et des administrateurs pour la gestion des mots de passe pour les premiers et celle des comptes actifs pour les seconds
Enfin normalement, tout est maintenant en place pour ouvrir votre première application à des clients. Il ne reste plus qu’à définir ses fonctionnalités spécifiques et surement revoir quelques points d’ergonomie, mais nous verrons cela dans une prochaine chronique.
Olivier Piochaud, PDG d’Apsynet
