Ajout supports formation DIIAGE (DEV & RES 3)
This commit is contained in:
parent
affa70b31c
commit
f383613cbd
|
|
@ -0,0 +1,66 @@
|
|||
# Curation de contenu - Travaux pratiques
|
||||
|
||||
## Objectifs
|
||||
|
||||
**Créer de manière collaborative une fiche d'information** (1 à 3 pages) répondant à une problématique. La rédaction de la fiche d'information devra **prendre en compte un public cible** donné.
|
||||
|
||||
La fiche d'information devra comprendre **une bibliographie** des sources d'informations
|
||||
utilisées pour sa réalisation. Elle devra également **indiquer la fréquence estimée** (et/ou les événements déclencheurs) des mises à jour des informations la constituant.
|
||||
|
||||
La fiche d'information fera ensuite l'objet d'**une présentation devant la classe** par
|
||||
le groupe de travail. Le groupe devra **argumenter ses choix** de sélection des informations et le plan utilisé pour répondre à la problématique.
|
||||
|
||||
## Temps
|
||||
|
||||
- ~60min de travail préparatoire
|
||||
- 10-15min de présentation et questions
|
||||
|
||||
## Sujets proposés
|
||||
|
||||
### 1. Les crypto monnaies: quelle adoption du grand public et quels usages internes dans l'entreprise ?
|
||||
|
||||
#### Cible
|
||||
|
||||
- **Profil** Directeur d'entreprise (niveau technique: faible)
|
||||
- **Contexte** Grand groupe avec beaucoup d'échanges inter succursales. Recherche et développement.
|
||||
|
||||
<div style="page-break-after:always;"></div>
|
||||
|
||||
### 2. Quelles solutions pour l'hébergement des applications Web pour l'entreprise ?
|
||||
|
||||
#### Cible
|
||||
|
||||
- **Profil** Responsable de la Sécurité des Systèmes d'Information (niveau technique: élevé)
|
||||
- **Contexte** Entreprise avec applicatifs vieillissants. Manque de moyens pour l'installation et la maintenance des serveurs.
|
||||
|
||||
### 3. Quelle plateforme pour prototyper notre nouveau projet "Toutou 2000", l'application/collier GPS pour le suivi de chiens fugueurs ?
|
||||
|
||||
- **Profil** Technico-commercial (niveau technique: moyen)
|
||||
- **Contexte** Obligation de résultats sur un délai court. Contraintes financières fortes.
|
||||
|
||||
### 4. Comment former nos salariés aux problématiques de sécurité informatique ?
|
||||
|
||||
- **Profil** Directeur d'entreprise (niveau technique: faible)
|
||||
- **Contexte** Vague massive d'attaque de type "phishing". Formation continue. Difficulté à bloquer du temps pour les salariés.
|
||||
|
||||
### 5. Quelles solutions pour maintenir dans de bonnes conditions de sécurité nos applications vieillissantes ?
|
||||
|
||||
- **Profil** Client/Directeur de service (niveau technique: moyen)
|
||||
- **Contexte** Évolution du parc des serveurs. Maintien opérationnel d'applications non maintenue. Sécurité de l'infrastructure. Sauvegarde et restauration.
|
||||
|
||||
<div style="page-break-after:always;"></div>
|
||||
|
||||
### 6. Optimisation des coûts opérationnels: comment réduire les frais liés au fonctionnement de notre service en ligne ?
|
||||
|
||||
- **Profil** Service financier (niveau technique: faible)
|
||||
- **Contexte** Afflux important de nouveaux utilisateurs suite à une campagne de communication réussie. Application web 3 tiers classique avec usage important en lecture de la base de données.
|
||||
|
||||
### 7. Sauvegarde des postes clients: comment sauvegarder/restaurer des données sur les postes des salariés ?
|
||||
|
||||
- **Profil** Chef de service RH (niveau technique: faible)
|
||||
- **Contexte** Perte de données critique des données d'un des postes de salarié. Transparence des opérations pour les utilisateurs. Facilité à restaurer les données d'un instant T en autonomie.
|
||||
|
||||
### 8. Modernisation de la stack de développement: quels nouveaux langages pour quels usages pour nous développeurs Web ?
|
||||
|
||||
- **Profil** Chef de projet (niveau technique: élevé)
|
||||
- **Contexte** Évolution du socle technique d'une société de développement Web. Travail d'équipe. Nouvelles technologies.
|
||||
|
|
@ -0,0 +1,120 @@
|
|||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="84.116531mm"
|
||||
height="54.857159mm"
|
||||
viewBox="0 0 298.05072 194.37576"
|
||||
id="svg2"
|
||||
version="1.1"
|
||||
inkscape:version="0.91 r"
|
||||
sodipodi:docname="cycle.svg">
|
||||
<defs
|
||||
id="defs4" />
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageopacity="0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="1.4"
|
||||
inkscape:cx="251.9618"
|
||||
inkscape:cy="8.6816679"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1053"
|
||||
inkscape:window-x="1600"
|
||||
inkscape:window-y="0"
|
||||
inkscape:window-maximized="1" />
|
||||
<metadata
|
||||
id="metadata7">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
inkscape:label="Calque 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-137.1359,-130.28912)">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-weight:normal;font-size:27.93373489px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#333333;fill-opacity:0.94117647;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
x="208.96439"
|
||||
y="151.68951"
|
||||
id="text4140"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4142"
|
||||
x="208.96439"
|
||||
y="151.68951"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Droid Sans';-inkscape-font-specification:'Droid Sans';fill:#333333;fill-opacity:0.94117647">Aggréger</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-weight:normal;font-size:27.93373489px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#333333;fill-opacity:0.94117647;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
x="285.31558"
|
||||
y="278.75479"
|
||||
id="text4140-3"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
id="tspan4142-5"
|
||||
x="285.31558"
|
||||
y="278.75479"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Droid Sans';-inkscape-font-specification:'Droid Sans';fill:#333333;fill-opacity:0.94117647">Éditorialiser</tspan><tspan
|
||||
sodipodi:role="line"
|
||||
x="285.31558"
|
||||
y="313.67197"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Droid Sans';-inkscape-font-specification:'Droid Sans';fill:#333333;fill-opacity:0.94117647"
|
||||
id="tspan4162" /></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-style:normal;font-weight:normal;font-size:27.93373489px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#333333;fill-opacity:0.94117647;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
x="134.42163"
|
||||
y="278.75479"
|
||||
id="text4140-3-7"
|
||||
sodipodi:linespacing="125%"><tspan
|
||||
sodipodi:role="line"
|
||||
x="134.42163"
|
||||
y="278.75479"
|
||||
style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Droid Sans';-inkscape-font-specification:'Droid Sans';fill:#333333;fill-opacity:0.94117647"
|
||||
id="tspan4162-3">Rectifier</tspan></text>
|
||||
<path
|
||||
style="fill:#304e8a;fill-opacity:0.94117647;fill-rule:evenodd;stroke:none;stroke-width:1.5;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.94117647"
|
||||
d="m 378.04866,228.06005 c 4.26899,-28.35846 -17.35148,-57.39168 -35.76229,-69.9753 l -18.20323,8.2396 c 28.72428,3.00847 49.30018,30.78961 48.70109,62.38945 l -7.23071,-2.11387 5.82375,16.55837 14.46894,-15.31083 z"
|
||||
id="path4136-14"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cccccccc" />
|
||||
<path
|
||||
style="fill:#304e8a;fill-opacity:0.94117647;fill-rule:evenodd;stroke:none;stroke-width:1.5;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.94117647"
|
||||
d="m 228.26039,311.30376 c 21.96802,18.43454 58.01619,15.13274 78.35571,5.98891 l 2.46532,-19.82854 c -17.54992,22.93764 -51.98496,26.00135 -78.63276,9.00711 l 5.57518,-5.06644 -17.16501,-3.66848 5.51557,20.33102 z"
|
||||
id="path4136-14-6"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cccccccc" />
|
||||
<path
|
||||
style="fill:#304e8a;fill-opacity:0.94117647;fill-rule:evenodd;stroke:none;stroke-width:1.5;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:0.94117647"
|
||||
d="m 180.22842,162.6946 c -23.07008,17.03521 -28.30955,52.85308 -24.1878,74.76922 l 18.69833,7.04423 c -18.18516,-22.43736 -13.09232,-56.63124 9.67446,-78.55344 l 3.61854,6.60738 7.58957,-15.82699 -21.05744,0.59656 z"
|
||||
id="path4136-14-6-9"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cccccccc" />
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 5.9 KiB |
|
|
@ -0,0 +1,5 @@
|
|||
# Notes
|
||||
|
||||
- [Curation de contenu](https://fr.wikipedia.org/wiki/Curation_de_contenu)
|
||||
- [Intelligence collective](https://fr.wikipedia.org/wiki/Intelligence_collective)
|
||||
- [Gestion des connaissances](https://fr.wikipedia.org/wiki/Gestion_des_connaissances)
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
<style>
|
||||
* {
|
||||
font-size: 0.9em !important;
|
||||
}
|
||||
</style>
|
||||
|
||||
# Curation de contenu: questionnaire
|
||||
|
||||
- **Nom**
|
||||
- **Prénom**
|
||||
- **Classe**
|
||||
- **Date**
|
||||
|
||||
## Consigne
|
||||
|
||||
Pour chaque question, entourer **la ou les bonnes réponses, si il y en a**.
|
||||
|
||||
## Questions
|
||||
|
||||
### A. Dans la phase d'agrégation, quelle est l'opération qui permet de préparer la bibliographie ?
|
||||
|
||||
1. L'indexation des références
|
||||
2. La mise en forme
|
||||
3. La synthétisation
|
||||
|
||||
### B. Recouper les sources permet de...
|
||||
|
||||
1. Vérifier la véridicité d'une information
|
||||
2. S'assurer de l'importance d'une information
|
||||
3. Multiplier les références
|
||||
|
||||
### C. Identifier le public cible de la base de connaissance permet de...
|
||||
|
||||
1. D'éviter de créer de la surcharge cognitive
|
||||
2. Économiser du temps lors de la phase d'agrégation
|
||||
3. Préparer son argumentaire
|
||||
|
||||
### D. Quel(s) outil(s) créé(s) grâce à l'avènement d'Internet à/ont modifié profondément la rédaction de base de connaissances ?
|
||||
|
||||
1. Les wiki
|
||||
2. Les "pads" collaboratifs
|
||||
3. Les éditeurs de texte
|
||||
|
||||
### E. L'identification des passerelles permet de...
|
||||
|
||||
1. Faciliter la navigation dans le corpus
|
||||
2. Guider le lecteur dans sa lecture
|
||||
3. Suggérer des sujets connexes potentiellement intéressants pour le lecteur
|
||||
|
|
@ -0,0 +1,50 @@
|
|||
<!-- $theme: default -->
|
||||
<!-- footer: William Petit - S.C.O.P. Cadoles -->
|
||||
|
||||
# Créer et maintenir une base de connaissance
|
||||
|
||||
---
|
||||
|
||||
> Un informaticien, c'est quelqu'un payé pour savoir chercher sur Stack Overflow/Exchange.
|
||||
>
|
||||
> **Auteur inconnu**
|
||||
|
||||
---
|
||||
|
||||
# Qu'est ce qu'une base de connaissance ?
|
||||
|
||||
---
|
||||
# Cycle de vie
|
||||
|
||||
<div style="text-align:center; margin-top: 50px">
|
||||
<img src="./img/cycle.svg" height="400px" />
|
||||
</div>
|
||||
|
||||
---
|
||||
|
||||
# Agréger
|
||||
|
||||
## Collecter l'information
|
||||
## Recouper les sources
|
||||
## Indexer les références
|
||||
|
||||
---
|
||||
|
||||
# Éditorialiser
|
||||
|
||||
## Définir la cible et les objectifs
|
||||
## Sélectionner l'information
|
||||
## Mettre en forme et synthétiser
|
||||
## Indexer les données
|
||||
|
||||
---
|
||||
|
||||
# Rectifier
|
||||
|
||||
## Évaluer la validité et la pertinence des informations
|
||||
## Définir la fréquence de mise à jour et ses événements déclencheurs
|
||||
## Identifier les sujets connexes et les passerelles
|
||||
|
||||
---
|
||||
|
||||
# Mise en pratique
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# DIIAGE Dev: préparation de la session du 17/11/2017
|
||||
|
||||
## Problématiques
|
||||
|
||||
- Qu'est ce que la sécurité informatique dans l'entreprise ?
|
||||
- Quels sont les objectifs de la sécurité informatique ?
|
||||
- Quelles sont les principales failles touchant les applicatifs Web ? Quels sont les risques associés ?
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
<style>
|
||||
* {
|
||||
font-size: 0.9em !important;
|
||||
}
|
||||
</style>
|
||||
|
||||
# Sécurité des SI et applications Web: questionnaire
|
||||
|
||||
- **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. Dans le contexte de la sécurité informatique, que représente le concept général de "menace" ?
|
||||
|
||||
1. Une cause potentielle d'incident, qui peut résulter en un dommage au système ou à l'organisation
|
||||
2. Une faiblesse dans un système informatique permettant à un attaquant de porter atteinte à l'intégrité de ce système
|
||||
3. Une mauvaise manipulation ou une malveillance entraînant une perte de matériel et/ou de données
|
||||
|
||||
### B. Parmi ces réponses, lesquelles sont des objectifs de la sécurité informatique en entreprise ?
|
||||
|
||||
1. Maintenir l'intégrité des données
|
||||
2. S'assurer du niveaux d'authentification et d'autorisation
|
||||
3. Maintenir la disponibilité des services
|
||||
|
||||
### C. Qu'est ce que la modélisation de menace ?
|
||||
|
||||
1. Un processus permettant d'identifier les menaces mettant en péril un système et d'évaluer les risques et les impacts potentiels de celles ci.
|
||||
2. Un document faisant un état des lieux des vulnérabilités d'une application
|
||||
3. Un processus de simulation d'attaque organisé pendant un audit de sécurité
|
||||
|
||||
### D. Quel est aujourd'hui le principal vecteur d'attaque sur les systèmes d'informations ?
|
||||
|
||||
1. La méconnaissance humaine
|
||||
2. Les failles "0-day"
|
||||
3. La mauvaise sécurisation des environnements "intranet"
|
||||
|
||||
### E. Quels sont les risques associés à une mauvaise définition du périmètre d'application de la politique de sécurité en entreprise ?
|
||||
|
||||
1. L'application de règles non adaptées aux spécificités des différents contextes fonctionnels/techniques
|
||||
2. Une mauvaise formation des collaborateurs face aux risques liés à la sécurité en entreprise
|
||||
3. Une mauvaise évaluation des risques liés à chaque contexte de l'entreprise
|
||||
|
||||
### F. Parmi ces acronymes, lesquels sont des catégories de failles impactant les applications Web ?
|
||||
|
||||
1. SQLI
|
||||
2. CSRF
|
||||
3. AJAX
|
||||
|
||||
### G. Une faille XSS...
|
||||
|
||||
1. ...permet d'injecter du code HTML/Javascript dans une page d'une application Web tierce
|
||||
2. ...permet d'exploiter les sessions HTTP de l'utilisateur en cours de validité
|
||||
3. ...permet d'accéder à des fichiers du serveur en parcourant l'arborescence du système de fichier
|
||||
|
||||
### H. Parmi ces pratiques, quelles sont celles qui sont des catalyseurs de risques ?
|
||||
|
||||
1. La mauvaise gestion du cycle de vie des dépendances de l'application
|
||||
2. Une mauvaise politique de journalisation des opérations de l'application
|
||||
3. L'utilisation de plateformes SaaS
|
||||
|
||||
### I. Dans le cadre du développement d'une application web, la sécurité de l'infrastructure devraient être abordée:
|
||||
|
||||
1. Dès les premières itérations de développement
|
||||
2. En conjugant le travail des équipes de développement et les équipes opérationnelles
|
||||
3. Analysée par une entité externe à la fin de chaque cycle de développement
|
||||
|
||||
### J. Quelles sont les différences fondamentales entre une requête HTTP "POST" et "GET" dans le cadre général des failles de type "Cross Site Request Forgery" (CSRF) ?
|
||||
|
||||
1. Les requêtes POST sont chiffrées par défaut par les navigateurs
|
||||
2. Une requête POST ne peut pas être automatiquement initiée par la simple inclusion d'une balise HTML
|
||||
3. Il n'y a aucune différence
|
||||
Binary file not shown.
|
|
@ -0,0 +1,21 @@
|
|||
# TP - Réaliser un audit de code
|
||||
|
||||
## Objectifs
|
||||
|
||||
- Découvrir les différents critères d'analyse d'une base de code tel que préconisés par l'OWASP
|
||||
- S'initier à la démarche d'audit de code en reproduisant la démarche proposée par le référentiel ASVS sur une application open-source.
|
||||
|
||||
## Contexte et contraintes
|
||||
|
||||
- L'audit devra suivre la méthodologie et la classification préconisées par le référentiel [ASVS](https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf). À vous d'en prendre connaissance
|
||||
avant de vous lancer dans l'audit réel.
|
||||
- Vous pouvez sélectionner n'importe qu'elle application Web à condition qu'elle soit open-source et/ou que vous pouvez fournir un lien vers le dépôt des sources (GIT, SVN, Mercurial...) avec le numéro de version que vous avez audité.
|
||||
- Un exemple de rapport d'audit de code est disponible dans votre espace de partage afin de vous aider à construire votre document.
|
||||
|
||||
## Production attendue
|
||||
|
||||
_Il est bien entendu que je n'attend pas de vous un audit d'une application complète. Dans le temps alloué au TP ce serait impossible (sauf si vous êtes réellement des surdoués dans ce domaine...). Prenez le temps de lire le référentiel dans son ensemble et focalisez vous sur les points qui concernent des failles applicatives._
|
||||
|
||||
- Un rapport d'audit de sécurité calqué sur le modèle fourni avec le sujet de ce TP. Pensez bien à identifier l'application testée et sa version. Prenez le temps de rédiger, la qualité primera sur la quantité.
|
||||
|
||||
_A l'issu de ce TP, nous ferons un debrief ensemble sur les difficultés que vous avez rencontré et sur les points d'incompréhension._
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
|
|
@ -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 ?
|
||||
|
|
@ -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.
|
||||
|
|
@ -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)
|
||||
|
|
@ -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)
|
||||
Loading…
Reference in New Issue