Nu träder EU:s uppdaterade NIS2-direktiv i kraft (2024), vilket gör frågan mer aktuell än någonsin. NIS2 ställer betydligt skarpare krav på cybersäkerhet, inte minst för offentliga aktörer. Direktivet omfattar numera offentlig förvaltning och många digitala tjänsteleverantörer, och betonar bland annat leverantörskedjans säkerhet, incidentrapportering och ansvarsutkrävande hos ledningen. Det innebär att beslutet att använda en extern molntjänst som Cloudflare inte längre är ett rent tekniskt val – det har blivit ett strategiskt riskbeslut som kan få regulatoriska konsekvenser. Samma egenskaper hos Cloudflare som tidigare kritiserats (till exempel bristande insyn i trafiken och potentiellt skydd av illasinnad aktivitet) kan nu sätta offentliga verksamheter på kollisionskurs med NIS2-kraven.

I denna uppföljande artikel analyserar vi de allvarligaste riskerna med Cloudflare ur ett NIS2-perspektiv. Flera svenska myndigheter använder redan Cloudflare för till exempel DNSSEC, webbapplikationsbrandvägg (WAF) och DDoS-skydd, så det är ingen abstrakt fråga. Hur påverkar Cloudflares utländska jurisdiktion, datahantering och tekniska upplägg en organisations förmåga att uppfylla NIS2?

Nedan går vi igenom fem nyckelområden: 

  • Jurisdiktion
  • Dataresidens
  • Insynsbrister
  • Beroenden
  • Incidentrapportering

Genom konkreta exempel (Schrems II-domen, CLOUD Act, den ökända Cloudbleed-buggen med flera) och koppling till aktuella EU-initiativ visar vi varför offentlig sektor måste väga dessa risker mycket noga. Vi avslutar med rekommendationer till beslutsfattare för hur man bör förhålla sig till Cloudflare i känsliga system, med fokus på att uppnå NIS2-efterlevnad.

Jurisdiktion: amerikansk lag kontra EU:s regelverk

En av de mest omtalade riskerna är Cloudflares jurisdiktion – dvs. det faktum att företaget är baserat i USA och därmed underställt amerikansk lag. Detta medför att lagar som US CLOUD Act och FISA 702 kan appliceras på data som Cloudflare hanterar. Konkret innebär det att amerikanska myndigheter kan kräva utlämning av data från Cloudflare, även om data fysiskt finns inom EU. Denna extraterritoriella räckvidd krockar direkt med EU:s dataskyddsregler: GDPR artikel 48 förbjuder utlämning av personuppgifter till utländska myndigheter utan rättslig grund i EU, och EU-domstolens Schrems II-dom (2020) slog fast att amerikansk övervakningslagstiftning inte uppfyller EU:s krav på nödvändighet och proportionalitet. Dessutom konstaterade domstolen att EU-medborgare saknar möjlighet till rättslig prövning i USA om deras data samlas in. Med andra ord finns en inneboende juridisk konflikt: Cloudflare kan tvingas lyda amerikansk lag på ett sätt som äventyrar europeiska sekretess- och integritets principer.

För offentlig sektor – som ofta hanterar känsliga personuppgifter och sekretessbelagd information – är detta ett rött varningstecken. I Sverige har man uttryckt stor försiktighet kring att använda molntjänster under utländsk lag. Samarbetet eSam har till exempel anfört att om en leverantör omfattas av CLOUD Act får man anta att sekretessreglerade uppgifter kan röjas för utlandet. Flera myndigheter har hamnat i ett ”dödläge” där man inte kunnat flytta data till amerikanska molnlösningar just på grund av risken för obehörig åtkomst och brott mot offentlighets- och sekretesslagstiftningen. Den pågående konflikten mellan EU:s och USA:s lagstiftning på området är välkänd och ännu olöst, trots nya ramverk som “Data Privacy Framework”. Kort sagt: Cloudflares amerikanska hemvist innebär en inneboende hög risk för att europeiska regler åsidosätts.

NIS2-direktivet adresserar denna fråga tydligt. I direktivets ingress betonas att riskhanteringen ska inkludera en analys av leverantörers juridiska hemvist och de risker det medför. Det handlar om digital suveränitet – EU vill säkerställa att kritiska tjänster inte är utlämnade till främmande makters lagar. Vi ser även konkreta initiativ som stöder detta synsätt: Enligt ENISA:s förslag till EU Cloud Certification Scheme (EUCS) ska den högsta säkerhetsnivån endast tilldelas molntjänster som har huvudkontor i EU, lagrar data inom EU och garanterar frihet från utländsk myndighetsaccess. Om detta antas skulle leverantörer som Cloudflare utestängas från de mest känsliga användningsområdena inom EU. Frankrike har redan infört en egen SecNumCloud-certifiering med liknande kriterier – franska myndigheter anser inte amerikanska moln “suveräna” så länge CLOUD Act gäller. Tyskland har varit något mer pragmatiskt, men även där pågår en dragkamp mellan behovet av amerikansk teknologi och kraven på juridisk kontroll.

