|
This is a frequent concern of shops with PC's attached to their iSeries
(which would all of us, wouldn't it?). And while it's good that you're
aware of the data access risks of ODBC, I would warn you to also be
aware of the similar exposures created by other OS/400 services such as,
FTP, DDM, Remote Command, and a whole host of Client Access services.
There are really two main avenues of attack when trying to secure data
against ODBC (or any other network) access -- either you change all of
your data files so that the end user does not have direct access to the
data (something like *PUBLIC = *EXCLUDE authority to all of your data)
and then change your business applications so that the users can still
access the application somehow, or you put exit programs in place to
regulate the flow of ODBC traffic on and off of your system. Most folks
choose the exit program route, because it is simple, secure, quick to
implement, and it is less likely to disrupt your business operations
than a complete application security redesign.
The value of an exit program is that it sits between the end-user's PC
and the iSeries database and controls who can access DB2/400 data. The
exit program acts as a sentinel so that only the ODBC or DDM traffic
that you want is let through. What's more, it also can create a log of
all the traffic (whether allowed or not) so that you can see who is
trying to read or change your data.
When it comes to putting exit programs in place, you have two choices
again, either write the programs yourself, or purchase a packaged
solution from an experienced software vendor. Writing exit programs requires a fairly substantial
amount of experience working with IBM API's and interfaces, as well as a
dedicated test machine to experiment on; you don't want to lock
everyone out of your production system because your exit program has a
little bug in it. You also want to make sure you cover all of the
network access points that people can use to access data or run commands. There are over 30 exit points to cover, and over 200 discrete
functions within those 30+ exit points. If you just cover ODBC, and
leave DDM or the Remote Command server exposed, you've still got a
significant exposure.
A purchased solution is often the more cost effective route. It
provides you with a complete and fully tested solution that will work on
your current release, and if you've picked a responsible vendor, on
future IBM releases as well. When evaluating any security solution, I
recommend the S.U.R.F. test, that is the Solution should be:
Secure: Both in it's approach to your data and its approach to
it's own data.
Usable: Easy to use and easy to implement. Complicated
solutions don't often get actually implemented, and if they are, are
difficult to verify and maintain.
Reliable: Security solutions have to work. Every time. End of
story.
Fast: Performance is critical, a security solution that
impacts your business processing runs the risk of getting torn out in
favor of business flow.
The Bottom Line is, you are on the right track. Secure ODBC, FTP,
Remote Command, DDM and all the other ways of getting at your data.
Exit Programs are safest and fastest way to get it done, while doing
nothing is a significant risk. ==================================
MORE INFORMATION ON THIS TOPIC
==================================
The Best Web Links: tips, tutorials and more.
Search400's targeted search engine: Get relevant information on security.
Ask your systems management questions--or help out your peers by answering them--in our live discussion
|
