3 Replies Latest reply on Oct 4, 2019 1:49 AM by Bentze Perlmutter

    AAPI Security for 'provision' services

    Bentze Perlmutter
      Share This:

      Hi All,

       

      I'm wondering how other sites are handling AAPI Security implications?

       

      1. Any AAPI user needs to have privilege to Login to CCM (you can give them browse on all CCM permissions but they need to be able to login to CCM in order to be able to login to AAPI)

      This is even if they are only going to use AAPI services like deploy, run, and so on that don't have anything to do with CCM.

      2. If they are going to use the provision service, to install and then add agent to Control-M, they need the CCM 'Configuration' privilege.

      So they are then able to login to CCM and do things like modify System Parameters, Pause Control-M, etc., in addition to be able to add agents and modify hostgroups.

      3. There is no way to limit what CTM/Servers they can add agents to? What Host Groups they can modify?

       

      Anyone has faced this yet?

       

      Any suggestions on how to give AAPI users access to provision an agent into Control-M, and remove it when needed, without giving them more privileges than are needed for these tasks?

       

      Anyone raise an RFE with BMC to enhance Privileges to cater for the new types of Control-M users that are introduced to Control-M thanks to AAPI features?

       

      Thanks,

      Bentze

        • 1. Re: AAPI Security for 'provision' services
          Paul Robins

          Hi Bentze, great question!
          You are entirely correct, a user with agent add access (Privileges -> Configuration -> Update) can set the value of certain EM parms, manipulate host groups, even add a new CTM Server to the EM environment!
          This really needs to be addressed by BMC sooner rather than later. We really need to be able to control the channels by which users access Control-M and we need fine control over what functions they can use. We are having similar issues with Control-M Self Service because IOA security has traditionally been performed at a job owner level, not a folder\jobname level. Security is simply not granular or flexible enough.

          One option we are considering is using an API gateway to lockdown which users can access which API URIs, and securing the API at a network level so only the gateway can send requests, but I haven't figured out how that works in reality yet.

          • 2. Re: AAPI Security for 'provision' services
            David Fernandez
            • You are right, as of today, minimum privileges to login and obtain token via AAPI must be “Category : Control-M Configuration Manager” > “Control-M Configuration Manager” = “Full”. But even if someone having AAPI access could login to the CCM (if installed), the rest of permissions/privileges can be limited (setting them to e.g. only Browse or None).

             

            • As an example, In “Category : Control-M Configuration Manager” we can modify the value of "Configuration" to define which operations he is permitted, e.g. if we set it as "Browse", he could niether add nor delete Agents, and with "Update" he could add Agents but not delete them. - Check the following KA which details the provileges required for Control-M Automation API, and the CCM authorizations required for its different services: What privileges are required for Control-M Automation API users

             

            • Finally, watch out for new functionalites coming in v20 and beyond. New RBA (Role Based Authorization) capabilities will allow more granularity when defining what an user is able to do depending on resources (such as Agents, Plugins, Connection Profiles and Run As definitions) he has been assigned.
            3 of 3 people found this helpful
            • 3. Re: AAPI Security for 'provision' services
              Bentze Perlmutter

              Hi Paul and David. Thanks for your replies.

               

              David, I'm definitely looking forward to more granular permissions. This is what I feel is missing at the moment.

              The challenge is not to allow/not allow CCM type permissions via AAPI.

              The challenge is to allow only some CCM type permissions.

               

              For now, instead of giving the user CCM permissions, I gave him "deploy" permissions, and in combination with 'Site Standards' I've allowed him to define/run jobs that call only some CTM/Server utilities like 'ctmping', 'ctm_agstat', 'ctm_agparm' and 'ctmhostgrp'.

               

              Thanks again for your replies and looking forward to v20...

               

              Regards,

              Bentze