Skip to Content
avatar image
Former Member

Queries in Production for Business Users

Hello fellow SAP Security Colleagues,

I am familiar with some of the obvious reasons why query development and execution should be restricted in production and have generally agreed with the restrictions.

However, I wanted to reach out to those of you who have supported a project which either:

A.) allowed business users to create and execute queries in production /or/

B.) allowed queries to be developed and transported to production for use by business users.

I would like more information on how this is working out for your company and what steps you are taking to make it work securely and with little performance issues.

Thank you so much for your feedback!

Edited by: Teresa Lansberry on Feb 5, 2009 3:46 PM

Edited by: Teresa Lansberry on Feb 5, 2009 3:47 PM

Edited by: Teresa Lansberry on Feb 5, 2009 3:48 PM

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

3 Answers

  • Best Answer
    avatar image
    Former Member
    Feb 05, 2009 at 09:59 PM

    Simply not allowed is the best policy I have seen. Same goes for Report painter, Quick viewer, Data browsers, etc.

    This keeps them off the tables and they have a BI system where they can request queries, extract reporting and cook the books in Excel if they want to... 😊

    The bugger is that once you give them such access, they will stop using the correct information systems or even whole reporting systems and create a crows nest of their own queries, which you will struggle to sort out or take away again.

    Cheers,

    Julius

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Former Member

      > Omly use i have allowed so far: let an expirenced ABBAP create a query in DEV. lat business agree that they need teh report then let the quesy code be rewritten by an ABBPER and creat a report program from thtah transport to prodcution and let the prograam be used by endusers.

      I agree with the second comment in this exception as well. The query and report generators do not generate performance optimized code.

      An ABAP developer should take a look at it, and the tables (particularly the size and type) and joins. There are a couple of legendary discussions about this in the ABAP forums already...

      Here is one of them:

      As you can see, having a good ABAPer to do a good job, makes a big difference.

      Cheers,

      Julius

  • Feb 06, 2009 at 09:05 PM

    Hi Teresa,

    I agree with Julius and Auke, but have a fair amount of experience of working with companies who disagree....

    At my current client we have a small project taking place to rationalise the use of queries.

    Until recently almost all users had the access to create and change queries in the production environment. There are approximately 3000 queries and 1500 infosets used, created, 50% of which are used over the previous 12 months. The result of this is that many reporting controls are bypassed and there are many "versions of the truth".

    For legal reasons we now need to secure the data. This also requires robust change control over the queries. The existing queries were transported into the development environment and access to maintain queries has been removed in Prod.

    All new queries are created by a functional expert and then handed over to the development team. The dev team review the query (make sure that it is reasonably efficient etc) and then put in auth checks into the infoset. This is then tested and only when signed off, is transported into the Prod.

    It's not an ideal situation but until most of the reporting has been moved to BI, is reasonably controlled. What it rarely addresses is the need for consistent reporting.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Perhaps I should have added <flame> </flame> tags to my post... 😊

      But the point is that as long as the application makes the correct checks and the choice of transaction or adhoc reporting chooses to use it... then your other application security can easily be hosed.

      If users realy for a valid reason need to see realtime data in a transactional production system at table level, then create a database view for it (tcode SM31) and add your own checks to it as required.

      > For legal reasons we now need to secure the data.

      I also agree with the fact that if there are no requirements, then why protect data. Unfortunately, some of those requirements might not be communicated at first or even known, so to build a concept which excludes them will be like digging your own hole.

      But it is possible. And it does work for a while...

      Cheers,

      Julius

  • avatar image
    Former Member
    Feb 07, 2009 at 03:41 AM

    Thank you all for your feedback. I remain pretty convinced that this is generally not a good idea and will push back on my current project. Have a great weekend!

    Add comment
    10|10000 characters needed characters exceeded