[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Approaches to provide adequate security
From: |
James Busser |
Subject: |
[Gnumed-devel] Approaches to provide adequate security |
Date: |
Mon, 1 May 2006 13:04:45 -0700 |
Locally there have been some lapses in government information
management, e.g. some media (that happened to contain intact health
information) got sold, also there was a break-in at a local public
health office and its computer (which contained a database) was
stolen. Which reminded me to clarify:
- if a server that is hosting gnumed's postgres databases is taken
into a computer shop for service, and the server's hard drive(s) are
booted from another system on which the user has root access, will
that root access grant them permission to all of the the drive's data?
- if access to the postgres data is controlled by entries in the
pg_hba.conf and pg_ident.conf files, and if their entries are
modifiable per above (or if the user can just install their own copy
of postgres and configure it as they like), would that provide a
means to defeat any userids and passwords that had been created for
the gnumed databases?
- are the gnumed databases only as secure as the users' passwords,
and so that if it is known that doctor edgar smith is a member of a
surgery/practice and it is guessed that configured into gnumed might
be a userid esmith does read-access to the entire data set depend on
esmith having created an adequately strong password (not esmith)?
- - is it built-in or easily added to GNUmed to be able to specify
minimum requirements for a valid password? Presumably these are
stored encrypted to that while an administrator could over-write a
password, they could not know the actual password that had been used?
- if a backup dump were used to recreate a GNUmed database, would the
dumps contain userids and encrypted password values and would these
credentials (and the associated security) be restored as part of
getting the database back up?
- what about dumps? Presumably these are simply structured data,
unencrypted, so anyone who gets a hold of a dump could freely extract
from it. Certainly the personally identifying information could be
useful and the linked information reassembled by recreating the
database per above. Thus, prior burning dump files to disk, each dump
file should be encrypted, presumably using a special key for this
purpose, and using it consistently so that the poor people who must
legitimately restore from backup can do so?
- how should subscribers to gnotary coordinate their processes? They
should presumably
- - write the dump into a backup directory
- - hash the dump and write a copy of the hash (maybe in the backup
directory?)
- - send the hash to gnotary
- - save into the backup directory a copy of the returned, signed,
timestamped message
- - encrypt the dump
- - burn backup directory contents to CD
(or two CDs if duplicate copies are meant to be kept)
- - clear out (or nest more deeply) the contents of the backup directory
PS are these questions too "general purpose" for a gnumed-devel list?
Maybe in a perfect world would be better-suited to a -user list, but
OK for now?
- [Gnumed-devel] Approaches to provide adequate security,
James Busser <=