Salaus ja avaintenhallinta: varmista suojausketju

Salaus suojaa tietoa tiettyjen oletusten vallitessa. Hyvä toteutus kertoo, mitä tietoja suojataan, millaiselta pääsyltä ja miten avaimet pysyvät hallinnassa koko elinkaarensa ajan. Asetus ”salaus käytössä” vastaa vain pieneen osaan tästä kysymyksestä.

Teknologiajohtajalle (CTO) teknisenä tehtävänä on varmistaa suojausketju: mistä selväkielinen tieto on peräisin, missä se kulkee, missä salattua tietoa säilytetään, kuka voi pyytää salauksen purkamista ja mitä tapahtuu häiriö- tai palautustilanteessa. Ketjuun kuuluvat sovellukset, identiteetit, pilvipalvelut, ylläpitäjät, varmuuskopiot ja operatiiviset menettelyt.

Seuraavat käytännön suositukset tarjoavat tavan suunnitella ja katselmoida tämä ketju. Aloita yhdestä arkaluonteisesta tietovarastosta ja laajenna sama menetelmä siitä riippuviin järjestelmiin ja toissijaisiin kopioihin.

Määrittele suojaustavoite ennen teknologian valintaa

Aloita uhkakuvauksesta, älä algoritmista. ”Suojataan asiakastietueet” on liian laaja ohjaamaan toteutusta. ”Estetään varastetun varmuuskopion haltijaa lukemasta asiakastietueita ilman erikseen hallittuja avaimia” yksilöi suojattavan kohteen, hyökkääjän kyvykkyyden ja suojausrajan.

Eri uhat edellyttävät eri hallintakeinoja. Levyn salaus voi suojata virrattomana varastettua kannettavaa, mutta todennettu käyttäjä tai haitallinen prosessi voi silti lukea tiedostoja, kun levyn lukitus on avattu. Tietokannan salaus voi suojata tallennusmediaa ja silti sallia tietokantakyselyjen palauttaa selväkielistä tietoa. Sovelluskerroksen salaus voi rajata sitä, mitä tietokannan ylläpitäjät näkevät, mutta se ei välttämättä suojaa vaarantunutta sovellusta vastaan, jolla on oikeus purkaa salaus.

Tee nämä erot näkyviksi lyhyellä tietovirtaluettelolla. Ota mukaan tuotannon tietueet, ladatut asiakirjat, välimuistit, jonot, analytiikkapoiminnat, lokit, väliaikaiset tiedostot, tilannevedokset ja varmuuskopiot. Tietojen kartoituksen pitäisi tunnistaa myös kopiot, jotka jäävät päätallennusarkkitehtuurin ulkopuolelle, ei vain arkkitehtuurikaaviossa näkyviä järjestelmiä.

Kirjaa jokaisesta tärkeästä tietovirrasta:

• Tietoluokka ja sen luottamuksellisuustarpeet.
• Lähde, kohde, välissä olevat palvelut ja selväkielisen tiedon rajat.
• Hyökkääjä tai luvaton rooli, jota salauksella on tarkoitus rajoittaa.
• Identiteetti, jolla on lupa purkaa salaus, ja syy, miksi se tarvitsee luvan.
• Saatavuus-, säilytys- ja palautusvaatimukset.
• Toteutuksesta vastaava omistaja ja näytöstä vastaava katselmoija.

Uhkamallinnuksen menetelmä auttaa testaamaan, vastaako valittu raja uhkaa. Jos hyökkääjä voi omaksua sovelluksen identiteetin, läpinäkyvä tallennussalaus ei yksinään estä pääsyä kyseisen sovelluksen kautta.

Tuotoksena syntyy suojauskartta: tietovirtakaavio, johon liittyvät nimenomaiset oletukset ja poikkeukset. Siitä tulee viitekohta konfiguraatiotarkistuksille, valtuutustesteille ja palautusharjoituksille.

Ymmärrä, mitä kryptografiset rakennuspalikat todella tarjoavat

Salaus muuntaa selväkielisen tiedon salatuksi tiedoksi kryptografisen algoritmin ja avaimen avulla. Sen luottamuksellisuus riippuu rakenteesta, toteutuksesta, avaimen salassapidosta ja käyttöympäristöstä. Vahva algoritmi ei voi korvata avainta, joka on tallennettu lähdekoodivarastoon, tai sovelluksen päätepistettä, joka palauttaa toisen asiakkaan tietueita.

Symmetrisellä ja epäsymmetrisellä kryptografialla on eri tehtävät

