Re: [Gnumed-devel] Managing users: restricting access within GNUmed

[Karsten Hilbert]

On Mon, Aug 03, 2009 at 07:27:32PM -0700, Jim Busser wrote:

> To the best of my knowledge we have still to this point deployed
> only one level of care team (named gm-doctors) for all patients. The
> intention. as we are able, is to introduce fine-grained access
> control for arbitrarily defined care teams, as per
> 
>       http://wiki.gnumed.de/bin/view/Gnumed/ManagingUsers
> 
> While client version 0.5 is essentially frozen, Karsten might give
> an opinion whether it can be in 0.6 that we can implement a basic
> restriction of desk staff to things like

That is a lot of work, I assume.

> I did notice in the bootstrapper some groups getting defined (in
> monolithic) as
>       gm-logins
>       gm-doctors
>       gm-staff_medical
>       gm-staff_office
>       gm-trainees_medical
>       gm-trainees_office
>       gm-public
> 
> but am not sure whether the above are values that constitute
> "dem.staff_role"

No. They are database-level groups.

> and whether the database already supports more than
> one role per individual.

There currently is neither proper restriction nor proper
support.

Regarding ways of controlling access - beyond not giving
your cleaning staff a GNUmed-capable login to your systems I
don't believe in application-side access controls being of
any real value.

OS/machine-level: fine, this will keep people from at all
using your systems for compromise

In-application: useless, people will simply use another
application (pgAdminIII or psql) to access the data

Any meaningful access restrictions need to be done at the
lowest possible level - which is the database in the case of
GNUmed.

Essentially, there's two types of access control involved here:

1) access to *types* of data

Here it may initially be sufficient to split people in two
main groups:

clerical - non-clinical data only
clinical - all data

Later people may argue that a third group is needed:

billing - billing data

In that case "clerical" would be split in people having
access to billing data and those that do not.

One main characteristic of this splitting in terms of
database design really should be that access control applies
to "which database/schema/table/view/column" - IOW "which
database meta objects" - are accessible.

This is probably "fairly" easy to accomplish, especially
since PostgreSQL 8.4 now offers column level access control.
The path to enabling this type of access control would be to

a) enable GNUmed to create clerical and clinical users
   (currently all users are clinically enabled)

b) withdraw access to the schemata blobs. and clin. from
   clerical users

        - then see what happens
        - re-design the schemata to conform to this split
        - likely this will not be entirely possible

c) re-grant access to some tables in clin. and blobs. to clerical

        - some re-organization of tables may be needed
        - find out which columns of those tables are actually
          needed by analyzing the queries

d) withdraw table access from clerical and grant column access

        - this may require some query rewriting

Note that this approach will make PostgreSQL 8.4 a
requirement for GNUmed. An alternative would be to use views
which list the specified columns only and only grant access
to those views -- which is what veil does:

        http://veil.projects.postgresql.org/curdocs/main.html

Implementing this would, however, be a lot of work for what
PG 8.4 already offers natively. It can be a lot more
flexible though.



2) access to data *content* regardless of type

This much more relates to the traditional patient-doctor
confidentiality. It also needs to be done at the database
level but the suitable means are different. Here we need to
restrict access to rows *within* columns. As this depends on
the needs of each and every application PostgreSQL does not
offer any specific tools.

PostgreSQL does, however, offer generic tools to help solve
this. Usually it is done by using views and filtering rows
from the table into that based on the current user.

In GNUmed we'd have to make it a bit smarter: Restriction
shouldn't occur to a particular user but rather to a
to-be-defined care team. Such care teams need to be able to
be dynamic: Doctors may cover for each other. Today nurse A
will work with doctor X while tomorrow it will be nurse B.
Basically it would mean that a care team is "headed" by one
or temporarily potentially several doctors. Nurses and
possibly other clinical staff will need to be able to "sign
into" the care team on an as-needed basis -- perhaps
per-shift or some such.

This shouldn't really affect the GNUmed middleware all that
much in terms of SQL because the business logic views which
is being accessed by that would sit atop the access control
views. IOW, the access control views would sit between, say,
clin.test_result and clin.v_test_results.

This will be a lot of work as well and it won't be as easy
and clear-cut as it may sound, but there isn't really any
other sensible way (that I can see). Fortunately, the GNUmed
design affords such a change or at least I cannot see any
existing design decision making this impossible ;-)




As a stop-gab measure, however, we *can* put some controls
into the application -- but we shouldn't kid ourselves that
that really makes any security difference -- it'd fool quite
a few auditors, though ;-)


> We did foresee the need, and therefore already modified the table
> clin.health_issue to support boolean
> 
>       is_confidential

This is mainly intended (by way of Richard's original
design) to be used to prevent leakage to outside the
practice via exclusion from auto-generated letters or form
content. It wasn't intended to be used to "shield"
everything below it.

> I am now wondering whether we should likewise extend is_confidential
> into clin.episode, whereby an enclosing "health issue" by takes on
> the confidentiality level of the episode.

While I see the motivation this would just be a ad-hoc
measure and not really a solution.

> While I know that some may say "oh, is that not a lot of bother?" I
> have been doing a lot of privacy work and I think such capacities
> are both essential and would (eventually) make GNUmed a lot better
> than some of the stuff that is out there.

It would and I am all for implementing such measures but
it's a long and tedious journey, not to speak of difficult.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346