4 Replies Latest reply on Nov 15, 2019 9:15 AM by Mark Francome

    ControlM-related Roles and Responsibilities / user access best practices

    Kelly Briggette
      Share This:

      Curious whether anyone has a ControlM-related roles/resp policy that they would be willing to share. Looking for ControlM access/group per job role per environment...addressing separation of duties ...browse, vs update, vs Admin. We are wanting to streamline and document a policy based on best practices. Any thoughts/info is greatly appreciated.

       

      Requestor

      Apps Dev

      Apps Support

      Apps QA Tester

      Data Center 24x7 Monitoring

      Job Scheduler Admin

      Job Scheduler Software Admin

      DBA

      Cloud Operations

      Cloud Engineer

      Systems Engineer

        • 1. Re: ControlM-related Roles and Responsibilities / user access best practices
          Mark Francome

          Do you have Control-M Server security (i.e. ctmsec) switched on, or is all the admin done via the Enterprise Manager groups?

          • 2. Re: ControlM-related Roles and Responsibilities / user access best practices
            Kelly Briggette

            We use the CCM Security -> Authorizations to manage groups/users.

            • 3. Re: ControlM-related Roles and Responsibilities / user access best practices
              Paul Robins

              It's going to depend on your environment a lot.

              We have one Control-M for our entire dev\test environment. Within this we restrict based on Application name, Sub-Application name (environment; dev, uat, integration etc.), and folder name depending on whether you are a developer, tester, environment manager etc. These permissions were decided by our Production Support team.

              However moving to agile has thrown this into disarray as agile squads are supposed to be able to perform across multiple roles and developers may perform testing and even BAs who previously had no access might be testing.

              I suspect we will have to move to open access per application in dev\test based on which squad owns which application and create some stage gate processes on the way through.

              Luckily Dev is completely separate to Production :-D

              1 of 1 people found this helpful
              • 4. Re: ControlM-related Roles and Responsibilities / user access best practices
                Mark Francome

                Using different CM/EM environments is helpful, although I am interested to read Paul Robins' comments about the "Agile Gods" playing havoc with that approach.

                 

                I have switched on Control-M Server security (ctmsec) whenever possible and this allows you to take a "2 layer" approach to security, i.e. the EM security allows you to control what the various users see, then I use the CM security to control what they can do. In your case you are not using CM security, however you can still get very granular settings from EM security.

                 

                I gave groups access per application name (using access at folder level is also a good way to do it) and use the filter option on the actions to create "browse only" groups. Often this is enough (for groups like the Service Desk) and then you can always increase their access if they need it. Copying the groups is also very helpful, if you fine-tune a group you can then copy it to apply to other situations.

                1 of 1 people found this helpful