4 Replies Latest reply on Mar 7, 2014 10:09 AM by Sean Berry

    Implementing Bladelogic Security

    Robert Stinnett

      We are at the point where we need to start implementing security in BL.  Right now everyone basically logs in with the role of BLAdmin.  We want to start locking this down and breaking folks into groups.

       

      My question for others is how did you approach this?  Is there any best practices?  Any first steps you would suggest?

       

      We want to make sure we are doing this right, and it seems like this is a mighty tall task (but one that has to be done).

       

      Thanks,

      Robert Stinnett

        • 1. Re: Implementing Bladelogic Security

          Segregation of Duties and Separation of Powers:

           

          A very common model follows a functional -tiered model, something like this:

           

          Windows

          -Sr. Admin - All functions

          -Tier 1 - View servers and components, run existing jobs

          -Helpdesk - View servers and components, run specific jobs (like restart service)

          Linux

          -Sr. Admin - All functions

          -Tier 1 - View servers and components, run existing jobs

          -Helpdesk - View servers and components, run specific jobs (like restart service)

          Solaris

          -Sr. Admin - All functions

          -Tier 1 - View servers and components, run existing jobs

          -Helpdesk - View servers and components, run specific jobs (like restart service)

          Security

          -Sr. Admin - view components and servers, run compliance/patch analysis jobs.

          -Jr. Admin - view results

           

           

          Make sense?

          1 of 1 people found this helpful
          • 2. Re: Implementing Bladelogic Security
            Bill Robinson

            there is really no 'right' way to do this - it depends on how your organization controlls access to your systems.  typically rbac is modeled to follow your existing permission or organization structure and then the determination is made about who can create what kinds of objects in bsa - for example having a separate role that manages the patch catalogs and allowing your server admins to only run analysis and deploy patches but not update the catalog.  that may or may not make sense in your environment.

             

            typically when we run rbac workshops we map out what your existing or desired access structure looks like and then start creating rbac objects to match that.

            1 of 1 people found this helpful
            • 3. Re: Implementing Bladelogic Security
              Joe Piotrowski

              Couple of other things I would suggest. If you install the BSA OOTB Content you will see numerous examples of RBAC permissions you can review.

               

              I would also recommend creating a spreadsheet like the one I attached. I created this by exporting all the authorizations. When you create new Roles you can keep track of them, and filter them accordingly.

              • 4. Re: Implementing Bladelogic Security
                Sean Berry

                Robert: make sure to check out this webinar on RBAC to get started: RBAC and Access Control Server Automation Best Practices Webinar

                 

                Next, make sure you've run "blcontent" to stand up the "basic" RBAC content to get some good samples.