2

The unrestricted rights of administrators

I would like to talk about the very extensive authorizations of the Enterprise and Domain Admins. Although I also have a corresponding product idea/feature request in mind for the problem described below, I am first of all interested in whether other users face similar challenges and how they deal with them.

At our customer, the problem is becoming more and more apparent that an (Enterprise or Domain) Admin implicitly always possesses all roles and therefore also has unrestricted access to all reporting data and reporting artifacts!

In other words, the segregation of duties (SoD) required in most security concepts is currently not possible in Pyramid in my opinion. Or am I missing an aspect here? How do you deal with this?

We can use the Pyramid roles to grant non-admin users very granular authorizations for the content they need and are allowed to access. However, as soon as an employee has to perform even one administrative task, they are also given access to all data secured via the roles by implicitly assigning all roles.

As far as I know, you can take away functional administration areas from domain administrators, such as access to logs or user administration, but not access to certain modules - and, as I said, not the possession of certain roles.

I would be very happy about a lively discussion.

THANKS & regards,
Michael

4 replies

null
    • Customer Solutions Architect
    • Moshe_Yossef
    • 2 wk ago
    • Reported - view

    Hi 

    I had a discussion on this with a client recently.

    They had a request that some data will not be exposed even to the Pyramid Enterprise admins.

    The direction of solution in this case was to implement the security in the underlying database, and define the data source so that it will use the user's identity.

    It sound adjacent to what you're asking, but different.

      • Lead Consultant Advanced Analytics
      • Michael_Daun
      • 2 wk ago
      • Reported - view

      Thanks,!

      We've actually already thought about that. So that would be a kind of two-stage process: as before, non-administrators are given access authorisation to certain data or data models via the role assignment. And for administrators, a database-side check ensures that they can only view data for which a corresponding authorisation has been stored.

      However, I lack a little imagination and certainly also the knowledge to implement such ‘member security’ - the query syntax is generated by the Pyramid Engine! How can a separate check for the authorisations of the executing user be included in the SQL code?

       

      Further questions:

      • Would this also work for data models with direct queries?
      • Do the objects in the database have to be customised?
      • Would the Member Security described in the help also work for admins - or again only for roles?

      Finally, thinking along the lines of a product idea/feature request:

      An admin does not currently need any roles, as he implicitly has all of them. Why is this approach not cancelled? If you want to retain the current status (‘Admin has unrestricted access’), you would only have to explicitly give the admin all roles. If the admin's access to the data is to be restricted, this could be achieved by assigning correspondingly restricted roles.

       

      Regards,
      Michael

      • Customer Solutions Architect
      • Moshe_Yossef
      • 2 wk ago
      • Reported - view

       

      Well, maybe we should take it a step back:

      Enterprise Admins in Pyramid have full access to everything in Pyramid - that is the only way an admin makes sense.

      if you to say that an admin can't view certain data - that has to be done outside of Pyramid - in the database (so it can only be applied in Direct Query, not in IMDB). In the database you create views that use identity to determine permissions - so the admin (and any other user) identifies to the database as himself, and the database views run the tests on what they are allowed to see.

      I think you're actually looking at creating a profile that isn't an admin but has some additional functions - looking at certain logs, activating schedules, managing subscriptions etc. From your message it seems this is the direction you're looking at.

      • Lead Consultant Advanced Analytics
      • Michael_Daun
      • 2 wk ago
      • Reported - view

      THANK YOU for your answers,, I really appreciate it!

      However, I disagree that an administrator without full access to everything would not make sense!

      An example: We have two external employees who work in User Access Management and manage the user accounts at our customer for Pyramid, among others. They configure the rights in Azure AD and then create a corresponding account in Pyramid. Why should these two users have access to the reporting data - including personal customer data that only a few selected users are authorised to access via corresponding roles?

      The same applies to our server admins, who support us with the installation and operation of the servers. Why should these users have access to reporting data? Why does their admin role make no sense without this data access?

      I can accept your decision not to implement a comprehensive segregation of duties. I just don't understand the reasoning! I don't want to be polemical - but for me the question is not yet ‘answered’: How do other customers or consulting firms solve this?

      Regards,
      Michael

Login to reply

Content aside

  • Status Answered
  • 2 Likes
  • 2 wk agoLast active
  • 4Replies
  • 60Views
  • 5 Following