Symmetrinen salaus käyttää samaa salaista avainta salaukseen ja purkuun. Sitä käytetään yleisesti suurille tietomäärille, koska se on tehokasta. AES tukee 128-, 192- ja 256-bittisiä avaimia, mutta pelkkä avaimen pituus ei kuvaa turvallista toteutusta: myös toimintatila, nonce-arvojen käsittely, todentaminen ja kirjaston toiminta vaikuttavat.

Epäsymmetrinen kryptografia käyttää toisiinsa liittyviä julkisia ja yksityisiä avaimia. Algoritmista ja protokollasta riippuen se tukee salausta, allekirjoituksia tai avainten sopimista. RSA:lla ja elliptisten käyrien rakenteilla on erilaiset ominaisuudet ja parametrit; ne eivät ole keskenään vaihdettavia nimiä. Epäsymmetrinen kryptografia ei ole luonnostaan ”turvallisempaa” kuin symmetrinen salaus.

Nykyaikaiset järjestelmät yhdistävät usein molempia. Turvallinen siirtoprotokolla voi todentaa vastapuolen ja muodostaa jaetut salaisuudet ja käyttää sitten symmetristä salausta liikenteen suojaamiseen. Suuret tiedostot salataan tyypillisesti symmetrisillä data-avaimilla sen sijaan, että koko tiedosto käsiteltäisiin suoraan epäsymmetrisellä algoritmilla.

Luottamuksellisuus ei ole sama kuin eheys tai aitous

Todennettu salaus, kuten oikein käytetty AES-GCM, suojaa luottamuksellisuutta ja havaitsee suojattuun salattuun tietoon ja siihen liittyvään tietoon tehdyt luvattomat muutokset. Nonce-arvon uudelleenkäyttö saman avaimen kanssa voi heikentää tätä suojaa. Suosi ylläpidettyjä kirjastoja ja hyvin tuettuja formaatteja, jotka käsittelevät nämä vaatimukset turvallisesti; älä keksi omaa salausalgoritmia, toimintatilaa tai avaintenvaihtoprotokollaa.

Tiivistefunktio tuottaa tiivisteen eikä palautettavissa olevaa salattua tietoa. Tavallinen tiiviste ei todista, kuka viestin loi. Salasanojen tallentaminen edellyttää tarkoitukseen suunniteltua salasanatiivistystä, ei palautettavaa salausta tai pelkkää nopeaa yleiskäyttöistä tiivistettä.

Viestin todennuskoodi (MAC) käyttää salaisuutta eheyden ja aitouden varmistamiseen osapuolten välillä, jotka jakavat kyseisen salaisuuden. Digitaaliset allekirjoitukset käyttävät yksityistä allekirjoitusavainta ja julkista tarkistusavainta; ne eivät tee allekirjoitetusta sisällöstä luottamuksellista.

Näillä eroilla on merkitystä katselmoinnissa. Kysy, mikä ominaisuus vaaditaan ja mikä mekanismi sen tarjoaa, sen sijaan että hyväksyisit ”kryptografian” yhtenä erittelemättömänä hallintakeinona.

Tarkista jokainen tallennuskerros ja jokainen toissijainen kopio

Tallennuksenaikainen salaus kattaa tallennetun tiedon, myös käynnissä olevan palvelun aktiivisesti käyttämän tiedon. Ilmaus ei tarkoita vain arkistoitua tai passiivista tietoa.

Eri kerrokset suojaavat eri pääsypoluilta:

Varmista resurssin todellinen konfiguraatio, älä pelkkää tilin oletusasetusta. Oletus voi koskea vain uutta tallennustilaa. Olemassa olevat objektit, tuodut taltiot, replikat tai historialliset tilannevedokset voivat noudattaa eri asetuksia.

Tarkasta tietokannoista transaktiolokit, väliaikainen tallennustila, replikat, viennit ja ylläpidon vedosmenettelyt. Tarkista objektitallennuksesta lataukset, kopiot, replikoinnin kohteet, versioidut objektit ja latauspolut. Tarkista päätelaitteista palautusavainten käsittely ja se, kattaako salaus siirrettävät tallennusvälineet.

Sovelluskerroksen salaus ansaitsee oman suunnittelupäätöksensä. Se voi vähentää altistumista tietokannan ylläpitäjille tai rajata, mitkä työkuormat voivat purkaa valittujen kenttien salauksen. Se voi myös hankaloittaa indeksointia, hakua, analytiikkaa ja tukityönkulkuja. Dokumentoi, missä puretut arvot päätyvät muistiin, lokeihin, virheraportteihin tai vienteihin.

