Changes between Version 14 and Version 15 of Archtectural Overview Security
- Timestamp:
- Feb 10, 2008, 7:26:10 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Archtectural Overview Security
v14 v15 89 89 * failures in software (due to bugs, incorrect configuration, interoperability failures etc.) causing corruption to data, or incorrect display or computation, resulting in clinical errors. 90 90 91 セキュリティ、機密保護、及び整合性をサポートするメカニズムを設計することに関する主要原則は、 ぜひ銘記いただきたいのだが、方式の如何によらず標的とされた不適切アクセスの発生可能性は、情報の見積られた価値に比例し、アクセスのためのコストに反比例するということである。ヘルス・データ・セキュリティに関するRoss Andersonの英国医師協会誌[[FootNote(see e.g. Ross Anderson - "Security in Clinical Information Systems" available at http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html.)]] 記事に倣うならば、あるアクセスを想定した場合、犯人は最も単純で安上がりですばやい方法を見つけ出そうとするものである。それは、ジェームズ・ボンドに触発されたテクノロジーよりも、贈収賄や強盗の手口に近い。openEHRは、実装するのは安価であるが、悪用は極めて難しく、可用性について妥協のない、比較的単純なメカニズムを提供することによって、この原則を実用に供する。91 セキュリティ、機密保護、及び整合性をサポートするメカニズムを設計することに関する主要原則は、方式の如何によらず標的とされた不適切アクセスの発生可能性は、情報の見積られた価値に比例し、アクセスのためのコストに反比例するということを忘れてはなならない。ヘルス・データ・セキュリティに関するRoss Andersonの英国医師協会誌[[FootNote(see e.g. Ross Anderson - "Security in Clinical Information Systems" available at http://www.cl.cam.ac.uk/users/rja14/policy11/policy11.html.)]] 記事に倣うならば、あるアクセスを想定した場合、犯人は最も単純で安上がりですばやい方法を見つけ出そうとするものである。それは、ジェームズ・ボンドに触発されたテクノロジーよりも、贈収賄や強盗の手口に近い。openEHRは、実装するのは安価であるが、悪用は極めて難しく、可用性について妥協のない、比較的単純なメカニズムを提供することによって、この原則を実用に供する。 92 92 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. … … 103 103 Many of the concrete mechanisms relating to security and privacy are found in system deployments rather than in models such as openEHR, particularly the implementation of authentication, access control, and encryption. The openEHR specifications and core component implementations do not explicitly define many concrete mechanisms since there is great variability in the requirements of different sites - secure LAN deployments many require minimal security inside, whereas web-accessible health record servers are likely to have quite different requirements. What openEHR does is to support some of the key requirements in a flexible enough way that deployments with substantially different requirements and configurations can nevertheless implement the basic principles in a standard way. 104 104 105 図21は、openEHRのアーキテクチャーによって直接仕様化された主要なセキュリティ手段を示している。ここには、EHRとデモグラフィックの分離、 及びEHR全体に対するアクセス制御オブジェクトが含まれる。バージョン付きオブジェクトのレベルでは、コミット・オーディット（必須）、電子署名及びハッシュが利用可能である。以下のセクションで、これらの機構についてより詳細に記述する。105 図21は、openEHRのアーキテクチャーによって直接仕様化された主要なセキュリティ手段を示している。ここには、EHRとデモグラフィックの分離、およびEHR全体に対するアクセス制御オブジェクトが含まれる。バージョン付きオブジェクトのレベルでは、コミット・オーディット（必須）、電子署名及びハッシュが利用可能である。以下のセクションで、これらの機構についてより詳細に記述する。 106 106 107 107 FIGURE 21 illustrates the main security measures directly specified by the openEHR architecture. These include EHR/demographic separation and an EHR-wide access control object. At the level of versioned objects, commit audits (mandatory), digital signatures and hashes are available. The following subsections describe these features in more detail. … … 140 140 * Usability: The general mentality of access control setting is one of "sensible defaults" that work for most of the information in the EHR, most of the time. The defaults for the EHR can be set by the patient, defining access control behaviour for the majority of access decisions. Exceptions to the default policy are then added. This approach minimises the need to think about the security of every item in the EHR individually. 141 141 142 その他の最小限のEHRデプロイでも実装されるべきであり，openEHRのみの特色ではないセキュリティーポリシー原則について以下に示す。 143 142 144 Other security policy principles that should be implemented in even a minimal EHR deployment but are not directly specified by openEHR include the following. 145 146 * アクセスログ: アプリケーションユーザーがEHRのデータを読み出したという記録はEHRシステムにログとして残されるべきである。現在のopenEHRではそのようなログに関するモデルの仕様を定めてはいないが将来的には策定するであろう。ユーザーにアクセスログが記録亜sれテイルという事実を知らせることによって，（特に他のアクセス制御が実装されていなくても)不適切なアクセスを抑制する効果があるという研究がある。読み出すためにアクセスしたという記録をログとして残すことがEHRの適切な構成要素の一つであるとすることに山道するものもいる。現在のopenEHRはこのアプローチに対してサポートしていない。 143 147 144 148 * Access logging: read accesses by application users to EHR data should be logged in the EHR system. Currently openEHR does not specify models of such logs, but might do so in the future. Studies have shown that making users aware of the fact of access logging is an effective deterrent to inappropriate access (especially where other controls are not implemented). There are some proponents of the argument that even read-access logs should be made part of the content of the EHR proper; currently openEHR does not support this approach.
