Identitetsbaserede webservices og personlige data

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Starte visningen fra side:

Download "Identitetsbaserede webservices og personlige data"

Transkript

1 > Identitetsbaserede webservices og personlige data Version 0.8 IT- & Telestyrelsen juni 2009

2 Indhold > Indledning 3 Målgruppe 3 Afgrænsning 4 Definitioner og begreber 5 Scenarier 7 Scenarie med browser og ekstern logintjeneste 7 Scenarie med rig klient og lokal STS 9 Sikkerhedsmæssige og juridiske egenskaber 11 Profiler i OIOIDWS 14 Kontrol af aktiv brugersession 16 Juridiske forhold 17 Regulering 17 Personoplysningsloven 17 Bevismæssige forhold 20 Ansvar 21 Referencer 23

3 Indledning Identitetsbaserede webservices er en særlig slags webservices, der kan 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 webservices (herefter OIOIDWS) er et sæt af web service profiler udviklet af IT- og Telestyrelsen, som tilbyder en standardiseret måde at overføre påstande (engelsk: claims) om en serviceaftager til en serviceudbyder. Påstande om serviceaftageren (som kan være en fysisk person, eller et it-system) vil typisk blive afvendt til adgangsmæssige afgørelser. 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 Trafikstyrelsen. 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 Trafikstyrelsen, 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 webservices baseret på OIOIDWS profilerne til at udveksle data.

4 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, og der henvises til de underliggende profildokumenter for tekniske detaljer. 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 personoplysningsloven 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 generelle personoplysninger vil ikke blive særskilt behandlet, da reglerne vil kunne opfyldes af samme sikkerhedsniveau som for fortrolige oplysninger.

5 Definitioner og begreber Videregivende myndighed Betegnelsen er valgt ud fra personoplysningslovens begreber. 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 personoplysningslovens regler. Databehandling I personoplysningslovens 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 webservices. 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 webservices. 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. Figur 1: De vigtigste elementer i OIOIDWS

6 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 webservices. Et security token identificerer brugeren, hvilken applikation der må anvende tokenet, samt hvilken service, det er udstedt til.

7 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. 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).

8 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.

9 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.

10 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.

11 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 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 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å. 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 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 personoplysningslovens krav til kryptering af data, der sendes over Internet, og dette er tilstrækkeligt til både fortrolige og følsomme personoplysninger.

12 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. Personoplysningsloven 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, 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 myndighederne 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. 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 på baggrund af data modtaget fra fremmede myndigheder; for detaljer om signaturbeviser henvises til [SIG-BEV]. Det er muligt for myndighederne 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. Egenskab 8: Samtykke fra borger Når der er behov for samtykke fra borgeren 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 2 Tokenet er bundet til applikationens signatur via holder-of-key mekanismen i SAML.

13 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 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 brugeren en mulighed for at underskrive samtykkeerklæringen 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 generelle, 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 personoplysningslovens 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.

14 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 transportniveaukryptering, 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-

15 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.

16 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 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.

17 Juridiske forhold Regulering Den regulering, der er relevant for videregivelsen af borgerens data, er listet i nedenstående tabel. 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 personoplysningsloven. 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 Personoplysningsloven. Nr. 429 af 31/ Sikkerhedsbekendtgørelsen Nr. 528 af 15/ Vejledning til bekendtgørelse nr. 528 af 15. juni 2000 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 POL. Når der udveksles persondata indenfor det offentlige. Bekendtgørelsen uddyber tekniske og administrative krav til personoplysningsloven. Vejledning omkring sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning. 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. Personoplysningsloven Der stilles krav til, hvordan personoplysninger behandles indenfor følgende 4 hovedområder: Administrative krav til behandlingssikkerhed. Den registreredes rettigheder. Anmeldelse til Datatilsynet. Teknisk sikkerhed. Kravene retter sig imod al behandling af data, fordi en databehandling i personoplysningslovens 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 generelle, fortrolige eller følsomme.

