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

avance reseau, requis et model

Browse Source
This commit is contained in:
Etienne Ischer
2018-09-15 19:38:30 +02:00
parent a4b606477a
commit 9deb1d806a
5 changed files with 138 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

54
bibli.bib
View File

@@ -99,3 +99,57 @@
title = {Wikipedia, The Free Encyclopedia},
note = {URL: "\url{https://www.gitkraken.com/}"}
}
@misc{jsonapi,
author = {Json Api},
title = {A specification for building apis in Json},
note = {URL: "\url{http://jsonapi.org/}"}
}
@misc{activemodelserializer,
author = {rails},
title = {ActiveModelSerializers brings convention over configuration to your JSON generation},
note = {URL: "\url{https://github.com/rails-api/active_model_serializers/tree/0-10-stable}"}
}
@misc{dsjsonapiserializer,
author = {ActiveModelSerializers},
title = {Ember Data 2.0 Serializer},
note = {URL: "\url{https://www.emberjs.com/api/ember-data/release/classes/DS.JSONAPISerializer}"}
}
@misc{mongoid,
author = {mongoDB},
title = {Ruby ODM framework for MongoDB},
note = {URL: "\url{https://github.com/mongodb/mongoid}"}
}
@misc{rspec,
author = {RSpec},
title = {Behaviour Driven Development for Ruby. Making TDD Productive and Fun.},
note = {URL: "\url{http://rspec.info/}"}
}
@misc{rubocop,
author = {RuboCop},
title = {A Ruby static code analyzer and formatter, based on the community Ruby style guide.},
note = {URL: "\url{https://github.com/rubocop-hq/rubocop}"}
}
@misc{rubocopdoc,
author = {RuboCop},
title = {Documentation for the RuboCop project},
note = {URL: "\url{http://docs.rubocop.org/en/latest/}"}
}
@misc{rubystyleguide,
author = {RuboCop},
title = {A community-driven Ruby coding style guide},
note = {URL: "\url{https://github.com/rubocop-hq/ruby-style-guide}"}
}
@misc{railsstyleguide,
author = {RuboCop},
title = {A community-driven Ruby on Rails style guide },
note = {URL: "\url{https://github.com/rubocop-hq/rails-style-guide}"}
}

19
chapitres/introduction/network.tex
View File

@@ -142,20 +142,23 @@ schéma ouverture de connexion.
\subsection{Firewall}
\label{subsec:network:ip:firewall}
Les firewall sont des routers qui sont également capable de gérer les éléments de la couche quatre. Ils sont utilisés pour filtrer les communications entre les réseaux en filtrant les échanges basé sur les ports destinations. Ces équipements de sécurité permettent donc de n'autoriser que les paquets à destination d'un n\oe{}ud spécifique et sur un ou plusieurs ports. Ces filtres sont représenté par des règles de sécurité qui correspondent ici à la classe \Colorbox{light-gray}{\lstinline{Policy}}.
Les firewall sont des routers qui sont également capable de gérer les protocoles de la couche quatre. Ils sont utilisés pour filtrer les communications entre les réseaux en filtrant les échanges basé sur les ports destinations. Ces équipements de sécurité permettent donc de n'autoriser que les paquets à destination d'un n\oe{}ud spécifique et sur un ou plusieurs ports. Ces filtres sont représentés par des règles de sécurité qui correspondent ici à la classe \Colorbox{light-gray}{\lstinline{Policy}}.
\begin{table}[H]
\centering
\caption{Exemples de règles de sécurité}
\label{rules-tab}
\begin{tabular}{|l|l|l|l|l|}
\begin{tabular}{|l|l|l|l|l|l|l|}
\hline
\small{\textbf{Id}} &\small{\textbf{Source}} &\small{\textbf{Destination}} &\small{\textbf{Service}} &\small{\textbf{Action}} \\ \hline
1 & \small{192.168.1.0/24} & \small{10.0.1.1/32} & \small{tcp/22} & \cellcolor[HTML]{FE0000}\small{Deny} \\ \hline
2 & \small{192.168.1.0/24} & \small{10.0.1.2/32} & \small{tcp/80, tcp/443} & \cellcolor[HTML]{009901}\small{Accept} \\ \hline
3 & \small{192.168.1.0/24} & \small{10.0.1.0/24} & \small{tcp/3389} & \cellcolor[HTML]{009901}\small{Accept} \\ \hline
4 & \small{10.0.1.2/24} & \small{192.168.1.0/24} & \small{any} & \cellcolor[HTML]{009901}\small{Accept} \\ \hline
5 & \small{10.0.1.2/24} & \small{0.0.0.0/0} & \small{any} & \cellcolor[HTML]{FE0000}\small{Deny} \\ \hline
\small{\textbf{Id}} &\small{\textbf{Int. source}} &\small{\textbf{Int. destination}} &\small{\textbf{Source}} &\small{\textbf{Destination}} &\small{\textbf{Service}} &\small{\textbf{Action}} \\ \hline
1 & \small{client} & \small{server} & \small{192.168.1.0/24} & \small{10.0.1.1/32} & \small{tcp/22} & \cellcolor[HTML]{FE0000}\small{Deny} \\ \hline
2 & \small{client} & \small{server} & \small{192.168.1.0/24} & \small{10.0.1.2/32} & \small{tcp/80, tcp/443} & \cellcolor[HTML]{009901}\small{Accept} \\ \hline
3 & \small{client} & \small{server} & \small{192.168.1.0/24} & \small{10.0.1.0/24} & \small{tcp/3389} & \cellcolor[HTML]{009901}\small{Accept} \\ \hline
4 & \small{server} & \small{client} & \small{10.0.1.2/24} & \small{192.168.1.0/24} & \small{any} & \cellcolor[HTML]{009901}\small{Accept} \\ \hline
5 & \small{server} & \small{client} & \small{10.0.1.2/24} & \small{0.0.0.0/0} & \small{any} & \cellcolor[HTML]{FE0000}\small{Deny} \\ \hline
\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ègles 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{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.

22
chapitres/model/validation.tex Normal file
View File

@@ -0,0 +1,22 @@
\chapter{Tests et validations}
\label{ch:tests}
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}
\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.
\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}.
\subsection{Brakeman}
\section{Frontend}
\subsection{QUnit}
\subsection{ESLint}

