Nederst foto på forsiden: B Tal ( Creative Commons NY-NC (

Save this PDF as:
 WORD  PNG  TXT  JPG

Størrelse: px
Starte visningen fra side:

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

Transkript

1

2 Sikkerhedsmodeller for OIOREST Udgivet af: IT- & Telestyrelsen IT- & Telestyrelsen Holsteinsgade København Ø Telefon: Fax: Nederst foto på forsiden: B Tal ( Creative Commons NY-NC ( Publikationen kan hentes på IT- & Telestyrelsens Hjemmeside: ISBN (internet):

3 Sikkerhedsmodeller for OIOREST Version 1.0 IT- & Telestyrelsen marts 2009

4 Indhold > Indledning 5 Afgrænsning 5 Model 1: Sikring af systemkald 6 Arkitektur 6 Etablering af sikkerhed 6 Sikkerhedsmæssige egenskaber 8 Praktiske forhold 8 Særlige juridiske forhold i system-til-system kald 9 Model 2: Systemkald på vegne af bruger 11 Arkitektur 11 Overførsel af brugeridentitet 11 Etablering af sikkerhed 11 Sikkerhedsmæssige egenskaber 12 Attributter i fremmede registre 12 Praktiske forhold 12 Særlige juridiske overvejelser ved systemkald på vegne af bruger 13 Juridiske forhold 14 Regler der er i spil, når man sammenkobler services 14 Personoplysningsloven 14 Scenarie A 15 Scenarie B 16 Ansvar 17 Kom godt fra start med personoplysningsloven 17 Referencer 19

5 Indledning > Denne guide er henvendt til offentlige myndigheder samt private virksomheder, der ønsker at udstille eller anvende web services baseret på [OIOREST]. Guiden beskriver sikkerhedsmodeller, der kan anvendes i forbindelse med OIOREST. Formålet er at opnå fundamentale sikkerhedsmæssige egenskaber for kommunikationen herunder autenticitet, integritet og konfidentialitet. Anvendelse af de beskrevne sikkerhedsmodeller gør det muligt at udbyde eller anvende web services, der eksponerer følsomme data eller udbyder kritiske ressourcer via internettet. Sikkerhedsmodellerne tager udgangspunkt to alment forekommende scenarier for serviceintegration: det første scenarie består af et system-til-system kald via internettet, og det andet scenarie udvider det første med kald på vegne af en bruger. Begge sikkerhedsmodeller er baseret på brug af sikre transportprotokoller nærmere betegnet TLS / SSL 1 (se [TLS] og [SSL]). For hver sikkerhedsmodel beskrives: Arkitekturen hvor modellen kan anvendes. Hvordan sikkerheden etableres. De sikkerhedsmæssige egenskaber modellen tilvejebringer. Praktiske forhold man skal være opmærksom på. Juridiske aspekter af serviceintegration. Afgrænsning Guiden udstikker generelle retningslinjer, og der gives således ikke detailanvisninger på, hvorledes specifikke servere eller programmeringsmiljøer konfigureres i praksis. Endvidere skal det påpeges, at de beskrevne sikkerhedsmodeller alene dækker kommunikationen mellem en serviceaftager og en serviceudbyder; generelle itsikkerhedsaspekter i organisationer og it-systemer behandles ikke. Den juridiske del af vejledningen er udarbejdet for at give et kortfattet overblik over de krav især personoplysningsloven stiller. Vejledningen vil derfor ikke gå i detaljer med de enkelte forhold, i stedet gives et overblik, som hjælper godt fra start i forbindelse med brug af OIOREST. Læseren forudsættes at være bekendt med OIOREST samt gængse begreber indenfor it-sikkerhed. 1 I det følgende anvendes betegnelsen SSL som en fællesbetegnelse for SSL og TLS. De to protokoller er stort set ækvivalente; SSL (Secure Socket Layer) er den oprindelige protokol, der blev udviklet af Netscape, og navnet TLS (Transport Security Layer) blev indført i forbindelse med standardisering af protokollen under Internet Engineering Task Force. 5

6 Model 1: Sikring af systemkald > Arkitektur Den første sikkerhedsmodel finder anvendelse på system-til-system kald via internettet, hvor de to systemer evt. tilhører forskellige organisationer. Det ene system initierer kommunikationen og optræder i rollen som serviceaftager (forkortet SA i det følgende), og det andet optræder i rollen som serviceudbyder (forkortet SU). Figur 1: Scenarie med system-til-system kald Kommunikationen følger request-response mønstret, hvor serviceaftageren sender en forespørgsel og herefter (synkront) modtager et svar fra serviceudbyderen. Ønsker man asynkron kommunikation, hvor der f.eks. kaldes tilbage på et senere tidspunkt, etableres en ny OIOREST kommunikation, hvor rollerne af serviceaftager og serviceudbyder byttes om. I dette scenarie foretages systemkaldet med serviceaftagerens identitet og serviceudbyderen får ikke direkte informationer, om hvorvidt kaldet afvikles på vegne af en bruger eller it-system hos serviceaftageren, men alene at det kommer fra den virksomhed, som serviceaftageren repræsenterer. Etablering af sikkerhed Sikringen af kommunikationen etableres ved, at parterne anvender SSL protokollen til den HTTP-baserede kommunikation 2. SSL protokollen findes i to varianter, nemlig med eller uden klientautentifikation (se nedenfor). I denne sikkerhedsmodel anvendes varianten med klientautentifikation (serverautentifikation er obligatorisk). Inden kommunikationen kan etableres, skal begge parter udstyres med et såkaldt X.509 certifikat med en tilhørende privat nøgle (som illustreret på ovenstående figur): Serviceaftageren skal have et klientcertifikat og her anbefales enten et OCES Virksomhedscertifikat (forkortet VOCES), et OCES Funktionscertifikat (forkortet FOCES) eller et OCES Medarbejdercertifikat (forkortet MOCES) 2 Når HTTP sikres med SSL benyttes ofte betegnelsen HTTPs, som angivet på figuren. 6

7 med tilhørende privat nøgle. Som regel skal disse installeres på de applikationsservere eller på den klient, der skal kalde servicen 3. Serviceudbyderen skal konfigureres med et SSL servercertifikat med tilhørende privat nøgle. Som regel skal dette installeres på virksomhedens web servere. Et OCES Virksomhedscertifikat identificerer indehaveren som virksomhed via et CVR nummer, og et OCES Funktionscertifikat identificerer tillige den service eller applikation, som på virksomhedens vegne anvender certifikatet. Forskellen på de to OCES certifikattyper består primært i, at VOCES kan anvendes til at indgå bindende aftaler på vegne af en virksomhed, mens FOCES alene er beregnet til sikring af teknisk kommunikation. Forskellene mellem de to typer certifikater i OIOREST sammenhæng er opsummeret i nedenstående tabel: Forskelle mellem FOCES og VOCES Fordele ved funktionscertifikater sammenlignet med virksomhedscertifikater: Mindre konsekvenser ved kompromittering, da den private nøgle ikke kan binde virksomheden. Dette kan være en fordel, hvis certifikat og privat nøgle skal installeres på en server i en demilitariseret zone (DMZ), som kan være under angreb fra internettet. Identificerer servicen som anvender certifikatet. Billigere end virksomhedscertifikater. Fordele ved virksomhedscertifikater sammenlignet med funktionscertifikater: Kan anvendes i flere sammenhænge herunder til bindende aftaleindgåelse. Rent praktisk bestilles begge typer certifikater gennem LRA klienten fra DanID (tidligere TDC). Et MOCES certifikat identificerer en medarbejder i en given virksomhed og adskiller sig fra de to øvrige typer ved, at der skal angives kodeord hver gang den private nøgle anvendes. MOCES certifikater er derfor i OIOREST sammenhæng kun relevante, når serviceaftager er en rig klient, der har adgang til brugerens private nøgle (efter brugeren har indtastet password). For detaljer om OCES certifikatpolitikkerne henvises til [OCES-CP]. Endelig skal det nævnes, at OCES personcertifikater og medarbejdercertifikater spiller en rolle i forbindelse med på-vegne-af scenarier (se næste kapitel), hvor de anvendes af slutbrugeren til at logge ind i serviceaftagers applikation. 3 Langt de fleste applikationsservere og netværksstakke kan konfigureres til at anvende SSL, så programmøren ikke behøver at udvikle programkode. 7

8 Et SSL servercertifikat identificerer indehaveren via et domænenavn på internettet (f.eks. hvilket er et krav i forbindelse med SSL protokollen. Disse certifikater kan anskaffes fra en lang række udbydere. Sikkerhedsmæssige egenskaber Ved anvendelse af ovenstående sikkerhedsmodel opnår man følgende sikkerhedsmæssige egenskaber: Konfidentialitet af kommunikationen såvel HTTP headere og body, der bærer OIOREST kommunikationen, holdes hemmelige under transport. Integritet af kommunikationen. Autentifikation af serviceaftager som virksomhed eller evt. medarbejder i en virksomhed overfor serviceudbyder. Ved anvendelse af softwarebaserede OCES certifikater opnås i udgangspunktet autentifikation på niveau 3 i forhold NIST s klassificeringer af autenticitetssikring 4 svarende til høj tillid til påstået identitet (se evt. [AUTH-LEV] for detaljer). Er der brug for et højere niveau af autenticitetssikring (dvs. 4), skal man i udgangspunktet anvende kryptografisk hardware til beskyttelse af den private nøgle. Autentifikation af serviceudbyder (i form af domænenavn) overfor serviceaftager. Det skal bemærkes, at ovenstående egenskaber opnås mellem serviceaftagers applikationsserver og den (web) server hos serviceudbyderen, der terminerer SSL forbindelsen. Hvis serviceudbyderen har en it-arkitektur bestående af flere sikkerhedszoner adskilt af firewalls, vil SSL termineringen typisk ske i en demilitariseret zone (DMZ). Her skal man være opmærksom på sikring af kommunikationen videre ind i bagvedliggende zoner hos serviceudbyderen, hvilket typisk også vil ske med SSL forbindelser. Endvidere skal det nævnes, at modellen ikke giver uafviselighed på de enkelte transaktioner / servicekald. Har man brug for dette, kan man evt. indføre digitale signaturer over de data, som transporteres i HTTP kaldet. Dette beskrives dog ikke yderligere i denne guide. Guiden [SIG-BEV] beskriver, hvorledes bevisværdien af digitale signaturer kan sikres. Praktiske forhold Ved implementering af ovenstående model er der en række praktiske forhold, man bør overveje: Inden kommunikationen kan etableres, skal parterne konfigurere systemerne med en liste af certifikatudstedere, der skal accepteres for modpartens certifikat. Serviceudbyderen skal konfigurere hvilke serviceaftagere, der må kalde servicen dvs. opsætte adgangskontrol. Dette kan typisk ske ved at identificere 4 8

9 certifikater eller andre referencer for de serviceaftagere, man vil give adgang, samt opsætte regler for, hvad de må tilgå. De private nøgler hørende til certifikaterne skal beskyttes mod uautoriseret adgang. Hvis hackere kan få adgang til de private nøgler, er kommunikationen usikker, og en hacker vil bl.a. kunne udgive sig for at være den part, der er angivet i det tilhørende certifikat. SSL protokollen kan anvende forskellige krypteringsalgoritmer, hashalgoritmer og forskellige nøglelængder (såkaldte cipher suites ; se evt. [TLS] afsnit A.5), hvoraf nogle giver ringe eller ingen sikkerhed. Man bør derfor konfigurere sine servere, så der kun accepteres cipher suites med stærk kryptering (minimum 128 bit). Serviceudbyderen skal konfigurere sin server til at kræve klientautentifikation, da dette er krævet i sikkerhedsmodellen men valgfrit i SSL. Tillader man kald uden klientautentifikation, har man ikke vished for serviceaftagers identitet. SSL protokollen findes i forskellige versioner, og man bør ikke tillade gamle versioner. Serverne bør derfor kræve mindst version 3.0 af SSL og mindst version 1.1 af TLS. Certifikaterne har en udløbsdato (typisk to år efter udstedelse), og parterne bør etablere en procedure, der sikrer, at de fornys i god tid inden udløb. I modsat fald vil systemerne pludselig holde op med virke den dag, certifikatet udløber. Man skal konfigurere sine servere til at foretage et spærrecheck af certifikatet enten via spærrelister (CRL) eller on-line opslag hos certifikatudstederen (OCSP protokollen). Hvis man ikke foretager spærrecheck, bliver det muligt at få adgang med et spærret certifikat. I ovenstående beskrivelse har udgangspunktet været, at kommunikationen består af et enkelt request-response kald. Det skal dog nævnes, at SSL protokollen etablerer en session, hvor man vil kunne sende mange OIOREST kald/svar. I situationer, hvor der er behov for mange servicekald indenfor en kort tidsperiode (f.eks. såkaldte batch jobs), kan man overveje at genbruge sessionen med henblik på at opnå bedre performance. Dette kræver dog, at begge systemer kan håndtere dette. Særlige juridiske forhold i system-til-system kald Ved at følge ovenstående anbefalinger etableres stærk kryptering, hvilket er et krav, hvis følsomme persondata skal udveksles. Dette er et krav som følger af Sikkerhedsbekendtgørelsen 14. Sikkerhedsmodellen forudsætter generel tillid fra serviceudbyder til serviceaftager, herunder at der kun foretages kald, som serviceaftageren er berettiget til. Man bør forud for integrationen af systemerne udforme en skriftlig aftale / kontrakt mellem parterne, der regulerer væsentlige forhold som f.eks.: Teknisk kvalitet af den udbudte service herunder svartider, oppetider, tilladte antal transaktioner. Hvis serviceudbyder f.eks. lukker servicen ned for vedligehold, kan det betyde, at serviceaftagers it-systemer holder op med at fungere korrekt. Vilkår for anvendelse af servicen f.eks. at det kun må ske som led i sagsbehandling, som serviceaftager lovmæssigt er pålagt. Et andet vilkår kan være betaling for servicen. 9

10 Parternes ansvar og samarbejde, herunder om begge myndigheder er dataansvarlige eller om den ene er databehandler på vegne af den anden. Hvis den ene myndighed er databehandler på vegne af den anden myndighed, så er den skriftlige kontrakt et lovkrav jf. personoplysningsloven 42, stk. 2. Der kan være lovgivningsmæssige eller forretningsmæssige forhold der medfører, at serviceudbyderen skal etablere en logning af, hvilke serviceaftagere, der har kaldt servicen, samt hvilke data der er blevet udleveret. Hvis der eksempelvis behandles fortrolige eller følsomme personoplysninger, står der i sikkerhedsbekendtgørelsen, at logning skal ske, se hertil 15, 18 og 19. For en nærmere perspektivering af de lovgivningsmæssige forhold der vil være i forbindelse med anvendelsen af OIOREST henvises til vejledningens afsnit om juridiske forhold. 10

11 Model 2: Systemkald på vegne af bruger > Arkitektur Det andet scenarie er en udvidelse af det første, hvor serviceaftageren foretager et OIOREST servicekald på vegne af en bruger. Det antages, at serviceaftageren udbyder en web applikation (f.eks. en portal), hvor brugeren er logget ind med et OCES person- eller medarbejdercertifikat. Applikationen hos serviceaftageren har på et tidspunkt behov for at kalde en service hos serviceudbyderen det kunne eksempelvis være for at hente data om brugeren i et fremmed system, som skal bruges i applikationen: Figur 2: Scenarie med systemkald på vegne af bruger Servicekaldet adskiller sig i forhold til den første model ved, at man overfører såvel brugerens identitet som serviceaftagerens identitet til serviceudbyderen. Der er således mange lighedspunkter til den første model, og nedenfor fokuseres derfor kun på nye aspekter. Overførsel af brugeridentitet Brugerens identitet overføres fra serviceaftager til serviceudbyder ved at anvende en HTTP header med navnet X-On-Behalf-Of. Det specifikke indhold af headeren specificeres af serviceudbyderen afhængigt af, hvad hans service har brug for at vide om brugeren 5. Oplagte eksempler kan være overførsel af brugernavn, CPR- eller CVR-nummer, PID- eller RID-nummer fra OCES certifikat, Subject serialnumber fra OCES certifikat mv. For indholdet af OCES certifikater henvises til certifikatpolitikkerne [OCES-CP]. Etablering af sikkerhed Sikkerheden består i etablering af to sikre kommunikationskanaler: Mellem brugerens browser og serviceaftagerens web server etableres en SSL session. Brugeren kan blive autentificeret på flere måder: 5 Indholdet skal URL-encodes i UTF-8 (som beskrevet i RFC 2616) for sikre, at specialtegn ikke forvanskes under transport. 11

12 o o Der anvendes klientautentificeret SSL og browseren vil anvende brugerens digitale signatur og OCES certifikat til at etablere forbindelsen med. Der anvendes SSL uden klientautentifikation og brugeren autentificeres efter SSL sessionen er oprettet f.eks. ved at anvende en login applet, der tilgår hans digitale signatur, eller eksempelvis via en fællesoffentlig single sign-on løsning baseret på [OIO-SAML] standarden som NemLog-in eller Virk BRS. Mellem serviceaftager og serviceudbyder etableres en SSL forbindelse på samme måde som beskrevet for den første sikkerhedsmodel. Sikkerhedsmæssige egenskaber Ved anvendelse af ovenstående sikkerhedsmodel opnår man samme sikkerhedsmæssige egenskaber som i model 1 for hver af de to transportkanaler. Bemærk at serviceaftageren står inde for, at den overførte brugeridentitet er korrekt. Eksempelvis kan dette indgå i aftalevilkår for brug af servicen. Serviceudbyderen har således ikke nogen mulighed for at fastslå, om denne er korrekt eller om brugeren virkelig har aktiv browsersession med serviceaftageren eller evt. har afgivet samtykke til kaldet (se nedenfor). Hvis serviceudbyderen skal være sikker på dette, kan man evt. anvende protokoller, hvor serviceaftageren sender brugerens browser forbi serviceudbyderen, så han selv kan indhente samtykke. Denne teknik anvendes bl.a. i OAuth protokollen (se oauth.net). Attributter i fremmede registre Hvis serviceudbyderen har brug for ekstra informationer om brugeren eksempelvis i forbindelse med autorisationsbeslutninger for afvikling af servicekaldet, kan serviceudbyderen vælge at kontakte eksterne attributservices. Som eksempel kan nævnes, at NemLog-in samt Virk.dk s brugerrettighedsløsning tilbyder services, hvormed man kan slå attributter op for en bruger; sidstnævnte giver mulighed for at hente rettigheder for medarbejdere administreret via portalen. Praktiske forhold Ved implementering af ovenstående model er der en række praktiske forhold, man bør overveje (udover dem der allerede er nævnt for den første model): Serviceudbyderen skal specificere det forventede indhold af HTTP headeren, der angiver brugerens identitet. Serviceaftageren skal etablere brugerautentifikation til hans web-applikation med en af de beskrevne mekanismer (klientautentificeret SSL, login applet eller SAML 2.0 baseret SSO løsning). Serviceaftager og serviceudbyder bør overveje at anskaffe et såkaldt Extended Validation 6 SSL certifikat til deres web servere. Disse certifikater kræver en ekstra grundig validering af indehaverens identitet før udstedelse, 6 For detaljer henvises til 12

13 og modparten kan derfor have højere tillid til sådanne certifikater end normale SSL certifikater. Endvidere skal det nævnes, at certifikaterne genkendes af nyere browsere, og at deres tilstedeværelse afspejles i brugeroplevelsen (en grøn adresselinje i browseren), hvilket giver en større tryghed for brugerne. Serviceudbyderen skal afvikle kaldet i kontekst af brugeren, hvilket kan få indflydelse på den måde, adgangskontrollen er indrettet på. I nogle situationer skal servicen blot hente data for den angivne bruger, i andre situationer vil brugerens identitet få indflydelse på, om servicekaldet må udføres eller ej, eller om der er særlige rettigheder forbundet med kaldet. Særlige juridiske overvejelser ved systemkald på vegne af bruger Udover de allerede beskrevne problemstillinger, bør man overveje implikationerne af, at servicekaldet sker på vegne af en bruger. Det kan eksempelvis være relevant at indhente brugerens samtykke til, at servicekaldet udføres (f.eks. at man henter brugerens helbredsoplysninger i et fremmed system). I den forbindelse bør man overveje samtykkets form, virkefelt, og hvordan man senere kan dokumentere, at alle data er hentet på baggrund af specifikke samtykker. Rent praktisk kan man overveje at give brugeren en mulighed for at underskrive en samtykkeerklæring med sin digitale signatur. I den forbindelse er det vigtigt at kommunikere tydeligt, hvilke data, man vil hente i servicekaldet. Derudover bør brugeren til enhver tid kunne vedligeholde sine samtykker i applikationen herunder tilbagekalde samtykker. Et andet aspekt er, hvor meget et samtykke kan dække, f.eks. om der skal gives samtykke ved alle servicekald eller om samtykket kan genbruges. Det kommer an på den konkrete anvendelse af data, hvad der er muligt, og det er væsentligt at skabe en balance imellem brugerens mulighed for hele tiden at kontrollere anvendelsen af data og selve anvendeligheden af applikationen. I forbindelse med overvejelserne omkring indhentelse af samtykke hos borgeren er det væsentligt at gøre klart, om serviceudbyderen eller serviceaftageren er dataansvarlig, idet det er den dataansvarlige, der har pligten til at indhente borgerens samtykke. I situationer hvor serviceaftager indhenter brugerens samtykke til udvekslingen af data, skal serviceudbyder sikre sig, at håndteringen af samtykket sker forsvarligt og opfylder lovgivningen. Se mere om ansvarsfordelingen under afsnittet om juridiske forhold. 13

14 Juridiske forhold > OIOREST giver mulighed for servicekald imellem forskellige offentlige myndigheder over internettet. Dermed opnås nye, fleksible muligheder for betjening af borgere f.eks. ved automatisk indhentning af nødvendige oplysninger i andre myndigheders registre. Med den øgede funktionalitet kommer dog udfordringer i forhold til overholdelse af regler, hvor hver myndighed har et ansvar overfor borgeren. I særligt fokus er personoplysningsloven, men også overholdelse af andre regler kan have betydning, især hvis den ene myndighed opererer under specialregler som det eksempelvis er tilfældet på sundhedsområdet. Regler der er i spil, når man sammenkobler services For at bringe et OIOREST projekt godt fra start er det vigtigt at få sat fokus på, hvilke regler man skal have for øje. Nedenfor er listet de regler, som umiddelbart vil have interesse: Lov / bekendtgørelse Personoplysningsloven. Nr. 429 af 31/ Sikkerhedsbekendtgørelsen Nr. 528 af 15/ Forvaltningsloven Nr af 7/ Lov om elektroniske signaturer Nr. 417 af 31/ Specialregler 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 sygdomsoplysninger. Forkortes POL. Når der udveksles persondata indenfor det offentlige. Bekendtgørelsen uddyber tekniske og administrative krav til personoplysningsloven. Når myndigheden behandler data for borgere. Eksempelvis kan der være forhold at afklare imellem myndighederne vedrørende svarfrister og notatpligt. OIOREST løsningen kan ikke i sig selv fungere som signaturløsning, og der skal derfor kobles et ekstra lag på, hvis man skal anvende løsningen til at modtage et uafviseligt samtykke. Den enkelte myndighed kan være underlagt særlige regler, som kan have betydningen for dataudvekslingen. Som eksempel kan sundhedsområdet nævnes. Personoplysningsloven I det følgende fokuseres på personoplysningsloven i forhold til servicekald, hvor der hentes data fra en myndighed til en anden. Det er vigtigt at huske, at man kan have sikkerhed uden privacy, men man kan ikke have privacy uden sikkerhed. Privacy er således mere end teknisk sikkerhed, fordi der stilles krav til, hvem der må tilgå data og hvordan administrationen skal være. Kravene som stilles afhænger af, hvilke data der udveksles. 14

15 Generelt kan data 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, kan man ud fra den paragraf, data hører under (se tabellen ovenfor) se, hvilke krav der stilles til data og behandlingen heraf. Generelt stilles der krav indenfor følgende 4 hovedområder: Behandlingssikkerhed administration. Den registreredes rettigheder. Anmeldelse. 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 og den påtænkte anvendelse. Scenarie A Der tages i det følgende udgangspunkt i et scenarie, hvor myndighed A kalder en service hos myndighed B for at læse data. Data kopieres ikke over i et særskilt register. Alligevel er det en databehandling, der er omfattet af personoplysningsloven. Kravene, som stilles til behandlingen, vil naturligvis kun rette sig imod datalæsningen. I denne situation er det derfor vigtigt at overveje, om myndighed B må give myndighed A ret til at læse data. Dertil kommer om det kun er bestemte medarbejdere i myndighed A, der skal gives adgang og hvordan der følges op på, at det er de rigtige der rent faktisk gives adgang. I det beskrevne tilfælde er myndighed B dataansvarlig, fordi det er myndighed B, der forvalter data. Som dataansvarlig skal myndighed B sikre, at det er lovligt at lade medarbejderne hos myndighed A tilgå data. Det vil være tilladt at give adgang, hvis det eksempelvis står i en lov, at data skal gives videre. 15

16 Når vi omtaler en videregivelse af data, er det vigtigt at huske, at de informationer data indeholder, bliver givet videre allerede, når en person læser dem. Af denne grund bliver en læseadgang, som gives til en anden myndighed, anset som en videregivelse af data. Myndighed A s rolle som enten databehandler eller dataansvarlig afhænger af, om der er indgået en skriftlig kontrakt der regulerer, hvem der må tilgå data, hvordan data må anvendes, og hvordan sikkerheden skal være hos myndighed A. Kontrakten kan kun indgås for behandlinger, Myndighed B har ret til at foretage. Kravene til udformning af kontrakten findes i personoplysningslovens 42. Eksisterer en sådan kontrakt er myndighed A databehandler på vegne af myndighed B, som er dataansvarlig. I modsat fald er myndighed A også dataansvarlig. Scenarie B Hvis vi tager fat i samme situation som i scenarie A med den ændring, at myndighed A indlæser data i et eget system, så skal myndighed A skal sørge for it-sikkerheden for de data, som ligger i dette system. Om myndighed A bliver dataansvarlig for oplysningerne afhænger som nævnt ovenfor af, om der foreligger en kontrakt med myndighed B, som binder Myndighed A i forhold til anvendelsen af data. Foreligger der ikke en kontrakt, bliver myndighed A dataansvarlig på lige fod med myndighed B, og begge parter skal løfte det ansvar, som påhviler den dataansvarlige efter personoplysningsloven. Det ansvar, som påhviler den dataansvarlige, er blandt andet, at: Sikre, at der er tilladelse til behandlingen af data og eventuelle samtykker er indhentet. Sørge for it-sikkerheden. Sikre, at de rigtige personer har adgang til data. Sikre, at der er historik i forhold til adgangen af data. Foretage de nødvendige anmeldelser til datatilsynet. Udarbejde skriftlige aftaler med databehandlere. Sikre, at borgeren er orienteret om brugen af data. Sikre borgerens ret til at gøre indsigelse imod databehandlingen. Sikre at data er korrekte. Sikre at data bruges til saglige formål. Slette data, når de ikke længere er nødvendige. Kravene, som specifikt skal overholdes, afhænger af datas klassifikation og ganske kort kan følgende overordnede krav nævnes indenfor de 3 kategorier: Konsekvens Følsom Fortrolig Generel Der er et generelt forbud mod at dele data med mindre der er lovhjemmel eller uafviseligt samtykke fra borger. Med uafviseligt menes, at samtykkes skal gives af en borger, der er tydeligt oplyst om formål og anvendelse. Desuden skal samtykket 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 Der stilles ikke så store sikkerhedskrav til generelle persondata. Behandlingen er dog stadig omfattet af personoplysningsloven. 16

17 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. se og rette data skal sikres. Behandlingen skal generelt ikke anmeldes til Datatilsynet. Borgerens ret til eksempelvis at se og rette data skal sikres. Ansvar Såvel serviceaftager som serviceudbyder har ansvar og opgaver, når personoplysningsloven skal overholdes. For at afklare ansvarsforholdet er det nødvendigt at finde ud af, om man er dataansvarlig eller databehandler. Begreberne findes i personoplysningsloven 3 nr. 4 og 5. Den dataansvarlige er den, som kan bestemme, hvordan og hvornår data anvendes. I OIOREST sammenhæng vil dette som udgangspunkt være serviceudbyderen, som har data liggende. Hvis data videregives på en måde, så data kan behandles selvstændigt af serviceaftageren, vil denne også blive dataansvarlig. Gives data derimod til serviceaftager med baggrund i en skriftlig aftale med nøje instruktioner om brug, så vil serviceaftager blive databehandler i stedet for dataansvarlig. Denne model bruges til outsourcing af driftopgaver og dette kaldes efter personoplysningsloven en overladelse. En overladelse er derfor en videregivelse af data, hvor der er en skriftlig kontrakt som sikrer, at databehandleren ikke kan handle frit og hvor den dataansvarlige giver en opgave videre, som denne ellers selv skulle løse. Den dataansvarlige bærer det overordnede ansvar for brugen af oplysningerne, og har kontakten med borgeren. Databehandleren skal overholde kontrakten med den dataansvarlige og sørge, for at sikkerheden er i orden. Kom godt fra start med personoplysningsloven Nedenfor er angivet en lille huskeliste til komme godt fra start, når man skal finde ud, af hvilke krav, der skal opfyldes. Få overblik over hvilke data der deles. Er der personoplysninger? Hvis ikke, så gælder personoplysningsloven ikke. Hvis der er personoplysninger, så skal disse klassificeres, så der er overblik over, om de er generelle, fortrolige eller følsomme. Afklar, hvem der har ansvaret for data og dermed er dataansvarlig. Hvis man er serviceudbyder, er det vigtigt at finde ud af, om man er i gang med at videregive data på en måde så serviceaftager selvstændigt kan anvende data. Hvis ikke skal der laves en skriftlig kontrakt om, hvordan data må bruges. 17

18 Hvis serviceaftager ikke begrænses skriftligt i brugen af data, og der ikke føres kontrol med serviceaftageren, så regnes det som en videregivelse af data, hvor serviceaftager kan anvende data selvstændigt. Tilladelsen til at videregive data skal undersøges er der eksempelvis en lov der siger, at data skal videregives eller har man et skriftligt samtykke fra brugeren? Hvis ikke skal man undersøge, om man på anden måde har ret til at videregive data, Hvis man videregiver data, skal man i de fleste tilfælde have borgerens samtykke. Som tommelfingerregel er det vigtigt at huske, at borgeren skal kunne forstå, hvor data er og hvem han/hun kan henvende sig til for indsigt, rettelser i data m.m. Hvis serviceaftager skal fungere som databehandler på vegne af serviceudbyder, så er det vigtigt, at man husker at udarbejde en skriftlig kontrakt, der tager højde for datasikkerheden. 18

19 Referencer > [OIOREST] [SSL] SSL 3.0 Specification : [TLS] The Transport Layer Security (TLS) Protocol Version 1.2, Internet Engineering Task Force. [OCES-CP] [OIO-SAML] [SIG-BEV] [AUTH-LEV] Signatur- og Systembevis teknisk vejledning i sikring af digitale signaturers bevisværdi, IT- og Telestyrelsen. Vejledning vedrørende niveauer af autenticitetssikring. 19

20

21

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sikkerhed i Stamdatamodulet KOMBIT

Sikkerhed i Stamdatamodulet KOMBIT Sikkerhed i Stamdatamodulet KOMBIT 1 Indholdsfortegnelse 1 Indholdsfortegnelse... 2 2 Historik... 3 3 Oversigt... 4 3.1 Relevante OCES-detaljer... 4 4 Overholdelse af persondatalov mv.... 5 5 Importer...

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

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

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

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

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

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

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

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

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

Regler for NemID til netbank og offentlig digital signatur v5, 1. marts 2017

Regler for NemID til netbank og offentlig digital signatur v5, 1. marts 2017 Regler for NemID til netbank og offentlig digital signatur v5, 1. marts 2017 1 Indledning NemID er en sikkerhedsløsning, du kan bruge til din netbank, offentlige og private hjemmesider. Du kan også bruge

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

Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3

Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3 Notat 21. februar 2017 Den samlede erhvervsløsning i næste generation af NemID og NemLog-in3 Dette notat giver en overordnet konceptuel fremstilling af, hvordan erhvervsområdet forventes håndteret samlet

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

Artikel om... Digital signatur. OpenOffice.org

Artikel om... Digital signatur. OpenOffice.org Artikel om... Digital signatur OpenOffice.org Rettigheder Dette dokument er beskyttet af Copyright 2005 til bidragsyderne, som er oplistet i afsnittet Forfattere. Du kan distribuere og/eller ændre det

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

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

Finanstilsynets indberetningssystem. Vejledning til indsendelse af xml-filer via sikker e- mail (signeret og krypteret e-mail)

Finanstilsynets indberetningssystem. Vejledning til indsendelse af xml-filer via sikker e- mail (signeret og krypteret e-mail) Finanstilsynets indberetningssystem Vejledning til indsendelse af xml-filer via sikker e- mail (signeret og krypteret e-mail) Finanstilsynet - 8. udgave oktober 2009 Indholdsfortegnelse 1 INTRODUKTION...

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

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

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

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

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

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

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

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

(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

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

Vejledning til leverandørers brug af Serviceplatformen

Vejledning til leverandørers brug af Serviceplatformen Vejledning til leverandørers brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange...

Læs mere

DataHub Forbrugeradgangsløsning NemID Quick Guide

DataHub Forbrugeradgangsløsning NemID Quick Guide 20. august 2012 JHH/MEH DataHub Forbrugeradgangsløsning NemID Quick Guide Dok 75936-12_v1, Sag 10/3365 1/6 Indhold 1. NemId/Digital Signatur... 3 2. Tjenesteudbyderaftaler... 3 2.1 Selve aftalen... 3 2.2

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

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09 LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,

Læs mere

Hvad er KRYPTERING? Metoder Der findes to forskellige krypteringsmetoder: Symmetrisk og asymmetrisk (offentlig-nøgle) kryptering.

Hvad er KRYPTERING? Metoder Der findes to forskellige krypteringsmetoder: Symmetrisk og asymmetrisk (offentlig-nøgle) kryptering. Hvad er KRYPTERING? Kryptering er en matematisk teknik. Hvis et dokument er blevet krypteret, vil dokumentet fremstå som en uforståelig blanding af bogstaver og tegn og uvedkommende kan således ikke læses

Læs mere

Introduktion til NemID og Tjenesteudbyderpakken

Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S 11. april

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

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

Digital Signatur Sikker brug af digital signatur

Digital Signatur Sikker brug af digital signatur Digital Signatur IT- og Telestyrelsen December 2002 Resumé Myndigheder, der ønsker at indføre digital signatur, må ikke overse de vigtige interne sikkerhedsspørgsmål, som teknologien rejser. Det er vigtigt,

Læs mere

Vejledning til kommuners brug af Serviceplatformen

Vejledning til kommuners brug af Serviceplatformen Vejledning til kommuners brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange på Serviceplatformen...

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

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

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

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

DanID Certification Practice Statement v. 1.1. DanID. Certification Practice Statement (CPS) V. 1.1

DanID Certification Practice Statement v. 1.1. DanID. Certification Practice Statement (CPS) V. 1.1 DanID Certification Practice Statement (CPS) V. 1.1 februar 2009 1 1 Introduktion 1.1 Oversigt DanID A/S (CVR-nr. 30 80 84 60) er et 100% datterselskab ejet af PBS A/S (CVR-nr. 20 01 61 75). Årsregnskaber

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

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

Termer og begreber i NemID

Termer og begreber i NemID Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Termer og begreber i NemID DanID A/S 26. maj 2014 Side 1-11 Indholdsfortegnelse

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

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

Ny persondataforordning

Ny persondataforordning Ny persondataforordning GUIDE Hvorfor? Ny persondataforordning Den eksisterende persondatalov gennemfører direktiver fra 1995 en tid, som digitaliseringen for længst har overhalet. En ny persondataforordning

Læs mere

Ny digital signatur. IT-arkitekturkonferencen. den 1. april 2009, 11.00. V/ Palle H Sørensen. Centerleder. IT- og Telestyrelsen

Ny digital signatur. IT-arkitekturkonferencen. den 1. april 2009, 11.00. V/ Palle H Sørensen. Centerleder. IT- og Telestyrelsen Ny digital signatur IT-arkitekturkonferencen den 1. april 2009, 11.00 V/ Palle H Sørensen Centerleder IT- og Telestyrelsen Center for Digital Signatur Den nuværende digitale signatur- et godt udgangspunkt

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel Indhold > Indledning 3 Standarder 5 OIOUBL 5 OIO RASP 6 OIO SMI 7 Biblioteker 8 Web applikationer 9 Fakturablanket 9 NemHandel Registrering 9 NemHandel.dk 10 Web services

Læs mere

Vejledning til leverandørers brug af Serviceplatformen

Vejledning til leverandørers brug af Serviceplatformen Vejledning til leverandørers brug af Serviceplatformen Udarbejdet for: KOMBIT A/S Halfdansgade 8 2300 København S 1 Indhold 1 Indledning... 3 2 Ordforklaringer... 3 3 Oprettelse... 4 4 Arbejdsgange...

Læs mere

It-sikkerhedstekst ST8

It-sikkerhedstekst ST8 It-sikkerhedstekst ST8 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST8 Version 1 Maj 2015 Logning

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

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

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

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

Privatlivspolitik. Coverwise Limited deler en forpligtelse til at beskytte dit privatliv og holde dine personlige oplysninger sikre.

Privatlivspolitik. Coverwise Limited deler en forpligtelse til at beskytte dit privatliv og holde dine personlige oplysninger sikre. Privatlivspolitik Denne hjemmeside opererer internationalt og er i overensstemmelse med den lokale lovgivning og regler i de pågældende lande. Denne privatlivspolitik omhandler hvordan vi bruger og behandler

Læs mere

Introduktion til NemID og Tjenesteudbyderpakken

Introduktion til NemID og Tjenesteudbyderpakken Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Introduktion til NemID og Tjenesteudbyderpakken DanID A/S 12. oktober

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

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

Udvidet brug af personligt NemID i erhvervssammenhæng

Udvidet brug af personligt NemID i erhvervssammenhæng Udvidet brug af personligt NemID i erhvervssammenhæng Side 1 af 10 16. juni 2016 TG Baggrund Digitaliseringsstyrelsen planlægger i samarbejde med Erhvervsstyrelsen at gennemføre nogle ændringer i NemLog-in

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

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

It-sikkerhedstekst ST5

It-sikkerhedstekst ST5 It-sikkerhedstekst ST5 Identificering af en fysisk person med henblik på udstedelse af faktorer til et personligt login Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST5 Version

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

It-sikkerhedstekst ST6

It-sikkerhedstekst ST6 It-sikkerhedstekst ST6 Registrering af en fysisk person med henblik på udstedelse af faktorer til et personligt login Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST6 Version

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

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

Anmeldelsesskema for Videnskabelige og statistiske undersøgelser på SDU

Anmeldelsesskema for Videnskabelige og statistiske undersøgelser på SDU Anmeldelsesskema for Videnskabelige og statistiske undersøgelser på SDU Bemærk: Der henvises til vejledningen ved udfyldelsen af nedenstående anmeldelsesskema. 1. Dataansvarlig myndighed Myndighedens navn:

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

Termer og begreber i NemID

Termer og begreber i NemID Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Termer og begreber i NemID DanID A/S 25. oktober 2011 Side 1-10 Indholdsfortegnelse

Læs mere

Retningslinjer for behandling af cookies og personoplysninger

Retningslinjer for behandling af cookies og personoplysninger Gældende fra 27. juni 2017 Retningslinjer for behandling af cookies og personoplysninger MDL ApS ( MDL vi, os, vores ) ved, hvor vigtig fortrolighed er i forhold til vores kunder, og vi bestræber os på

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

Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne

Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne > Sammenhængende log-in - SSO til applikationer i et andet sikkerhedsdomæne IT- & Telestyrelsen, Kontor It-infrastruktur og Implementering februar 2010 Indhold > 1 Introduktion 4 1.1 Føderationsfordele

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

Ny persondataforordning

Ny persondataforordning Ny persondataforordning www.centex.dk Ny persondataforordning Flere virksomheder betragter ikke deres persondata som et must. Det kan være at det ikke er set som et forretningskritisk område, og derfor

Læs mere

Bliv klar til Persondataforordningen

Bliv klar til Persondataforordningen Bliv klar til Persondataforordningen Der indføres væsentlige ændringer og nyskabelser, i forhold til den nuværende persondatalov, der træder i kraft maj 2018. Den nye persondatalov vil i de fleste virksomheder

Læs mere

Nykredit Portefølje Administration A/S

Nykredit Portefølje Administration A/S Nykredit Portefølje Administration A/S Vejledning i oprettelse af brugere til NPA-portal og log ind med nemid medarbejdersignatur version 2.0 januar 2014 Side 1 af 11 Indholdsfortegnelse 1. INTRODUKTION

Læs mere

Webservice kald. System-til-system integration. Ny Easy. ATP 1. februar 2017

Webservice kald. System-til-system integration. Ny Easy. ATP 1. februar 2017 Webservice kald System-til-system integration Ny Easy ATP 1. februar 2017 Side 1 of 9 Dokumenthistorik Revisionshistorik Dato for denne revision: 01.02.2017 Dato for næste revision ukendt Revisions Revisions

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

Version: 1.0 Udarbejdet: Okt. 2013 Udarbejdet af: Erhvervsstyrelsen og Digitaliseringsstyrelsen

Version: 1.0 Udarbejdet: Okt. 2013 Udarbejdet af: Erhvervsstyrelsen og Digitaliseringsstyrelsen Anbefalinger om brug af Digital Post for store virksomheder, administratorer/advokater (fx ejendomsadministratorer) og virksomheder med mange p- enheder Version: 1.0 Udarbejdet: Okt. 2013 Udarbejdet af:

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

Generelt om persondata og EU s persondataforordning

Generelt om persondata og EU s persondataforordning SSV-Udvikling aps 2017 1 Generelt om persondata og EU s persondataforordning Persondata er i Danmark allerede beskyttet af Persondataloven. Her stilles strenge krav til omgangen med persondata, og disse

Læs mere

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365 NemID DataHub adgang morten@signaturgruppen.dk & jakob@signaturgruppen.dk Agenda Funktionaliteten og brugeroplevelsen Arkitekturen og komponenterne bag NemID og digital signatur Datahub token Pause Udvikling

Læs mere