SAP Basis / DBA Controls 2520

  • Ok… auditors just now through a fit over the SAP Basis team’s access. Our Basis team (like most SAP Basis teams) have administrator access to our database as part of our required access to fulfill our roles. Now the auditors to revoke our SQL Admin access or want us to prove that we are not doing direct data changes and want some sort of log (they are not happy about our windows admins domain access on the systems either). Well SQL logs don’t provide that information. Additionally they want to further limit our SAP access, but the kicker is of course we are the application administrators so we are the ones who issue access in the first place.
    They say even if the business signs off on this access we will still get a significant deficiency.
    Can anyone provide me any white papers or documentation that will show this access is typical or any REASONABLE way to log and mitigate these concerns?

  • Administrator access on the application, database or operating system level is always tricky.
    From a hypothecial point there is a risk that a person with administrator access could do unautorized changes for various reasons:

    1. obtain a profit or help somebody else to profit
    2. get revenge on the organization because they did not treat him fairly
    3. makes unintended changes/deletions by error
      The important questions are:
    4. To ask when and for which purposes the administrator access is really needed (compared to a more normal user access) and how often it has really been needed in the past
    5. which controls exist to detect that somebody has used the administrator access and what he has used it for (including the prevention of deleting logs of the administrator’s activities)
    6. if needed changes cannot be done by doing them in a development and quality assurances system and then moving them to production.
      If have seen cases where administrator passwords are in a sealed envelope for emergency uses.
      The quantity of activities in the administrator log can be limited if the employees have a more normal personal user account for day-to-day activities and an emergency administrator account for the really tricky access rights whose activities should be logged and reviewed.
      Try to keep reviews of logs and the pains to the IT administrators to a minimum since it is a rather hypothetical and hopefully low risk.

  • gmerkel… thank you for your reply.
    My team is the SAP administration team and I am just well stumped I have never had this come up before and have been in audit controlled environments for years.
    The problem boils down to we install the system and know the master passwords on the operating system, database and application level. Those master accounts have to be kept operational for the system to run. Within the application we can log activity, but on the database level the logs are:
    a) an unreadable binary files and would require a third party tool to even decipher
    b) even if we got some program it would only show commands such as select this record, update this record, etc and there would be no way to know if it was the application using -and-lt;sid-and-gt;adm to do those tasks or one of my team using the account.
    Right now we of course use our own accounts but if they take those away, we could just use the -and-lt;sid-and-gt;adm account.
    I guess I am just sitting here trying to figure out how we can comply and still do our jobs.

  • We’ve had the raised regarding DBAs w/ access to production data. A couple of arguements that we’ve made are:

    1. The number of DBAs that we have is limited (We only have 2).
    2. Processes outside of the ITGC world would timely detect unauthorized data changes. These processes include reconciliations, f/s analytics, budget v actual reviews etc.
      Hope this helps. 😎

  • I agree with Paul that the DBAs and System ADMINS have to be empowered to do their jobs. While there is always a need to ‘trust but verify’, you might look at some of these ideas which may help some:
    – Contact the vendor’s technical support (SAP) and ask for ideas on how to accommodate this special need to see if you realistically meet SOX requirements in accordance with the SOX auditor’s recommendations.
    – Institute special logging on the data bases anytime your special accounts are used to ensure your team doesn’t accidentally or intentionally alter data base information.
    – When you need to physically fix tables (due to a DB corruption error), have procedures in place (maybe a special Emergency User Account) where you could perform this. These are sometimes called ‘Fire ID’ accounts and the password is changed daily by some in another area and an account is checked out only for emergency needs. It’s a very formal process and contains checks-and-balances that usually satisfy many auditors - but you can’t always satisfy them all 😉 😄 … Also include in the procedure, change management and email notifications to key affected parties
    – Ensure that ADMIN account access is as limited as possible (even if you have to eventually throw SAP into it’s own trusted domain if it’s Windows Server based for example). Although, that could be a HUGE project if the process isn’t that vulnerable currently.
    – In many of the systems I’ve worked with in the past, special application security compensated for the all powerful ADMIN accounts. Although I’ve never used this product, I’m sure SAP accommodates this need. Then look at ways you can restrict any updates outside the application (within reason) beyond just those needing to support it.

Log in to reply