TLS-asetukset ratkaisevat, millä ehdoilla asiakas ja palvelin muodostavat salatun yhteyden. Toimiva kokonaisuus tarvitsee ajantasaisen protokollan lisäksi oikean palvelinnimen, luotetun varmenneketjun, suojatun yksityisen avaimen ja uusimisen, joka tavoittaa kaikki liikennettä vastaanottavat palvelimet. Selaimen onnistunut käynti etusivulla ei yksin todista näitä asioita.
Tässä oppaassa rakennetaan kuvitteellisen Varauslahti Oy:n asiointipalvelulle tarkistettava TLS-politiikka. Yritys käsittelee asiakkaiden yhteystietoja ja varauksia verkkopalvelussa. Täytetty esimerkki auttaa erottamaan palvelun ulkoisen HTTPS-yhteyden sisäisistä yhteyksistä ja osoittaa, millä havainnoilla asetusten käyttöönotto hyväksytään.
Mitä TLS suojaa ja mitä jää sen ulkopuolelle?
TLS suojaa yhteyttä siihen pisteeseen, jossa salaus puretaan. Jos selain keskustelee kuormantasaajan kanssa, kuormantasaaja näkee puretun liikenteen. Sen ja sovelluspalvelimen yhteys on arvioitava erikseen. HTTPS ei myöskään estä sovellusta näyttämästä asiakkaan varausta väärälle kirjautuneelle käyttäjälle.
Varauslahdessa ylläpitäjä piirtää kolme yhteyttä: selain kuormantasaajaan, kuormantasaaja sovellukseen ja sovellus tietokantaan. Kaikkien vieressä on vastaanottajan nimi ja asetuksista vastaava henkilö. Näin järjestelmien ja riippuvuuksien kartoitus muuttuu tarkistuslistan perustaksi. Tietokannan levyjen ja varmuuskopioiden suojaus käsitellään erikseen henkilötietojen salauksen ja avainten hallinnassa.
GDPR:n 32 artikla edellyttää riskiä vastaavia teknisiä ja organisatorisia toimenpiteitä ja mainitsee salauksen yhtenä keinona. Se ei säädä kaikille suomalaisille verkkopalveluille tiettyä TLS-versionumeroa tai varmenteen uusimispäivää. Valinnan perustelu yhdistää käsiteltävät tiedot, uhkat, toteutuksen ja toimivuuden arvioinnin. Asetuksen 32 artikla on oikeudellinen lähtökohta; tekninen standardi auttaa toteutustavan arvioinnissa.
TLS 1.3 ja vuoden 2026 standardimuutos
Heinäkuussa 2026 julkaistu RFC 9852 päivittää RFC 9325:tä uusien TLS:ää käyttävien protokollien osalta. Näiden pitää tukea TLS 1.3:a ja käyttää sitä oletuksena. TLS 1.2 voidaan toteuttaa lisäksi muuna kuin oletuksena, jos käyttöönoton tarpeet perustelevat sen. Muutos ei koske DTLS:ää. Soveltamisala on uudet protokollat: jokaisen uuden verkkosivun julkaiseminen ei itsessään tarkoita uuden protokollan suunnittelua. RFC 9852, kohdat 4–5.
Varauslahti käyttää tavallista HTTPS:ää ja päättää suosia TLS 1.3:a. TLS 1.2 jää rajattua asiakasohjelmien yhteensopivuutta varten. Päätös ei perustu ajatukseen, että TLS 1.2 olisi automaattisesti lainvastainen, vaan sen ylläpito vaatii huolellisemman asetuskokonaisuuden. Yritys kirjaa asiakkaat, joiden vuoksi tukea tarvitaan, sekä vastuuhenkilön selvittämään niiden päivityksen.
SSL sekä TLS 1.0 ja 1.1 suljetaan pois. TLS 1.2:n sallituiksi yhdistelmiksi valitaan toteutuksen tukemat nykyiset vaihtoehdot, joissa käytetään väliaikaista avaintenvaihtoa ja todennettua salausta. Pelkkä pitkä avain ei tee vanhasta yhdistelmästä turvallista. RFC 9325 torjuu esimerkiksi NULL-salauksen ja RC4:n sekä käsittelee staattisen RSA-avaintensiirron puutteita. Myös TLS 1.3:n varhaisen datan eli 0-RTT:n käyttö tarvitsee sovelluskohtaisen turvallisuusarvion. RFC 9325, kohdat 3–4.
Esimerkkipalvelussa varauspyyntö muuttaa järjestelmän tilaa. Tiimi ei ota 0-RTT:tä käyttöön tämän toiminnon nopeuttamiseksi, koska toistettujen pyyntöjen hallintaa ei ole arvioitu. Sovelluksen oma yksilöllinen varaustunniste ja saman pyynnön uudelleenkäsittelyn esto toteutetaan joka tapauksessa. Verkon suojaus ja liiketoimintatapahtuman oikeellisuus tarvitsevat molemmat omat ratkaisunsa.
Täytetty päätös: kolme yhteyttä ja yksi hylätty asetus
Varauslahden ylläpito kirjaa ennen muutosta seuraavan tavoitetilan. Taulukko kuvaa harjoitusesimerkin ratkaisuja, ei kaikille järjestelmille valmista asetustiedostoa.
| Yhteys | Päätetty toteutus | Hyväksymisen havainto |
|---|---|---|
| Selain → kuormantasaaja | TLS 1.3 ensisijainen, TLS 1.2 perusteltuun yhteensopivuuteen | Molemmat tuetut asiakasryhmät toimivat; vanhat versiot torjutaan |
| Kuormantasaaja → sovellus | Salattu yhteys ja sovelluksen varmenteen tarkistus | Väärän palvelinnimen varmenne keskeyttää yhteyden |
| Sovellus → tietokanta | Salattu yhteys luotettuun tietokantapalvelimeen | Virheellinen luottamusketju estää kirjautumisen |
| Vanha huoltoliittymä | Suljetaan julkisesta verkosta, päivitys ennen käyttöönottoa | Ulkopuolinen yhteys ei tavoita liittymää |
Ensimmäisessä kokeessa ulkoinen verkkopalvelu saa hyvän TLS-tuloksen. Sisäinen yhteys kuitenkin hyväksyy minkä tahansa varmenteen. Ylläpitäjä oli ottanut tarkistuksen pois päältä väliaikaisesti palvelinnimivirheen vuoksi. Tätä ei hyväksytä: nimi ja varmenne korjataan vastaamaan toisiaan, ja tarkistus kytketään takaisin.
Korjaus muuttaa myös palautussuunnitelmaa. Jos uusi palvelin palautetaan varmuuskopiosta, sen pitää saada oikea varmenne ja luottamusketju. Sovellusta ei palauteta tuotantoon kiertämällä varmennusvirhettä. Asiakaspalvelulle sovitaan väliaikainen toimintatapa liiketoiminnan jatkuvuussuunnitelmassa, jotta kiire ei johda tarkistusten pysyvään ohittamiseen.
Varmenteen nimi, avain ja luottamusketju
Varmenne tarkistetaan sillä nimellä, jota asiakas todella käyttää. Esimerkkipalvelulla on erilliset asiointi- ja rajapintanimet. Yhden nimen onnistunut tarkistus ei todista toisen toimivuutta. Myös vaihtoehtoinen reitti ja varapalvelin käydään läpi. OWASP käsittelee palvelinnimien vastaavuutta, avainten suojausta ja useaan järjestelmään jaetun wildcard-varmenteen vaikutuksia. OWASP:n TLS-ohje.
Varauslahti ei kopioi samaa yksityistä avainta julkisesta asiointipalvelusta ylläpidon yhdyskäytävään. Eri käyttötarkoitusten erottaminen rajaa yhden avaimen vaarantumisen vaikutuksia. Yksityinen avain ei kuulu tukipyyntöön, dokumentaation liitteeseen eikä sovelluksen lähdekoodivarastoon. Sen käyttöoikeus annetaan vain sitä tarvitsevalle palvelulle ja rajatulle ylläpidolle.
Sisäisen varmentajan käyttäminen on mahdollinen ratkaisu sisäisiin yhteyksiin, jos luottamus ja varmentajan elinkaari hallitaan. Esimerkissä tietokantayhteyden luottamusketju jaetaan hallitulla asetuksella. Uutta juurivarmennetta ei hyväksytä tuotantoon pelkän sähköpostiliitteen perusteella. Ylläpito tarkistaa alkuperän sovitussa kanavassa ja kokeilee muutoksen ensin erillisessä ympäristössä.
Uusiminen pitää todentaa asiakkaan suunnasta
Julkisesti luotettujen TLS-palvelinvarmenteiden enimmäisvoimassaoloa on lyhennetty. CA/Browser Forumin voimassa olevien vaatimusten mukaan 15.3.2026 alkaen ja ennen 15.3.2027 myönnetyn tällaisen varmenteen voimassaolo saa olla enintään 200 päivää; suositeltu enimmäiskesto on 199 päivää. Tämä koskee kyseistä julkisen luottamuksen varmennejärjestelmää, ei yleistä GDPR-määräaikaa tai kaikkia yksityisen varmentajan varmenteita. TLS Baseline Requirements, kohta 6.3.2.
Varauslahden uusimisprosessi sisältää myöntämisen, jakelun, palvelun latauksen ja ulkoisen tarkistuksen. Uusimistyön onnistumismerkintä kattaa vain ensimmäisen vaiheen, jos vanha varmenne jää edelleen palvelimen muistiin. Prosessi suljetaan vasta, kun tuotannossa tarjottu varmenne on tunnistettu.
Harjoituksessa uusi varmenne päätyy ensimmäiseen kuormantasaajaan mutta ei toiseen. Yhden yhteyden tarkistus näyttää kaiken olevan kunnossa. Ylläpitäjä tarkistaa seuraavaksi kummankin taustalla olevan vastaanottavan solmun sovitulla tavalla ja havaitsee eron. Jakelutyön käyttöoikeus korjataan, molemmat solmut päivitetään ja liikennettä seurataan muutoksen jälkeen.
Hälytys osoitetaan ylläpidon yhteiselle päivystyskanavalle, jolla on nimetty vastuuvuoro. Se ei jää yhden lomalla olevan työntekijän postilaatikkoon. Uusimiseen käytettävän tunnuksen oikeudet rajataan tarvittavaan alueeseen. Jos DNS-vahvistus vaatii erillisen tunnisteen, sen säilytys ja vaihtaminen kuuluvat samaan avainten hallintaan.
Kun yksityisen avaimen epäillään vuotaneen
Esimerkin ylläpitäjä löytää vanhasta tukiliitteestä tiedoston, joka saattaa sisältää tuotannon yksityisen avaimen. Hän rajoittaa liitteen saatavuuden ja käynnistää selvityksen siitä, mitä avainta tiedosto vastaa ja ketkä ovat voineet saada sen. Pelkkä liitteen poistaminen ei tee jo kopioitua avainta salaiseksi. Vaihtosuunnitelmassa luodaan uusi avain, hankitaan sille varmenne, päivitetään kaikki sitä käyttävät palvelimet ja hoidetaan vaarantuneen varmenteen peruuttaminen varmentajan menettelyllä.
Samalla tarkistetaan, pääsikö sama tukitunnus muihin salaisuuksiin. Vanhalla avaimella suojattujen yhteyksien mahdollinen altistuminen arvioidaan toteutuksen ja havaintojen perusteella. Avainlöydöstä ei päätellä automaattisesti, että kaikki asiakkaiden tiedot olisi luettu, mutta tapahtumaa ei myöskään suljeta onnistuneen avaimenvaihdon perusteella. Selvityksen vastuuhenkilö vie henkilötietoihin kohdistuvan epäilyn organisaation tietoturvaloukkausten käsittelyyn.
HTTPS, uudelleenohjaus ja HSTS
Selaimelle tarkoitettu palvelu tarvitsee johdonmukaisen HTTPS-käytön. Kirjautumissivun suojaaminen ei riitä, jos seuraava sivu tai lomakkeen lähetys käyttää suojaamatonta yhteyttä. HSTS kertoo sitä tukevalle selaimelle, että sivustoon tulee käyttää HTTPS:ää määrätyn ajan. Sen aliverkkotunnuksiin ulottaminen vaatii niiden valmiuden selvittämistä. Tämä käytännön kokonaisuus sisältyy myös OWASP:n edellä mainittuun ohjeeseen.
Varauslahden vanha tapahtumasivusto on eri aliverkkotunnuksessa eikä vielä toimi HTTPS:llä. Tiimi korjaa sen ennen koko nimialueen kattavan käytännön käyttöönottoa. HSTS-asetuksen poistaminen palvelimelta ei välittömästi poista selainten jo muistamaa käytäntöä, joten palautuminen suunnitellaan etukäteen. Esimerkissä aloitetaan rajatulla kokeilulla ja pidennetään voimassaoloa vasta toimivuuden varmistuttua.
Mitä tarkistuksesta tallennetaan?
Tallennettava havainto sisältää palvelinnimen, tarkistusajan, käytetyn reitin, hyväksytyt protokollaversiot, varmenteen tunnistetiedot ja poikkeaman käsittelyn. Raportti ei tarvitse asiakkaiden istuntotunnuksia tai lomakkeiden sisältöä. Lokituksen suunnittelu auttaa valitsemaan tiedot niin, että virhe voidaan selvittää lisäämättä tarpeetonta henkilötietojen keräämistä.
Hyväksymiseen kuuluu myös kielteinen koe: vanha protokolla ei muodosta yhteyttä, väärä nimi ei kelpaa sisäiselle asiakkaalle ja varmenteen uusimisen hälytys tavoittaa vastuuhenkilön. Näitä havaintoja verrataan tavoitetilaan. Pelkkä skannerin yhteispistemäärä ei korvaa sisäisten yhteyksien ja liiketoimintatoimintojen tarkastelua.
Kun alusta vaihtuu, TLS-politiikka arvioidaan uudelleen todellista toteutusta vasten. Windowsin ja Linuxin koventaminen kattaa palvelimen muun perustan, ja tietoturvan perustoimet sitovat muutoksen päivityksiin, käyttöoikeuksiin ja palautumiseen. Varauslahden hyväksytty lopputulos on nimettyihin yhteyksiin sidottu toimiva ratkaisu, jonka uusiminen ja virhetilanteet on osoitettu käytännössä.