Open database security issues

[rez]

Is there any way to secure a database, after a user is logged in, from access through external data source by another database?

It has come to my attention that creating a new local database (L) while logged in to another server hosted database (S) will give the user access to all data, scripts and value lists as enabled by the user's privileges in S. In other words, the local database (L) is implicitly inheriting the open database's user privilege set. How can this type of sharing be locked down/stopped?

Thanks.

[Vaughan]

Is there any way to secure a database, after a user is logged in, from access through external data source by another database?

It has come to my attention that creating a new local database (L) while logged in to another server hosted database (S) will give the user access to all data, scripts and value lists as enabled by the user's privileges in S. In other words, the local database (L) is implicitly inheriting the open database's user privilege set. How can this type of sharing be locked down/stopped?

The access is limited to the user restrictions granted by the privilege set the user has. When the shared file is opened the user will be prompted to authenticate: they'll be limited by their privileges in the shared file.

If a user's account has read-only privileges in the shared file, those privileges are enforced whether they open the file directly or indirectly through another file (as an external data source). So even if you have full access in the local file, you'll be limited to whatever access your account grants in the shared file.

[rez]

The crux of the issue is when a user creates their own local database, and links up to one a developer has created. The user is then able to access the database in a way not intended by the developer.

Thanks.

[Vaughan]

Yes, that's correct.

The developer can control the fields that each user can access, and whether the user can edit, delete or create records, and whether the user can export or print the records.

Even if a user creates a local database and links to a shared database, their access to the shared database is still limited by the privileges set up by the developer. The only difference is that the user can display the records in a different interface -- the interface in the local file.

This, btw, is the mechanism by which most custom-built access control schemes can be worked-around ("ersatz" as Steven Blackwell calls them). Trivially easy to do. Unless the developer has set up the built-in access privileges correctly. Then it's almost impossible to defeat.

If you allow a user to view data in a database, it doesn't matter whether they do so through your interface or their own. There is no security breach. Unless you've relied on the interface to control access and security, in which case it's a fail.

Set up the privilege sets and accounts to control access to the table, record and field level. Use field validation to ensure that the data is entered correctly at the table and field level.

[Steven H. Blackwell]

The developer can control the fields that each user can access, and whether the user can edit, delete or create records, and whether the user can export or print the records.

Access, create, edit, or delete-->Yes.

Print or export-->No.

These are very subtle distinctions and not at all well known by even advanced developers in many instances.

Record Level Access privileges are among the very best ways to limit exposure in these situations.

I am going to be talking about this at the Developer Conference.

There is a significant issue here to be sure.

Steven

[rez]

Thank you both for your comments on this issue. Security is becoming a big issue and I'm trying to make sure we are doing it right.

Steven I'll be at Dev Con this year and will attend your briefing on this issue.

The other point I want to stress is that users creating their own local system can also execute scripts located in the logged in database. Allowing one to manipulate data and also changing the context of the script since the user can run it against any table occurrence.

Thanks!!

Edited May 13, 2009 by Guest