Uppe.nu

TL;DR: Schrems II-domen (CJEU C-311/18, juli 2020) ogiltigförklarade Privacy Shield och slog fast att data i USA inte har likvärdigt skydd som inom EU. Den centrala konsekvensen: en EU-baserad cloud-leverantör med amerikanskt moderbolag — AWS, Microsoft Azure, Google Cloud — kan tvingas lämna ut data till US-myndigheter via CLOUD Act eller FISA 702, även om hårdvaran står i Frankfurt eller Stockholm. SCC (Standard Contractual Clauses) löser inte problemet automatiskt. För svenska företag som hostar känslig data är moderbolagsjurisdiktion en separat faktor från fysisk dataplats.

Vad är Schrems II — kort

Max Schrems, österrikisk jurist och dataskyddsaktivist, drev sedan 2013 mål mot Facebooks dataöverföringar från EU till USA. Schrems I (2015) ogiltigförklarade Safe Harbor-avtalet. Schrems II (juli 2020) ogiltigförklarade dess efterföljare Privacy Shield. EU-domstolen slog fast att amerikansk lag — specifikt FISA Section 702 och Executive Order 12333 — ger US-myndigheter bred åtkomst till data hos amerikanska tjänsteleverantörer utan EU-likvärdig rättssäkerhet.

Konsekvensen: överföring av personuppgifter från EU till USA kräver ytterligare skyddsåtgärder utöver SCC, och i många fall är dessa praktiskt omöjliga att uppfylla.

CLOUD Act — den parallella historien

Clarifying Lawful Overseas Use of Data Act (USA, 2018) klarlägger att amerikanska brottsutredande myndigheter kan kräva data från amerikanska tjänsteleverantörer oavsett var data fysiskt lagras. AWS i Frankfurt, Microsoft Azure i Stockholm, Google Cloud i Belgien — alla omfattas av CLOUD Act eftersom moderbolagen är amerikanska.

Det här är skilt från Schrems II men förstärker problemet. Schrems II handlar om överföringar; CLOUD Act handlar om åtkomst till data som aldrig ”lämnar” EU.

Vad händer i praktiken vid en CLOUD Act-begäran?

Tre scenarier som faktiskt har inträffat eller är dokumenterade:

Scenario 1: Konkreta brottsutredningar

FBI eller DOJ kräver data från ett US-bolag som driver EU-datacenter. Bolaget kan välja att:

• Lämna ut data direkt — i strid med GDPR men i enlighet med amerikansk lag
• Bestrida via egen jurist (sällan framgångsrikt, dyrt)
• Försöka få MLAT-process (mutual legal assistance treaty) — saktar ner men löser sällan principfrågan

Microsoft tappade sitt eget ”Microsoft Ireland”-fall (2018) som föranledde CLOUD Act från början. Sedan dess har juridiska invändningar mot CLOUD Act-begäran i praktiken slagits ner.

Scenario 2: Bulk-program enligt FISA 702

NSA:s PRISM-program ber stora US-cloudleverantörer regelbundet om data. Antalet begäran är hemligstämplat men Googles transparency report redovisar ~70 000 FISA-baserade begäran per halvår (2024-data). Begäran specificeras med ”selector” — vanligen e-postadress, telefonnummer eller IP.

Den drabbade individen får inte veta att begäran skett. Anställda hos cloud-leverantören som hanterat begäran får inte heller berätta (gag order).

Scenario 3: ”National Security Letter” (NSL)

FBI kan utfärda NSL utan domstolskontroll, med inbyggt sekretessförbud. Mottagaren — typiskt en ISP eller cloud-leverantör — får varken bekräfta eller förneka att de fått en NSL. Det här är vad många refererar till som ”warrant canary”-mekanismens motpol.

Räcker SCC eller egen kryptering?

EU-kommissionen publicerade uppdaterade SCC (Standard Contractual Clauses) 2021 som inkluderar Schrems II-aspekter. De fungerar — men endast om mottagarlandets lagstiftning faktiskt erbjuder likvärdigt skydd. För USA är det inte fallet enligt EU-domstolen. EDPB (European Data Protection Board) har därför rekommenderat ytterligare tekniska åtgärder:

• Stark kryptering där nyckel hanteras i EU — bara om leverantören aldrig får tillgång till klartext
• Pseudonymisering före överföring — där återidentifiering kräver information som lagras i EU
• Splittrad lagring — där ingen single part har komplett dataset