Konsekvenser för NIS2-efterlevnad:

  • Hög risknivå: Enligt en färsk riskbedömning rankas Cloudflares amerikanska jurisdiktion som “Hög” risk (hög sannolikhet, hög konsekvens) för en offentlig verksamhet. Detta bedöms vara välgrundat med tanke på Schrems II-domen och den linje EU intar kring tredjelandsöverföringar.

  • Krav på åtgärder: NIS2 kräver att organisationer vidtar ”lämpliga och proportionerliga tekniska och organisatoriska åtgärder” för att hantera risker. Om man trots allt använder en USA-baserad tjänst som Cloudflare i känsliga system, måste man införa starka skyddsåtgärder (till exempel kryptering, avtal om datahantering) för att mitigera jurisdiktionsrisken. Vi återkommer till rekommendationer kring detta.

  • Framtida regleringar: Offentliga beslutsfattare bör beakta att trenden inom EU går mot ökad restriktivitet med utlandsberoende leverantörer. Att ignorera dessa signaler kan leda till att man om några år tvingas byta lösning under tidspress när regler skärps ytterligare. Jurisdiktionsfrågan är alltså inte bara en teoretisk diskussion – den kan avgöra om en tjänst som Cloudflare alls är tillåten för vissa applikationer framöver.

Dataresidens: var hamnar data och trafiken?

Nära kopplat till jurisdiktion är frågan om dataresidens, det vill säga, var data flödar och lagras. Cloudflare driver ett globalt nätverk av servrar i över 100 länder för att optimera prestanda. Det innebär att även om din webbserver och databas står i EU, så kan trafikdata, metadata och cache-innehåll mellanlagras på noder utanför EU beroende på nätverkets routing. Riskbedömningen noterar uttryckligen att trafik “kan routas utanför EU”, vilket utgör en potentiell överträdelse mot lokala krav på datalagring. Denna risk bedömdes som medel–hög i analysen.

Rent formellt stipulerar inte NIS2 att all data måste stanna inom EU. Men direktivet betonar att man ska adressera leverantörskedjans säkerhet och jurisdiktion (återigen dyker jurisdiktionsaspekten upp här). I praktiken hamnar dataresidensfrågan under flera regelverk: GDPR kräver skydd vid tredjelandsöverföring av personuppgifter, och nationella lagar kan förbjuda att sekretessbelagd information hanteras utanför svensk kontroll. Som nämnt ovan anser många att om en molntjänst lyder under CLOUD Act, så hjälper det föga att datacentren råkar ligga i EU – data är ändå inte ”säker” i europeisk mening.

Schrems II-domen (2020) underkände det tidigare Privacy Shield-avtalet mellan EU och USA och införde krav på fall-för-fall-bedömningar innan persondata förs över till tredjeland. Myndigheter och företag måste alltså genomföra s.k. överföringsbedömningar och eventuellt införa extra skydd (kryptering, med mera) om data kan hamna utanför EU. I Sverige har eSam och Integritetsskyddsmyndigheten signalerat att överföringar till USA ska ses som hög risk och hanteras med största försiktighet.

Under 2023 har flera kommuner och myndigheter fått kritik för användning av molntjänster utan ordentlig riskbedömning av tredjelandshantering.

Cloudflare är medvetet om dessa farhågor och har lanserat initiativ för att möta kunders krav på dataresidens. Bland annat erbjuds en “Data Localization Suite” där Cloudflare lovar att behandla kundens trafikdata endast i datacenter inom till exempel EU. Man kan även konfigurera en Customer Metadata Boundary som ska begränsa var vissa metadata lagras. Dessa lösningar, tillsammans med standardavtalsklausuler (SCC) för GDPR, är steg i rätt riktning. Men de eliminerar inte risken helt. Problemet är att de underliggande juridiska dilemman kvarstår: en USA-baserad aktör kan aldrig garantera full immunitet mot amerikanska myndighetskrav – oavsett var servrarna står. Cloudflare kan tekniskt sett försöka hålla data inom EU, men om en domstolsorder från USA kräver ut information som passerat deras nät, hamnar Cloudflare i en rävsax mellan att bryta mot EU-lag eller mot US-lag.

