PrENV : Sikkerhet for kommunikasjon i helsevesenet. Del 3 : Sikre datakanaler. Oversatt ved Kompetansesenter for IT i Helsevesenet

Transkript

1 PrENV : Sikkerhet for kommunikasjon i helsevesenet Del 3 : Sikre datakanaler Oversatt ved Kompetansesenter for IT i Helsevesenet

2 Forord Denne Europeiske Prestandard ble forberedt av CEN/TC251 Helseinformatikk under et mandat gitt til CEN av EU-kommisjonen og den europeiske frihandelsorganisasjonen (EFTA). Denne flerdels standarden består av de følgende delene, under den generelle tittelen Sikkerhet for Kommunikasjon i Helsevesenet (SEC-COM): - prenv : Begreper og Terminologi - prenv : Sikre Data Objekter - prenv : Sikre Data Kanaler Denne standarden er designet er utført etter kravene fra Teknisk Rapport CEN/TC251/N Helseinformatikk Rammeverk for sikkerhetsbeskyttelse av kommunikasjon i helsesektoren. Denne standarden ble utformet i henhold til konvensjonene i ISO/IEC direktivet Del 3. Alle annexer er informative. Introduksjon Bruk av dataprosessering og telekommunikasjon i helsesektoren må oppfølges med adekvate sikkerhetstiltak for å sikre datas konfidensialitet og integritet i overensstemmelse med det juridiske rammeverk for å beskytte pasienter så vel som profesjonell ansvarlighet og organisasjonelle verdier. I tillegg er det viktig å ta hensyn til tilgjengelighetsaspekter i flere systemer. Til dette formål har den tredelte Standarden som utgjør SEC-COM-serien (prenv : Konsepter og Terminologi; prenv : Sikre Dataobjekter; prenv : Sikre Datakanaler) til hensikt å forklare og detaljere for sluttbrukere i helsesektoren hvilke alternativer de må håndtere i form av sikkerhetstiltak som kan implementeres for å oppfylle deres sikkerhetsbehov og forpliktelser. Innbefattet i dette er standardiseringen av noen elementer relatert til prosessen med kommunikasjon av informasjon, når de faller innenfor sikkerhetsdomenet. I fortsettelsen av Rammeverk for Sikkerhetsbeskyttelse av kommunikasjon i helsesektoren (CEN/TC251/N98-110), heretter benevnt som Rammeverket, hvis CEN-rapport siktet mot å bidra til en bedre forståelse av sikkerhetsaspekter knyttet til IT-kommunikasjon i helsesektoren, skal denne Europeiske Prestandard hjelpe til å produsere systemer som tillater ansatte og applikasjoner i helsesektoren å kommunisere og samhandle sikkert, og derfor trygt, legitimt, lovlig og presist. SEC-COM-serien av standarder er nøkkelstandarder innen sikker kommunikasjon som kan benyttes generisk på en lang rekke kommunikasjonsprotokoller og informasjonssystemer relevant for helsesektoren, uten å være verken komplette eller uttømmende i denne forstand. Disse standardene må defineres innen sammenhengen og scenariene definert av arbeidsprogrammet til TC251, hvor meldingsparadigmet for samhandling mellom informasjonssystemer er en av de essensielle komponentene, som reflektert av Rammeverket. Sikker Datakanal Denne del 3 av den europeiske prestandard for Sikkerhet for Kommunikasjon i Helsesektoren beskriver hvordan å sikkert kommunisere vilkårlige oktettstrømmer gjennom bruk av kommunikasjonsprotokoll for en sikker datakanal. 1. Denne standarden spesifiserer ikke metoder relatert til tilgjengelighet, lagring eller transportering av nøkkelsertifikater eller andre infrastrukturelle spørsmål, ei heller dekker den aspekter rundt applikasjonssikkerhet slik som brukerautentisering. For denne standardens formål defineres en sikker datakanal som en pålitelig kommunikasjonsprotokoll som implementerer de følgende sikkerhetstjenestene: 1. autentisering av de kommuniserende entiteter før kommunikasjon av annen data finner sted 2. bevaring av dataintegritet 3. bevaring av konfidensialiteten til kommunisert data. En protokoll for sikker datakanal opererer i to distinkte faser, men som kan gjentas: 1999 Copyright reserved to CEN members 2 Ref. No. prenv

