views:

59

answers:

1

Hello all,

I've been working with a couple different contact management solutions, but my security paranoia prevents me from wanting to put any sensitive data in the cloud. While I'm not dealing with anything like credit transactions that have detailed security requirements, I am considering handling sensitive personal data that I wouldn't want unauthorized people to have access to.

I'm considering a model where there are two systems: one on a Firewalled LAN that contains the sensitive data, which can only be accessed by those on the lan. A second system would contain the non-sensitive (phone book) information subset of the secure system. I would like changes to the non-sensitive data to be synchronized by a connection initiated by the secure system, so as not to compromise the firewall.

I understand that master-slave replication could probably provide synchronization from the secure system to the public system, however this would seem to overwrite any changes made to the public database.

Now to my questions:

1) Does this security model make sense? Are there any downsides or inherent problems with this approach that I might be overlooking?

2) Is there an off-the-shelf or some example of how to implement this type of system?

3) If no, how would you go about implementing this? (language suggestions, synch algorithms, etc)

Assume a LAMPP configuration, with no persistent processes allowed (except for Apache & MySQL) on the public system.

A: 

1) This sounds like it'll end up being a lot of pain. Are you sure you want the public system being able to push changes to the private one?

2) Mysql replication with the public system as the master should do the trick. You'll want to use the --replicate-do-* options to restrict what statements the slave will execute. To avoid breaking replication, you'll need to ensure that any SQL affecting tables you care about doesn't reference tables the slave doesn't know about.

An important part of the concept is that the clients be able to update their own contact information. I'm more likely to hold off putting the sensitive data online than make the public DB read-only.
JeffP