Konsekvenser för NIS2-efterlevnad:

  • Överföringsbedömningar: Offentliga verksamheter måste, enligt GDPR och god sed, göra en överföringsbedömning för Cloudflare om tjänsten används och det finns personuppgifter i trafiken. Givet CLOUD Act etcetera skulle en sådan bedömning sannolikt identifiera betydande risker som kräver stark kryptering eller att man avstår från att använda tjänsten för just de uppgifterna. NIS2 skärper kraven på att sådana analyser verkligen görs och dokumenteras.
  • Klassificering av data: Det blir viktigt att klassificera vilken data och trafik som passerar via Cloudflare. Öppna, offentliga webbplatser (utan inloggning eller känsliga uppgifter) kan anses mindre känsliga – där kan nyttan med Cloudflare väga upp riskerna. Känsliga personuppgifter eller säkerhetsklassad information är en annan sak; där talar mycket för att dataresidens- och jurisdiktionsrisken är oacceptabel. Att medvetet skicka till exempel sekretessbelagda personuppgifter genom Cloudflares globala nät skulle sannolikt ses som ett brott mot försiktighetsprincipen i offentlig verksamhet.

  • Mitigerande avtal: Som kompensation bör tydliga avtal finnas: Cloudflare måste åtaga sig att hålla data inom EU när det är möjligt, att informera om var data kan hamna och att bestrida orimliga myndighetsförfrågningar. Även om detta inte tar bort själva jurisdiktionskonflikten, kan det åtminstone visa att organisationen gjort vad den kunnat – något som kan vara avgörande vid en tillsyn enligt NIS2.

Sammanfattningsvis blir dataresidens och jurisdiktion två sidor av samma mynt. EU betonar alltmer ”cloud sovereignty”, så offentlig sektor behöver fråga sig: Hur stort problem vore det om vissa data via Cloudflare hamnar utanför EU-kontroll? Om svaret är ”oacceptabelt”, bör man välja bort Cloudflare för den tillämpningen – alternativt kryptera/kapsla in data så att även Cloudflare själv inte kan komma åt något användbart.

Bristande insyn: när molnskölden skymmer sikten

En teknisk risk som uppmärksammats är bristen på insyn när Cloudflare agerar mellanhand (”reverse proxy”). Cloudflares tjänst fungerar som en sköld framför din server: all trafik från användare går först genom Cloudflares nätverk där filtrering och cachning sker, innan den skickas vidare till din applikation. Detta ger många fördelar (skydd mot DDoS, filtrering av skadlig trafik, prestandaförbättring via cache), men också en nackdel: du som kund kan tappa viss sikt över vad som faktiskt sker i trafiken.

Två konkreta exempel på insynsproblem:

  • Dolda IP-adresser: När Cloudflare proxyar din webbtrafik syns inte besökarens riktiga IP-adress i dina loggar – i stället ser du en Cloudflare-IP. Original-IP kan fås via särskilda headers (CF-Connecting-IP), men det kräver att dina system stödjer och loggar dem. För många äldre system eller standardloggar innebär användning av Cloudflare att man förlorar information om var trafiken kommer ifrån. Det försvårar geobaserade analyser, blockering av enskilda hotaktörer, med mera.

  • Loggar i molnet: Mycket av logginformationen om vad Cloudflare blockerar eller släpper igenom finns hos Cloudflare, inte lokalt hos dig. För att se detaljerade loggar över HTTP-förfrågningar, cache-träffar, WAF-händelser etcetera måste du använda Cloudflares gränssnitt eller API. Här uppstår problem för framför allt mindre kunder: Cloudflare erbjuder fullständiga HTTP-loggar enbart till Enterprise-kunder. Om du inte betalar för högsta nivån kan din åtkomst till rådata vara begränsad – kanske får du bara aggregat eller kortare retentionstid. Riskbedömningen pekar ut att forensik och övervakning kan bli lidande utan rätt avtalsnivå.

För en offentlig aktör som måste upprätthålla hög säkerhet innebär bristande insyn att man potentiellt missar attacker eller anomalier. Det kan bli svårt att upptäcka en avancerad intrångskampanj om viktiga detaljer filtreras bort i molnet. Och om en incident utreds i efterhand, kanske kritisk bevisning ligger utom räckhåll på Cloudflares servrar. Man blir beroende av Cloudflares “goodwill” för att få ut all nödvändig information.

NIS2 kräver att organisationer har förmåga att detektera och hantera incidenter löpande.