Älä käsittele salausta valtuutuksen korvikkeena. Sovellus voi purkaa tietueen salauksen oikein ja silti paljastaa sen väärälle vuokralaiselle. Pidä vuokralaisten eristys, pääsytarkistukset ja etuoikeutetun pääsyn hallintakeinot samassa katselmoinnissa.

Varmista siirto ensimmäiseltä lähettäjältä lopulliselle vastaanottajalle

Siirronaikainen salaus suojaa päätepisteiden välillä liikkuvaa tietoa. Hyödyllinen kysymys ei ole ”Käytämmekö HTTPS:ää?” vaan ”Mitkä yhteydet on suojattu ja mitkä identiteetit todennettu?”

Kartoita yhteydet selaimesta reunaverkkoon, reunaverkosta sovellukseen, palveluiden välillä, sovelluksesta tietokantaan, replikoinnissa, varmuuskopioiden siirrossa, ylläpitopääsyssä ja kolmansille osapuolille tehtävissä vienneissä. TLS-yhteyden päättäminen kuormantasaajaan luo rajan: seuraava yhteysväli edellyttää oman suojauspäätöksensä. Yksityinen verkko ei automaattisesti poista salakuuntelun tai sivuttaisliikkeen riskejä.

Käytännön perustasona suosi tuettuja nykyaikaisia TLS-konfiguraatioita ja ylläpidettyjä asiakaskirjastoja. TLS 1.3 on vahva oletus siellä, missä sitä tuetaan; asianmukaisesti konfiguroitu TLS 1.2 voi edelleen olla tarpeen yhteensopivuuden vuoksi. Vanha SSL ei ole sopiva nykyaikainen tietoturvavalinta.

Varmenteiden tarkistus on osa suojausta. Tarkista isäntänimen varmistus, luottamussäilöt, vanhenemisen valvonta, varmenteiden uusiminen ja se, ettei tuotannossa ole asetuksia, jotka poistavat tarkistuksen käytöstä. Salaus todentamattomaan päätepisteeseen voi suojata liikennettä passiiviselta seurannalta ja silti lähettää sen väärälle osapuolelle.

Kaksisuuntainen TLS (mTLS) voi todentaa yhteyden molemmat päät, mutta se ei korvaa sovelluksen valtuutusta. Varmenteiden myöntämisestä, työkuormien identiteetistä, uusimisesta ja mitätöinnistä tulee operatiivisia riippuvuuksia, jotka tarvitsevat omistajat ja testit.

Erota siirronaikainen salaus päästä päähän -salauksesta. Palvelu, joka päättää TLS-yhteyden ja käsittelee selväkielistä tietoa, ei tarjoa päästä päähän -luottamuksellisuutta itseltään. Päästä päähän -ratkaisut varaavat salauksen purun nimetyille päätepisteille; ne tuovat mukanaan omat kysymyksensä laitteiden rekisteröinnistä, vastaanottajan varmistamisesta, usean laitteen käytöstä ja palautuksesta.

Näytön pitäisi sisältää konfiguraatio- ja yhteystestejä. Testaa, että virheelliset varmenteet ja kielletyt protokollaversiot hylätään, älä vain yhtä onnistunutta salattua yhteyttä.

Hallitse avaimia suojattavina kohteina, joilla on elinkaari

Avaimet on luotava, säilytettävä, käytettävä valtuutetusti, vaihdettava, mitätöitävä, säilytettävä ja hävitettävä. Jokaisella vaiheella pitäisi olla omistaja ja määritelty menettely.

Luo ja rekisteröi avaimet harkitusti

Luo avaimet ylläpidetyillä kryptografisilla välineillä, joissa on riittävä satunnaisuus. Älä johda tuotannon salausavaimia helposti muistettavista salasanoista, tunnisteista, aikaleimoista tai sovellusten tavallisista satunnaislukufunktioista.

Ylläpidä avainluetteloa, joka sisältää käyttötarkoituksen, omistajan, ympäristön, suojattavat järjestelmät, algoritmin, avaintunnisteen, luontipäivän, tilan ja palautusriippuvuudet. Kirjaa metatiedot, älä salaista avainmateriaalia. Erota salausavaimet, allekirjoitusavaimet, TLS-yksityisavaimet ja rajapintatunnisteet toisistaan, koska niiden paljastumiseen ja vaihtamiseen liittyvät menettelyt eroavat.

