Changes between Version 35 and Version 36 of Archtectural Overview Security


Ignore:
Timestamp:
Apr 18, 2008, 10:06:03 PM (11 years ago)
Author:
KOBAYASHI, Shinji
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Archtectural Overview Security

    v35 v36  
    667 Security and Confidentiality
    77
    8 == 7.1 要件 ==
     8== 7.1 要件 == #requirements
    99
    10107.1 Requirements
     
    6666The following sections describe support in openEHR for the main security and privacy requirements of EHRs.
    6767
    68 == 7.2 セキュリティとプライバシーへの脅威 ==
     68== 7.2 セキュリティとプライバシーへの脅威 == #threats
    69697.2 Threats to Security and Privacy
    7070
     
    9393A key principle with respect to the design of mechanisms supporting security, confidentiality and integrity has to be kept in mind: the likelihood of any given mode of targeted inappropriate access is proportional to the perceived value of the information and inversely proportional to the cost of access. To paraphrase Ross Anderson's BMA paper1 on health data security, for a given access, the perpretrator will try to find the simplest, cheapest and quickest method, which is more likely to be bribery or burglary than James Bond-inspired technology. openEHR makes use of this principle by providing some relatively simple mechanisms that are cheap to implement but can make misuse quite difficult, without compromising availability.
    9494
    95 == 7.3 openEHRが提供するソリューション ==
     95== 7.3 openEHRが提供するソリューション == #solution
    96967.3 Solutions Provided by openEHR
    9797
    98 === 7.3.1 概要 ===
     98=== 7.3.1 概要 === #sol_overview
    99997.3.1 Overview
    100100
     
    109109[[Image(security2.gif)]]
    110110
    111 === 7.3.2 セキュリティ・ポリシー ===
     111=== 7.3.2 セキュリティ・ポリシー === #policy
    1121127.3.2 Security Policy
    113113
     
    162162A key feature of the policy is that it must scale to distributed environments in which health record information is maintained at multiple provider sites visited by the patient.  As Anderson points out in the BMA study, policy elements are also needed for guarding against users gaining access to massive numbers of EHRs, and inferencing attacks. Currently these are outside the scope of openEHR, and realistically, of most EHR implementations of any kind today.  The following sections describe how openEHR supports the first list of policy objectives.
    163163
    164 === 7.3.3 一貫性 ===
     164=== 7.3.3 一貫性 === #integrity
    1651657.3.3 Integrity
    166166
     
    185185The signing of data in a versioning system acts as an integrity check (the digest performs this function), an authentication measure (the signature performs this function), and also a non-repudiation measure. To guard against hacking of the versioned persistence layer itself, signatures can be forwarded to a trusted notarisation service. A fully secure system based on digital signing also requires certified public keys, which may or may not be available in any given environment.  One of the benefits of digitally signing relatively small pieces of the EHR (single Versions) rather than the whole EHR or large sections of it is that the integrity of items is more immune to localised repository corruptions.
    186186
    187 === 7.3.4 匿名性 ===
     187=== 7.3.4 匿名性 === #anonymity
    188188
    1891897.3.4 Anonymity
     
    205205This simple mechanism provides a basic protection against certain kinds of information theft or hacking if used properly. In the most secure situation, a hacker has to steal not just EHR data but also separate demographic records and an identity cross reference database, both of which can be located on different machines (making burglary harder). The identity cross-reference database would be easy to encrypt or protect by other security mechanisms.
    206206
    207 == 7.4 アクセスコントロール ==
     207== 7.4 アクセスコントロール == #control
    208208
    2092097.4 Access Control