forked from hl7-fhir/fhir-dstu1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsecurity.html
263 lines (230 loc) · 13.5 KB
/
security.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
<!DOCTYPE HTML>
[%settitle Security%]
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
[%file newheader%]
</head>
<body>
[%file newnavbar%]
<div class="col-9">
<h1>FHIR Security</h1>
<p>
Fast Healthcare Interoperability Resources (FHIR) is not a security protocol, nor does it define any security
related functionality. However FHIR does define exchange protocols and content models that need to be used
with various security protocols defined elsewhere. This section gathers all information about security
in one section. A summary:
</p>
<ul class="dense">
<li>Communications Security - all exchange of production data should be secured using TLS/SSL (e.g. https)</li>
<li>Authentication - Users/Clients may be authenticated in any way desired. For web-centric use, OAuth is recommended</li>
<li>Authorization/Access Control - FHIR defines a Security Label infrastructure to support access control management. FHIR may also define a set of resources to administer access control management, but does not define any at present</li>
<li>Audit - FHIR defines <a href="provenance.html">provenance</a> and <a href="securityevent.html">security event</a> resources suitable for tracking the origins, authorship, history, status and access of resources</li>
<li>Digital Signatures - FHIR includes several specifically reserved locations for digital signatures</li>
<li>Attachments - FHIR allows for binary resources and attachments. These have their own concerns</li>
<li><a href="security-labels.html">Labels</a> - FHIR allows for set of security related tags that affect that way resources are handled</li>
<li>Data Management Policies - FHIR defines a set of capabilities to support data exchange.
Not all the capabilities that FHIR enables may be appropriate or legal for use in some combinations of context and jurisdiction (e.g. HIPAA for exchange between institutions).
It is the responsibility of implementers to ensure that relevant regulations and other requirements are met</li>
<li>Narrative - Care must be taken when displaying the narrative from FHIR resources</li>
</ul>
<p>
Time critical concerns regarding security flaws in the FHIR specification should be addressed to
the <a href="http://wiki.hl7.org/index.php?title=FHIR_email_list_subscription_instructions">FHIR email
list</a> for prompt consideration. Alternatively, issues can be raised through the
<a href="http://wiki.hl7.org/index.php?title=FHIR_Security_Page">community input</a> mechanism.
</p>
<p>
Implementers should track the developing IHE IUA Profile for additional security considerations.
</p>
<p>
A production FHIR system will need some kind of security sub-system that administers
users, user authentication and user-authorization. Where this sub-system fits into the
deployment architecture is a matter for system design:
</p>
<table class="dense">
<tr>
<td valign="center">
<img height="263" width="358" src="security-layout.png"/>
</td>
<td> </td>
<td valign="center" style="border-left: 1px solid grey">
<table class="dense">
<tr><td><img height="32" width="32" src="security-icon-user.png"/></td><td>The consumer that is using a healthcare related system</td></tr>
<tr><td><img height="32" width="32" src="security-icon-app.png"/></td><td>The client application the user is using (application, mobile app, website, etc.)</td></tr>
<tr><td><img height="32" width="32" src="security-icon-sec.png"/></td><td>The security system (authentication and access control)</td></tr>
<tr><td><img height="32" width="32" src="security-icon-fhir.png"/></td><td>The clinical/healthcare repository</td></tr>
</table>
</td></tr></table>
<p>
In this diagram, the red lines represent FHIR interfaces. From the perspective of the FHIR API,
the client (consumer of FHIR services) may either interact with a security system that manifests
as a FHIR server, and which depends on a subsequent FHIR interface to provide the actual storage,
or either the client or server interacts with the security system independently. In each of these
3 scenarios, the different components may be assembled into applications or network components
differently, but the same logical layout applies. The FHIR specification assumes that a security
system exists, and that it may be deployed in front of or behind the FHIR API.
</p>
<a name="access-control"> </a>
<p>
The security system includes the following subsystems:
</p>
<ul>
<li>Authentication: Identifies and Authenticates the user</li>
<li>Access Control decision engine: decides whether FHIR operations are allowed</li>
<li>Audit Log: records actions to allow for subsequent review and detection of intrusion or inappropriate usage</li>
</ul>
<p>
Because there are a plethora of standards relating to
the administration and functionality of the security system, FHIR does not provide user,
profile, or other such administration resources. Instead, the FHIR resources are the targets
of the policies expressed in these other approaches. What FHIR does specify is a way to apply
<a href="security-labels.html">security labels</a> to resources so that a security system may use these (along with the contents
of the resources if appropriate) to determine whether a user is authorized to perform a
particular FHIR operation or not.
</p>
<!--
These HTTP calls may be authenticated against a single user account (including
using <a href="http://www.oauth.org">OAuth</a>), but this arrangement doesn't cater for common transaction metadata such as multiple users,
responsible party, reasons, consents, etc. that are commonly encountered in healthcare. Instead,
use of this RESTful implementation assumes that appropriate security and logs are managed by the client (perhaps
through using <a href="http://wiki.ihe.net/index.php?title=Audit_Trail_and_Node_Authentication">ATNA</a>), and
that the server trusts the client to maintain these. One implication is that this RESTful framework is
only suitable for use where such trust relationships exist (e.g. in a single institution) and is not
suitable where such trust does not exist (e.g. state & national EHR systems and health record
systems that support disparate systems). Similarly, this simple RESTful interface has no support for
explicit archiving and similar functions. Use-cases where these kind of features are required should
consider a <a href="messaging.html">messaging</a> or <a href="implementation.html#SOA">SOA-based approach</a> or
some other kind of profiled REST interface.
-->
<a name="http"> </a>
<h2>
Communications
</h2>
<p>
For the <a href="http.html">RESTful API</a>, normal HTTP security rules apply.
The <a href="http.html#root">Service Root URL</a> will specify whether SSL is required.
Client authentication may be required by the server, possibly including the requirement for
client certificates.
</p>
<p>
SSL SHOULD be used for all production data exchange.
</p>
<p>
To support browser-based client applications, recommend that servers SHOULD implement <a href="http://enable-cors.org/">cross-origin resource sharing</a> for the <a href="http.html">REST operations</a>.
</p>
<a name="authentication"> </a>
<h2>Authentication</h2>
<p>
Other than testing systems, FHIR servers should authenticate the clients.
The server may choose to authenticate the client system and trust it, or to authenticate
the individual user by a variety of techniques. For web-centric use,
<a href="http://oauth.net/">OAuth</a> may be used to authenticate and/or authorize
the users.
</p>
<!-- note about using OAuth and delegating user authority -->
<a name="binding"> </a>
<h2>
Authorization/Access Control
</h2>
<p>
Correctly identifying people, devices, locations and organizations is one of the foundations that any security system is built on.
Most applications of security protocols, whether authentication, access control, digital signatures, etc. rely on the correct mapping between
the relevant resources and the underlying systems. Note that this isn't necessary: there is nothing in FHIR that requires or relies
on any security being in place, or any particular implementation. But real world usage will generally require this.
</p>
<p>
A holder of data should not allow the data to be communicated unless there is assurances that the
other party is authorized to receive it. This is true for a Client creating a resource through a PUT/POST,
as much as it is true for a Server returning resources on a GET. The presumption is that without
proper authorization, to the satisfaction of the data holder, the data does not get communicated.
</p>
<p>
The rules behind the Access Control decision are often very complex, and potentially depends on information sourced from:
</p>
<ul>
<li>Client, such as User Identity, User Role, Location, level of assurance</li>
<li>Resource, such as confidentiality, sensitivity, type of data, date ranges covered by the data, author of the data</li>
<li>Patient, such as the patient identity, patient relationship to the user, patient consent policies</li>
<li>Context of the transaction, system identity, time-of-day, purpose of use, workflow state, and transport security</li>
</ul>
<!-- HL7 has papers on this topic. -->
<p>For one source of further information, see the
<a href="http://www.ihe.net/Technical_Framework/upload/IHE_ITI_TF_WhitePaper_AccessControl_2009-09-28.pdf">IHE Access Control white paper</a>
</p>
<a name="audit"> </a>
<h2>Audit Logging</h2>
<p>
FHIR provides a <a href="securityevent.html">SecurityEvent</a> resource suitable for use by
FHIR clients and servers to record when a security or privacy relevant event has occurred.
This form of audit logging records as much detail as reasonable at the time the event happened.
</p>
<p>
The SecurityEvent when used to record security and privacy relevant events can then be
used by properly authorized applications to support audit reporting, alerting, filtering,
and forwarding. This model has been developed and used in healthcare for a decade as
<a href="http://wiki.ihe.net/index.php?title=Audit_Trail_and_Node_Authentication">IHE-ATNA profile</a>.
ATNA log events can be automatically converted to SecurityEvent resources, and from there,
client applications are able to search the security events, or subscribe to them.
</p>
<a name="signatures"> </a>
<h2>
Digital Signatures
</h2>
<p>
This specification recommends the use of <a href="http://www.w3.org/TR/xmldsig-core/">W3C Digital Signatures</a> for signatures.
</p>
<p>
Resources can be signed using the <a href="provenance.html">Provenance</a> resource to carry a
<a href="http://www.w3.org/TR/xmldsig-core/#def-SignatureDetached">detached digital signature</a>
for the purpose of detecting subsequent changes to the resource. This signature is not
suitable for non-repudiation purposes.
</p>
<p>
In addition, <a href="documents.html#signatures">documents may be signed</a> using an
<a href="http://www.w3.org/TR/xmldsig-core/#def-SignatureEnveloped">enveloped</a>
signature.
</p>
<p>
Neither of these definitions prohibits the use of other ways of using digital signatures.
</p>
<a name="dstu"> </a>
<blockquote>
<p>
DSTU Note: Additional work is anticipated in this area, including alignment with the <a href="http://wiki.ihe.net/index.php?title=Document_Digital_Signature">IHE DSG profile</a>.
</p>
</blockquote>
<a name="attachments"> </a>
<h2>Attachments</h2>
<p>
Several FHIR resources include attachments. Attachments can either be references to content found elsewhere, or included inline encoded in base64.
Attachments represent security risks in a way that FHIR resources do not, since some attachments contain executable code. Implementers should
always use caution when handling resources.
</p>
<a name="labels"> </a>
<h2>Security Labels</h2>
<p>
See <a href="security-labels.html">Security Labels</a>.
</p>
<a name="narrative"> </a>
<h2>Narrative</h2>
<p>
FHIR resources include an XHTML narrative, so that applications can display the contents of the resource to users
without having to fully and correctly process the data in the resource. However displaying HTML is associated
with several known security issues that have been observed in production systems in other contexts (e.g.
<a href="http://wiki.hl7.org/index.php?title=CDA_Security_Issue_Description">with CDA</a>). For
this reason, the <a href="narrative.html#security">FHIR narrative is not allowed to contain active content</a>.
However, care is still needed when displaying the narrative:
</p>
<ul>
<li>Validate the narrative (the standard FHIR schemas do not allow active content, and the reference implementations won't handle it). Note, though, that external references could still be included in CSS, and these are outside the scope of schemas and reference implementations.</li>
<li>Ensure that any external references to images or anchors (e.g. outside the resource) do not cause the display software to <a href="http://wiki.hl7.org/index.php?title=CDA_Security_Issue_Description">leak sensitive information in headers</a></li>
<li>Do not allow external links to run in a privileged context such as the EHR unless you are sure they can be trusted</li>
</ul>
<p>
Also note that the inclusion of an external reference to an image can allow the server that hosts the image to track
when the resource is displayed. This may be a feature or a problem depending on the context.
</p>
</div>
[%file newfooter%]
</body>
</html>