Faculté Universitaire Notre Dame de la Paix de Namur Sécurité des SI : Matière Avancée - Réflexion méthodologique - Juin 2012 Groupe 5 LEDOUX Denis MAES Jerome SIMON Martin Cours : INFO-M474 Professeur : J-N Colin Assistant : S. Dynerowicz
Table des matières Table des matières 1 1 Introduction 2 2 Rappel des règles en matière de traitement de données à caractère personnel 3 3 Rappel des étapes du SDLC 4 3.1 Le cycle en cascade................................ 4 3.2 Le cycle en V................................... 4 3.3 Le cycle en W................................... 5 3.4 Le cycle en Spirale................................ 5 4 Proposition de prise en compte des règles dans les étapes du SDLC 6 4.1 Analyse des besoins................................ 6 4.2 Conception.................................... 7 4.3 Implémentation.................................. 7 4.4 Tests........................................ 8 4.5 Maintenance.................................... 8 5 Proposition organisationnelle : acteurs, rôles, responsabilités 9 6 Conclusion 10 1
1 Introduction Le but de ce travail est de présenter une façon d intégrer les mesures de sécurité au fil du développement d un logiciel. Le logiciel à développer serait un portail Web, avec des données sensibles. Nous allons donc commencer par décrire les mesures les plus importantes à intégrer concernant ce genre de logiciel. Puis, nous rappellerons les différents cycles de développement possibles, en développement les diverses étapes de ceux-ci. Ensuite, nous expliquerons les propositions de sécurité à intégrer dans le développement et quand les intégrer. Nous terminerons par des propositions organisationnelles impactant la sécurité de l application. Le contexte choisi pour ce travail est donc le développement d un portail web. ce contexte implique des mesures particulières vis-à-vis des données à caractères personnels. Le système étant exposé sur internet, le respect de ses règles est donc primordial. 2
2 Rappel des règles en matière de traitement de données à caractère personnel Dans le cadre de données sensible, jugées à caractères personnels, nous avons identifié que les principes de protection suivants étaient particulièrement importants : 1. Confidentialité ; il s agit du fait de s assurer que l information n est seulement accessible qu à ceux dont l accès est autorisé. en effet, sur un portail web, il n est pas rare que les utilisateurs y possèdent des informations que seul le système ou un groupe d utilisateurs peut consulter, éditer,... 2. Intégrité : le fait que les données qui ont été envoyées, reçues ou stockées sont complètes et n ont pas été modifiées. En effet, lorsqu un utilisateur soumet des informations, ces dernières doivent restées intactes, surtout dans le cas ou elles sont partagées. 3. Authentification : Il s agit de vérifier l identité d une entité (personne, ordinateur,...) afin, le cas échéant, de l autoriser à accéder à certaines données. 4. Contrôle d accès : Regroupe les autorisations et la gestion des droits des utilisateurs. 5. Disponibilité : les données stockées sur un portail ou, de manière générale, sur tout site web se doivent d être accessibles tout le temps. Il en va de même pour les ressources et les services. Sur notre exemple du portail web, si le service mail venait à être indisponible pour une durée indéterminée, cela risque fort de perturber l organisation. 6. Surveillance : Il s agit de vérifier qui a accès à quelles informations. En outre, pour respecter la législation, quelques mesures visant les données elles-mêmes seront à intégrer : 1. Rectification : L utilisateur dispose d un droit de rectification sur ses données. Il peut en effet exiger la modification de ses données. 2. Opposition : L utilisateur doit à tout moment être capable de supprimer ses données du logiciel. 3. Information : Un certains nombre d informations relatives aux données collectées doivent être disponibles pour l utilisateur (utilisation faite, personnes responsables,...) 4. Collecte : Il faudra définir quelles données à collecter. Certaines catégories de données sont d ailleurs interdites de traitement. 5. Notification des traitements auprès d une autorité de contrôle 6. Légitimité : Il faudra ici que l utilisateur donne son consentement à l utilisation des données. 3
3 Rappel des étapes du SDLC Dans cette section, nous allons exposer les quelques types de cycle de développement de logiciel, et une explication rapide des leurs étapes. 3.1 Le cycle en cascade Il s agit d un cycle incrémental où on ajoute des éléments à chacune des étapes. Les différentes étapes successives sont 1. l analyse des besoins : on détermine ce que veulent les clients, les objectifs globaux que le logiciel devra remplir, et on construit des spécifications précises pour les développeurs. 2. la conception : description de l architecture de l application. Pour cela, on décrit en détail les différentes fonctionnalités du logiciel (à l aide d exemple de captures d écrans, de diagrammes, de pseudocode,...). 3. l implémentation : Phase de codage proprement dite. 4. les tests : l application est testée dans un environnement particulier de différentes façons 5. la maintenance : Changements, corrections, ajouts. 3.2 Le cycle en V Sa description se trouve sur le schéma de la figure 1, où chaque étape de la seconde branche du V amène un feedback ou un retour à l étape correspondante si on détecte des erreurs. Figure 1 Cycle en V 4
3.3 Le cycle en W Ce modèle s inspire de celui en V, mais sépare la réalisation de la validation des besoins. Dans le premier V, on y développe une maquette, c est-à-dire une version minimale de l application afin que l utilisateur puisse la valider avant de passer à la conception réelle de l application finale. Figure 2 Cycle en W 3.4 Le cycle en Spirale L objectif est de mettre en évidence l analyse du niveau de risque et de le planifier pour chaque nouveau produit. Pour cela on utilise un modèle cyclique tel que chaque cycle s appuie sur les précédents. Ce se traduit par des coûts cumulé et des spécifications qui tiennent compte de l existant. Un cycle est un niveau du produit ou un produit composé de 4 phases ; Identifier les objectifs, les contraintes et les alternatives Evaluer les alternatives, identifier les risques et par après choisir Développer et vérifier le produit de ce niveau Planifier le cycle suivant Il s agit d un modèle itératif, incluant le prototypage. 5
4 Proposition de prise en compte des règles dans les étapes du SDLC Nous détaillons ici les différentes mesures à appliquer pour chacune des étapes du cycle de vie du développement logiciel, appliqué au cas du portail web. 4.1 Analyse des besoins Dans cet phase, on défini les mesures importantes, identifiée par les requirements des clients, mais également celles qui découle du contexte organisationnel et légal. Collecte : La première question à se poser, avant même de s intéresser aux autres points, sera : De quelles informations le logiciel a-t-il besoin pour fonctionner? Par exemple : est-ce que le logiciel a réellement besoin des nom et prénom de l utilisateur ou peutil se contenter d un pseudonyme? La bonne pratique est ici de ne collecter que les informations nécessaires. Egalement, certaines informations ne peuvent d ailleurs pas être traitées. Information : Il faudra définir et mettre en place une page reprenant les différentes informations relatives aux données collectées et à leur utilisation. Ce point étant trivial, nous ne le développerons pas dans la suite. De même, pour être en accord avec la législation, il faudra notifier l autorité de contrôle des données récoltées et de leur utilisation. Légitimité : Une politique de gestion des données devra être établie. L utilisateur devra marquer son accord avec celle-ci lors de l inscription. Authentification : En fonction des besoins de l entreprises et du logiciel, il va falloir décider quelle politique d authentification sera utilisée pour la gestion des identités. Il sera sans doute nécessaire dans ce cas-ci de faire la distinction entre compte utilisateur et administrateur, chaque client disposant d un portail particulier. L idée sera de voir si nous utiliserons du single sign on ou pas. Comme l organisation développera plusieurs portails, il faudra déterminer si les clients seront amenés à avoir un compte sur chacun de ceux-ci, et alors nous utiliserons le SSO, ou si les portails sont bien séparés (des clients très différents, une boucherie de Namur et un producteur de cinéma de Bruxelles, par exemple), et dans ce cas, le SSO n aura pas beaucoup d influence. Un système tel que Shibboleth pourrait être une solution. Une solution plus légère HTTPS dans le cas non SSO également. Contrôle d accès : Il faudra ici définir la politique générale de gestion des accès. Etant donné le nombre d utilisateurs présumés assez large (plusieurs portails, contenant chacun un certain nombre d utilisateurs) le modèle RBAC sera privilégié sur DAC ou MAC. En particulier, P-RBAC semble être une solution intéressante pour les notions de finalité, d obligation et de condition qu il implémente. La définition des différents rôles (utilisateur, administrateur,...), des actions (read, write,..), des types de données (ex : public : pseudonyme, privé : nom, prénom,...), des finalités (on pourrait imaginer une finalité info permettant à un utilisateur de voir les infos publiques d un autre utilisateur, une finalité contact permettant aux administrateurs de voir les informations postales d un utilisateur,...) seront définies lors de cette étape. Comme nous n aurons, à 6
priori, pas énormément de rôles et de règles (il devrait exister une grande réutilisabilité entre les services des différents portails), P-RBAC ne devrait pas être difficile à mettre en place. Si les portails offrent des services bien différents et ont besoin de règles différentes d un portail à l autre, il serait sans doute plus intéressant de proposer une implémentation XACML. Rectification : Penser à un système permettant la correction des erreurs. Doit-elle être permise par l utilisateur lui-même, est-ce que seulement certaines personnes de l entreprise seront habilitées à modifier ces données, Est-ce qu un système de signalement d erreur par l utilisateur sera mis en place,... Etant donnée le domaine d application, une modification de ses données par l utilisateur lui-même au moyen d un formulaire semble être la solution la plus simple. De même, l utilisateur doit être capable de supprimer ses données et son compte. Il faudra pour cela supprimer ses informations de la base de données. Surveillance : Un système de log sera mis en place grâce au modèle P-RBAC qui permet d exécuter des actions (ici le référencer dans le système de log). Une liste des actions à priorité élevée sera également dressée (tentatives de connexion successives, par exemple. Intégrité : Une fois stockées, le contrôle d accès devrait permettre de conserver l intégrité des données. Néanmoins, une modification volontaire ou non des données par un utilisateur disposant des droits nécessaires peut survenir. Ce sera du rôle de la surveillance d assurer ce cas. Disponibilité : Les exigences de disponibilité d un tel service devront être analysées. A priori, le système de contrôle d accès sera très important. Par contre, bien qu il empêchera les connexions, le service d authentification sera moins important en terme de disponibilité, car seule l authentification sera impossible, et les utilisateurs ne pourrons pas utiliser les service du portail, mais rien ne sera compromis. Une analyse déterminera évidemment si une haute disponibilité est nécessaire. 4.2 Conception Ici, on définit l architecture de l application en incluant les outils et principes de sécurité se rapportant aux règles identifiées précédemment. Contrôle d accès : On définira les règles d accès à cette étape. Un exemple : (user, (read, object.ehr.user.public), Info, φ) Permet à un utilisateur de consulter les données publiques d un autre utilisateur. Authentification : Ne pas mettre l identity provider sur le même serveur que les portails semble une solution de bon sens. Si le serveur est compromis, l attaquant n aura de cette façon pas accès à toute la base de données des mots de passe. 4.3 Implémentation On implémente selon l architecture définie, mais également selon les bonnes pratiques. Contrôle d accès : il s agira d implémenter les règles et différentes variable définies. 7
Authentification : Mise en place de l identity provider et des différents services providers. A noter que pour chaque nouveau portail implémenté, il faudra installer un nouveau service provider. Intégrité : l organisation disposant sans doute déjà de son propre modèle de gestion de données à caractère personnel, il faudra s assurer lors du passage de leur modèle vers notre implémentation, que toutes les données ne subissent pas de modification et soient toujours intègres une fois la mise à jour effectuée. Un soin tout particulier devra être apporté à cette étape, étant donnée la cricicité de celle-ci. Afin d empêcher les intrutions et la corruptions des base de données, on pense également à se prémunir contre les injections SQL, au moyen de preparedstatement, par exemple. 4.4 Tests Les tests permettent de vérifier si les mesures ont bien été appliquées, mais aussi de découvrir s il n existe pas d autres failles. Authentification : Des tests d authentification pour tous les rôles des utilisateurs seront effectués. Contrôle d accès : Un soin particulier devra être apporté aux tests relatifs au contrôle d accès. Si l exhaustivité est possible, il faudrait tester toutes les règles avec toutes les variables (rôle, objet, finalité,...). Surveillance : Une vérification du bon fonctionnement des logs et notifications sera apportée 4.5 Maintenance Surveillance : Un rôle particulier sera ici donné à la surveillance. En effet, il est bien beau d avoir mis en place un système de log, mais il faut absolument sensibiliser les responsables sécurité à l importance de la lecture de ces logs afin de repérer d éventuelles tentatives de pénétration. Mise à jour : Comme dans tout projet informatique, le système de gestion des données devra prendre ne compte les différentes évolutions des outils mis en place. 8
5 Proposition organisationnelle : acteurs, rôles, responsabilités Dans le cas d un portail web, nous pouvons définir plusieurs classe d acteurs possédant des rôles et privilèges différents ; Utilisateur : Le simple utilisateur sera une simple personne accédant et utilisant un des portails. A ce titre, ses actions sont très limitées et il ne connaitra aucune information confidentielle. Par contre, comme c est un fournisseur de données, il faudra l informer de l utilisation faite par le logiciel de ses données, comme nous l avons souligné auparavant. Administrateur : Par administrateur, on entend client de l organisation à qui nous fournissons un portail. Les informations nécessaire pour le fonctionnement de son portail lui seront fournies. Néanmoins, il ne disposera d aucun droit de modification sur ces informations. Super-Administrateur : Les super-administrateurs seront en charge de la maintenance du logiciel et de ses données. De ce fait, il faudra les former aux aspects légaux de l utilisation des données personnelles des utilisateurs (exemple : la falsification de données, consciemment ou non, est punie par la législation belge). Ces utilisateurs auront en effet des droits de lecture et écriture sur toutes les données des utilisateurs. Partenaires : On pourrait envisager la présence de partenaires, avec lesquels il faudrait partager les informations des utilisateurs. Ici aussi, l information des utilisateurs des échanges avec ces partenaires est primordiale. Autres utilisateurs de l entreprise : On pourrait définir d autres rôles (exemples : service comptabilité ayant accès aux données des administrateurs-clients, helpdesk permettant la réinitialisation d un mot de passe utilisateur,...) en fonction des secteurs de l entreprise. Comme nous ne connaissons pas exactement les différents rôles de l entreprise et qu on peut en imaginer un nombre très grand, nous ne les développerons pas plus. 9
6 Conclusion Notons tout de même que dans un but d exercice, nous n avons pas parlé de la solution de la délégation à un SSO web plus général. Elle aurait bien sûr pu être envisagée. Nous avons donc décrit les différentes mesures à appliquer concernant les données sensibles. L émanance de ces mesures provient tantôt des requirements de l utilisateurs, tantôt de la législation. Il est donc souhaitable d y apporter un soin particulier. Nous pouvons remarques que la démarche de sécurité s intègre aussi dans les premières phases de développement, et pas uniquement dans la partie implémentation. En intégrant ainsi la démarche à chaque étape, elle bénéficie également des feedbacks client, mais peut aussi être corrigée durant le développement. Comme vu aux cours, il existe déjà une multitude d outils offrant une aide précieuse pour combler certaines règles. L organisation n est donc pas obligée de tout fabriquer elle-même ( ne pas réinventer la roue ). On pense également au bonne pratique à définir dans l entreprise : en effet, celle-ci étant spécialiser dans le développement de portail web, il est donc intéressant de mettre en place un guide de bonne pratique défini avec l expérience acquise, mais aussi de l améliorer en permance. De plus, des normes existent pour formaliser ces pratiques. L aspect sécurité doit donc être intégré le plus tôt possible dans le SDLC. Le cycle de vie de la sécurité doit avoir la même forme que celui du logiciel : à chaque étape du SDLC, il y a un aspect sécurité. 10