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-25 10:44:44 +02:00
parent 61109bf65f
commit c960554837
18 changed files with 39 additions and 39 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
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 \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}

2
chapitres/model/methodes.tex
View File

@@ -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:

6
chapitres/model/validation.tex
View File

@@ -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.