structure, model, requis et validations

bibli.bib

@@ -153,3 +153,21 @@
     title   =   {A community-driven Ruby on Rails style guide},
     note    =   {URL: "\url{https://github.com/rubocop-hq/rails-style-guide}"}
 }
+
+@misc{brakeman,
+    author  =   {Brakeman},
+    title   =   {A static analysis security vulnerability scanner for Ruby on Rails applications},
+    note    =   {URL: "\url{https://github.com/presidentbeef/brakeman}"}
+}
+
+@misc{qunit,
+    author  =   {QUnit},
+    title   =   {A JavaScript Unit Testing framework},
+    note    =   {URL: "\url{https://qunitjs.com/}"}
+}
+
+@misc{eslint,
+    author  =   {ESLint},
+    title   =   {The pluggable linting utility for JavaScript and JSX},
+    note    =   {URL: "\url{https://eslint.org/}"}
+}

chapitres/introduction/introduction.tex

@@ -1,4 +1,4 @@
-\chapter{Contexte}
+\chapter{Contexte et problématique}
 
 \section{Le CHUV}
 
@@ -6,3 +6,12 @@ Le \gls{chuv} emploie environ 11'000 personnes\cite{rapportActiviteChuv} dans de
 
 Le profil des utilisateurs du système d'information sont bien différents et le niveau de confidentialité des données l'est aussi. Dans le milieu académique, les étudiants travaillent avec leur propre matériel et ne sont pas des employés du \acrshort{chuv}. A l'inverse, dans le secteur hospitalier, les équipements informatiques sont tous gérés et administrés en interne. De plus, les informations échangées sont par exemple des dossiers de patients dont la confidentialité doit être assurée. Pour pouvoir y arriver, l'équipe en charge de l'infrastructure réseau et de la sécurité (équipe dont je fais partie) a mis en place de la segmentation pour maintenir le meilleur niveau de sécurité possible entre les différents environnements de travail.
 