Erota tuotanto kehitys- ja testiympäristöistä. Avaimen jakaminen ympäristöjen kesken laajentaa vähemmän luotetun ympäristön vaikutusta ja vaikeuttaa käyttölokien tulkintaa.

Erota avainten hallinta tietoihin pääsystä

Avaintenhallintapalvelu (KMS) tarjoaa tyypillisesti hallittuja avainoperaatioita, pääsypolitiikkoja, versiointia ja käyttötietueita. Laitteistopohjainen turvamoduuli (HSM) tarjoaa laitteistoon perustuvan rajan kryptografisille operaatioille ja avainten suojaukselle. Palvelut voivat yhdistää näitä toimintoja, mutta tuotenimet eivät määritä tarkkaa suojausrajaa.

Selvitä, voidaanko avaimia viedä ulos, mitkä operaatiot tapahtuvat rajan sisällä, kuka hallinnoi politiikkoja ja miten palautus toimii. Valitse hallinnoidut avainpalvelut tai laitteistosuojaus riskin ja operatiivisten vaatimusten perusteella sen sijaan, että pitäisit erillistä laitteistoa yleisesti välttämättömänä. HSM:t suojaavat ensisijaisesti avaimia ja kryptografisia operaatioita; ne eivät ole yleiskäyttöisiä säilöjä kaikelle salatulle liiketoimintatiedolle.

Kirjekuorisalaus (envelope encryption) on yleinen malli. Data-avain salaa sisällön, ja avaimensalausavain suojaa data-avaimen. Salattu data-avain voi kulkea salatun tiedon mukana. Sen turvallisuus riippuu siitä, että kyky purkaa sen suojaus pysyy erikseen hallittuna, ei siitä, että jokainen salattu avain piilotetaan toiseen paikkaan.

Rajaa salauksen purku niihin työkuormiin, jotka sitä tarvitsevat. Erota mahdollisuuksien mukaan avainten hallinnointi avainten käytöstä ja tallennustilan hallinnoinnista. Tarkista, voiko ylläpitäjä, joka ei tällä hetkellä pysty purkamaan salausta, myöntää itselleen tämän oikeuden. Hätäpääsyllä pitäisi olla nimenomainen hyväksyntä, rajattu kesto ja katselmointijälki.

Käsittele avainten vaihtoa muutosprosessina, ei rastina ruudussa

Määritä avainten voimassaoloajat (cryptoperiod) tietojen arkaluonteisuuden, altistumisen, algoritmin rajoitusten, käyttömäärän ja sovellettavien vaatimusten mukaan. Avaimen vaihtaminen on aiheellista myös epäillyn vaarantumisen tai olennaisen luottamusmuutoksen jälkeen.

Selvitä, mitä ”vaihto” tarkoittaa valitussa palvelussa. Uuden avainversion luominen tulevaa salausta varten voi jättää historiallisen tiedon riippuvaiseksi vanhemmista versioista. Data-avainten uudelleenkääriminen uudella avaimensalausavaimella eroaa taustalla olevan tiedon salauksen purkamisesta ja uudelleensalaamisesta. Kumpaakaan toimintoa ei pidä olettaa automaattisen vaihdon asetuksen perusteella.

Vaihtosuunnitelman pitäisi yksilöidä vaikutuksen kohteena olevat sovellukset, tallennetut avaintunnisteet, historialliset versiot, vaiheittainen käyttöönotto, virheiden valvonta, peruutusehdot ja lopullinen käytöstä poisto. Testaa eri versioiden sekaluku ja pitkäkestoiset ajot ennen vanhan pääsyn poistamista.

Erota mitätöinti hävittämisestä

Mitätöinti poistaa oikeuden tai estää avaimen tulevan käytön. Se ei poista jo haettua selväkielistä tietoa, mitätöi jokaista välimuistissa olevaa data-avainta tai saa ulos vietyä salaisuutta katoamaan.

Hävittäminen voi tehdä säilytetystä salatusta tiedosta palauttamattoman, mutta vain, jos kaikki käyttökelpoiset kopiot ja palautuspolut on otettu huomioon. Huomioi replikat, avainten talletus (escrow), ulos viety materiaali, varmuuskopiot ja jaettuihin avaimiin liittyvät riippuvuudet. Jos toisiinsa liittymättömät tietueet jakavat avaimen, sen hävittäminen voi viedä pääsyn myös tietoihin, joiden on pysyttävä saatavilla.

