DIIAGE: ajout derniers cours

This commit is contained in:
2018-03-02 12:03:52 +01:00
committed by Benjamin Bohard
parent 3998722c7f
commit 506d99e91b
9 changed files with 355 additions and 0 deletions

View File

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

View File

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

View File

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

View File

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