Ajout supports formation DIIAGE (DEV & RES 3)
This commit is contained in:
BIN
diiage/C3-4_Base_de_données_Big_Data_BI/API/img/cycle.png
Normal file
BIN
diiage/C3-4_Base_de_données_Big_Data_BI/API/img/cycle.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 20 KiB |
BIN
diiage/C3-4_Base_de_données_Big_Data_BI/API/img/request.png
Normal file
BIN
diiage/C3-4_Base_de_données_Big_Data_BI/API/img/request.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 24 KiB |
BIN
diiage/C3-4_Base_de_données_Big_Data_BI/API/img/response.png
Normal file
BIN
diiage/C3-4_Base_de_données_Big_Data_BI/API/img/response.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 22 KiB |
8
diiage/C3-4_Base_de_données_Big_Data_BI/API/prepa.md
Normal file
8
diiage/C3-4_Base_de_données_Big_Data_BI/API/prepa.md
Normal file
@ -0,0 +1,8 @@
|
||||
# DIIAGE SysRes: préparation de la session du 17/11/2017
|
||||
|
||||
## Problématiques
|
||||
|
||||
- Qu'est ce qu'une API ?
|
||||
- Quelles sont aujourd'hui les différents types/schéma de conception/protocoles d'API sur le Web aujourd'hui ?
|
||||
- Quels sont les modèles d'authentification utilisés aujourd'hui avec les API sur le Web ?
|
||||
- Quels sont les risques associés à l'usage d'API pour la manipulation de services systèmes ? Quels sont les solutions de supervision et de détection des intrusions ?
|
68
diiage/C3-4_Base_de_données_Big_Data_BI/API/qcm.md
Normal file
68
diiage/C3-4_Base_de_données_Big_Data_BI/API/qcm.md
Normal file
@ -0,0 +1,68 @@
|
||||
se<style>
|
||||
* {
|
||||
font-size: 0.9em !important;
|
||||
}
|
||||
</style>
|
||||
|
||||
# API Web pour les services systèmes et réseaux: QCM
|
||||
|
||||
- **Nom**
|
||||
- **Prénom**
|
||||
- **Classe**
|
||||
- **Date**
|
||||
|
||||
## Consigne
|
||||
|
||||
Pour chaque question, entourer **la ou les bonnes réponses, si il y en a**.
|
||||
|
||||
**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. Que signifie API ?
|
||||
|
||||
1. Acceptance Program Initialization
|
||||
2. Applicative Product Injection
|
||||
3. Application Programming Interface
|
||||
|
||||
### B. Parmi ces acronymes, lesquels représentent des patrons de conception/protocoles d'API utilisés communément sur le Web aujourd'hui ?
|
||||
|
||||
1. REST
|
||||
2. SOAP
|
||||
3. JS-RPC
|
||||
|
||||
### C. Quels sont les risques majeurs induits par la bascule sur le modèle "administration par API" pour les services "système" ?
|
||||
|
||||
1. Une surface d'attaque plus grande pour les services critiques
|
||||
2. Une perte de stabilité du système
|
||||
3. Une perte de traçabilité des acteurs modifiants l'état du système
|
||||
|
||||
### D. Parmi ces mécanismes d'authentification, quels sont ceux communément utilisés pour authentifier les accès aux API sur le Web ?
|
||||
|
||||
1. JSON Web Token
|
||||
2. Certificats client/serveur
|
||||
3. NTLM
|
||||
|
||||
### E. Quels dynamiques récentes dans le monde de l'infrastructure ont poussé les développeurs de services systèmes et réseaux à se tourner vers le modèle "administration par API" ?
|
||||
|
||||
1. La généralisation de la virtualisation et la conteneurisation
|
||||
2. L'augmentation exponentielle de la taille des centres de données
|
||||
3. La complexification des processus métiers dans le monde de l'entreprise
|
||||
|
||||
### F. Dans une infrastructure pilotée par les API, quelles bonnes pratiques sont à appliquer quant à la gestion/génération de jetons d'identification ?
|
||||
|
||||
1. Une rotation régulière et automatisée des jetons d'authentification
|
||||
2. L'usage de générateurs de nombres aléatoires reposant sur des primitives cryptographiques normalisées et validées
|
||||
3. Utiliser des algorithmes internes personnalisés et secrets pour la génération des jetons
|
||||
|
||||
### G. Le stockage d'un "secret partagé", pour être sécurisé, doit:
|
||||
|
||||
1. Être haché
|
||||
2. Êtré salé
|
||||
3. Être chiffré
|
||||
|
||||
### H. Votre application communique avec une API JSON tierce à travers Internet. L'API est interrogée en utilisant HTTPS, utilisant un certificat auto-signé. La communication entre votre application et l'API est elle sécurisée ?
|
||||
|
||||
1. Oui
|
||||
2. Oui, si le certificat a pu être importé de manière sécurisée dans l'application.
|
||||
3. Non, c'est impossible avec les certificats auto-signés.
|
71
diiage/C3-4_Base_de_données_Big_Data_BI/API/slides.md
Normal file
71
diiage/C3-4_Base_de_données_Big_Data_BI/API/slides.md
Normal file
@ -0,0 +1,71 @@
|
||||
# Le Web et les API
|
||||
|
||||
---
|
||||
|
||||
# Qu'est-ce qu'une API ?
|
||||
|
||||
---
|
||||
|
||||
# HTTP
|
||||
|
||||
## Cycle requête/réponse
|
||||
## URL
|
||||
## Structure d'une requête
|
||||
## Structure d'une réponse
|
||||
|
||||
---
|
||||
|
||||
# Cycle requête/réponse
|
||||
|
||||
<div style="text-align:center; margin-top: 50px">
|
||||
<img src="img/cycle.png" height="400px" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# Structure d'une requête
|
||||
|
||||
|
||||
<div style="text-align:center; margin-top: 50px">
|
||||
<img src="img/request.png" height="400px" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# Structure d'une réponse
|
||||
|
||||
<div style="text-align:center; margin-top: 50px">
|
||||
<img src="img/response.png" height="400px" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# Le format des données
|
||||
|
||||
---
|
||||
|
||||
# Les protocoles applicatifs
|
||||
|
||||
---
|
||||
|
||||
# REST
|
||||
|
||||
---
|
||||
|
||||
# JSON-RPC2
|
||||
|
||||
---
|
||||
|
||||
# SOAP
|
||||
|
||||
---
|
||||
|
||||
# GraphQL
|
||||
|
||||
---
|
||||
|
||||
# API et authentification
|
||||
|
||||
## HTTP Basic
|
||||
## API Key + Secret (Amazon Scheme)
|
||||
## OAuth2 (OpenId Connect, JWT)
|
41
diiage/C3-4_Base_de_données_Big_Data_BI/API/tp.md
Normal file
41
diiage/C3-4_Base_de_données_Big_Data_BI/API/tp.md
Normal file
@ -0,0 +1,41 @@
|
||||
# TP - Concevoir une API REST de manipulation simpliste d'un système GNU/Linux
|
||||
|
||||
## Objectifs
|
||||
|
||||
- Comprendre les principes du patron de conception REST
|
||||
- Savoir documenter une API
|
||||
- Comprendre les risques associés à l'exécution d'opérations "système" via une API HTTP
|
||||
|
||||
## Contexte et contraintes
|
||||
|
||||
- La distribution cible est une Ubuntu Server 16.04.3 LTS (amd64)
|
||||
- Votre API doit utiliser le format JSON
|
||||
- Le langage de programmation est libre
|
||||
- Votre API doit permettre:
|
||||
- de lister l'espace disponible sur votre système (équivalent d'un `df -h`)
|
||||
- de lister les services exécutés sur votre système (équivalent d'un `systemctl status`)
|
||||
- de stopper un service sur votre système (équivalent d'un `systemctl stop <service>`)
|
||||
- de redémarrer votre serveur (équivalent d'un `reboot`)
|
||||
|
||||
## Production attendue
|
||||
|
||||
_Ceci est un TP de conception et pas d'implémentation. Vous devez vous focaliser sur le travail rédactionnel. Si ce TP est noté, c'est ce travail qui sera principalement pris en compte._
|
||||
|
||||
_Le fait d'implémenter une première version, si elle est fonctionnelle, vous apportera par contre un bonus non négligeable de points, SI ET SEULEMENT SI le travail rédactionnel préparatoire est de bonne qualité._
|
||||
|
||||
**Par ordre de priorité**
|
||||
|
||||
1. Un document expliquant les différents "points d'entrée" de votre API (voir la section "Ressources" pour un modèle de document)
|
||||
2. Un document expliquant les modifications apportées au système pour limiter le domaine d'impact de votre application.
|
||||
|
||||
Toutes les opérations demandées requièrent les droits `root` par défaut. Comment limiteriez vous le "pouvoir" (au niveau système) de votre application pour mitiger l'impact en cas de compromission de celle ci ?
|
||||
|
||||
Vous pouvez également fournir les fichiers de configuration pour appuyer votre argumentaire.
|
||||
3. Le code source de votre prototype si vous arrivez à une première implémentation
|
||||
4. Un document décrivant la procédure d'installation de votre prototype
|
||||
|
||||
## Ressources
|
||||
|
||||
- [ISO Ubuntu Server 16.04.3 LTS](https://www.ubuntu.com/download/server/thank-you?version=16.04.3&architecture=amd64)
|
||||
- [Documenter une API REST avec Markdown](https://gist.github.com/iros/3426278)
|
||||
- [Is it possible to give sudo access to only a particular command?](https://askubuntu.com/questions/90726/is-it-possible-to-give-sudo-access-to-only-a-particular-command)
|
Reference in New Issue
Block a user