|
> Where is a good place to start looking at Client-level > security? > Specifically in the area of ODBC/OLE access. > > We are starting to roll out several client based access > apps where the > user's are going to be using ODBC and the like to access > our production > data, and I want to try and head off any security issues. Ron, On a typical iSeries system, end users are going to have pretty broad authority to your database. Our company did an iSeries security study and found that (on average) *PUBLIC had *CHANGE rights to over 80% of the data on a typical system. While most people might think this is excessive, this particular data point did not even address the number of users that have *ALL rights to the data because they belong to the group profile that owns the data. (You can download the study and read it for yourself at http://www.powertech.com/promotions/whitepaper.html). You can also see how you stack up against the survey data by running a PowerLock FlashAudit for your self - you can find this free download at http://www.powertech.com/SOA.html. The most prominent security issue with traditional iSeries applications (and even some newer ones) is that users have direct Read, Add, Update, and Delete rights to the data. If you can somehow manage to keep your users completely locked into your own application interfaces, your data might be safe from their experimentations. But if your users have the ability to run FTP and ODBC drivers from their PC's (and most do), then you're going to have the added challenge of trying to discern when a trusted application is trying to access data, and when an errant, malicious, or un-authorized application is trying to get at your data. This can be more than just a little bit tricky. We use (and sell) ODBC exit programs to do this sort of low level transaction inspection. The exit program can intercept the inbound ODBC statement and scrutinize it for legitimacy. Known Good transactions are accepted, and suspect transactions are either suspended, or outright rejected. If you want to write your own ODBC exit programs (and few people who have gone this route would recommend the write-your-own route to others), you can learn more about them in the Client Access Host Servers manuals. The Call Level Interfaces are described there, and there may even be some sample code. If you go this route, you should also look at the TCP/IP manuals for information on how to protect against FTP and REXEC, as well as the Distributed Database Guide for the DDM interfaces (I think that's all of the sources, but it's been a while since I looked them all up). If you are interested in putting a commercial application in place and letting somebody else (the vendor) worry about keeping it current with OS releases, then visit our main page (www.powertech.com <http://www.powertech.com/> ) and learn more about our exit program solution called PowerLock NetworkSecurity In any case, you are right to be concerned about your end users accidentally (or on purpose) hammering your data with direct ODBC access. And as with any other application project, the earlier you can architect a security solution in to the application, the more effective an less disruptive your solution will be. If you need more specific information about some of the ODBC exposures, just ask. jte -- John Earl | Chief Technology Officer The PowerTech Group 19426 68th Ave. S Seattle, WA 98032 (253) 872-7788 ext. 302 john.earl@xxxxxxxxxxxxx www.powertech.com This email message and any attachments are intended only for the use of the intended recipients and may contain information that is privileged and confidential. If you are not the intended recipient, any dissemination, distribution, or copying is strictly prohibited. If you received this email message in error, please immediately notify the sender by replying to this email message, or by telephone, and delete the message from your email system. -- > -----Original Message----- > From: midrange-l- > bounces+john.earl=powertech.com@xxxxxxxxxxxx > [mailto:midrange-l- > bounces+john.earl=powertech.com@xxxxxxxxxxxx] On Behalf Of > ron_adams@xxxxxxxxxxxxxx > Sent: Thursday, September 30, 2004 12:57 PM > To: Midrange Systems Technical Discussion > Subject: Client Access Security > > Where is a good place to start looking at Client-level > security? > Specifically in the area of ODBC/OLE access. > > We are starting to roll out several client based access > apps where the > user's are going to be using ODBC and the like to access > our production > data, and I want to try and head off any security issues. > > Ron Adams > Information Technology Group > Crane Valves > 9200 New Trails Dr. Suite 200 > The Woodlands, TX 77385 > Office: 281-298-5463 x104 > Direct: 281-465-3054 > Cell: 281-216-7721 > > -- > This is the Midrange Systems Technical Discussion > (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: > http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the > archives > at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
