dainii/heig-rapport-tb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Corrections diverses

Browse Source
This commit is contained in:
Etienne Ischer
2018-09-21 17:33:52 +02:00
parent c16079f60e
commit 61109bf65f
10 changed files with 42 additions and 41 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
chapitres/model/classes.tex
View File

@@ -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 \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 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.
\vspace{3mm}
\begin{figure}[h]
@@ -24,7 +24,7 @@ Cette structure est possible pour les objets qui n'ont de sens que dans le conte
\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".
Cette classe est utilisée pour sauvegarder les informations d'identification 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".
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/credential.rb"]
@@ -44,13 +44,13 @@ Cette classe est utilisée pour sauvegarder les informations d'identifications p
\end{lstlisting}
\vspace{3mm}
Les méthodes pour chiffrer et déchiffrer les mots de passe sont fournit par le module "Symmetric\-Encryption"\cite{symmetricencryption}. Ce dernier utilise un système de clés pour cela qui sont définies dans le fichier "backend/config/symmetric-encryption.yml". Ce fichier est volontairement exclu de Git afin que les clés ne se retrouve pas dans le dépot. Lors du premier développement, il faut générer un jeu de clés avec la commande précisée dans le "README.md" du projet. En production, le fichier doit être généré sur le serveur et utilise des mécanismes plus avancés pour assurer un meilleur niveau de chiffrement.
Les méthodes pour chiffrer et déchiffrer les mots de passe sont fournit par le module "Symmetric\-Encryption"\cite{symmetricencryption}. Ce dernier utilise un système de clés pour cela qui sont définies dans le fichier "backend/config/symmetric-encryption.yml". Ce fichier est volontairement exclu de Git afin que les clés ne se retrouve pas dans le dépot. Lors du premier lancement de l'application, il faut générer un jeu de clés avec la commande précisée dans le "README.md" du projet. En production, le fichier doit être généré sur le serveur et utilise des mécanismes plus avancés pour assurer un meilleur niveau de chiffrement.
\newpage
\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 (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.
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.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/address.rb"]
@@ -64,7 +64,7 @@ Il s'agit d'un élément d'une règle de sécurité (\Colorbox{light-gray}{\lsti
\end{lstlisting}
\vspace{3mm}
Cette classe fournit également la méthode match? (section ) qui permet de savoir si un réseau exprimé au format \acrshort{cidr} est contenu dans l'objet en question. Pour cela, il suffit de vérifier que les adresses limites du réseau en paramètre soient comprises dans l'objet en question.
Cette classe fournit également la méthode \Colorbox{light-gray}{\lstinline|match?|} qui permet de savoir si un réseau exprimé au format \acrshort{cidr} est contenu dans l'objet en question. Pour cela, il suffit de vérifier que les adresses limites du réseau en paramètre sont comprises dans l'objet en question.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/address.rb"]
@@ -109,7 +109,7 @@ 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 'addresses' contient le nom de toutes les \Colorbox{light-gray}{\lstinline|Address|} qu'il contient.
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.
\subsection{Zone}
@@ -128,18 +128,18 @@ 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é 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 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.
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 arriver 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|}.
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.
\subsection{Device}
Les équipements de sécurité gérés dans l'application sont des objets de type \Colorbox{light-gray}{\lstinline|Device|}. 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é.
Les équipements de sécurité gérés dans l'application sont des objets de type \Colorbox{light-gray}{\lstinline|Device|}. 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}(section \ref{sec:methodes:matched_policies}) qui permet de mettre en place la fonctionnalité principale de l'application, soit la recherche de règles de sécurité.
\subsection{Task}
Afin que les informations de configurations des équipements puissent être récupérées régulièrement, cela se fait sous forme de tâche qui vont être exécuter de façon asynchrone par le module Sidekiq\cite{sidekiq}. Une fois une tache valide créée, l'application va l'ajouter en file d'attente pour qu'elle soit ensuite traitée par le programme d'exécution qui tourne en parallèle. Les différents files sont gérées avec le système de base de donnée en mémoire Redis\cite{redis}.
Afin que les informations de configurations des équipements puissent être récupérées régulièrement, cela se fait sous forme de tâche qui vont être exécuter de façon asynchrone par le module Sidekiq\cite{sidekiq}. Une fois une tache valide créée, l'application va l'ajouter en file d'attente pour qu'elle soit ensuite traitée par le programme d'exécution qui tourne en parallèle. Les différentes files sont gérées avec le système de base de donnée en mémoire Redis\cite{redis}.
Il existe deux taches différentes, la \Colorbox{light-gray}{\lstinline|PolicyRetrievalJob|} et \Colorbox{light-gray}{\lstinline|RoutingTableRetrievalJob|}. La première va s'occuper de récupérer sur les équipements les polices de sécurité ainsi que les objets qui les composent. La seconde va obtenir l'état actuel de la table de routage de l'équipement pour mettre à la base. Ces deux tâches sont séparées afin de pouvoir les exécuter indépendament l'une de l'autre. En pratique, la table de routage d'un équipement peut évoluer sans intervention humaine, on souhaite donc pouvoir la mettre à jour plus fréquement que pour les règles de sécurité qui elles ne changent que lorsqu'une modification est faite.