Pidä säilytyksen ja poistamisen suunnittelu kytkettyinä toisiinsa. Avainten säilyttäminen toistaiseksi voi vaarantaa poistotavoitteen; ennenaikainen hävittäminen voi aiheuttaa saatavuuspoikkeaman.

Arvioi pilven avainmalleja niiden todellisen hallintarajan perusteella

Pilvisalaus voi vähentää toteutustyötä, mutta palveluntarjoajan oletusasetukset eivät määritä uhkamalliasi. Arvioi palvelu, avainpolitiikka, ylläpitopääsy, alue, palautusmalli ja tukeva näyttö yhdessä.

Palveluntarjoajan hallinnoimat avaimet voivat sopia joihinkin riskeihin suhteellisen pienellä operatiivisella kuormalla. Asiakkaan hallinnoimat avaimet voivat tarjota nimenomaisemman politiikkojen hallinnan, omistajuuden ja elinkaaripäätökset. Ulkoisesti säilytetyt avaimet voivat luoda erilaisen luottamusrajan, mutta ne tuovat myös riippuvuuden ulkoisesta saatavuudesta ja yhteyksistä.

Termit kuten bring your own key, bring your own encryption ja encryption as a service eivät ole keskenään vastaavia arkkitehtuurisia takeita. Avaimen tuominen palveluntarjoajan palveluun ei välttämättä tarkoita, ettei palveluntarjoaja voisi koskaan purkaa salausta. Asiakaspään salauksen käyttöönotto muuttaa selväkielisen tiedon rajaa, mutta se voi hankaloittaa sovelluksen ominaisuuksia ja palautusta.

Kysy mahdolliselta palveluntarjoajalta:

• Pystymmekö tunnistamaan avaimen, jota kukin asiaankuuluva tallennusresurssi ja varmuuskopio käyttää?
• Kuka voi muuttaa avainpolitiikkoja, ja miten muutokset kirjataan?
• Mitä tapahtuu, kun avain poistetaan käytöstä tai avainpalvelu ei ole saatavilla?
• Miten vienti, replikointi, siirto ja tilin sulkeminen vaikuttavat suojaukseen?
• Mitkä käyttötapahtumat ovat saatavilla, ja mikä toiminta jää niiden näkyvyyden ulkopuolelle?

Arvioi suorituskyky edustavilla työkuormilla: läpäisykyky, viive, avainpalvelun kiintiöt, välimuistin toiminta ja vikatilanteet. Pienessä esittelyssä toimiva palvelu voi pettää massapalautuksen aikana. Tietojen sijainti ja asiakkaan avainomistajuus ovat hyödyllisiä suunnittelun lähtötietoja, eivät todiste suvereniteetista tai sääntelyn noudattamisesta.

Valitse ratkaisu operatiivisen kokeilun avulla

Vertaa vaihtoehtoja suojauskarttaan algoritmien nimilistan sijaan. Ota huomioon kirjastojen ylläpito, tuetut alustat, hallinnollinen eriyttäminen, näytön saatavuus, siirtomahdollisuudet ja tiimin kyky operoida palvelua. Jos sopimus edellyttää validoitua kryptografista moduulia, selvitä kyseinen moduuli, versio, käyttöympäristö ja validoinnin soveltamisala; pelkkä AES-merkintä ei osoita vaatimuksen täyttymistä.

Käytännön kokeilussa pitäisi salata edustavaa tietoa, suorittaa tavallisia lukuja, vaihtaa avain, palauttaa vanhempi kopio ja simuloida avainpalvelun saavuttamattomuus. Ota mukaan massatuonnit ja -viennit, koska niiden toiminta voi poiketa tavallisista sovelluspyynnöistä. Mittaa vaikutus sovelluksen omaan viiveeseen ja palautumistavoitteisiin sen sijaan, että hyväksyisit yleisen suorituskykyväitteen.

Kirjaa nimenomainen hyväksymispäätös: mihin uhkiin vastataan, mitä riippuvuuksia syntyy, mikä jää soveltamisalan ulkopuolelle ja kuka omistaa jäännösriskit. Testaa myös siirrettävyys. Ulos viedyllä salatulla tiedolla on vähän operatiivista arvoa, jos sen formaattia, käärittyjä avaimia tai tarvittavia metatietoja ei voida tulkita palvelusuhteen päätyttyä.

Suunnittele palautus yhdessä luottamuksellisuuden kanssa

Varmuuskopiosta on varmistettava kolme asiaa: tiedot on salattu, valtuutettu palautushenkilöstö saa tarvittavat avainoperaatiot käyttöönsä ja palautus onnistuu.