18 Internettet er et åbent netværk, og det er hverken sikkert eller lovligt i forhold til personoplysningsloven 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 personoplysningslovens organisatoriske krav. I det følgende fokuseres på de krav i personoplysningsloven 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 webservices over internettet. Omdrejningspunktet vil være it-sikkerheden og dermed personoplysningslovens 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 personoplysningsloven klassificeres i følgende 3 kategorier: Følsom Fortrolig Generel POL 7 POL 8 POL 11 POL 6 POL 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, skatteforhold, gæld, sygedage, tjenestelige forhold og familieforhold Bolig, bil, eksamen, ansøgning, CV, ansættelsesdato, stilling, arbejdsområde, arbejdstelefon, stamoplysninger. Eksempler er Navn, adresse og fødselsdato. Når data er blevet inddelt i en af de 3 kategorier følsom, fortrolig og generel - kan man ud fra klassifikationen se, hvilke krav der stilles til data og behandlingen heraf. Kravene, der afhænger af datas klassifikation, er kortfattet beskrevet i nedenstående tabel: Generelle krav Følsom Fortrolig Generel Der er et generelt forbud mod at dele data medmindre der er lovhjemmel eller oplyst og uafviseligt samtykke fra borger. Med uafviseligt menes, at samtykkes skal gives af en borger, Der stilles krav til sikkerheden såvel teknisk som administrativt. Ikke alle behandlinger af fortrolige data skal anmeldes til Datatilsynet, Der stilles ikke så store sikkerhedskrav til generelle persondata. Behandlingen er omfattet af

19 der er tydeligt oplyst om formål og anvendelse. Desuden skal samtykket være givet skriftligt, så der ingen tvivl er om omfanget. Endelig skal der anvendes en teknik der er sikker nok til, at man kan stole på data. 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. men forholdet skal undersøges. Borgerens ret til eksempelvis at se og rette data skal sikres. personoplysningsloven. 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. Krav der vedrører den enkelte myndigheds interne administration af data såsom relevans og saglighedskriterier efter POL 5, 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. Behandlingssikkerhed Databehandling og videregivelse er lovlig (POL 6,7,8 og 11) Data behandles sikkert POL 41, stk. 3 Logning af adgang og behandling af fortrolige personoplysninger (sikkerhedsbekendtgørelsen 15, 18 og 19) OIOIDWS Videregivende myndighed skal sikre hjemmel til videregivelsen ved samtykke fra borgeren eller ved tilladelse i lov. For følsomme og fortrolige data, der videregives på baggrund af samtykke, skal det være specifikt oplyst, hvilke oplysninger der videregives. Kravene til uafviselighed vil være mest tungtvejende ved følsomme data. 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. Servicekald kan logges ved brug af IDWS konceptet. Det er den enkelte myndighed der skal sikre, at egne webservices sættes op, så den nødvendige logning af tilgang og brug af fortrolige og følsomme personoplysninger foretages.

20 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.(pol 41, stk. 1) B. Den registreredes rettigheder Den dataansvarliges har opfyldt sin oplysningspligt. OIOIDWS 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 webservices 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. 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.

21 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 er det væsentlige at have for øje, at det 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 personoplysningsloven 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 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: Sikre klassifikation af data dvs. om det er generelle, fortrolige eller følsomme persondata. Sikre hjemmel til videregivelsen eksempelvis i forbindelse med 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 behørigt orienteret om videregivelse af data. 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.

22 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.

23 Referencer [DTT] [OIO-WST] OIO WS-Trust Profile V0.98, Danish IT and Telecom Agency. [OIO- WSTDEP] [OIO-IDT] [OIO-BOOT] [OIO-SAML- SSO] [LIB-BAS] [LIB-SOAP] [WST] [SIG-BEV] OIO WS-Trust Deployment Profile V0.2, Danish IT and Telecom Agency. OIO SAML Profile for Identity Tokens, V0.9, Danish IT and Telecom Agency. OIO Bootstrap Token Profile, Danish IT and Telecom Agency. OIO Web SSO Profile V2.0, Danish IT and Telecom Agency. Liberty Basic SOAP Binding Profile, version 0.95, 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] SSL 3.0 Specification : [TLS] [OCES-CP] The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force. https://www.signatursekretariatet.dk/certifikatpolitikker.html [AUTH-LEV] Vejledning vedrørende niveauer af autenticitetssikring.

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

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

Læs mere

Datatilsynet skal bemærke følgende:

Datatilsynet skal bemærke følgende: IT- og Telestyrelsen Holsteinsgade 63 2100 København Ø Sendt til: oiostandarder@itst.dk 17. juli 2009 Vedrørende høring over OIO identitetsbaserede webservices version 1.0 Datatilsynet Borgergade 28, 5.

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

Guide til NemLog-in Security Token Service

Guide til NemLog-in Security Token Service Guide til NemLog-in Security Token Service Side 1 af 10 18. juni 2014 TG Denne guide indeholder en kort beskrivelse af, hvordan en myndighed eller itleverandør kan benytte NemLog-in s Security Token Service

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

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

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

23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring

23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring 23. maj 2013Klik her for at angive tekst. HHK/KMJ Vejledning til 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

