Merge pull request #414 from alphaxr6/main
French translation of the first day of 90 Days of DevOps
This commit is contained in:
Michael Cade
GitHub
commit
d4df029a02
166
2023/fr/2023.md
Normal file
166
2023/fr/2023.md
Normal file
@ -0,0 +1,166 @@
|
||||
# 90DaysOfDevOps
|
||||
|
||||
<p align="center">
|
||||
<img src="2023.png?raw=true" alt="90DaysOfDevOps Logo" width="50%" height="50%" />
|
||||
</p>
|
||||
|
||||
Ce dépôt est utilisé pour documenter mon aventure dans la découverte des principes fondamentaux des notions des DevSecOps
|
||||
|
||||
[](https://ko-fi.com/N4N33YRCS)
|
||||
|
||||
Si vous avez des questions et que vous souhaitez vous impliquer dans le projet, vous pouvez rejoindre le discord et partager vos questions avec la communauté.
|
||||
|
||||
[](https://discord.gg/vqwPrNQsyK)
|
||||
|
||||
Ou nous contacter via twitter : [@MichaelCade1](https://twitter.com/MichaelCade1) Vous pouvez trouver les auteurs des différentes parties de cette édition 2023 dans le tableau suivant
|
||||
|
||||
## Liste des sujets abordés
|
||||
|
||||
| Topic | Author | Date | Twitter Handle |
|
||||
| -------------------------------------- | ----------------------------------- | ------------------- | ----------------------------------------------------------------------------------------------- |
|
||||
| DevSecOps | Michael Cade | 1st Jan - 6th Jan | [@MichaelCade1](https://twitter.com/MichaelCade1) |
|
||||
| Secure Coding | Prateek Jain | 7th Jan - 13th Jan | [@PrateekJainDev](https://twitter.com/PrateekJainDev) |
|
||||
| Continuous Build, Integration, Testing | Anton Sankov and Svetlomir Balevski | 14th Jan - 20th Jan | [@a_sankov](https://twitter.com/a_sankov) |
|
||||
| Continuous Delivery & Deployment | Anton Sankov | 21st Jan - 27th Jan | [@a_sankov](https://twitter.com/a_sankov) |
|
||||
| Runtime Defence & Monitoring | Ben Hirschberg | 28th Jan - 3rd Feb | [@slashben81](https://twitter.com/slashben81) |
|
||||
| Secrets Management | Bryan Krausen | 4th Feb - 10th Feb | [@btkrausen](https://twitter.com/btkrausen) |
|
||||
| Python | Rishab Kumar | 11th Feb - 17th Feb | [@rishabk7](https://twitter.com/rishabk7) |
|
||||
| AWS | Chris Williams | 18th Feb - 24th Feb | [@mistwire](https://twitter.com/mistwire) |
|
||||
| OpenShift | Dean Lewis | 25th Feb - 3rd Mar | [@saintdle](https://twitter.com/saintdle) |
|
||||
| Databases | Taylor Riggan & Andrew Pruski | 4th Mar - 10th Mar | [@triggan](https://twitter.com/triggan) & [@dbafromthecold](https://twitter.com/dbafromthecold) |
|
||||
| Serverless | Kristi Perreault | 11th Mar - 17th Mar | [@kperreault95](https://twitter.com/kperreault95) |
|
||||
| Service Mesh | Marino Wijay | 18th Mar - 24th Mar | [@virtualized6ix](https://twitter.com/virtualized6ix) |
|
||||
| Engineering for Day 2 Ops | Alistair Hey | 25th Mar - 31st Mar | [@alistair_hey](https://twitter.com/alistair_hey) |
|
||||
|
||||
## Progress
|
||||
|
||||
- [✔️] ♾️ 1 > [Retour sur l'édition 2022 et lancement de l'édition 2023](days/day01.md)
|
||||
|
||||
### DevSecOps
|
||||
|
||||
- [✔️] ♾️ 2 > [Vue d'ensemble: DevSecOps](days/day02.md)
|
||||
- [✔️] ♾️ 3 > [Penser comme un attaquant](days/day03.md)
|
||||
- [✔️] ♾️ 4 > [Red Team vs. Blue Team](days/day04.md)
|
||||
- [✔️] ♾️ 5 > [OpenSource Security](days/day05.md)
|
||||
- [✔️] ♾️ 6 > [Hands-On: Building a weak app](days/day06.md)
|
||||
|
||||
### Secure Coding (En cours de traduction)
|
||||
|
||||
- [✔️] 🔐 7 > [Secure Coding Overview](2023/day07.md)
|
||||
- [✔️] 🔐 8 > [SAST Overview](2023/day08.md)
|
||||
- [✔️] 🔐 9 > [SAST Implementation with SonarCloud](2023/day09.md)
|
||||
- [✔️] 🔐 10 > [Software Composition Analysis Overview](2023/day10.md)
|
||||
- [✔️] 🔐 11 > [SCA Implementation with OWASP Dependency Check](2023/day11.md)
|
||||
- [✔️] 🔐 12 > [Secure Coding Practices](2023/day12.md)
|
||||
- [✔️] 🔐 13 > [Additional Secure Coding Practices](2023/day13.md)
|
||||
|
||||
### Continuous Build, Integration, Testing
|
||||
|
||||
- [✔️] ⚒️ > [Container Image Scanning](2023/day14.md)
|
||||
- [✔️] ⚒️ > [Container Image Scanning Advanced](2023/day15.md)
|
||||
- [✔️] ⚒️ > [Fuzzing](2023/day16.md)
|
||||
- [✔️] ⚒️ > [Fuzzing Advanced](2023/day17.md)
|
||||
- [✔️] ⚒️ > [DAST](2023/day18.md)
|
||||
- [✔️] ⚒️ > [IAST](2023/day19.md)
|
||||
- [✔️] ⚒️ > [Practical Lab on IAST and DAST](2023/day20.md)
|
||||
|
||||
### Continuous Delivery & Deployment
|
||||
|
||||
- [✔️] 🚚 21 > [Continuous Image Repository Scan](2023/day21.md)
|
||||
- [✔️] 🚚 22 > [Continuous Image Repository Scan - Container Registries](2023/day22.md)
|
||||
- [✔️] 🚚 23 > [Artifacts Scan](2023/day23.md)
|
||||
- [✔️] 🚚 24 > [Signing](2023/day24.md)
|
||||
- [✔️] 🚚 25 > [Systems Vulnerability Scanning](2023/day25.md)
|
||||
- [✔️] 🚚 26 > [Containers Vulnerability Scanning](2023/day26.md)
|
||||
- [✔️] 🚚 27 > [Network Vulnerability Scan](2023/day27.md)
|
||||
|
||||
### Runtime Defence & Monitoring
|
||||
|
||||
- [✔️] 🏃 28 > [System monitoring and auditing](2023/day28.md)
|
||||
- [✔️] 🏃 29 > [Application level monitoring](2023/day29.md)
|
||||
- [✔️] 🏃 30 > [Detecting suspicious application behavior](2023/day30.md)
|
||||
- [✔️] 🏃 31 > [Runtime network protections and policies](2023/day31.md)
|
||||
- [✔️] 🏃 32 > [Vulnerability and patch management](2023/day32.md)
|
||||
- [✔️] 🏃 33 > [Application runtime and network policies](2023/day33.md)
|
||||
- [✔️] 🏃 34 > [Runtime access control](2023/day34.md)
|
||||
|
||||
### Secrets Management
|
||||
|
||||
- [✔️] 🕵 35 > [Understanding the Importance of Secrets Management](2023/day35.md)
|
||||
- [✔️] 🕵 36 > [Securing Secrets with HashiCorp Vault](2023/day36.md)
|
||||
- [✔️] 🕵 37 > [Working with HashiCorp Vault's Secrets Engines](2023/day37.md)
|
||||
- [✔️] 🕵 38 > [Increase the Security Posture of Your Organization with Dynamic Credentials](2023/day38.md)
|
||||
- [] 🕵 39 > [](2023/day39.md)
|
||||
- [] 🕵 40 > [](2023/day40.md)
|
||||
- [] 🕵 41 > [](2023/day41.md)
|
||||
|
||||
### Python
|
||||
|
||||
- [✔️] 🐍 42 > [Programming Language: Introduction to Python](2023/day42.md)
|
||||
- [✔️] 🐍 43 > [Python Loops, functions, modules and libraries](2023/day43.md)
|
||||
- [✔️] 🐍 44 > [Data Structures and OOP in Python](2023/day44.md)
|
||||
- [✔️] 🐍 45 > [Debugging, testing and Regular expression](2023/day45.md)
|
||||
- [✔️] 🐍 46 > [Web development in Python](2023/day46.md)
|
||||
- [✔️] 🐍 47 > [Automation with Python](2023/day47.md)
|
||||
- [✔️] 🐍 48 > [Let's build an App in Python](2023/day48.md)
|
||||
|
||||
### AWS
|
||||
|
||||
- [✔️] ☁️ 49 > [AWS Cloud Overview](2023/day49.md)
|
||||
- [✔️] ☁️ 50 > [Create Free Tier Account & Enable Billing Alarms](2023/day50.md)
|
||||
- [✔️] ☁️ 51 > [Infrastructure as Code (IaC) and CloudFormation](2023/day51.md)
|
||||
- [✔️] ☁️ 52 > [Identity and Access Management (IAM)](2023/day52.md)
|
||||
- [✔️] ☁️ 53 > [AWS Systems Manager](2023/day53.md)
|
||||
- [✔️] ☁️ 54 > [AWS CodeCommit](2023/day54.md)
|
||||
- [✔️] ☁️ 55 > [AWS CodePipeline](2023/day55.md)
|
||||
|
||||
### Red Hat OpenShift
|
||||
|
||||
- [✔️] ⛑️ 56 > [What does Red Hat OpenShift bring to the party? An Overview](2023/day56.md)
|
||||
- [✔️] ⛑️ 57 > [Understanding the OpenShift Architecture, Installation Methods and Process](2023/day57.md)
|
||||
- [✔️] ⛑️ 58 > [Deploying Red Hat OpenShift on VMware vSphere](2023/day58.md)
|
||||
- [✔️] ⛑️ 59 > [Deploying applications and getting a handle on Security Constraints Context (SCC)](2023/day59.md)
|
||||
- [✔️] ⛑️ 60 > [Looking at OpenShift Projects - Creation, Configuration and Governance](2023/day60.md)
|
||||
- [✔️] ⛑️ 61 > [Understanding Authentication, Role-Based Access Control (RBAC) and Auditing in Red Hat OpenShift: Control and Secure Your Cluster](2023/day61.md)
|
||||
- [✔️] ⛑️ 62 > [Compliance and Vulnerability Scanning provided by Red Hat OpenShift Operators](2023/day62.md)
|
||||
|
||||
### Databases
|
||||
|
||||
- [✔️] 🛢 63 > [An introduction to databases](2023/day63.md)
|
||||
- [✔️] 🛢 64 > [Querying data in databases](2023/day64.md)
|
||||
- [✔️] 🛢 65 > [Backing up and restoring databases](2023/day65.md)
|
||||
- [✔️] 🛢 66 > [High availability and disaster recovery](2023/day66.md)
|
||||
- [✔️] 🛢 67 > [Performance tuning](2023/day67.md)
|
||||
- [✔️] 🛢 68 > [Database security](2023/day68.md)
|
||||
- [✔️] 🛢 69 > [Monitoring and troubleshooting database issues](2023/day69.md)
|
||||
|
||||
### Serverless
|
||||
|
||||
- [✔️] 👩🏿💻 70 > [What is Serverless?](2023/day70.md)
|
||||
- [✔️] 👩🏿💻 71 > [Serverless Compute](2023/day71.md)
|
||||
- [✔️] 👩🏿💻 72 > [Serverless Storage](2023/day72.md)
|
||||
- [✔️] 👩🏿💻 73 > [Serverless APIs](2023/day73.md)
|
||||
- [✔️] 👩🏿💻 74 > [Serverless Orchestration](2023/day74.md)
|
||||
- [✔️] 👩🏿💻 75 > [Serverless & Well Architected](2023/day75.md)
|
||||
- [✔️] 👩🏿💻 76 > [Serverless - Beyond the Basics](2023/day76.md)
|
||||
|
||||
### Service Mesh
|
||||
|
||||
- [✔️] 🧩 77 > [Let's break down a Service Mesh](2023/day77.md)
|
||||
- [✔️] 🧩 78 > [Install and Test a Service Mesh](2023/day78.md)
|
||||
- [✔️] 🧩 79 > [Comparing Different Service Meshes](2023/day79.md)
|
||||
- [✔️] 🧩 80 > [Traffic Engineering Basics](2023/day80.md)
|
||||
- [✔️] 🧩 81 > [Observability in your Mesh](2023/day81.md)
|
||||
- [✔️] 🧩 82 > [Securing your microservices](2023/day82.md)
|
||||
- [✔️] 🧩 83 > [Sidecar or Sidecar-less? Enter Ambient Mesh](2023/day83.md)
|
||||
|
||||
### Engineering for Day 2 Ops
|
||||
|
||||
|
||||
- [] 👷🏻♀️ 84 > [Writing an API - What is an API?](2023/day84.md)
|
||||
- [] 👷🏻♀️ 85 > [Queues, Queue workers and Tasks (Asynchronous architecture)](2023/day85.md)
|
||||
- [] 👷🏻♀️ 86 > [Designing for Resilience, Redundancy and Reliability](2023/day86.md)
|
||||
- [] 👷🏻♀️ 87 > [Zero Downtime Deployments](2023/day87.md)
|
||||
- [] 👷🏻♀️ 88 > [Monitoring, Alerting and On-Call](2023/day88.md)
|
||||
- [] 👷🏻♀️ 89 > [Oops: When something goes wrong - Post Mortems](2023/day89.md)
|
||||
- [] 👷🏻♀️ 90 > [](2023/day90.md)
|
||||
BIN
2023/fr/2023.png
Normal file
BIN
2023/fr/2023.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 159 KiB |
74
2023/fr/days/day01.md
Normal file
74
2023/fr/days/day01.md
Normal file
@ -0,0 +1,74 @@
|
||||
## Retour sur l'édition 2022 et lancement de l'édition 2023
|
||||
|
||||
Bonjour à tous et bienvenue dans l'édition 2023 du #90DaysOfDevOps (90 jours de DevOps). Le but de ce premier jour est de faire un récapitulatif sur l'édition 2022, notamment sur les statistiques, les retours et les idées que nous avons eus pendant l'année.
|
||||
|
||||
### 2022 Recap
|
||||
|
||||
Tout d'abord, WOW ! La mission que j'ai imaginée durant la soirée du nouvel an 2021 était de passer les 90 premiers jours de 2022 à apprendre, documenter et écrire quelques notes après avoir regardé des gens beaucoup plus intelligents que moi sur Youtube.
|
||||
|
||||
Avance rapide d'un an, nous avons aujourd'hui des chiffres incroyables sur le dépôt. Je l'ai déjà mentionné sur le repository, je le redis et je le redirai toujours: tout contenu vaut le coup d'être fait si ça aide au moins une personne. Le nombre d'étoiles (notation) et de forks du repository sont incroyable !
|
||||
|
||||
|
||||
|
||||
|
||||
Egalement, presque **500** contributeurs sur le repository !
|
||||
|
||||
Premièrement, je voudrai remercier tout ceux qui ont partagé le repository avec leur communauté. Apprendre que Microsoft et d'autre grosse entreprise de la tech ont partagés le projet avec leurs équipes est vraiment gratifiant.
|
||||
|
||||
Deuxièmement, je voudrai remercier les contributeurs. Tout à commencé par créer un endroit pour prendre des notes et apprendre en public, il n'a fallu attendre que quelques jours pour voir des gens corriger ma mauvaise traduction et grammaire. (Je suis sûr que la même chose va arriver cette année.) Mais la chose la plus folle qui soit arrivé a été de voir la communauté commencer à traduire le repository dans leur langue maternelle. C'est vraiment incroyable de voir ça arriver et d'aider des gens qui ne parlent pas du tout anglais, apprendre les pouvoirs du DevOps.
|
||||
|
||||
|
||||
|
||||
|
||||
Si vous voulez trouver les contributeurs du dépôt, c'est par [ici](https://github.com/MichaelCade/90DaysOfDevOps/blob/main/Contributors.md)
|
||||
|
||||
|
||||
|
||||
### Apprentissage continu
|
||||
|
||||
J'ai toujours dis, et je continuerai toujours de dire, que nous ne cessons jamais d'apprendre. Si vous pensez que vous connaissez déjà tout, vous vous êtes trompé de domaine. En effet, les choses changent tous les jours et à un rythme phénoménale.
|
||||
|
||||
C'est pour cette raison que nous devons continuer d'apprendre. Pour certains, apprendre est un challenge. Pour ces personnes là, j'espère que vous trouverez un support pédagogique que vous aimerez. J'ai toujours aimé documenté les choses que j'apprends et ainsi, pouvoir les maitriser et mettre la main à la pâte lors de mise en pratique concrète. C'est exactement la genèse de ce projet. C'est partagé les bases fondamentales du DevOps et les outils qui y sont associés. Vous n'allez pas être diplomé d'un diplome d'ingénieur DevOps en suivant le projet, mais vous allez avoir une meilleure compréhension des terminologies et surtout, vous allez pouvoir utiliser, pratiquer des technologies que vous n'auriez probablement pas pu voir dans votre vie de tous les jours.
|
||||
|
||||
Tout le monde évolue et apprends. Ca n'a pas d'importance que vous soyez CTO d'une entreprise éditrice de logiciel ou un administrateur systeme qui veut en apprendre plus sur l'automatisation. Tout le monde apprend et ce petit syndrome de l'imposteur que vous ressentez au fond de vous est tout à fait normal. Mon conseil est le suivant: acceptez le challenge plutôt que de le fuir. Ca vaut vraiment le coup. Plus vous apprendrez et plus vous prendrez de plaisir à apprendre.
|
||||
|
||||
|
||||
### Concentré sur la sécurité
|
||||
|
||||
Pour ceux qui ont suivi le projet depuis le début, vous avez pu vous rendre compte que la partie qui manquait le plus sur l'édition 2022 était la partie sécurité. La sécurité appliqué au DevOps est notamment appelé DevSecOp. Le but étant d'intégré la sécurité dans le cycle infini du DevOps et ainsi, s'assurer que nous pensons à la sécurité de notre système d'information à chaque étape de développement.
|
||||
|
||||
Dans cette édition, nous allons plongé dans les principes et les process de la sécurité lié au DevSecOps. Ainsi, nous en apprendrons encore plus sur les sujets que nous n'avons pas abordé dans la première édition.
|
||||
|
||||
|
||||
### Un petit coup de main de mes amis
|
||||
|
||||
En terme d'écriture, l'édition 2022 a été l'équivalent décrire un article de blog (blog post) par jour. Nous avons écrit plus de 100k mots, et si on devait en écrire un livre (qui est d'ailleurs une option, les instructions peuvent être trouvé dans le dépôt si vous voulez le faire) il ferait plus de 700 pages en format A4.
|
||||
L'idée du livre n'est pas enterré puisque je travaille en "sous marin" sur une version plus petite qui pourrai faire office de giveaway lors de conférence ou de salon.
|
||||
|
||||
L'autre gap pour moi était l'authenticité du projet. Lors de la création du projet, je venais à peine de commencer à apprendre et documenter cette aventure. Cette fois ci, j'ai décidé de demander de l'aide à des amis et à la communauté.
|
||||
|
||||
Il y a 2 raison à ça:
|
||||
|
||||
1. Je pense que c'est important d'avoir plusieurs point de vu sur chacun des sujets abordés. Nous allons tous mieux apprendre sur des sujets dont les articles sont écrits par des experts du domaine.
|
||||
|
||||
2. Certains des amis qui m'aideront auront l'opportunité de faire grandir leur image de marque et potentiellement d'intervenir dans des évènements a propos de leur domaines de compétences.
|
||||
|
||||
Vous trouverez les auteurs (et les liens de leur profil) de cette édition 2023 dans le fichier 2023.md.
|
||||
|
||||
|
||||
Il est venu le temps d'être clair à propos de ce projet. Personne n'est payé, ni pour écrire, ni pour parler du projet. J'ai été approché par des sponsors de nombreuses fois, mais le but premier du projet est de rester impartial, gratuit, pour la communauté et par la communauté. Oui, nous avons utilisé des projets et des solutions technique tout au long du projet, mais aucune entreprise n'a sponsorisé ou n'a son mot à dire sur la rédaction du projet.
|
||||
|
||||
Pour finir, mon employeur, Veeam Software. Je suis extrèmement chanceux de faire partie d'une entreprise qui me permet de faire partie de cette communauté et de documenté ce que j'apprends sans interférences. Je n'ai pas un poste traditionnel qui me permet de faire 9h - 17h (et je suis sur que les nombreuses personnes qui lirons le projet non plus) mais je suis libre de créer et de trouver le temps pour créer des projets comme celui ci.
|
||||
|
||||
|
||||
### Ressources
|
||||
|
||||
Tout au long du projet (comme lors de l'édition 2022), vous pourrez trouver la section ressource. Cette section contient une liste de contenu sur lesquelles, les auteurs et moi, nous sommes appuyés pour documenter le projet. Si vous voulez en apprendre plus, n'hésitez pas à fouiller cette section.
|
||||
|
||||
Vous pouvez trouver l'édition 2022 [ici](https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2022.md)
|
||||
|
||||
Mais également, certains membres de la communauté ont transformé et donné un nouveau look au projet : [GitHub Pages](https://www.90daysofdevops.com/#/)
|
||||
|
||||
Sur la [page de l'édition 2023](https://www.90daysofdevops.com/#/2023) vous trouverez de quoi intéragir avec les membres de la communauté.
|
||||
|
||||
Il est maintenant temps de rentrer dans le vif du sujet. Rendez vous au [jour 2](day02.md).
|
||||
94
2023/fr/days/day02.md
Normal file
94
2023/fr/days/day02.md
Normal file
@ -0,0 +1,94 @@
|
||||
## Vue d'ensemble: DevSecOps
|
||||
|
||||
Bienvenue dans la 2e journée de cette édition 2023. Dans le premier module de ces 6 prochains jours, nous allons aborder les bases fondamentales de ce qu'est le DevSecOps.
|
||||
|
||||
### Qu'est ce que le DevSecOps?
|
||||
|
||||
DevSecOps est une approche du développement logiciel dont le but est de réunir les équipes de développement, de sécurité et les équipes opérationnelles autour du développement et de la sécurisation d'une application.
|
||||
|
||||
L'approche est basée sur l'intégration, la livraison et le déploiement continu dont le but est de délivrer des mise à jours et des nouvelles fonctionnalités plus rapidement.
|
||||
|
||||
Dans l'approche DevSecOps, la sécurisation se fait dès le développement de l'application, et non après coup. Concrètement, les tests de sécurité, la surveillance (monitoring) et les autres mesures de sécurisation sont développés dès le début du cycle de vie du développement logiciel, plutôt qu'ajouté après.
|
||||
|
||||
DevSecOps oeuvre pour améliorer la collaboration et la communication entre les équipes de développement, de sécurité et les équipes opérationnelles afin de créer des processus de développement logiciel plus efficace.
|
||||
|
||||
### DevSecOps vs DevOps
|
||||
|
||||
J'utilise le terme "vs" ici de manière anecdotique. Le but n'étant pas de confronter les 2 termes, mais bien d'en comprendre les différences. Si vous vous rappelez bien de l'édition 2022, l'objectif du DevOps était d'améliorer la vitesse de traitement et de test, la fiabilité et la qualité générale des logiciels déployés.
|
||||
|
||||
DevSecOps est une extension de la philosophie DevOps. Le but est d'intégrer les bonnes pratiques en terme de sécurité lors du processus de dévelopement d'un logiciel. Ainsi, la sécurité du logiciel est intégralement partie prenante du développement d'un logiciel depuis le début plutôt qu'à la fin. Cela va aider à réduire les risques de vulnérabilités et à les rendre plus facile à identifier et à patcher.
|
||||
|
||||
Le DevOps se concentre sur l'amélioration de la communication entre les équipes de développements et les équipes opérationnelles afin d'améliorer la rapidité de traitement, la fiabilité, et la qualité des logiciels délivré. Le DevSecOps quant à lui, se concentre sur l'intégration des bonnes pratiques de sécurité dans le processus de développement d'une application afin de réduire les risques de vulnérabilité et pour améliorer la sécurité du logiciel et des sytèmes d'informations en général.
|
||||
|
||||
### Automatisation de la sécurité
|
||||
|
||||
L'automatisation de la sécurité fait référence a l'utilisation de différentes technologies, différents outil, pour lancer des tâches de sécurité sans intervention humaine.
|
||||
Il existe différent moyen de sécurisé une application ou son SI, par exemple, l'utilisation d'un outil de monitoring de réseau pour détecter des menaces et les bloquer (IPS/IDS) ou l'utilisation d'outil basé sur des intelligence articielle pour analyser des paterns d'attaque pour identifier des activités inhabituelles. Les outils d'automatisation des sytèmes de sécurité ont été conçu pour faire en sorte que la sécurité d'une application, d'un SI ou autre se fasse de manière efficace et pour réduire les charges de travail redondantes des ingénieur spécialisé en cybersécurité.
|
||||
|
||||
La plus value qu'apporte le DevSecOps est la possibilité d'automatisé un grand nombre de tâches lorsqu'on développe et qu'on délivre une application. Lorsqu'on ajoute la partie sécurité dès le début du cycle de développement, il faut prendre en compte l'automatisation de cette partie sécurité.
|
||||
|
||||
### Security at Scale (Containers and Microservices)
|
||||
|
||||
La création et le déploiement de microservice et de container ont changé les manière de travailler de la plus part des entreprises, notamment grace à la grande scalabilité et dynamique que peuvent offrir ces nouveaux services.
|
||||
|
||||
C'est également pour cette raison que nous devons introduire l'automatisation des tâches de sécurité dans les principes fondamentaux du DevOps. Nous devons nous assurer que la sécurité des containers et des microservices est conforme aux guidelines de sécurité mise en place dans les entreprises.
|
||||
|
||||
Pour être un peu plus précis, grâce aux technologies cloud-native, les entreprises ne peuvent plus se permettre de garder une politique de sécurité statique. Les modèles de sécurité des entreprises se doivent d'être aussi dynamique que les charges de travail et de comment elles tournent.
|
||||
|
||||
Les équipes DevOps se doivent d'inclure des tâches automatique de gestion de la sécurité pour protéger l'environnement et les données dans son ensemble (Système d'information de manière générale)
|
||||
|
||||
La liste suivante est tiré du post [RedHat](https://www.redhat.com/en/topics/devops/what-is-devsecops)
|
||||
|
||||
- Standardiser et automatiser l'environnement: chaque service doit avoir le moins de privilèges possible afin de minimiser les connections et les accès non autorisé.
|
||||
|
||||
- Centraliser les identités utilisateur et les RBAC: Des RBAC consciencieusement controlés et une centralisation de l'authentification sont des mécanismes essentiels pour sécuriser les microservices.
|
||||
|
||||
- Isoler les container, les microservices et le réseaux associé les uns des autres: Ce qui inclu également les donnés "chaudes", lesdonnées "froides" et les données en circulation. Toutes données représentent une grosses valeurs pour les attaquants.
|
||||
|
||||
- Chiffrer les données entre les apps et les services: Un orchestrateur de container (kub) avec une intégration de fonctionnalitées de sécurités aide a minimiser les chances d'accès non autorisé.
|
||||
|
||||
- Créer des API Gateways sécurisé: Sécurisé les API augmente la visibilité sur les autorisations et le routing. En réduisant l'exposition des API, les entreprises et organisation peuvent réduire les surfaces d'attaques.
|
||||
|
||||
### La sécurité au centre de tout
|
||||
|
||||
Peu importe de votre parcours dans l'IT, vous ne pouvez pas être passé à coté du faite que la sécurité est un sujet très important dans toutes l'industries récemment. C'est notamment dû a l'apparition de breches de sécurité dans des grandes entreprises ou l'utilisation de mauvaises habitudes en matières de sécurités. De mon point de vu, la création et le développement de logiciels et d'application est beaucoup plus réalisable et accessible aujourd'hui qu'avant. Mais lors de la création d'application, l'exposition aux vulnérabilité est nettement en hausse. Ceci permets à de mauvaises personnes de voler des données, lancer des ransomware et causer la fermeture d'entreprises. Nous avons déjà beaucoup discuté de ce qu'est le DevSecOps, mais je crois fortement qu'explorer les vecteurs d'attaques et de comprendre pourquoi nous devons protéger notre cycle de développement est inavitable pour éviter les attaques informatiques, ou du moins, réduire les surfaces d'attaques.
|
||||
|
||||
|
||||
### Cybersecurity vs DevSecOps
|
||||
|
||||
Il est important de noter les différences entre cybersécurité et DevSecOps afin de comprendre pourquoi la sécurité doit être intégré dans les process, les principes et la méthodologie DevOps.
|
||||
|
||||
La cybersécurité consiste à protéger le système d'information (données, systèmes, réseaux) d'attaquant malveillant, de voleur et de dommages physique ou virtuel. Il est important d'identifié et de comprendre les vulnérabilités, de mettre en place des mesures de sécurités, et de déployer des services de monitoring.
|
||||
|
||||
De l'autre côté, le DevSecOps et une combinaison des pratiques de développements, de sécurité et d'opérations. C'est une philosophie dont le but est d'intégré la sécurité lors du développement d'une application plutôt que de l'intégrer après-coup. Cela implique la collaboration entre les équipes de développement, de sécurité et les équipes opérationnelle durant le cycle de développement des systèmes d'informations.
|
||||
|
||||
Voici les différences notables entre la cybersécurité et la philosophie DevSecOps:
|
||||
|
||||
**Focus**: Les équipes de cybersécurité sont principalement concentré sur la protection du systèmes d'information des menaces, alors que le DevSecOps se concentre sur l'intégration de la sécurité dans les process de développements.
|
||||
|
||||
**Scope**: La cybersécurité couvre une grande diversité de sujets, notamment la sécurité des réseaux, des données, des applications et bien plus encore. Le DevSecOps, de l'autre côté, se concentre sur l'amélioration de la sécurité dans le développement et le déploiement des applications.
|
||||
|
||||
**Approach**: Les équipes de cybersécurité implémentent des mesures de sécurités après que les processus de développement soient finis. L'approche DevSecOps est d'intégré la partie sécurisation dès le début des processus de développement.
|
||||
|
||||
**Collaboration**: La cybersécurité implique souvent la collaboration entre les équipes IT et les équipes sécurité, alors que le DevSecOps implique la communication entre les équipes de développement, de sécurité, et les équipes opérationnelles.
|
||||
|
||||
|
||||
## Ressources
|
||||
|
||||
Durant tous le projet, vous verrez apparaitre une liste de ressource qui vous permettrons de creuser un peu plus dans les différents sujets abordé.
|
||||
|
||||
- [TechWorld with Nana - What is DevSecOps? DevSecOps explained in 8 Mins](https://www.youtube.com/watch?v=nrhxNNH5lt0&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=1&t=19s)
|
||||
|
||||
- [What is DevSecOps?](https://www.youtube.com/watch?v=J73MELGF6u0&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=2&t=1s)
|
||||
|
||||
- [freeCodeCamp.org - Web App Vulnerabilities - DevSecOps Course for Beginners](https://www.youtube.com/watch?v=F5KJVuii0Yw&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=3&t=67s)
|
||||
|
||||
- [The Importance of DevSecOps and 5 Steps to Doing it Properly (DevSecOps EXPLAINED)](https://www.youtube.com/watch?v=KaoPQLyWq_g&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=4&t=13s)
|
||||
|
||||
- [Continuous Delivery - What is DevSecOps?](https://www.youtube.com/watch?v=NdvMUcWNlFw&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=5&t=6s)
|
||||
|
||||
- [Cloud Advocate - What is DevSecOps?](https://www.youtube.com/watch?v=a2y4Oj5wrZg&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=6)
|
||||
|
||||
- [Cloud Advocate - DevSecOps Pipeline CI Process - Real world example!](https://www.youtube.com/watch?v=ipe08lFQZU8&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=7&t=204s)
|
||||
|
||||
J'espère que cette journée à attiser votre curiosité sur les sujets abordé et que les ressources précédemment listé vous aiderons à creuser un peu plus dans les différents topics. Lors de la [Day 3](day03.md) nous essaierons de comprendre comment un attaquant peut réfléchir et ainsi comprendre pourquoi et comment nous pouvons protéger nos SI et application dès le début.
|
||||
96
2023/fr/days/day03.md
Normal file
96
2023/fr/days/day03.md
Normal file
@ -0,0 +1,96 @@
|
||||
## Penser comme un attaquant
|
||||
|
||||
Hier, nous avons abordé en détail ce qu'est le DevSecOps. Aujourd'hui, nous allons parler des caractéristiques d'un attaquant. Pour comprendre un attaquant, nous devons penser comme un attaquant.
|
||||
|
||||
|
||||
### Les caractéristiques d'un attaquant
|
||||
|
||||
Pour commencer, toutes les entreprises et tous les software sont des vecteurs d'attaque pour un hacker. Il n'existe pas d'endroit 100% sûr. Tout ce qui est possible de faire, c'est de rendre un réseau, une SI, une entreprise, moins "attirante" aux hackers.
|
||||
|
||||
|
||||
***[image from this source](https://www.trainerize.me/articles/outrun-bear/)***
|
||||
|
||||
En partant de ce principe, les attaquants sont des menaces constantes.
|
||||
|
||||
Ces personnes malveillantes vont identifier les vulnérabilités d'un système en lançant des attaques dans un ordre spécific afin d'avoir accès au SI et extraire des data, ou lancer un ransomware, bref, pour remplir la mission qu'ils se sont attribué.
|
||||
|
||||
Les hackers peuvent être chanceux, mais ils travaillent toujours sur des attaques ciblé spécifiques.
|
||||
|
||||
Ils peuvent trouver des brêches rapidement, ou non. Toutes les attaques seront différentes.
|
||||
|
||||
### Leur motivation
|
||||
|
||||
Dans notre rôle d'ingénieur DevOps, nous allons provisionner des infrastructures, des softwares, ou autre. Nous allons probablement déployer tout ça sur différents environnements, différents cloud, différents types de virtualisation et de containerisation.
|
||||
|
||||
Nous devons nous poser les bonnes questions:
|
||||
|
||||
- **Comment** peuvent ils nous attaquer ?
|
||||
- **Pourquoi** nous attaqueraient ils ?
|
||||
- **Qu'avons** nous qui puissent avoir de la valeur pour un attaquant ?
|
||||
|
||||
Les motivations d'attaques sont différentes selon les attaquants. Ca peut également être pour s'amuser... Je pense que nous sommes tous passé par là à un moment donné de notre vie, à l'école par exemple, en allant un peu trop loin dans la découverte du réseau de notre fac ou lycée par exemple.
|
||||
|
||||
Mais nous avons pu voir dans les récentes attaques que celles-ci ont plutôt des objectifs pécunier ou politiques.
|
||||
|
||||
Par exemple, nous avons vu des workspace Kubernetes être utilisé par des attaquants pour se servir de la puissance de calcul disponible afin de miner de la crypto monnaie.
|
||||
|
||||
Dans le coeur des attaquants, leur objectif principal est la **DATA**.
|
||||
|
||||
Les données d'une entreprises sont extrèmement profitable sur le marché noir. C'est pourquoi nous mettons beaucoup d'effort à protéger nos données et s'assurer qu'elles soient sécurisées et chiffrées.
|
||||
|
||||
|
||||
### Attack Maps
|
||||
|
||||
Dans le cadre d'une attaque planifié, les attaquants vont devoir mettre en place un plan en identifiant quels sont les services et les types de données ciblées.
|
||||
|
||||
Un "schéma d'attaque" (attack map) est une représentation visuel d'une attaque sur un réseau donné. Ce schéma montre les différentes étapes d'une attaques, les outils et techniques utilisé par un attaquants, ainsi que les différents point d'entrées et de sortis d'un réseau. Un schéma d'attaque peut être utilisé pour analyser les détails d'une attaque précédentes, identifier les vulnérabilités d'un réseau et planifier et construire les défenses contre de futures attaques. Elle peut également être utilisé pour communiquer des informations à des personnes non habitué à du langage techniques, comme des directeurs exécutifs, des managers, ou des équipes de juristes.
|
||||
|
||||
Vous pouvez voir dans la description ci-dessous qu'une schéma visuel d'attaque doit être créé par toutes les équipes. (red team et blue team. Sujet que nous couvrirons plus tard.)
|
||||
|
||||
Si vous souhaitiez construire un schéma d'attaque de votre réseau privé, il serait important de noter les points suivants:
|
||||
|
||||
- Construire un schéma de vos applications en y incluant les fluxs de communications et les technologies utilisées.
|
||||
|
||||
- Les listes des vulnératilitées et des surfaces d'attaques potentielles.
|
||||
|
||||
- Prendre conscience et schématiser la confidentialité, l'intégrité et la disponibilité des données pour chaque connections/intéraction avec des applications.
|
||||
|
||||
- Schématiser l'intégralité des attaques et vulnérabilités possible.
|
||||
|
||||
Un schéma d'attaque doit ressembler à ça:
|
||||
|
||||
|
||||
|
||||
En étudiant ce schéma, nous pouvons nous attendre à une attaque par déni de service (DOS) ou une attaque man-in-the-middle afin d'accéder au Bucket S3 pour éviter l'application de sauvegarder les données ou pour forcer l'application à sauvegarder de mauvaises données.
|
||||
|
||||
Ce schéma n'est jamais définitif. Pour la même raison que votre application va constamment évoluer en fonction des feedback, ce schéma d'attaque doit constamment évoluer et être testé. Chaque test doit fournir des feedbacks afin de solidifier les défenses d'une application ou d'un système d'information. Nous pourrions appeler ça "Réponse Continue" dans la boucle des feedback liées à la sécurité.
|
||||
|
||||
Pour améliorer la sécurité, nous devons suivre 3 modèles différents:
|
||||
|
||||
- **Good** - Construire l'application selon un modèle "security by design" afin de réduire les attaques potentielles.
|
||||
|
||||
- **Better** - Prioriser et construire des outils de sécurité pour les problèmes identifié lors du cycle de développement.
|
||||
|
||||
- **Best** - Construire et automatiser des scripts lors des déploiement pour détecter des soucis, faire des test unitaire, faire des tests de sécurité et des "Black Box" tests.
|
||||
|
||||
La sécurité peut être une contrainte lors de la conception d'un design.
|
||||
|
||||
## Resources
|
||||
|
||||
- [devsecops.org](https://www.devsecops.org/)
|
||||
|
||||
- [TechWorld with Nana - What is DevSecOps? DevSecOps explained in 8 Mins](https://www.youtube.com/watch?v=nrhxNNH5lt0&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=1&t=19s)
|
||||
|
||||
- [What is DevSecOps?](https://www.youtube.com/watch?v=J73MELGF6u0&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=2&t=1s)
|
||||
|
||||
- [freeCodeCamp.org - Web App Vulnerabilities - DevSecOps Course for Beginners](https://www.youtube.com/watch?v=F5KJVuii0Yw&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=3&t=67s)
|
||||
|
||||
- [The Importance of DevSecOps and 5 Steps to Doing it Properly (DevSecOps EXPLAINED)](https://www.youtube.com/watch?v=KaoPQLyWq_g&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=4&t=13s)
|
||||
|
||||
- [Continuous Delivery - What is DevSecOps?](https://www.youtube.com/watch?v=NdvMUcWNlFw&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=5&t=6s)
|
||||
|
||||
- [Cloud Advocate - What is DevSecOps?](https://www.youtube.com/watch?v=a2y4Oj5wrZg&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=6)
|
||||
|
||||
- [Cloud Advocate - DevSecOps Pipeline CI Process - Real world example!](https://www.youtube.com/watch?v=ipe08lFQZU8&list=PLsKoqAvws1pvg7qL7u28_OWfXwqkI3dQ1&index=7&t=204s)
|
||||
|
||||
On se retrouver lors du [jour 4](day04.md)
|
||||
87
2023/fr/days/day04.md
Normal file
87
2023/fr/days/day04.md
Normal file
@ -0,0 +1,87 @@
|
||||
## <span style="color:red">Red Team</span> vs. <span style="color:blue">Blue Team</span>
|
||||
|
||||
J'aimerai revenir sur quelque chose que j'ai mentionné hier: <span style="color:red">**Red**</span> et <span style="color:blue">**Blue**</span> teams.
|
||||
|
||||
Dans le domaine de la sécurité, les <span style="color:red">**Red**</span> teams et <span style="color:blue">**Blue**</span> teams travaillent comme attaquants et défenseurs pour améliorer la sécurité d'une entreprise et d'une organisation
|
||||
|
||||
Les 2 équipes travaillent pour améliorer la sécurité de l'entreprise, mais de manières différentes.
|
||||
|
||||
La <span style="color:red">**Red**</span> team à le rôle d'attaquant. Cette équipe essaye de trouver des vulnérabilitées dans de code d'une application ou dans l'infrastructure d'un système d'information. Ils essayent alors de casser les défenses et de s'introduire dans le système informatique de l'entreprise.
|
||||
|
||||
La <span style="color:blue">**Blue**</span> team à plutôt un rôle de défenseur. Leur objectif et de défendre le SI contre les attaquants et de répondre aux incidents qui peuvent arriver.
|
||||
|
||||
|
||||
***[image from this source](https://hackernoon.com/introducing-the-infosec-colour-wheel-blending-developers-with-red-and-blue-security-teams-6437c1a07700)***
|
||||
|
||||
### Les bénéfices
|
||||
|
||||
Une bonne façon d'amélioré la sécurité d'une entreprise peut être d'organiser des exercices entre les <span style="color:red">**Red**</span> team et <span style="color:blue">**Blue**</span> team. L'idée est de créer un scénario au plus proche de la réalité et d'une véritable attaque. Voici quelques-uns des domaines dans lesquels cette approche sera utile :
|
||||
|
||||
- Découverte des vulnérabilités
|
||||
- Durcissement (hardening)
|
||||
- Gagner de l'expérience dans la détection et l'isolement des attaques
|
||||
- Contruire des plans de réponses et de remédiation (+ PRA/PCA)
|
||||
- Faire prendre conscience de l'importance de la sécurité dans l'entreprise.
|
||||
|
||||
### <span style="color:red">Red Team</span>
|
||||
|
||||
La NIST (national institute of standards and technology) décrit la <span style="color:red">**Red**</span> team de la manière suivante:
|
||||
|
||||
"Un groupe de personne organisé et autorisé a émuler les capacité d'attaque ou d'exploitation contre la sécurité d'une entreprise."
|
||||
|
||||
Dans une scénario de simulation d'attaque, ils jouent les "méchants".
|
||||
|
||||
Lorsque l'on parle de <span style="color:red">**Red**</span> team et <span style="color:blue">**Blue**</span> team, il en va au delà des simples processus de DevSecOps et des principes des cycles de vie logiciel. Néanmoins, en apprendre un peu plus sur la sécurité de manière général ne fera de mal à personne. Qui peut le plus, peut le moins.
|
||||
|
||||
La tâche principal de la <span style="color:red">**Red**</span> team est de penser comme un attaquant (ce que nous avons vu lors de notre dernière session.) notamment en y ajoutant les principes de social engineering et y incluant toutes les équipes de l'entreprise afin de potentiellement les manipuler et avoir un accès au réseau et aux services informatiques dans son ensemble.
|
||||
|
||||
Une partie fondamentale de la <span style="color:red">**Red**</span> team est de comprendre les principes de fonctionnement du cycle de vie de développement d'un logiciel. En comprenant comment les applications sont constuites, il est plus facile d'identifier des faiblesses et des failles, de réécrire un programme et de procéder à une élévation de privilège ou de lancer un exploit.
|
||||
|
||||
Vous devez avoir déjà entendu parler du terme "Penetration testing" ou "pen test". Pour une <span style="color:red">**Red**</span> team, cela signifie d'identifier et d'essayer d'exploiter des vulnérabilités connues dans un environnement données. Nous couvrirons un peu plus tard comment la monté en puissance des outils open-source peut contribuer à aider les membres des <span style="color:red">**Red**</span> teams.
|
||||
|
||||
### <span style="color:blue">Blue Team</span>
|
||||
|
||||
La NIST (national institute of standards and technology) décrit la <span style="color:blue">**Blue**</span> team de la manière suivante:
|
||||
|
||||
"L'équipe responsable de la défense du système d'information d'une entreprise en maintenant un haut niveau de sécurité contre une équipe d'attaquant."
|
||||
|
||||
La <span style="color:blue">**Blue**</span> team joue la défense. Il ont la charge d'analyser les politiques de sécurité actuelle d'une entreprise et de mettre des actions en place pour empêcher ou ralentir les attaques. La <span style="color:blue">**Blue**</span> team est également en charge du monitoring continu (notion que nous avons couvert à la fin de l'édition 2022) de brêches et de vulnérabilité.
|
||||
|
||||
En tant que membre de la <span style="color:blue">**Blue**</span>, vous allez devoir comprendre quelles type d'asset vous devez protéger, et comment les protéger de la meilleure manière possible. Dans l'IT aujourd'hui, nous avons de nombreuses manière de faire tourner nos workload, nos applications, et d'héberger nos données.
|
||||
|
||||
- Etude de risque - L'étude de risque vous apportera une meilleure vision des asset les plus critiques de votre entreprise/business.
|
||||
|
||||
- Veille technologique - Quels sont les menaces ? Il y a des milliers de vulnérabilités, dont beaucoup qui ne sont pas patché. Comment atténuer les risques sans ralentir et interrompre le business de votre entreprise ?
|
||||
|
||||
### Cybersecurity colour wheel
|
||||
|
||||
Comme l'important de la sécurité informatique grandit, notamment à cause de l'impact que peuvent avoir les attaques sur les entreprises, il y a un besoin plus important que les simples <span style="color:red">**Red**</span> and <span style="color:blue">**Blue**</span> teams lorsque l'on parle de sécurité à l'intérieur d'un business.
|
||||
|
||||
|
||||
|
||||
***[image from this source](https://hackernoon.com/introducing-the-infosec-colour-wheel-blending-developers-with-red-and-blue-security-teams-6437c1a07700)***
|
||||
|
||||
- La <span style="color:yellow">**Yellow Team**</span> sont les "builders", les ingénieurs et les développeurs qui contruisent les applications.
|
||||
|
||||
"Nous avons les <span style="color:red">**Red**</span> and <span style="color:blue">**Blue**</span> comme nous avons toujours eu jusqu'à présent. Maintenant, avec la création de la <span style="color:yellow">**Yellow**</span> Team, nous avons d'autre équipe de couleur qui se créé (Orange, Green, et Purple) dédié à créer un esprit collaboratif et à mixer les skills entre les attaquants, les défenseurs, et les développeurs. Il est important de rendre le code plus sécurisé, et par extension, l'entreprise."
|
||||
|
||||
La citation au dessus est tiré de la première source listé à la fin du post.
|
||||
|
||||
<span style="color:red">**Red**</span>, <span style="color:blue">**Blue**</span>, <span style="color:yellow">**Yellow**</span> sont les couleurs primaires. En les combinant, nous commencons a comprendre où interviennent les autres couleurs (ou couleurs secondaire).
|
||||
|
||||
- La <span style="color:purple">**Purple Team**</span> - The special team! Si vous prenez le <span style="color:blue">**Blue**</span> et le <span style="color:red">**Red**</span>, vous obtenez le <span style="color:purple">**Purple**</span>. Si ovus intégré les processus de défense dans les processus d'attaque et que vous collaborez en partageant le savoir des 2 équipes, vous obtiendrez une meilleure politique de sécurité dans son ensemble.
|
||||
|
||||
- La <span style="color:green">**Green Team**</span> - Feedback loop, la <span style="color:green">**Green**</span> team va récupérer et rassembler les feedback interne de la <span style="color:blue">**Blue**</span> team et travailler étroitement avec la <span style="color:yellow">**Yellow**</span> team pour être plus efficace. Mélanger la <span style="color:blue">**Blue**</span> et la <span style="color:green">**Green**</span> et vous <span style="color:purple">**obtenez**</span>?
|
||||
|
||||
- La <span style="color:orange">**Orange Team**</span>, comme la <span style="color:green">**Green**</span> team, travaille avec la <span style="color:blue">**Blue**</span> team pour les feedbacks, la <span style="color:orange">**Orange**</span> team, travaille avec la <span style="color:red">**Red**</span> team et partager les informations apprises avec la <span style="color:yellow">**Yellow**</span> team pour améliorer la sécurité du code.
|
||||
|
||||
Lorsque j'ai commencé a chercher ces notions, je me suis rendu compte que nous nous éloignons un peu des sujets DevOps habituel. Si une personne de la sphère DevSecOps lis ceci, est ce que ça vous parait correct ? Utils ? Et avez vous quelque chose à ajouter ?
|
||||
|
||||
|
||||
## Resources
|
||||
|
||||
- [Introducing the InfoSec colour wheel — blending developers with red and blue security teams.](https://hackernoon.com/introducing-the-infosec-colour-wheel-blending-developers-with-red-and-blue-security-teams-6437c1a07700)
|
||||
|
||||
|
||||
On se retrouve au [Day 5](day05.md).
|
||||
|
||||
64
2023/fr/days/day05.md
Normal file
64
2023/fr/days/day05.md
Normal file
@ -0,0 +1,64 @@
|
||||
## Open Source Security
|
||||
|
||||
Les logiciels et solutions Open-Source ont été massivements adopté ces dernières années par les entreprises. Cela est dû notamment à l'approche communautaire et collaborative des projets.
|
||||
|
||||
L'appelation Open-Source fait référence à des logiciels/application dans le domaine publique qui peuvent être utilisé, modifié et partagé gratuitement.
|
||||
|
||||
La raison principale de cette adoption massive de solution Open Source vient du fait que ces solutions sont souvent utilisé en complément de solutions propriétaire, ce qui permet d'accélerer le time-to-market des entreprise. L'utilisation de solutions Open Source accélère le développement des applications et aide les entreprises à pousser leurs produits sur le marché plus rapidement.
|
||||
|
||||
|
||||
### Qu'est-ce que la sécurité Open Source ?
|
||||
|
||||
La sécurité Open Source fait référence aux pratiques de sécurité mise en place pour sécuriser un système d'information qui utilise des logiciel open source.
|
||||
|
||||
Comme mentionné précédemment, les solutions open-source sont libre d'être utilisé, modifié et distribué gratuitement. Ces solutions sont souvent développer par une communauté de volontaire. Néanmoins, il y a de plus en plus de gros éditeur de logiciel qui contribuent à des projet open-source. Il n'y à qu'a regarder le repository Kubernetes pour se rendre compte des éditeurs qui ont décidé d'investir dans le projet.
|
||||
|
||||
Comme les solutions Open Source sont gratuite, elles sont facilement utilisé et étudié, permettant ainsi d'améliorer leur sécurité. Néanmoins, il est important de s'assurer que ces solutions sont utilisées de manière responsable et que les vulnérabilitées qui peuvent être trouvé sont communiqué rapidement pour maintenir un haut niveau de sécurité.
|
||||
|
||||
|
||||
### Comprendre la supply chain de la sécurité des solutions Open Source
|
||||
|
||||
J'ai l'habitude de documenter mes trouvailles dans de petits paragraphes lorsque les sources vidéos sont assez longue. Néanmoins, cette vidéo là ne dure que 10 minutes, du coup, il est probablement plus simple que je vous fournisse le lien de la vidéo directement. [Understanding Open-Source Supply Chain Security](https://www.youtube.com/watch?v=pARGj6j0-ZY)
|
||||
|
||||
Que l'on soit une entreprise éditeur de logiciel qui utilise des solutions Open Source avec parcimonie, un projet communautaire qui utilise des packages Open Source ou autre, nous devons être conscient des enjeux de sécurité et proposer une meilleure visibilité entre les projets.
|
||||
|
||||
|
||||
### Les 3 As de la sécurité des outils Open Sources
|
||||
|
||||
Une autre source que j'ai trouvé intéressant d'aborder ici nous viens d'IBM, le lien sera disponible dans la section ressource.
|
||||
|
||||
- **Assess** - Evaluer la santé du projet, si le repository est plutot actif, quel est le temps de réponse de la communauté qui maintiens le projet ? Si vous souhaitez utiliser une solution open source dont ces signaux sont mauvais, vous n'allez probablement pas être très content de la sécurité du projet.
|
||||
|
||||
On peut également jeter un oeil au modèle de sécurité mise en place sur le projet, comment sont fait les reviews du code, les validations des données, les tests spécialisé pour la sécurité, et surtout, où se situe le projet par rapport aux CVE déjà sortie ?
|
||||
|
||||
Quelles sont les dépendances du projet ? Vous devriez également regarder la santé générale des dépendants pour être sûr que l'intégralité de la stack de présente pas de risque de sécurité.
|
||||
|
||||
- **Adopt** - Si vous souhaitez utiliser une solution open source à l'intérieur de votre projet, ou comme une application Stand Alone, vous devez décider rapidement qui va manager l'application et la maintenir au sein de votre organisation ? Mettre en place une vrai gouvernance.
|
||||
|
||||
- **Act** - La sécurité est la responsabilité de tous, pas seulement la communauté de la solution. En tant qu'utilisateur, il est important de communiquer et de donner du feedback du projet.
|
||||
|
||||
|
||||
### Vulnérabilité Log4j
|
||||
|
||||
En 2022, une important vulnérabilité à été mise en lumière (Log4j (CVE-2021-44228) RCE Vulnerability)
|
||||
|
||||
Log4j est une librairie assez commune de logging Java. Cette vulnérabilité a affecté des millions d'application basé sur du java.
|
||||
|
||||
Une personne malveillante pouvait utiliser cette vulnérabilité dans une application pour gagner accès à un système.
|
||||
|
||||
2 choses importantes que j'ai mentionné:
|
||||
|
||||
- Des **millions** d'application utilisent ce package.
|
||||
- Des **acteurs malveillants** peuvent utiliser cette vulnérabilité pour avoir accès à un système ou pour déployer un malware dans un environnement.
|
||||
|
||||
Pourquoi je mentionne cet exemple ? La sécurité d'un système ne s'arrête jamais. La croissance de l'adoption d'outil open source à augmenter les vecteurs d'attaques sur des applications et c'est pourquoi nous devons tous faire un effort concernant la sécurité.
|
||||
|
||||
|
||||
## Ressources
|
||||
|
||||
- [Open Source Security Foundation](https://openssf.org/)
|
||||
- [Snyk - State of open source security 2022](https://snyk.io/reports/open-source-security/)
|
||||
- [IBM - The 3 A's of Open Source Security](https://www.youtube.com/watch?v=baZH6CX6Zno)
|
||||
- [Log4j (CVE-2021-44228) RCE Vulnerability Explained](https://www.youtube.com/watch?v=0-abhd-CLwQ)
|
||||
|
||||
Rendez vous au [Day 6](day06.md).
|
||||
0
2023/fr/days/day06.md
Normal file
0
2023/fr/days/day06.md
Normal file
Loading…
Reference in New Issue
Block a user