Älä sijoita ainoaa palautuspolkua samaan vikarajaan kuin tuotanto. Tilin lukittuminen, alueellinen häiriö tai ylläpitovirhe voi vaikuttaa sekä varmuuskopioon että sen avaimiin. Erillisten palautusjärjestelyjen on pysyttävä tiukasti hallittuina; niiden riippumattomuus ei saa tehdä niistä laajasti saatavilla olevia.

Dokumentoi kunkin varmuuskopiosukupolven tarvitsemat avainversiot, vaaditut identiteetit, hyväksyntävaiheet, palveluntarjoajariippuvuudet ja palautettuja tietoja koskevat rajoitukset. Palauttaminen testiympäristöön ei saa huomaamatta paljastaa tuotantotietoja kehittäjille.

Harjoittele palautusta eristetyssä ympäristössä. Kirjaa, löydettiinkö varmuuskopio, menivätkö eheystarkistukset läpi, pysyivätkö tarvittavat avaimet käyttökelpoisina, olivatko sovelluksen tiedot luettavissa ja täyttikö saavutettu palautumisaika organisaation tavoitteen. Mahdolliset aikaluvut kuuluvat todelliseen harjoitukseen, eivät salauksen oletettuun hyötyyn.

Ota avainpalvelun vikaantuminen mukaan häiriönsietokyvyn testaukseen. Päätä, pitäisikö työkuorman pysähtyä turvallisesti (fail closed), yrittää uudelleen vai käyttää hyväksyttyä välimuistiin tallennettua avainta. Välimuistiin tallentaminen voi parantaa saatavuutta, mutta se pidentää aikaa, jonka prosessi voi purkaa salausta keskitetyn pääsyn poistamisen jälkeen. Dokumentoi tämä kompromissi nimenomaisesti.

Varaudu epäiltyyn avaimen vaarantumiseen

Toimet riippuvat siitä, mitä paljastui. Vuotanut sovellustunniste, jolla on oikeus kutsua KMS:ää, eroaa ulos viedystä salausavaimesta: tunnisteen poistaminen voi estää palvelun tulevan käytön, kun taas hyökkääjä, jolla on avain ja salattu tieto, voi purkaa salauksen itsenäisesti. Vaarantunut allekirjoitusavain luo toisenlaisen ongelman, joka koskee allekirjoitusten luotettavuutta eikä pelkästään luottamuksellisuutta.

Laadi toimintaohje, jossa yksilöidään päätöksentekijä, vaikutuksen kohteena olevat avaintunnisteet, riippuvaiset järjestelmät, rajausvaihtoehdot ja säilytettävä näyttö. Tutki politiikkamuutoksia, epätavallisia avainoperaatioita, tietojen latauksia, sovelluspääsyä ja mahdollista altistumisikkunaa. Puuttuvat lokitapahtumat eivät todista, ettei salausta purettu, etenkään silloin, kun avaimia voidaan viedä ulos tai tallentaa välimuistiin.

Rajaaminen voi tarkoittaa identiteetin poistamista käytöstä, politiikan kaventamista, työkuorman eristämistä tai avaimen poistamista käytöstä. Arvioi saatavuusvaikutukset ennen peruuttamatonta toimenpidettä. Älä hävitä ainoaa palautusavainta improvisoituna rajaamistoimena.

Selvitä rajaamisen jälkeen, mitkä tiedot on siirrettävä vaarantumattomille avaimille. Kääreavaimen vaihtaminen ei riitä, jos hyökkääjä sai taustalla olevat data-avaimet. Säilytettyjen tietojen uudelleensalaaminen voi suojata tulevia kopioita, mutta se ei voi peruuttaa salattua tietoa ja avaimia, jotka on jo varastettu yhdessä. Samoin vaarantuneen sovellusidentiteetin korvaaminen korjaamatta sen valtuutusvirhettä jättää alkuperäisen paljastumispolun auki.

Säilytä poikkeaman aikajana, vaikutuksen kohteena olevien tietojen arviointi, korvaus- ja validointitietueet sekä jäljelle jäävät epävarmuudet. Kun kyse on henkilötiedoista, arvioi ilmoitusvelvollisuudet erikseen; ”tietokanta oli salattu” ei vastaa kysymykseen, saattoiko hyökkääjä saada selväkielisen tiedon tai käyttökelpoiset avaimet.

Kokoa näyttö, joka testaa ketjun

