Re: Informix security

John, We are currently using database roles in both production and development environements. All access to the roles (ie. granting, revoking, setting) is done through dba stored procedures to limit access. These stored procedures can be executed from dbaccess as well as client apps (ie. powerbuilder). Some members of our team are currently working on a solution to furthur distinquish our production and development environments in order to limit access to the production db to client front-end access only using "sequence-generated codes" known and generated only by the client (and that's about all I understand about it). If you would like details I could dig a little furthur. Another option we are looking into for our production environments involves granting access only through active client sessions and then revoking that access within the same stored proc. This allows the active session to continue with role-based access while active through the client only, if they close the session/database the access is lost. Alicia Ray On Feb 17, 2:53pm, John Carlson wrote: > Subject: Re: Informix security > Michael Segel wrote: > > > > John Carlson wrote: > > [SNIP] > > > Read it. While it woould work under normal circumstances . . . > > > > > > We have a test system and a production system. 4GL developers have > > > command-line access to both systems, although rarely on the production > > > system. My understanding of roles is that the role would be embedded > > > into the 4gl program, thus preventing certain table access. > > > > > > The problem is that the same people who would add the role to the 4gl > > > would also have access to the role name. All that is needed would be a > > > DBACCESS session and . . . > > > > > [SNIP] > > > > You will always have that issue. > > Whoever knows root on a system will have access to anything. > > ( does su - informix mean anything? :-) > > > > At this point, I am the sole repository and high keeper of the Informix > password. If there were a problem, I guess they could reset it, but > then someone in our production control center (sysadmin) would catch > it. 8-> > > > The only way you could limit them is to reduce their access to > > the production system, and secure the production system. > > (Ie no .rhosts, and keep the development systems out of host.equiv) > > > > Already tried that approach. Developers would still need to be able to > run "selects" from the command line. > > > My point is that no matter what you do, you will always have > > someone who has total access to the data. Unless of course you > > want to encrypt the data before entering it in to the DB, then > > the programmers can get at the encrypted data, unless they know > > the key. (salts are usually the first two bytes if using crypt()) > > > > Wow, what fun that would be. :) > > > Now that's getting paranoid. And thats why they pay me the big > > bucks. ;-) > > > > Someone working with Informix getting paid big bucks? You mean, more > than minimum wage? 8-> > > > John Carlson > Informix DBA > WH Smith, Inc. >-- End of excerpt from John Carlson -- ********************************************************************** Alicia Ray Internet : Alicia.Ray@med.osd.mil EDS-D/SIDDOMS Phone : 703-845-3807 5113 Leesburg Pike Skyline 4 Suite 800 Falls Church, VA 22041-3201 **********************************************************************