Nederst foto på forsiden: Publikationen kan hentes på IT- & Telestyrelsens Hjemmeside: ISBN (internet):

Størrelse: px
Starte visningen fra side:

Download "Nederst foto på forsiden: Publikationen kan hentes på IT- & Telestyrelsens Hjemmeside: ISBN (internet):"

Transkript

1

2 > Identitetsbaserede web services og personlige data Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade København Ø Nederst foto på forsiden: Publikationen kan hentes på IT- & Telestyrelsens Hjemmeside: ISBN (internet): Telefon: Fax:

3 > Identitetsbaserede web services og personlige data Version 1.1 IT- & Telestyrelsen marts 2010

4 Indhold [ Indledning 5 Målgruppe 5 Afgrænsning 6 Definitioner og begreber 7 Scenarier 9 Scenarie med browser og ekstern logintjeneste 9 Scenarie med rig klient og lokal STS 11 Sikkerhedsmæssige og juridiske egenskaber 13 Profiler i OIOIDWS 16 Kontrol af aktiv brugersession 18 Juridiske forhold 19 Regulering 19 Persondataloven 19 Bevismæssige forhold 25 Ansvar 25 Referencer 27

5 Indledning > Identitetsbaserede web services er en særlig slags web services, der kaldes samt opererer på vegne af en bruger. Som eksempler kan nævnes en brugers kalenderservice, der gør det muligt at booke en aftale med brugeren, eller en service, der eksponerer en borgers skatteoplysninger til brug i offentlige myndigheders selvbetjeningsløsninger. OIO identitetsbaserede web services (herefter OIOIDWS) er et sæt af web service profiler udviklet af IT- og Telestyrelsen, der er målrettet den offentlige sektor. OIOIDWS gør det bl.a. muligt at udbyde services, som eksponerer personlige data fra offentlige registre på en sikker og standardiseret måde, hvilket er nødvendigt for digitalisering af en række tværgående sagsgange. Et eksempel på en proces, der kræver indhentning af data fra flere myndigheder, er ansøgning om vognmandstilladelse hos Færdselsstyrelsen. Her skal borgeren uden digitalisering igennem en langsommelig, papirbaseret proces med at indhente oplysninger fra SKAT, Politiet, Motorkontoret, Erhvervs- og Selskabsstyrelsen mv. hvorefter disse indsendes til Færdselsstyrelsen, hvor sagsgangen primært består i at kontrollere oplysningerne fra de andre myndigheder, inden tilladelsen kan udstedes. Er der fejl eller mangler i de indsendte formularer, må sagsbehandlingen midlertidigt afbrydes, og borgeren må forsøge igen. Hvis borgerens data kunne indhentes automatisk via services hos de relevante myndighederne, ville det medføre store gevinster både for borgeren og myndighederne. En forudsætning for, at data kan deles er naturligvis, at det juridiske, tekniske og sikkerhedsmæssige grundlag er i orden. OIOIDWS giver et højt niveau af sikkerhed for både borgere og myndigheder i forhold til mere traditionelle integrationsformer. Eksempelvis kan en service kun kaldes, når borgeren er logget ind hos den applikation, der anmoder om data. Dette giver borgerne en høj grad af tryghed for, at udleveringen af data kun sker, når de har tilgået en selvbetjeningsløsning, der har brug for data. Endvidere giver det den dataansvarlige/udleverende myndighed en tryghed for, at data kun frigives til applikationer, som rent faktisk er i gang med at betjene den pågældende borger. Med OIO identitetsbaserede webservices bliver det således muligt at lette administration, når myndigheder skal sende/videregive oplysninger om en borger. Arbejdsgange, der tidligere har været udført ved anvendelse af blanketter, kan gøres elektroniske og give en stor administrativ lettelse. OIOIDWS er et teknisk fundament baseret på interoperable profiler af internationale, åbne standarder. Konceptet og arkitekturen kan realiseres med gængse udviklingsværktøjer og platforme, og der er vide muligheder for tilpasning af konceptet og arkitekturen til den konkrete situation. Målgruppe Dette dokument er henvendt til offentlige myndigheder, der ønsker at anvende identitetsbaserede web services baseret på OIOIDWS profilerne til at udveksle data. Dokumentet kan læses af beslutningstagere, projektledere og IT arkitekter med interesse for digitalisering. Der berøres således både forretningsmæssige, juridiske og tekniske problemstillinger i relation til deling af data. Dokumentet er introducerende, 5

6 og der henvises til de underliggende profildokumenter for tekniske detaljer for detaljer om juridiske forhold i forhold til persondataloven henvises til Afgrænsning Dette dokument tager afsæt i en situation, hvor en myndighed videregiver data til en anden myndighed på vegne af en borger. Det juridiske fokus retter sig imod selve videregivelsen af data fra en myndighed til en anden. Vejledningen omhandler ikke digital signering af dokumenter og aftalers bindende virkning. Ved benyttelsen af OIOIDWS forudsættes endvidere, at der ikke sker sammenkøring af data. I stedet anvendes konceptet til at fremsende oplysninger i konkrete tilfælde fra en myndighed til en anden. Vejledningen er ikke en gennemgang af de i persondataloven gældende behandlingsprincipper i den enkelte myndigheds systemer. Der er således stillet skarpt på det scenarie, som retter sig imod anvendelse af OIOIDWS. I forhold til videregivelsen vil der blive set på tilfælde, der omfatter fortrolige og følsomme persondata. Videregivelse af almindelige personoplysninger vil ikke blive særskilt behandlet, da reglerne vil kunne opfyldes af samme sikkerhedsniveau som for fortrolige oplysninger. 6

7 Definitioner og begreber > Videregivende myndighed Betegnelsen er valgt ud fra persondatalovens begreber (også kendt som personoplysningsloven). Det er den myndighed, der har ansvar og råderet over data, og som giver data til en tredjepart til deres selvstændige brug. Den videregivende myndighed er dataansvarlig. Modtagende myndighed Den myndighed, som modtager data. I denne vejledning modtages data til myndighedens eget selvstændige brug, og den modtagende myndighed er derfor også dataansvarlig efter persondatalovens regler. Den registrerede Term i persondataloven som henviser til den, der er registreret personoplysninger om. I forhold til de her opstillede scenarier vil den registrerede være den enkelte borger. Databehandling I persondatalovens forstand er en behandling læsning, registreringen, opbevaring, brug, videregivelse og sletning af data. Dermed omfattes al anvendelse af data. Web Service Provider (WSP) Dette er den tekniske komponent hos den videregivende myndighed, som udstiller data via web services. Web Service Consumer (WSC) Dette er den tekniske komponent (typisk en del af en applikation) hos den modtagende myndighed, som henter data via kald til web services. Applikation Applikationen stiller funktionalitet til rådighed for brugeren, som kan anvendes efter login. Applikationen har brug for at kalde en identitetsbaseret web service hos en fremmed myndighed på vegne af brugeren eksempelvis med det formål at hente data om brugeren. Typiske eksempler på applikationer er web applikationer / portaler, som tilgås via en browser, eller tykke klienter, der er installeret på brugerens PC. Bruger Brugeren er en fysisk person (f.eks. borger eller sagsbehandler), som anvender en applikation. Brugeren har akkreditiver i form af eksempelvis en digital signatur, som anvendes til at logge på applikationen. Når borgeren, som bruger, tilgår egne data betragtes myndigheden som databehandler, og der er her ikke en videregivelse af data, da det er borgeren selv, som styrer dette (som egen access). Dette scenarie falder udenfor vejledningen. Udtrykkeligt samtykke Med udtrykkeligt samtykke menes en frivillig, specifik og informeret viljestilkendegivelse, hvor borgeren indvilger i behandling af egne oplysninger. Der gælder ikke noget formkrav til samtykket, men bevisbyrden påhviler den dataansvarlige og det anbefales, at samtykke afgives skriftligt, evt. via de muligheder den elektroniske løsning giver herfor. 7

8 Samtykket skal være konkretiseret så det klart og utvetydigt fremgår, hvad det er, der meddeles samtykke til, herunder, hvilke typer af oplysninger, der må behandles, hvem der kan foretage behandling af oplysningerne og til hvilke formål. Figur 1: De vigtigste elementer i OIOIDWS Logintjeneste (Identity Provider) Dette er en ekstern tjeneste, som forestår autentificering af brugeren for applikationer. Et eksempel er NemLog-in. Security Token Service (STS) En Security Token Service er en tjeneste, der kontaktes af applikationer for at få udstedt adgangsbilletter (security tokens) til brug for kald til eksterne web services. Et security token identificerer brugeren, hvilken applikation der må anvende tokenet, samt hvilken service, det er udstedt til. 8

9 Scenarier > I dette kapitel beskrives en række scenarier, der illustrerer brugen af OIOIDWS konceptet. Scenarierne er valgt, så de viser typiske brugsmønstre i den offentlige sektor indenfor digital forvaltning. Beskrivelsen er overordnet, og der henvises til OIOIDWS profilerne for tekniske detaljer. Scenarie med browser og ekstern logintjeneste Nedenstående figur viser et scenarie med en borger, der anvender en browser mod en web-baseret selvbetjeningsapplikation (eller portal) hos en offentlig myndighed. Borgeren autentificerer sig med en digital signatur via en ekstern logintjeneste (som f.eks. NemLog-in). Applikationen får brug for at hente data om borgeren hos en fremmed myndighed via en identitetsbaseret web service, og anvender herefter disse data til betjeningen af borgeren et eksempel kunne være indhentning af oplysninger som anvendes til behandling af en ansøgning fra borgeren. Til det formål kontakter applikationen en STS for at få udstedt en adgangsbillet (security token) til servicen. Trinene i scenariet er som følger: 1. Borgeren tilgår en selvbetjeningsapplikation via sin browser. 2. Applikationen kræver autentifikation af borgeren og videresender derfor browseren til en ekstern logintjeneste (f.eks. NemLog-in). 3. Logintjenesten autentificerer borgeren via dennes digitale signatur 1 og udsteder herefter en SAML assertion, der identificerer borgeren overfor applikationen. Den udstedte SAML assertion indeholder endvidere et såkaldt bootstrap token, der kan anvendes i det videre forløb (se næste trin). 4. Applikationen får på et senere tidspunkt brug for at kalde en fremmed identitetsbaseret web service på vegne af borgeren f.eks. med det formål at hente dennes personlige data. Applikationen anmoder derfor en såkaldt Security Token Service (STS) om at få udstedt en adgangsbillet (security token) til den fremmede web service. Applikationen angiver hvilken web service, der ønskes kaldt, og medsender borgerens bootstrap token for at indikere, hvem kaldet skal ske på vegne af. 5. STS en validerer requestet samt bootstrap tokenet og foretager evt. en autorisationsbeslutning samt evt. et opkald til logintjenesten for at sikre, at brugeren stadig har en aktiv session. Hvis alt går godt udstedes og returneres et nyt token til applikationen, der kan anvendes mod den ønskede web service. 6. Applikationen kalder den fremmede identitetsbaserede web service på vegne af borgeren; kaldet signeres og tokenet udstedt af STS en medsendes. 7. Web servicen validerer tokenet og udfører servicekaldet på vegne af borgeren. Svaret signeres inden det returneres. 8. Applikationen anvender data i svaret fra serviceudbyderen i det videre forløb. 1 Hvis borgeren allerede har en session med logintjenesten overspringes autentifikationen og der kan udstedes en SAML assertion direkte (dvs. brugeren oplever single sign-on). 9

10 Figur 2: Scenarie med browserklient Forudsætningerne for ovenstående scenarie er bl.a.: Borgeren er i besiddelse af akkreditiver (f.eks. en OCES digital signatur), hvormed han kan autentificere sig overfor logintjenesten (Identity Provider). Logintjenesten udsteder en SAML assertion indeholdende et bootstrap token, som STS en kan forstå. Web applikationen er i besiddelse af en digital signatur (f.eks. OCES virksomhedssignatur), hvormed den kan autentificere sig overfor STS og WSP. STS en er i besiddelse af en digital signatur hvormed den kan signere tokens. Serviceudbyderen (WSP) er i besiddelse af en digital signatur, hvormed svar kan signeres. Applikation (WSC) og Serviceudbyder (WSP) stoler begge på STS en og kan validere de tokens, den udsteder. Det er ikke en forudsætning, at applikation (WSC) og serviceudbyder (WSP) stoler på hinanden og kender hinandens certifikater på forhånd. 10

11 > Scenarie med rig klient og lokal STS I det næste scenarie er brugeren en sagsbehandler i en offentlig myndighed, der fra en desktop applikation installeret på hans computer har brug for at tilgå data i en anden offentlig myndighed. Brugeren logger på applikationen via netværkslogin på hans arbejdsplads, og en Security Token Service internt hos myndigheden udsteder et security token, der indeholder information om de roller, brugeren er tildelt. Med dette token kan en applikation tilgå den eksterne web service. Figur 3: Scenarie med rig klient Trinene i scenariet er som følger: 1. Brugeren logger på det lokale netværk / directory (f.eks. Active Directory) hos myndigheden, når arbejdsdagen begynder. 2. Brugeren starter en klientapplikation på sin PC. 3. Klientapplikationen logger automatisk brugeren på (single sign-on). 4. Klientapplikationen har brug for at kalde en identitetsbaseret web service hos en anden myndighed og anmoder derfor STS en om et security token. 5. STS en slår op i directory et og undersøger hvilke roller/rettigheder/grupper, brugeren er associeret med. STS en foretager evt. en oversættelse af disse roller i forhold de applikationsroller, som den aktuelle web service forventer. 6. Applikationen foretager kaldet til den ønskede service og medsender det udstedte token. Web servicen validerer tokenet og udfører servicekaldet med de roller/rettigheder, der fremgår af tokenet. Svaret signeres inden det returneres. Applikationen anvender data i svaret fra serviceudbyderen i det videre forløb. Forudsætningerne for ovenstående scenarie er bl.a.: Brugeren er i besiddelse af akkreditiver (f.eks. brugerid/password eller OCES medarbejdersignatur), hvormed han kan autentificere sig på det lokale netværk. 11

12 12 Applikationen er i besiddelse af en digital signatur (f.eks. OCES virksomhedscertifikat eller funktionscertifikat), hvormed den kan autentificere sig overfor web servicen. STS en er i besiddelse af en digital signatur, hvormed den kan signere tokens. Serviceudbyderen (WSP) er i besiddelse af en digital signatur, hvormed svar kan signeres. Serviceudbyderen stoler på myndighedens STS herunder at de medsendte roller er korrekte i forhold til sagsbehandlerens arbejdsfunktion, og at sagsbehandleren er blevet korrekt autentificeret på det lokale netværk. STS en har viden om hvilke applikationsroller, web servicen forventer at modtage, og kan evt. oversætte interne brugerroller fra directory et til disse. Brugeren er tildelt brugerroller i directory et f.eks. af myndighedens brugeradministratorer.

13 Sikkerhedsmæssige og juridiske egenskaber > I dette kapitel beskrives en række sikkerhedsmæssige egenskaber, der opnås ved at anvende OIOIDWS - herunder en række af de fordele IDWS giver sammenlignet med mere traditionelle integrationsformer. Egenskaberne sættes i relation til relevante juridiske forhold ved dataudveksling. Egenskab 1: Den kaldende applikation er autentificeret, og integriteten af kaldet er sikret Den myndighed, der henter data, skal signere web service kaldet med et certifikat. Anvendes OCES virksomhedscertifikater eller -funktionscertifikater opnår den videregivende myndighed en høj grad af sikkerhed for, hvem den kaldende myndighed er. Desuden sikrer den digitale signatur, at kaldet ikke kan modificeres dvs. integriteten er sikret. Juridisk har dette betydning for, at myndigheden der videregiver data kan stole på, at data sendes frem til den rigtige myndighed. Dermed giver konceptet den videregivende myndighed sikkerhed for, at data kan afsendes til modtager myndigheden. Egenskab 2: En betroet tredjepart står inde for, at brugeren er logget på Brugerens identitet fremgår af et såkaldt sikkerhedstoken, der er udstedt af en betroet tredjepart, og som medsendes i web service kaldet. Dette token kan kun udstedes såfremt borgeren, som bruger, er logget på, og da det er signeret med en betroet tredjeparts signatur, kan det ikke forfalskes eller modificeres. I brugerens token findes en attribut (assurancelevel), der fortæller hvor sikkert brugeren loggede på Identity Provideren. Værdien er et tal i intervallet 1-4, hvor den nuværende OCES signatur indplaceres på niveau 3; se mere i [AUTH-LEV]. På den måde kan myndigheden, der videregiver data, vurdere hvor stærkt brugeren er autentificeret, og lade dette indgå i beslutningen om, hvorvidt data frigives. Juridisk giver denne egenskab sikkerhed for, at borgeren, som er den registrerede efter persondataloven, er korrekt identificeret og at myndigheden har ret til at tilgå den service, som kaldes på vegne af borgeren. Der gøres opmærksom på, at de videregivende myndigheder altid bør overveje nøje, hvilke services de vil lade modtagende myndigheder tilgå. Desuden bør det overvejes, hvordan det styres, at sagsbehandleren hos modtagende myndighed kun kan tilgå de sager, som er af arbejdsmæssig relevans. Denne egenskab kan fremgå af det udstedte token (via et såkaldt claim), således at den modtagende myndighed (via sin STS) overfor den videregivende myndighed står inde for, at sagsbehandleren er tilknyttet den pågældende sag. Egenskab 3: Data er krypterede under transport OIOIDWS anvender sikre transportkanaler (SSL / TLS) med stærk kryptering, så data kan ikke aflyttes af uvedkommende under transport. Dermed opnås konfidentialitet af kommunikationen. Da både SSL og TLS protokollerne kan anvendes med forskellige krypteringsalgoritmer, hashalgoritmer og forskellige nøglelængder, er det vigtigt, at man ikke anvender svage algoritmer eller nøgler. Dette opnås konkret ved at 13

14 konfigurere web servere til at kun at anvende stærk kryptering med anerkendte algoritmer (eksempelvis AES med 128 bit nøgler eller bedre). Når der anvendes stærk kryptering, som bygger på anerkendte algoritmer, opfyldes persondatalovens krav til kryptering af data, der sendes over Internet, og dette er tilstrækkeligt til både fortrolige og følsomme personoplysninger. Egenskab 4: OIOIDWS Tokens sikrer at adgang gives begrænset Et token udstedt af en betroet tredjepart er indrettet, så det kun kan anvendes i et kort tidsrum af den applikation, det er udstedt til 2, og kun til den service, det er beregnet til. Der kan implementeres en adgangspolitik, der begrænser hvem der kan få tokens til hvilke services. Persondataloven stiller krav om, at kun de data, som er nødvendige, behandles. OIOIDWS kan hjælpe med at begrænse adgangen til data på serviceniveau. Det betyder, at den videregivende myndighed kan definere, hvilke services den modtagende myndighed kan tilgå og derved undgå, at der gives adgang til andre services, som kan indeholde oplysninger om borgeren (den registrerede), som den modtagende myndighed ikke har behov for. Egenskab 5: Web servicen er autentificeret og integriteten af svaret er sikret Svaret fra web servicen hos den videregivende myndighed er signeret med et certifikat. Anvendes OCES virksomhedscertifikater eller -funktionscertifikater opnås en høj grad af sikkerhed for, hvem den videregivende myndighed er, herunder at de sendte data er korrekte. Endvidere betyder signaturen, at svaret ikke kan modificeres, hvilket sikrer integriteten. Egenskab 6: Kald til web service kan logges som bevis Web servicen kan logge kald til den som et kryptografisk sikret bevis på, at den har udleveret data (og hvilke) på baggrund af en legitim anmodning fra en fremmed myndighed; for detaljer om signaturbeviser henvises til [SIG-BEV]. Det er muligt for de dataansvarlige myndigheder at opsætte logning på deres webservices. Behandles fortrolige eller følsomme personoplysninger, stilles der i sikkerhedsbekendtgørelsen krav om, at tilgang og behandling af personoplysningerne logges. Behovet for logning af kald til webservicen bør vurderes op imod den logning, som myndigheden i øvrigt foretager og det it-sikkerhedsniveau, som løsningen skal imødekomme. I forbindelse med logning er det vigtigt at huske, at logningen i sig selv er en behandling af persondata, hvor det skal overvejes hvilke oplysninger der er nødvendige og logge. Egenskab 7: Svar fra web service kan logges som bevis Applikationen kan logge svaret fra web servicen som et kryptografisk sikret bevis på, hvilke data den modtog dette kan eksempelvis være relevant, når afgørelser træffes 2 Tokenet er bundet til applikationens signatur via holder-of-key mekanismen i SAML. 14

15 > på baggrund af data modtaget fra fremmede myndigheder; for detaljer om signaturbeviser henvises til [SIG-BEV]. Det er muligt for de dataansvarlige myndigheder at opsætte logning på deres web services. Behandles fortrolige eller følsomme personoplysninger, stilles der i sikkerhedsbekendtgørelsen krav om, at tilgang og behandling af personoplysningerne logges. Behovet for logning af svaret fra webservicen bør vurderes op imod den logning, som myndigheden i øvrigt foretager og det it-sikkerhedsniveau, som løsningen skal imødekomme. I forbindelse med logning er det vigtigt at huske, at logningen i sig selv er en behandling af persondata, hvor det skal overvejes hvilke oplysninger der er nødvendige og logge. Egenskab 8: Samtykke fra borger Når der er behov for udtrykkeligt samtykke fra borgeren (som den registrerede) til at videregive data, er det muligt at benytte protokollen Request to interact, som er beskrevet i OIOIDWS. I praksis betyder dette, at den videregivende myndighed beder den kaldende applikation om at sende brugerens browser over til en bestemt adresse, hvor et samtykke fra borgeren kan indhentes, inden web service kaldet udføres, og data frigives til applikationen. Efter indhentet samtykke sender den videregivende myndighed browseren tilbage til applikationen. Ved udveksling af følsomme personoplysninger uden direkte lovhjemmel, skal udtrykkeligt samtykke indhentes. I request to interact protokollen sker dette ved, at borgeren sendes hen til den videregivende myndigheds applikation, hvor samtykke til at netop de udbedte oplysninger gives. OIOIDWS giver altså en teknisk viderestillingsmekanisme, men det er op til myndigheden selv at udforme, indhente og lagre samtykker, så det giver mening i den konkrete sammenhæng. Rent praktisk kan man overveje at give den registrerede en mulighed for at underskrive den udtrykkelige samtykkeerklæring med sin digitale signatur. I den forbindelse er det vigtigt at kommunikere tydeligt, hvilke data, samtykket giver ret til videregivelse af. Egenskab 9: Det er muligt at sætte et sikkerhedsniveau, der matcher det konkrete behov Flere elementer i arkitekturen er åbne og kan indstilles efter det konkrete behov. Det gælder f.eks. timeout perioder, tilladte akkreditiver, adgangspolitikker, granularitet af adgange, certifikatpolitikker mv. Med udgangspunkt i den konkrete situation defineres de acceptable værdier, som er afstemt med det ønskede sikkerhedsniveau alt efter den konkrete anvendelse, herunder om der udveksles almindelige, fortrolige eller følsomme personoplysninger, se definitionen herfor under afsnittet Juridiske forhold. Det er op til den enkelte myndighed at definere et niveau, som passer med de personoplysninger der udveksles, og så det hele tiden følger den praksis, der er for sikkerhedsopsætninger. Kravene til sikkerhed kan udvikle sig over tid, og af denne grund er persondatalovens krav beskrevet teknik-neutralt. Den sikkerhed, som vil give tilstrækkelig beskyttelse af oplysningerne afhænger af, hvad der til enhver tid kan anses for god it-sikkerhed set i forhold til, hvor følsomme oplysninger der udveksles. 15

16 Profiler i OIOIDWS OIOIDWS består af en række profiler af en række internationale standarder bl.a. fra OASIS og Liberty Alliance. Nedenfor findes en oversigt over disse profiler, og deres roller forklares. Der henvises til profildokumenterne for tekniske detaljer. Profil Liberty Basic SOAP Binding [LIB-BAS] Anvendelse Denne profil af standarden Liberty ID WSF 2.0 SOAP Binding beskriver hvad et web service kald fra en Web Service Consumer til Web Service Provider skal indeholde samt regler for behandling. Profilen detaljerer udseendet af SOAP meddelelsen med særlig vægt på SOAP headere, foreskriver transportniveau, kryptering, signering af meddelelsen og medsendelse af security tokens. OIO WS-Trust Profile [OIO-WST] OIO WS-Trust Deployment Profile [OIO-WST-DEP] OIO Identity Token Profile [OIO-IDT] OIO Bootstrap Token Profile [OIO-BOOT] OIOSAML Web SSO Profile [OIO-SAML-SSO] Profilen kan udvides med Request to Interact protokollen fra den overliggende Liberty standard, som gør det muligt for web servicen at bede applikationen om at sende brugerens browser til en specifik URL hvor brugerens samtykke til frigivelse af data så kan indhentes. Denne profil af OASIS WS-Trust 1.3 standarden beskriver hvorledes en applikation kan anmode om at få udstedt et security token med henblik på et efterfølgende web service kald for en bruger. Profilen beskriver alene beskedformatet for de meddelelser, der udveksles (ligesom WS-Trust standarden). Denne profil specificerer en række tekniske detaljer i forbindelse med deployment af OIO WS-Trust profilen i en dansk kontekst. Bl.a. beskrives en konkret binding til SOAP via Liberty Basic SOAP Binding, der refereres til danske profiler vedr. indhold af tokens samt brug af danske attributter defineret i OIOSAML, og endelig anbefales brug af OCES certifikater. Denne profil beskriver indholdet af de security tokens (i form af SAML 2.0 assertions) som udstedes af en STS til brug for et efterfølgende servicekald. Denne profil beskriver en særlig attribut, der kan indlejres i en SAML assertion opnået via en browser fra en Identity Provider (se næste profil). Attributten rummer et såkaldt bootstrap token, der kan anvendes til at identificere brugeren overfor en STS, når der anmodes om et security token. Boostrap tokenet udtrækkes konkret af applikationen og anvendes i WS-Trust kaldet mod STS en. Denne profil af SAML 2.0 standarden beskriver web SSO scenariet, hvor brugeren via sin browser logger på en applikation (Service Provider) ved brug af en logintjeneste (Identity Provider) udbudt af en tredjepart (f.eks. NemLog- 16

17 > in). Profilen beskriver bl.a. hvorledes en række danske attributter, som befindes sig i brugerens OCES certifikat, kan repræsenteres i den udstedte SAML assertion. 17

18 Kontrol af aktiv brugersession I dette kapitel dykkes ned i en af de tekniske detaljer omkring udstedelsen af security tokens fra STS en i OIOIDWS, der har betydning for sikkerhed og arkitektur. Ideelt set skal en STS kun udstede et security token til en kaldende applikation, hvis brugeren er logget ind hos den applikation, der anmoder om tokenet, og hos den Identity Provider, der gav adgang til applikationen. Derfor vil det være optimalt, hvis STS en kan kalde Identity Provideren og forespørge, om brugeren (stadig) har en aktiv session. Imidlertid er der ikke nogen standardiseret protokol til dette, og kontrollen kan derfor ikke realiseres uden mere eller mindre proprietære integrationer mellem STS og IdP. Det overlades derfor til de enkelte dataansvarlige myndigheder at foretage en risikovurdering som afdækker, hvorvidt der er behov for real-time information om brugerens session. På den måde kan integrationen udelades, når den ikke er absolut nødvendig. Endvidere opfordres fællesoffentlige Identity Providere til at udbyde en grænseflade, hvormed STS er kan forespørge om sessionsstatus for en bruger. I nogle sammenhænge stilles en Identity Provider og en STS op ved siden af hinanden i samme organisation (f.eks. som to dele af et fælles softwareprodukt), og i den forbindelse kan det være lettere at foretage integrationen. Her anvendes betegnelsen at IdP og STS er ko-lokerede. I tilfælde hvor STS en ikke har adgang til at forespørge Identity Provideren om brugerens aktuelle sessionsstatus, må der tages en beslutning om hvorvidt tokenet kan udstedes ud fra informationerne i bootstrap tokenet. Her vil være angivet et tidspunkt for, hvornår brugeren loggede på Identity Provideren samt hvornår brugeren fik udstedt den SAML assertion, som gav adgang til applikationen Med disse informationer kan STS en definere en timeoutpolitik, der begrænser hvor længe efter disse tidspunkter applikationen kan hente security tokens og dermed tilgå services på brugerens vegne. I princippet kunne brugeren jo have logget ud på Identity Provideren efter at have tilgået applikationen. Jo kortere denne timeout periode sættes, jo tættere mindre bliver vinduet, hvor services kan kaldes uden sikkerhed, for at brugeren ikke har logget ud. Omvendt vil en for kort periode medføre byrder for applikationen om hyppigt at forny (web SSO) tokens hos Identity Provideren (og dermed forny bootstrap tokens). Det overlades til de enkelte myndigheder at definere en passende timeout periode, som afvejer følsomheden af konkrete data mod byrderne ved hyppige fornyelser af tokens. 18

19 Juridiske forhold > Regulering Den regulering, der er i forhold til selve persondataloven er relevant for videregivelsen af borgerens data, er listet i nedenstående tabel. Listen har til formål og give et overblik over de krav som stilles i persondataloven og som uddybes i underliggende retskilder og standarder. På specialområder er der ofte særregler for persondatabeskyttelse, og de skal naturligvis overholdes på de enkelte områder. Når disse giver bedre beskyttelse end persondataloven, er det specialreglerne der skal følges. Det er vigtigt, at der inddrages jurister i de enkelte projekter, da retsområdet er komplekst. Dette afsnit repræsenterer udelukkende et kortfattet og generelt overblik. Den tungeste kilde er loven, som gælder for alle myndigheder og private virksomheder. Den næste kilde, der er angivet, er sikkerhedsbekendtgørelsen, som er direkte gældende for den offentlige forvaltning, og som uddyber sikkerhedskravene i persondataloven. De efterfølgende kilder er vejledninger og standarder for sikkerhed, der har vejledende karakter og er med til at fastsætte god praksis for behandling af personoplysninger. Regulering og standarder Persondatalov: Lov om behandling af personoplysninger Nr. 429 af 31/ Sikkerhedsbekendtgørelsen Nr. 528 af 15/ Vejledning til bekendtgørelse nr. 528 af 15. juni 2000 Datatilsynets afgørelser og publikationer DS484:2005 ISO/IEC CD under udarbejdelse Hvornår Når der udveksles persondata. Der er forskellige krav til behandlingen alt efter om det drejer sig om eksempelvis et navn eller om det er udveksling af eksempelvis straffeattest eller sygdomsoplysninger. Forkortes som PDL og omtales persondataloven. Når der udveksles persondata indenfor det offentlige. Bekendtgørelsen uddyber tekniske og administrative krav til persondataloven. Vejledning omkring sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning. Datatilsynet har tilsynet med Persondataloven. Derfor skal den praksis og de udtalelser, som Datatilsynet fremkommer med tages med, når kravene i persondataloven skal overholdes. Se mere på: It-sikkerhedsstandard, som efter statslig beslutning skal følges indenfor staten. Her omhandler afsnit 15 privacy og er relevant i forhold til de identitetsbaserede webservices Information technology -- Security techniques -- A privacy framework. Standarden er under udarbejdelse, men er relevant I forhold til dens indgangsvinkel på identity management. Persondataloven Der stilles krav til, hvordan personoplysninger behandles, og groft opdelt kan det siges, at der arbejdes indenfor følgende 4 hovedområder: Administrative/organisatoriske krav til behandlingssikkerhed. Den registreredes rettigheder. 19

20 Anmeldelse til Datatilsynet. Teknisk sikkerhed. Kravene retter sig imod al behandling af data, fordi en databehandling i persondatalovens forstand vedrører al brug af data. Det betyder, at læsning, registreringen, opbevaring, brug, videregivelse og sletning alt sammen er databehandlinger. Ingen behandlinger går derfor fri, men kravene til procedurer og sikkerhed bliver større eller mindre alt efter datas klassifikation, dvs. alt efter om data er almindelige, fortrolige eller følsomme. Internettet er et åbent netværk, og det er hverken sikkert eller lovligt i forhold til persondataloven at sende fortrolige eller følsomme personoplysninger uden ekstra sikkerhedsforanstaltninger over Internet. OIOIDWS kan give den tekniske sikkerhed, når myndighed skal sende oplysninger sikkert over Internet. Den enkelte myndighed skal dog stadig sikre, at anvendelse af personoplysningerne internt i myndigheden opfylder persondatalovens ikke tekniske krav. I det følgende fokuseres på de krav i persondataloven og sikkerhedsbekendtgørelsen, som retter sig specifikt mod de scenarier, som OIOIDWS understøtter, nemlig videregivelse af oplysninger fra en myndighed til en anden via web services over internettet. Omdrejningspunktet vil være it-sikkerheden og dermed persondatalovens 41, stk. 3 som lyder: Stk. 3. Den dataansvarlige skal træffe de fornødne tekniske og organisatoriske sikkerhedsforanstaltninger mod, at oplysninger hændeligt eller ulovligt tilintetgøres, fortabes eller forringes, samt mod, at de kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med loven. Tilsvarende gælder for databehandlere. Kravene til sikkerheden skærpes alt efter datas klassifikation, og generelt kan data i forhold til persondataloven klassificeres i følgende 3 kategorier: Følsom Almindelig -Fortrolig Almindelig ikke fortrolig PDL 7 PDL 8 PDL 11 PDL 6 PDL 6 Racemæssig / etnisk baggrund, politisk, religiøs, eller filosofisk overbevisning, fagforeningsforhold, seksuelle forhold, helbredsmæssige forhold. Eksempel hvis der er angivet registreret partnerskab. Strafbare forhold, væsentlige sociale problemer, andre rent private forhold. Eksempel herpå er selvmordsforsøg, bortvisning fra job. CPR-nummer. Private oplysninger om eks. økonomi, hemmelig adresse, skatteforhold, gæld, sygedage, tjenestelige forhold og familieforhold Bolig, bil, eksamen, ansøgning, ansættelsesdato, stilling, arbejdsområde, arbejdstelefon, stamoplysninger. Eksempler er Navn, adresse og fødselsdato. 20

21 > Klassificeringen af oplysningerne er ikke et lovkrav men et nyttigt praktisk redskab, når man skal lave en risikovurdering der klarlægger, hvor høj et niveau af it-sikkerhed, der er nødvendigt. Når myndigheden skal klassificere personoplysningerne, vil der altid være tale om en konkret vurdering, som det påhviler den dataansvarlige myndighed at foretage. For eksempel vil oplysninger om en borgers adresse kunne være en fortrolig oplysning, hvis borgeren har navne- og adressebeskyttelse efter CPR-loven. Et CV kan indeholde fortrolige eller følsomme oplysninger om f.eks. den registreredes karakterer eller personnummer eller andet. Det er derfor vigtig at tage aktivt stilling til de oplysninger myndigheden behandler og kun anvende nedenstående skema som hjælp til klassificeringen. Når data er blevet inddelt i en af de 3 kategorier følsom, almindelig-fortrolig og almindelig ikke fortrolig - kan man ud fra klassifikationen se, hvilken tyngde der skal ligge på it-sikkerheden og kontrollerne med behandlingen af data. Kravene, der skal opfyldes er styret af, hvorvidt det er anmeldelsespligtigt at behandle disse, se mere herom på Helt overordnet kan følgende generelle tommelfingerregler opstilles for de enkelte klassifikationer: Der er et generelt forbud mod at dele data medmindre der er lovhjemmel eller udtrykkeligt samtykke fra borger. Med udtrykkeligt menes, at samtykkes skal gives af en borger, der er tydeligt oplyst om data der skal behandles, formål hvem der kan behandle og anvendelse. Desuden bør det udtrykkelige samtykke være givet skriftligt, så der ingen tvivl er om omfanget og det efterfølgende kan dokumenteres. Der stilles store krav til såvel administrativ som teknisk sikkerhed. Der skal ske anmeldelse til Datatilsynet og borgerens ret til eksempelvis at se og rette data skal sikres. Generelle krav Følsom Almindelig fortrolig Almindelig ikke fortrolig Der stilles krav til sikkerheden såvel teknisk som administrativt. Ikke alle behandlinger af fortrolige data skal anmeldes til Datatilsynet, men forholdet skal undersøges. Borgerens ret til eksempelvis at se og rette data skal sikres. Der stilles ikke så store sikkerhedskrav til almindelige persondata, men husk, at kun nødvendige oplysninger må behandles. Behandlingen er omfattet af persondataloven. Behandlingen skal generelt ikke anmeldes til Datatilsynet. Borgerens ret til eksempelvis at se og rette data skal sikres. For at stille skarpt på de forhold, der er væsentlige når internettet anvendes til at videregive data, er kravene uddybet i listen nedenfor, der tager udgangspunkt i persondatalovens behandlingsregler i kapitel 4 samt det generelle sikkerhedskrav i persondatalovens 41. Listen fokuserer særligt på de krav som OIOIDWS løsningen kan hjælpe med at opfylde. Gennemgangen er således ikke en fuldstændig liste over krav til sikkerheden og behandlingen af personoplysninger, det anbefales derfor at der inddrages juridisk assistance tidligt i projektforløbet, for at få opstillet de konkrete krav den enkelte 21

22 myndighed i det enkelte tilfælde skal overholde. OIOIDWS kan således bidrage med tekniske egenskaber, der hjælper med overholdelsen af personoplysningsloven, men det er den enkelte myndigheds ansvar at sikre, at opsætning sker korrekt og at behandlingen af personoplysningerne også sikres igennem organisatoriske tiltag. Krav der vedrører den enkelte myndigheds interne administration af data såsom relevans og saglighedskriterier efter PDL 5 medtages overordnet, borgerens rettigheder såsom indsigelse og indsigt, og den enkelte myndigheds anmeldelse til Datatilsynet er ikke medtaget, da det ikke har sammenhæng med anvendelsen af OIOIDWS til videregivelse af data. I kolonnen til højre kommenteres kravet i forhold til OIOIDWS. Krav A. Behandlingshjemmel PDL 5 Databehandling og videregivelse er lovlig (PDL 5, 6,7,8 og 11) Retsinformationssystemer PDL 9 OIOIDWS PDL 5 kræver overholdelse af god databehandlingsskik. De principper der ligger bag og som videregivende og modtagende myndighed skal have i mente er: *Et sagligt formål med behandlingen *Kun relevante og proportionale data behandles * Data opdateres *Data opbevares kun så længe det er nødvendigt, derefter skal ske anonymisering/arkivering/sletning. I øvrigt henvises til Datatilsynets praksis herom. Videregivende myndighed skal sikre hjemmel til videregivelsen ved udtrykkeligt samtykke fra borgeren eller ved tilladelse i lov. For følsomme og fortrolige data, der videregives på baggrund af udtrykkeligt samtykke, skal det være, så vidt muligt specificeres, hvilke oplysninger der videregives, hvem data videregives til. Kravene til uafviselighed vil være mest tungtvejende ved følsomme data. Bevisbyrden for samtykket påhviler den dataansvarlige. Følsomme personoplysninger kan behandles, hvis dette sker med henblik på at føre retsinformationssystemer af væsentlig samfundsmæssig betydning. 22

23 > Krav Statistiske og videnskabelige undersøgelser PDL 10 Adresserings- og kuverteringsbureauer 12 Registrering af telefonnumre PDL 13 Arkivering PDL 14 Data behandles sikkert PDL 41, stk. 3 Logning af adgang og behandling af fortrolige personoplysninger (sikkerhedsbekendtgørelsen 15, 18 og 19) OIOIDWS Dette vil navnlig være systemer, som er til rådighed for en bredere kreds af abonnenter for at sikre en ensartet retsanvendelse. Det kan blandt andet være en myndigheds offentliggørelse af afgørelser på myndighedens hjemmeside eller i Retsinformation eller offentliggørelse af domme i et tidsskrift. Behandlingen skal samtidig være nødvendig for førelsen af systemerne. Bestemmelsen giver en udvidet mulighed for at behandle følsomme personoplysninger, hvis dette sker til statistiske eller videnskabelige formål af samfundsmæssig betydning. Ikke relevant i forhold til IOIIDWS løsningen, da denne vedrører offentlige myndigheder. Adresserings- og kuverteringsbureauer er særligt reguleret i bestemmelsen, som nævnes for at medtage hele kap 4 i persondataloven Ikke relevant i forhold til OIOIDWS løsningen, men nævnes for at medtage hele kap 4 i persondataloven. Bestemmelsen giver hjemmel til at overføre data til arkivering. OIOIDWS krypterer data ved afsendelsen og sikrer, at afsenderen kan have tillid til modtagermyndighedens og borgerens identitet. Niveauet af sikkerhed kan justeres i konceptet alt efter hvordan opsætning sker af eksempelvis timeout, adgangspolitiker, certifikatpolitiker mv. Pligten til logning af adgang og behandling af personoplysninger omfatter de oplysninger der er omfattet af anmeldelsespligten til Datatilsynet groft sagt fortrolige oplysninger. Se evt. nærmere om anmeldelsespligten i Datatilsynets vejledning nr. 125 af 10. juli Servicekald kan logges ved brug af IDWS konceptet. Det er den enkelte dataansvarlige myndighed der skal sikre, at egne webservices sættes op, så den nødvendige logning af tilgang og brug af fortrolige og følsomme 23

24 Krav Tildelte adgange er i overensstemmelse med arbejdsmæssigt betingede behov. (sikkerhedsbekendtgørelsen 12 og 16 autorisation og adgangskontrol). Tildelte brugeradgange revurderes halvårligt (sikkerhedsbekendtgørelsen 17) Procedure for sikring af eksterne kommunikationslinier er udarbejdet og kryptering (Sikkerhedsbekendtgørelsen 14) Medarbejdere instrueres om hvorledes behandling af data skal ske.(pdl 41, stk. 1) B. Den registreredes rettigheder Den dataansvarliges har opfyldt sin oplysningspligt. OIOIDWS personoplysninger foretages. Der skal som minimum sikres logning af: *Tidspunkt (kan kræve synkronisering af ure på tværs af systemer). *Bruger (den ID som logges, skal kunne hæftes på en person, og må dermed ikke være en "anonym" token). *Anvendelse. *Angivelse af den person, de anvendte oplysninger vedrørte, eller det anvendte søgekriterium. *Afviste adgangsforsøg desuden skal der ske blokering ved gentagne afviste forsøg Hver myndighed skal sikre, at de medarbejdere, der tilgår data, er autoriserede til det. OIOIDWS giver mulighed for at tilknytte roller til medarbejderne, så det sikres, at de må bruge systemet herunder er autoriserede til kald af web services i fremmede myndigheder. Det er ikke muligt at automatisere det organisatoriske krav, som altid vil gælde uanset hvilken teknisk løsning der vælges. Hver myndighed skal følge op på medarbejdernes autorisationer. OIOIDWS profilerne foreskriver stærk kryptering. OIOIDWS sørger for at der er vejledninger tilgængelige, men hver myndighed har pligten til at instruere egne medarbejdere. I scenariet bestiller borgeren videregivelsen af oplysningerne, og der gives et SAML token med som dokumentation for at borgeren bestiller data til en bestemt modtager myndighed. Det er dog vigtig at være sikker på, at borgeren ved hvilke data, der indsamles hos den modtagende myndighed. 24

25 > Krav OIOIDWS Modtager og afsender myndighed kan aftale, hvem der sikrer, at borgeren modtager oplysninger omkring, hvilke data der er videresendt til hvilken myndighed, og hvem der er ansvarlig i forhold til rettigheder omkring indsigelse, berigtigelse og indsigt. Bevismæssige forhold Bevismæssige forhold er væsentlige at have for øje, når en sagsgang omlægges fra papir til et digitalt medie. Det er også tilfældet ved benyttelsen af OIOIDWS. I scenariet er der en myndighed, der videregiver (afsender) data, og en som modtager. Logningen af tilgang og brugen af data er en vigtig del af dokumentationen for det sagsforløb, myndigheden har ansvaret for. Det gælder for den myndighed, der afsender data helt frem til det tidspunkt, hvor data videregives, og for den modtagende myndighed fra det tidspunkt, hvor data modtages. I forhold til den enkelte borger, som er den registrerede efter persondataloven, er det væsentlige at have for øje, at det udtrykkelige samtykke, som borgeren afgiver, efterfølgende skal kunne bevises. For nærmere information henvises i øvrigt til IT- og Telestyrelsens udgivelse Signatur- og systembevis - Teknisk vejledning i sikring af digitale signaturers bevisværdi. [SIG-BEV]. Ansvar Såvel videregivende som modtagende myndighed har ansvar og opgaver, når persondataloven skal overholdes. Ses der på ansvaret i forhold til den afgivende myndighed, som er dataansvarlig for de oplysninger, der videregives, så er det den videregivende myndighed som skal sikre, at der er hjemmel i lov eller via borgerens udtrykkelige samtykke til at videregive oplysningerne. Da modtagermyndigheden generelt skal anvende data til egne selvstændige formål, vil modtagermyndigheden efter modtagelse af oplysningerne være ansvarlig for den fremadrettede behandling af data. Formålet med denne anvendelse af OIOIDWS er derfor ikke, at den ene myndighed skal være databehandler på vegne af den anden. Derimod skal data til den videregives til den modtagende myndigheds eget brug. Det ansvar, som i forbindelse med videregivelsen af data påhviler den videregivende myndighed, er blandt andet, at: 25

26 Sikre klassifikation af data dvs. om det er almindelige, fortrolige eller følsomme persondata. Sikre hjemmel til videregivelsen eksempelvis i forbindelse med udtrykkeligt samtykke fra borgeren eller ved tilladelse i lov. Sikre at videregivelsen sker til den rigtige myndighed - dette understøtter OIOIDWS. Sikre at medarbejdere er korrekt autoriserede til at anvende OIOIDWS konceptet. OIOIDWS konceptet understøtter dette med mulighed for rolletildeling. Sikre at modtageren er den rigtige. OIOIDWS konceptet sørger for anvendelse af certifikater, så dette understøttes. Sikre at der er historik i forhold til adgangen af data dvs. den enkelte myndighed skal sikre opsætning af logning. Sikre at borgeren er orienteret om videregivelse af data, når der er pligt til det. Sikre at data er korrekte. Det ansvar, som påhviler den dataansvarlige myndighed som modtager data, er blandt andet, at: Oplyse borgeren om hvilke data, der er behov for at indsamle. Sikre at medarbejdere er korrekt autoriserede til at anvende data. OIOIDWS understøtter dette med mulighed for rolletildeling. Sikre at der er historik i forhold til adgangen af data dvs. den enkelte myndighed skal sikre opsætning af logning. 26

27 Referencer > [DTT] [OIO-WST] [OIO- WSTDEP] [OIO-IDT] [OIO-BOOT] [OIO-SAML- SSO] [LIB-BAS] [LIB-SOAP] [WST] [SIG-BEV] [SSL] [TLS] [OCES-CP] [AUTH-LEV] OIO WS-Trust Profile V1.0, Danish IT and Telecom Agency. OIO WS-Trust Deployment Profile V1.0, Danish IT and Telecom Agency. OIO SAML Profile for Identity Tokens, V1.0, Danish IT and Telecom Agency. OIO Bootstrap Token Profile V1.0, Danish IT and Telecom Agency. OIO Web SSO Profile V2.0, Danish IT and Telecom Agency. Liberty Basic SOAP Binding Profile, version 1.0, Liberty Alliance Project. Liberty IDWF 2.0 SOAP Binding, Liberty Alliance Project. WS-Trust 1.3, OASIS Standard. Signatur- og Systembevis teknisk vejledning i sikring af digitale signaturers bevisværdi, IT- og Telestyrelsen. SSL 3.0 Specification : The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force. https://www.signatursekretariatet.dk/certifikatpolitikker.html Vejledning vedrørende niveauer af autenticitetssikring. 27

28

29

Identitetsbaserede webservices og personlige data

Identitetsbaserede webservices og personlige data > Identitetsbaserede webservices og personlige data Version 0.8 IT- & Telestyrelsen juni 2009 Indhold > Indledning 3 Målgruppe 3 Afgrænsning 4 Definitioner og begreber 5 Scenarier 7 Scenarie med browser

Læs mere

Certifikatpolitik. For den fællesoffentlige log-in-løsning. Side 1 af 9 2. december Version 1.1

Certifikatpolitik. For den fællesoffentlige log-in-løsning. Side 1 af 9 2. december Version 1.1 Side 1 af 9 2. december 2009 Certifikatpolitik For den fællesoffentlige log-in-løsning Version 1.1 Dette dokument beskriver certifikatpolitikken for den fællesoffentlige log-inløsning. Politikken definerer

Læs mere

Sikker udstilling af data

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

Læs mere

Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/) Creative Commons NY-NC (http://creativecommons.org/licenses/bync/2.0/deed.

Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/) Creative Commons NY-NC (http://creativecommons.org/licenses/bync/2.0/deed. Sikkerhedsmodeller for OIOREST Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø Telefon: 3545 0000 Fax: 3545 0010 Nederst foto på forsiden: B Tal (http://flickr.com/photos/b-tal/)

Læs mere

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring

Version 1.0. Vilkår for brug af Støttesystemet Adgangsstyring Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT

Læs mere

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0.

Autencitetssikring. Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning. Side 1 af 12 19. september 2008. Version 1.0. Side 1 af 12 19. september 2008 Autencitetssikring Vejledning til autenticitetssikringsniveau for den fællesoffentlige log-in-løsning Version 1.0. Denne vejledning introducerer problemstillingen omkring

Læs mere

Forsikring & Pension Philip Heymans Allé 1 2900 Hellerup

Forsikring & Pension Philip Heymans Allé 1 2900 Hellerup Forsikring & Pension Philip Heymans Allé 1 2900 Hellerup 14. maj 2012 Orientering om nye regler om private dataansvarliges anmeldelsespligt Datatilsynet Borgergade 28, 5. 1300 København K CVR-nr. 11-88-37-29

Læs mere

Timeout-politik for den fællesoffentlige føderation

Timeout-politik for den fællesoffentlige føderation Side 1 af 8 7. november 2012 Timeout-politik for den fællesoffentlige føderation Dette dokument beskriver en politik for timeout af brugersessioner i den fællesoffentlige føderation, der er obligatorisk

Læs mere

Persondataloven og sundhedsvidenskabelige forskningsprojekter

Persondataloven og sundhedsvidenskabelige forskningsprojekter Persondataloven og sundhedsvidenskabelige forskningsprojekter Fuldmægtig Signe Astrid Bruun Fuldmægtig Martin Nybye-Petersen Datatilsynet 9. januar 2014 Dagens Program Datatilsynets struktur og arbejdsopgaver

Læs mere

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22.

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED OG VERSIONERING AF WEBSERVICES VERSION: 1.7.0 STATUS: FRIGIVET DATO: 22. AUGUST 2013 Fil: DIADEM - Kom godt igang - Ver 1.7.0.docx Indhold 1.

Læs mere

Certifikatpolitik for NemLog-in

Certifikatpolitik for NemLog-in Side 1 af 9 7. november 2012 Certifikatpolitik for NemLog-in Version 1.2 Dette dokument beskriver certifikatpolitikken for NemLog-in løsningen. Politikken definerer hvilke typer certifikater, der må anvendes

Læs mere

OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen -

OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen - OISAML Workshop Århus 31. marts 2009 Kontor for It-infrastruktur og implementering IT og Telestyrelsen IT Arkitekt Søren Peter Nielsen - spn@itst.dk Velkommen! Dette er en WORKSHOP Ikke et fintunet kursus!!

Læs mere

Digital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet

Digital Sundhed. Brugerstyringsattributter - Introduktion. - Specificering af nye og ændrede attributter i id-kortet Digital Sundhed Brugerstyringsattributter - Introduktion - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Læsevejledning... 2 3. Aktører... 2 4. Autentifikation...

Læs mere

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

Vejledning VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL. Februar 2015 (VERSION 1.4 AF FEBRUAR 2015)

Vejledning VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL. Februar 2015 (VERSION 1.4 AF FEBRUAR 2015) Vejledning Februar 2015 VEDRØRENDE GENERELLE BETINGELSER FOR ANVENDELSE AF NEMHANDEL (VERSION 1.4 AF FEBRUAR 2015) Side 2 af 12 Indholdsfortegnelse: Indholdsfortegnelse:... 2 INDLEDNING... 4 GENERELLE

Læs mere

Teknisk Dokumentation

Teknisk Dokumentation Sundhedsstyrelsens E2B Bivirkningswebservice Teknisk Dokumentation Side 1 af 8 Indhold Indledning... 3 Terminologi... 3 Arkitektur... 4 Web Service Snitflade... 4 Valideringsfejl... 5 Success... 5 E2B...

Læs mere

[Fremsendes af Rigspolitiet sammen med fremsendelse af børneattester.]

[Fremsendes af Rigspolitiet sammen med fremsendelse af børneattester.] !"#!"$! % &&&$!"$! [Fremsendes af Rigspolitiet sammen med fremsendelse af børneattester.] Du har fra Rigspolitiet modtaget en blank børneattest, dvs. en attest, hvoraf det fremgår, at den person, oplysningerne

Læs mere

DanID A/S Lautrupbjerg 10 Postboks 500 2750 Ballerup

DanID A/S Lautrupbjerg 10 Postboks 500 2750 Ballerup DanID A/S Lautrupbjerg 10 Postboks 500 2750 Ballerup 24. september 2010 Vedrørende sikkerhedsforanstaltningerne omkring udstedelse af NemID Datatilsynet Borgergade 28, 5. 1300 København K CVR-nr. 11-88-37-29

Læs mere

Tilladelsen gives på følgende vilkår:

Tilladelsen gives på følgende vilkår: Amgros I/S Dampfærgevej 22 2100 København Ø Sendt til: amgros@amgros.dk og cch@amgros.dk 6. april 2016 Vedrørende anmeldelse af behandlingen "Behandling af ESPD dokumentation" Datatilsynet Borgergade 28,

Læs mere

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm

Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Tilstrækkelig sikker dataudveksling via Sundhedsdatanettet (SDN) Ved Kåre Kjelstrøm Sundhedsdatanettets Anatomi UNI-C Router Organisation A Router Router Organisation B Firewall Firewall Linjesikkerhed

Læs mere

hos statslige myndigheder

hos statslige myndigheder IT-Universitetet i København Rued Langgaards Vej 7 2300 København S Sendt til: itu@itu.dk 25. juni 2015 Udtalelse til anmeldelsen Videnskabelige og statistiske undersøgelser hos statslige myndigheder Datatilsynet

Læs mere

AFTALE OM DATASIKKERHED I FORBINDELSE MED GODKENDELSE AF PRIVATE LEVERANDØRER UNDER FRIT VALGS-ORDNINGEN

AFTALE OM DATASIKKERHED I FORBINDELSE MED GODKENDELSE AF PRIVATE LEVERANDØRER UNDER FRIT VALGS-ORDNINGEN AFTALE OM DATASIKKERHED I FORBINDELSE MED GODKENDELSE AF PRIVATE LEVERANDØRER UNDER FRIT VALGS-ORDNINGEN Mellem Norddjurs Kommune Torvet 3 8500 Grenaa (i det følgende benævnt Dataansvarlige ) og Leverandør

Læs mere

Databehandleraftale. om [Indsæt navn på aftale]

Databehandleraftale. om [Indsæt navn på aftale] Databehandleraftale om [Indsæt navn på aftale] Jf. bestemmelserne i lov nr. 429 af 31. maj 2000 om behandling af personoplysninger med senere ændringer (Persondataloven) mellem Vesthimmerlands Kommune

Læs mere

Retsudvalget 2013-14 REU Alm.del Bilag 364 Offentligt

Retsudvalget 2013-14 REU Alm.del Bilag 364 Offentligt Retsudvalget 2013-14 REU Alm.del Bilag 364 Offentligt Folketinget Udvalgssekretariatet Christiansborg 1240 København K Sendt til: Birgitte.Toft-Petersen@ft.dk 29. august 2014 Vedrørende høring over beretning

Læs mere

It-sikkerhedstekst ST2

It-sikkerhedstekst ST2 It-sikkerhedstekst ST2 Overvejelser om sikring mod, at personoplysninger kommer til uvedkommendes kendskab i forbindelse med Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST2 Version

Læs mere

BILAG 5 DATABEHANDLERAFTALE

BILAG 5 DATABEHANDLERAFTALE BILAG 5 DATABEHANDLERAFTALE INDHOLDSFORTEGNELSE 1. Formål og omfang... 5 2. Databehandlers opgave... 5 3. Instruks... 5 4. Brug af ekstern Databehandler eller underleverandør... 5 5. Behandling i udlandet...

Læs mere

Rammer og vilkår for brug af data. 25. oktober 2016 Afdelingschef Birgitte Drewes,

Rammer og vilkår for brug af data. 25. oktober 2016 Afdelingschef Birgitte Drewes, Rammer og vilkår for brug af data 25. oktober 2016 Afdelingschef Birgitte Drewes, bidr@sundhedsdata.dk Lovgivning - sundhedsdata Sundhedsloven Persondataloven I sundhedsloven fastlægges reglerne for indhentning/videregivelse

Læs mere

Valg af webservice standard

Valg af webservice standard Valg af webservice standard Agenda Valg til en serviceorienteret infrastruktur Identitetsbaserede Services, Kåre Kjelstrøm Teknologiske trends og udfordringer Debat, spørgsmål og kritik Skal du lave en

Læs mere

Guide til kravspecifikation

Guide til kravspecifikation Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten

Læs mere

Databehandlerinstruks

Databehandlerinstruks 1. Databehandleren handler alene efter instruks af den dataansvarlige. 2. Databehandleren forpligter sig til, til enhver tid at overholde lovgivningsmæssige krav samt denne databehandlerinstruks. 3. Databehandleren

Læs mere

AFTALE OM BEHANDLING AF PERSONOPLYSNINGER. Mellem. [X] [Adresse] [Postnr. + By] CVR. nr.: [xxxxxxxx] (herefter Leverandøren )

AFTALE OM BEHANDLING AF PERSONOPLYSNINGER. Mellem. [X] [Adresse] [Postnr. + By] CVR. nr.: [xxxxxxxx] (herefter Leverandøren ) AFTALE OM BEHANDLING AF PERSONOPLYSNINGER Mellem [X] [Adresse] [Postnr. + By] CVR. nr.: [xxxxxxxx] (herefter Leverandøren ) og Midttrafik Søren Nymarks Vej 3 8270 Højbjerg CVR-nr.: 29943176 (herefter Midttrafik

Læs mere

Dette dokument beskriver den fællesoffentlige føderations minimumskrav til logning hos Service og Identity Providere.

Dette dokument beskriver den fællesoffentlige føderations minimumskrav til logning hos Service og Identity Providere. Side 1 af 17 19. september 2008 Logningspolitik For den fællesoffentlige log-in-løsning Version 1.0. Dette dokument beskriver den fællesoffentlige føderations minimumskrav til logning hos Service og Identity

Læs mere

Uddrag af Persondatalovens bestemmelser angående tv-overvågning (pr. 1. juli 2007)

Uddrag af Persondatalovens bestemmelser angående tv-overvågning (pr. 1. juli 2007) Side 1 af 8 Uddrag af Persondatalovens bestemmelser angående tv-overvågning (pr. 1. juli 2007) Kapitel 1 Lovens område 1. Stk. 7. Loven gælder for enhver form for behandling af personoplysninger i forbindelse

Læs mere

Udkast til Bekendtgørelse om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning i Grønland

Udkast til Bekendtgørelse om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning i Grønland Lovafdelingen Dato: Kontor: Databeskyttelseskontoret Sagsbeh: André Dybdal Pape/ Marcus Nymand Sagsnr.: 2016-766-0019 Dok.: 2104838 Udkast til Bekendtgørelse om sikkerhedsforanstaltninger til beskyttelse

Læs mere

Eksempel på KOMBITs instruks til ISAE 3000 revisionserklæring

Eksempel på KOMBITs instruks til ISAE 3000 revisionserklæring Eksempel på KOMBITs instruks til ISAE 3000 revisionserklæring KOMBIT har som indkøbscentral på vegne af landets kommuner indgået aftale med [leverandørnavn] (herefter Leverandøren ) om udvikling, drift,

Læs mere

Vilkår vedrørende brug af Støttesystemet Adgangsstyring

Vilkår vedrørende brug af Støttesystemet Adgangsstyring Vilkår vedrørende brug af Støttesystemet Adgangsstyring 1. Indledning Nærværende vejledning beskriver, hvordan it-systemer skal anvender Adgangsstyring i rammearkitekturen såvel dynamisk som i den daglige

Læs mere

Databehandleraftale. Der er indgået denne Databehandlingsaftale ("Aftale") mellem

Databehandleraftale. Der er indgået denne Databehandlingsaftale (Aftale) mellem Oktober 2014 Sagsnr. 013928-0190 cen/dla Databehandleraftale Der er indgået denne Databehandlingsaftale ("Aftale") mellem Fredericia Kommune Gothersgade 20 7000 Frdericia CVR-nr.: 69116418 ("Kommunen")

Læs mere

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED VERSION: 1.3 (INGEN ÆNDRINGER SIDEN 1.1) STATUS: FRIGIVET DATO: 1.

DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED VERSION: 1.3 (INGEN ÆNDRINGER SIDEN 1.1) STATUS: FRIGIVET DATO: 1. DIADEM KOM GODT I GANG INTEGRATIONSVEJLEDNING IFT. SIKKERHED VERSION: 1.3 (INGEN ÆNDRINGER SIDEN 1.1) STATUS: FRIGIVET DATO: 1. OKTOBER 2012 Fil: DIADEM - Kom godt igang - Ver 1.3.docx Indhold 1. INDLEDNING...

Læs mere

Sikkerhedsregler for Kalundborg Kommune

Sikkerhedsregler for Kalundborg Kommune Bilag 19 Sikkerhedsregler for Kalundborg Kommune Sikkerhedsregler for Kalundborg Kommune i henhold til Justitsministeriets bekendtgørelse nr. 528 af den 15. juni 2000 om sikkerhedsforanstaltninger til

Læs mere

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler Blankettype: Privat virksomhed Datatilsynet Borgergade 28 1300 København K Anmeldelse af behandlinger af oplysninger om rent private forhold der foreta- ges for en privat dataansvarlig. Felter markeret

Læs mere

Rammeaftalebilag 5 - Databehandleraftale

Rammeaftalebilag 5 - Databehandleraftale Rammeaftalebilag 5 - Databehandleraftale Denne databehandleraftale (Aftale) er indgået mellem Norddjurs Kommune Torvet 3 8500 Grenaa (Kommunen) Dataansvarlig og Leverandør Adresse Postnummer CVR nr.: (Leverandøren)

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

Databehandleraftale vedrørende brug af. WinPLC og relaterede services. Version 1.0 d. 1. november Parterne. Kundenr.:

Databehandleraftale vedrørende brug af. WinPLC og relaterede services. Version 1.0 d. 1. november Parterne. Kundenr.: Databehandleraftale vedrørende brug af WinPLC og relaterede services Version 1.0 d. 1. november 2015 Parterne Kundenr.: Klinikkens navn og adresse (evt. stempel) (herefter den Dataansvarlige) og (herefter

Læs mere

Michael Teschl Etik Portalerne ApS Lotusvej 58 2300 København S. Sendt til: mt@etikportalen.dk

Michael Teschl Etik Portalerne ApS Lotusvej 58 2300 København S. Sendt til: mt@etikportalen.dk Michael Teschl Etik Portalerne ApS Lotusvej 58 2300 København S Sendt til: mt@etikportalen.dk 14. marts 2013 Vedrørende behandling af personoplysninger hos Etik Portalerne ApS Datatilsynet Borgergade 28,

Læs mere

Vedrørende behandling af flypassagerers biometriske oplysninger i form af template af fingeraftryk

Vedrørende behandling af flypassagerers biometriske oplysninger i form af template af fingeraftryk Brevdato: 23. maj 2006 Modtager: Scandinavian Airlines Danmark (SAS) J.nr. 2006-219-0370 Stikord: Fingeraftryk, personoplysninger, saglighed og proportionalitet, alternativ løsning, oplysningspligt, datasikkerhed.

Læs mere

Brugen af personoplysninger

Brugen af personoplysninger Gode råd om Brugen af personoplysninger Kend reglerne for håndtering af personlige oplysninger om medarbejderne! Udgivet af Dansk Handel & Service Brugen af personoplysninger 2006 Gode råd om Brugen af

Læs mere

Håndtering af fortrolige og følsomme personoplysninger ved Center for Misbrugsbehandling og Pleje, jf. forvaltningens sagsnummer

Håndtering af fortrolige og følsomme personoplysninger ved Center for Misbrugsbehandling og Pleje, jf. forvaltningens sagsnummer Borgerrådgiveren Socialforvaltningen Brev er d.d. fremsendt pr. e-mail. 16-11-2012 Sagsnr. 2012-98616 Dokumentnr. 2012-900691 Håndtering af fortrolige og følsomme personoplysninger ved Center for Misbrugsbehandling

Læs mere

It-sikkerhedstekst ST9

It-sikkerhedstekst ST9 It-sikkerhedstekst ST9 Single Sign-On og log-ud Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST9 Version 1 Juli 2015 Single Sign-On og log-ud Betegnelsen Single Sign-On (SSO)

Læs mere

BILAG 14: DATABEHANDLERAFTALE

BILAG 14: DATABEHANDLERAFTALE BILAG 14: DATABEHANDLERAFTALE Side 1/9 Aftale om databehandling mellem Kunden og Leverandøren Side 2/9 Vejledning: [Dette bilag kan ikke ændres af tilbudsgiver. Bilaget udgør således i sin helhed et mindstekrav

Læs mere

Udgivet af: IT- & Telestyrelsen. IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø. Telefon: 3545 0000 Fax: 3545 0010

Udgivet af: IT- & Telestyrelsen. IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø. Telefon: 3545 0000 Fax: 3545 0010 Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade 63 2100 København Ø Telefon: 3545 0000 Fax: 3545 0010 Sikkerhedsvejledning til OAuth 2.0 - sikkerhedsmodeller for OIOREST IT- & Telestyrelsen

Læs mere

Vejledning om videregivelse. af personoplysninger til brug for forskning og statistik

Vejledning om videregivelse. af personoplysninger til brug for forskning og statistik Vejledning om videregivelse af personoplysninger til brug for forskning og statistik 1 Indholdsfortegnelse 1. Baggrund 2. Definitioner 2.1. Personoplysning 2.2. Anonymiseret personoplysning (i persondatalovens

Læs mere

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Bilag til standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Servicebeskrivelse Økonomistyrelsen Marts 2011 Side 1 af

Læs mere

lov nr. 429 af 31/05/2000 med senere ændringer om behandling af personoplysninger (Persondataloven).

lov nr. 429 af 31/05/2000 med senere ændringer om behandling af personoplysninger (Persondataloven). Bilag 6 Databehandleraftale og databehandlerinstruks 1. Leverandøren overholder de til enhver tid gældende regler og forskrifter for behandling af personoplysninger under Kontrakten, herunder: lov nr.

Læs mere

Dokumentation af sikkerhed i forbindelse med databehandling

Dokumentation af sikkerhed i forbindelse med databehandling - Dokumentation af sikkerhed i forbindelse med databehandling Al databehandling, der er underlagt persondataloven, skal overholde de tekniske krav, der er opstillet i Datatilsynets bekendtgørelse 528 (sikkerhedsbekendtgørelsen).

Læs mere

Uddrag af lov om behandling af personoplysninger

Uddrag af lov om behandling af personoplysninger Myndighed: Justitsministeriet Udskriftsdato: 7. oktober 2016 (Gældende) Uddrag af lov om behandling af personoplysninger 1-4. (Udelades) Afsnit II Behandlingsregler Kapitel 4 Behandling af oplysninger

Læs mere

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler Blankettype: Stillingsbesættende virksomhed Datatilsynet Borgergade 28 1300 København K Anmeldelse af behandlinger af oplysninger der foretages for en privat dataansvarlig, og som sker med henblik på erhvervsmæssig

Læs mere

spørgsmål vedrørende privatlivets fred

spørgsmål vedrørende privatlivets fred Problemidentificerende spørgsmål vedrørende privatlivets fred Appendiks 4 Håndbog i: Privatlivsimplikationsanalyse IT og Telestyrelsen INDHOLDSFORTEGNELSE Brug af problemidentificerende spørgsmål... 3

Læs mere

SKABELON FOR DATABEHANDLERAFTALER MELLEM KOMMUNER OG IT-LEVERANDØRER - version 1.0 af 3. april 2017

SKABELON FOR DATABEHANDLERAFTALER MELLEM KOMMUNER OG IT-LEVERANDØRER - version 1.0 af 3. april 2017 SKABELON FOR DATABEHANDLERAFTALER MELLEM KOMMUNER OG IT-LEVERANDØRER - version 1.0 af 3. april 2017 Side 1/19 Vejledning til brug af skabelonen Tekst, der er sat i [ ] og markeret med gul er aftaletekst,

Læs mere

Databehandleraftale. Mellem. Egedal Kommune. Dronning Dagmars Vej Ølstykke. (Herefter benævnt Dataansvarlig)

Databehandleraftale. Mellem. Egedal Kommune. Dronning Dagmars Vej Ølstykke. (Herefter benævnt Dataansvarlig) Databehandleraftale Mellem Egedal Kommune Dronning Dagmars Vej 200 3650 Ølstykke (Herefter benævnt Dataansvarlig) Og (Herefter benævnt Databehandler) side 1 af 5 Generelt Databehandleren indestår for at

Læs mere

Sagsnr. 26250-0 NOTAT OM DATABEHANDLING

Sagsnr. 26250-0 NOTAT OM DATABEHANDLING Sagsnr. 26250-0 NOTAT OM DATABEHANDLING INDHOLDSFORTEGNELSE 1. Beskrivelse af problemstillingen... 3 2. Overladelse af persondata... 3 2.1. Behandlingshjemmel... 3 2.2. Dataansvar... 4 2.3. Databehandlerinstruks...

Læs mere

Datatilsynets inspektionsrapport

Datatilsynets inspektionsrapport Side 1 af 28 Datatilsynets inspektionsrapport Version 1.0 af Datatilsynets inspektionsskema i SurveyXact Dette skema anvendes på Datatilsynets inspektioner hos myndigheder. Tilsynet udfylder skemaet med

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne

Læs mere

ELEKTRONISK VINDUESKIGGERI HVOR ER

ELEKTRONISK VINDUESKIGGERI HVOR ER ELEKTRONISK VINDUESKIGGERI HVOR ER GRÆNSEN? Af advokat, LL.M., Benjamin Lundström og advokat, HD(O), Pernille Borup Vejlsgaard fra advokatfirmaet von Haller. Ifølge den nugældende lovgivning er der grænser

Læs mere

Databehandleraftale mellem Aarhus Kommune, Børn og Unge og [leverandørnavn indsættes]

Databehandleraftale mellem Aarhus Kommune, Børn og Unge og [leverandørnavn indsættes] Databehandleraftale mellem Aarhus Kommune, Børn og Unge og [leverandørnavn indsættes] Det er, jf. Kontrakt om levering af Skolesystem (Læringsplatform) som servicebureauløsning, aftalt, at [leverandørnavn

Læs mere

Digital Signatur Infrastrukturen til digital signatur

Digital Signatur Infrastrukturen til digital signatur Digital Signatur Infrastrukturen til digital signatur IT- og Telestyrelsen December 2002 Resumé: I fremtiden vil borgere og myndigheder ofte have brug for at kunne kommunikere nemt og sikkert med hinanden

Læs mere

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

Har I styr på reglerne? Forsyningsselskabers behandling af persondata

Har I styr på reglerne? Forsyningsselskabers behandling af persondata Har I styr på reglerne? Forsyningsselskabers behandling af persondata Langt de fleste virksomheder vil i forbindelse med deres virke få adgang til persondata af den ene eller anden slags. En forsyningsvirksomhed

Læs mere

PERSONDATALOVEN OG SUNDHEDSLOVEN

PERSONDATALOVEN OG SUNDHEDSLOVEN KIROPRAKTIK 2014 PERSONDATALOVEN OG SUNDHEDSLOVEN Kort om Persondataloven og Sundhedsloven Sundhedsloven 'Hovedloven' på området Relevant i ft. oplysninger er særligt:» Tavshedspligt, indhentelse og videregivelse

Læs mere

Databehandleraftale Bilag 8 til Contract regarding procurement of LMS INDHOLD

Databehandleraftale Bilag 8 til Contract regarding procurement of LMS INDHOLD INDHOLD INDHOLD... 1 1. Baggrund... 2 2. Definitioner... 2 3. Behandling af personoplysninger... 3 4. Behandlinger uden instruks... 3 5. Sikkerhedsforanstaltninger... 3 6. Underdatabehandling... 4 7. Overførsel

Læs mere

Databehandleraftale. mellem. [anfør kontraktpart] [anfør adresse] [anfør postnummer] [anfør cvr.nr.] (herefter benævnt Databehandleren )

Databehandleraftale. mellem. [anfør kontraktpart] [anfør adresse] [anfør postnummer] [anfør cvr.nr.] (herefter benævnt Databehandleren ) #BREVFLET# Click here to enter text. Dokument: Neutral titel Aalborg Kommune Boulevarden 13, 9000 Aalborg Databehandleraftale mellem [anfør kontraktpart] [anfør adresse] [anfør postnummer] [anfør cvr.nr.]

Læs mere

Persondata og IT-sikkerhed. Vejledning i sikker anvendelse og opbevaring af persondata

Persondata og IT-sikkerhed. Vejledning i sikker anvendelse og opbevaring af persondata Persondata og IT-sikkerhed Vejledning i sikker anvendelse og opbevaring af persondata December 2015 Indledning Denne vejledning har til formål, at hjælpe ansatte på IT-Center Fyns partnerskoler med at

Læs mere

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler Blankettype: Advarselsregister Datatilsynet Borgergade 28 1300 København K Anmeldelse af behandlinger af oplysninger der foretages for en privat dataansvarlig, og som sker med henblik på at advare andre

Læs mere

Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning

Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning Sundhedsstyrelsens Elektroniske Indberetningssystem (SEI) Vejledning til indberetning via Citrix-løsning Indholdsfortegnelse Indledning... 3 Systemkrav... 4 Installation af Citrix-klient... 5 Tilpasning

Læs mere

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for

SUP-specifikation, version 2.0. Bilag 9. SUP-Styregruppen. Sikkerhed og samtykke. Udkast af 12. juni Udarbejdet for SUP-specifikation, version 2.0 Bilag 9 Sikkerhed og samtykke Udkast af 12. juni 2003 Udarbejdet for SUP-Styregruppen Uddrag af indholdet kan gengives med tydelig kildeangivelse Indholdsfortegnelse 1 Introduktion...

Læs mere

Datatilsynet har besluttet at undersøge sagen af egen drift.

Datatilsynet har besluttet at undersøge sagen af egen drift. KL Weidekampsgade 10 2300 København S Sendt pr. brev samt på mail til MIH@kl.dk 15. april 2011 Vedrørende sikkerhedsbrist som følge af KL s overførsel af køreprøvebooking system til en cloud-løsning Datatilsynet

Læs mere

Administration af brugere vha. sammenhængende log-in

Administration af brugere vha. sammenhængende log-in Hvad er sammenhængende log-in? Danmarks Miljøportal Ref.: jejnb 21. august 2012 Formål Formålet med beskrivelsen er at skabe et overblik over sammenhængende log-in, som en nem og enkel måde at administrere

Læs mere

Ulrich Stigaard Jensen. Persondataloven og sagsbehandling i praksis

Ulrich Stigaard Jensen. Persondataloven og sagsbehandling i praksis Ulrich Stigaard Jensen Persondataloven og sagsbehandling i praksis Jurist- og Økonomforbundets Forlag 2011 Kapitel 1. Persondatalovens baggrund og formål 13 1.1. Persondatalovens baggrund og formål 13

Læs mere

DESIGNDOKUMENT (Teknisk dokumentation)

DESIGNDOKUMENT (Teknisk dokumentation) 29. feb.2016 version 1.2 Lægemiddelstyrelsens E2B Bivirkningsservice DESIGNDOKUMENT (Teknisk dokumentation) Dokument historik Version Dato Ændring 1.0 19-06-2014 Final version ifm. idriftsættelse 1.1 29-06-2015

Læs mere

Standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter

Standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Standardaftale om delegering af brugerrettigheder mellem lokale identitetsudbydere og serviceudbydere ved anvendelse af SAML-billetter Økonomistyrelsen Marts 2011 Side 1 af 16 Oversigt over dokumentet...3

Læs mere

Vejledning til udfyldelse af anmeldelsesskema til Datatilsynet

Vejledning til udfyldelse af anmeldelsesskema til Datatilsynet Afdeling: Direktionssekretariatet Udarbejdet af: Dorte Riskjær Larsen Sagsnr.: 13/1121 E-mail: dorte.riskjaer.larsen @ouh.regionsyddanmark.dk Dato: 26. september 2013 Telefon: 2128 4616 Vejledning til

Læs mere

Understøttelse af LSS til NemID i organisationen

Understøttelse af LSS til NemID i organisationen Understøttelse af LSS til NemID i organisationen Table of contents 1 Dette dokuments formål og målgruppe... 3 2 Introduktion til LSS til NemID... 4 2.1 Forudsætninger hos organisationen... 5 2.1.1 SSL

Læs mere

MedCom. Marts Deloitte Statsautoriseret Revisionspartnerselskab CVR-nr Weidekampsgade 6 Postboks København C

MedCom. Marts Deloitte Statsautoriseret Revisionspartnerselskab CVR-nr Weidekampsgade 6 Postboks København C Deloitte Statsautoriseret Revisionspartnerselskab CVR-nr. 33 96 35 56 Weidekampsgade 6 Postboks 1600 0900 København C Telefon 36 10 20 30 Telefax 36 10 20 40 www.deloitte.dk MedCom Revisorerklæring vedrørende

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Contents 1 Introduktion 1 2 Arkitekturoverblik 3 2.1 Eksterne snitflader..................................................

Læs mere

Forsvarsministeriets Materiel- og Indkøbsstyrelse

Forsvarsministeriets Materiel- og Indkøbsstyrelse Bilag 8 Databehandleraftale [Vejledning til Tilbudsgiverne: Bilaget skal ikke udfyldes af Tilbudsgiver i forbindelse med afgivelse af tilbud. Bilag udfyldes i fællesskab med FMI, hvis det er nødvendigt.

Læs mere

Datatilsynets udtalelse af 15. oktober 2009 vedhæftes.

Datatilsynets udtalelse af 15. oktober 2009 vedhæftes. Region Syddanmark Damhaven 12 7100 Vejle Sendt til kontakt@regionsyddanmark.dk 4. februar 2013 Vedrørende sikkerhedsbrist i Region Syddanmark Datatilsynet Borgergade 28, 5. 1300 København K CVR-nr. 11-88-37-29

Læs mere

Bilag 1 - Fælles arkitekturramme for GD1-GD2-GD7. Forslag til fælles sikkerhedsmodel for Grunddataprogrammet

Bilag 1 - Fælles arkitekturramme for GD1-GD2-GD7. Forslag til fælles sikkerhedsmodel for Grunddataprogrammet Bilag 1 - Fælles arkitekturramme for GD1-GD2-GD7 Forslag til fælles sikkerhedsmodel for Grunddataprogrammet Status: Version 1.2 Version: 19.06.2014 Indholdsfortegnelse 1. INDLEDNING... 4 1.1 BAGGRUND...

Læs mere

PERSONDATAPOLITIK. Som hovedregel kan du tilgå vores hjemmeside uden at fortælle os, hvem du er eller give personlige oplysninger om dig selv.

PERSONDATAPOLITIK. Som hovedregel kan du tilgå vores hjemmeside uden at fortælle os, hvem du er eller give personlige oplysninger om dig selv. PERSONDATAPOLITIK Ved at benytte dig af Forælder Fondens hjemmeside, www.foraelderfonden.dk, og funktionerne derpå samt ansøge Forælder Fonden om hjælp og rådgivning accepterer du, at vi behandler dine

Læs mere

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler

Oplysningerne opbevares hos den dataansvarlige og/eller Oplysningerne opbevares hos databehandler Blankettype: Kreditoplysning Datatilsynet Borgergade 28 1300 København K Anmeldelse af behandlinger af oplysninger der foretages for en privat dataansvarlig, og som sker med henblik på erhvervsmæssig videregivelse

Læs mere

Præcisering af transportbaseret sikkerhed i Den Gode Webservice

Præcisering af transportbaseret sikkerhed i Den Gode Webservice Præcisering af transportbaseret sikkerhed i Den Gode Webservice 1. Historik...2 2. Indledning...3 3. SSL/TLS baseret netværk...3 4. Sundhedsdatanettet (VPN)...5 5. Opsummering...6 6. Referencer...6 Side

Læs mere

TVovervågning. Struer Kommune Retningslinjer for anvendelse og indkøb af. TV-overvågning

TVovervågning. Struer Kommune Retningslinjer for anvendelse og indkøb af. TV-overvågning TVovervågning Struer Kommune Retningslinjer for anvendelse og indkøb af TV-overvågning Formål TV-overvågning i Struer Kommune benyttes for at bekæmpe, forebygge og opklare kriminelle handlinger som hærværk,

Læs mere

INFORMATIONSSIKKERHEDSPOLITIK. Informationssikkerhedspolitik

INFORMATIONSSIKKERHEDSPOLITIK. Informationssikkerhedspolitik Informationssikkerhedspolitik Er informationssikkerhed aktuel? Hvorfor arbejder vi med informationssikkerhedspolitik? EU direktiv 95/46/EF Persondataloven Sikkerhedsbekendtgørelsen Datatilsynet Hvorfor

Læs mere

Guide til integration med NemLog-in / Brugeradministration

Guide til integration med NemLog-in / Brugeradministration Guide til integration med NemLog-in / Brugeradministration Side 1 af 9 21. januar 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør)

Læs mere

Incest, samleje eller anden kønslig omgang med børn under 15 år

Incest, samleje eller anden kønslig omgang med børn under 15 år [Fremsendes af Rigspolitiet sammen med fremsendelse af børneattester.]!"#!"$! % &&&$!"$! Du har fra Rigspolitiet modtaget en positiv børneattest, dvs. en attest, hvoraf det fremgår, at den person, oplysningerne

Læs mere

MedCom. Året Deloitte Statsautoriseret Revisionspartnerselskab CVR-nr Weidekampsgade 6 Postboks København C

MedCom. Året Deloitte Statsautoriseret Revisionspartnerselskab CVR-nr Weidekampsgade 6 Postboks København C Deloitte Statsautoriseret Revisionspartnerselskab CVR-nr. 33 96 35 56 Weidekampsgade 6 Postboks 1600 0900 København C Telefon 36 10 20 30 Telefax 36 10 20 40 www.deloitte.dk MedCom Revisorerklæring vedrørende

Læs mere

Persondataloven hvad er nyt?

Persondataloven hvad er nyt? Persondataloven hvad er nyt? Den 27. februar 2013 Indhold Behandling af data... 2 Dataansvar og datasikkerhed... 3 Offentlighed... 4 Den registreredes rettigheder... 5 Nedenfor følger en oversigt over

Læs mere

Databehandleraftale. mellem. [Virksomhed] [Adresse] [Postnr.] [By] [CVR nr.] (herefter kaldet Databehandler)

Databehandleraftale. mellem. [Virksomhed] [Adresse] [Postnr.] [By] [CVR nr.] (herefter kaldet Databehandler) Databehandleraftale mellem [Virksomhed] [Adresse] [Postnr.] [By] [CVR nr.] (herefter kaldet Databehandler) og Hedensted Kommune Horsens Kommune Odder Kommune Niels Espes Vej 8 Rådhustorvet 4 Rådhusgade

Læs mere

UDSNIT 8. februar 2008

UDSNIT 8. februar 2008 UDSNIT 8. februar 2008 Dette udsnit indeholder indeholder en introduktion til hvad begrebet brugerstyring dækker over Kolofon: OIO Referencemodel for tværgående brugerstyring Dette baggrundsdokument kan

Læs mere

I arkivloven, jf. lovbekendtgørelse nr. 1035 af 21. august 2007, som ændret ved lov nr. 1170 af 10. december 2008, foretages følgende ændringer:

I arkivloven, jf. lovbekendtgørelse nr. 1035 af 21. august 2007, som ændret ved lov nr. 1170 af 10. december 2008, foretages følgende ændringer: Lovforslag (udkast) 17. februar 2015 Forslag til lov om ændring af arkivloven I arkivloven, jf. lovbekendtgørelse nr. 1035 af 21. august 2007, som ændret ved lov nr. 1170 af 10. december 2008, foretages

Læs mere

Databehandleraftale. Dags dato er indgået nedenstående aftale mellem

Databehandleraftale. Dags dato er indgået nedenstående aftale mellem Dags dato er indgået nedenstående aftale mellem Københavns Kommune Teknik- og Miljøforvaltningen Njalsgade 13 2300 København S CVR.nr.: 64 94 22 12 (Herefter benævnt Kunden) og [Firmanavn] CVR.nr.: [CVR.nr.]

Læs mere