Konttiratkaisujen tietoturva - Tero Niemistö
•Download as PPTX, PDF•
2 likes•374 views
Konttiteknologiat -seminaarissa 6.6.2017 pidetty luento aiheena Konttiratkaisujen tietoturva.
Recommended
Recommended
More Related Content
Similar to Konttiratkaisujen tietoturva - Tero Niemistö
Similar to Konttiratkaisujen tietoturva - Tero Niemistö (20)
Konttiratkaisujen tietoturva - Tero Niemistö
- 2. Kuka olen? • Tero Niemistö • Teknologiajohtaja @Digia • 19 vuotta alalla, viimeiset 7 Digialla • Cloud/Devops/Docker • Kahden lapsen isä https://www.linkedin.com/in/teroniemisto https://twitter.com/tero_niemisto
- 3. “Gartner asserts that applications deployed in containers are more secure than applications deployed on the bare OS” because even if a container is cracked “they greatly limit the damage of a successful compromise because applications and users are isolated on a per-container basis so that they cannot compromise other containers or the host OS”. - Joerg Fritsch, Research Director, Gartner
- 4. But…
- 5. With great power comes great responsibility
- 6. • Ilman tietoista Dockerin tietoturvaamista tietoturva on helposti huonompi kuin perinteisissä järjestelmissä • Tietoturvapäivitykset eivät ole automaattisia, kuten useissa tuotantoympäristöissä • Riski suurempi, koska usein Docker-ympäristössä ajetaan useita eri sovelluksia samalla palvelimella Docker ei takaa tietoturvaa
- 7. Docker Arkkitehtuuri Container App 1 Bins/Libs App 2 Bins/Libs App 3 Bins/Libs Docker Daemon Host
- 8. Docker Image Writable container Add Glassfish image Add Java image Alpine Base Image Kernel
- 10. • Haavoittuvuudet propagoituvat kontissa • Kontit on syytä skannata jatkuvasti haavoittuvuuksilta • Mikäli haavoittuvuus löytyy, täytyy kontti kääntää ja asentaa uudestaan • Ilman kunnollista automaatiota tämä voi olla todella työlästä! Miksi?
- 11. Docker Arkkitehtuurin hyökkäysvektorit App 1 Bins/Libs App 2 Bins/Libs App 3 Bins/Libs Docker Daemon Host
- 12. Konttihyökkäyksen laajentaminen App 1 Bins/Libs App 2 Bins/Libs App 3 Bins/Libs Docker Daemon Host Yhteen konttiin pääseminen • Ohjelmistot epäluotettavista lähteistä • Vanhat versiot • Sovelluksessa oleva aukko Hyökkäyksen laajentaminen • Konttien verkkotaso • Docker Daemon • Host Hyökkäyksen laajentaminen • Konttien verkkotaso • Docker Daemon • Host Hyökkäyksen laajentaminen • Konttien verkkotaso • Docker Daemon • Host Muihin palveluihin vaikuttaminen • Resurssien syöminen / palvelimen hidastaminen • Palvelimen kaataminen Hyökkäyksen jälkien poistaminen • Paikallisten lokien poistaminen
- 13. 5 tyypillistä tietoturvariskiä Dockerin käytössä Kernel Exploits Denial-of-Service (DOS) Container Breakouts Poisoned Images Compromising Secrets
- 15. Koventaminen • Kovennuksilla tarkoitetaan jonkun asian “koventamista” tietoturvallisemmaksi kaventamalla potentiaalisia hyökkäysvektoreita • Kovennussuositukset pohjautuvat usein CIS Benchmarks –suosituksiin (https://www.cisecurity.org/cis-benchmarks/) tai vastaaviin • Kovennussuositukset ovat vain suosituksia, joten on hyvä tunnistaa, mitä voidaan tehdä ja mitä on järkevä tehdä tai ottaa käyttöön • Osa kovennuksista voi olla työläitä toteuttaa ja saattavat rajoittaa paljon asioita sekä haitata suorituskykyä
- 16. Dockerin 3-tasoinen kovennus App 1 Bins/Libs App 2 Bins/Libs App 3 Bins/Libs Docker Daemon Host Kontti Docker Daemon Palvelin
- 18. Kontin kovennus – Kontin luonti • Vastuu ohjelmistokehittäjillä • Käytännössä toteutetaan: • Lukuisilla eri parametreillä Dockerfile – tiedostossa • Kontin sisältöä tulee jatkuvasti skannata uusilta haavoittuvuuksilta, jonka jälkeen kontit on aina rakennettava uudestaan ja vietävä ajoon
- 19. Kontin kovennus – Kontin ajaminen • Vastuu sovellustoimittajalla, jos Docker on osa toimitusta • Vastuu käyttöpalveluilla, jos Docker ajoympäristö on osana palvelua. • Käytännössä toteutetaan: • Palvelinasetuksilla • Parametreillä Docker Compose –tiedostossa • Parametreillä kontin käynnistyksessä
- 20. Kontin kovennus – esimerkkejä: • Luo kontille oma käyttäjätunnus • Tarkista ladattu kontti • Lataa kontit vain luotetuista lähteistä • Aseta kontin juuri ”read only” -tilaan • Luo erillinen verkko konttien välille • Avaa vain tarvittavat portit konttiin • https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.13. 0_Benchmark_v1.0.0.pdf
- 21. 2: Docker Daemon kovennus
- 22. Docker Daemon kovennus • Vastuu Docker-ajoympäristön toimittajalla • Käytännössä toteutetaan: • Palvelinasetuksilla • Docker Daemonin käynnistysparametreillä • Rajoittamalla Docker Daemonin tiedostojen käyttöoikeudet
- 23. Docker Daemon kovennus – esimerkkejä: • Konttien välisen liikenteen estäminen (oletuksena sallittu) • Keskitetty lokitus • https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.13. 0_Benchmark_v1.0.0.pdf
- 25. Palvelimen kovennus • Vastuu käyttöpalvelutoimittajalla sekä Docker-ajoympäristön toimittajalla • Käytännössä toteutetaan: • Palvelinasetuksilla Dockerin suhteen • Palvelimen käyttöjärjestelmäkohtaisella kovennuksella
- 26. Palvelimen kovennus – esimerkkejä: • Auditoi Docker Daemon ja Docker-tiedostot • Päivitä Docker Daemon säännöllisesti • Vain luotetut käyttäjät docker –groupissa • https://benchmarks.cisecurity.org/tools2/docker/CIS_Docker_1.13. 0_Benchmark_v1.0.0.pdf
- 27. App 1 Bins/Libs App 2 Bins/Libs App 3 Bins/Libs Docker Daemon Host 80 443 8080 22
- 28. Yhteenveto • Toimintatapa-muutokset • Konttiteknologiaa hyödynnettäessä tietoturvasta siirtyy sovelluskehittäjien vastuulle osioita, jotka ovat olleet aiemmin palvelinylläpidon vastuulla • Konttiteknologia mahdollistaa myös julkaisuvastuun siirtymisen sovellustoimittajille automatisaation avulla • Hyvät käytänteet / suositukset • Hyvä luoda Docker Compose & Dockerfile templatet joita jaetaan sovellusprojekteille • Automaation rakentaminen sekä tietoturvan skannaukselle että konttien uudelleenkäännöksille ja asennuksille • Mikäli kontteja viedään automaatisaation (=orkestroinnin) avulla tuotantoon, tulee myös julkaisukanava turvata koventamalla.
Editor's Notes
- Kernel exploits Unlike in a VM, the kernel is shared among all containers and the host, magnifying the importance of any vulnerabilities present in the kernel. Should a container cause a kernel panic, it will take down the whole host. In VMs, the situation is much better: an attacker would have to route an attack through both the VM kernel and the hypervisor before being able to touch the host kernel. Denial-of-service attacks All containers share kernel resources. If one container can monopolize access to certain resources–including memory and more esoteric resources such as user IDs (UIDs)—it can starve out other containers on the host, resulting in a denial-of-service (DoS), whereby legitimate users are unable to access part or all of the system. Container breakouts An attacker who gains access to a container should not be able to gain access to other containers or the host. By default, users are not namespaced, so any process that breaks out of the container will have the same privileges on the host as it did in the container; if you were root in the container, you will be root on the host. This also means that you need to worry about potential privilege escalation attacks–whereby a user gains elevated privileges such as those of the root user, often through a bug in application code that needs to run with extra privileges. Given that container technology is still in its infancy, you should organize your security around the assumption that container breakouts are unlikely, but possible. Poisoned images How do you know that the images you are using are safe, haven't been tampered with, and come from where they claim to come from? If an attacker can trick you into running his image, both the host and your data are at risk. Similarly, you want to be sure that the images you are running are up-to-date and do not contain versions of software with known vulnerabilities. Compromising secrets When a container accesses a database or service, it will likely require a secret, such as an API key or username and password. An attacker who can get access to this secret will also have access to the service. This problem becomes more acute in a microservice architecture in which containers are constantly stopping and starting, as compared to an architecture with small numbers of long-lived VMs. This report doesn't cover how to address this, but see the Deployment chapter of Using Docker (O'Reilly, 2015) for how to handle secrets in Docker.