Ron Johnson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 03/08/07 20:38, Kenneth Downs wrote:
[snip]
Management and we are about to add the CRM to it so that the
scheduling/billing database also serves the doctor's public website,
Is that wise? One bug and a cracker is poking around some very
private stuff!!
We use the "Spartan" security model rather than perimeter defense, which gives us the confidence to do things that others may not.
The general outline is as follows.
First, security is defined directly in terms of tables, it is not arbitrated by code. The "public" group has SELECT access to the articles table and the schedules tables, that's it. If a person figures out how our links work and tries to access the "claims" table it will simply come up blank (and we get an email). The "staff" group has read/write access to scheduling, and so forth.
Second, the security assignments to tables are generated by a builder, which revokes and grants all priveleges to all groups on all tables. This is to prevent the possibility of error or omission if a person were to implement it table-by-table.
Third, as you probably have guessed, we do not connect to the database as a super-user and then arbitrate in code. Regular staff connect with real database accounts and their security in the database is limited to those accounts. Bugs in code that try to provide unauthorized information will return server errors. A person with no account, such as the public user, has the lowest security priveleges, as mentioned above.
Finally, our URL parameter scheme is really very simple and easy to figure out, we are not hiding it. Anybody trying to get something they can't would not take long to work it out (especially as the underlying tools are GPL), they would simply find it did them no good.
It is good to be very concerned about security, especially HIPPA, where there are legal ramifications. It is also very good to be able to provide convenience and security in one package.