[Gnumed-devel] Approaches to provide adequate security

[James Busser]

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?