Quel que soit le niveau auquel vous développez, la sécurité est une partie intégrante du travail. Ni l'abstraction ni le processus de développement moderne semble capable de protéger les développeurs des obstacles soulevés par la sécurité. Il est assez difficile de ne pas detester la sécurité quand il ne semble pas ajouter de la valeur intrinsèque, et souvent est dans la manière de fournir une expérience utilisateur agréable. Pour couronner le tout les produits peuvent se pirater de toute façon, en dépit de toute travail que vous faites pour rendre vos produits sécurisés.
Rendre la sécurité transparente
La théorie derrière un grand nombre de mécanismes de sécurité d'aujourd'hui consiste à faire de la sécurité transparente. Sandboxing, conteneurs, et d'autres mécanismes de sécurité modernes créent une couche d'abstraction qui protège tout le monde à partir des détails de la politique de sécurité. Bien que cela permet d'atteindre les objectifs déclarés de l'isolement du programme, il rend le partage légitime des informations beaucoup plus complexe. Commande du partage au niveau de granularité est la partie la plus difficile de la sécurité, ce qui est l'endroit où nos problèmes se posent.
En dépit de ces efforts en vue de la transparence, trop souvent les développeurs trouvent que les exigences de sécurité les ont peint dans un coin avec pas de solution facile. Heureusement, il existe des moyens pour les développeurs à réfléchir et à l'approche de la sécurité afin que la sécurité ne détruit pas leurs produits, l'expérience de l'utilisateur, ou le calendrier.
La plus grande erreur une équipe de développement peut faire est le traitement de la sécurité différemment de la façon dont ils traitent leurs autres exigences. Tout comme une équipe de produit qui prévoit d'accorder à des problèmes de performance après tout le code se fait inévitablement créer un logiciel plein de problèmes de performance, une équipe de produit qui attend pour mettre un système de sécurité juste avant la libération va avoir un tas de la technologie qui ne fonctionne plus. Pour éviter ce sort, les équipes de développement doivent considérer la sécurité comme une partie intégrante de la spécification, la conception et la mise en œuvre du logiciel, et devraient inclure la sécurité le plus tôt possible dans le processus de développement.
Quelle approche adopter ?
Les développeurs ont quelques options de base lorsqu'ils traitent avec la sécurité. Vous pouvez prendre l'approche traditionnelle cathartique et continuer à le detester et blâmer pour tout ce que l'impact qu'elle a sur ce que vous essayez d'accomplir. Vous pouvez également prendre l'approche populaire d'ignorer la sécurité, ce qui est étonnamment rentable. Ou vous pouvez mettre la sécurité en tant que votre première priorité, mais cela est rarement une stratégie gagnante en raison de ses coûts élevés et de l'impact sur l'expérience utilisateur et les performances.
Mais la meilleure façon de passer à travers le processus de sécurité est d'inclure la sécurité tôt dans le cahier des charges, la conception et la mise en œuvre ainsi que d'autres exigences de base. Bien que cela puisse sembler gênant, et dans certains cas peut nécessiter un certain recyclage (en particulier des développeurs de sécurité, qui pourraient ne pas savoir ce qui les frappe), il est le meilleur moyen de développer un logiciel qui a une sécurité efficace sans créer d'obstacles inutiles au processus de développement .
Commentaires