From: gordonb.zirtz@... (Gordon Burditt) Date: 2004-07-10T05:12:31+09:00 Subject: Re: Secure Database Systems >I was wondering if it is possible to create a secure database system >using RDBMS(MySQL, Oracle, SQL*Server, PostgreSQL etc) and web >scripting/programming language(Perl, PHP, Ruby, Java, ASP, etc) combination? It depends on how you define 'secure' and what your security policy is. For example, MySQL allows database connections to be encrypted with SSL. I suspect that some of the others do also. Also, most web servers can be set up in a configuration that supports https. And pretty much every web browser supports https. >I have the following in mind: > >I wanted to store all my( and my brothers and sisters) important >document >information such as birth certificate, SSN, passport number, travel >documents, insurance(car, home, etc) document, and other important >documents >imagined in the database. Why is this not several SEPARATE databases? >The data will be entered either manually and/or scanned(with OCR). I >need to >be able to search on all the fields in the database. Do you actually have a program that does decent OCR of handwriting, starting from images? It would be useful to be able to take a bunch of scanned cancelled checks and search for, say, "Auto insurance" (a comment I'd probably write on the memo line of the check). It is very difficult to get anything useful out of searching images stored as binary blobs in a database table. >We have 10 computers(5bros, 4sisters, and myself) plus 1 server with I >maintained. The data should be synchronize/replicate between those >computers. MySQL allows replication between different servers, again with SSL for the replication connection. Generally, though, changes need to be entered at the master. >Well, so far it is easy, isn't it? > >Here's my question: > >a) How can I make sure that it secure so only authorized person can >modify/add/delete the information? Beside transaction logs, are there >any >other method to trace any transaction(kind of paper trail)? Who's an authorized person? At what granularity do you need the access controls? For example, MySQL has access controls on individual table columns, so a specific person (database login) may be allowed read-write, read, or no access to the 'SSN' column. However, I do not believe it has any kind of access restrictions that would allow one to read and alter the SSN in THEIR OWN RECORD ONLY. If you put each person's data in different tables, or different databases, that would make access control better, but it makes it harder to search for things like "whose wills are kept by "? It is possible for PHP to access the data using its own database login (for which it will likely have near-full privileges), and let the PHP code enforce restrictions like "a user may see only his own SSN". PHP would have its own set of web users (with their own passwords, privileges, etc. enforced by PHP but with the info kept in the database). This does mean, however, that anyone with PHP's database login gets to see all the data. It also means that the PHP code that enforces the security rules could leak information if the security policy is not implemented correctly. And implementing all that PHP code CORRECTLY takes work. A suggestion for your PHP web pages: log the time, date, IP address the request came from, user name (or other form identifying the requester), whether the password was correct (log the bad attempts too!), what they accessed, and what they changed, and what the old values of the changed fields were. MySQL has query logs (however, if there is one database user, PHP, for all the web page users, it will not log which query was made on behalf of who). Your PHP application can log what screens who viewed and what changes were entered. This takes WORK. PHP will not do all that logging itself automatically. >Assuming there are 3 step process to one enter the info e.g: >- One who enter the info (me) Now, right here, you've got a security problem. You see all the data. And you shouldn't. >- One who verify the info(the owner of info) >- One who verify and then commit the change! For a multi-step process like this you need some place in the database to store pending changes. What is your access policy for THOSE? Can I, who entered the data, see the data I entered while it is waiting for the owner of the data to approve it? >How can I implement such a process in RDBMS and/or PHP or any other web >language? > >b) How can I make sure that no one can tap the info while we are >entering >the data in the computer? (our family are scattered within US and >Canada) Use SSL web pages (https). SSL between the web server and the database matters less if the web server and the database are on the same machine or on a local LAN, and direct access to the database is not allowed except on the same machine or within the local LAN. But SSL between the web server and various users' browsers all over the continent is a must. Even if you use a VPN, browsers tend to take better care of SSL data (like not leaving it around in a cache). >c) Is it possible to securely synchronize/replicate between our >computers >using VPN? Does RDBMS has this functionality by default? VPN is typically not a feature of a RDBMS (neither is "wireless 802.11g", or DSL, or IP over Avian Carriers - a RDBMS typically runs over IP, and a VPN uses some means to transport IP securely). A RDBMS that can replicate over the net should be able to transparently replicate over a VPN if you set up the VPN to encrypt all traffic. There is nothing inherently wrong with using multiple security layers (e.g. https over IPSEC over SSH tunnel over WEP-enabled 802.11g, although this is a bit extreme) unless the overhead just gets to be unacceptable. MySQL supports replication over a SSL database connection, by itself without needing to install a VPN. (Having both is not an unreasonable choice, though). Is there a need for users of this database to access data on the road, away from their VPNs? For example, several family members are on a trip, there's an accident, and one of them urgently needs medical history information for one of the others. >d) Other secure method that I have not yet mentioned. Another thing to think of is encrypting data *IN* the database, and if you do that, how you manage keys. Presumably some of this info is being kept to ensure that it is available if the owner of the data dies, which may make this option less desirable. >Anyone has good ideas on how to implement such a systems? First, you need to decide on your security policy (especially the part about legitimate users snooping on other legitimate users data). You also need to decide what functions are needed. A RDBMS can generally "search on anything" but a web page, unless it lets you enter an arbitrary SQL query, usually doesn't. Gordon L. Burditt