Sanomme usein: "HTTPS on suojattu" tai "HTTP ei ole turvallinen". Mutta tarkoitamme sitä, että "HTTPS: ää on vaikea ryöstää ja se tekee ihmisen välissä olevat hyökkäykset vaikeaksi" tai "isoäidilläni ei ole vaikeuksia törmätä HTTP: hen".
Siitä huolimatta HTTPS on hakkeroitu, ja joissakin olosuhteissa HTTP on riittävän turvallinen. Lisäksi, jos löydän hyödynnettävissä olevan vian HTTPS: ää tukevassa yhteisessä toteutuksessa (ajattele OpenSSL: ää ja Heartbleediä), HTTPS: stä voi tulla hakkerointiyhdyskäytävä, kunnes toteutus on korjattu.
HTTP ja HTTPS ovat protokollia, jotka on määritelty IETF RFC: ssä 7230-7237 ja 2828. HTTPS suunniteltiin suojatuksi HTTP: ksi, mutta HTTPS on turvallinen ja HTTP ei silti piilota tärkeitä poikkeuksia.
Virtuaalikoneet (VM) ja kontit on määritelty vähemmän tarkasti, eikä kumpikaan ole tarkoituksella suunniteltu turvallisemmaksi kuin toinen. Siksi turvallisuuskysymykset ovat edelleen epämääräisempiä.
Miksi uskon, että virtuaalikoneet ovat turvallisempia kuin kontit
Divide and Conquer on voittanut strategia sodassa ja ohjelmistoissa. Kun arkkitehtuuri jakaa yhden monimutkaisen, vaikeasti ratkaistavan tietoturvaongelman helpommiksi ongelmiksi, tulos on useimmissa tapauksissa turvallisempi kuin yksi ratkaisu, joka käsittelee kaikki ongelmat.
Säiliöt ovat esimerkki jaosta ja hallitse -sovelluksista, joita sovelletaan vaakasuoraan sovelluksiin. Lukitsemalla kukin sovellus omaan vankilaansa yhden sovelluksen heikkoudet eivät heikennä sovelluksia muissa säiliöissä. Myös virtuaalikoneet jakavat ja valloittavat, mutta he menevät askeleen pidemmälle erillään.
Marvin Waschke /Vankilassa olevan sovelluksen vika ei voi vaikuttaa suoraan muihin sovelluksiin, mutta vankilassa oleva sovellus voi rikkoa yksittäisen käyttöjärjestelmän (OS), joka on jaettu muiden säilöjen kanssa, ja vaikuttaa kaikkiin säilöihin. Jaetulla käyttöjärjestelmällä sovelluksen, säilön ja käyttöjärjestelmän toteutuspinon virheet voivat milloin tahansa heikentää koko pinon turvallisuutta ja vaarantaa fyysisen koneen.
+ Myös Verkkomaailmassa: Mikä on halvempaa: kontit tai virtuaalikoneet? +
Kerrostettu arkkitehtuuri, kuten virtualisointi, erottaa kunkin sovelluksen suorituspinon aina laitteistoon asti, eliminoiden mahdollisuuden, että sovellukset häiritsevät toisiaan jaetun käyttöjärjestelmän kautta. Lisäksi kunkin sovelluspinon ja laitteiston välinen rajapinta on määritelty ja rajoitettu väärinkäytösten estämiseksi. Tämä tarjoaa erityisen vankan kehän sovellusten suojaamiseksi toisiltaan.
Virtuaalikoneet erottavat käyttäjän toimintaa ohjaavan käyttöjärjestelmän hypervisorista, joka ohjaa vieras-käyttöjärjestelmän ja laitteiston välistä vuorovaikutusta. VM-vieras-käyttöjärjestelmä ohjaa käyttäjän toimintaa, mutta ei laitteistovaikutusta. Sovelluksen tai vieras käyttöjärjestelmän virhe ei todennäköisesti vaikuta fyysiseen laitteistoon tai muihin virtuaalikoneisiin. Kun virtuaalikoneen vieras-käyttöjärjestelmä ja säilöä tukeva käyttöjärjestelmä ovat identtiset, mikä on usein tapaus, sama haavoittuvuus, joka vaarantaa kaikki muut käyttöjärjestelmässä toimivat säilöt, ei vaaranna muita virtuaalikoneita. Siten virtuaalikoneet erottavat sovellukset vaakasuunnassa ja myös pystysuunnassa erilliset käyttöjärjestelmät laitteistoista.
VM yläpuolella
Virtuaalikoneiden ylimääräinen turvallisuus tulee maksamaan. Ohjauksen siirto on aina kallista tietojenkäsittelyjärjestelmissä, sekä prosessorisykleissä että muissa resursseissa. Suorituspinot tallennetaan ja nollataan, ulkoiset toiminnot saatetaan joutua keskeyttämään tai antamaan suorittaa loppuun jne.
Siirtyminen vieras käyttöjärjestelmän ja hypervisorin välillä maksaa paljon ja tapahtuu usein. Vaikka prosessorin siruihin poltettaisiin erityiset ohjausohjeet, ohjauksen siirtokustannukset heikentävät virtuaalikoneiden yleistä tehokkuutta. Onko lasku merkittävä? Vaikea kysymys. Sovellukset voidaan virittää vähentämään yleiskustannuksia hallitsemalla ohjauksen siirtoa, ja useimmat palvelinprosessorit on nyt suunniteltu virtaviivaistamaan ohjauksen siirtoa. Toisin sanoen merkitys riippuu sovelluksesta ja palvelimesta, mutta yleiskustannuksia ei voida koskaan poistaa kokonaan, vain lieventää.
Hypervisorin haavoittuvuudet
Asiat edelleen monimutkaistavat, kun kerrosten erottaminen VM-arkkitehtuurissa herättää toisen haavan: hypervisorin puutteet. Hypervisorin rikkominen on yksi epäonnistumispiste, jolla voi olla suuria seurauksia, erityisesti julkisissa pilvissä. Mahdollisesti yksi hakkeri voisi käynnistää koodin virtuaalikoneessa, joka hallitsee muiden julkisten pilvipalvelujen kuluttajien omistamat sovellukset ja luo julkisen pilven erän yhdellä hyödyntämisellä.
Vakaa arkkitehtuuri voi silti sisältää toteutusvirheitä, jotka heikentävät järjestelmää huomattavasti. Hypervisor-rikkomukset torjutaan usein väittämällä, että niitä ei koskaan tapahdu: Tarinan mukaan hypervisorit ovat niin yksinkertaisia, niin hyvin kirjoitettuja, niin huolellisesti tarkistettuja, etteivät ne koskaan petä. Hypervisorin rikkomus voi olla yhtä tuhoisa kuin WannaCry, mutta älä huoli siitä. Mutta Heartbleed tapahtui. Ja OpenSSL: llä on paljon vähemmän koodiriviä kuin hypervisorilla. Minun täytyy mennä ulos nyt - lentävä sika haluaa lisää tylsää.
En tiedä merkittäviä hypervisoririkkomuksia tähän mennessä. Mutta nopea katsaus Common Vulnerilities and Exposures (CVE) -tietokantaan paljastaa, että tutkijat löytävät hyödynnettävissä olevia hypervisorin heikkouksia. Hypervisorin kehittäjät ja toimittajat ovat nopeasti paikantaneet haavoittuvuuksia niiden esiintyessä. Maaliskuussa 2017 Microsoft julkaisi tietoturvatiedotteen MS17-008, jossa dokumentoitiin Hyper-V-hypervisorissa seitsemän korjattavaa haavoittuvuutta, jotka kaikki on merkitty tai kriittinen.
Uskon edelleen, että virtuaalikoneet tarjoavat paremman turvallisuuden kuin kontit, mutta meidän on tarkasteltava virtuaalikoneiden turvallisuutta selkeillä silmillä. Aion keskustella hypervisorin heikkouksista tarkemmin tulevaisuudessa. Myös kontit ja virtuaalikoneet yhdistetään usein. Paljon on vielä sanottavaa.
