Sikker udstilling af data

Sikker udstilling af data Digitaliseringsstyrelsen 8. oktober 2012 Thomas Gundel

Agenda Baggrund hvorfor udstille data? OWSA Model T Identitetsbaserede Web Services NemLog-in s fuldmagtsløsning OAuth 2.0 Kontekstafhængige akkreditiver

Baggrund hvorfor udstille data? Flere og flere virksomheder udstiller data og services via API er. Antallet af API er vokser eksponentielt analytikere taler om Open API Economy som ny mega trend. Udviklingen drives af cloud computing, mobile computing og social computing. Citat fra Craig Burton (analytiker hos KuppingerCole): Baking your company s core competency into an open API is an economic imperative. If you are not engaged in generating or enabling open APIs you are not in the game. Sikkerhed og identitet er nødvendige forudsætninger.

API vækst

Milliardærklubben

Model 1: OWSA MODEL T

OWSA Model T Profil for punkt-til-punkt web services (SOAP) Udgivet i 2005 af IT-og Telestyrelsen Transportbaseret sikkerhed (SSL med OCES) Datatyper baseret på OIOXML

OWSA Model T

OWSA Model T -opsummering Hyppigt anvendt i legacy systemer Meget grovkornet adgangsstyring - typisk alt eller intet. Hvem sidder bag certifikatet og i hvilken sammenhæng foretages kaldet? Svært at dokumentere / auditere at adgange er korrekte. Forudsætter stor tillid til databehandlere. Ved personfølsomme data er det nødvendigt med støttende kontroller, eksempelvis aftaler, procedurer, logning, audits. Ingen signerede beviser at gemme for serviceudbyder. Certifikater besværlige at håndtere.

Model 2: IDENTITETSBASEREDE WEB SERVICES

Identitetsbaserede web services (OIO IDWS) Profiler af WS-Security og WS-Trust fra IT-og Telestyrelsen udgivet i 2009. Understøttes i den nye NemLog-in løsning, som er påvej. I SOAP kaldet medsendes et security token i form af en SAML Assertion. Kalderen signerer SOAP kaldet med digital signatur.

Overført identitet Log-in ID = System ID = System External service Log-in ID = System ID = External service

Scenarie 1: direkte føderering

Scenarie 2: Ekstern IdP / STS

OIO IDWS -opsummering Velegnet til SOAP API er, hvor der ønskes mere finkornede sikkerhedsmodeller. Autorisation kan baseres påattributter i SAML Assertion f.eks. roller, rettigheder mv. Token er digitalt signeret bevis, som kan gemmes. Nemmere at dokumentere compliance i forhold til persondatalov mv. Løst-koblet arkitektur hvor billetudstedelse (STS) er separat komponent. Muliggør mange forskellige trust-modeller.

Model 3: NEMLOG-IN S FULDMAGTSLØSNING

NemLog-in s fuldmagtsløsning Muliggør at en borger kan autorisere en repræsentant til at agere påsine vegne ved oprettelse af fuldmagt (borgerfokus). Relevant for web-applikationer / portaler. Repræsentantens fuldmagt udtrykkes som rettigheder i udstedt SAML Assertion.

Koncept for løsning Agerer på vegne af borger Repræsentant Myndighedsløsning Udveksler autorisation Borger Autoriserer repræsentant Supporter Løsning til partsrepræsentation

Partsrepræsentation via NemLog-in Repræsentant 3. Log-in NemLog-in 5. SAML billet med rettigheder 6. Adgangskontrol IT løsning 2. Autorisér repræsentant 4. Hent rettigheder 1. Definer rettigheder til administration Bruger NemLog-in Partsrepræsentation Administrator NemLog-in Myndighed

Fuldmagt -opsummering Relevant til personrettede grænseflader, når log-in sker via NemLog-in. Gør det let at håndtere fuldmagtsforhold med eksisterende infrastruktur (OIOSAML). Kun statiske rettigheder understøttet indtil videre. Brugeren er i kontrol.

Model 4: OAUTH 2.0

