Re: Increase Security

In my opinion, and for our needs, this is one of the most critical problems we see with relational databases currently. Any solutions, even to the extent of enhancing or defining new security systems, is becoming critical for us. May be DCE, Kerberos or some other solutions are allready available? > dshirazi@labyrnth.uhl.uiowa.edu (Dariush Shirazi) writes: > In article <ian.goddard.33.0015B6E5@geo2.poptel.org.uk>, > ian.goddard@geo2.poptel.org.uk (Ian Goddard) writes: > > There is at least 1 way to fix this problem. Keek your own security based on > the program that is being run rather table permissions. It is very easy to > do and much more managable than Informix's grant/revoke. If you need more > information, I can send it to you. This is easy in 4GL running on the server. We use a combination of this and grant/revoke in the database. But it solves no problems in a client/server environement. Also it only works with programs you have written yourself. A proper security system must work outside the programs, or possibly within a standardised protocol every program uses. > >It seems to me that we need the client/server protocols to enable a client > >*program* to identify itself in a manner which will be proof against tampering > >(as far as this is possible) and will let the server check the client against > >an approved list. As a by-product this would also enable the server lock out > >incorrect versions of the clients. Whilst it's easy to define the > >requirement, however, it's less easy to see how it might be met. Anyone got > >any ideas? > > > > Again, this can be done using the same thing. All you have to do is to make > the program switch into another user once the first user is authenticated. > I think newera can do this. That's *not* all. Because we need to know the individual user every user would have to have two login-names on the server. A maintenance problem. Also it does not solv problems with 3rd party programs which are important! > Also, Informix 7.1 or 7.2 has a role future. I think it should do what you > want. From what I have seen of "roles" they solve a maintenance problem, but as John said, I don't think they give you to much with regard to security in a client server world. Particularly not with third party programs. All this is becoming a very serious problem for us (and for many others.) The senario is as follows: A user has been granted update/delete rights to run a 4GL application on the server. We open up the TCP/IP connection into the database to run some Windows client programs on PCs. As soon as this is done there is no way to stop any user (with these update/delete rights) on the network from installing ODBC, run MS Access or any other ODBC enabled program, and create total caos in the database. It may not be because the user wanted to do it, he simply didn't relise the consequences of hitting the delete key or whatever at the wrong moment. Anybody who knows a way around this, or know of any work beeing done to gard against this? Of course it is *important* that users must be allowed to run controled programs on their PC that uses an ODBC connection to update/delete/insert on tables in the database. Stored procedures is *not* a viable solution! Nils.Myklebust@ccmail.telemax.no NM-data, Dalsbergstien 7, N-0170 Oslo, Norway My opinions are those of my company