Re: Security options at different SQL-Databases with ODBC - who is best ?

In <53qrcr$8dk@nntp.idgonline.no> Nils.Myklebust@idg.no (Nils Myklebust) wrote: : Micorsoft seems to believe that free access by everyone to all data in : all databases is the best situation for everyone. No comments. : There is *no* mechanism built into ODBC to protect any data from free : manipulation by any user *if* that user has access to some application : that can do such updates. : ... If i write a Visual Basic application using : the Microsoft recomended way of updating data via ODBC, there is no : standard mechanism in ODBC or anywhere else that can stop that user : from staring MS Access, connecting to that same database via the same : ODBC interface, giving the same username and password used for that : application, and then manipulate the data in any way that user wants. If you are talking about ODBC as an implemention of CLI(ANSI or X/Open), then you need specify which driver(s) you are talking about because your statement is not true for ODBC drivers in general. If you are talking about ODBC as an specification, than, you should understand specifiction usually not offer(or build) very much *mechanism(s)*. The only mechanism I know that ODBC preassumed is dynamic driver loading. For most desktop databases and their ODBC drivers, your statement is absolute correct. However, those databases themself don't have much mechanisms to do the protection(because there are no way to do that without system has mechanis to protect the low level files themselves). Thus, why bother to secure ODBC access to those databases without securing the database engines themselves. It has not to much sense to secure you windows without secure your door(s). I believe this may be one reason that most desktop database ODBC drivers don't have a real build in mechanism to protect unauthorized access. For database drivers for Oracle, Informix, etc. Then, you need first answer do you allow remote native access. If you still allow remote native access, then there are not too much sense if native client library and network layer don't secure themselves. Many ODBC drivers for this class of databases are build as simply a wrap of the original native client library. then, the whole access authentication, data transport encryption etc. are all responsible by native library. A wraper can't/needn't do any thing beyond what the native library. Because, even an ODBC wraper does something beyond native library protection, an user is still easily to bypass it by using native client directly(that is same as you protect your window without protecting your door). If you disallow remote native access but only use your own network layer plus a local native access on the server host, then it is up to this particual gateway driver(or mulit-tier driver) to implement all of access/information protection. There are far too many ways to do all of those things, for example use DCE or Kerberos for authenticatioin and public key data encryption, etc.etc. and most of them can easily fit into ODBC's frame. I know many these kind of multi-tier drivers(and the middleware servers) already did these(i.e. using DCE/Kerberos as well as public key on wire encryption). Of cause, 1. you still need system support to protect unauthorized local access from file level. 2. you still can access a datasoure with password you get form someone mouth, but it is his/her problem not ODBC's, not DCE's and not Kerberos', etc. etc. : Microsoft and others should be pressured into doing something about : this totaly unacceptable situation. Any help in doing this would be : much appreciated. You should clearfy what is the unacceptable situation. I.e. is what appeared in desktop databases ODBC driver implemention or is what appeared on native remot access implementions or is what appeared on multi-tire driver/server implementions? For the first case, the solution is change your OS. For the 2nd case, the solution is either fix/enhance the native implemention or simply avoid use native remote access before it has been done and replacing it with a multi-tire driver/server architecture. For the 3rd case, it is up to an implemention to do it(and already many many did it) within the frame of ODBC. But all of these are implemention issues(and technically can/already easily be solved) not a problem of MS ODBC, ANSI CLI, X/Open DBC or SQL in general. -g