gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Approaches to provide adequate security


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Approaches to provide adequate security
Date: Mon, 1 May 2006 23:30:50 +0200
User-agent: Mutt/1.5.11+cvs20060403

On Mon, May 01, 2006 at 01:04:45PM -0700, Jim Busser wrote:

> - 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?
Yes. So "data" better mean "encrypted data".

> - if access to the postgres data is controlled by entries in the  
> pg_hba.conf and pg_ident.conf files,
yes

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

> - are the gnumed databases only as secure as the users' passwords,
if password is the method of authentication, yes

> 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)?
yes and no, esmith may have *limited* read-access so it's
not necessarily the *entire* dataset

> - - is it built-in or easily added to GNUmed to be able to specify  
> minimum requirements for a valid password?
Such would have to be supported by a) the OS for logging on
users and b) PostgreSQL for allowing access. Both can be
setup to use PAM which allows for enforcing minimum
requirements, yes.

> Presumably these are stored encrypted
Depending on how PostgreSQL is set up to do authentication.
GNUmed certainly supports using PostgreSQL's best
authentication - IOW it doesn't care.

> to that while an administrator could over-write a  
> password, they could not know the actual password that had been used?
If the above holds true then yes.

> - 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?
Yes or no. It could, depending on how the dump was taken
(that is, which command line switches were given to
pg_dump).

> - what about dumps? Presumably these are simply structured data,  
> unencrypted, so anyone who gets a hold of a dump could freely extract  
> from it.
yes

> Certainly the personally identifying information could be  
> useful and the linked information reassembled by recreating the  
> database per above.
yes

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

> - 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
sounds reasonable

> PS are these questions too "general purpose" for a gnumed-devel list?  
yes but

> Maybe in a perfect world would be better-suited to a -user list, but  
> OK for now?
yes

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




reply via email to

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