En af de mest forvirrende dele af Cyber Resilience Act for virksomheder med cloud-arkitektur handler om grænserne for ansvar og ejerskab i skyen, ikke om sikkerhedskrav. Det handler om det grundlæggende spørgsmål: Er din cloud-backend overhovedet en del af det produkt, som CRA regulerer?
Svaret er ikke så lige til, som man kunne ønske, og faktisk afhænger det af noget helt andet end, om du bruger cloud eller ej. Ja, nemt skal det jo ikke være, men hæng på, så skal vi nok sørge for, det giver mening til sidst.
CRA regulerer "produkter med digitale elementer" – hardware og software med netværksforbindelser. Men en ren webapplikation, som dine brugere udelukkende tilgår via en browser, er ifølge Kommissionens vejledning typisk ikke et produkt med digitale elementer.
Browseren er brugerens software, ikke din. Du leverer en tjeneste, ikke et installeret produkt – og det gør en afgørende forskel.
Mange SaaS-virksomheder, der driver alt i en browser, er ikke producenter i CRA's forstand og er dermed ikke underlagt de krav, der gælder for producenter.
Det er det gode nyt. Nu til det, du skal holde øje med.
Remote Data Processing Solutions (RDPS) er begrebet CRA bruger, når en cloud-backend er en integreret del af et produkt. Det afgørende er ikke, hvor din kode kører – det handler om, hvad den gør for produktet.
Kommissionens vejledning stiller tre spørgsmål, og det er kun, hvis du kan svare bekræftende på alle tre, at din cloud-backend kvalificerer som RDPS:
En mobilapp, der kalder din API for at hente realtidsdata. Firmware i en IoT-enhed, der kommunikerer med din cloud for at udføre en af sine funktioner - uanset om det er enhedens hovedformål eller en understøttende funktion. En installeret desktopapplikation, der synkroniserer med din backend. I alle disse tilfælde er din backend sandsynligvis RDPS – og en del af produktet i CRA's forstand.
Når du bruger cloud-infrastruktur fra en tredjepartsleverandør, er det afgørende at forstå, hvilken del du selv er ansvarlig for.
IaaS (Infrastructure as a Service): Du lejer virtuelle servere og netværk. Din software, der kører på den infrastruktur, er dit ansvar – og kvalificerer sig som RDPS, hvis betingelserne er opfyldt. Hypervisor-laget og den underliggende infrastruktur er leverandørens komponent, ikke din.
PaaS (Platform as a Service): Du deployer din applikationskode på en managed platform. Din kode er stadig dit RDPS. Selve platform-runtime er leverandørens komponent.
SaaS (Software as a Service): Du bruger en tredjeparts-applikation. Den er en ekstern komponent, og altså ikke din RDPS. Men den er heller ikke usynlig i dit compliance-billede (mere om det nedenfor).
Tænk på det på den her måde: Det, du har designet og bygget, er dit. Det, du har købt og integreret, er en komponent.
Det er da ok-simpelt, ikk’?
Måske lander din arkitektur et sted, hvor din cloud-backend er en tredjepartskomponent – noget, du er afhængig af, men ikke selv har bygget. Det fritar dig ikke for alle forpligtelser. CRA kræver, at du vurderer, hvad der sker for dit produkts sikkerhed, hvis komponenten fejler eller kompromitteres.
Du skal kunne dokumentere, at du har undersøgt leverandørens sikkerhed. Og du skal implementere sikkerhedsforanstaltninger i dit eget produkt – autentificering, integritetskontrol, isolation – der reducerer risikoen ved afhængigheden.
Det er langt fra fuld RDPS-compliance, men det er heller ikke ingenting. Og det er et område, mange virksomheder undervurderer.
For at gøre principperne omkring cloud og CRA konkrete, får du herunder tre typiske arkitekturer og den RDPS-vurdering, de hver især lander på.
Scenario A – Ren SaaS via browser: Din virksomhed leverer et projekt-styringsværktøj, som brugerne tilgår via Chrome. Alt kører i din cloud. Der er ingen installeret klient. → Sandsynligvis ikke et produkt med digitale elementer. Ikke RDPS. CRA's producent-krav gælder typisk ikke.
Scenario B – Mobilapp med cloud-backend: Du har en app i App Store, der bruger din API til at hente realtidsdata og udføre beregninger. Uden API'en virker appen ikke. → Appen er produktet. Din API er RDPS. Begge dele er inden for CRA's scope.
Scenario C – IoT-enhed med cloud-styring: Du sælger en smart sensor, der sender data til din cloud for analyse og sender kommandoer tilbage. Enheden kan ikke fungere selvstændigt. → Enheden er produktet med digitale elementer. Cloud-backenden er RDPS. Fuld producent-compliance gælder.
Er du producent med RDPS, gælder de samme grundlæggende krav som for al anden software under CRA. Sikkerhed skal tænkes ind fra start, hvilket betyder, at vulnerability management, adgangskontrol, kryptering og minimal angrebsflade ikke er tilvalg, men designprincipper.
Du skal dokumentere din sikkerhedsarkitektur og kunne rapportere aktivt udnyttede sårbarheder til relevante myndigheder inden for 24 timer. Og du skal yde support i hele produktets levetid – eller tydeligt angive, hvornår den ophører.
Kravene gælder for produktet som helhed, herunder din RDPS-backend.
Spørgsmålene om RDPS-scope, tredjepartskomponenter og dokumentationskrav kan virke abstrakte, indtil de rammer din konkrete arkitektur. Dine næste skridt handler om at tage det, du har læst her, og anvende det i praksis.
Første skridt: Kortlæg din arkitektur. Identificér alle cloud-komponenter og stil de tre spørgsmål for hver enkelt: Sker behandlingen eksternt? Er produktet funktionelt afhængigt? Har du designet og bygget det?
Andet skridt: Afgræns dit scope. Skil RDPS fra tredjepartskomponenter. Det skel bestemmer, hvilke krav du selv skal leve op til, og hvilke der kræver due diligence på dine leverandører.
Tredje skridt: Byg dokumentationen op nu. CRA's krav til sikkerhedsdokumentation er ikke noget, du laver dagen inden deadline. Start med den tekniske dokumentation af din arkitektur og dine sikkerhedsbeslutninger.
Afgrænsningen af cloud i CRA er sjældent sort-hvidt i praksis – de fleste arkitekturer indeholder elementer, der trækker i forskellige retninger.
Er du usikker på, hvor din arkitektur lander, er du ikke alene. NorthGRC har mere end 20 års rådgivningserfaring, og vi kan hjælpe dig med at kortlægge dit RDPS-scope og opbygge den nødvendige compliance-dokumentation.