Re: HIPPA (was Re: Anyone know ...)

From: Kenneth Downs <ken(at)secdat(dot)com>
To: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: HIPPA (was Re: Anyone know ...)
Date: 2007-03-09 13:08:11
Message-ID: 45F15C3B.90905@secdat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Galantucci Giovanni 2007-03-09 13:30:51 Error code associated to "could not open relation with OID ..."
Previous Message Bill Moran 2007-03-09 12:38:11 Re: security permissions for functions