Re: Increase Security

I'm glad to hear people finally discussing these issues, which I think are very important and tend to be missing when people are talking about client-servers solutions. A relatively simple solution which seems to work is as follows: - Set up user accesses with grant/revoke for read access only. - Create a single user with full read/write access to all tables. - Use I4gl for all programs that update the database. These programs connect to the database as the full-access user, and contain user access controls that are easy to maintain. The password for the full-access user is encrypted in the program somehow. - Any other client programs on PC's or whatever thereby get only read access to information granted to the user, and are harmless. The PC's are left to do what they do best - fancy reports. This is not the long-term solution that Nils is seeking, but it does the trick while we wait for the client-server model to mature. Nils.Myklebust@ccmail.telemax.no wrote: >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 > > >