| Subject | Re: [ib-support] Firebird Deployment |
|---|---|
| Author | IB/FB List |
| Post date | 2003-01-09T19:53:43Z |
At 17:43 09/01/2003 +0100, you wrote:
I have asked two differnt things based on a Marcus problem..
First one:
Encryt the fields data based on user/group/role..
Second one: Wich I think better for *the exposed problem*.
Ignore records that are not "own" by the person (user/role/group) who sends
as select statment. It's possible to do this using views, SP's, but I think
will be a shorcut make some kind of "record hiding" as properties of a
table like constraints, could be done in triggers but have a straight way
if you do it on the table definition.
As we started talking in the begging of the thread...
Marcus will (i think) encrypt the fields data on the client side...
I have suggested an server side encrypt to avoid different client
applications to re-implement the decryption algoritm... My applications are
written in Delphi and the reports are done in Crystal Reports (I can use an
external Function, I do not remember the Crystal Reports terminology fot
that, like in FB, but I never tested this feature, and if simple things
Crystal Reports have some work arounds to do, imagine with an external dll
messing up with the Crystal Data...). If you have an application written in
VB, another on PHP that uses the database you should writen decrypt
routines for the diferent client applications. For this reason I asked if
server side encryption is a good thing.
Now the SYSDBA thing...
I think it is discussed earlier... To have a SYSTEM user who can acces data
for backup's but cannot connect to the database for normal use ? As Ann has
said... If you have the GDB and Firebird sources everything can be done.
But I think that not every one could read, understand, hack with the
sources to overpass the security, of course, if one is REALLY interested on
it they will do, but just for look at employees salary the work will be so
hard...
avoid different applications to have to re-implement data decryption.
I was not talking to secure the data over the wire (to avoid sniffing), but
to avoid users who have right to access the database but not all records
from a table.
It's possible to implement the decrypt routine on fb client library (as
suggest before) to divide the workload by the server and teh client machine ?
Back to the option that ignores records that user has no right to view....
If it's done on the server, only "valid" records will be returned to the
client (less bandwidth) if the ALL the records that meat the search
criteria are returned to the fb client (fb client not application client)
and the fb client ignores the records that the user are not allowed to see,
the work will be shared, but bandwidth will be wasted.
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
----------
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.437 / Virus Database: 245 - Release Date: 06/01/2003
[Non-text portions of this message have been removed]
>Hello Ann,IB/FB List is me Alexandre... ;-)
>
> >> ...but why should good encryption be very expensive?
>
> > Because the database has to encrypt and decrypt each piece of data
> > as it goes in and out of the database. That's an absolutely
> > critical path and very heavily travelled. We've talked about page
> > level encryption - cheaper because it's done only when a page is
> > read or written. That doesn't help in this case.
>
>Do you mean en/decrypting the page as a whole when it is written or
>read? As far as I can read back the thread (which is not very far
>at this moment) the person you responded to (IB/FB List == Marcus?)
>wrote:
I have asked two differnt things based on a Marcus problem..
First one:
Encryt the fields data based on user/group/role..
Second one: Wich I think better for *the exposed problem*.
Ignore records that are not "own" by the person (user/role/group) who sends
as select statment. It's possible to do this using views, SP's, but I think
will be a shorcut make some kind of "record hiding" as properties of a
table like constraints, could be done in triggers but have a straight way
if you do it on the table definition.
As we started talking in the begging of the thread...
Marcus will (i think) encrypt the fields data on the client side...
I have suggested an server side encrypt to avoid different client
applications to re-implement the decryption algoritm... My applications are
written in Delphi and the reports are done in Crystal Reports (I can use an
external Function, I do not remember the Crystal Reports terminology fot
that, like in FB, but I never tested this feature, and if simple things
Crystal Reports have some work arounds to do, imagine with an external dll
messing up with the Crystal Data...). If you have an application written in
VB, another on PHP that uses the database you should writen decrypt
routines for the diferent client applications. For this reason I asked if
server side encryption is a good thing.
Now the SYSDBA thing...
I think it is discussed earlier... To have a SYSTEM user who can acces data
for backup's but cannot connect to the database for normal use ? As Ann has
said... If you have the GDB and Firebird sources everything can be done.
But I think that not every one could read, understand, hack with the
sources to overpass the security, of course, if one is REALLY interested on
it they will do, but just for look at employees salary the work will be so
hard...
> >> Are a good feature have record encryption based on user or rolesYes ! You interpreted right. but I have suggested server side encryption to
>
>...which I interpreted as "encryption of records based upon the user
>that should have access to those records", i.e. using different
>ecncryption keys for different users. I must admit however that I also
>interpreted "record encryption" as "field encryption" or rather "field
>data encryption". Which is not too expensive on the client side.
avoid different applications to have to re-implement data decryption.
I was not talking to secure the data over the wire (to avoid sniffing), but
to avoid users who have right to access the database but not all records
from a table.
It's possible to implement the decrypt routine on fb client library (as
suggest before) to divide the workload by the server and teh client machine ?
Back to the option that ignores records that user has no right to view....
If it's done on the server, only "valid" records will be returned to the
client (less bandwidth) if the ALL the records that meat the search
criteria are returned to the fb client (fb client not application client)
and the fb client ignores the records that the user are not allowed to see,
the work will be shared, but bandwidth will be wasted.
>It started to dawn on me that we were probably talking about twoAlexandre Benson Smith
>different things when you asked the other guy if he'd ever thought
>about client side encryption... ;-)
>
>
>Greetings,
>Paul Vinkenoog
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
----------
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.437 / Virus Database: 245 - Release Date: 06/01/2003
[Non-text portions of this message have been removed]