6
chapitres/model/methodes.tex
View File

@@ -2,7 +2,7 @@
\subsection{route}
La méthode "route" retourne la route (\Colorbox{light-gray}{\lstinline|Route|}), utilisée par l'équipement (\Colorbox{light-gray}{\lstinline|Device|}) pour atteindre le réseau spécifié. C'est une mise en application de ce qui est expliqué dans la section \ref{subsec:network:ip:routing}. Pour y arriver, il faut donc obtenir ceux dont les adresses limites du réseau comprennent celle du réseau voulu.
La méthode "route" retourne la route (\Colorbox{light-gray}{\lstinline|Route|}), utilisée par l'équipement (\Colorbox{light-gray}{\lstinline|Device|}) pour atteindre le réseau spécifié. C'est une mise en application de ce qui est expliqué dans la section \ref{subsec:network:ip:routing}. Pour y arriver, il faut donc obtenir celles dont les adresses limites du réseau comprennent celle du réseau voulu.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/routing\_table.rb"]
@@ -19,7 +19,7 @@ La méthode "route" retourne la route (\Colorbox{light-gray}{\lstinline|Route|})
\end{lstlisting}
\vspace{3mm}
Une fois les routes possibles obtenues, il faut encore isolé celle qui est la plus précise. Pour cela, il suffit de calculer le nombre d'adresses maximum disponibles dans le réseau et de choisir celui qui en a le moins.
Une fois les routes possibles obtenues, il faut encore isoler celle qui est la plus précise. Pour cela, il suffit de calculer le nombre d'adresses disponibles dans le réseau et de choisir celle qui en a le moins.
\vspace{3mm}
\begin{lstlisting}[language=Ruby, title="app/model/routing\_table.rb"]
@@ -116,4 +116,4 @@ Le but ici est de faire la requête de recherche et de retourner toutes les règ
end
\end{lstlisting}
La requête sur la base de donnée qui permet d'obtenir les règles de sécurité voulues est définie dans la fonction ci-dessous. Pour cela, il faut commencer par isoler les adresses source et destination ainsi que les services. On cherche ici à comparer des tableaux de String entre eux et à savoir si au moins un des éléments de ce tableau se retrouvent dans l'autre tableau. La méthode utilisée pour cela est "any\_in"\cite{stackanyin} en lui précisant les paramètres.
La requête sur la base de donnée qui permet d'obtenir les règles de sécurité voulues est définie dans la fonction ci-dessus. Pour cela, il faut commencer par isoler les adresses source et destination ainsi que les services. On cherche ici à comparer des tableaux de String entre eux et à savoir si au moins un des éléments de ce tableau se retrouvent dans l'autre tableau. La méthode utilisée pour cela est "any\_in"\cite{stackanyin} en lui précisant les paramètres.

4
chapitres/model/validation.tex
View File

@@ -7,7 +7,7 @@ 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 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'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.
\subsection{ESLint}
@@ -41,4 +41,4 @@ Les tests se lancent avec la commande \Colorbox{light-gray}{\lstinline|bundle ex
\subsection{Brakeman}
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.
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 depuis la racine du projet avec la commande \Colorbox{light-gray}{\lstinline|bundle exec brakeman|}.