Обсуждение: Can I restrict backups?

Hi,
now this might be a bit of a silly question, but I'll give it a shot anyway.

I'm working on a remote database for a few employees of a rather small
startup company where at least a few will get teleworking jobs. They'll
get a ms-access application that connects via ODBC from their home.

They'll have limited access to the tables. Some will be just readable or
writable.
Obviously to work with the most intersting data they'll need reading an
writing access.

Could I somehow avoid that one of them uses pg_dump or even Access
itself to pull all the data out and sell it to a competitor?

Andreas wrote:
> Hi,
> now this might be a bit of a silly question, but I'll give it a shot
> anyway.
>
> I'm working on a remote database for a few employees of a rather small
> startup company where at least a few will get teleworking jobs.
> They'll get a ms-access application that connects via ODBC from their
> home.
>
> They'll have limited access to the tables. Some will be just readable
> or writable.
> Obviously to work with the most intersting data they'll need reading
> an writing access.
>
> Could I somehow avoid that one of them uses pg_dump or even Access
> itself to pull all the data out and sell it to a competitor?

You have conflicting objectives here.

You give them read access to the data, but you don't want them to read it.

The real issue here is a legal one.  Once you let the data go from the
server to their machine, who knows what they'll do with it.

Scott Marlowe schrieb:
> Andreas wrote:
>> now this might be a bit of a silly question, but I'll give it a shot
>> anyway.
>>
>> I'm working on a remote database for a few employees of a rather
>> small startup company where at least a few will get teleworking jobs.
>> They'll get a ms-access application that connects via ODBC from their
>> home.
>>
>> They'll have limited access to the tables. Some will be just readable
>> or writable.
>> Obviously to work with the most intersting data they'll need reading
>> an writing access.
>>
>> Could I somehow avoid that one of them uses pg_dump or even Access
>> itself to pull all the data out and sell it to a competitor?
>
> You have conflicting objectives here.
> You give them read access to the data, but you don't want them to read
> it.
That's why I wrote "silly question".
>
> The real issue here is a legal one.  Once you let the data go from the
> server to their machine, who knows what they'll do with it.

Right.
It's like that. They should work on projects that only contain a subset
e.g. of customer addresses and subsequently on the task related objects
like orders regarding the current project.

The staff of my customer has quite some fluctuation since he hires
mainly project based university students who can't work longer than a
few weeks anyway.
There's now and then one among them who knows a wee bit more than enough
to test the limits of the work environment.

We just want to stop them to run off with the content of our database on
to of the usual pencil and coffee pot.

The problem - not only - of my customer is that he primarily has to
trust strange people enough to grant them access to the very base of his
business and this base could be carried away on an USB stick or piped
out via email or whatever.
Legal repercussions against the individual when the worst case happened
are no actual solution, I fear.

That must be a common problem for a lot of businesses so there might be
concepts to counter this threat.

On Wed, May 23, 2007 at 10:44:36AM +0200, Andreas wrote:
> The problem - not only - of my customer is that he primarily has to
> trust strange people enough to grant them access to the very base of his
> business and this base could be carried away on an USB stick or piped
> out via email or whatever.
> Legal repercussions against the individual when the worst case happened
> are no actual solution, I fear.

The only actually useful advice one can give in that case is, "Don't
do that." If the business is worth having, it's surely worth
protecting by hiring people you can trust.  But you could restrict
the subset of the data they can see using VIEWs.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
The whole tendency of modern prose is away from concreteness.
        --George Orwell

On May 23, 2007, at 4:44 AM, Andreas wrote:

> Right.
> It's like that. They should work on projects that only contain a
> subset e.g. of customer addresses and subsequently on the task
> related objects like orders regarding the current project.

Another thought is to make all data returned through pl/pgsql
function calls (see SECURITY DEFINER option). I think you could
revoke all access to the underlying tables.

In addition to only returning data relevant to the task, the function
could automatically limit the number of rows returned to make it more
difficult to dump large amounts of data.



John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL