|
David:
I have run into a few showstoppers with adoption. Triggers, IFS files
and vendor packages are three examples. If you rely on adoption, you may need to redo your security scheme when you implement an application change. I have been forced to redo the authority of an application that relied on adoption when a new OS release ended adoption in an IBM supplied process. I had a similar experience with a widely-used vendor package that broke on a new release because it started using a system function that ended adoption. I have also run into application changes that failed due to IFS access. It sounds like you are advocating to limit the profiles that actually have authority to work on your system. Then use profile swaps rather than program adoption to enable most users to access these programs. In your environment you've seen issues with authority adoption. As more users modernize their applications, we can expect to see these problems more often. Based on your experience, part of what is needed to modernize applications is a way to move away from programs that adopt authority to something that implements profile swapping. Otherwise the core elements of your ideal i5 security scheme seem to be the same: few owners; most users have little or no rights; most users' rights to objects come through some means from higher-powered users. Elsewhere Rob Berendt has indicated the difficulties he ran across using private authority instead of authority lists. Your experience doesn't seem to invalidate Rob's findings.
I took that to mean that you used adopted authority in your exit
program but it sounds like you are actually swapping or setting the effective user, which is the approach I use in all cases where I used to use adoption. There are some other steps you need to take like register exits to back out the authority to mimic adoption. The NetIQ exit programs actually swap profiles to something and set it back. Other NetIQ authority schemes are based on authority adoption.
You mention remote access users being granted ownership privileges as
the biggest security problem you see with adoption. I frequently see high power profiles being adopted in poorly implemented programs opening up all kinds of possibilities. Every object needs an owner, and the profiles that own important objects should be controlled. There is all sorts of abuse that can happen when high power profiles (*ALLOBJ or object owners) aren't controlled and monitored. Regardless, bad program design is bad program design, and there are a lot of ways bad programs can hurt your shop. Phil Ashe NetIQ (A division of Attachmate) 1233 West Loop South, Suite 1800 | Houston, TX 77027 USA 713.418.5279 phone phil.ashe@xxxxxxxxxxxxxx www.netiq.com
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.