DIIAGE: ajout derniers cours
This commit is contained in:
parent
5255503103
commit
5f537a3a77
|
|
@ -0,0 +1,14 @@
|
|||
# Préparation: Modèles d'autorisation
|
||||
|
||||
## Problématiques
|
||||
|
||||
- Quels sont les différents modèles d'autorisation aujourd'hui utilisés dans les applications informatiques ?
|
||||
- Quels sont les avantages et inconvénients de ces différents modèles ?
|
||||
|
||||
## Bibliographie
|
||||
|
||||
- [Role Based Access Control - Wikipédia](https://en.wikipedia.org/wiki/Role-based_access_control)
|
||||
- [Access Control List - Wikipédia](https://en.wikipedia.org/wiki/Access_control_list)
|
||||
- [Attribute Based Access Control - Wikipédia](https://en.wikipedia.org/wiki/Attribute-based_access_control)
|
||||
- [Role Based Acccess Control - NIST - 15th National Computer Security Conference](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/1992/10/13/role-based-access-controls/documents/ferraiolo-kuhn-92.pdf)
|
||||
- [Attribute Based Access Control](http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf)
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
<style>
|
||||
* {
|
||||
font-size: 0.8em !important;
|
||||
}
|
||||
</style>
|
||||
|
||||
# Autorisation: QCM
|
||||
|
||||
- **Nom**
|
||||
- **Prénom**M
|
||||
- **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. Dans un modèle d'autorisation de type ACL, les permissions sont attachées:
|
||||
|
||||
1. À l'objet sur lequel on veut effectuer l'action
|
||||
2. À l'utilisateur qui veut effectuer l'action
|
||||
3. À l'action que l'utilisateur veut effectuer sur l'objet
|
||||
|
||||
### B. Quelles sont limites inhérentes au modèle d'autorisation de type ACL (dans son implémentation classique) ?
|
||||
|
||||
1. L'impossibilité de modéliser des interdictions.
|
||||
2. Une impossibilité de mutualiser les permissions entre les utilisateurs
|
||||
3. Une nécessité de scanner l'ensemble des objets lorsqu'on souhaite retirer une permission à un utilisateur.
|
||||
|
||||
### C. Les ACL sont souvent stockées sous forme:
|
||||
|
||||
1. Des graphes
|
||||
2. De tables
|
||||
3. Des listes chaînées
|
||||
|
||||
### D. Que signifie "principe de moindre privilège" ?
|
||||
|
||||
1. Que le nombre total de permissions différentes devrait être maintenu au minimum dans une application.
|
||||
2. Qu'une entité ne devrait pouvoir interagir qu'avec les éléments qui sont absolument nécessaires à son fonctionnement.
|
||||
3. Qu'une action ne devrait pas être générique.
|
||||
|
||||
### E. Dans le modèle ABAC, qu'est ce qu'une "politique" ?
|
||||
|
||||
1. Une classification d'attributs
|
||||
2. Un ensemble de règles définissant si une opération est possible sur un objet.
|
||||
3. L'ensemble des opérations possibles sur un objet.
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
# TP - Concevoir un modèle d'autorisation
|
||||
|
||||
## Contexte
|
||||
|
||||
Un client souhaite réaliser une application de gestions des ressources techniques pour palier aux problèmes de "sur-réservation" qui touchent son entreprise avec le modèle actuel basé sur des formulaires papiers.
|
||||
|
||||
L'entreprise met à disposition de ses employés les ressources suivantes:
|
||||
|
||||
- 4 salles de réunion
|
||||
- 5 véhicules professionnels
|
||||
- 3 projecteurs numériques
|
||||
- 6 ordinateurs portables
|
||||
|
||||
Les ressources sont évidemment indivisibles. Chaque employé peut réserver une ressource pour une ou plusieurs heures.
|
||||
|
||||
Les salariés sont répartis par services:
|
||||
|
||||
- Un service "Direction"
|
||||
- Un service "RH"
|
||||
- Un service "Direction"
|
||||
- Un service "Commercial"
|
||||
|
||||
Le client souhaite que les règles de gestion suivantes soient respectées:
|
||||
|
||||
- Une ressource, pour une heure donnée, à 3 états possibles: libre, pré-réservée ou réservée.
|
||||
- Tous les services peuvent réserver une ou plusieurs ressources pour une ou plusieurs heures si celle(s) ci ne sont pas encore réservées.
|
||||
- Les membres du services "Commercial" ont la priorité sur les véhicules de fonction. Ils peuvent donc annuler une pré-réservation existante sur un véhicule par leur propre propre pré-réservation. Ils ne peuvent pas annuler une réservation validée.
|
||||
- Le service "RH" peut valider les réservations des ressources (ils passent donc une ressource de l'état pré-réservée à réservée)
|
||||
- Les membres du service "Direction" peuvent remplacer n'importe quelle pré-réservation existante sur n'importe quelle ressource.
|
||||
|
||||
## Consignes
|
||||
|
||||
- Identifier les entités métiers constituant l'application.
|
||||
- Identifier les différents types d'utilisateurs de l'application
|
||||
- Identifier les actions possibles sur les entités et les permissions associées
|
||||
- Concevoir et modéliser un système d'autorisation permettant d'implémenter les contraintes de gestion attendues par le client. Votre proposition devra respecter le principe de moindre privilège et de séparation des droits. Votre modélisation peut être soit sous forme de graphique ou textuelle.
|
||||
- Argumenter son choix du type de modèle ACL, RBAC ou ABAC par rapport aux contraintes du projet.
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
# Évaluation - TP
|
||||
|
||||
## Objectifs
|
||||
|
||||
1. Implémenter un micro-projet dans un temps donné
|
||||
2. Respecter les consignes
|
||||
3. S'organiser pour respecter les contraintes de temps et réaliser le contrat
|
||||
4. Appliquer les concepts et principes découverts lors des sessions précédentes
|
||||
|
||||
## Sujet
|
||||
|
||||
Concevoir et implémenter en NodeJS une version numérique des "[dead drops](https://fr.wikipedia.org/wiki/Dead_Drop)".
|
||||
|
||||
Réaliser le modèle de menace de cette application.
|
||||
|
||||
### Fonctionnement de l'application
|
||||
|
||||
Un utilisateur anonyme transfère un fichier via une URL HTTP sur un serveur.
|
||||
|
||||
Le serveur chiffre **à la volée** le fichier avec une clé publique et l'enregistre sur le disque du serveur dans un répertoire.
|
||||
|
||||
Un utilisateur connaissant la clé privée associée à la clé publique peut utiliser un script pour déchiffrer un fichier voulu **en entrant interactivement sa phrase de passe** (Exemple d'utilisation: `node decrypt.js <chemin_fichier>`).
|
||||
|
||||
## Contraintes concernant l'implémentation
|
||||
|
||||
- Vous devez réaliser votre implémentation en NodeJS (version LTS 8.9.4)
|
||||
- Vous ne pouvez utiliser que les modules [`express`](https://expressjs.com/), [`express-fileupload`](https://www.npmjs.com/package/express-fileupload) et la librairie standard (notamment le module [`crypto`](https://nodejs.org/api/crypto.html)).
|
||||
- Le code doit être commenté.
|
||||
|
||||
### Rédaction du modèle de menace
|
||||
|
||||
Vous devrez réaliser un modèle de menace de l'application en vous basant sur les informations disponibles [sur le site de l'OWASP](https://www.owasp.org/index.php/Application_Threat_Modeling).
|
||||
|
||||
Notamment, vous devrez identifier:
|
||||
|
||||
- les dépendances externes nécessaires au bon fonctionnement de votre application
|
||||
- les points d'entrée
|
||||
- les "assets"
|
||||
- les niveaux de confiances
|
||||
|
||||
Un [diagramme de flux de données](https://www.owasp.org/index.php/Application_Threat_Modeling#Data_Flow_Diagrams) ainsi qu'une liste des différentes menaces (en utilisant la [catégorisation STRIDE](https://www.owasp.org/index.php/Application_Threat_Modeling#Determine_and_Rank_Threats)) devront être également réalisés.
|
||||
|
||||
## Éléments attendus
|
||||
|
||||
- Un répertoire nommé `projet` comprenant les sources de votre application, notamment:
|
||||
- Un fichier `server.js` comprenant le code source de votre serveur HTTP/chiffrement des fichiers.
|
||||
- Un fichier `decrypt.js` qui comprendra le code source du script permettant de déchiffrer un fichier donné.
|
||||
- Le fichier `package.json` qui sera utilisé pour définir/installer les dépendances.
|
||||
- Un fichier `README` décrivant la procédure d'installation et d'utilisation de votre implémentation.
|
||||
- Un fichier PDF nommé `modele_de_menace.pdf` comprenant votre modèle de menace, le diagramme de flux de données ainsi que la liste des menaces que vous avez identifié.
|
||||
|
||||
Votre TP est à téléverser sur la plateforme de partage dans le répertoire défini par l'intervenant **avant la fin de la journée** (l'horodatage de création du fichier sur l'application fera foi). **Il ne devra pas être modifié après cette journée**.
|
||||
|
||||
L'archive (zip ou tar.gz, à votre convenance) comprenant vos fichiers devra respecter le format suivant:
|
||||
|
||||
```
|
||||
[prenom]_[nom]_evaluation.[extension]
|
||||
```
|
||||
|
||||
<div style="page-break-after: always;"></div>
|
||||
|
||||
## Grille de notation
|
||||
|
||||
| Critère | Description | Points maximum |
|
||||
|---------|-------------|----------------|
|
||||
| Respect des consignes | Les consignes sont respectées. | 3 |
|
||||
| Implémentation | L'implémentation fournie est fonctionnelle. | 6 |
|
||||
| Documentation | Le code est commenté. Le fichier `README` est clair et exhaustif. | 3 |
|
||||
| Modèle de menace | Le modèle de menace est clair, les différents points d'inventaire sont couverts. Le diagramme de flux de données est complet et couvre l'ensemble de l'application. La catégorisation des menaces comporte au moins 3 menaces et sont correctement catégorisées et décrites par rapport au modèle STRIDE. | 6 |
|
||||
| Orthographe et vocabulaire | Les règles d’orthographe et le choix du vocabulaire est correct (l'usage d'anglicismes ne sera pas pénalisé). | 2 |
|
||||
| Tests unitaires | Vous avez implémenté des tests unitaires viables (i.e. qui vérifie véritablement le bon fonctionnement de votre code) dans votre implémentation. Les modalités d'exécution de vos tests sont décrites dans votre `README`. | 3 (points bonus) |
|
||||
|
||||
**Le total de vos points ne peut excéder 20.**
|
||||
|
||||
0
diiage/C3-4_Base_de_données_Big_Data_BI/20171208_Conteneurisation_Docker/start-minio.sh
Executable file → Normal file
0
diiage/C3-4_Base_de_données_Big_Data_BI/20171208_Conteneurisation_Docker/start-minio.sh
Executable file → Normal file
|
|
@ -0,0 +1,18 @@
|
|||
# Préparation: Stratégie de communication dans l'IoT
|
||||
|
||||
## Problématiques
|
||||
|
||||
- Quelles sont les différentes stratégies envisageables pour faire communiquer des flottes d'objets connectés ?
|
||||
- Quelles techniques sont utilisées pour assurer la scalabilité des communications ?
|
||||
- Quelles techniques sont utilisées pour la découverte des services disponibles dans l'environnement immédiat (ou non) des objets connectés ?
|
||||
|
||||
## Ressources
|
||||
|
||||
- [Choosing the right communication pattern for the Internet of Things - Intel](https://software.intel.com/en-us/articles/communication-patterns-for-the-internet-of-things)
|
||||
- [Multicast DNS - Wikipédia](https://en.wikipedia.org/wiki/Multicast_DNS)
|
||||
- [Zeroconf - Wikipédia](https://fr.wikipedia.org/wiki/Zeroconf)
|
||||
- [Consul - Service Discovery and Configuration](https://www.consul.io/)
|
||||
- [NATS - Simple High Performance Messaging Server](https://nats.io/)
|
||||
- [ZeroMQ - Multi language communication librairy](http://zeromq.org/)
|
||||
- [MQTT - M2M communication protocol](http://mqtt.org/)
|
||||
- [UPnP](https://en.wikipedia.org/wiki/Universal_Plug_and_Play)
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
<style>
|
||||
* {
|
||||
font-size: 0.8em !important;
|
||||
}
|
||||
</style>
|
||||
|
||||
# Authentification: 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. Dans un modèle de communication `publish/subscribe`, les agents communiquent via l'envoi de:
|
||||
|
||||
1. messages
|
||||
2. sémaphores
|
||||
3. signaux
|
||||
|
||||
### B. Dans le contexte de la communication inter-agents, un "broker" a pour rôle:
|
||||
|
||||
1. De déduire automatiquement le sujet d'un message par rapport à son contenu
|
||||
2. De découpler les producteurs et consommateurs d'information
|
||||
3. D'acheminer et router les messages entre les différents les producteurs d'informations et les consommateurs de ces informations
|
||||
|
||||
### C. Le protocole mDNS utilise pour la découverte de services
|
||||
|
||||
1. Une adresse IP multicast
|
||||
2. Un serveur de "rendez vous"
|
||||
3. Du broadcast UDP
|
||||
|
||||
### D. En dehors d'une communication directe possible (réseaux différents, NAT, etc), les agents utilisent habituellement pour se découvrir mutuellement:
|
||||
|
||||
1. Un serveur de "rendez vous"
|
||||
2. Un registre global
|
||||
3. Des champs TXT sur un enregistrement DNS
|
||||
|
||||
### E. L'utilisation d'une "queue" dans un protocole de communication basée sur les messages permet de:
|
||||
|
||||
1. S'assurer que les messages produits ne sont consommés que par N agents au maximum
|
||||
2. Répartir la charge liée au traitement d'un message
|
||||
3. Décharger le "broker" du traitement de certains messages
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
# TP - Créer un réseau d'agents indépendants communicants
|
||||
|
||||
## Avertissement
|
||||
|
||||
Ceci est un **TP de classe**. Vous devez vous répartir les tâches et travailler par binome/trinome/etc. N'essayez pas d'implémenter l'ensemble des agents de manière individuelle. Vous devez donc également vous mettre d'accord sur le format des messages pour que vos agents soient inter-opérables.
|
||||
|
||||
## Contexte
|
||||
|
||||
Créer un réseau d'agents indépendants capables de récolter/partager des informations sur vos machines respectives. Ces agents devront communiquer via un serveur NATS en suivant le paradigme `publish/subscribe`.
|
||||
|
||||
Les agents suivants devraient être implémentés:
|
||||
|
||||
- Un agent récoltant l'espace disque utilisé sur votre machine et publiant celui ci sur le réseau.
|
||||
- Un agent récoltant la température des CPU de votre machine (sur Linux, voir `/sys/class/thermal`).
|
||||
- Un agent d'alerte réagissant aux messages des agents "Espace disque" et "Température CPU". Si les valeurs dépassent un seuil prédéfini (le choix reste à votre discrétion), cet agent doit envoyer un message d'alerte sur le réseau.
|
||||
- Un agent de transmission des alertes. Lorsque cet agent reçoit un message d'alerte via le serveur NATS, il doit transformer celui ci en courriel et l'envoyer à une adresse prédéfinie.
|
||||
|
||||
> Ce type de topologie avec des agents indépendants est typique d'un réseau "IoT".
|
||||
>
|
||||
> Chaque agent que vous implémenterez est assimilable à un objet avec une fonction précise (capteur d'humidité, thermomètre, capteur de présence, etc...).
|
||||
>
|
||||
> Ces objets communiquent par l'envoi/réception de messages sur un médium/protocole de transport commun (ici TCP/IP + NATS). Dans la réalité, ces objets pourraient utiliser du Bluetooth, des ondes radio, une connexion 4G...
|
||||
|
||||
|
||||
## Consignes
|
||||
|
||||
- Récupérer/installer un serveur [NATS](https://nats.io/download/nats-io/gnatsd/) et le lancer sur une de vos machines. Ce serveur NATS servira de canal de communication entre vos agents.
|
||||
- À l'aide du [langage de votre choix](https://nats.io/download/) implémenter un des agents décrits ci dessus. Si vous préférez travailler avec des scripts (Bash ou Powershell, à votre convenance), vous pouvez utiliser l'utilitaire [nuts](https://forge.cadoles.com/wpetit/nuts) pour gérer la communication avec le serveur NATS. **Vous n'êtes pas obligé d'implémenter vos agents avec le même langage.**
|
||||
- Concevoir un protocole commun pour que vos agents puissent communiquer ensemble.
|
||||
- S'assurer que les agents implémentés sont interopérables et que les alertes par courriel sont correctement envoyées.
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
# Évaluation - TP
|
||||
|
||||
## Objectifs
|
||||
|
||||
1. Implémenter un micro-projet dans un temps donné
|
||||
2. Respecter les consignes
|
||||
3. S'organiser pour respecter les contraintes de temps et réaliser le contrat
|
||||
4. Appliquer les concepts et principes découverts lors des sessions précédentes
|
||||
|
||||
## Sujet
|
||||
|
||||
Concevoir et implémenter une architecture élastique de base de données autour des solutions [CockroachDB](https://www.cockroachlabs.com/docs/stable/), [Docker](https://docs.docker.com/) et [NATS](https://nats.io/).
|
||||
|
||||
### Contexte
|
||||
|
||||
Un client souhaite mettre en place une infrastructure élastique autour d'une base de données relationnelle.
|
||||
|
||||
Son système d'information est d’ors et déjà basé sur Docker pour la conteneurisation et NATS pour l'échange de messages entre les différents services de son environnement applicatif.
|
||||
|
||||
Son objectif est de pouvoir (à travers l'envoi de messages NATS) d'ajouter/supprimer des instances de base de données pour s'adapter automatiquement au niveau de charge de l'environnement applicatif.
|
||||
|
||||
Il voudrait qu'on lui fournisse un prototype implémentant les fonctionnalités suivantes:
|
||||
|
||||
- Un script `bootstrap-env.sh` qui créait un environnement basé sur Docker avec une instance de CockroachDB en mode cluster et un serveur NATS dans des conteneurs différents.
|
||||
- Un script `add-node.sh` qui démarre un nouveau conteneur CockroachDB qui rejoindra automatiquement le cluster déjà existant.
|
||||
- Un script `remove-node.sh` qui arrête un des conteneurs CockroachDB en cours d'exécution si il en reste plus de 1.
|
||||
- Un script `db-node-add-subscriber.sh` qui une fois lancé s'abonne à la publication du sujet `db.node.add` sur le serveur NATS et invoque automatiquement le script `add-node.sh`.
|
||||
- Un script `db-node-remove-subscriber.sh` qui une fois lancé s'abonne à la publication du sujet `db.node.remove` sur le serveur NATS et invoque automatiquement le script `remove-node.sh`.
|
||||
- Un script `test.sh` qui publie des messages sur le serveur NATS afin de tester le bon fonctionnement du prototype.
|
||||
|
||||
Un fichier `README` devra être fourni décrivant la procédure d'installation et d'utilisation du prototype.
|
||||
|
||||
Il voudrait également qu'on lui fournisse un [diagramme de séquence](https://fr.wikipedia.org/wiki/Diagramme_de_s%C3%A9quence) pour les développeurs et les administrateurs opérationnels illustrant les processus suivants:
|
||||
|
||||
- Ajout d'une nouvelle instance CockroachDB via un message NATS
|
||||
- Suppression d'une instance CockroachDB via un message NATS
|
||||
|
||||
Il aimerait enfin qu'on lui présente une potentielle solution, accompagnée d'un [diagramme d'activité](https://fr.wikipedia.org/wiki/Diagramme_d%27activit%C3%A9), pour limiter le nombre maximum d'instances CockroachDB en cours d'exécution à un instant T.
|
||||
|
||||
## Contraintes concernant l'implémentation
|
||||
|
||||
- Vos scripts doivent utiliser l'interpréteur Bash.
|
||||
- Le code doit être commenté.
|
||||
- Vous pouvez utiliser [nuts](./https://forge.cadoles.com/wpetit/nuts) (voir la section Release pour télécharger les binaires) pour la partie communication avec le serveur NATS.
|
||||
|
||||
## Éléments attendus
|
||||
|
||||
- Un répertoire nommé `projet` contenant les fichiers suivants:
|
||||
- `bootstrap-env.sh`
|
||||
- `add-node.sh`
|
||||
- `remove-node.sh`
|
||||
- `db-node-add-subscriber.sh`
|
||||
- `db-node-remove-subscriber.sh`
|
||||
- `test.sh`
|
||||
- `README`
|
||||
- Un fichier PDF nommé `document_achitecture.pdf` comprennant les diagrammes de séquence ainsi que la proposition de solution pour limiter le nombre maximum d'instances, accompagné de son diagramme d'activité.
|
||||
|
||||
Votre TP est à téléverser sur la plateforme de partage dans le répertoire défini par l'intervenant **avant la fin de la journée** (l'horodatage de création du fichier sur l'application fera foi). **Il ne devra pas être modifié après cette journée**.
|
||||
|
||||
L'archive (zip ou tar.gz, à votre convenance) comprenant vos fichiers devra respecter le format suivant:
|
||||
|
||||
```
|
||||
[prenom]_[nom]_evaluation.[extension]
|
||||
```
|
||||
|
||||
_Grille de notation page suivante_
|
||||
|
||||
<div style="page-break-after: always;"></div>
|
||||
|
||||
## Grille de notation
|
||||
|
||||
| Critère | Description | Points maximum |
|
||||
|---------|-------------|----------------|
|
||||
| Respect des consignes | Les consignes sont respectées. | 3 |
|
||||
| Implémentation | Le prototype fourni est fonctionnel. | 6 |
|
||||
| Documentation | Le code est commenté. Le fichier `README` est clair et exhaustif. | 3 |
|
||||
| Document d'architecture | Les diagrammes de séquences sont représentatifs du comportement du prototype. La proposition de solution est claire et argumentée. Le diagramme d'activité illustre correctement la solution présentée. | 6 |
|
||||
| Orthographe et vocabulaire | Les règles d’orthographe et le choix du vocabulaire est correct (l'usage d'anglicismes ne sera pas pénalisé). | 2 |
|
||||
| Prototypage de la solution proposée | Vous avez implémenté la solution de limitation des instances proposée et elle est fonctionnelle. | 3 (points bonus) |
|
||||
|
||||
**Le total de vos points ne peut excéder 20.**
|
||||
|
||||
Loading…
Reference in New Issue