3 1. forhandlingsfase: autentisering av de kommuniserende entiteter (f.eks. utveksling av sertifikater), forhandling om chiffersuite, utleding av en delt hemmelighet gjennom en algoritme for nøkkelutveksling 2. kommunikasjonsfase: overføring av brukerdata kryptert i henhold til forhandlet chiffersuite. I tillegg kan hvem som helst av partene stenge datakanalen når den ikke lenger er nødvendig. Konseptet med sikre datakanaler kan best forstås ved å studere deres egenskaper, spesielt sammenlignet med egenskapene til et sikkert dataobjekt. (prenv , del 2 av denne europeiske prestandard): 1. Interaktivitet: forhandlingsfasen lar de kommuniserende entitetene interaktivt bli enige om en chiffersuite som møter begge parters sikkerhetspolicy for det aktuelle kommunikasjonsscenariet (f.eks. nasjonal vs. internasjonal kommunikasjon). Hvis forhandlingen om chiffersuite er mislykket etableres ingen kommunikasjon. 2. Flyktighet: den sikre datakanalen, som en del av en lagdelt kommunikasjonsprotokoll, mottar og leverer usikret brukerdata fra og tilbake til det kallende laget. Den krypterte representasjonen av dataene er midlertidig (f.eks. tilgjengelig kun under overføringen) og utilgjengelig for det kallende laget (f.eks. applikasjon). 3. Ytelse: etter etableringen av chiffersuiten og en delt hemmelighet under forhandlingsfasen er det ikke lenger behov for å benytte de beregningsmessig ressursintensive asymmetriske algoritmene under kommunikasjonsfasen. På den andre siden, pga. flykigheten av den krypterte representasjonen av dataene må kryptering utføres under kommunikasjonsprosessen og kan ikke forhåndsberegnes i frakoblet tilstand. 4. Framlengs hemmelighold: (forward secrecy): kan enkelt implementeres som den av protokollen for nøkkelutveksling. 5. Kompletthet: siden autentiseringen av de kommuniserende entiteter (f.eks. sertifikatutveksling) er en del av protokollen er ytterlig kommunikasjon med tredjepart (f.eks. slå opp sertifikat i en tiltrodd katalog) ikke nødvendig for å benytte den sikre datakanalen om ikke tilbaketrekkingslister benyttes for sertifikatene. 6. Gjennomsiktighet: en sikker datakanal kan implementeres på en slik måte at dens øvre tjenestetilgangspunkter er lik dens lavere tjenestetilgangspunkter (f.eks. TCP/IP socket interface). Dette muliggjør enkel benyttelse av sikkerhetstjenester for eksisterende systemer og protokoller som ikke sikkerhetsbeviste ved å integrere den sikre datakanalen som et ekstra lag i kommunikasjonsprotokollens stakk. Et velkjent eksempel på denne tilnærmingen er Sikker HTTP (HTTP over SSL3). Spesifikasjonen av IETF Transport Layer Security (TLS) er en beskrivelse av hvordan å tilby en sikker datakanal. Selv om TLS er en IETF spesifikasjon er den ikke begrenset til TCP/IP. TLS krever kun tilgang til en pålitelig overføringsprotokoll. Dette betyr at TLS over OSI ville være mulig om ønsket. Denne europeiske prestandard definerer et sett profiler brukt innen TLS for bruk til kommunikasjon innen helsesektoren over sikre datakanaler. 1 Omfang Denne europeiske prestandard spesifiserer tjenester og metoder for å sikre interaktive kommunikasjoner benyttet innen helsesektoren. Interaktive kommunikasjoner defineres for denne standardens formål som scenarier hvor begge systemer er oppkoblet og i bidireksjonal kommunikasjon simultant. Sikring inkluderer i denne europeiske prestandard bevaring av dataintegritet, bevaring av konfidensialitet med hensyn til data som kommuniseres, og ansvarlighet i form av autentisering av en eller begge kommuniserende parter. MERK Eksempler på interaktiv kommunikasjon er nedlasting av HTML innhold over Internet, en DICOM kommunikasjon, eller fjerninnlogging til en datamaskin. 2 Normative referanser Denne europeiske prestandard inneholder ved datert eller udatert referanse bestemmelser fra andre publikasjoner. Disse normative referansene er sitert i teksten og publikasjonene listes her. For daterte referanser gjelder påfølgende endringer eller tillegg til noen av disse publikasjonene for denne europeiske prestandard kun når inntatt ved tillegg eller endring. For udaterte referanser gjelder siste utgave av den refererte publikasjonen. [ISO ] Information processing systems Open Systems Interconnection Basic Reference Model Part 2: Security Architecture 1999 Copyright reserved to CEN members 3 Ref. No. prenv