Politiikka kuvaa tavoiteltua toimintaa. Näytön pitäisi osoittaa, että toteutus noudattaa sitä ja että tärkeät vikapolut toimivat odotetusti.

Käytä konfiguraatiovientejä, politiikkakatselmointeja, pääsytestejä, avainten käyttölokeja, käyttöönottotarkistuksia ja palautustietueita yhdessä. Kuvakaappaukset voivat tukea katselmointia, mutta ne harvoin yksinään selittävät soveltamisalaa, historiallista toimintaa tai konfiguraation ajautumista.

Tulkitse lokituksen kattavuutta huolellisesti. Kirjekuorisalauksessa ja välimuistiin tallennetuissa data-avaimissa yksi avainpalvelun operaatio voi mahdollistaa useita myöhempiä paikallisia salauksen purkuja. KMS-loki ei siksi välttämättä ole täydellinen tietue jokaisesta selväkielisen tiedon käytöstä. Yhdistä se tarvittaessa sovelluksen valtuutus- ja tietojen käyttötietueisiin.

Poista salaisuudet näyttöpaketeista. Älä koskaan lataa raakoja avaimia, palautuslauseita, voimassa olevia tunnistetietoja tai tarpeettomia selväkielisiä tietueita. Säilytä resurssitunniste, aikaleima, soveltamisala, katselmoija, testitulos ja asiaankuuluva konfiguraatio luomatta uutta altistumista.

Poikkeuksista pitäisi käydä ilmi kyseinen järjestelmä, syy, korvaavat hallintakeinot, omistaja, päättymispäivä ja korjaustehtävä. Väliaikainen poikkeus vanhan siirtoprotokollan osalta tarvitsee päätöksen ja irtautumissuunnitelman, ei pysyvää merkintää taulukossa.

Käytännön suosituksena toista kohdennetut tarkistukset tallennustilan, työkuormien identiteettien, avainpolitiikkojen, varmenteiden tai varmuuskopioiden kohteiden muutosten jälkeen. Aikataulutetut katselmoinnit ovat edelleen hyödyllisiä, mutta käyttöönotto voi muuttaa suojausrajaa ennen seuraavaa kalenterikatselmointia. Automaattisten tarkistusten pitäisi tuottaa toimeenpantavia havaintoja resurssikontekstin ja omistajan kera, kun taas ihmiset katselmoivat poikkeukset ja uhkamallin muutokset.

Esimerkki: asiakasasiakirjapalvelun jäljittäminen

Oletetaan havainnollistava SaaS-palvelu, joka tallentaa luottamuksellisia asiakasasiakirjoja objektitallennukseen. Sen sovellus hakee asiakirjoja todennetuille käyttäjille, ja päivittäiset varmuuskopiot tukevat liiketoiminnan määrittelemää palautumistavoitetta. Katselmoitavat uhat ovat varastetut tallennuskopiot, luvaton ylläpitopääsy ja tietojen paljastuminen vuokralaisten välillä.

Tiimi kartoittaa TLS-yhteydet selaimesta reunaverkkoon ja reunaverkosta sovellukseen, sovelluksen ja tallennuksen väliset yhteydet, tuotannon säilön ja erillisen varmuuskopiokohteen. Se huomaa, että vianmääritykseen tarkoitettu vientiajo kirjoittaa salaukseltaan purettuja tiedostoja tukikansioon. Kansiosta tulee välitön soveltamisalan kohde; tuotannon säilön salausasetus ei kata sitä.

Alkuperäisessä suunnitelmassa tallennussalaus asiakkaan hallinnoimalla avaimella suojaa tuotannon objekteja. Sovelluksen identiteetti voi hakea valtuutettuja objekteja ja kutsua tarvittavia avainoperaatioita. Käyttöönottorooli voi luoda resursseja, mutta sillä ei ole rutiininomaista purkuoikeutta. Avainpolitiikkojen hallinnointi kulkee erillisen hyväksyntäpolun kautta.

Tiimi tunnistaa jäljelle jäävän rajan: sovelluksen vaarantuminen voisi edelleen mahdollistaa selväkielisen tiedon hakemisen. Se harkitsee sovelluskerroksen salausta erityisen arkaluonteiselle asiakirjaluokalle ja arvioi sitten hakuvaatimukset, tukipääsyn ja palautuksen monimutkaisuuden ennen kuin päättää, onko lisäraja perusteltu.

Varmennus tuottaa konkreettisia tuloksia:

• Luvaton palveluidentiteetti ei voi hakea asiakirjaa tai purkaa sen salausta.
• Sovellus estää toisen vuokralaisen todennetun käyttäjän pääsyn.
• Virheelliset ylävirran varmenteet hylätään eikä niitä ohiteta.
• Vanhempi varmuuskopio palautuu onnistuneesti vaaditulla historiallisella avainversiolla.
• Vaiheittaisen avainmuutoksen jälkeen sekä olemassa olevat asiakirjat että uudet lataukset ovat luettavissa.
• Tuen vientiajo muutetaan käyttämään hyväksyttyä, pääsynhallittua ja salattua kohdetta, jolla on määritelty säilytysaika.

Katselmoija säilyttää tietovirtakartan, konfiguraatioviennit, identiteettipolitiikat, anonymisoidut negatiivisten testien tulokset, avainten vaihtotietueen ja palautusraportin. Avaimen käytöstä poistamista koskeva harjoitus muussa kuin tuotantoympäristössä vahvistaa, että palvelu palauttaa hallitun virheen eikä paljasta tietoja tai hylkää kirjoituksia huomaamatta.

Esimerkki ei osoita suojausta kaikkia hyökkäyksiä vastaan. Se osoittaa, mihin uhkiin suunnitelma vastaa, mikä identiteetti pysyy luotettuna ja mikä näyttö tukee näitä johtopäätöksiä.

Kytke oikeudelliset vaatimukset ja tulevat muutokset suunnitteluun

Salauspäätösten pitäisi heijastaa oikeudellisia, sopimuksellisia ja viitekehyksiin perustuvia vaatimuksia tekemättä niistä yleistäviä väitteitä. Yleisen tietosuoja-asetuksen (GDPR) 32 artikla noudattaa riskiperusteista lähestymistapaa ja mainitsee salauksen asianmukaisten toimenpiteiden joukossa; se ei aseta yleistä salausvelvoitetta kaikelle käsittelylle. Salaus ei myöskään poista velvollisuuksia, jotka koskevat lainmukaista käsittelyä, pääsyä, säilytystä tai poikkeamien arviointia.

Rajatussa ISO 27001 -ISMS:ssä dokumentoi riskien käsittely, sovellettavat hallintakeinot, omistajuus ja näyttö sen sijaan, että olettaisit yhden salatun tietokannan täyttävän laajemman hallintajärjestelmän vaatimukset. Kun NIS2 on sovellettavissa kansallisen lainsäädännön kautta, sen 21 artiklan toimenpiteisiin kuuluvat kryptografiaa ja tarvittaessa salausta koskevat toimintaperiaatteet ja menettelyt. Varmista soveltuvuus ja kansalliset vaatimukset erikseen.

Suunnittele kryptografiset muutokset teknisenä riippuvuutena. Luetteloi algoritmit, varmenteet, kirjastot, protokollat ja sulautetut formaatit, jotta vanhentuneet mekanismit voidaan korvata. Arvioi pitkäikäisen luottamuksellisen tiedon osalta tulevien kryptoanalyyttisten ja kvanttiuhkien merkitys. Kvanttiturvalliseen kryptografiaan siirtymisen kysymykset eroavat avainten muodostamisessa, allekirjoituksissa ja symmetrisessä salauksessa; vältä testaamatonta kokonaiskorvausta, joka esitetään yleisratkaisuna.

Tee seuraavasta katselmoinnista konkreettinen

Secani voi kytkeä tähän työhön liittyvät kohdejärjestelmät, hallintakeinovaatimukset, toteutuskuvaukset, näytön, omistajat ja katselmointipäätökset. Liitä suojauskartta ja anonymisoidut testitietueet asiaankuuluviin järjestelmiin ja hallintakeinoihin, muuta ratkaisemattomat avainpääsyä tai palautusta koskevat kysymykset tehtäviksi ja säilytä tieto siitä, miksi kukin kryptografinen valinta hyväksyttiin. Katselmoi tekoälyavusteiset ehdotukset niiden lähteitä vasten ja pidä ihmisen hyväksyntä nimenomaisena.

Aloita yhdestä arkaluonteisesta tietovarastosta ja jäljitä tietoihin pääsy, avaimiin pääsy ja palautus yhdessä. Valitse yksi negatiivinen valtuutustesti ja yksi palautusharjoitus, nimeä omistajat ja kirjaa tulokset ennen soveltamisalan laajentamista. Pilviturvallisuusoppaamme tarjoaa ympäröivän konfiguraatiokontekstin.