Proposal of Security Sharing Cross-Enterprises

ovenforksqueeΑσφάλεια

3 Νοε 2013 (πριν από 3 χρόνια και 11 μήνες)

55 εμφανίσεις

Proposal of
Security
S
haring

Cross
-
E
nterprises

1.

Introduction of IHE Security and Privacy Profiles

Inte
gration the Healthcare Enterprise

(IHE) has developed a number of profiles that address
security an
d patient privacy requirements
, including
authentication, authorization and audit.



Enterprise User Authentication Profile (EUA)


This profile leverages
kerberos

and the HL7
CCOW standard to authenticate users within a single enterprise governed by a single security
policy.

The

authenticated user can use all devices and software with one name.




Audit Trail and Node Authentication Profile (ATNA)


This
profile requires the use of
bi
-
directional certificated
-
based node authentication for connections
between

nodes both
within enter
prise and cross enterprise.
Audit messages are recorded in local audit repository.



Cross Enterprise User Assertion Integration Profile (XUA)



In cross
domain

environment,
each domain may
choose

to have his own user directory with unique method of
authenticating users (EUA). This profile leverages Web
-
Security and SAML 2.0 to support
identity federation.
It provides mechanism to exchange authenticated subject information
across domain boundaries.



Basic Patient Privacy Consents Integration Profile (
BPPC
)



This profile provide a way to
express allowances or restrictions on healthcare data access because of the patients own
wishes when sharing patient

s documents.

Depending on above existing integra
tion profiles, IHE provides a white paper on the topic of
access controls
, which proposes a trusted model
where

each local domain is responsible for
ensuring that personal health information is
adequately

protected.


2.

Architecture

of IHE Authentication, Aut
horization and Audit

Through
studying IHE
security

and privacy profiles and access co
ntrol white paper, we
summarize

the architecture about security sharing of healthcare information cross
-
domains as Figure 1.


Figure 1.

Architecture of security sharing cross domains proposed by IHE

The processes of accessing resource owned by domain B from the client of domain A are
described as below:

1)

Client enters a context by starting a session of client application.

2)

Client provides
user name and password and such information is authenticated by Kerberos
Authentication Server.

After being authenticated, the client
obtains

a service ticket which is
used as part of the Kerberized communication.

3)

The event of authentication successful or

failed is recorded in local Audit Repository.


4)

The subject domain hosts the identity provider (Security Token Service, STS) which is
responsible for identi
fying an authenticating subject

by their claims, and encapsulating the
respective assertions such th
at other STS can validate them.
For example, the subject

s
identifier and authenticating credential is transmitted to subject domain. If the user

s
credential

is
verified

successfully, a cross
-
enterprise user assertion is issued. This assertion
states the
successful authentication of the user and contains further attributes on
roles

and
organizational membershi
ps.


5)

Client
-
side access control policy is enforced.

6)

Client
-
side
access denies

is recorded in local Audit Repository.

7)

Send access request to resource
domain.

8)

Validate Security Token.

9)

Privacy
consent

polices are checked by
identifying

authorized
identities

(
individuals,
organizations, groups
).

10)

Access denies
because

of consent policy is recorded in local Audit Repository.

11)

Resource
-
side access control
policy is enforced.

12)

Access denies is recorded in local Audit Repository.

13)

Return Resource to client.

3.

Problem
s

Specified in our Project

According to
our project overview, a key challenge with this trusted model showed in Figure 1 is
the lack of federated
capabilities:



Red block
-

Access control rules are local to each system. This means that consistency of
access rules across all systems has to be managed
manually
.



Blue block
-

Patient
consent directives and their impact on access control are not
communica
ted electronically
or

automatically to each system.



Yellow block
-

User
authentication

is local to each system.

This impose
s

a significant
administrative burden to ensure that persons are uniformly identified in each system.



Green block


Access to data is

audited in each system. This imposes a significant
administrative burden to investigate inappropriate access or to monitor security breaches.

Solution for solving the problems
is to
move from trusted security model to an i
ntegrated common
security model (
HIAL). However, PACS don

t provide any external
interface that allows

systems
to interact with or impose on the PACS any form of authentication, authorization and audit.
Furthermore, PACS vendors are very slow to change their products. As such, innovative
solutions
are required that integrate into the PACS workflow and achieve desired level of security.

4.

Proposed Architecture to Tackle above Problems

We want to apply generic service representative
technology

and database replication technology
to
our new
architecture

to get such benefits:



A generic agent/adapter is pre
-
installed in PACS workstations.
PACS client application, both
desktop app and browser app, need little changes. Client app has to implement a
communication layer to send request to agent and

receive response from agent.



HIAL common services, such as authentication
service, access control service and

consent

directive management service are

modeled as task services
. Generic agent is trained by the
triple
<Model,
Knowledge
, Data>
.

Then agent i
s able to guide client app to do authentication
and authorization aga
inst the common infrastructure.



Since each vendor PACS has its own requirements for security and privacy,
variable profiles
are supported.



If PACS vendor wants to
maintain

IHE
trusted

model for access control, polices and consent
directives stored in Provincial Repository can be updated to local PACS
domain

through
agent.



Real
-
time
data replication
technology

for
heterogeneous

databases
, like Oracle GoldenGate,
is beneficial to audit relevant PACS activities in
Provincial

Audit Repository.


Figure 2
.
Integration PACS to Common Infrastructure


As shown in Figure 2, a pre
-
installed agent is employed

when client
enters a context by starting a
session of client
application.

The agent asks for <Model,
Knowledge
, Data> from HIAL.



Model
specifies

processes of task logic. For example,
HIAL authentication service
is

based
on OpenID,
and then

the model is OpenID workflow for client site.



Knowledge provides required rul
es and actions. Take
common
access control service as an
example,
knowledge

specify what to do if access denied.



Data represents
business data consumed by rules and actions. Take IHE access control as an
example, policy and consent directives can be update
d to local domain.

5.

Verify proposed architecture achieves the desired level of security (TBD)