Direktivet föreskriver bland annat att man ska ha kontinuerlig övervakning och regelbundna säkerhetstester. Om Cloudflare står för en stor del av säkerhetsfunktionaliteten (till exempel blockerar attacker), så måste man säkerställa att dessa händelser delas tillbaka till den egna organisationen. Annars riskerar man att leva i en falsk trygghet. Som NIS2-omfattad entitet förväntas man kunna uppvisa en lägesbild av sin cybersäkerhetssituation, något som förutsätter att loggar och trafikdata faktiskt är åtkomliga för analys.

Möjliga åtgärder för insyn:

Det finns sätt att mildra insynsbristen, vilka också rekommenderats i riskanalysen:

  • Avancerad logghantering: Utnyttja Cloudflares funktioner som Logpush för att i realtid skicka över loggdata (HTTP requests, DNS-förfrågningar, WAF-events, etcetera) till er egen miljö för lagring och analys. Integrera Cloudflare-loggarna i ert SIEM övervakningssystem. Målet bör vara att nästan all relevant trafikdata som Cloudflare ser, ska ni också se – åtminstone i efterhand.

  • ”Dubbel-loggning”: Fortsätt logga så mycket som möjligt i era egna system. Även om Cloudflare står framför, se till att er originserver loggar besök (med forwarded IP), och logga eventuellt krypterad trafik innan den går in i Cloudflare. Vissa organisationer kör till exempel en parallell nätverkssniffer eller en IDS på trafiken som går in/ut ur Cloudflare, för att ha en egen kopia.

  • Kontraktuella krav: Skriv in i avtal/SLA att ni vid säkerhetsincidenter ska få omedelbar tillgång till relevanta loggar hos Cloudflare. För kritiska system kanske ni vill avtala om utökad loggtillgång även utan Enterprise-paket. Kräv också revisionsrätt – att ni eller en tredje part ska kunna granska Cloudflares kontroller och få insyn (under NDA om behövs) i säkerhetsprocesser.

  • Tester: Genomför regelbundet tester där ni simulerar en incident och utvärderar hur mycket data ni lyckas få fram med nuvarande loggnivåer. Om testerna visar luckor – justera konfigurationen därefter.

Kort sagt gäller det att ta tillbaka kontrollen över datan så långt det går. Cloudflare får inte bli en “svart låda” i er infrastruktur. I värsta fall kan en mellanhand som förlänger era ögon och öron också fungera som en ögonbindel om ni inte har rätt tillgång. Var också medveten om att om Cloudflare själv skulle utsättas för en attack (till exempel en supply chain-attack på deras plattform) kan det vara svårt för er att upptäcka i tid. Sådana scenarion bör ingå i er riskanalys: ”Vad gör vi om Cloudflare komprometteras eller filtrerar bort något vi borde se?”

Beroende av extern aktör: risk för inlåsning och single-point-of-failure

Cloudflare är idag en kritisk del av internet: företaget uppger att de hanterar trafik för över 30 miljoner webbplatser och står som skydd framför en betydande andel av all webtrafik. Om en offentlig verksamhet väljer att lägga sin webbplats eller e-tjänst bakom Cloudflare innebär det att en extern leverantör plötsligt ansvarar för en stor del av tillgängligheten och säkerheten. Detta skapar ett beroende som måste hanteras.

Riskanalysen lyfter fram flera dimensioner av detta beroende:

  • Svårt att byta snabbt: Om ni byggt upp er infrastruktur kring Cloudflares tjänster (DNS, certifikat, WAF-regler, med mera) kan det vara operativt svårt att byta leverantör med kort varsel. Tänk er att Cloudflare drabbas av en allvarlig sårbarhet eller att en ny lag tvingar er att sluta använda tjänsten – hur snabbt kan ni ställa om till en annan lösning? Denna inlåsningseffekt är reell, särskilt om man använt många av Cloudflares mervärdestjänster.

  • Single point of failure: Även om Cloudflares driftsäkerhet normalt är mycket hög, är det inte ofelbart. Det finns incidenter som visar att fel hos Cloudflare kan få globala konsekvenser – till exempel råkade en felaktig nätverksregel 2019 slå ut Cloudflares tjänster i ~30 minuter för stora delar av internet, vilket drabbade många kunders sajter. Och 2020 upplevde Cloudflare ett avbrott som påverkade delar av Europa. Om er verksamhet inte har redundans eller en backup-väg utanför Cloudflare, så utgör detta en ensam felpunkt. Som riskanalysen noterar: Cloudflares styrka och storlek eliminerar inte risken för totalavbrott – den kvarstår om all trafik går genom en aktör.

  • Leverantörskedjerisk: NIS2 framhäver vikten av att hantera risker i leverantörskedjan. Om Cloudflare skulle bli fientligt inställt (till exempel vid en avtalskonflikt) eller drabbas av cyberangrepp, är det i praktiken en sårbarhet i er kedja. Faktum är att NIS2 artikel 21 kräver att organisationer utvärderar säkerheten hos sina leverantörer och tar hänsyn till deras sårbarheter. Cloudflare får betraktas som en ”kritisk tredjepart” i er IT-leverans om ni är beroende av dem för drift.

