DIIAGE: Préparation session 20171208
This commit is contained in:
parent
e3e4b6291f
commit
8085490457
|
|
@ -0,0 +1,68 @@
|
|||
<style>
|
||||
* {
|
||||
font-size: 0.9em !important;
|
||||
}
|
||||
</style>
|
||||
|
||||
# Modélisation de menace: QCM
|
||||
|
||||
- **Nom**
|
||||
- **Prénom**
|
||||
- **Classe**
|
||||
- **Date**
|
||||
|
||||
## Consigne
|
||||
|
||||
Pour chaque question, entourer **la ou les bonnes réponses**.
|
||||
|
||||
**Attention**, certaines questions sont volontairement rédigées sous la forme plurielle. Cela n'implique pas forcément qu'il y a plusieurs bonnes réponses.
|
||||
|
||||
## Questions
|
||||
|
||||
### A. Quels sont les objectifs de la modélisation de menace ?
|
||||
|
||||
1. Apporter une approche systématique de la sécurité dans le processus de conception de systèmes d'information.
|
||||
2. Identifier les composants nécessitant le plus d'attention de la part des développeurs/responsables opérationnels.
|
||||
3. Permettre d'aborder la sécurité en amont de la conception afin d'évacuer toutes les questions de sécurité lors du cycle de vie de l'application.
|
||||
|
||||
### B. Quelle est la première étape du processus de modélisation de menace ? _(une seule bonne réponse)_
|
||||
|
||||
1. Audit du code
|
||||
2. Identification des menaces
|
||||
3. Décomposition l'environnement applicatif
|
||||
|
||||
### C. La catégorisation des menaces est nécessaire car:
|
||||
|
||||
1. Elle permet aux développeurs d'associer à celle ci rapidement des mesures de mitigations identifiées et fiables
|
||||
2. Elle permet aux développeurs d'utiliser des outils de protection automatique en fonction de la catégorie de la menace identifiée
|
||||
3. Elle permet aux développeurs d'employer un vocabulaire commun pour discuter des problèmes de sécurité lié à la menace
|
||||
|
||||
### D. Parmi ces propositions, lesquelles sont des catégories proposées par la méthodologie de classification STRIDE ?
|
||||
|
||||
1. Falsification des données
|
||||
2. Déni de service
|
||||
3. Élévation de privilèges
|
||||
|
||||
### E. Dans la modélisation de menace, qu'identifient les "dépendances externes" ?
|
||||
|
||||
1. Les composants externes au code dont l'application dépend
|
||||
2. Les acteurs externes non identifiés par le modèle de menace
|
||||
3. Les contraintes techniques externes nécessaires au bon fonctionnement de l'application
|
||||
|
||||
### F. Dans la modélisation de menace, qu'identifient les "points d'entrée" ?
|
||||
|
||||
1. Les interfaces permettant à l'utilisateur d'interagir avec l'application et/ou d'y insérer des données
|
||||
2. Les seuils d'authentification de l'application
|
||||
3. Le nombre de requêtes moyen effectués sur une page d'une application
|
||||
|
||||
### G. Dans la modélisation de menace, qu'identifient les "niveaux de confiance" ?
|
||||
|
||||
1. Les différents acteurs pouvant interagir avec l'application et leurs accréditations
|
||||
2. Le niveau de chiffrement dans un secteur de l'application
|
||||
3. Le niveau de fiabilité des données de l'application dans un contexte donné
|
||||
|
||||
### H. Dans la modélisation de menace, à quoi sert la modélisation des flux de données ?
|
||||
|
||||
1. Identifier les échanges entre les différents composants
|
||||
2. Identifier les seuils de changement de niveau de confiance
|
||||
3. Identifier les goulots d'étranglement potentiels pour les performances
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# Ressources
|
||||
|
||||
- http://www.ulb.ac.be/di/info-f-405/enonce/TP3_ThreatModeling.pdf
|
||||
- https://www.sans.org/reading-room/whitepapers/securecode/threat-modeling-process-ensure-application-security-1646
|
||||
- https://msdn.microsoft.com/en-us/library/ff649461.aspx
|
||||
- https://msdn.microsoft.com/en-us/library/ff648644.aspx
|
||||
- https://www.owasp.org/index.php/Application_Threat_Modeling
|
||||
|
|
@ -0,0 +1,59 @@
|
|||
# TP - Conception applicative et réalisation d'un modèle de menace
|
||||
|
||||
## Objectifs
|
||||
|
||||
- Concevoir un environnement applicatif en fonction d'un cahier des charges en intégrant la sécurité dès l'amorçage du projet.
|
||||
|
||||
## Contexte et contraintes
|
||||
|
||||
Soit le cahier des charges suivant:
|
||||
|
||||
> World Express, société de logistique/transport international
|
||||
souhaite revoir ses services numériques proposés à ses employés et clients.
|
||||
>
|
||||
> Notamment, elle souhaite proposer un service permettant d'effectuer un meilleur suivi des marchandises qu'elle achemine.
|
||||
>
|
||||
> **Fonctionnalités attendues**
|
||||
>
|
||||
> * Une application web de supervision accessible en "extranet" (**via Internet, sans VPN**) permettant aux **gestionnaires** d'effectuer le suivi des colis entreposées/en cours de transport.
|
||||
> * Une application mobile permettant aux **transporteurs** d'entrer le code d'identification du colis à l'embarquement et de renseigner quotidiennement leur position afin d'effectuer le suivi d'acheminement. Cette position doit pouvoir être entrée manuellement en cas de mauvais fonctionnement du système GPS du terminal mobile.
|
||||
> * Un service de notification automatique **par SMS** aux **clients** quand leur colis arrive près de chez eux.
|
||||
>
|
||||
> **Entités identifiées**
|
||||
>
|
||||
> - **Colis** Un "colis" représente un paquet/caisse de transport/conteneur identifié dans le système d'information de World Express. Chaque "colis" a un destinataire unique et est identifié par un code unique. Chaque colis a un statut qui peut être soit "en entrepot" ou "en transport" et une position GPS.
|
||||
> - **Client** Un "client" représente une entreprise utilisatrice du service de logistique proposé par la société World Express. Outre un nom, un client est également associé à une position GPS correspondant à l'adresse de livraison des colis pour l'entreprise.
|
||||
> - **Salarié** Un "salarié" représente un employé de la société World Express. Outre son couple identifiant/mot de passe, il est également associé à un rôle qui définit ses droits d'accès dans le système d'information de World Express.
|
||||
>
|
||||
> **Rôles identifiés**
|
||||
>
|
||||
> - **Gestionnaire** Ce rôle donne accès à l'application web de supervision. Il permet de créer/modifier les clients enregistrés dans le système d'information et de visualiser les statut/position des colis gérés par World Express.
|
||||
> - **Transporteur** Ce rôle donne accès à l'application mobile de suivi des colis. Il permet de modifier le statut et la position des colis présents dans le système d'information de World Express. Ces opérations ne sont possibles que depuis l'application mobile.
|
||||
> - **Administrateur** Ce rôle permet de faire toutes les actions possibles pour les rôles "gestionnaire" et "transporteur". Il permet également d'ajouter/modifier/supprimer des salariés dans l'application web de supervision.
|
||||
>
|
||||
> **Contraintes techniques**
|
||||
>
|
||||
> - World Express comporte déjà un annuaire de type OpenLDAP/Active Directory au sein de son infrastructure sur lesquels s'authentifient les salariés. Le serveur hébergeant ce service **se situe dans l'intranet** de la société. Elle souhaiteraient que les salariés puissent utiliser ces mêmes identifiants sur les nouvelles applications.
|
||||
> - World Express ne comporte pas d'infrastructure permettant d'envoyer des SMS et ne souhaite pas avoir à gérer cette partie. Elle est prête à utiliser un service externe pour cela.
|
||||
|
||||
Proposer une architecture logicielle répondant aux besoins exprimés et écrire le document de modélisation de la menace associé.
|
||||
|
||||
_Le cahier des charges étant succinct et factice, ne vous focalisez pas sur les détails fonctionnels. Analysez plutôt les contraintes techniques et fonctionnelles explicitement définies. Mais si certains détails vous bloquent réellement pour avancer, n'hésitez pas à me poser la question._
|
||||
|
||||
## Production attendue
|
||||
|
||||
* Un document de conception décrivant l'architecture logicielle proposée pour répondre au cahier des charges. Ce document devra identifier:
|
||||
- Les briques techniques utilisées (serveurs avec services hébergés, bases de données, etc) et/ou services distants utilisés
|
||||
- Les technologies (langages) utilisées sur chacune des applications à implémenter
|
||||
|
||||
_Ne perdez pas trop de temps sur cette partie. Une grande partie devrait être redondante avec votre document de modélisation de la menace. Le document de conception me permettra principalement de comprendre comment vous avez conçu votre architecture logicielle._
|
||||
|
||||
* Le document de modélisation de la menace associé à votre document de conception.
|
||||
|
||||
## Ressources
|
||||
|
||||
- [Présentation de Naïm Qachri & Frédéric Pluquet (ULB) sur la modélisation de menace](http://www.ulb.ac.be/di/info-f-405/enonce/TP3_ThreatModeling.pdf)
|
||||
- [Livre blanc sur la modélisation de menace (en anglais)](https://www.sans.org/reading-room/whitepapers/securecode/threat-modeling-process-ensure-application-security-1646)
|
||||
- [Web Application Security Frame - Microsoft - Grille de catégorisation des menaces ](https://msdn.microsoft.com/en-us/library/ff649461.aspx) _Déprécié mais le contenu reste d'actualité sur beaucoup de points_
|
||||
- [Threat Modeling - Microsoft](https://msdn.microsoft.com/en-us/library/ff648644.aspx) _Idem_
|
||||
- [Threat Modeling - OWASP](https://www.owasp.org/index.php/Application_Threat_Modeling)
|
||||
|
|
@ -13,7 +13,7 @@
|
|||
|
||||
## Consigne
|
||||
|
||||
Pour chaque question, entourer **la ou les bonnes réponses, si il y en a**.
|
||||
Pour chaque question, entourer **la ou les bonnes réponses**.
|
||||
|
||||
**Attention**, certaines questions sont volontairement rédigées sous la forme plurielle. Cela n'implique pas forcément qu'il y a plusieurs bonnes réponses.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Pour chaque question, entourer **la ou les bonnes réponses, si il y en a**.
|
|||
### G. Quelle est la plus-value apportée par le fichier `Dockerfile` à l'écosystème Docker ?
|
||||
|
||||
1. Il permet de construire de manière normalisée et reproductible une image d'un conteneur
|
||||
2. Il permet de partager partager simplement la "recette" de création d'une image
|
||||
2. Il permet de partager simplement la "recette" de création d'une image
|
||||
3. Il permet d'automatiser la configuration du réseau de fonctionnement du conteneur
|
||||
|
||||
### H. La gestion du réseau par défaut dans Docker s'effectue avec:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,24 @@
|
|||
#!/usr/bin/env bash
|
||||
|
||||
#
|
||||
# Exemple d'usage: ./start-minio.sh minio1 9001 minio1 minio2 minio3 minio4
|
||||
#
|
||||
|
||||
set -x
|
||||
|
||||
NAME=$1
|
||||
PORT=$2
|
||||
LINKS=${@:3}
|
||||
|
||||
# docker network create --driver bridge minio
|
||||
|
||||
DOCKER_ARGS="--rm -p ${PORT}:9000 --name ${NAME} --network bridge"
|
||||
DOCKER_ARGS="${DOCKER_ARGS} -e MINIO_ACCESS_KEY=access_key"
|
||||
DOCKER_ARGS="${DOCKER_ARGS} -e MINIO_SECRET_KEY=secret_key"
|
||||
DOCKER_ARGS="${DOCKER_ARGS} minio/minio server"
|
||||
|
||||
for l in ${LINKS}; do
|
||||
DOCKER_ARGS="${DOCKER_ARGS} http://${l}/data/"
|
||||
done
|
||||
|
||||
docker run ${DOCKER_ARGS}
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
# TP - Utilisation de l'API Docker pour monter un cluster Minio
|
||||
|
||||
## Objectifs
|
||||
|
||||
- Comprendre et utiliser une API REST
|
||||
- Créer un outil facilitant la manipulation d'un service via son API REST
|
||||
- S'initier à la conteneurisation avec Docker
|
||||
- S'initier à la création de grappes applicatives avec Minio
|
||||
|
||||
## Contexte et contraintes
|
||||
|
||||
- La distribution cible est une Ubuntu Server 16.04.3 LTS (amd64)
|
||||
- Utilisation de [Docker CE](https://docs.docker.com/) et de l'image `minio/minio`
|
||||
|
||||
|
||||
### Qu'est ce que Minio ?
|
||||
|
||||
[Minio](https://minio.io/) est une application répliquant les fonctionnalités du service Amazon S3, solution de stockage de fichiers dans le "cloud".
|
||||
|
||||
Contrairement à Amazon S3, il est possible d'installer Minio sur ses propres serveurs et surtout de mettre en place sa propre "grappe" applicative afin de créer un service de stockage redondé.
|
||||
|
||||
L'utilisation de Minio est intéressante puisque la plupart des applications faisant un fort usage du stockage de fichiers sont compatibles Amazon S3. Minio permet alors d'installer ces applications dans son infrastructure tout en gardant son indépendance vis à vis de la plateforme Amazon.
|
||||
|
||||
## Production attendue
|
||||
|
||||
_Ceci est un TP d'implémentation. Vous devez fournir à la fin de la période au minimum un code fonctionnel, même partiel._
|
||||
|
||||
_Le TP étant complexe, le TD suivant sera consacré à vous aider à prendre en main Docker et à aborder les notions de stockage distribué, très importantes dans le secteur du "Big Data"._
|
||||
|
||||
### Étapes
|
||||
|
||||
1. Dans une machine virtuelle, installer la distribution Ubuntu Server 16.04.
|
||||
2. Installez Docker sur votre machine virtuelle.
|
||||
3. Récupérer l'image Docker `minio/minio`
|
||||
4. Lancer un conteneur `minio` en suivant la documentation, se connecter à l'interface web pour se familiariser avec l'application.
|
||||
|
||||
_À la fin du temps du TP en autonomie, vous devriez au minimum avoir passé l'étape 4._
|
||||
|
||||
5. Via les commandes Docker et en suivant la documentation du site, monter une infrastructure multi-conteneurs distribuée d'instances Minio.
|
||||
|
||||
Pour vous faciliter le travail, sachez qu'il vous faudra créer un "network" dédié à votre groupe de conteneurs afin qu'ils puissent communiquer entre eux. La démarche est la suivante:
|
||||
- Créer le réseau dédié à vos conteneurs: `docker network create minio-net`
|
||||
- Dans chaque commande `docker run` que vous utiliserez pour lancer vos conteneurs, ajoutez le drapeau `--network minio-net` pour que ceux ci se retrouve dans le bon réseau.
|
||||
|
||||
6. Tester un appel à l'API sur le socket Unix du service Docker avec `curl`
|
||||
|
||||
```bash
|
||||
curl -v --unix-socket "/var/run/docker.sock" "http:/containers/json"
|
||||
```
|
||||
Cet appel devrait vous retourner la liste des conteneurs en cours d'exécution sur la machine. Dans le cas contraire, suivre la documentation fournie dans les ressources pour faire écouter le service Docker sur l'interface locale.
|
||||
7. Implémenter un script/programme (langage de votre choix) qui, en utilisant l'API HTTP Docker permettra de (dans l'ordre d'importance):
|
||||
1. Lancer un certain nombre d'instances Minio en mode distribué:
|
||||
|
||||
**Proposition de commande**
|
||||
|
||||
```bash
|
||||
./minio-cluster start <nombre_instances>
|
||||
```
|
||||
2. Stopper les instances en cours d'exécution
|
||||
|
||||
**Proposition de commande**
|
||||
```bash
|
||||
./minio-cluster stop
|
||||
```
|
||||
4. Ajouter/retirer une instance du cluster
|
||||
|
||||
**Proposition de commandes**
|
||||
```bash
|
||||
./minio-cluster add <nombre_instance>
|
||||
./minio-cluster remove <nombre_instance>
|
||||
```
|
||||
|
||||
|
||||
## Ressources
|
||||
|
||||
- [ISO Ubuntu Server 16.04.3 LTS](https://www.ubuntu.com/download/server/thank-you?version=16.04.3&architecture=amd64)
|
||||
- [Installer Docker sur Ubuntu](https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/)
|
||||
- [Docker Minio Quickstart](https://docs.minio.io/docs/minio-docker-quickstart-guide)
|
||||
- [Distributed Minio Quickstart](https://docs.minio.io/docs/distributed-minio-quickstart-guide)
|
||||
- [Docker Remote API with systemd](https://wiki.archlinux.org/index.php/Docker#Remote_API_with_systemd)
|
||||
- [Docker REST API](https://docs.docker.com/engine/api/v1.32/)
|
||||
Loading…
Reference in New Issue