Re: Securing ODBC connections
Posted in 1999
> > Is it possible to secure ODBC access to a server's ports even if a client > may be connecting in via their own ODBC s/w > I assume the answer is no, but I'd like to be sure. Any tips on how to make > ODBC connections safer would be appreciated > > Paul Matthews > You can use OpenLink Multi-tier ODBC drivers (not their Lite driver) instead of the Informix drivers. While it does not completely solve all of the problems of ODBC security, it does fix several. OpenLink has a piece that runs on the client and a separate piece on the server. The server piece (the request broker) has a rules-based system for accepting or rejecting ODBC requests. The rules can check (among other things) the user-id, client operating system, client program, client-name (IP address), and database name. Based on these parameters, you can choose to accept or reject the connection request. The request broker runs as a separated Unix task. When an ODBC connection is requested, the request broker applies the rules you have specified to determine whether to accept or reject the request. When you accept a connection, you (as the OpenLink administrator) have the option of forcing the ODBC connection to connect to the database as a specific user, with a specific password, and can set any necessary environment variables. The request broker spawns a new process and sets the environment variables and the user-id as you specify. The new process can connect to the database through a shared memory connection or a network connection to a port that you hide from normal users. An example of how this is helpful involves a third-party program we have. The application controls security within itself, and requires that all connections use the same user-id and requires that I GRANT all permissions to that user for all of the tables. Based on the client program being used, I allow those users using the application to have read/write access to the database. Any users using a different application (e.g., MS Access, Crystal Reports, etc.) has read-only access. I could just as easily prevent them from connecting at all. With Informix's ODBC, if the user connected with Access instead of the application, they could bypass the application-enforced security. The biggest downside to OpenLink is that the support is through the Web (no phone access). They are responsive, but it sometimes is nice to actually talk to someone. Of course, another downside is that it costs money. Given the extra protection it allows over Informix's own ODBC solution, I consider it money well spent. Just my thoughts. I have no connection to OpenLink other than as a customer. Check them out at www.openlinksw.com. Mark Collins mcollins@us.dhl.com