+\section{La problématique}
+
+Le découpage du réseau informatique en plusieurs zones distinctes a conduit à une architecture de plus en plus complexe. Chaque liens entre ces zones est soumis à des règles de sécurité précises afin de ne laisser passer que les communications explicitement autorisées. Cette sécurité permet de réduire la surface d'attaque possible au cas où une machine est compromise. Bien que ce système soit efficace est ait fait ces preuves dans le milieu, il engendre un coût en terme d'implémentation et d'exploitation assez élevé.
+
+Lorsqu'une nouvelle application doit être mise en production, l'équipe réseau est en charge de configurer les nouvelles polices de sécurité pour faire en sorte que les communications nécessaires à son fonctionnement soient possible. Pour y arriver, il faut préalablement savoir quels sont les équipements qui sont considérés et qui doivent être adaptés. Ce travail est compliqué, car avec un réseau qui grandit en permanence, il n'est plus possible de connaître de tête le chemin réseau qui sera utilisé et il faut donc aller chercher dans plusieurs schémas pour obtenir cette information. Ces taches mises à la suite prennent beaucoup de temps et ces demandes d'ouvertures de flux étant fréquentes, il est maintenant indispensable pour l'équipe de s'équiper d'un outil qui soit capable d'analyser tous les équipements mis en place et de retourner facilement cette information.
+
+\section{L'analyse du besoin}
+
+Pour définir précisément les besoins du projet, une série de cas d'utilisation ont été rédigées avec l'équipe qui sera amener à l'utiliser. Toutes ces \emph{User Stories} ont été formalisées et sont décrites dans la pré-étude de ce projet dans la partie 2 "Analyses et planification". Elles ont été ensuite priorisée par la personne responsable de l'équipe qui est également le mandant de ce projet. Il a été convenu qu'une séance de revue sur l'avancement du projet soit faite toutes les deux semaines tout au long de la durée de la réalisation du projet. Les détails sur le déroulement du projet se trouvent au chapitre "Dossier de gestion".

chapitres/introduction/network.tex

@@ -11,7 +11,7 @@ Le but d'un réseau informatique et d'acheminer des données sous forme de paque
 
 Le modèle \gls{osi} est un découpage en  sept couches, représentant les différents acteurs nécessaires à l'échange et la compréhension de l'information.
 
-\begin{figure}[ht]
+\begin{figure}[h]
   \centering
   \includegraphics[width=100mm]{OSI_Model_v1.png}
   \caption{Le modèle OSI}
@@ -93,7 +93,7 @@ Ainsi le réseau \emph{192.168.1.0 255.255.255.0} peut s'écrire plus simplement
 
 Pour qu'un n\oe{}ud d'un sous réseau soit capable de communiquer avec un n\oe{}ud se trouvant dans un autre, il faut que le paquet soit \emph{routé} du sous réseau source vers celui de destination. Cette action est effectuée par des équipements qui s'appellent "router" et qui utilisent pour cela les tables de routage. Pour comprendre cela, il faut reprendre le schéma réseau de l'infrastructure de test.
 
-\begin{figure}[ht]
+\begin{figure}[h]
   \centering
   \includegraphics[width=\textwidth]{reseau_test}
   \caption{Schéma réseau de l'environnement de test}

chapitres/model/classes.tex

@@ -1,7 +1,26 @@
-\chapter{Les classes}
-\label{ch:classes}
+\chapter{Analyses statiques}
 
-\section{Credential}
+\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 \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 \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 \lstinline{Device} contient les autres objets qui lui sont associés.
+
+\begin{figure}[h]
+  \centering
+  \includegraphics[width=80mm]{mongodb_device}
+  \caption{Extrait de la collection Device}
+\end{figure}
+
+Cette structure est possible pour les objets qui n'ont de sens que dans le contexte d'un équipement spécifique, ce qui n'est pas le cas de tous. C'est notamment le cas de la classe \lstinline{Credential}, qui sauvegarde dans la base les identifiants nécessaires pour authentifier les requêtes sur les API des équipements. Ces informations peuvent être liées à plusieurs équipements différents et doivent donc être stockées dans une collection séparée.
+
+\begin{figure}[H]
+  \centering
+  \includegraphics[height=200mm]{pathecure_mld}
+  \caption{Diagramme de classes}
+\end{figure}
+
+\section{Classes}
+
+\subsection{Credential}
 
 Cette classe est utilisée pour sauvegarder les informations d'identifications pour accéder aux équipements et est identifiable par un nom unique. Le mot de passe est enregistré dans la base de donnée de façon chiffrée, mais avec un chiffrement symétrique, car il est nécessaire de pouvoir le réutiliser pour s'authentifier par la suite sur les équipements. Les fonctions pour chiffrer et déchiffrer le mot de passe sont fournit par l'attribut "password".
 
@@ -21,7 +40,7 @@ Cette classe est utilisée pour sauvegarder les informations d'identifications p
   end
 \end{lstlisting}
 
-\section{Address}
+\subsection{Address}
 \label{sec:classe:address}
 
 Il s'agit d'un élément d'une règle de sécurité (\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 \lstinline{start_ip} est la représentation numérique de la première adresse IP de ce réseau, et \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 (cité la doc réseau au début)), ces deux valeurs seront identiques. Ces dernières sont calculées à chaque modifications de l'attribut network.
@@ -36,38 +55,38 @@ Il s'agit d'un élément d'une règle de sécurité (\lstinline{Policy}) qui dé
   #   address.end_ip                      # => 3232235775
 \end{lstlisting}
 
-\section{AddressGroup}
+\subsection{AddressGroup}
 
 Un groupe d'adresse est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \lstinline{Address} qu'il contient.
 
-\section{PortRange}
+\subsection{PortRange}
 
 Un \lstinline{PortRange}, représente une plage de numéro de port et le protocol qui leur est associé. Il peut en plus également gérer une combinaison de code et type pour les communications ICMP. Il est contenu dans un \lstinline{Service}.
 
-\section{Service}
+\subsection{Service}
 \label{sec:classe:service}
 
 Un service est un élément d'une règle de sécurité (\lstinline{Policy}) qui est composé d'un ensemble de port/protocol nécessaire au fonctionnement d'une application. Par exemple, un service qui autoriserait les flux web (HTTP/HTTPS) va autoriser les ports TCP 80 et 443. Pour cela, il aura donc deux \lstinline{PortRange} liés.
 
 Il fournit également la méthode 'match?' qui va retourner 'true' si l'ensemble port/protocol en paramètre est inclus dans les \lstinline{PortRange} liés.
 
-\section{ServiceGroup}
+\subsection{ServiceGroup}
 
 Un groupe de service est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \lstinline{Address} qu'il contient.
 
-\section{Route}
+\subsection{Route}
 \label{sec:classe:route}
 
 Correspond à une route dans une table de routage d'un équipement réseau. (pti cf qui va bien). Elle est notamment caractérisée par le réseau de destination, lui aussi donné avec une notation \acrshort{cidr}. Comme pour les adresses réseaux (\lstinline{Address}), la première et la dernière adresse IP du réseau sont converties en décimal pour être indexées dans la base de donnée. Chaque \lstinline{Route} est reliée a une table de routage (\lstinline{RoutingTable}).
 
-\section{RoutingTable}
+\subsection{RoutingTable}
 \label{sec:classe:routingtable}
 
 La table de routage est un élément des équipement réseau et est composé de routes. 
 
 Elle fournit la méthode 'crossed?' (\nameref{sec:methodes:crossed}) qui permet de savoir si un équipement (\lstinline{Device}) est traversé par un flux définit par un réseau source et de destination.
 
-\section{Policy}
+\subsection{Policy}
 
 Une policy représente un règle de sécurité dans un équipement réseau. Elle décrit comme 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'adresses (section \ref{sec:classe:address}-\nameref{sec:classe:address}) ainsi que du protocol et de son numéro de port utilisé (représenté par le service (section \ref{sec:classe:service}-\nameref{sec:classe:service})), la règle va définir si la communication est autorisée où si elle doit être bloquée. 
 
@@ -75,6 +94,6 @@ La source et la destination sont deux champs qui peuvent contenir un ou plusieur
 
 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.
 
-\section{Device}
+\subsection{Device}
 
 Les équipements de sécurité gérés dans l'application sont des objets de type \lstinline{Devices}. Il s'agit de la classe principale de l'application étant donné que la plupart des autres objets dépendent directement d'un équipement. Il fournit la méthode \nameref{sec:methodes:matched_policies} qui permet de mettre en place la feature principale de l'application, soit la recherche de règles de sécurité. 

chapitres/model/diagram.tex

@@ -1,4 +1,4 @@
-\chapter{Analyses}
+\chapter{Analyses dynamiques}
 
 \section{Diagramme de séquence}
 

chapitres/model/methodes.tex

@@ -1,6 +1,6 @@
-\chapter{Les méthodes}
+\section{Méthodes}
 
-\section{route}
+\subsection{route}
 
 La méthode "route" retourne la route (\lstinline{Route}), utilisée par l'équipement (\lstinline{Device}) pour atteindre le réseau spécifié. 
 
@@ -17,7 +17,7 @@ La méthode "route" retourne la route (\lstinline{Route}), utilisée par l'équi
   end
 \end{lstlisting}
 
-\section{crossed?}
+\subsection{crossed?}
 \label{sec:methodes:crossed}
 
 La méthode "crossed?" est un élément essentiel pour l'analyse des règles de sécurité (\lstinline{Policy}). Elle permet de déterminer sur un équipement (\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 (\lstinline{RoutingTable}) de l'équipement en question et comparer l'interface de sortie des deux routes (Route) retourné. Si elles sont différentes, cela signifique que le flux traverse ce firewall.
@@ -36,5 +36,5 @@ La méthode "crossed?" est un élément essentiel pour l'analyse des règles de
     end
 \end{lstlisting}
 
-\section{matched\_policies}
+\subsection{matched\_policies}
 \label{sec:methodes:matched_policies}

chapitres/model/validation.tex

@@ -3,20 +3,42 @@
 
 Pour valider le bon fonctionnement de l'application et mettre en place l'intégration continue, différents modules sont utiliser pour tester les objets et méthodes ainsi que pour valider la syntaxe et l'indentation du code. 
 
-\section{Backend}
+\section{Javascript}
+
+\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 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.
+
+\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|}.
+
+\section{Ruby}
 
 \subsection{RSpec}
 
 RSpec\cite{rspec} est une solution qui propose un ensemble d'outils pour tester les applications Ruby et notamment celles créées avec Rails. Il va permettre de créer des objets et de vérifier leur validité ainsi que de tester le bon fonctionnement des méthodes. Cet outil est utilisé dans le backend mais également pour valider les deux modules d'accès aux équipements (paltogem et fortigem). Les fichiers qui concernent les tests RSpec se trouvent dans le dossier \Colorbox{light-gray}{\lstinline|spec/|} à la racine du projet.
 
+Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exec rspec spec/|} depuis la racine du projet. Il est aussi possible de ne lancer que certains tests en précisant le fichier de test dans la commande.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=100mm]{rspec_valid_tests}
+    \caption{Tests réussi avec RSpec}
+\end{figure}
+
 \subsection{Rubocop}
 
