Subject | RE: [ib-support] ISC4 security MORE |
---|---|
Author | Kevin Lingofelter |
Post date | 2003-04-10T16:12:52Z |
Hello,
The problem is that sometimes instructing the client isn't enough. We deploy
proprietary lookup data with our application. Right now, we have to encrypt
the data at the field level. Having access to our raw data is not something
we want our clients to have.
Encryption works ok, but there is unnecessary overhead involved with this
process. Someone mentioned linking a database file to the security file
which, to me, seems like a practical solution...but that is only IMHO...=)
Best Regards,
Kevin Lingofelter
-----Original Message-----
From: Artur Anjos [mailto:arsoft@...]
Sent: Thursday, April 10, 2003 8:50 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] ISC4 security MORE
Jason:
This is a problem for everyone that owns a simple file server, no matter
what type of file is. :-)
For the first Rod message, I understand that the problem was direct access
to the file. Maybe Rod is using a os that don't have security (win98,...).
But I undestand that Rod's problem is the copy to another machine with a
'clean' isc4.gdb. And in that way, even if he don't owns the server, he just
needs to instruct the client for this subject. And it's up to his client to
protect the file, as he (maybe already) do with other files that security is
important.
Artur
The problem is that sometimes instructing the client isn't enough. We deploy
proprietary lookup data with our application. Right now, we have to encrypt
the data at the field level. Having access to our raw data is not something
we want our clients to have.
Encryption works ok, but there is unnecessary overhead involved with this
process. Someone mentioned linking a database file to the security file
which, to me, seems like a practical solution...but that is only IMHO...=)
Best Regards,
Kevin Lingofelter
-----Original Message-----
From: Artur Anjos [mailto:arsoft@...]
Sent: Thursday, April 10, 2003 8:50 AM
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] ISC4 security MORE
Jason:
This is a problem for everyone that owns a simple file server, no matter
what type of file is. :-)
For the first Rod message, I understand that the problem was direct access
to the file. Maybe Rod is using a os that don't have security (win98,...).
But I undestand that Rod's problem is the copy to another machine with a
'clean' isc4.gdb. And in that way, even if he don't owns the server, he just
needs to instruct the client for this subject. And it's up to his client to
protect the file, as he (maybe already) do with other files that security is
important.
Artur
----- Original Message -----
From: "Jason Chapman (JAC2)" <jason@...>
Newsgroups: egroups.ib-support
To: <ib-support@yahoogroups.com>
Sent: Thursday, April 10, 2003 4:06 PM
Subject: Re: [ib-support] ISC4 security MORE
> I think Rod's problem is when you install your software on a client site
> with their own Hardware Support who have access to the server. In essence
> there is no way i can see of protecting the info on the server without:
> 1) Using EFS (Encrypted File System), I believe this is an option with
W2K.
> 2) Supplying them with a server that is yours and they don't have access
to
> it at all.
> You then have the issue of backups and whether to make them encrypted
.....
>
> I think there has been talk of building a plug-in architecture, kind of
> like Blob filters to add functionality that isn't going to be in the core
> products. Ideas for the use of this are encryption, XML .....
>
> HIH
>
> JAC.
>
Yahoo! Groups Sponsor
<http://us.ard.yahoo.com/M=249982.3083889.4452939.1728375/D=egroupweb/S=1705
115386:HM/A=1524963/R=0/*http://hits.411web.com/cgi-bin/autoredir?camp=556&l
ineid=3083889&prop=egroupweb&pos=HM>
<http://us.adserver.yahoo.com/l?M=249982.3083889.4452939.1728375/D=egroupmai
l/S=:HM/A=1524963/rand=841826316>
To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .
[Non-text portions of this message have been removed]