Référence à
https://ecirtam.net/zerobin/?ad486cba82d88c92#Ywjj2BuEXepQn2+L/I0/GRBooCckMB7IAYTBupENyPE=
«est-ce qu'il y a une représentation structurelle de la "sécurité" et de l'aspect "fonctionnel" d'un programme préférable à une autre ?»
Réponse personnelle : Il n'y a pas de représentation meilleur d'une autre dans tout les cas.
La sécurité, ça coûte beaucoup de temps et donc de l'argent.
Du coup, il faut faire des choix en fonction de :
- ses moyens
- son but
- la sensibilité des infos traitées
- l'importance de l'appli
Exemples de choix :
- https ou http ?
- contrôle des données en entrées ou pas ?
- compte unique ou pas ?
- id visible dans l'URL ou pas ?
- mise à jour du site automatique ou manuel ?
- ftp ou sftp ou ssh/scp ?
- tests unitaires ou pas ?
- load balancer ou pas ?
- disques en raid ou pas ? Et quel type de raid
- quel OS pour le serveur ?
- mise à jour automatique ou pas ?
- backup ou pas ?
- analyse des logs ou pas ?
- double alimentation sur le serveur ou pas ?
De mon expérience, faire un prototype d'une appli sans prendre en compte la sécurité, puis vouloir la transformer pour la passer en prod est vraiment compliqué et prend du temps.
Plus la prise en compte de la sécurité de se fera tôt (dès le cahier des charges), moins ça sera galère à sécuriser.
Par exemple, si ton modèle de données en base n'a pas été bien pensé pour la sécurité, t'as plus qu'à tout péter :-/
Pour les bonnes pratiques :
https://www.owasp.org/index.php/Main_Page
https://github.com/OWASP/Top10/
https://www.ssi.gouv.fr/entreprise/bonnes-pratiques/
https://fr.wikipedia.org/wiki/ISO/CEI_27000
—
Permalink