Problemet: i många SaaS-tjänster (Office 365, Google Workspace, Salesforce) har leverantören tekniskt tillgång till klartext för att leverera funktioner som sök, ML, content-analys. Då fungerar inte E2E-kryptering som skyddsåtgärd.

Datainspektionen och Schrems II i Sverige

IMY (Integritetsskyddsmyndigheten, tidigare Datainspektionen) har varit relativt stillsam jämfört med franska CNIL och österrikiska DSB, men har:

• 2021 — varnat svenska skolor för Google Workspace för Utbildning (efter klagomål från flera kommuner)
• 2023 — granskat Microsoft Office 365-användning hos statliga myndigheter
• 2024 — utfärdat tillsynsbeslut mot flera svenska företag för otillräcklig SCC-implementering

EU-domstolen har i flera nyare mål (Bindl v Commission 2025) bekräftat att ”ytterligare åtgärder” är ett krav, inte en rekommendation, vid överföringar till USA.

Vad innebär det här för svenska företag?

Beroende på datatyp och regulatoriskt sammanhang:

För personuppgifter i offentlig sektor

Skolor, sjukvård, statliga myndigheter: amerikanska SaaS-tjänster för känslig data är högrisk. Flera svenska kommuner har migrerat bort från Google Workspace och Microsoft Office 365 för specifika dataset. Egna datacenter eller EU-baserade leverantörer utan US-modernbolag (t.ex. tyska Hetzner, svenska Adminor, franska OVH) är säkrare alternativ.

För B2B-företag

Risken är lägre men inte noll. Om er affärsdata innehåller personuppgifter (HR, kunder, leads), så är CLOUD Act-exponering en relevant fråga. Det gäller särskilt om ni har avtal med statliga kunder eller annan reglerad sektor — de kommer fråga.

För känslig affärsdata utan personuppgifter

Källkod, finansiell data, kunddatabaser, drug discovery, R&D, patent-relaterad data: GDPR gäller inte direkt, men FCPA, säkerhetsskydd, och industri-specifik reglering kan göra US-exponering problematisk.

Vad gör man konkret?

Tre nivåer av åtgärder:

Nivå 1: Inventering

Lista alla SaaS/cloud-tjänster ni använder och deras moderbolagsland. AWS, GCP, Azure, Salesforce, Slack, GitHub, Atlassian (Confluence/Jira), Zoom = alla US-baserade. Datadog, MongoDB Atlas, Snowflake = US. Office 365 = US.

Nivå 2: Riskbedömning per system

Inte alla data är lika känslig. För varje system: vilken datatyp, vilken regulatorisk klassning, vilka skyddsåtgärder redan på plats. Det styr om migration är nödvändig eller om SCC + extra åtgärder räcker.

Nivå 3: Migration för kritiska system

För regulatoriskt känsliga system — finansiell journaling, hälsodata, statliga uppdrag — flytta till en EU-leverantör utan US-modernbolag. Helsvensk drift (Adminor, GleSYS, Bahnhof, Glesys, Resilans) eller EU-baserad utan US-exponering (Hetzner, OVH, Scaleway).

Vanliga frågor

Räcker det att hosta i AWS Frankfurt istället för us-east-1?
Nej. Fysisk dataplats inom EU eliminerar dataöverföringsproblematiken (Schrems II) men inte CLOUD Act-exponeringen. AWS-Frankfurt-data omfattas fortfarande av amerikansk jurisdiktion via moderbolaget.

Är ”EU-only” sovereign cloud från Microsoft eller AWS lösningen?
Microsoft ”EU Data Boundary” och AWS European Sovereign Cloud (annonserad 2024) försöker hantera detta genom strikt EU-personal och separata juridiska entiteter. Inget av initiativen har än så länge bedömts som tillräckligt av EDPB, eftersom moderbolagsrelationen kvarstår.

Är svenska AWS-kunder olagliga?
Nej, inte automatiskt. Det handlar om risknivå och tillämpliga skyddsåtgärder per datatyp. Men IMY kan i vissa fall förbjuda specifika överföringar om SCC + extra åtgärder inte räcker.

Vad är skillnaden mellan Schrems II och GDPR i sig?
GDPR är grundförordningen som styr databehandling inom EU. Schrems II är ett rättsfall som tolkat hur GDPR ska tillämpas vid överföringar till tredjeland (specifikt USA). Schrems II tillför inga nya regler — det förtydligar att existerande regler är striktare än många antagit.