Ur NIS2-synpunkt är kontinuitet och resiliens nyckelord. Direktivet kräver att man planerar för att upprätthålla samhällsviktiga tjänster även under störningar. Här blir ”Vad händer om Cloudflare faller bort?” en central fråga. I riskanalysen bedömdes beroendet av Cloudflare som hög risk (medelhög sannolikhet, hög konsekvens), just för att en plötslig förlust av Cloudflare kan lamslå en organisation utan beredskap.

Strategier för att hantera beroendet:

  • Redundans: Se till att det finns en fallback-plan om Cloudflare skulle fallera. Det kan vara alternativa DNS-servrar (som kan tas i bruk om Cloudflare DNS ligger nere) eller en parallell enklare CDN/proxy-tjänst som kan ta över basfunktioner. Vissa organisationer har en ”bypass”-mekanism – till exempel att man snabbt kan peka om domänen direkt till originservern ifall Cloudflare är otillgängligt. En sådan plan bör testas praktiskt i förväg.

  • Exit-strategi: Redan vid upphandling bör man tänka på exit-strategin – hur avslutar vi Cloudflare vid behov? Hur lång tid tar det att migrera DNS-zoner, certifikat, WAF-regler etcetera till en ny plattform? Planera för en ordnad övergång så att ni inte blir ”fast” om omvärlden förändras. Under NIS2 förväntas organisationer ha beredskap för scenarier där en leverantör måste ersättas.

  • Leverantörsdiversifiering: Överväg att inte lägga alla ägg i samma korg. Kanske kan ni använda Cloudflare för vissa tjänster men hålla andra kritiska tjänster på en annan lösning. Det begränsar konsekvensen om en leverantör går ner. Dock ska man väga detta mot komplexitet – ibland kan flera leverantörer innebära mer att hantera säkerhetsmässigt. Huvudpoängen är att medvetet välja var man kan tolerera ett Cloudflare-bortfall och var man inte kan det.

  • Avtalsmässiga skydd: Försök skriva in åtaganden från Cloudflare kring support vid incidenter och förhandsmeddelanden vid förändringar. Om Cloudflare till exempel planerar en ändring som kan påverka er, vill ni veta det. Om ni själva måste avbryta avtalet p.g.a. lagkrav, bör det finnas en smidig väg ut utan lång bindningstid.

Att vara beroende av tredjepartstjänster är inget nytt, men NIS2 höjer ribban för hur detta beroende ska hanteras. Ledningen ska känna till riskerna och aktivt mitigera dem. Ett tankeväckande citat från analysdokumentet är: “Cloudflare bör inte användas i system som omfattas av NIS2 utan tydliga tekniska och organisatoriska skyddsåtgärder”. Det vill säga, om man inte har stenkoll på redundans, kontrakt och säkerhetsåtgärder – då bör man låta bli att göra sig så beroende av en extern aktör i kritiska system.

Incidentrapportering under NIS2: utmaningar med Cloudflares involvering

En av de mest konkreta nyheterna i NIS2 är de skarpa kraven på incidentrapportering. ”Väsentliga” verksamheter (dit bland annat många myndigheter kommer räknas) måste skicka en första indikationsrapport inom 24 timmar efter att en allvarlig incident upptäckts, och en mer detaljerad rapport inom 72 timmar. Detta innebär att organisationer behöver upptäcka incidenter snabbt och ha tillgång till detaljerad information för att kunna rapportera orsak, omfattning, påverkade system, åtgärder etcetera på bara några dygn.