4 [ISO 8824] [ISO ] [ISO ] [IETF TLS] Information technology - Open Systems Interconnection Specification of Abstract Syntax Notation One (ASN.1) (Version ). Information technology Open Systems Interconnection The Directory: Authentication framework Information technology - Open Systems Interconnection Security frameworks for open systems: Overview. Internet Engineering Task Force: The TLS (Transport Layer Security) Protocol, RFC Definisjoner 4 Symboler og forkortinger 3DES Triple DES CORBA Common Object Request Broker Architecture DES Data Encryption Standard DICOM Digital Imaging and Communications in Medicine HTML HyperText Markup Language HTTP HyperText Transfer Protocol IETF Internet Engineering Task Force IIOP Internet Inter-ORB Protocol MIME Multimedia Internet Message Extensions ORB Object Request Broker PKCS#7 Public Key Cryptography Standard #7 RFC Request For Comment RSA Rivest-Shamir-Adleman SDC Secure Data Channel SMTP Simple Mail Transfer Protocol SSL3 Secure Sockets Layer, version 3 TLS Transport Layer Security UML Unified Modelling Language 5 Krav 5.1 Protokoll for transportlaget Systemer i overensstemmelse med denne europeiske prestandard skal implementere kommunikasjon av helsesektordata i overensstemmelse med spesifikasjonen til IETF Transport Layer Security [IETF-TLS]. 5.2 Obligatorisk chiffersuiter Systemer i overensstemmelse med denne europeiske prestandard skal støtte de følgende chiffersuiter innen TLSprotokollen for å tilby de kryptografiske tjenestene definert i spesifikasjonen av IETF TLS: - TLS-DH-RSA-WITH-3DES-EDE-CBC-SHA1 - TLS-RSA-WITH-3DES-EDE-CBC-SHA1 MERK 1 Disse chiffersuitene tilbyr ikke framlengs hemmelighold MERK 2 Full definisjon av de overnevnte chiffersuitene kan finnes i spesifikasjonen av IETF TLS. 5.3 Andre chiffersuiter Systemer i overensstemmelse med denne europeiske prestandard kan i tillegg støtte den følgende chiffersuiten innen TLS-protokollen for å tilby de kryptografiske tjenestene definert i spesifikasjonen av IETF-TLS: - TLS-DHE-RSA-WITH-3DES-EDE-CBC-SHA Copyright reserved to CEN members 4 Ref. No. prenv

5 Systemer som velger å støtte denne chiffersuiten skal forhandle den med preferanse framfor siffersuitene definert i avsnitt 5.2 MERK 1 Denne chiffersuiten tilbyr framlengs hemmelighold. Se 3.18 framlengs hemmelighold. MERK 2 Framlengs hemmelighold gjør det mer vanskelig for angripere å kompromittere konfidensiell informasjon under overføring i kryptert form, og er derfor sikrere enn bruk av chiffersuiter som ikke støtter framlengs hemmelighold. MERK 3 Noen nasjonale lovgivninger forbyr bruk av framlengs hemmelighold i form av ikke gjenvinnbar kryptering. 5.4 Unngå kryptering utsatt for rå kraft angrep Systemer i overensstemmelse med denne europeiske prestandard skal ikke forhandle chiffersuiter som gir mindre enn 80 bits effektivt nøkkelrom. De skal heller ikke støtte algoritmer for nøkkelutveksling som tilbyr mindre enn 768 bits av RSA eller DH nøkkel asymmetrisk styrke. MERK Nøkkellengder nødvendig for å motvirke rå kraft angrep øker over tid. Kravene i dette avsnittet reflekterer tingenes tilstand i skrivende stund og de effektive nøkkellengder som tilbys av TLS chiffersuitene spesifisert i [IETF-TLS]. 5.5 Andre chiffersuiter Systemer i overensstemmelse med denne europeiske prestandarden kan støtte og forhandle andre chiffersuiter så lenge systemer oppfyller kravene fra avsnitt 5.2 og 5.3 og chiffersuitene oppfyller kravene fra avsnitt Sikkerhetshensyn Systemer i overensstemmelse med denne europeiske prestandarden skal ikke tilby baklengs kompatibilitet med SSL versjon 1 og Autentifisering av klienter Systemer i overensstemmelse med denne europeiske prestandard kan implementere TLS autentifisering av klienter. MERK Selv om det kan være anvendelser av denne europeiske prestandard innen helsesektoren som ikke krever autentifisering av klienter, kan det være ønskelig for enkelte anvendelser Copyright reserved to CEN members 5 Ref. No. prenv