Hur är det med UK efter Brexit?
EU-kommissionen har 2021 utfärdat adekvansbeslut för UK (motsvarande tidigare Privacy Shield), men det är skört. Flera dataskydds­organisationer driver mål för att få det ogiltigförklarat på samma sätt som Privacy Shield. Risk-medveten praxis: behandla UK som lågre-risk-tredjeland snarare än EU.

Sammanfattning

Schrems II och CLOUD Act tillsammans innebär att amerikanska cloud-leverantörers EU-datacenter inte ger samma dataskydd som EU-baserade leverantörer utan US-moderbolag. Det är inte en teknisk fråga — det är en juridisk. Stark kryptering hjälper för storage, men SaaS-tjänster med funktionsberoenden mot klartext är problematiska.

För svenska företag som driftar känslig data — personuppgifter i offentlig sektor, finansiell data, säkerhetsklassad data — är moderbolagsjurisdiktion en separat faktor från fysisk lagringsplats. Helsvenska eller EU-baserade leverantörer utan US-exponering minskar riskprofilen utan att kräva ändringar i den underliggande tekniska arkitekturen.

Adminor är ett helägt svenskt aktiebolag utan utländsk moderbolagsjurisdiktion. Era servrar hos oss — VPS, colocation eller dedikerade — lyder enbart under svensk och EU-lag. Inga CLOUD Act-begäran kan riktas mot oss, eftersom vi inte är amerikansk jurisdiktionssubjekt. Mer information på Adminor VPS och colocation.

---

Frågor om Schrems II, GDPR-compliance eller datasuveränitet för er specifika situation? Kontakta Adminor — vi har drivit svensk IT-infrastruktur sedan 1983 och hanterar dataskydds-känsliga kunder från offentlig sektor och regulerade branscher.

TL;DR: RPKI är en signaturmekanism för BGP — själva protokollet som styr hur Internet-trafik hittar vägen mellan operatörer. Utan RPKI kan vem som helst annonsera era IP-adresser som sina egna och stjäla trafik. Med RPKI är det kryptografiskt verifierbart vem som äger vilka prefix. För svenska företag som driftar egen infrastruktur, hostar känslig data eller är beroende av nätverksupptid är RPKI-täckning idag en hygienfråga — inte ett tillval.

Det grundläggande problemet: BGP litar på rykte

BGP (Border Gateway Protocol) är det språk som alla världens internetoperatörer pratar med varandra på. När er trafik till adminor.net ska hitta vägen från Comhem hem-router till en server i Stockholm, så är det BGP-tabeller hos varje operatör som styr nästa hopp.

Problemet: i grundkonfigurationen finns ingen autentisering. Om en operatör i Pakistan eller Ryssland råkar (eller avsiktligt) annonsera ”jag äger 192.51.100.0/24”, och deras grannar accepterar det, så börjar trafik dit gå dit. Det kallas BGP hijack.

Det är inte teoretiskt. Klassiska incidenter:

• 2008 — Pakistan Telecom annonserade YouTubes IP-prefix för att blockera tjänsten inrikes. Annonsen läckte ut globalt → YouTube nere i två timmar världen över.
• 2018 — Amazon Route 53 hijackad i 2 timmar för att stjäla kryptovaluta. ~$150k flöt iväg.
• 2022 — Klayswap (sydkoreansk DEX) — BGP-hijack via KT Telekom, ~$1.9M i förluster.

Hijack-attacker kräver inget intrång hos er. Det räcker att någon på andra sidan jordklotet annonserar ert IP-utrymme — och era kunder hamnar hos dem.

RPKI: kryptografisk svar på frågan ”vem äger denna IP-adress?”

RPKI lägger ett signaturlager ovanpå BGP. Konceptuellt:

1. Resource certificate utfärdas av regionala internet-registry (RIPE NCC för Europa). Bevis att ni äger ett visst IP-prefix.
2. ROA — Route Origin Authorization — ni signerar ett uttalande: ”AS51701 får annonsera 192.51.100.0/24, ingen annan.”
3. Validerande router — operatörers BGP-routers slår upp varje inkommande annons mot ROA-databasen. Om annonsen inte matchar → den droppas eller nedprioriteras.

Resultat: om någon i Pakistan annonserar ert prefix utan att ha er signatur, så ignoreras annonsen av alla operatörer som validerar RPKI. Hijack-försöket stoppas innan det når svenska Internet.