Cloudflare kan påverka denna process på både positiva och negativa sätt:

  • Hjälpande hand: Cloudflare kan, rätt använt, faktiskt minska antalet incidenter som drabbar er. Om Cloudflare blockerar en stor DDoS-attack eller filtrerar bort känd skadlig trafik via WAF, kanske ni aldrig behöver rapportera det som en incident (eftersom det stoppades i tid). Cloudflare har ett säkerhetsteam som övervakar globala hot, och de kan ibland varna kunder vid större angrepp. Exempel: om er webbplats blir måltavla för en enorm bot-attack kan Cloudflare märka detta och notifiera er att något är på gång. Denna typ av ”proaktiv incidenthantering” kan stärka er säkerhet och göra att ni klarar er utan avbrott. I bästa fall fungerar Cloudflare som en partner som förser er med threat intelligence och första linjens försvar.

  • Försvårande omständighet: Å andra sidan, om en incident faktiskt inträffar som involverar Cloudflare blir situationen mer komplex. Tänk er att ni upptäcker att data har läckt eller ett intrång skett, och det visar sig att angriparen utnyttjade Cloudflares infrastruktur för att dölja sig. Kanske ser ni spår av skadlig trafik men bara Cloudflares IP-adresser. Då är ni beroende av Cloudflare för att få fram loggar som visar den ursprungliga källan (till exempel via deras CF-RAY ID eller andra loggparametrar). Om Cloudflare inte levererar dessa uppgifter snabbt, sitter ni med ofullständig information när klockan tickar mot 72-timmarsdeadlinen. Ännu värre om incidenten ligger hos Cloudflare själv – till exempel Cloudbleed-buggen 2017 där ett programfel hos Cloudflare orsakade att kunddata läckte ut i klartext via cachar och sökmotorer. I en sådan situation måste ni lita på Cloudflares egen utredning av vad som läckt, och era rapporter till myndighet får bygga på Cloudflares information. Det säger sig självt att rapportera en incident utan att själv ha full insyn sätter er i en svår sits.

Riskbedömningen för Cloudflare under NIS2 pekar just ut ”potentiellt försvårad incidentrapportering” som en risk. Bristande insyn (som vi behandlade ovan) kan göra att ni upptäcker incidenter för sent eller inte kan sammanställa en komplett incidentrapport i tid. För NIS2-efterlevnad är detta problematiskt – en ofullständig eller sen rapport kan i sig leda till sanktioner, utöver de konsekvenser själva incidenten har.

Rekommendationer för incidenthantering:

  • Avtala om support: Se till att ert avtal med Cloudflare inkluderar snabb support vid säkerhetsincidenter. Ni bör ha en namngiven kontakt eller tydlig process för att eskalera ärenden och få ut loggar/information inom timmar – inte dagar. Cloudflare som leverantör bör åta sig att bistå så att ni kan möta era lagkrav. Detta innefattar också klargöranden om vem som rapporterar vad: Om till exempel Cloudflare självt drabbas av en incident (som Cloudbleed), kommer de informera er skyndsamt så att ni kan rapportera vidare?

  • Öva incidenter med Cloudflare i loopen: Inkludera Cloudflare i era incidentövningar. Om ni gör en table-top-övning eller teknisk drill, simulera att Cloudflare-loggar behövs och se hur fort ni kan få fram dem. Identifiera kontaktvägar till Cloudflare. Allt för att undvika att första gången ni testar processen är skarpa läget.

  • Tydlig ansvarsfördelning: NIS2 inför delvis nytt ansvar på leverantörer också. Cloudflare kommer sannolikt själva att omfattas av NIS2 (de klassas antagligen som leverantör av digitala infrastrukturtjänster). Det innebär att Cloudflare kan ha egna rapporteringsskyldigheter för incidenter som drabbar deras tjänst. Ni bör hålla er informerade om hur Cloudflare agerar kring detta – till exempel om de utfärdar ”incident advisories” till kunder. I bästa fall kan Cloudflares egen NIS2-efterlevnad bli en fördel för er, om de snabbt kommunicerar problem. I värsta fall kan ni inte förlita er på det, utan måste anta att ni själva måste driva på.

  • Inbyggd redundans i rapportering: Om Cloudflare är nere eller otillgängligt under en incident (kanske själva orsaken till incidenten), hur ska ni då samla fakta? Se om ni kan ha någon övervakning utanför Cloudflare (till exempel externa syntetiska transaktioner, annan loggkälla) så att inte all er evidens vilar på en leverantör som kanske är mitt i kaoset.

I offentlig sektor kan dessutom förtroendeskadan bli stor om det framkommer att man saknat kontroll. Media och tillsynsmyndigheter kan fråga: ”Visste ni om riskerna med en utländsk molntjänst, och hur säkerställde ni att inga medborgaruppgifter kom på villovägar?”. Här gäller det att kunna visa att man gjort sin hemläxa. En dokumenterad riskbedömning (såsom den vi refererar till här) och vidtagna motåtgärder blir rentav en livlina för att visa att ledningen agerat med due diligence. Enligt NIS2 bär ledningen ansvaret, med möjliga personliga sanktioner vid grov försummelse. Alltså: incidenthantering är inte bara en IT-fråga, utan en ledningsfråga. Beslutet att använda Cloudflare i känsliga system bör därför förankras i högsta ledningen just med tanke på de rapporterings- och ansvarsplikter som kommer med NIS2.

