IDMS

 View Only
  • 1.  Unbridled access to your Production CV's SYSCTL file, good or bad, allow or not?

    Posted Mar 15, 2016 06:08 AM

    Do you allow everyone in your site to access your production CV's SYSCTL file or just certain group(s) of people?

     

    If you have it secured from access by anyone, why?

    What are you accomplishing by restricting access to the file?

     

    If you do not restrict access, do you have security measures in place within the CV to stop unauthorized rununits from being started in the CV?

    If so, what mechanism are you using to determine a batch rununit's worthiness of being allowed to access the CV?

     

    Thanks to any and all that answer.



  • 2.  Re: Unbridled access to your Production CV's SYSCTL file, good or bad, allow or not?

    Posted Mar 15, 2016 08:01 AM
      |   view attached

    We give READ access ONLY to IDs defined as batch production – NO USER has ANY access

     

    We have a system setup called ONE-SHOTS where a user can run an adhoc update vs prod – but under a prod ID (with mgr approval)

     

     

     

    Chris Hoelscher

    Technology Architect, Database Infrastructure Services

    Technology Solution Services

    : humana.com

    123 East Main Street

    Louisville, KY 40202

    Humana.com

    (502) 714-8615, (502) 476-2538



  • 3.  Re: Unbridled access to your Production CV's SYSCTL file, good or bad, allow or not?

    Posted Mar 15, 2016 09:03 AM

    SYSCTL is secured in the production environments, except for the DBA group and production batch ID's.  We further secure database files for production to batch ID's only.  Batch ID's can only be submitted thru our scheduling utility. 



  • 4.  Re: Unbridled access to your Production CV's SYSCTL file, good or bad, allow or not?

    Posted Mar 23, 2016 01:51 AM

    The site I (until recently) worked at secured rununits via ACF2 using exit 14. I'm not sure what restrictions were on the SYSCTL file, but I think it was fairly open.

     

    On a BIND Run unit, Exit 14 would issue a #SECHECK on a special resource type with the resource name of the subschema. The user needed execute authority to proceed. On a ready area, exit 14 would check that the user had select authority (if readied in ret) or update authority (when readied in update) on a different resource type with the resource name of the area. If the user failed the #SECHECK, a message was written to the log and the run unit terminated with a xx10 error code.

     

    This required special entries in the SRTT to map the resource types to external security.

     

    There were different resource types for batch and online, though they only had it active for online in one application. The overhead of all the security checks for a busy online environment was too much and  the application & OLQ security was sufficient anyway. Each CV could have different rule types, though they shared some across similar CV's to reduce admin effort.

     

    This did allow quite fine control over what each user could do. It could be setup so that a user could only bind batch run-units using certain subschemas and/or ready only certain areas. But the reality was that it was not necessary to have that level of control and most of the security definitions would have been wild carded and authority granted to groups to keep admin overhead to a minimum. The authority to ready areas in update was quite restricted.