OAuth OAuth 2.0 er en protokol specificeret af Internet Engineering Task Force. Løser problemet med delegeret adgang til brugerressourcer uden at brugeren skal give sine credentials til tredjeparter. Lader brugeren delegere adgang til en App til sine data. Bruges af mange brugercentriske API er tjenester (Facebook, Twitter, Google )

Eksempel: adgang til Facebook profil

Autorisering i Facebook

OAuth flow

OAuth -opsummering Benyttes til at give adgang til en specifik brugers data (user-present scenarier). Velegnet til REST-baserede API er Mobile-friendly Bruger autoriserer alle adgange (samtykke), hvilket styrker privacy egenskaber. Klient lærer ikke brugerens credentials hos dataudbyder. Specificerer ikke autentifikationsformen (kan være SAML-baseret). Afkobling mellem brugerid hos klient og ressourceserver Meget let at implementere (JavaScript klient på under 1 sides kode) Revokering af tokens med lang levetid mere kompliceret Dataudbyder lærer (normalt) serviceudbyderens identitet at kende (mangler unlikability).

Model 5: KONTEKSTAFHÆNGIGE AKKREDITIVER

Kontekstafhængige akkreditiver IT-og Telestyrelsen udgav i 2011 et diskussionspapir om nye digitale sikkerhedsmodeller. Mange traditionelle sikkerhedsmodeller bygger grundlæggende påantagelsen om, at brugerne skal identificeres. Papiret præsenterer en ny måde at lave digitale sikkerhedsmodeller på, hvor det modsatte princip anvendes: brugeren har en vis grad af anonymitet eller pseudonymitet. Derved kan en række sikkerhedsudfordringer undgås.

Udfordringer med nuværende modeller Traditionelle akkreditiver giver sporing og mulighed for sammenkobling af brugerdata. Personhenførbarhed - også når det ikke er ønskeligt. Vanskeligt at lave tjenester, som kræver anonymitet. Identitetsudbydere bliver single point of failure. Persondata i cloud er en udfordring.

Målet med nye sikkerhedsmodeller Tilgodese hensynet til borgernes privatliv Tilgodese hensynet til applikationernes sikkerhed Gøre det muligt at flytte applikationer til cloud uden de traditionelle risici Gøre det billigere at passe pådata Begrænse single point of failures Muliggøre helt nye løsninger, hvor anonymitet / pseudonymitet er et grundlæggende krav.

Fiktivt eksempel: digital låneberegning SKAT Bank A Bank B Bank C Borger

Fiktivt eksempel: digital låneberegning SKAT Bank A Bank B Bank C 2. CPR 3. Data 1. Borger Traditionel løsning!

Fiktivt eksempel: digital låneberegning SKAT Bank A Bank B Bank C 2. Anonym skatteattest 1. 3. Anonym skatteattest Borger Alternativ løsning!

Virtuelle identiteter Bruger (fysisk person) Virtuelle identiteter Serviceudbydere

Anonym udstedelse ( untraceability ) Udsteder =? Bruger (indehaver)

Unlinkability Serviceudbyder 1 Serviceudbyder 2 =? Bruger (indehaver)

Selective Disclosure Kommune: Køn: Alder : >18 år

Opsummering En helt ny måde at tænke sikkerhedsmodeller på. Meget stærke privacy-egenskaber samtidig med stærke sikkerhedsegenskaber ( sikkerhed for alle ). Desværre endnu ikke at finde i kommercielle produkter (UProve, Identity Mixer). Muliggør helt nye typer anvendelser. Kan være katalysator for cloud computing. Kan lette compliance og gøre det billigere at beskytte data.

Spørgsmål

Referencer OWSA Model T http://www.digst.dk/da/arkitektur-og-standarder/itarkitektur/~/media/files/arkitektur%20og%20standarder/arkitektur/mod el_t_godkendt.ashx OIOIDWS: http://digitaliser.dk/resource/526486 OAuth 2.0: http://digitaliser.dk/resource/1246357 NemLog-in s fuldmagtsløsning: http://digitaliser.dk/fuldmagt Kontekstafhængige akkreditiver: http://digitaliser.dk/resource/781482