Changes between Version 35 and Version 36 of Archtectural Overview Security
- Timestamp:
- Apr 18, 2008, 10:06:03 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archtectural Overview Security
v35 v36 6 6 7 Security and Confidentiality 7 7 8 == 7.1 要件 == 8 == 7.1 要件 == #requirements 9 9 10 10 7.1 Requirements … … 66 66 The following sections describe support in openEHR for the main security and privacy requirements of EHRs. 67 67 68 == 7.2 セキュリティとプライバシーへの脅威 == 68 == 7.2 セキュリティとプライバシーへの脅威 == #threats 69 69 7.2 Threats to Security and Privacy 70 70 … … 93 93 A 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. 94 94 95 == 7.3 openEHRが提供するソリューション == 95 == 7.3 openEHRが提供するソリューション == #solution 96 96 7.3 Solutions Provided by openEHR 97 97 98 === 7.3.1 概要 === 98 === 7.3.1 概要 === #sol_overview 99 99 7.3.1 Overview 100 100 … … 109 109 [[Image(security2.gif)]] 110 110 111 === 7.3.2 セキュリティ・ポリシー === 111 === 7.3.2 セキュリティ・ポリシー === #policy 112 112 7.3.2 Security Policy 113 113 … … 162 162 A 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. 163 163 164 === 7.3.3 一貫性 === 164 === 7.3.3 一貫性 === #integrity 165 165 7.3.3 Integrity 166 166 … … 185 185 The 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. 186 186 187 === 7.3.4 匿名性 === 187 === 7.3.4 匿名性 === #anonymity 188 188 189 189 7.3.4 Anonymity … … 205 205 This 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. 206 206 207 == 7.4 アクセスコントロール == 207 == 7.4 アクセスコントロール == #control 208 208 209 209 7.4 Access Control