Læs mere

Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in

Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in Overordnet løsningsbeskrivelse - Private aktører og borger log-in via SEB / NemLog-in (samt mulighed for FMK tilgang via SOSI STS) 15.marts 2017 /chg Baggrund Private aktører på sundhedsområdet som apoteker,

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

Hvordan er det med datasikkerhed og privacy? Highlights fra persondataloven Århus, d. 14. marts 2017 Erika Wolf, jurist, Sundhedsdatastyrelsen

Hvordan er det med datasikkerhed og privacy? Highlights fra persondataloven Århus, d. 14. marts 2017 Erika Wolf, jurist, Sundhedsdatastyrelsen Hvordan er det med datasikkerhed og privacy? Highlights fra persondataloven Århus, d. 14. marts 2017 Erika Wolf, jurist, Sundhedsdatastyrelsen Hvem er jeg, og hvor kommer jeg fra? Erika Wolf, jurist i

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

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

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

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

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

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

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

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne)

(Bilag til dagsordenspunkt 8, Kommunale anvenderkrav til støttesystemerne) 25. april 2013Klik her for at angive tekst. NOTAT Bilag 11: Anvenderkrav til adgangsstyring - Støttesystemerne Context handler, Security Token Service og Administrationsmodul (Bilag til dagsordenspunkt

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

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

Ishøj Kommune Ishøj Store Torv Ishøj CVR [behandlernes navn] [behandlerens adresse] [Postnummer] CVR.

Ishøj Kommune Ishøj Store Torv Ishøj CVR [behandlernes navn] [behandlerens adresse] [Postnummer] CVR. IT Databehandleraftale Databehandleraftale om [SYSTEMNAVN] mellem Ishøj Kommune Ishøj Store Torv 20 2635 Ishøj CVR. 11 93 13 16 (herefter nævnt som dataansvarlige) Og [behandlernes navn] [behandlerens

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

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. Mellem parterne: Den dataansvarlige myndighed Regioner og kommuner (herefter Dataansvarlig )

DATABEHANDLERAFTALE. Mellem parterne: Den dataansvarlige myndighed Regioner og kommuner (herefter Dataansvarlig ) DATABEHANDLERAFTALE Mellem parterne: Den dataansvarlige myndighed Regioner og kommuner (herefter Dataansvarlig ) og Databehandler Dansk Telemedicin A/S Robert Jacobsens Vej 68 2300 København S CVR.nr.:

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

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 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

Underbilag 4B til kontrakt om elektronisk nøglesystem mellem Kalundborg Kommune og [Navn - skal udfyldes af leverandøren]

Underbilag 4B til kontrakt om elektronisk nøglesystem mellem Kalundborg Kommune og [Navn - skal udfyldes af leverandøren] Underbilag 4B til kontrakt om elektronisk nøglesystem mellem Kalundborg Kommune og [Navn - skal udfyldes af leverandøren] DATABEHANDLERAFTALE Der er dags dato indgået følgende Databehandleraftale mellem

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

Procedure for tilsyn af databehandleraftale

Procedure for tilsyn af databehandleraftale IT Projekt og Udviklingsafdeling Dato:7.2.2017 Procedure for tilsyn af databehandleraftale Reference til Retningslinjer for Informationssikkerhed: Afsnit 14.5 (Databehandleraftaler). Ved ibrugtagning af

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

Almindelig viden om persondataforordningen

Almindelig viden om persondataforordningen Almindelig viden om persondataforordningen Hvad er persondata? En Personoplysning er enhver form for information om en identificeret eller identificerbar fysisk person ( den registrerede ). Dette gælder

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

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

Kontraktbilag 7: Databehandleraftale

Kontraktbilag 7: Databehandleraftale Kontraktbilag 7: Databehandleraftale DATABEHANDLERAFTALE Mellem parterne: Den dataansvarlige myndighed Region Syddanmark Damhaven 12 CVR.nr.: 29190909 (herefter Dataansvarlig ) og Databehandler Leverandør

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

DATABEHANDLERAFTALE. Mellem. [XXXX] Kommune [adresse] [postnr. og by] CVR. nr.: [XXXX] (herefter Kommunen )

DATABEHANDLERAFTALE. Mellem. [XXXX] Kommune [adresse] [postnr. og by] CVR. nr.: [XXXX] (herefter Kommunen ) DATABEHANDLERAFTALE Mellem [XXXX] Kommune [adresse] [postnr. og by] CVR. nr.: [XXXX] (herefter Kommunen ) og [Leverandørens navn] [adresse] [postnr. og by] CVR. nr.: [XXXX] (herefter Leverandøren ) er

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

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

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

DATABEHANDLERAFTALE. Mellem. Silkeborg Kommune Søvej Silkeborg CVR. nr.: (herefter Kommunen )

DATABEHANDLERAFTALE. Mellem. Silkeborg Kommune Søvej Silkeborg CVR. nr.: (herefter Kommunen ) DATABEHANDLERAFTALE Mellem Silkeborg Kommune Søvej 1 8600 Silkeborg CVR. nr.: 29 18 96 41 (herefter Kommunen ) og [Leverandørens navn] [adresse] [postnr. og by] CVR. nr.: [XXXX] (herefter Leverandøren

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

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

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

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

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

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

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

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

DATABEHANDLERAFTALE. Mellem. Svendborg Kommune Ramsherred Svendborg CVR. nr.: (herefter Kommunen ) XXXXXX xxxxxx xxxx

DATABEHANDLERAFTALE. Mellem. Svendborg Kommune Ramsherred Svendborg CVR. nr.: (herefter Kommunen ) XXXXXX xxxxxx xxxx DATABEHANDLERAFTALE Mellem Svendborg Kommune Ramsherred 5 5700 Svendborg CVR. nr.: 29189730 (herefter Kommunen ) og XXXXXX xxxxxx xxxx CVR. nr.: [XXXX] (herefter Leverandøren ) er der indgået nedenstående

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

Dragør Kommune Borgmestersekretariat, IT og Personale Marts

Dragør Kommune Borgmestersekretariat, IT og Personale Marts Bilag 5 Databehandleraftale 1. Overholdelse af gældende regler og forskrifter Databehandleren overholder de til enhver tid gældende regler og forskrifter for behandling af personoplysninger under Kontrakten,

Læs mere

BILAG 14 TIL KONTRAKT OM EPJ/PAS IT-SIKKERHED OG DATABEHANDLERAFTALE

BILAG 14 TIL KONTRAKT OM EPJ/PAS IT-SIKKERHED OG DATABEHANDLERAFTALE BILAG 14 TIL KONTRAKT OM EPJ/PAS IT-SIKKERHED OG DATABEHANDLERAFTALE INSTRUKTION TIL BESVARELSE AF BILAGET: Teksten i dette afsnit er ikke en del af Kontrakten og vil blive fjernet ved kontraktindgåelse.

Læs mere

1.3. Kentaur er dataansvarlig for dine personoplysninger. Al henvendelse til Kentaur skal ske via kontaktoplysningerne anført under pkt. 7.

1.3. Kentaur er dataansvarlig for dine personoplysninger. Al henvendelse til Kentaur skal ske via kontaktoplysningerne anført under pkt. 7. PERSONDATAPOLITIK 1. GENERELT 1.1. Denne politik om behandling af personoplysninger ( Personadatapolitik ) beskriver, hvorledes Kentaur A/S ( Kentaur, os, vores, vi ) indsamler og behandler oplysninger

Læs mere

Driftskontrakt. Databehandleraftale. Bilag 14

Driftskontrakt. Databehandleraftale. Bilag 14 Databehandleraftale Bilag 14 DATABEHANDLERAFTALE mellem Danpilot Havnepladsen 3A, 3. sal 5700 Svendborg CVR-nr. 30071735 (herefter den Dataansvarlige ) og [Leverandørens navn] [adresse] [postnr. og by]

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

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

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

Bilag 9 Databehandleraftale

Bilag 9 Databehandleraftale Bilag 9 Databehandleraftale Aftale om databehandling mellem Trafik-, Bygge- og Boligstyrelsen Edvard Thomsens Vej 14 2300 København S (i det følgende betegnet som den Dataansvarlige) og XXX XX XX (i det

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

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

Vandforsyningens håndtering af den kommende persondataforordning. Danske Vandværker

Vandforsyningens håndtering af den kommende persondataforordning. Danske Vandværker Vandforsyningens håndtering af den kommende persondataforordning Danske Vandværker Praktiske spørgsmål vi modtog Hvem har ansvaret for beskyttelse af forbrugernes persondata? Er medlemslister i ringbindsmapper

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

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

- med dig i fremtiden DATABEHANDLERAFTALE. Aftale omkring behandling af persondata. Udarbejdet af: Mentor IT

- med dig i fremtiden DATABEHANDLERAFTALE. Aftale omkring behandling af persondata. Udarbejdet af: Mentor IT DATABEHANDLERAFTALE Aftale omkring behandling af persondata Udarbejdet af: Mentor IT Aftalen Denne databehandleraftale (Aftalen) er er et tillæg til den indgåede kontrakt mellem kunden (Dataansvarlig)

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

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

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

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

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

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

DATABEHANDLERAFTALE vedr. Indkøbsordning til visiterede borgere i eget hjem

DATABEHANDLERAFTALE vedr. Indkøbsordning til visiterede borgere i eget hjem vedr. Indkøbsordning til visiterede borgere i eget hjem Mellem Hvidovre Kommune Hvidovrevej 278 2650 Hvidovre Glostrup Kommune Rådhusparken 2 2600 Glostrup (CVR nr. 65120119) Rødovre Kommune Rødovre Parkvej

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

DATABEHANDLERAFTALE VEDRØRENDE [AFTALENAVN]

DATABEHANDLERAFTALE VEDRØRENDE [AFTALENAVN] DATABEHANDLERAFTALE VEDRØRENDE [AFTALENAVN] Tekst markeret med GRØN, udfyldes inden udsendelse til leverandøren Tekst markeret med TURKIS, udfyldes af leverandøren Side 1/16 Side 2/16 DATABEHANDLERAFTALE

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

Kontraktbilag 3. Databehandleraftale

Kontraktbilag 3. Databehandleraftale Kontraktbilag 3 Databehandleraftale 1. DATABEHANDLERAFTALENS OMFANG OG FORMÅL Formålet med behandlingen af personoplysninger er overordnet set at drive en iværksætterpilotordning som nærmere fastlagt i

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

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

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0

SOSI. (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 SOSI (ServiceOrienteretrienteret SystemIntegration) Quick Tour 2.0 Indhold Hvad og hvem er SOSI Visionen og Missionen Begreber, arkitektur og teknik Hvad er SOSI Projekt initieret og drevet af Ribe- og

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

Indhold. Digital Sundhed. Brugerstyringsattributter - Politikker ... 2. 1. Introduktion... 2 2. Identifikation...

Indhold. Digital Sundhed. Brugerstyringsattributter - Politikker ... 2. 1. Introduktion... 2 2. Identifikation... Digital Sundhed Brugerstyringsattributter - Politikker - Specificering af nye og ændrede attributter i id-kortet Indhold 1. Introduktion... 2 2. Identifikation...... 2 2.1. Politik... 2 3. Sundhedsfaglig

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

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

[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

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

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

Guide til integration med NemLog-in / Web SSO

Guide til integration med NemLog-in / Web SSO Guide til integration med NemLog-in / Web SSO Side 1 af 13 5. januar 2015 TG Denne guide indeholder en kort beskrivelse af, hvordan en myndighed eller itleverandør kan integrere en it-løsning til NemLog-in

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

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

September Indledning

September Indledning September 2016 Eksempel fra KOMBIT: Vejledning til gennemførelse af indledende overordnet kortlægning af it-løsningers parathed i forhold til efterlevelse af kendte krav i Databeskyttelsesforordningen

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

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark

De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark De fællesoffentlige komponenter: Federativa identitetslösningar, Erfarenheter från Danmark Digital post, NemSMS & Fjernprint samt strategien for udvikling af mobile løsninger for Digital post og Min side

Læs mere

Vilkår for It-systemudbyderes tilslutning til og anvendelse af NemLog-in. Digitaliseringsstyrelsen 2013

Vilkår for It-systemudbyderes tilslutning til og anvendelse af NemLog-in. Digitaliseringsstyrelsen 2013 Vilkår for It-systemudbyderes tilslutning til og anvendelse af NemLog-in Digitaliseringsstyrelsen 2013 Side 2 af 31 Indhold Indhold... 2 0. Praktisk info... 5 0.1 Om tiltrædelse af vilkår... 5 0.2 Om gateway-leverandørers

Læs mere

Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og Google Apps skoleløsning Version 1.0, 30.

Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og Google Apps skoleløsning Version 1.0, 30. Udveksling af login- og brugeroplysninger mellem Odense Kommunes brugerkatalog og skoleløsning Version 1.0, 30. september 2010 Dette dokument giver et kort overblik hvordan brugeroplysninger i Odenses

Læs mere

Datatilsynet: Krav om datasikkerhed i forbindelse med personaleadministration

Datatilsynet: Krav om datasikkerhed i forbindelse med personaleadministration Side 1 af 2 Forside / Erhverv / Personaleadministration / Krav om datasikkerhed i forbindelse med personaleadministration Opdateret: 06.05.15 Krav om datasikkerhed i forbindelse med personaleadministration

Læs mere