|
It's more than a signon program. If I have a user profile with limited capability and a signon program specified, there are a variety of methods I can use to execute commands even though my user profile and JBA are both set up to prevent this. Again, if you are not using exit programs, you can not secure an AS/400. Thanks. Charlie Massoglia Chief Information Officer mailto:cmassoglia@xxxxxxxxxxxxx 517-780-4336 Fax: 517-789-4503 "Santos, Fred" <Fred.Santos@Nor thSafety.com> To <CMassoglia@xxxxxxxxxxxxx>, 06/08/2006 08:58 "System 21 Users" AM <system21@xxxxxxxxxxxx> cc <bharper@xxxxxxxxxxxxxxxx>, <mdearmond@xxxxxxxxxxxxxxxx> Subject RE: [SYSTEM21] Control of database updates for Sarbanes-Oxley You are correct. I left out that we setup our live users to go directly into S/21. Once in S/21, they cannot enter commands. -----Original Message----- From: CMassoglia@xxxxxxxxxxxxx [mailto:CMassoglia@xxxxxxxxxxxxx] Sent: Thursday, June 08, 2006 8:35 AM To: System 21 Users Cc: bharper@xxxxxxxxxxxxxxxx; mdearmond@xxxxxxxxxxxxxxxx; Santos, Fred Subject: Re: [SYSTEM21] Control of database updates for Sarbanes-Oxley While your overall approach is quite good, I am a little concerned about one statement you made: 4. Finally, Use the System/21 Administrative Functions to control that none of your "LIVE" users have Command Line Authority. This will stop them from running SQL and other update jobs. First, I assume there are some additional parameters you specify on user profiles such as FRED: Current library . . . . . . . . . . . . . : *CRTDFT Initial program . . . . . . . . . . . . . : JBAPRDEXP (or whatever) Library . . . . . . . . . . . . . . . . : *LIBL Initial menu . . . . . . . . . . . . . . . : *SIGNOFF Library . . . . . . . . . . . . . . . . : Limit capabilities . . . . . . . . . . . . : *YES The key here is to specify LMTCPB(*YES). However, even after restricting command line authority in JBA and in the user profile there are numerous methods these profiles can run commands on the AS/400. I am not sure you can prevent a user from running commands no matter how the user profile is created unless you use exit programs to secure a variety of functions. Again, your approach is excellent. I just want to make sure you understand your people can execute commands using a variety of methods. Thanks. Charlie Massoglia Chief Information Officer mailto:cmassoglia@xxxxxxxxxxxxx 517-780-4336 Fax: 517-789-4503 "Santos, Fred" <Fred.Santos@Nor thSafety.com> To Sent by: "System 21 Users" system21-bounces <system21@xxxxxxxxxxxx> @midrange.com cc mdearmond@xxxxxxxxxxxxxxxx, bharper@xxxxxxxxxxxxxxxx 06/07/2006 09:10 Subject AM Re: [SYSTEM21] Control of database updates for Sarbanes-Oxley Please respond to System 21 Users <system21@midran ge.com> Dan, we have completed our SOX controls here at NORTH Safety. We feel we have a very good control and verification of changes. The question you raised, we resolved by creating Group Teams to work in each of our Three environments, OY1 (live), TST (User Testing), DEV (Programmer Development testing) 1. We started by creating a dummy user OY1TEAM, one for each team. This ID is disabled. And only used for Supplemental Grouping. Display User Profile - Basic User profile . . . . . . . . . . . . . . . : OY1TEAM Previous sign-on . . . . . . . . . . . . . : Sign-on attempts not valid . . . . . . . . : 0 Status . . . . . . . . . . . . . . . . . . : *DISABLED Date password last changed . . . . . . . . : 05/28/99 Password expiration interval . . . . . . . : *SYSVAL Date password expires . . . . . . . . . : 08/26/99 Set password to expired . . . . . . . . . : *NO Local password management . . . . . . . . : *YES User class . . . . . . . . . . . . . . . . : *USER Special authority . . . . . . . . . . . . : *NONE Group profile . . . . . . . . . . . . . . : *NONE Owner . . . . . . . . . . . . . . . . . . : *USRPRF Group authority . . . . . . . . . . . . . : *NONE Group authority type . . . . . . . . . . . : *PRIVATE Supplemental groups . . . . . . . . . . . : *NONE 2. We then assigned all live users to be a part of the Supplemental group User profile . . . . . . . . . . . . . . . : FREDS Previous sign-on . . . . . . . . . . . . . : 06/06/06 14:01:02 Sign-on attempts not valid . . . . . . . . : 0 Status . . . . . . . . . . . . . . . . . . : *ENABLED Date password last changed . . . . . . . . : 03/30/06 Password expiration interval . . . . . . . : *SYSVAL Date password expires . . . . . . . . . : 06/28/06 Set password to expired . . . . . . . . . : *NO Local password management . . . . . . . . : *YES User class . . . . . . . . . . . . . . . . : *USER Special authority . . . . . . . . . . . . : *NONE Group profile . . . . . . . . . . . . . . : QPGMR Owner . . . . . . . . . . . . . . . . . . : *GRPPRF Group authority . . . . . . . . . . . . . : *NONE Group authority type . . . . . . . . . . . : *PRIVATE Supplemental groups . . . . . . . . . . . : OY1TEAM 3. We assigned Object Authority to all Physical Files in our live environment, to allow QPGMR to "*USE" the data with the Team Group "*ALL" Authority. This allows the programmers to refresh data in DEV or TST, But does not allow them to change. "Any" program that tries to perform an update to a physical file, and the user is not in the OY1TEAM, will crash. Display Object Authority Object . . . . . . . : INP35 Owner . . . . . . . : QPGMR Library . . . . . : OY1@@F3 Primary group . . . : *NONE Object type . . . . : *FILE ASP device . . . . . : *SYSBAS Object secured by authorization list . . . . . . . . . . . . : *NONE Object User Group Authority *PUBLIC *EXCLUDE *GROUP QPGMR *USE OY1TEAM *ALL 4. Finally, Use the System/21 Administrative Functions to control that none of your "LIVE" users have Command Line Authority. This will stop them from running SQL and other update jobs. XA100 Administration Functions System: NSPS204 Maintain User Profiles User Profile Process CRPC1 * User not defined to OS/400 * *Update Type changes, press Enter and then F3 to Update User level. . . . . . . . . . . 9 (1=Novice,3=Expert,8=Nov Grp,9=ExpGrp) Initial menu . . . . . . . . . AM Default sign-on company . . . . A2 Single application task . . . . Default development application Language code . . . . . . . . . Default job queue / library . . QBATCH / QGPL Default print queue / library . PRTCRPUR01 / QUSRSYS Hold on print queue . . . . . . 1 (1=Yes,0=No) Authorized to common functions 0 (1=Yes,0=No) Sign-off on leaving system. . . 1 (1=Yes,0=No) Date format (D/M/Y) . . . . . . M Allow submit job prompt . . . . 1 (1=Yes,0=No) Allow command entry . . . . . . 0 (1=Yes,0=No) Message delivery. . . . . . . . *USER (*NOTIFY,*BREAK,*HOLD,*DFT,*USER) 5. We set each of our Environments up this way. It works very well. No user can maintain "Live" data outside the System/21 Menu System. 6. You ask what happens in the event data "must" be patched in live and no S21 function exists? The Operations Staff has full control of assigning Authorities and User Profiles. They have a special user profile called "PRODUCTION". This user is normally disabled. It can be activated by special written authority, to allow corrections to data. The correction is logged with the request, and the update must be verified by the IT Manager, -----Original Message----- From: system21-bounces@xxxxxxxxxxxx [mailto:system21-bounces@xxxxxxxxxxxx] On Behalf Of DThomas@xxxxxxxxxxxxxxxx Sent: Tuesday, June 06, 2006 3:55 PM To: SYSTEM21@xxxxxxxxxxxx Cc: mdearmond@xxxxxxxxxxxxxxxx; bharper@xxxxxxxxxxxxxxxx Subject: [SYSTEM21] Control of database updates for Sarbanes-Oxley We are interested in restricting database updates outside System 21 applications. Our thoughts are to limit these changes (which should be rare) to DBU and use the DBU auditing utility. We wish to prevent use of interactive SQL (STRSQL) and DFU. I'm looking for feedback from other companies that have gone through the same issue. Also, would restricting use of STRSQL affect embedded SQL statements in System 21 RPG programs? Dan Thomas Vice President RxCrossroads 4500 Progress Blvd Louisville, KY 40218-3420 Office Direct (502) 318-1208 Cell (502) 931-3736 Fax (502) 318-1128 This information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material, the disclosure of which is governed by applicable law. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact me and destroy the materials contained in this message. _______________________________________________ This is the System 21 Users (SYSTEM21) mailing list To post a message email: SYSTEM21@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/system21 or email: SYSTEM21-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/system21. _______________________________________________ This is the System 21 Users (SYSTEM21) mailing list To post a message email: SYSTEM21@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/system21 or email: SYSTEM21-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/system21.
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
