[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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]