Mot en balanserad strategi – rekommendationer för beslutsfattare

Cloudflare erbjuder utan tvekan stora tekniska fördelar. Högre prestanda globalt, kraftfullt skydd mot DDoS-attacker, avlastning av egna system och ett ekosystem av säkerhetstjänster – allt detta kan möjliggöra digitala satsningar som annars vore svåra att genomföra, särskilt för mindre organisationer. Offentlig sektor står under press att leverera snabba och pålitliga e-tjänster, och molntjänster som Cloudflare kan teoretiskt hjälpa till att höja säkerhetsnivån generellt.

Men som vi har visat med stöd av både riskanalys och aktuella EU-trender medför Cloudflare också betydande risker för en NIS2-omfattad verksamhet, särskilt om inga extra åtgärder vidtas. Faktorer som juridisk suveränitet, dataresidens, insyn och kontinuitet har seglat upp som strategiska frågor – inte bara tekniska detaljer – i och med NIS2 och den europeiska debatten om digital självständighet. Det gäller nu för beslutsfattare att väga fördelar mot risker på ett strukturerat sätt. Man får varken bländas av marknadsföringens löften eller drabbas av onödig alarmism; i stället krävs en nyanserad, evidensbaserad bedömning.

Avslutningsvis vill vi ge några tydliga rekommendationer till IT-chefer och andra beslutsfattare inom offentlig sektor som överväger eller redan använder Cloudflare i känsliga eller kritiska system:

  1. Genomför en formell riskanalys enligt NIS2: Dokumentera riskerna med Cloudflare i er miljö, jämfört med alternativa lösningar. Inkludera leverantörens jurisdiktion som en parameter – NIS2 kräver numera uttryckligen att detta beaktas. Bedöm sannolikhet och konsekvens för scenarier som ”åtkomst av främmande stat till data”, ”Cloudflare orsakar driftavbrott”, ”loggar otillräckliga vid incident” etcetera Var ärliga med osäkerheter och utgå från worst case i kritiska fall (försiktighetsprincipen). Detta underlag behövs för att motivera era beslut inför både intern revision och extern tillsyn.

  2. Begränsa användningen utifrån systemets känslighet: Tillämpa principen ”rätt sak på rätt plats”. För varje system eller dataklass, avgör om risknivån med Cloudflare är acceptabel. Icke-kritiska, publika system (till exempel en kommunal informationswebb) kan mycket väl drivas via Cloudflare – där kanske prestanda- och säkerhetsvinsterna överväger. Kritiska system eller sådana med känslig information (till exempel interna e-tjänster med persondata, hälsosystem, rättsväsende-applikationer) bör man starkt överväga att inte lägga på ett utlandsägt moln Proxy. Som riskdokumentet uttryckte det: använd Cloudflare endast i icke-kritiska system som tål den extra risknivån. På så vis begränsar ni värsta möjliga konsekvens ifall något går snett – ni sprider risken.

  3. Ställ krav och vidta skyddsåtgärder om ni använder Cloudflare: Om ni beslutar att ändå använda Cloudflare för ett visst system, gör det med ”säkerhetsbälte och airbag på”. Bygg in kompensatoriska kontroller för att hantera de risker vi diskuterat. Några centrala åtgärder är:

    • Juridiska avtal: Säkerställ att ni har gällande Standardavtalsklausuler (SCC) för GDPR med Cloudflare och att de förbinder sig att hålla data inom EU när det är möjligt. Försök få in skrivningar om att leverantören ska meddela och bestrida eventuella myndighetskrav på era data (Cloudflare har offentligt sagt att de gör detta, men det är bra att ha skriftligt).

    • Dataplacering: Utnyttja tekniska möjligheter som Cloudflare Data Localization Suite – konfigurera att er trafik endast ska hanteras i EU-datacenter. Följ upp var era data faktiskt går; begär rapporter om vilka datacenter som oftast används för er domän. Om möjligt, lås trafiken till specifika regioner.

    • Kryptering end-to-end: Ha alltid TLS-kryptering hela vägen från klient till er originserver (Cloudflare stöder detta genom Full (strict)-läget). Använd egna certifikat på origin och se till att Cloudflare inte kan kringgå krypteringen. Detta förhindrar att någon (inklusive Cloudflare själv eller en aktör som får tillgång till deras system) kan läsa känsligt innehåll i klartext. All data som passerar deras servrar blir då åtminstone krypterad “på ytan”.

    • Loggning och övervakning: Aktivera Logpush/Logpull av så många loggtyper som möjligt till en miljö ni själva kontrollerar. Samla Cloudflare-loggar, analysera dem ihop med era egna systemloggar. Sätt upp larm som korrelerar Cloudflares attacker/blockeringar med era interna händelser. Öva på att spåra en händelse genom både Cloudflare och era egna loggar.

    • Redundansplan: Implementera en fallback (till exempel alternativa DNS, backup-proxy eller bypass-möjlighet) ifall Cloudflare skulle fallera eller behöva kopplas bort akut. Dokumentera och testa denna plan regelbundet.

    • Exit-plan: Definiera hur ni vid behov skulle avsluta användningen av Cloudflare. Hur snabbt kan ni avveckla tjänsten och övergå till en annan leverantör eller driftsmodell? Detta bör finnas nedtecknat så ni inte famlar om ni ställs inför faktum. NIS2 betonar robusthet och det inkluderar att inte bli fast i en ohanterlig sits.

    • Revisionsrätt och tester: Utnyttja möjligheter att ta del av Cloudflares revisioner/certifieringar (ISO 27001, SOC 2 etcetera). Om möjligt delta i kundrevisioner eller be att få se mer detaljer under NDA – insyn bygger förtroende. Fortsätt även med egna penetrationstester på era system med Cloudflare aktiverat, så att ni verifierar både skydd och identifierar eventuella blinda fläckar.

  4. Håll er uppdaterade om EU-regler och vägledningar: Landskapet inom cybersäkerhet och dataskydd är i ständig förändring. Nya lagkrav och standarder kan tillkomma som påverkar er leverantörsstrategi. Följ utvecklingen av till exempel EUCS-certifieringen – om högsta klassning där blir ett krav för vissa offentliga system kan det utesluta utländska molntjänster. Håll koll på nästa kapitel i Schrems-ärendet – ett Schrems III kan mycket väl dyka upp om nuvarande arrangemang inte anses tillräckliga. Myndigheter som MSB och PTS kommer sannolikt med vägledningar kring NIS2-efterlevnad; bevaka dessa. Poängen är att vara proaktiv: om ni förutser att “om två år kanske Cloudflare inte är tillåtet för oss”, då är det bättre att agera nu (till exempel utvärdera alternativ) än att panikartat tvingas agera då.

  5. Förankra och vara transparenta: Se till att ledningen och relevanta intressenter är införstådda med resonemanget. Presentera riskbilden och åtgärderna för er styrelse eller direktion – NIS2 betonar ledningens ansvar, så de måste vara med på tåget. Var också beredda att möta frågor från media eller allmänhet: dokumentera ert beslutsunderlag så att ni kan visa att ni gjort en noggrann avvägning och vidtagit nödvändiga skyddsåtgärder. Inom offentlig sektor är öppenhet viktigt; hellre proaktiv transparens om er molnanvändning än att det uppfattas som att ni smugit in en potentiellt kontroversiell leverantör.

