Always Encrypted - SQL Server 2016 - I
Always Encrypted on SQL Server 2016 versiossa julkaistu uusi tietoturvaominaisuus, joka varmistaa, että haluttu sisältö on aina salattuna tietokantapalvelimella sekä tiedonsiirron aikana. Ensimmäisessä osassa käydään ominaisuuden yleisellä tasolla läpi ja tutkitaan miten salausprosessi menee käytännössä.
Blogi-kirjoitus pohjautuu TechTalks 2016 tilaisuudessa pitämääni esitykseen. ~45min
Lyhyesti
Tiedon omistajan määrittelemä data on aina salattu SQL Serverissä. Eli halutut sarakkeet salataan ’automaattisesti’ sovelluksessa, jolloin SQL Serverillä ei ole pääsyä salauksen purkamiseen tarvittaviin avaimiin. Tämä suojaa datan tiedonsiirron aikana sekä estää myös tehokkaasti ylläpitäjien pääsyn sisältöön.
Ominaisuus on suunniteltu suojaamaan, vain arvokasta tietoa, EI kaikkea sisältöä toisin kuin jo 2008 julkaistu Transparent Data Encryption (TDE), joka salaa reaaliaikaisesti tietokannan data-, loki- ja backup-tiedostot. Käytä tätä uutta ominaisuutta vain luottokortti-numeroiden, henkilötunnuksien, tärkeiden dokumenttien ym. salaamiseen.
Käyttö vaatii sovelluksen, jossa itse salaus tehdään ja josta on pääsy salauksen käyttämään sertifikaattiin. Lisäksi tarvitaan jokin seuraavista data providereista:
.NET 4.6+, Microsoft JDBC Driver 6.0 (tai uudempi) tai ODBC Driver 13.1 for SQL Server.
Tietokanta palvelin johon salattu data tallennetaan täytyy olla
SQL Server 2016 Enterprise Edition tai Azure SQL Database.
Verkkoliikenteen analysointi
Tiedonsiirto on oletuksena salaamatonta sovelluksen ja SQL Serverin välillä. Tämä voidaan havaita kuuntelemalla verkkoliikennettä esim. Wireshark-ohjelmalla.
Seuraavassa esimerkissä lähetetään sovelluksesta SQL-kysely palvelimelle. Myynti-tietokannasta haetaan yhden käyttäjän tiedot. Henkilötunnus- ja luottokorttitietoja ei haluttaisi siirtää tai tallentaa selväkielisinä.
.NET sovellus lähettää parametrisoiden SQL-kyselyn, joka palauttaa yhden käyttäjän tiedot.
Jos palvelinta monitoroidaan Profilerilla, niin huomataan, että kaikki tieto on tarvittavat käyttöoikeudet omaavien nähtävissä.
Wiresharkilla analysoitaessa salaamaton verkkoliikenne näyttää seuraavalta
Miten Always Encrypted auttaa ratkaisemaan ongelman?
Tiedon salaus
Salattava sisältö määritellään tietokantataulu ja sarake-kohtaisesti. Helpoin tapa tehdä salaus on käyttää SQL Server Management Studiota (SSMS), jonka kautta voi avata Wizardin salauksen tekemiseksi. Lopputuloksen voi tallentaa Powershell scriptiksi. Testatuilla PS-scripteillä kannattaa salaus toteuttaa testi- ja tuotantoympäristöissä. Suurilla data määrillä salaukseen voi kulua pitkäkin aika, joten arvioitu kesto kannattaa päätellä testiympäristössä ennen tuotantoa.
Tietoturva syistä taulujen sisältöä ei voi salata tai purkaa T-SQL käskyillä, koska SQL Serverillä ei pitäisi olla pääsyä salauksen purkamiseen vaadittaviin sertifikaatteihin.
Tietoa salatessa pitää päättää kenttä kohtaisesti salaustapa. Deterministic tarkoittaa sitä, että sama alkuarvo tuottaa aina saman lopputuloksen. Hyvä puoli tässä on se, että kyseistä kenttää voidaan käyttää hakuehtona, mutta huono puoli on mahdollisuus päätellä lopputuloksesta alkuarvo. Päättely onnistuu vain jos käytössä on jokin suppeampi joukko esim. kategoria. Randomized tarkoittaa sitä, että riippumatta alkuarvosta lopputulos on aina eri.
Esimerkki taulun sisällön salaamisesta Management Studiolla.
Nyt jos haetaan taulun sisältö, niin valittujen sarakkeiden sisältö on salattu.
Mitä muutoksia täytyy tehdä sovellukseen?
Hyvä uutinen on se, että sovellukseen ei tarvitse tehdä mitään muuta kuin lisätä connectionstringiin attribuutti: Column Encryption Setting=enabled
Jos nyt katsotaan miltä palvelimelle lähetetty kysely näyttää, niin huomataan, että hakuehdon parametri on salattu sekä salatavien sarakkeiden data siirtyy suojattuna verkon yli.
Salausavaimet
Always Encrypted käyttää kahta avaintyyppiä tiedon suojaamiseen. Column Encryption Key (CEK) on avain, jolla salataan itse sisältö ja se tallennetaan SQL Server tietokantaan salattuna. Column Master Key (CMK) on avain, jolla salataan CEK-salausavaimet. CMK-avaimen tiedot tallennetaan suojattuun paikkaan, joita on Azure Key Vault, Windows Certificate Store tai Hardware Security Module (HMS).
CMK-salausavaimia ei pidä koskaan tallentaa SQL Server palvelimelle, jonka lisäksi ne pitää generoida suojatussa paikassa.
Tarkemmat tiedot salausavaimista ja käytetyistä algoritmeistä löytyy osoitteesta:
Kuinka salaus toimii käytännössä?
Ohessa on esimerkki miten parametrisoidun kyselyn käsittely etenee.
Sovellus lähettää SQL-kyselyn, josta ADO.NET päättelee sen olevan parametrisoitu, joten se lähettää erikseen ensin kyselyn SQL Serverille tarvitseeko parametreja salata. Hetu on salattu sarake, joten palvelin vastaa kyselyyn tiedolla mistä löytyy CMK sertifikaatti, jolla CEK salausavaimen voi purkaa, jotta parametri voidaan salata.
ADO.NET käy palvelimelta saamien tietojen perusteella hakemassa Windows Certificate Storagesta kyseisen sertifikaatin ja purkaa CEK-salausavaimen ja salaa selväkielisellä avaimella @hetu parametrin arvon.
Lopuksi ADO.NET lähettää varsinaisen SQL-kyselyn palvelimelle.
SQL Server palauttaa datan ja ADO.NET purkaa salatut sarakkeet, jonka jälkeen tulos palautuu sovelluksen selväkielisenä.
.NET 4.6.1 versiossa suorituskykyä on parannettu niin, että ADO.NET säilyttää oletuksena 2 tuntia salausavaimia muistissa sekä tietoa salatuista sarakkeista. Jos sama kysely suoritetaan uudestaan, ei palvelimelle lähetetä kahta kyselyä, vaan kysely salataan suoraa muistista löytyvillä tiedoilla.
.NET 4.6.2 versiossa voi tietoturva syistä määritellä kuinka kauan avaimia pidetään muistissa.
Tiedonsiirron salaus
Joskus voi olla tarpeen salata valittujen sarakkeiden lisäksi kaikki liikenne sovelluksen ja palvelimen välillä. Tämä onnistuu konfiguroimalla SQL Server käyttämään SSL/TLS-salausta.
Lisää tietoa seuraavalta sivulta: Enable Encrypted Connections to the Database Engine
Yhteys Azure SQL Databaseen on oletuksena suojattu.
Blogin seuraavissa osissa käsitellään tarkemmin avainten hallintaa sekä suorituskykyä ja sovelluksen tietoturvaominaisuuksia.