Vem validerar RPKI i Sverige idag?

Det här är den bit många missar. Att publicera ROAs är värdelöst om ingen operatör validerar dem.

Svenska operatörer som hade RPKI-validering aktiv per 2024 (källa: NLnet Labs Routinator + MANRS):

• Telia (AS3301) — invalid-routes droppas
• Bahnhof (AS8473) — invalid-routes droppas
• GleSYS (AS42708) — validerar och droppar
• Resilans (AS25406) — validerar
• Netnod IX-route-servers — droppar invalid
• STHIX route-server — droppar invalid

Det innebär att om ert prefix har en korrekt ROA, så ignoreras hijack-försök automatiskt av de operatörer som hanterar majoriteten av svensk konsumenttrafik.

Vad behöver ett svenskt företag göra?

Det beror på hur ni hanterar IP-adresser:

Om ni använder leverantörens IP-adresser

Ni har inget eget IP-utrymme — ni hostar hos AWS, Azure, GleSYS, Bahnhof eller liknande. Då är RPKI leverantörens ansvar, inte ert. Men ni bör fråga: ”har ni ROA-täckning på era IP-prefix?” Om svaret är nej eller ”vad är det?” — det är en signal om driftmognad i övrigt.

Kontrollera er leverantör på RIPEstat → sök på prefix → fliken ”Routing” → ”RPKI Validity”.

Om ni har egna PI-prefix (Provider Independent)

Ni har eget IP-utrymme i RIPE-databasen, oftast med ett eget AS-nummer. Då är ROA ert ansvar och måste hanteras genom er Sponsoring LIR — den RIPE-medlem som administrerar ert PI-prefix.

Adminor är RIPE LIR och fungerar som Sponsoring LIR för flera svenska företag — vi hanterar ROA-publicering, LOA-utfärdanden och uppdateringar i RIPE Database när ni byter operatör. Vi signerar typiskt ROA inom 1 arbetsdag efter prefix-allokering.

Om ni har eget AS-nummer

Ni driver eget autonomt system. Då måste ni:

1. Publicera ROA för alla prefix ni annonserar
2. Köra en RPKI-validerande router (Routinator, FORT, rpki-prover)
3. Konfigurera BGP-policyn att droppa invalid

Det här är arbete för en nätverksingenjör, inte en webbutvecklare. Om ni inte har den kompetensen in-house — be er IP-leverantör om hjälp.

Vanliga frågor

Kostar RPKI något?
Nej, inte direkt. RIPE NCC tar inte separat avgift för ROA-publicering — det ingår i LIR-medlemskapet (~1 700 EUR/år). Som slutkund med PI-prefix kan ni ha en mindre årlig sponsorshipavgift.

Hur lång tid tar det innan ROA syns?
Ny ROA propagerar typiskt inom 30 minuter via RPKI-repository. Validering hos operatörer som hämtar var 10:e minut → max ~40 min innan skyddet är aktivt.

Vad händer vid felkonfigurerad ROA?
Det här är största risken. Om ni publicerar ROA som inte matchar er faktiska annonsering, så droppas er trafik av validerande operatörer. Ni ”RPKI-hijackar” er själva. Dubbelkolla MaxLength-värden och AS-nummer innan publicering.

RPKI vs BGPsec — är det samma sak?
Nej. RPKI signerar origin (vem som får annonsera). BGPsec signerar hela path (vilka mellanled trafik gick via). BGPsec finns men har minimal utbredning. RPKI är dagens standard.

Sammanfattning

RPKI är ett gratis, väletablerat skyddslager mot en specifik attack-klass — BGP hijack — som annars är osynlig för era egna säkerhetssystem. Det är inte ett kraftfullt verktyg, utan en hygienåtgärd som svenska operatörer (Telia, Bahnhof, GleSYS, STHIX-deltagarna) redan validerar mot. Om ni har eget IP-utrymme och inte har publicerat ROA, så är ni i 2026 i minoritet — och anledning till oro vid säkerhetsgranskningar.

Adminor publicerar ROA för alla kundprefix vi hanterar och fungerar som Sponsoring LIR för svenska företag som vill driva eget IP-utrymme utan att själva bli RIPE-medlemmar. Mer information på Adminor IP Registry.

---

Frågor om RPKI eller eget IP-utrymme? Kontakta Adminor — vi är RIPE LIR med AS51701 och hanterar IP-registry-frågor för flera svenska företag.