Uusi SharePoint Online Content Security Policy rikkoo räätälöintejä
Content Security Policy (CSP) eli sisällön suojauskäytäntö on verkkosivujen mekanismi, joka määrittää, mitä resursseja (skriptejä, tyylejä jne.) sivu saa ladata ja suorittaa. Sen tarkoituksena on vähentää XSS-hyökkäysten (cross-site scripting) ja muiden vastaavien selaimessa ajettavaan koodiin liittyvien injektiohyökkäysten vaikutuksia.
Aiemmin SharePoint Online ei tiukasti määritellyt sellaisia CSP-rajoituksia, jotka olisivat vaikuttaneet räätälöinteihin, joissa käytetään inline-skriptejä tai ulkoisia skriptiviittauksia. Microsoft on kuitenkin nyt linjaamassa SharePointia nykyaikaisten verkkosivustojen tietoturvakäytäntöjen mukaiseksi ja ottaa vaiheittain käyttöön tiukempaa sisällön suojauskäytäntöä SharePoint Online -ympäristöissä. Tämä on hyvä asia. Kunnolla konfiguroidun CSP:n ansiosta selain kieltäytyy suorittamasta injektoituja skriptejä, jotka ovat peräisin epäluotettavista lähteistä.
Aluksi SharePointin uusi CSP toimi vain raportointitilassa ja ainoastaan kirjasi rikkomukset lokiin. 1.3.2026 Microsoft alkoi kuitenkin vaihtaa tätä moodia SharePoint Online -tenanteissa pelkästä raportoinnista oikeaan käyttöön, joka käytännössä estää kaikkien uutta CSP:tä rikkovien skriptien suorittamisen.
Vaikka Microsoftin tavoitteena onkin pelkästään parantaa SharePoint Online -ympäristöjen tietoturvaa, muutos on ollut monille myös ikävä yllätys. Uusi tietoturvakäytäntö on yllättänyt monet organisaatiot, joiden räätälöinnit ovat perustuneet ulkoisiin skriptiviittauksiin ja inline-skripteihin, jotka on upotettu SharePointiin avoimen lähdekoodin Script Editor -verkko-osan avulla. Käytäntö estää tällaisten skriptien suorittamisen ja rikkoo näin nämä räätälöinnit kokonaan.
Jos työskentelet organisaatiossa, joka on havahtunut siihen, että uusi sisällön suojauskäytäntö on rikkonut SharePoint Online -räätälöinnit, tämä blogikirjoitus on juuri sinua varten. Käymme tässä läpi ne ratkaisuvaihtoehdot, jotka voidaan toteuttaa nopeasti lyhyellä tähtäimellä ja laadukkaasti pitkällä tähtäimellä.
Väliaikainen ratkaisu: poista uusi CSP käytöstä kesäkuun 2026 alkuun saakka
Väliaikaisratkaisuna, jolla saat itsellesi lisäaikaa pidemmän aikavälin ratkaisun toteuttamiseen, voit lykätä uuden CSP:n aktivointia alla olevalla skriptillä. Tämä palauttaa välittömästi suojauskäytännön rikkomien räätälöintien toimintakyvyn. Aktivointia voi kuitenkin lykätä vain 1. kesäkuuta 2026 saakka. Sen jälkeen (tai mieluiten hyvissä ajoin ennen sitä) sinulla täytyy kuitenkin olla pitkän aikavälin ratkaisu valmiina.
Katso Pdf-tiedostossa oleva skripti
Nopea ja helppo pidemmän aikavälin ratkaisu sisältää tietoturvariskejä
Toiseksi nopein tapa palauttaa alkuperäinen toiminnallisuus vaatii kaksi suhteellisen pientä muutosta. Molempiin liittyy kuitenkin mahdollisia tietoturvariskejä, jotka sinun tulee tiedostaa ja virallisesti hyväksyä, jos todella haluat lähteä tälle polulle.
Ulkoisten skriptidomainien lisääminen Trusted Script Sources -listalle
Jos SharePoint-räätälöinti nojaa ulkoisessa domainissa hostattuun skriptiin, saat kyseisen skriptiviittauksen taas toimimaan lisäämällä domainin Trusted Script Sources -listalle. Kolmannen osapuolen domainin lisääminen Trusted Script Sources -listalle aiheuttaa kuitenkin seuraavan tietoturvariskin:
Viitattu kolmannen osapuolen domainissa oleva JavaScript-tiedosto saattaa muuttua tulevaisuudessa ja alkaa sisältää tietoturva-aukon tai jopa hyökkäyskoodia. Näin voi käydä, jos kyseinen kolmas osapuoli esimerkiksi joutuu tietomurron kohteeksi. Ja kun viitattua JavaScript-tiedostoa muutetaan siten, että se sisältää tietoturva-aukon tai hyökkäyksen, haittakoodi ladataan ja suoritetaan SharePoint-ympäristössäsi heti, kun joku käyttäjä seuraavan kerran avaa sivun, joka viittaa kyseiseen tiedostoon.
Lisäämällä kolmannen osapuolen domainin Trusted Script Sources -listalle annat käytännössä kaiken luottamuksesi kyseisen domainin omistajan tietoturvakulttuurille ja julkaisuprosessille. Ja jos heidän järjestelmänsä korkataan, SharePoint-ympäristösi on seuraavana vuorossa. Tämän vuoksi sinun tulisi lisätä skriptilähteitä Trusted Script Sources -listalle vain silloin, kun hallitset täysin kyseisten skriptien sisältöä ja päivitysprosessia.
Jos räätälöintisi hyödyntää skriptiä, jota tällä hetkellä hostataan kolmannen osapuolen domainissa, on suositeltavaa, että vähintäänkin otat skriptistä kopion (ja tarkistat, ettei se sisällä tietoturvahaavoittuvuuksia), hostaat sen joko Microsoft 365:n -sisällönjakeluverkossa tai omassa ulkoisessa CDN:ssä, jota sinä itse hallinnoit (esimerkiksi Azuressa), ja päivität skriptiviittauksen osoittamaan tähän CDN:ään tallennettuun skriptitiedostoon. Näin vain ne organisaatiosi käyttäjät, joilla on pääsy CDN:ään, voivat päivittää skriptin.
Jos päädyt tallentamaan tietoturvatarkastetun version skriptistä ulkoiseen CDN:ään, voit lisätä CDN-domainisi Trusted Script Sources -listalle seuraavasti:
- Mene SharePoint Online Admin Centeriin
- Avaa Advanced ja valitse Script sources
- Lisää ulkoinen CDN-domainisi uudeksi luotetuksi skriptilähteeksi
React Script Editor -verkko-osan uusimman version käyttäminen
Jos olet hyödyntänyt avoimen lähdekoodin Script Editor -verkko-osaa lisätäksesi räätälöintejä SharePoint Online -sivuille, olet ehkä huomannut, että myös nuo räätälöinnit ovat rikkoutuneet. Ainakin toistaiseksi inline-skriptit on kuitenkin mahdollista saada taas toimimaan asentamalla React Script Editor -verkko-osan uusin versio.
Uusimmassa versiossa on mukana muutos, joka kiertää SharePointin CSP-rajoitukset käyttämällä Function-konstruktoria. Tämä toimii, koska SharePointin uusi CSP-konfiguraatio sisältää tällä hetkellä ’unsafe-eval’-direktiivin, joka sallii eval()-funktion ja Function()-konstruktorin käytön.
Tämän varaan ei kuitenkaan kannata rakentaa pitkän aikavälin räätälöintistrategiaa. Jos Microsoft päättää tulevaisuudessa poistaa ’unsafe-eval’-direktiivin SharePointin CSP-headereista (mikä olisi täysin järkevä tietoturvaa kiristävä toimenpide), tämä kiertotie lakkaa toimimasta välittömästi. Voit lukea lisää CSP-headereista ja -direktiiveistä MDN:n virallisesta dokumentaatiosta.
Edellä mainitun liiketoiminnan jatkuvuuteen liittyvän riskin lisäksi Script Editor -verkko-osan käyttämiseen liittyy seuraava tietoturvariski:
Kuka tahansa, jolla on oikeudet muokata SharePoint-sivua, voi liittää siihen mielivaltaista JavaScript-koodia. Tämä ei edellytä kaapattua tiliä. Hyvää tarkoittava sisällöntuottaja saattaa upottaa internetistä napatun, näennäisesti hyödyllisen koodinpätkän sivulle ymmärtämättä sen tietoturvaseurauksia ja sitä kautta altistaa käyttäjät vahingossa haavoittuvuudelle.
Eivätkä kaikki uhkatahot ole ulkoisia. Vaikka yleensä haluamme täysin luottaa kollegoihimme, organisaatiot koostuvat ihmisistä, jotka kohtaavat monimutkaisia tilanteita ja tunteita. Esimerkiksi organisaatiomuutokset tai irtisanomiset voivat johtaa turhautumiseen ja kyseenalaisiin päätöksiin. Haitallinen sisäpiiriläinen, jolla on sivunmuokkausoikeudet ja pääsy Script Editor -verkko-osaan, voi aiheuttaa merkittävää vahinkoa. Lisätietoa sisäpiiriuhista voit lukea blogipostauksesta Sisäiset riskit ja uhat – tietoturvan kuollut kulma?
Suositeltu pitkän aikavälin ratkaisu: SharePoint Framework
Turvallinen, moderni ja Microsoftin suosittelema tapa on toteuttaa räätälöinnit SharePoint Framework (SPFx) -ratkaisuina.
Sen sijaan, että injektoidaan skriptejä moderneille SharePoint-sivuille, toteutetaan asianmukaisesti paketoitu SPFx-verkko-osa tai -laajennos. Koodi katselmoidaan, versioidaan ja paketoidaan ja julkaistaan sen jälkeen SharePoint-sovelluskatalogin kautta tenanttiin. Tämä on linjassa ohjelmistokehityksen modernien parhaiden käytäntöjen kanssa ja toimii luontevasti uuden SharePointin sisällön suojauskäytännön määrittämien rajojen puitteissa.
Jos aiempi toteutus on nojannut ulkoisiin JavaScript-kirjastoihin, on mahdollista yhä viitata kyseisiin skripteihin SPFx-ratkaisuissa sen jälkeen, kun ne on ensin siirretty M365:n CDN:ään tai organisaation omaan CDN:ään. On kuitenkin suositeltavaa, että arvioidaan, ovatko nuo riippuvuudet yhä tarpeellisia vai voidaanko toiminnallisuudet toteuttaa suoraan SPFx-ratkaisussa moderneihin kirjastoihin nojaten.
Ulkoisista skriptiviittauksista ja sisällöntuottajien lisäämistä inline-skripteistä siirtyminen kunnollisiin SPFx-ratkaisuihin tuo useita etuja:
- Selkeästi organisoitu lähdekoodi, jota on helppo lukea
- Kunnolliset versionhallinta- ja koodikatselmointiprosessit, jotka tyypillisesti puuttuvat sivuille tungetuista satunnaisista koodinpätkistä
- Selkeä julkaisu- ja versiointimalli
- Luotettavampi sovelluksen ja siihen liittyvien oikeuksien hallinnointitapa
- Linjassa Microsoftin pitkän aikavälin suunnitelmien kanssa
Kyllä, tämä vaatii enemmän vaivaa kuin yksinkertaisesti skriptin lisääminen sivulle. Mutta se myös pienentää dramaattisesti tietoturvariskejä ja todennäköisyyttä sille, että ratkaisusi rikkoutuu seuraavan kerran, kun Microsoft parantaa SharePointin tietoturvaa.
Bonus: Muista säilyttää kaikki salaisuudet palvelinpuolella
Kun olen käynyt läpi näitä nyt rikkoutuneita, vuosikymmenen vanhoja toteutuksia ja miettinyt parasta tapaa korjata ne, olen törmännyt tapauksiin, joissa selainpohjainen ratkaisu kommunikoi suoraan ulkoisen rajapinnan kanssa API-avaimen avulla. Koska API-kommunikaatio tapahtuu selaimessa suoritettavassa koodissa, API-avain (joka vastaa salasanaa) on käytännössä kaikkien SharePoint-käyttäjien nähtävillä, jos he tietävät, mistä etsiä.
Tämän kaltaisilla salaisuuksilla on tapana olla paljon tavallista käyttäjää laajemmat oikeudet, usein järjestelmän kaiken datan luku- ja kirjoitusoikeudet. Siksi API-avaimet ja sovellussalaisuudet tulisi aina säilyttää turvallisesti eikä koskaan tuoda niitä osaksi selaimessa suoritettavaa koodia.
Jotta pidät API-avaimet ja muut salaisuudet turvallisesti selaimessa suoritettavan koodin ulkopuolella, on toteutettava erillinen ratkaisu palvelinpuolelle. Tyypillisesti tämä tarkoittaa Azure Function Appia tai Azure App Serviceä, joka on suojattu Entra ID -kirjautumisella. SharePoint Framework -ratkaisu kommunikoi tällöin Azure-sovelluksen kanssa, joka puolestaan kommunikoi ulkoisen rajapinnan kanssa. API-avain voidaan tallentaa Azure Key Vaultiin ja hakea sieltä palvelinpuolen koodiin käyttöön Azure-sovelluksen hallitun identiteetin (managed identity) avulla.
Voisin jatkaa tästä aiheesta loputtomiin, joten lienee parasta pysähtyä tähän ja käsitellä aihetta syvällisemmin erillisessä postauksessa. Olkoon tämä osio kuitenkin pieni muistutus siitä, että myöskään tässä kohtaa sovellusten tietoturvaa ei kannata oikaista.
Yhteenveto
Tiivistetysti, polkusi rikkoutuneesta räätälöinnistä parhaan käytännön mukaiseen ratkaisuun sisältää todennäköisesti seuraavat vaiheet:
- Jos räätälöinnit ovat jo rikki ja pystyt vielä lykkäämään CSP:n käyttöönottoa (ennen kesäkuuta), voit ”korjata” hajonneet toiminnallisuudet nopeasti PowerShell-skriptillä. Tämä on tilapäinen korjaus, joka antaa sinulle aikaa pidemmän aikavälin ratkaisun toteuttamiseen.
- Jos CSP:n käyttöönoton lykkääminen ei ole enää mahdollista (kesäkuusta eteenpäin), toiseksi nopein tapa palauttaa toiminnallisuus on lisätä ulkoiset skriptiviittaukset Trusted Script Sources -listalle ja/tai asentaa React Script Editor -verkko-osan uusin versio, jossa on kiertotie inline-skriptien suorittamiselle. Näitä lähestymistapoja tulisi kuitenkin myös käyttää vain väliaikaisena kiertotienä niihin liittyvien tietoturvariskien vuoksi.
- Noudattaaksesi parhaita käytäntöjä ja varmistaaksesi korkeimman mahdollisen tietoturvatason, tulee rakentaa SharePoint Framework -ratkaisu, joka toteuttaa aiemman räätälöintilogiikan modernilla ja turvallisella tavalla.
Jos kaipaat apua SharePoint Online -ratkaisuihin liittyen, olethan meihin rohkeasti yhteydessä!
Kirjoittaja:
