Windowsin ja Linuxin koventaminen tarkoittaa järjestelmän hyökkäyspinnan pienentämistä ja suojausasetusten sovittamista sen käyttötarkoitukseen. Työssä poistetaan tarpeettomia palveluja, rajataan käyttöoikeuksia, suojataan ylläpitoyhteydet ja varmistetaan, että hyväksytyt asetukset pysyvät käytössä. Päivitys ja koventaminen täydentävät toisiaan: korjattu ohjelmisto voi silti olla tarpeettomasti avoinna verkkoon.
Koventamista ei kannata aloittaa irrallisten komentojen suorittamisesta tuotannossa. Ensin tunnistetaan käyttöjärjestelmän versio, laitteen rooli, sovellusten riippuvuudet ja palautusmahdollisuus. Tässä oppaassa kuvitteellinen Sataman suunnittelu koventaa Windows-työasemia ja yhtä Red Hat Enterprise Linux -palvelinta. Esimerkin päätökset ja poikkeukset kuvaavat sen omaa ympäristöä. Ne eivät ole kaikille suomalaisille organisaatioille määrätty yhtenäinen asetustaulukko.
Määritä lähtötilanne ja nimetty vertailutaso
Yritys kirjaa Windows-työasemien versiot, hallintatavan, laitemallit ja tärkeimmät sovellukset. Linux-palvelimesta kirjataan jakelu, versio, tarjottu palvelu, avoimet yhteydet ja ylläpidon reitti. Järjestelmäkartoitus kertoo, mihin toimintaan kohteet liittyvät. Tämän jälkeen voidaan valita juuri käytössä olevaan tuotteeseen ja versioon sopiva valmistajan ohje.
Microsoftin security baseline on valmistajan suositeltujen suojausasetusten kokonaisuus, johon sisältyy tietoa asetusten turvallisuusmerkityksestä. Se tarjoaa paremman lähtökohdan kuin satunnainen luettelo rekisterimuutoksista. Organisaatio arvioi kuitenkin soveltuvuuden, käyttöönoton ja poikkeukset. Työaseman suositusta ei sovelleta sellaisenaan kaikkiin palvelinrooleihin.
Sataman suunnittelu nimeää vertailutasoksi oman käytössä olevan Windows-version Microsoft-suosituksen ja Linux-palvelimelle vastaavan RHEL-version dokumentaation. Hyväksyttyyn päätökseen merkitään lähteen versio, tarkistuspäivä ja organisaation poikkeukset. Pelkkä sana ”CIS”, ”Microsoft” tai ”Linux hardening” ei kerro, mitä todella sovellettiin.
Rajaa käyttäjän ja ylläpidon oikeudet
Tavallinen käyttäjä ei tarvitse jatkuvasti paikallisia ylläpito-oikeuksia sähköpostin ja asiakasasiakirjojen käsittelyyn. Sataman suunnittelu tunnistaa ensin tehtävät, joissa korotettu oikeus on ollut käytössä. Yhden suunnitteluohjelman päivitys vaatii oikeuden, mutta päivittäinen käyttö ei. Ratkaisu on hallittu päivitysmenettely, ei kaikkien käyttäjien pysyvä ylläpitorooli.
Ylläpitotehtäviin käytetään erillisiä tunnuksia ja hyväksyttyä yhteystapaa. Paikallisen ylläpitotilin salaisuutta ei jaeta kaikille laitteille samana. Windows LAPS voi tuetussa ympäristössä hallita ja varmistaa paikallisen ylläpitotilin salasanaa. Käyttöönotossa selvitetään myös, kenellä on oikeus hakea salasana ja miten haku näkyy valvonnassa. Ominaisuuden nimi ei yksin osoita, että nämä oikeudet on rajattu oikein.
Ulkoisen huollon tunnukselle nimetään omistaja, käyttöaika ja tarvittavat kohteet. Huoltotunnus ei jää aktiiviseksi vain siksi, että toimittajan kanssa on voimassa oleva sopimus. Salasanapolitiikka ja tunnuksen palauttaminen määrittävät tunnistautumisen, mutta koventamisen tarkistuksessa katsotaan myös toteutuneet paikalliset tilit ja roolit.
Windowsin käytännön tarkistuskohteet
Windows-työasemista tarkistetaan levysalaus, palautusavaimen hallinta, palomuuri, haittaohjelmasuojauksen tila, sovellusten suoritusrajoitukset ja käyttöjärjestelmän suojausominaisuudet. Ominaisuuksien saatavuus ja toiminta riippuvat tuotteesta, versiosta, laitteesta ja hallinnasta. Esimerkiksi jonkin ominaisuuden oletustilaa ei pidä päätellä pelkästä Windows 11 -nimestä.
Sataman suunnittelu havaitsee, että kahden kannettavan salaus on keskeytetty huollon jälkeen. Korjaus ei rajoitu politiikan uudelleen hyväksymiseen: ylläpito palauttaa suojauksen sovitusti ja varmistaa sen tilan. Palautusavain on löydyttävä oikeutetulla menettelyllä myös silloin, kun käyttäjä ei voi kirjautua. Salauksen ja avainten hallinta käsittelevät tätä riippuvuutta tarkemmin.
Hyökkäyspintaa pienentävien ASR-sääntöjen käyttöönotossa yritys aloittaa valituilla säännöillä ja sopivalla arviointitavalla. Microsoftin käyttöönotto-ohje kuvaa suunnittelua, arviointia ja vaiheittaista käyttöönottoa. Tarkkailutilan tapahtumia käydään läpi ennen estävää asetusta silloin, kun se sopii säännön käyttöönottoon. Tarkkailutila ei kuitenkaan ole sama asia kuin toteutunut esto.
Pilotissa yksi sääntö estäisi hyväksytyn suunnitteluohjelman vientitoiminnon. Yritys selvittää ohjelman toimintatavan ja mahdollisen päivityksen. Se ei lisää koko käyttäjäkansiota pysyvään poikkeukseen. Mahdollinen poikkeus rajataan tunnistettuun tarpeeseen, sille nimetään omistaja ja poistumisen ehto. Microsoft 365:n erilliset suojausasetukset arvioidaan lisäksi, jos työasemalla käytetään kyseisiä palveluja.
Linuxin palvelut, oikeudet ja pakollinen pääsynvalvonta
Linux-palvelimella ensimmäinen kysymys on, mitä palvelua sen pitää tarjota. Sataman suunnittelun palvelin vastaanottaa yhden sisäisen sovelluksen aineistoa. Se ei tarvitse julkista hallintaliittymää tai työpöytäympäristön lisäpalveluja. Ylläpito vertaa käynnissä olevia palveluja hyväksyttyyn käyttötarkoitukseen ennen poistamista, koska näennäisesti tarpeeton osa voi tukea varmistusta tai valvontaa.
RHEL-ympäristössä SELinux tuo käyttöoikeuksien lisäksi käytäntöihin perustuvan suojakerroksen. Enforcing-tilassa käytäntöjen vastaisia toimia estetään. Permissive-tilassa niitä kirjataan mutta SELinux ei estä niitä. Tilojen ero on olennainen: raporttiin ei merkitä suojausta aktiiviseksi pelkästään siksi, että SELinuxin lokissa näkyy tapahtumia.
Esimerkkipalvelun käyttöönotto epäonnistuu ensin, koska sovelluksen uusi tiedostopolku ei sovi määriteltyyn pääsynvalvontaan. Ylläpito tutkii estomerkinnän ja tarkistaa tiedoston kontekstin sekä sovelluksen tarvitseman oikeuden. Koko SELinux-suojausta ei poisteta ratkaisuksi. Korjauksen jälkeen varmistetaan sekä luvallinen toiminto että raja, jonka pitäisi edelleen estää ylimääräinen pääsy.
Muissa jakeluissa käytettävät mekanismit ja hallintatavat voivat olla erilaisia. RHEL-ohjeen komentoa ei esitetä yleisenä Ubuntu-ohjeena. Myös järjestelmän laajuiset salauskäytännöt, palvelujen eristys ja tiedostojärjestelmän asetukset valitaan version ja roolin mukaan. Koventamisen tavoite on perusteltu suojaus, ei mahdollisimman suuri määrä muutettuja asetuksia.
Suojaa hallintayhteydet ja vähennä verkkonäkyvyyttä
Yritys tarkistaa, mistä hallintaan voi todella päästä. RDP- tai SSH-palvelun löytyminen koneelta ei yksin kerro internetnäkyvyyttä, eikä paikallisen palomuurin sääntö kerro koko pilviverkon toteutusta. Kartoituksessa huomioidaan reititys, välittävät palvelut, verkon säännöt ja mahdolliset poikkeavat hallintaportaalit.
Sataman suunnittelu rajaa Linuxin ylläpidon hyväksyttyyn hallintareittiin ja nimettyihin tunnuksiin. Ennen kirjautumistavan muutosta se varmistaa vaihtoehtoisen luvallisen palautusreitin. Muuten väärä asetus voisi sulkea myös ylläpidon ulos. Käyttämättömän verkkopalvelun sulkeminen tarkistetaan ulkoisesta näkökulmasta sovitussa rajauksessa, jotta pelkkä asetustiedoston muutos ei jää ainoaksi näytöksi.
Palvelun siirtäminen epätavalliseen porttiin ei korvaa tunnistautumista tai käyttöoikeuksia. Samoin salattu hallintayhteys voi olla tarpeettoman laajasti avoin. TLS:n ja varmenteiden tarkistus sekä oikeuksien arviointi käsittelevät eri puolia samasta käyttöpolusta.
Täytetty muutos- ja poikkeusluettelo
Pilotin jälkeen yritys kokoaa havainnot päätettäviksi. Alla oleva luettelo on kuvitteellisen ympäristön täytetty esimerkki:
| Havainto | Päätetty toimi | Hyväksymisen näyttö |
|---|---|---|
| Kahden kannettavan salaus keskeytetty | Suojaus palautetaan ja huollon jälkitoimi lisätään | Laitteen tila ja palautusavaimen saatavuus tarkistettu |
| Vanha paikallinen huoltotunnus | Tunnus poistetaan, kun riippuvuudet on tarkistettu | Kirjautuminen ei onnistu eikä hyväksytty huolto katkea |
| ASR-sääntö ja vientiohjelma ristiriidassa | Sovelluspäivitys tutkitaan; rajattu poikkeus omistajalle | Vienti toimii hyväksytysti ja muu esto säilyy |
| SELinux-estomerkintä uudessa polussa | Tarvittava konteksti ja oikeus korjataan | Palvelu toimii enforcing-tilassa ilman ylimääräistä oikeutta |
Jokaiselle avoimelle poikkeukselle kirjataan syy, riski, korvaava suojaus, vastuuhenkilö ja tarkistuspäivä. Päivämäärä on organisaation seurantaraja, ei automaattisesti lain sallima poikkeusaika. Jos perusteltua suojausta ei saada aikaan, palvelun käyttöä tai laajuutta on tarvittaessa muutettava.
Asetusten pysyvyys tarkistetaan myös uudelleenkäynnistyksen ja hallintapolitiikan päivityksen jälkeen. Esimerkiksi tilapäinen SELinux-tilan vaihto ei yksin osoita seuraavan käynnistyksen asetusta. Pilotissa ylläpito käynnistää sovitun harjoituspalvelimen uudelleen ja varmistaa suojauksen, sovelluksen sekä lokien toiminnan. Windowsissa se tarkistaa, ettei toinen hallintaprofiili palauta ristiriitaista arvoa seuraavassa päivityksessä.
Laiteryhmien erottelu auttaa rajaamaan käyttöönoton. Suunnittelutyöasemat, tavalliset toimistolaitteet ja palvelimet saavat rooliaan vastaavan hyväksytyn kokonaisuuden. Poikkeusta ei levitetä vahingossa koko organisaatioon muuttamalla yhteistä profiilia yhden vanhan ohjelman vuoksi. Käyttöönoton vastuuhenkilö tarkistaa ryhmän todelliset jäsenet ja varmistaa, että uuden laitteen liittyminen tuo sille oikean suojaustason.
Päivitys, palautus ja toimivuuden hyväksyminen
Kovennettu peruskuva vanhenee, jos ohjelmistot eivät saa korjauksia tai henkilöstö voi muuttaa asetuksia huomaamatta. Päivityksen kiireellisyydessä huomioidaan haavoittuvuuden hyväksikäyttö, kohteen näkyvyys, vaikutus ja käytettävissä olevat suojatoimet. Yhtä CVSS-taulukkoa ei nimetä kaikkien NIS2-toimijoiden lakisääteiseksi päivitysaikatauluksi. Tietoturvan perustoimet yhdistävät korjaukset omaisuuden ja vastuiden hallintaan.
Ennen laajaa käyttöönottoa pilotissa tarkistetaan kirjautuminen, tavalliset työtehtävät, päivitys, etätuki ja palautus. Turvallisuus- ja liiketoimintavaatimukset arvioidaan yhdessä. Palautus tarkoittaa hyväksyttyä tapaa korjata epäonnistunut muutos; se ei saa huomaamatta palauttaa kaikkia vanhoja turvattomia asetuksia pysyvästi. Palautumissuunnitelmassa kuvataan myös tämä raja.
Käyttöönoton jälkeen asetuksia verrataan hyväksyttyyn tilaan. Poikkeava laite selvitetään: oliko kyse hallinnan epäonnistumisesta, paikallisesta muutoksesta vai hyväksytystä erosta? Lokit ja seuranta auttavat tunnistamaan muutoksen ajankohdan. Raportin prosenttiluku ei riitä, jos kriittinen palvelin jää poikkeamien joukkoon ilman omistajaa.
Koventaminen tukee tietosuoja-asetuksen turvallisuusvelvoitetta, mutta tarkistusohjelman hyväksytty tulos ei osoita koko henkilötietojen käsittelyn lainmukaisuutta. Organisaatio säilyttää valitun vertailutason, sovelletut asetukset, todelliset havainnot ja ratkaistavat poikkeukset. Näin seuraava ylläpitäjä pystyy jatkamaan työtä ymmärtäen, miksi järjestelmä toimii juuri näillä rajoilla.
Lähteet
- Microsoft: Windows security baselines: suositusten sisältö ja käyttötarkoitus.
- Microsoft: ASR-sääntöjen käyttöönotto: suunnittelu, arviointi ja vaiheistus.
- Microsoft: Windows LAPS: paikallisen ylläpitotilin salasanan hallinta.
- Red Hat: RHEL 10 Security hardening: version mukaiset koventamisen osa-alueet.
- Red Hat: Getting started with SELinux: toimintatilat ja pääsynvalvonnan perusteet.
- Yleinen tietosuoja-asetus, 32 artikla: riskiä vastaavat turvatoimet.