diff --git a/.DS_Store b/.DS_Store index 5ede25f..5d2a955 100644 Binary files a/.DS_Store and b/.DS_Store differ diff --git a/annexes/page_de_garde.tex b/annexes/page_de_garde.tex index cbd79dc..1204cee 100644 --- a/annexes/page_de_garde.tex +++ b/annexes/page_de_garde.tex @@ -23,7 +23,7 @@ %---------------------------------------------------------------------------------------- % AUTHOR SECTION %---------------------------------------------------------------------------------------- - + \vfill \begin{minipage}{0.4\textwidth} \begin{flushleft} \large @@ -43,7 +43,7 @@ % DATE SECTION %---------------------------------------------------------------------------------------- - {\large Février à Septembre 2018}\\[2cm] % Date, change the \today to a set date if you want to be precise + {\large Juillet à Septembre 2018}\\[2cm] % Date, change the \today to a set date if you want to be precise %---------------------------------------------------------------------------------------- % LOGO SECTION diff --git a/chapitres/conclusions/resultats.tex b/chapitres/conclusions/resultats.tex index 3395e5f..da0ab1b 100644 --- a/chapitres/conclusions/resultats.tex +++ b/chapitres/conclusions/resultats.tex @@ -4,9 +4,9 @@ Au terme de la période de la réalisation de ce travail de bachelor, le résult \chapter{Synthèse personnelle} -En tant que premier projet de développement \emph{professionnel}, je suis non seulement satisfait du résultat mais surtout du chemin parcouru pour y arriver. Trouver des solutions pertinentes et savoir s'adapter à la situation sont pour moi deux des trais les plus importants d'un ingénieur. La problématique présentée dans ce projet est propre à la sécurité des réseaux informatiques, et sa parfaite compréhension m'a permis d'imaginer des solutions adéquates. +En tant que premier projet de développement \emph{professionnel}, je suis non seulement satisfait du résultat mais surtout du chemin parcouru pour y arriver. Trouver des solutions pertinentes et savoir s'adapter à la situation sont pour moi deux des traits les plus importants d'un ingénieur. La problématique présentée dans ce projet est propre à la sécurité des réseaux informatiques, et sa parfaite compréhension m'a permis d'imaginer des solutions adéquates. -Les différents modules suivi au cours de ma formation à la \acrshort{heig} m'ont amené certains outils qui ont été utiles durant la réalisation de ce projet. Les différents cours de programmation (bien que plus orienté pour des équipements embarqués) ont probablement contribué à améliorer ma logique et ma créativité lorsqu'il s'agit d'imaginer des algorithmes efficaces pour résoudre des problèmes. Le fait de mettre en pratique ces connaissances acquises est encore bien différent et je me suis rendu compte durant ce projet, que des idées qui semblent pertinentes au début, ne le sont plus par la suite. Savoir donc adapter le travail existants et continuellement l'améliorer et quelque chose que je me suis efforcé de faire pendant la phase de développement. +Les différents modules suivi au cours de ma formation à la \acrshort{heig} m'ont amené certains outils qui ont été utiles durant la réalisation de ce projet. Les différents cours de programmation (bien que plus orienté pour des équipements embarqués) ont probablement contribué à améliorer ma logique et ma créativité lorsqu'il s'agit d'imaginer des algorithmes efficaces pour résoudre des problèmes. Le fait de mettre en pratique ces connaissances acquises est encore bien différent et je me suis rendu compte durant ce projet, que des idées qui semblent pertinentes au début, ne le sont plus forcément par la suite. Savoir donc adapter le travail existant et continuellement l'améliorer et quelque chose que je me suis efforcé de faire pendant la phase de développement. La mise en pratique du \gls{tdd} comme méthode de développement m'a également beaucoup apporté. Il est vite devenu très naturel de décrire le comportement attendu par un objet ou une méthode et d'écrire ensuite le code nécessaire à sa mise en place. Cela m'a permis de m'assurer que ce qui était fonctionnel l'est toujours après l'ajout de nouvelles fonctionnalités. Ces tests sont également la base qui rend possible la mise en place des mécanismes d'intégration continue. Grâce à Gitlab, il va facilement pouvoir exécuter les taches de vérification et ne déployer le code que si l'ensembles des tests est validé. diff --git a/chapitres/gestion/echeancier.tex b/chapitres/gestion/echeancier.tex index cf08226..44c817d 100644 --- a/chapitres/gestion/echeancier.tex +++ b/chapitres/gestion/echeancier.tex @@ -2,7 +2,7 @@ \section{Planification} -La réalisation de ce présent travail de bachelor a été faite en suivant les \emph{User Stories} définis au chapitre "Analyse et planification" de la pré-étude. La période de réalisation en elle-même a été découpée en six \glspl{sprint} de deux semaines. Le but est de pouvoir faire une revue avec le client à la fin de chacun d'entre eux, pour avoir des retours sur le travail effectué et réajusté la priorité d'une fonctionnalité si besoin. Le premier sprint ayant surtout consisté à mettre en place l'environnement de développement et le réseau de test, il n'y avait pas lieu de faire une revue, car il n'y avait rien de terminé à montrer au client. Le dernier sprint se termine le jour du rendu de ce présent rapport, aucune revue ne sera donc faite avant cette date. +La réalisation de ce présent travail de bachelor a été faite en suivant les \emph{User Stories} définies au chapitre "Analyse et planification" de la pré-étude. La période de réalisation en elle-même a été découpée en six \glspl{sprint} de deux semaines. Le but est de pouvoir faire une revue avec le client à la fin de chacun d'entre eux, pour avoir des retours sur le travail effectué et réajuster la priorité d'une fonctionnalité si besoin. Le premier sprint ayant surtout consisté à mettre en place l'environnement de développement et le réseau de test, il n'y avait pas lieu de faire une revue, car il n'y avait rien de terminé à montrer au client. Le dernier sprint se termine le jour du rendu de ce présent rapport, aucune revue ne sera donc faite avant cette date. \vspace{3mm} \begin{table}[H] @@ -26,7 +26,7 @@ La gestion des sprints est gérée par le serveur Gitlab sous la forme de "miles \begin{figure}[H] \centering - \includegraphics[width=160mm]{gitlab_milestones} + \includegraphics[width=\textwidth]{gitlab_milestones} \caption{Gestion des sprints avec Gitlab} \end{figure} @@ -63,22 +63,22 @@ Certaines fonctionnalités requièrent du développement sur plusieurs parties d \begin{figure}[H] \centering - \includegraphics[width=160mm]{sprint1} + \includegraphics[width=\textwidth]{sprint1} \caption{Détail des taches du sprint 1} \end{figure} -Une grande partie de ce sprint a été dédié à la préparation de l'environnement de travail requis pour ce projet. Cela comprend notamment la mise en place d'un serveur de virtualisation pour pouvoir mettre en place une instance Gitlab\cite{gitlabsite} ainsi que d'autres machines virtuelles qui se sont occupées d'exécuter et de valider les différents tests. Avec cela, un mécanisme de backup journalier du serveur a été configuré pour se protéger contre une éventuelle perte de données. +Une grande partie de ce sprint a été dédiée à la préparation de l'environnement de travail requis pour ce projet. Cela comprend notamment la mise en place d'un serveur de virtualisation pour pouvoir mettre en place une instance Gitlab\cite{gitlabsite} ainsi que d'autres machines virtuelles qui se sont occupées d'exécuter et de valider les différents tests. Avec cela, un mécanisme de backup journalier du serveur a été configuré pour se protéger contre une éventuelle perte de données. Le réseau de test (comme décrit dans la section sur le routage (\ref{subsec:network:ip:routing})) a ensuite été configuré pour simuler une architecture réseau utilisant les mêmes technologies que celles du CHUV. Ces équipements ont pu ensuite servir d'éléments de tests pertinents durant le développement de l'application. -La seconde partie du sprint a servis à commencer le programme qui permet de pouvoir exécuter des requêtes sur les équipements Fortinet. +La seconde partie du sprint a servi à commencer le programme qui permet de pouvoir exécuter des requêtes sur les équipements Fortinet. \newpage \subsection{Sprint 2} \begin{figure}[H] \centering - \includegraphics[width=160mm]{sprint2} + \includegraphics[width=\textwidth]{sprint2} \caption{Détail des taches du sprint 2} \end{figure} @@ -95,7 +95,7 @@ Première revue avec les futurs utilisateurs pour valider les trois premières u \begin{figure}[H] \centering - \includegraphics[width=160mm]{sprint3} + \includegraphics[width=\textwidth]{sprint3} \caption{Détail des taches du sprint 3} \end{figure} @@ -108,7 +108,7 @@ Création du projet pour la partie frontend de l'application avec une interface \begin{figure}[H] \centering - \includegraphics[width=160mm]{sprint4} + \includegraphics[width=\textwidth]{sprint4} \caption{Détail des taches du sprint 4} \end{figure} @@ -121,7 +121,7 @@ L'interface WEB permet maintenant de voir les équipements gérés dans l'applic \begin{figure}[H] \centering - \includegraphics[width=160mm]{sprint5} + \includegraphics[width=\textwidth]{sprint5} \caption{Détail des taches du sprint 5} \end{figure} @@ -135,8 +135,8 @@ Mise à jour de l'interface WEB pour améliorer l'affichage et l'ergonomie. La q \begin{figure}[H] \centering - \includegraphics[width=160mm]{sprint6} + \includegraphics[width=\textwidth]{sprint6} \caption{Détail des taches du sprint 6} \end{figure} -Corrections des derniers problèmes remontés et finalisation du présent rapport. \ No newline at end of file +Corrections des derniers problèmes remontés et finalisation du présent rapport. diff --git a/chapitres/gestion/rendezvous.tex b/chapitres/gestion/rendezvous.tex index b932e74..d56e87b 100644 --- a/chapitres/gestion/rendezvous.tex +++ b/chapitres/gestion/rendezvous.tex @@ -15,7 +15,7 @@ Plusieurs rencontres ont eut lieu avec le conseiller durant la période de réal \section{Client - CHUV} -Les rencontres avec le mandant du projet et son équipe se sont déroulées dans les bureaux du CHUV pour faire les revues de fin de sprint. Ces échanges ont permis de valider les différentes \emph{User Story} et d'obtenir des retours sur l'utilisation de la solution. +Les rencontres avec le mandant du projet et son équipe se sont déroulées dans les bureaux du CHUV pour faire les revues de fin de sprint. Ces échanges ont permis de valider les différentes \emph{User Stories} et d'obtenir des retours sur l'utilisation de la solution. \begin{itemize} \item \textbf{09.08.2018 14h-15h30:} Démonstration de la première version du backend en faisant des requêtes sur l'API avec l'outil Postman\cite{postman}. Validation des quatres premières user stories. diff --git a/chapitres/introduction/introduction.tex b/chapitres/introduction/introduction.tex index adb392c..57b9a88 100644 --- a/chapitres/introduction/introduction.tex +++ b/chapitres/introduction/introduction.tex @@ -29,4 +29,4 @@ La réalisation de ce projet est découpée en plusieurs sous-projets distincts \section{Acronymes et définitions} -Par expérience, le milieu des réseaux informatiques utilisent beaucoup d'acronymes. Il existe surtout beaucoup de standards et de protocoles qui font partie du vocabulaire courant lorsqu'on parle d'infrastructure réseau. Pour améliorer la compréhension de ce rapport, un glossaire de définitions et d'acronymes se trouvent à la fin de ce rapport. \ No newline at end of file +Par expérience, le milieu des réseaux informatiques utilisent beaucoup d'acronymes. Il existe surtout beaucoup de standards et de protocoles qui font partie du vocabulaire courant lorsqu'on parle d'infrastructure réseau. Pour améliorer la compréhension de ce rapport, un glossaire de définitions et d'acronymes se trouve à la fin de ce rapport. \ No newline at end of file diff --git a/chapitres/introduction/network.tex b/chapitres/introduction/network.tex index 5aee2be..5f8df27 100644 --- a/chapitres/introduction/network.tex +++ b/chapitres/introduction/network.tex @@ -4,9 +4,9 @@ Pour être en mesure de comprendre le fonctionnement de l'analyse des règles de sécurité des réseaux informatiques, il est d'abords nécessaire de définir ce que sont ces dernières. Les classes et objets du projet utilisent les terminologies réseaux expliquées ici. -Le but d'un réseau informatique et d'acheminer des données sous forme de paquets \acrshort{ip} d'un n\oe{}ud A vers un ou plusieurs autres n\oe{}uds. Ces réseaux sont composés de plusieurs sortes d'équipements différents comme des routers, switches (commutateurs en français) mais aussi des équipements plus orienté sur la sécurité tels que des \glspl{firewall} ou \gls{proxy}. Tous ces équipements sont reliés ensemble via du câblages cuivre ou bien par du réseau optique. Ils forment ensemble le réseau physique. Son rôle est de faire transiter des trames ethernet d'un équipements à un autre, sans s'assurer qu'ils soient arrivés à destination. +Le but d'un réseau informatique et d'acheminer des données sous forme de paquets \acrshort{ip} d'un n\oe{}ud A vers un ou plusieurs autres n\oe{}uds. Ces réseaux sont composés de plusieurs sortes d'équipements différents comme des routers, switches (commutateurs en français) mais aussi des équipements plus orienté sur la sécurité tels que des \glspl{firewall} ou \gls{proxy}. Tous ces équipements sont reliés ensemble via du câblages cuivre ou bien par du réseau optique. Ils forment ensemble le réseau physique. Son rôle est de faire transiter des trames ethernet d'un équipement à un autre, sans s'assurer qu'ils soient arrivés à destination. -Contacter un n\oe{}ud réseau par son adresse physique (l'adresse \acrshort{mac}) peut vite s'avérer être un problème. Il faut être sur quelle soit unique dans l'entier du réseau, faute de quoi, la transmission ne pourra être faite. De plus, chaque changement d'équipement s'accompagne forcément d'un changement d'adresse matériel. Il n'est pas non plus possible d'isoler une machine d'une autre, ce qui rend impossible la mise en place de sécurité réseau. C'est notamment pour ces raisons qu'un réseau virtuel ou logique est configuré au dessus du réseau physique, réseau qui utilise les protocoles IP en version 4 ou 6. Ce système permet d'attribuer manuellement ou à la demande des adresses sur un n\oe{}ud indépendamment de son matériel. Il est également possible de créer plusieurs réseaux logiques sur un seul réseau physique (avec l'utilisation de \acrshort{vlan}), ce qui permet d'établir des règles de sécurité pour limiter les communications. +Contacter un n\oe{}ud réseau par son adresse physique (l'adresse \acrshort{mac}) peut vite s'avérer être un problème. Il faut être sur quelle soit unique dans l'entier du réseau, faute de quoi, la transmission ne pourra être faite. De plus, chaque changement d'équipement s'accompagne forcément d'un changement d'adresse matérielle. Il n'est pas non plus possible d'isoler une machine d'une autre, ce qui rend impossible la mise en place de sécurité réseau. C'est notamment pour ces raisons qu'un réseau virtuel ou logique est configuré au dessus du réseau physique, réseau qui utilise les protocoles IP en version 4 ou 6. Ce système permet d'attribuer manuellement ou à la demande des adresses sur un n\oe{}ud indépendamment de son matériel. Il est également possible de créer plusieurs réseaux logiques sur un seul réseau physique (avec l'utilisation de \acrshort{vlan}), ce qui permet d'établir des règles de sécurité pour limiter les communications. Bien que le protocole \acrshort{ip} amène un système d'adressage plus souple et modulaire, il ne s'assure pas que le paquet arrive correctement à destination. Il ne fournit pas non plus d'identifiant permettant à la machine distante de savoir quel processus doit traiter le paquet. Pour cela, deux protocoles principaux sont utilisés aujourd'hui, il s'agit de \acrshort{tcp} et \acrshort{udp}. Ces deux protocoles vont attribuer un numéro de port aux segments échangés, afin que les systèmes d'exploitation soient en mesure de savoir quel programme doit traiter la requête. @@ -181,6 +181,6 @@ Les \glspl{firewall} (classe \Colorbox{light-gray}{\lstinline|Device|}) sont des \end{tabular} \end{table} -Les polices de sécurité sont analysées et évaluées de façon séquentielle, dès que les critères d'une règle sont tous respectés, l'action est effectuée. Par exemple, si un poste de travail avec une adresse IP 192.168.1.57 essaie de se connecter en HTTPS (port TCP/443) sur le serveur 10.0.1.2, sa requête va passé au travers du firewall qui va analyser le flux pour définir s'il doit être accepté ou non, en utilisant la liste de règles du tableau \refname{sec:rules:tab} et en admettant que le réseau 192.168.1.0/24 est bien connu par l'interface "client" et le réseau 10.0.1.0/24 par l'interface "server". +Les polices de sécurité sont analysées et évaluées de façon séquentielle, dès que les critères d'une règle sont tous respectés, l'action est effectuée. Par exemple, si un poste de travail avec une adresse IP 192.168.1.57 essaie de se connecter en HTTPS (port TCP/443) sur le serveur 10.0.1.2, sa requête va passer au travers du firewall qui va analyser le flux pour définir s'il doit être accepté ou non, en utilisant la liste de règles du tableau \ref{sec:rules:tab} et en admettant que le réseau 192.168.1.0/24 est bien connu par l'interface "client" et le réseau 10.0.1.0/24 par l'interface "server". La première règle décrit bien un flux provenant de l'interface "client" vers "server", la source est le réseau "192.168.1.0/24" dans lequel l'adresse IP source "192.168.1.57" se trouve, cependant la destination indique un réseau "10.0.1.1/32" qui ne correspond pas à notre serveur "10.0.1.2". Les conditions n'étant pas toutes validées, le firewall va passer à la seconde règle et recommencer la même analyse. Dans la seconde règle, la destination est "10.0.1.2/32" qui est bien la destination du flux analysé, il ne reste donc que le service à valider. Notre communication utilise le port de destination tcp/443 qui est bien dans la liste de la règle. Les conditions étant toutes validées, l'action est appliquée, ce qui correspond dans ce cas à laisser le flux passer. Ce processus est ainsi répété pour chaque nouvelle connexion passant au travers du firewall. diff --git a/chapitres/model/classes.tex b/chapitres/model/classes.tex index 83fa7d4..d87a4d5 100644 --- a/chapitres/model/classes.tex +++ b/chapitres/model/classes.tex @@ -2,7 +2,7 @@ \section{Diagramme de classe} -Les modèles décrit dans la section suivante sont liées à des collections dans la base de données MongoDB. C'est le module mongoid\cite{mongoid} qui va s'occuper de faire la corrélation entre ce qui est décrit dans la classe en ruby et le schéma de la base dans MongoDB. Dans une structure non-relationnelle comme c'est le cas ici, un objet peut en contenir un autre. C'est notamment le cas pour le modèle \Colorbox{light-gray}{\lstinline|Device|}, qui va contenir tous les objets qui lui sont propre. Cette architecture a pour avantage de pouvoir plus facilement décrire les contraintes sur certains objets. Typiquement, l'attribut "name" d'un objet \Colorbox{light-gray}{\lstinline|Address|} doit être unique, mais uniquement dans le contexte de l'équipement auquel il est attaché. Si on utilise un outil pour afficher le contenu de la base, on constate bien que chaque objet \Colorbox{light-gray}{\lstinline|Device|} contient les autres objets qui lui sont associés. +Les modèles décrit dans la section suivante sont liées à des collections dans la base de données MongoDB. C'est le module mongoid\cite{mongoid} qui va s'occuper de faire la corrélation entre ce qui est décrit dans la classe en ruby et le schéma de la base dans MongoDB. Dans une structure non-relationnelle comme c'est le cas ici, un objet peut en contenir un autre. C'est notamment le cas pour le modèle \Colorbox{light-gray}{\lstinline|Device|}, qui va contenir tous les objets qui lui sont propre. Cette architecture a pour avantage de pouvoir plus facilement décrire les contraintes sur certains objets. Typiquement, l'attribut "name" d'un objet \Colorbox{light-gray}{\lstinline|Address|} doit être unique, mais seulement dans le contexte de l'équipement auquel il est attaché. Si on utilise un outil pour afficher le contenu de la base, on constate bien que chaque objet \Colorbox{light-gray}{\lstinline|Device|} contient les autres objets qui lui sont associés. \vspace{3mm} \begin{figure}[h] @@ -50,7 +50,7 @@ Les méthodes pour chiffrer et déchiffrer les mots de passe sont fournit par le \subsection{Address} \label{sec:classe:address} -Il s'agit d'un élément d'une règle de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) qui décrit un objet réseau caractérisé par un réseau IPv4 au format \acrshort{cidr}. De ce réseau nous allons pouvoir en déduire la première et dernière adresse IP. Ces addresses seront ensuite converties en décimal pour pouvoir être indexé par la base de donnée. Ainsi \Colorbox{light-gray}{\lstinline|start_ip|} est la représentation numérique de la première adresse IP de ce réseau, et \Colorbox{light-gray}{\lstinline|end_ip|} la dernière. Dans le cas où le réseau ne contient qu'une seule adresse IP (masque réseau de 32 bits), ces deux valeurs seront identiques. Ces dernières sont calculées à chaque modifications de l'attribut network. +Il s'agit d'un élément d'une règle de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}) qui décrit un objet réseau caractérisé par un réseau IPv4 au format \acrshort{cidr}. De ce réseau nous allons pouvoir en déduire la première et dernière adresse IP. Ces addresses seront ensuite converties en décimal pour pouvoir être indexées par la base de donnée. Ainsi \Colorbox{light-gray}{\lstinline|start_ip|} est la représentation numérique de la première adresse IP de ce réseau, et \Colorbox{light-gray}{\lstinline|end_ip|} la dernière. Dans le cas où le réseau ne contient qu'une seule adresse IP (masque réseau de 32 bits), ces deux valeurs seront identiques. Ces dernières sont calculées à chaque modifications de l'attribut network. \vspace{3mm} \begin{lstlisting}[language=Ruby, title="app/model/address.rb"] @@ -109,11 +109,11 @@ Il fournit également la méthode 'match?' qui va retourner 'true' si l'ensemble \subsection{ServiceGroup} -Un groupe de service est simplement un objet dont l'attribut 'services' contient le nom de toutes les \Colorbox{light-gray}{\lstinline|Service|} qu'il contient. +Un groupe de service est simplement un objet dont l'attribut 'services' contient le nom de tous les \Colorbox{light-gray}{\lstinline|Service|} qu'il contient. \subsection{Zone} -Une zone représente un groupe d'interfaces réseaux dans un équipement. C'est surtout utilisé dans les règles de sécurité pour faciliter l'écriture de celle-ci. +Une zone représente un groupe d'interfaces réseaux dans un équipement. C'est surtout utilisé dans les règles de sécurité pour faciliter l'écriture de celles-ci. \subsection{Route} \label{sec:classe:route} @@ -128,11 +128,11 @@ La table de routage est un élément des équipement réseaux et est composée d \newpage \subsection{Policy} -Une \Colorbox{light-gray}{\lstinline|Policy|} représente un règle de sécurité dans un équipement réseau. Elle décrit comment ce dernier doit se comporter lorsqu'il est traversé par des flux réseaux. En fonction de la source et de la destination du paquet (représenté sous forme d'\Colorbox{light-gray}{\lstinline|Address|} (section \ref{sec:classe:address}) ainsi que du protocol et de son numéro de port utilisé (représentés par le \Colorbox{light-gray}{\lstinline|Service|} (section \ref{sec:classe:service})), la règle va définir si la communication est autorisée où si elle doit être bloquée. +Une \Colorbox{light-gray}{\lstinline|Policy|} représente une règle de sécurité dans un équipement réseau. Elle décrit comment ce dernier doit se comporter lorsqu'il est traversé par des flux réseaux. En fonction de la source et de la destination du paquet (représenté sous forme d'\Colorbox{light-gray}{\lstinline|Address|} (section \ref{sec:classe:address}) ainsi que du protocole et de son numéro de port utilisé (représentés par le \Colorbox{light-gray}{\lstinline|Service|} (section \ref{sec:classe:service})), la règle va définir si la communication est autorisée où si elle doit être bloquée. La source et la destination sont deux champs qui peuvent contenir un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Address|} et/ou \Colorbox{light-gray}{\lstinline|AddressGroup|}. Le champ service peut être composé de un ou plusieurs nom de \Colorbox{light-gray}{\lstinline|Service|} et/ou \Colorbox{light-gray}{\lstinline|ServiceGroup|}. En plus de cela, la règle de sécurité peut contenir le ou les interfaces source et destination. Il s'agit de l'interface par lequel le flux doit passer pour que la règle soit évaluée. Il se peut qu'une interface face partie d'un groupe d'interfaces qui s'appelle dans ce cas là, une \Colorbox{light-gray}{\lstinline|Zone|}. -Le dernier attribut d'une règle de sécurité est l'action à faire lorsqu'un flux correspond aux critères de la règle. Les deux seuls actions possibles sont "accept" ou "deny", qui vont respectivement laisser passer le flux, ou bien le bloquer. +Le dernier attribut d'une règle de sécurité est l'action à faire lorsqu'un flux correspond aux critères de la règle. Les deux seules actions possibles sont "accept" ou "deny", qui vont respectivement laisser passer le flux, ou bien le bloquer. \subsection{Device} diff --git a/chapitres/model/methodes.tex b/chapitres/model/methodes.tex index 08f92f3..20278f9 100644 --- a/chapitres/model/methodes.tex +++ b/chapitres/model/methodes.tex @@ -46,7 +46,7 @@ Une fois les routes possibles obtenues, il faut encore isoler celle qui est la p \subsection{crossed?} \label{sec:methodes:crossed} -La méthode "crossed?" est un élément essentiel pour l'analyse des règles de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}). Elle permet de déterminer sur un équipement (\Colorbox{light-gray}{\lstinline|Device|}) est traversé par un flux définit par deux réseaux. Pour cela, il faut utiliser la méthode "route" de la table de routage (\Colorbox{light-gray}{\lstinline|RoutingTable|}) de l'équipement en question et comparer l'interface de sortie des deux routes obtenues. Si elles sont différentes, cela signifique que le flux traverse ce firewall. +La méthode "crossed?" est un élément essentiel pour l'analyse des règles de sécurité (\Colorbox{light-gray}{\lstinline|Policy|}). Elle permet de déterminer si un équipement (\Colorbox{light-gray}{\lstinline|Device|}) est traversé par un flux définit par deux réseaux. Pour cela, il faut utiliser la méthode "route" de la table de routage (\Colorbox{light-gray}{\lstinline|RoutingTable|}) de l'équipement en question et comparer l'interface de sortie des deux routes obtenues. Si elles sont différentes, cela signifique que le flux traverse ce firewall. \begin{lstlisting}[language=Ruby, title="app/model/device.rb"] # Params: diff --git a/chapitres/model/validation.tex b/chapitres/model/validation.tex index 989f82d..490e33a 100644 --- a/chapitres/model/validation.tex +++ b/chapitres/model/validation.tex @@ -7,11 +7,11 @@ Pour valider le bon fonctionnement de l'application et mettre en place le \gls{t \subsection{QUnit} -QUnit\cite{qunit} est un ensemble d'outil javascript qui permettent d'écrire des tests pour les applications WEB. Il peut simuler des cliques d'utilisateur sur des éléments de la page et de récupérer le contenu d'un \acrshort{dom} pour valider le bon fonctionnement des actions. Ce framework est utilisé nativement par EmberJS pour écrire les tests, les fichiers se trouvent dans le dossier \Colorbox{light-gray}{\lstinline|tests/|} à la racine du projet. +QUnit\cite{qunit} est un ensemble d'outils javascript qui permet d'écrire des tests pour les applications WEB. Il peut simuler des cliques d'utilisateur sur des éléments de la page et de récupérer le contenu d'un \acrshort{dom} pour valider le bon fonctionnement des actions. Ce framework est utilisé nativement par EmberJS pour écrire les tests et les fichiers qui le concerne se trouvent dans le dossier \Colorbox{light-gray}{\lstinline|tests/|} à la racine du projet. \subsection{ESLint} -ESLint\cite{eslint} est un analyseur de code JavaScript qui permet d'appliquer les bonnes pratiques. La syntaxe JS évoluent encore beaucoup aujourd'hui et l'analyse du code va vérifier que les derniers standards sont appliqués. Les tests sont fait automatiquement lors du lancement des tests Ember avec la commande \Colorbox{light-gray}{\lstinline|ember test|}. +ESLint\cite{eslint} est un analyseur de code JavaScript qui permet d'appliquer les bonnes pratiques. La syntaxe JS évolue encore beaucoup aujourd'hui et l'analyse du code va vérifier que les derniers standards sont appliqués. Les tests sont fait automatiquement lors du lancement des tests Ember avec la commande \Colorbox{light-gray}{\lstinline|ember test|}. \section{Ruby} @@ -29,7 +29,7 @@ Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle ex \subsection{Rubocop} -RuboCop\cite{rubocop} est un analyseur de code et de syntaxe basé sur le \emph{"A community-driven Ruby coding style guide"}\cite{rubystyleguide}. Il permet de s'assurer que la syntaxe est utilisée de façon uniforme dans le projet, de remonter l'utilisation de méthodes dépréciées, de vérifier les indentations. Tous les tests effectués par le programme peuvent être personnalisés au besoin et sont tous documentés avec des exemples\cite{rubocopdoc}. RuboCop propose également des tests supplémentaires pour les projets utilisant Rails, en se basant sur le \emph{"A community-driven Ruby on Rails coding style guide"}\cite{railsstyleguide}. +RuboCop\cite{rubocop} est un analyseur de code et de syntaxe basé sur le \emph{"A community-driven Ruby coding style guide"}\cite{rubystyleguide}. Il permet, entre autre, de s'assurer que la syntaxe est utilisée de façon uniforme dans le projet, de remonter l'utilisation de méthodes dépréciées et de vérifier les indentations. Tous les tests effectués par le programme peuvent être personnalisés au besoin et sont tous documentés avec des exemples\cite{rubocopdoc}. RuboCop propose également des tests supplémentaires pour les projets utilisant Rails, en se basant sur le \emph{"A community-driven Ruby on Rails coding style guide"}\cite{railsstyleguide}. Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle exec rubocop|} depuis la racine du projet. diff --git a/chapitres/requis/technique.tex b/chapitres/requis/technique.tex index 2817dc0..c969b41 100644 --- a/chapitres/requis/technique.tex +++ b/chapitres/requis/technique.tex @@ -12,13 +12,13 @@ L'application est construite selon une architecture trois tiers qui va séparer \end{figure} \vspace{3mm} -La communication entre le frontend et le backend se fait au travers d'un API \gls{restful} basé sur des échanges HTTP. Son implémentation du coté backend est assuré par le framework RubyOnRails\cite{railssite} et du coté frontend par EmberJS\cite{emberjssite}. Pour se comprendre, ces deux librairies respectent le même standard pour sérialiser l'information. Il s'agit de la spécification \emph{json api}\cite{jsonapi} dont l'implémentation coté backend est faite grâce au module ActiveModelSerializer\cite{activemodelserializer} et du coté frontend par la classe DS.JSONApiSerializer\cite{dsjsonapiserializer}. Cette convention décrit un ensemble de règles qui définissent comment les informations doivent être mises en forme dans une API qui utilise le JSON comme format de donnée. Cette structure force donc le développeur à structurer correctement les données et est une mise en application supplémentaire du paradigme "Convention plutôt que configuration". +La communication entre le frontend et le backend se fait au travers d'une API \gls{restful} basé sur des échanges HTTP. Son implémentation du coté backend est assurée par le framework RubyOnRails\cite{railssite} et du coté frontend par EmberJS\cite{emberjssite}. Pour se comprendre, ces deux librairies respectent le même standard pour sérialiser l'information. Il s'agit de la spécification \emph{json api}\cite{jsonapi} dont l'implémentation coté backend est faite grâce au module ActiveModelSerializer\cite{activemodelserializer} et du coté frontend par la classe DS.JSONApiSerializer\cite{dsjsonapiserializer}. Cette convention décrit un ensemble de règles qui définissent comment les informations doivent être mises en forme dans une API qui utilise le JSON comme format de donnée. Cette structure force donc le développeur à structurer correctement les données et est une mise en application supplémentaire du paradigme "Convention plutôt que configuration". Les échanges entre le backend et MongoDB sont assurés par le module Mongoid\cite{mongoid}. Cette extension applique le \emph{Data mapper pattern} en gérant la correspondance entre les objets définit en Ruby et les collections d'objets de la base de donnée. Elle va également fournir les méthodes pour interagir avec ces collections, comme par exemple les requêtes de recherche sur les objets. \section{Technologies et versions} -L'ensemble de la solution utilisent différentes technologies qui doivent toutes être supportées pour assurer son bon fonctionnement. Les programmes principaux sont listés dans le tableau ci-dessous: +L'ensemble de la solution utilise différentes technologies qui doivent toutes être supportées pour assurer son bon fonctionnement. Les programmes principaux sont listés dans le tableau ci-dessous: \vspace{3mm} \begin{table}[H] @@ -52,4 +52,4 @@ Les dépendances précises se trouvent dans des fichiers différents en fonction \section{Hébergement} -Pour pouvoir fonctionner correctement l'application doit pouvoir effectué des requêtes sur l'API des équipements gérés. Pour y parvenir, la machine sur laquelle l'application est hebergée doit pouvoir atteindre les ports TCP 80 et 443 de ces équipements. \ No newline at end of file +Pour pouvoir fonctionner correctement l'application doit pouvoir effectuer des requêtes sur l'API des équipements gérés. Pour y parvenir, la machine sur laquelle l'application est hebergée doit pouvoir atteindre les ports TCP 80 et 443 de ces équipements. \ No newline at end of file diff --git a/images/sprint1.png b/images/sprint1.png index 9663d8b..074ee43 100755 Binary files a/images/sprint1.png and b/images/sprint1.png differ diff --git a/images/sprint2.png b/images/sprint2.png index f4993db..242e791 100755 Binary files a/images/sprint2.png and b/images/sprint2.png differ diff --git a/images/sprint3.png b/images/sprint3.png index 11af71b..0dfda28 100755 Binary files a/images/sprint3.png and b/images/sprint3.png differ diff --git a/images/sprint4.png b/images/sprint4.png index 3e909c0..4ef3525 100755 Binary files a/images/sprint4.png and b/images/sprint4.png differ diff --git a/images/sprint5.png b/images/sprint5.png index e1b7cc3..4f7c4ab 100755 Binary files a/images/sprint5.png and b/images/sprint5.png differ diff --git a/images/sprint6.png b/images/sprint6.png index 6aec2ac..3e18f3f 100755 Binary files a/images/sprint6.png and b/images/sprint6.png differ diff --git a/index.tex b/index.tex index cb45f05..52baaf4 100644 --- a/index.tex +++ b/index.tex @@ -50,8 +50,8 @@ % Marges \usepackage{geometry} \geometry{ - left=2.5cm, - right=2cm, + left=2.75cm, + right=1.75cm, top=2cm, bottom=2cm, headheight=35pt, @@ -117,10 +117,6 @@ \addcontentsline{toc}{chapter}{Annexes} -% Dernière page - Authentification de l'auteur (modèle école) -\addcontentsline{toc}{section}{Authentification} -% \includepdf[pages=-]{annexes/authentification.pdf} - \addcontentsline{toc}{section}{Glossaire} \addcontentsline{toc}{section}{Acronymes} \printglossaries @@ -136,6 +132,10 @@ \addcontentsline{toc}{section}{Liste des tableaux} \listoftables +% Dernière page - Authentification de l'auteur (modèle école) +\addcontentsline{toc}{section}{Authentification} +\includepdf[pages=-]{annexes/bachelor_auth.pdf} + \printindex \end{document}