Genom att följa dessa riktlinjer kan offentliga aktörer navigera det dilemma som Cloudflare och liknande tjänster innebär. I vissa fall kanske det mest ansvarsfulla är att avstå och välja en lokalt förankrad lösning, trots högre kostnad eller visst funktionsbortfall – när samhällskritiska värden står på spel är riskaptiten låg. I andra fall kan man med gott samvete använda globala molntjänster, men då med rigorösa kontroller, noga avgränsad användning och ständig beredskap i bakfickan. Nyckeln är att göra informerade beslut där man kontinuerligt väger nyttan mot risken och är beredd att justera kurs när omvärlden förändras.

Slutsats

Cloudflare själv marknadsför visionen att “bygga ett bättre internet”. Det må så vara, men för offentlig sektor år 2024+ gäller att inte lämna något åt slumpen. NIS2 sätter strålkastarljuset på leverantörer som Cloudflare – efterlevnad och säkerhet måste gå hand i hand. Genom att proaktivt adressera riskerna vi tagit upp här kan myndigheter och offentliga verksamheter både skydda medborgarnas data och dra nytta av modern teknik på ett ansvarsfullt sätt. Balansen mellan innovation och försiktighet är svår, men med rätt åtgärder är den möjlig att uppnå. Det arbete ni lägger ned idag, innan en incident eller tillsyn tvingar er, är en investering i både robusthet och förtroende för er organisation. NIS2 må höja kraven – men också kvaliteten – på våra gemensamma digitala ekosystem, och det är upp till varje beslutsfattare att se till att vi lever upp till den ambitionen.