-RuboCop\cite{rubocop} est un analyseur de code Ruby et de syntaxe basé sur le \emph{Community Ruby 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 dans la documentation\cite{rubocopdoc}.
+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}.
+
+Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exec rubocop|} depuis la racine du projet.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=100mm]{rubocop_ok}
+    \caption{Validation Rubocop}
+\end{figure}
 
 \subsection{Brakeman}
 
-\section{Frontend}
-
-\subsection{QUnit}
-
-\subsection{ESLint}
+Brakeman\cite{brakeman} est également un analyseur de code mais qui va plutôt chercher des vulnérabilités et des problèmes de sécurité dans le code. Les tests se lancent avec la commande Colorbox{light-gray}{\lstinline|bundle exec brakeman|} depuis la racine du projet.

index.tex

@@ -85,57 +85,15 @@
 \pagenumbering{arabic}
 \part{Introduction}
 \include{chapitres/introduction/introduction}
-% Introduction
-%   Présentation de l'entreprise
-%   Contexte
-%   Problématiques
-
-% \part{Les fondamentaux des réseaux informatiques}
 \include{chapitres/introduction/network}
-% Les fondamentaux des réseaux informatiques
-%   Introduction
-%   Le modèle OSI
-%   Les réseaux IP
-%   Les protocoles de transports
-%   Les firewall
 
-\part{Outils et technologies}
-\include{chapitres/outiltech/outils}
-\include{chapitres/outiltech/technologies}
+\part{Analyses et réalisation}
 \include{chapitres/requis/technique}
-% Outils et technologies
-%   Outils
-%       Gitlab
-%       Git Kraken
-%       VS code
-%       Postman
-%   Technologies
-%       Rails
-%       Ruby
-%       EmberJS
-%       Javascript
-%       MongoDB
-%       Sidekiq/Redis
-%       LaTeX
+\include{chapitres/model/validation}
 
-\part{Méthodologies et développement}
 \include{chapitres/model/classes}
 \include{chapitres/model/methodes}
-\include{chapitres/model/db}
 \include{chapitres/model/diagram}
-\include{chapitres/model/validation}
-% Méthodologies et développement
-%   Gestion de projet
-%       Agile/scrum
-%       Issue/Merge request
-%   Développement
-%       Git flow
-%       Design patern
-%       TDD
-%       CI/CD
-%       Analyse de code (Rubocop + Brakeman)
-%       Standards (JsonAPI)
-%       Optimisations et benchmark
 
 \part{Dossier de gestion}
 % Dossier de gestion