> -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Jeffrey Deaver > Sent: Monday, February 05, 2007 4:17 PM > To: [email protected] > Subject: LPAR Org & Security > > The question I'll get to: How are your shops organized when it comes to > LPAR organization, access and security? > > To explain where I'm coming from: > > 1) LPARS > We have two. PROD supports everything from TSO users and program > development to multiple instances of IMS and DB2 and batch processes. > TEST2 is an exact image of PROD created with volume level snapshots and is > used for testing upgrades and troubleshooting issues. > > 2) Networks > We have two. Production, of course, has most things connected to it, > including the PROD LPAR, and all the other production servers in the > company. It also has a ton of development and QA servers connected to it, > along with the TEST2 LPAR when we want it there. > The other network is called NEQAL, and is our separate testing network. > We > dynamically build pieces of our production environment there when we want > to test upgrades and changes before we do it on the production network. > The TEST2 LPAR is sometimes connected to this network when the testing > there needs to involved the mainframe. > > With that explained, we've recently had a security question come up. > > Should the TEST2 LPAR only be connected to the NEQAL network? > > You see, this would then force a user to use a workstation in a separate > location, not at their desktop, in order to perform work on TEST2. In > this > way, then, the possibility of someone becoming confused about which LPAR > they are looking at on their desktop is minimized. In other words, I, > systems engineer, would be less likely, as an example, to stop TCPIP > accidentally on the PROD LPAR because if I'm sitting at my desk, I know > its > the PROD LPAR, and if I'm in the NEQAL lab, I know its TEST2. Right now, > I can swap from PROD to TEST2 at my workstation. > > We systems engineers are, of course, arguing that we need that access as a > matter of productivity. It really opens a can of worms, since if they > were to dictate that, we would soon be arguing that all the development > and > test servers should also only be on the NEQAL network. And then we get > into the arguments about where the production instances of DB2 verses the > 3 > test instances should be running. Separate LPARS? Ug. > > So the main question I want to ask you all is this: How are your shops > organized when it comes to LPAR organization, access and security? > > Most of us have only worked in our own shop, and so learning what others > do > will help us decided which course of action is best - and convince > management of it! > > THANKS! > > Jeffrey Deaver, Engineer
Just to muddy the waters further, I would suggest looking into elevating the security controls on the production and test systems to use RACF security labels. Make the default security label for your TSO systems engineers match the test system security label. In order to muck with the production system, you must log-on and explicitly specify the security label for the production system. Ensure all "privileged" or "authorized" commands and access procedures are protected by the appropriate security label. So, if you logged onto with the default security label, you won't have the authority to issue production system commands; only test system commands are available. If you try to log-on to a test system with a production system security label, RACF will reject the log-on. I am not a RACF expert. Two cents worth. Your mileage may vary. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ see my résumé at my website (yes, I am looking for employment) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