48
chapitres/requis/technique.tex Normal file
View File

@@ -0,0 +1,48 @@
\chapter{Requis techniques}
\section{Architecture et communications}
L'application est construite selon une architecture trois tiers qui va séparer la partie interface utilisateur de la partie traitement et des données. La couche de présentation sera appelée par la suite \emph{frontend} et celle de traitement \emph{backend}. Pour échanger des informations entre eux, ces tiers doivent utiliser des protocoles et un formatage précis.
Schéma architecture
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 et du coté frontend par EmberJS. Pour se comprendre, ces deux librairies respectent le même standard pour sérialiser l'information. Il s'agit de la spécification 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:
\vspace{3mm}
\begin{table}[H]
\centering
\caption{Technologies et versions}
\label{require-tab-techno}
\begin{tabular}{|l|l|l|}
\hline
\textbf{Nom} & \textbf{Version} & \textbf{Description} \\ \hline
Ruby & 3.4 & Interpréteur Ruby \\ \hline
Bundler & 1.16.1 & Gestionnaire de dépendances pour Ruby \\ \hline
Rails & 5.1.6 & Framework pour l'application backend \\ \hline
NodeJS & 8.1 & Moteur pour application Javascript \\ \hline
NPM & ? & Gestionnaire de dépendance de NodeJS \\ \hline
Ember-CLI & 3.3.0 & Framework pour l'application frontend \\ \hline
MongoDB & ? & Système de base de donnée non-relationnel \\ \hline
Redis & ? & Base de donnée en mémoire \\ \hline
\end{tabular}
\end{table}
\vspace{3mm}
Les dépendances précises se trouvent dans des fichiers différents en fonction du projet:
\begin{itemize}
\item Paltogem: \lstinline|/paltogem.gemspec|
\item Fortigem: \lstinline|/fortigem.gemspec|
\item Backend: \lstinline|/Gemfile|
\item Frontend: \lstinline|/package.json|
\end{itemize}
\vspace{5mm}
\section{Hébergement}

2
index.tex
View File

@@ -102,6 +102,7 @@
\part{Outils et technologies}
\include{chapitres/outiltech/outils}
\include{chapitres/outiltech/technologies}
\include{chapitres/requis/technique}
% Outils et technologies
% Outils
% Gitlab
@@ -122,6 +123,7 @@
\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