146 lines
11 KiB
TeX
146 lines
11 KiB
TeX
\chapter{Analyses statiques}
|
|
|
|
\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.
|
|
|
|
\vspace{3mm}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=80mm]{mongodb_device}
|
|
\caption{Extrait de la collection Device}
|
|
\end{figure}
|
|
\vspace{3mm}
|
|
|
|
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 \Colorbox{light-gray}{\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'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"]
|
|
# Returns the decrypted value of the 'encrypted_password' field
|
|
def password
|
|
@password = SymmetricEncryption.decrypt(encrypted_password)
|
|
end
|
|
|
|
# Encrypt the clear text password and set the 'encrypted_password' field.
|
|
#
|
|
# Params:
|
|
# * new_password: the new value of the password
|
|
def password=(new_password)
|
|
@password = SymmetricEncryption.encrypt(new_password)
|
|
self.encrypted_password = @password
|
|
end
|
|
\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 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), 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"]
|
|
# Exemples:
|
|
#
|
|
address = Address.new
|
|
address.name = 'unique name' # => true
|
|
address.network = '192.168.0.0/24' # => true
|
|
address.start_ip # => 3232235520
|
|
address.end_ip # => 3232235775
|
|
\end{lstlisting}
|
|
\vspace{3mm}
|
|
|
|
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"]
|
|
def match?(network)
|
|
ip = IPAddr.new network
|
|
start_ip = ip.to_range.first.to_i
|
|
end_ip = ip.to_range.last.to_i
|
|
|
|
((start_ip >= self.start_ip) && (end_ip <= self.end_ip))
|
|
end
|
|
\end{lstlisting}
|
|
|
|
\subsection{AddressGroup}
|
|
|
|
Un groupe d'adresse est simplement un objet dont l'attribut 'addresses' contient le nom de toutes les \Colorbox{light-gray}{\lstinline|Address|} qu'il contient.
|
|
|
|
\subsection{PortRange}
|
|
|
|
Un \Colorbox{light-gray}{\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 \Colorbox{light-gray}{\lstinline|Service|}.
|
|
|
|
\subsection{Service}
|
|
\label{sec:classe:service}
|
|
|
|
Un service est un élément d'une règle de sécurité (\Colorbox{light-gray}{\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 \Colorbox{light-gray}{\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 \Colorbox{light-gray}{\lstinline|PortRange|} liés.
|
|
|
|
\vspace{3mm}
|
|
\begin{lstlisting}[language=Ruby, title="app/model/service.rb"]
|
|
def match?(protocol, port)
|
|
match = false
|
|
|
|
port_ranges.each do |port_range|
|
|
match = true if (protocol == port_range.protocol) &&
|
|
(port >= port_range.start_port) &&
|
|
(port <= port_range.end_port)
|
|
end
|
|
|
|
match
|
|
end
|
|
\end{lstlisting}
|
|
|
|
\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.
|
|
|
|
\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.
|
|
|
|
\subsection{Route}
|
|
\label{sec:classe:route}
|
|
|
|
Correspond à une route dans une table de routage d'un équipement réseau (comme décrit à la section \ref{subsec:network:ip:routing}). 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 (\Colorbox{light-gray}{\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 \Colorbox{light-gray}{\lstinline|Route|} est reliée a une table de routage (\Colorbox{light-gray}{\lstinline|RoutingTable|}).
|
|
|
|
\subsection{RoutingTable}
|
|
\label{sec:classe:routingtable}
|
|
|
|
La table de routage est un élément des équipement réseaux et est composée de routes. Elle fournit la méthode 'crossed?' (section \ref{sec:methodes:crossed}) qui permet de savoir si un équipement (\Colorbox{light-gray}{\lstinline|Device|}) est traversé par un flux définit par un réseau source et de destination.
|
|
|
|
\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.
|
|
|
|
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}(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é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.
|