&KDSWHU  6HFXULW\ $GPLQLVWUDWLRQ

&RQWHQWV
Overview ................................................................................................................11–2 Audits .....................................................................................................................11–4 Security Layers .....................................................................................................11–6 Operational Security...........................................................................................11–25 Audit Tools ..........................................................................................................11–37 Audit Tasks..........................................................................................................11–57

System Administration Made Easy

11–1

Chapter 11: Security Administration Overview

2YHUYLHZ
The purpose of this chapter is to make you aware of your responsibilities as the R/3 system administrator(s) for security. These responsibilities include: < Protecting the R/3 System < Preparing you for a computer security audit When an audit is performed on an R/3 System, the administrator(s) will be responsible for responding to the audit findings. This chapter is an attempt to prepare you for these audits. Each auditing firm has their own audit procedures and may look at many different items, so we cannot prepare you for everything. However, we will try to prepare you for the core group of items that all firms normally look at. This chapter is only an introduction to computer security and its importance. Although an entire book can be written on this subject, even that would be insufficient. We recommend that you contact and work with all the parties (external auditors, internal auditors, finance department, legal department, and others) who might be affected by system security.

:KDW LV 6HFXULW\"
Security is more than the R/3 authorization (or keeping “undesirables” out of the system). It is concerned with the following issues regarding data: < < < Protecting it from hardware problems Maintaining its integrity Restoring it in the event of a disaster

Security is a broad topic and can be organized in many different ways. Some of the areas covered include: < < < < Keeping unauthorized people out of the system Keeping people out of places that they should not be Safeguarding the data from damage or loss Complying with legal, regulatory, and other requirements

Each of these areas can be further divided. .HHSLQJ 8QDXWKRUL]HG 3HRSOH RXW RI WKH 6\VWHP This area is what we usually think about as security and includes the R/3 authorization concept, operating system and network logon security, and physical security. .HHSLQJ 3HRSOH RXW RI 3ODFHV :KHUH 7KH\ 6KRXOG 1RW %H This area covers users having access to more parts of the system and to more data than they need to perform their job. The data may not be damaged but accessing and revealing this data could be equally damaging.

11–2

Release 4.6A/B

Chapter 11: Security Administration Overview

Examples of this sensitive data include: < < < Your company’s customer list, contacts, and sales volume. This information could be used by a competitor. Your employees’ personnel data. There are privacy laws that protect this type of data. Financial performance data, such as quarterly financial statements. There are strict SEC rules governing insider trading (see below for a definition of insider trading). Items specified in contracts with customers, vendors, or other parties.

<

6DIHJXDUGLQJ WKH 'DWD IURP 'DPDJH RU /RVV There are two major sources of damage: < Accidental, such as: ΠLoading test data into the production system. This situation happens, unfortunately, more often than people admit. ΠA hardware failure. ΠA fire that destroys the data center. ΠArson ΠA flood, hurricane, earthquake, tornado, or other regional natural disasters. Deliberate, such as: ΠA disgruntled employee who deletes or damages files from the system. ΠA hacker who deletes or damages files from the system.

<

&RPSO\LQJ ZLWK /HJDO 5HJXODWRU\ DQG 2WKHU 5HTXLUHPHQWV
:KDW

Other reasons for security are defined by laws, contracts and other parties. Security is a sensitive issue, and it has legal implications. One good example of security is insider trading. Before defining insider trading, we have to first define insider knowledge or inside information. Insider knowledge or inside information means you have information, which is not known or available to the general public. If the information is known to the general public, it could affect the stock price. Insider trading is using inside information to buy or sell stock and make a profit or reduce a loss. Even if you do not profit from the sale, you could be held liable.

System Administration Made Easy

11–3

Chapter 11: Security Administration Audits

([DPSOH  In one company, an employee’s spouse passed on inside information to a relative, who purchased the stock, then sold the stock at a profit after the earnings announcement. That relative made a profit by buying the stock before the earnings announcement (insider trading). The SEC fined the spouse and the relative. The spouse was guilty of providing insider information to the relative, who then made the profit on the sale of the stock. Both, therefore, were guilty of insider trading.

([DPSOH  The IS director of a company asked for authorization to log into the production R/3 System. This request raised the concern of the accounting/finance department. Access to financial information is typically on a “need-to-know” or “need-to-access” basis, and the IS director did not need to access the production R/3 System. “Red flags” went up when he started asking about financial performance information (quarterly earnings), well before this information was made public. He was asking for insider information.
Ã

+RZ

You will need the assistance of your company’s legal department.

$XGLWV
As a system administrator, you will be affected by two audits: < Security < Financial

)LQDQFLDO $XGLW
:KDW

A financial audit is a review of your company’s financial statements by a Certified Public Accountant (CPA) in the U.S., or their equivalent in other countries. The purpose of the audit is to issue an opinion on the company’s financial statements. This opinion essentially states that the financial statement represents fairly the financial position of the company. A financial audit is usually not an option. If your company’s stock is traded on the stock market, the audit is required by the Securities and Exchange Commission (SEC) in the U.S., or its equivalent in other countries. If your company is private, a financial audit could be required by creditors. As a part of the financial audit, the CPA will typically do a security audit of R/3 and the associated systems. The purpose of the security audit is to determine how much reliance can

11–4

Release 4.6A/B

Chapter 11: Security Administration Audits

be placed on the data in the R/3 System. Your external auditors will evaluate your system security to determine what audit tests to perform and how much testing they will have to do.
:K\

If their evaluation results are not good, they may need to increase the scope of their audit. This increased scope also increases the cost of the audit, and the extra work could delay the completion of the audit. In a worst case scenario, they could determine that the security is so weak that they cannot issue an opinion on the company’s financial statements. This situation is really bad. Because of the effect on the stock price (down) that this inability to issue an opinion will probably cause, the chief financial officer (CFO), and likely the president, will be quite upset. Is your resume updated?

6HFXULW\ $XGLW
:KDW

A security audit is performed specifically to test the security of the R/3 environment. This audit is usually done as a part of the financial audit or to comply with government or other regulatory agencies. It can also be done by your company’s internal audit group.
:K\

As a security audit. As a part of the financial audit, the CPA will typically do a security audit of R/3 and the associated systems. The purpose of the security audit is to determine how much reliance can be placed on the data in the R/3 System. Your external auditors will evaluate your system security to determine what audit tests to perform and how much testing they will have to do. The audit is also done to test the security of confidential data, such as: < < < < Financial information Customer data Product information Company personnel data (from the HR module)

$XGLW &RQVLGHUDWLRQV
:KDW

Audit considerations are the things that auditors will look at when they do the financial audit, or a computer security audit. Some of these considerations are: < < Physical security Network security

System Administration Made Easy

11–5

Chapter 11: Security Administration Security Layers

<

<

User administration procedures ΠAdequate segregation of duties ΠProper training ΠPasswords Data security ΠProtection from hardware failure; mirrored drives, RAID, fail-over, HA, etc. ΠBackup and recovery procedures ΠProtecting the production system from unauthorized changes ΠLocking dangerous transactions

:K\

These tasks are done to support the financial or security audit. Without knowing what the auditors will look for, you cannot properly prepare yourself, and protect the system. 1RWH This section is not an all-inclusive SAP security audit. It is only to make you aware of some of the things that could be reviewed as part of a security audit. We recommend that you work with your auditors before the financial audit, to review your system and bring it up to acceptable standards for the audit.

6HFXULW\ /D\HUV
To make security more manageable, we have chosen to use the security layer model, one of the many existing security models. It uses the following three major layers of security:

Data Security Access security

<

Access security ΠPhysical security ΠNetwork security ΠApplication security Operational security Data security

Operational Security

< <

11–6

Release 4.6A/B

Chapter 11: Security Administration Security Layers

$FFHVV 6HFXULW\
3K\VLFDO 6HFXULW\
:KDW

Physical security controls the physical access to R/3 and network equipment. Like the graphic on the previous page, to get to the inner circle, an intruder must penetrate the outer circles as follows: < < < Onto the property or site Into the building Into the areas of the building where the users are or where the equipment is located ΠFinance ΠMIS ΠComputer operations Into the specific equipment rooms within these areas of the building ΠServer room ΠWiring closet ΠNetwork room

<

:K\

This layer is probably the most important. If an intruder can physically access your equipment, all your other security layers can be bypassed. When this layer is bypassed: < < < < Equipment can be physically damaged or destroyed. The system can be accessed from the operators console (and could bypass strong network security). Equipment can be removed. Data could be hacked.

Without physical access to the equipment, the intruder must electronically access the system through the network.
+RZ

The R/3 equipment should be located in a secured room. Access to the room should be only through a locked door. It is crucial to control who is allowed access to the server room. If you have electronic card key access, periodically audit the access log for the server room. The periodic review of the access log may be an item for which auditors will test.

System Administration Made Easy

11–7

Chapter 11: Security Administration Security Layers

1HWZRUN 6HFXULW\
:KDW

Network security also has sublayers of security. The goal of this security type is to control the following types of access to the network: < External < Logon This type controls on-site and remote access and where on the network users can go once they gain access.
:K\

If intruders access your network, they could have an electronic link to your computers.
+RZ

Use network security specialists to properly configure the various access points into your network and, once users are on the network, control their movements. Some of these points of control are: < Outside access ΠDial-in access ΠInternet access ΠOther remote access methods, such as VPN Network login access This access method is the actual logon to the network (for example, the NT domain). Access to portions of the network. ΠNT domains

< <

1RWH We recommend that you have: < < A dedicated SAP domain where only the administrators are allowed to directly log onto. Other domains where users will log onto, trust the SAP domain, but the SAP domain does not trust other domains.

Œ

Router tables This table can be used to control (by IP address) which users can access the SAP servers.

11–8

Release 4.6A/B

Chapter 11: Security Administration Security Layers

$SSOLFDWLRQ 6HFXULW\
:KDW

Like the other layers, application security has sublayers of security, which controls: < < < < The ability to log into the application, such as logging into R/3 Where a user can go in the application What a user can do in the application What a user can do based on the system data in the application [such as the R/3 System (for example, limiting the user to company 001 and cost center 200)] R/3 security functions at this layer.
:K\

This layer provides the fine or specific security of what a user can do [for example, read (not change) accounting data for only cost center 200 in company 001].
+RZ

Using R/3 application tools such as: < < < < Profile Generator (transaction PFCG; for more information, see Authorizations Made Easy) Audit Information System (transaction SECR; see page 11–37) Security Audit Log (transaction SM19/SM20; see page 11–44) Delete Old Audit Logs (transaction SM18)

2SHUDWLRQDO 6HFXULW\
:KDW

This layer is security at the operational or user level. Because it is primarily procedures and control, there are few computer or systems issues related at this level.
:K\

These are organizational and people issues, which are always a problem, because people need to comply with guidelines and rules. The problem is, of course, that some people never want to comply with guidelines.
+RZ

Some of the methods of operational control are: < < < < Segregation of duties Preventing sharing of user IDs Password standards Log off when away from the computer, such as during lunch or at the end of day

System Administration Made Easy

11–9

Chapter 11: Security Administration Security Layers

'DWD 6HFXULW\
This layer is closely knit to the material in chapter 2, because disaster recovery is an integral part of data security.
:KDW

Data security is the protection of the data. < Data on the servers Here we are protecting the data on the server from damage or loss. This protection is accomplished in various ways. The goal is to prevent or minimize loss of data in a disaster. < Backup data The goal of this security layer is to preserve application data (usually on tape) so that the system can be recovered. The backup tapes must be stored safely to: ΠPreserve the backup tapes in the event of a disaster ΠProtect the backup tapes from theft Disaster Recovery For more information on disaster recovery, see chapter 2.
:K\

<

It is easier to be proactive and prevent a problem than to recover from it. To remain proactive: < Reduce the chances of losing data. The first place to do it is on the server. < < Protect backup data from damage or loss. Ensure that, if there is a disaster, the system be completely recovered.

+RZ

<

Data on the servers The goal is to prevent or minimize loss of data in a disaster. Some of the items below can be referred to as High Availability (HA) items: ΠRAID arrays for drives ΠRedundant equipment ΠUsing reliable equipment and vendors ΠPremium hardware support agreements for the production system The following are facilities-related items: ΠUninterruptible Power Supplies (UPS) ΠFire detection and prevention devices

11–10

Release 4.6A/B

Chapter 11: Security Administration Security Layers

Œ Œ

Intrusion alert Environmental alerts

<

Backups ΠBackup tapes should be sent to a secure, off-site data storage facility.
Œ

This step protects the backup data from damage or destruction a disaster. Tapes at both the off-site backup and the on-site tape storage facilities must be secured to prevent the theft of the backup tapes. If the backup tapes were stolen, the data can be restored and hacked. Using database tools, most R/3 security could be bypassed by directly reading the tables.

$SSOLFDWLRQ RU 5 6HFXULW\
&RQWUROOLQJ $FFHVV WR 5 Also see the Password section in this chapter. 3UHYHQW 0XOWLSOH 8VHU /RJLQV
:KDW

This process prevents users from logging onto the system multiple times. Multiple user logons is when several users are sharing a user ID, or someone is using a user’s ID without the user’s knowledge. Preventing multiple user logons is not allowing more than one R/3 logon from one user ID.
:K\

If several people share a user ID: < < You do not know who created a problem. This situation is an audit security issue.

+RZ

Set the disable multi-login parameter (login/disable_multi_gui_login) in the system profile. You can “allow” specific users to log on multiple times by entering their user IDs in the parameter login/multi_login_users separated by commas and no spaces.

3UHYHQWLQJ &KDQJHV LQ WKH 3URGXFWLRQ 6\VWHP
:KDW

The production system should be set to Not modifiable. The “locks” on the system should be set so that configuration changes (client-independent and client-dependent) cannot be made directly into the production system. The purpose for this setting is to ensure that all changes are completed in a controlled manner.

System Administration Made Easy

11–11

Chapter 11: Security Administration Security Layers

In the development pipeline, changes are: 1. Made in the development system 2. Tested in the development system 3. Transported from the development system to the test system 4. Tested in the test system 5. Transported from the test system to the production system This procedure ensures that changes are properly tested and applied to the systems in the pipeline. (A pipeline is the environment where development is moved from the development system to the quality assurance system, and finally to the production system.)
:K\

Configuration changes should not be made directly into the production system. This restriction maintains the integrity of the production system. If changes are made directly into the production system, it may “break” because the change: < < Was not tested Is not the same as the one made in the development system

The goal is to protect the production system from changes, without the changes being properly tested and to preserve the integrity of the pipeline. If changes are made into the production system, the development and testing pipeline could become out of sync with the production system. If the pipeline is out of sync, it get difficult to develop and test with any certainty that things will not be different in the production system. All changes should be made in the development system and then transported through the pipeline into production. In this way, all systems get the same changes. A common excuse is that making changes directly into the production system, “takes too long to transport the fix.” By making changes directly into the production system, you: < < Create an “out of sync” landscape, where the change made to the production system is not the same as the changes made to the development or test systems. Allow emergency transports to occur at any time, with coordination.

([FHSWLRQV

Infrequent exceptions occur when: < < There is no mechanism to transport the changes. An SAP note requires the direct change.

11–12

Release 4.6A/B

Chapter 11: Security Administration Security Layers

When a change cannot be transported, the following procedure should be used: 1. Verify that the change cannot be transported. Some objects may use an ABAP program to transport the object. 2. “Unlock” the system (to make it modifiable). 3. Make the change. 4. Immediately re-lock the system. 5. Make the same changes to all other systems. Use this procedure only if a change cannot be transported.

Manual entry always increases the chance of making an error.

6HWWLQJ WKH 3URGXFWLRQ 6\VWHP WR ´1RW 0RGLILDEOHµ 7UDQVDFWLRQV 6( 6&&
:KDW

There are switches that prevent changes from being made in the system. In the production system, these switches should be set to Not modifiable. The purpose of this setting in the production system is to make sure that changes are made using the development pipeline. With this procedure, changes are properly tested and applied to the systems in the pipeline.
:K\

Objects should not be modifiable in the production system. This rule protects the production system from object and configuration changes before being tested. By setting the production system to Not modifiable, before the integrity of the pipeline is preserved.
+RZ

There are two transactions (SE03 and SCC4) that you will use to set the system to Not modifiable. (These transactions can also be used for other tasks.)

System Administration Made Easy

11–13

Chapter 11: Security Administration Security Layers

&OLHQW,QGHSHQGHQW &KDQJHV 7UDQVDFWLRQ 6(
Ã

*XLGHG 7RXU

1. In the Command field, enter transaction SE03 and choose Enter. The menu path to access this screen is extremely complicated, which is why it is not included. 2. Select Set System Change Option. 3. Choose .
3

2

4. Under Global setting, choose : a. To lock the system, select Not modifiable. b. To unlock the system, select Modifiable (selected in this example). 5. Choose .
5

4

11–14

Release 4.6A/B

Chapter 11: Security Administration Security Layers

&OLHQW,QGHSHQGHQW DQG &OLHQW'HSHQGHQW &KDQJHV 6&&
Ã

*XLGHG 7RXU

1RWH This method also locks the client-dependent changes. 1. In the Command field, enter transaction SCC4 and choose Enter (or from the SAP standard menu, choose Tools → Administration → Administration → Client administration → SCC4-Client maintenance). 2. Choose .

2

3. To continue, choose

.

3

System Administration Made Easy

11–15

Chapter 11: Security Administration Security Layers

4. Select the client number (for example, 500). 5. Choose .
5

4

To Lock a Client (Not modifiable): 6. Under Changes and transports for client-dependent objects, select No changes allowed. 7. Under Client-independent object changes, choose and select No changes to Repository and clientindependent custom obj. 8. Under Protection: Client copier and comparison tool, choose and select Protection level 2: No overwriting, no external availability. 9. Choose Save.
9

6

7

8

11–16

Release 4.6A/B

Chapter 11: Security Administration Security Layers

To Unlock a Client (Modifiable): 6. Under Changes and transports for client-dependent objects, select Automatic recording of changes. 7. Under Client-independent object changes, choose and select Changes to Repository and client-ind. Customizing allowed. 8. Under Protection: Client copier and comparison tool, choose and select Protection level 0: No restriction. 9. Choose Save.
6 9

7

8

9HULI\LQJ WKDW 'DQJHURXV 7UDQVDFWLRQV $UH /RFNHG
:KDW

“Dangerous transactions” could: < < < Damage or corrupt the system Present a security risk Adversely impact performance

:K\

If users accidentally access these transactions, they could corrupt or destroy the R/3 System. < In a production system: Access to dangerous transactions is more critical in the production system than the development or test systems. This criticality is because of live data and the company’s operational dependency on the R/3 System. In a developmental system: Certain transactions should be locked in the production system, but not in the development, test, or training systems. Standard security normally prevents access to these transactions, but some administrators, programmers, consultants, and functional key users could access them depending on which system they are. In these cases, the transaction lock provides a second line of defense.

<

System Administration Made Easy

11–17

Chapter 11: Security Administration Security Layers

There are over 48,000 English transaction codes in the R/3 System. To manage such a large number of transactions, lock only the critical ones. Your functional consultants should supply you with any additional critical transactions in their modules. The table below is organized with input from Basis consultants and users and lists transactions that we recommend you lock. The transactions are categorized by the following risk categories: < < < Dangerous Security-related Performance impact Description Document Archiving Bank Master Data Archiving G/L Accounts Archiving Customer Archiving Vendor Archiving Document Archiving Transaction Figures Archiving Profiles: Initial screen Maintain Authorizations: Object Classes Archive Cost Centers (all) Archive cost centers (plan) Archive cost centers (line items) Archive admin: cost centers (line items) Archive admin: completely cancelled doc Archive admin: cost centers (all) Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Reset Transaction Data (delete transaction data) Maintain Users: Initial Screen Profiles: Initial screen X X X X X X X X X X X X Dangerous X X X X X X X X X Security Performance

Transaction F040 F041 F042 F043 F044 F045 F046 GCE2 GCE3 KA10 KA12 KA16 KA17 KA18 KA20 O001 O002 O016 OBR1 OBZ7 OBZ8

11–18

Release 4.6A/B

Chapter 11: Security Administration Security Layers

Transaction OBZ9 OD02 OD03 OD04 OIBA OIBB OIBP OMDL OMDM OMEH OMEI OMG7 OMI6 OML0 OMM0 OMNP OMSN OMSO OMSZ OMWF OMWG OMWK OOPR OOSB OOSP OOUS OP15 OP29 OPCA

Description Maintain Authorizations: Object Classes Maintain Authorizations: Object Classes Profiles: Initial screen Maintain Users: Initial Screen Maintain Authorizations: Object Classes Maintain Users: Initial Screen Profiles: Initial Screen Maintain Users: Initial Screen Profiles: Initial Screen Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Maintain Authorizations: Object Classes Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Profiles: Initial Screen Change View "User Authorizations": Overview Change View "Authorization Profiles": Overview Maintain Users: Initial Screen Profiles: Initial Screen Maintain Users: Initial Screen Maintain Users: Initial Screen

Dangerous

Security X X X X X X X X X X X X X X X X X X X X X X X X X X X X X

Performance

System Administration Made Easy

11–19

Chapter 11: Security Administration Security Layers

Transaction OPCB OPCC OPE9 OPF0 OPF1 OPJ0 OPJ1 OPJ3 OSSZ OTZ1 OTZ2 OTZ3 OVZ5 OVZ6 OY20 OY21 OY22 OY27 OY28 OY29 OY30 SARA SCC5 SE01 SE06 SE09 SE10 SE11 SE13 SE14

Description Profiles: Initial Screen Maintain Authorizations: Object Classes Profiles: Initial Screen Maintain Users: Initial Screen Maintain Authorizations: Object Classes Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Maintain Authorizations: Object Classes Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Maintain Users: Initial Screen Profiles: Initial Screen Maintain Authorizations: Object Classes Profiles: Initial Screen Maintain Users: Initial Screen Maintain Users: Initial Screen Maintain Users: Initial Screen Maintain Users: Initial Screen Maintain Users: Initial Screen Archive Management: Initial Screen Client delete Transport Organizer System Table maintenance Workbench Organizer Customizing Organizer Data Dictionary maintenance Maintain Storage parameters for table Utilities for dictionary tables

Dangerous

Security X X X X X X X X X X X X X X X X X X X X X

Performance

X X

X

X

X X X

11–20

Release 4.6A/B

Chapter 11: Security Administration Security Layers

Transaction SE15 SE16 SE17 SE38 SM49 SM59 SM69 ST05 SU12

Description Data Dictionary Information System Data Browser General Table display ABAP workbench External OS commands Maintain RFC destinations External OS commands SQL trace Delete All Users

Dangerous

Security

Performance

X X X X

X X X X

The following table shows dangerous transactions that probably cannot be locked because they are (or could be) used regularly. These transactions may have other valid reasons for use in a production system—but because of the potential danger, need to have restricted access. Transaction RZ10 SA38 SM04 SM12 SM13 SM30 SM31 STMS SU01 SU02 SU03 Description Edit System Profiles ABAP Workbench User Overview System Locks Update Terminates Table Maintenance Table Maintenance Transport Management System User Maintenance Profiles: Initial Screen Maintain Authorizations: Object Classes X X X X X X X X Dangerous X X X Security Performance

Table TSTCT contains the transaction codes and the name of the transaction. The current content is over 93,000 entries in the table, with over 48,000 in English.

System Administration Made Easy

11–21

Chapter 11: Security Administration Security Layers

+RZ

Create and maintain a list of the following information: < < < < Which transactions were locked? Why are they locked? Who locked them? When were they locked?

Maintaining the above-mentioned information will be important, because someone will invariably want to know who locked the transaction and why it was locked.

*XLGHG 7RXU

1. In the Command field, enter transaction SM01 and choose Enter (or from the SAP standard menu, choose Tools → Administration → Administration → SM01 Transaction Code Administration). 2. Enter the transaction code you want to lock (for example, SE14) 3 in the search field at the bottom of the TCode column. 3. Choose .

2

11–22

Release 4.6A/B

Chapter 11: Security Administration Security Layers

4. Use the locked checkbox: < To lock a transaction, select the transaction. < To unlock a transaction, deselect the transaction. 5. Choose .
4 5 6

6. Choose Back.

Check which transactions you are locking. You could accidentally lock yourself out of a key transaction, which would prevent you from unlocking this or other transactions.

Access to transactions can also be controlled by building security authorizations on the security object S_TCODE under Cross application authorization objects.

System Administration Made Easy

11–23

Chapter 11: Security Administration Security Layers

7R /LVW /RFNHG 7UDQVDFWLRQV 1. In the Command field, enter transaction SECR and choose Enter. 2. Select Complete audit. 3. Choose .
3 2

4. Expand the following menu path: Audit Information System (AIS) → System Audit → Development / Customizing → Transactions → Locked Transactions: Display. next to Locked 5. Choose Transactions: Display.
4

5

11–24

Release 4.6A/B

Chapter 11: Security Administration Operational Security

6. Verify that the following are selected: < Locked < Transactions < Menu transactions < Parameter transactions < Report transactions 7. Choose .

7

6

This screen shows the list of locked transactions.

2SHUDWLRQDO 6HFXULW\
This section describes selected operational security issues.

6HJUHJDWLRQ RI 'XWLHV
:KDW

There are standard audit guidelines that cover job or task combinations that are considered “risky” or that reduce internal controls. Some of these combinations are: < < < Accounts Payable and Check Generation Accounts Receivable and Cash Receipts ABAP development and transport control

System Administration Made Easy

11–25

Chapter 11: Security Administration Operational Security

Your external auditors should help you define these risky combinations. Testing for segregation of duties is a standard audit procedure.

:K\

Accounts Receivable and Cash Collection The purpose is to separate the person who collects and handles the cash from the person who keeps the records of what a customer owes. In this combination, the cash received from the customer could be pocketed and the amount written off the customer’s account. This separation explains why, in a restaurant, the waiter is not also the cashier, or why a mechanic must get spare parts from a storekeeper.
+RZ

The review of segregation of duties should be completed with the various user owners (key users of each functional area). Out of necessity, smaller companies must assign multiple functions to a single person. Be aware of the potential security risks in this situation. If you must combine functions, combine them in a way that minimizes risks.

5HVWULFWLQJ $FFHVV WR 6$3 RU '',&
:KDW

These are system user IDs that have restricted uses for specific purposes.
:K\

There are certain functions that can only be performed by SAP* or DDIC. If an R/3 user requires similar functionality, they should have a copy of the SAP* profile. These users should be grouped as “super users,” with the appropriate security approvals. The security profile for SAP* is SAP_ALL. This profile is extremely powerful because it grants the user complete access to the system. For more information, see chapter 12, Recommended Polices and Procedures: System Administration. A user with user administration rights cannot change the password to gain access to a user ID and then change it back to the original password. Passwords are not visible to the administrators, so they cannot restore the original password if they do not know it. At the next logon, the owner of the user ID will know that the password has been altered because they will be unable to log on with their current password.

11–26

Release 4.6A/B

Chapter 11: Security Administration Operational Security

+RZ

1. Log on using SAP* and DDIC to determine if someone has changed the password. 2. Periodically change the password for these users in all: < < Systems Clients in those systems

This step prevents a person who knows the password from accessing the system. 3. Update the secured password list. 4. Verify that the system profile parameter login/no_automatic_user_sapstar has been configured, to prevent the use of the automatic user sap*. If the user ID has been deleted, this step prevents the “backdoor” usage of user sap*.

&KDQJH 0DQDJHPHQW
:KDW

Change management is the process of controlling what changes are made to the system. In this context, “system” refers to the entire system environment, not just R/3.
:K\

One aspect of security is to control and know what changes are made to the system.
+RZ

Item of concern: < Is there a change management procedure for changes being made to the R/3 System? < < Is a QA testing process in place? Are reviews and approvals required to move changes into the production system?

6KDULQJ RI 8VHU ,'V
:KDW

This process occurs when more than one person uses a single user ID.
:K\

This issue is a security concern because: < < < There is no way to tell who is doing the activity. If there is a training problem, you do not know who needs training. If there is a deliberate security breach, there is no way to track the responsible party.

2WKHU

Despite the cautionary statements above, there are a few situations where it is not practical to have individual user IDs. These situations must be treated individually and with management and internal audits review and approval.

System Administration Made Easy

11–27

Chapter 11: Security Administration Operational Security

([DPSOH $ :DUHKRXVH In a warehouse, there is one computer and several employees who use that computer to post their warehouse transactions such as goods issued, goods received, etc. This process occurs because the user ID is used to log on, not at the individual transaction level, but the R/3 System. For each transaction that the warehouse employee access, it is impractical to log on to R/3, access transaction, and log off from R/3. The alternative is to have a computer for each warehouse person, although this step may not be economically justified.
+RZ

To prevent a user ID from being shared, the system profile parameter (login/disable_multi_gui_login) can (and should) be set. Parameter values are: < < 1 (to block multiple logins) 0 (to allow multiple logins)

We recommend that this value be set to “1” to prevent multiple logins under the same user ID.

3DVVZRUG ,VVXHV DQG 7DVNV
The password is the users key to accessing R/3. Like the key to your house, safeguarding this key is important to keep “undesirables” out. Your company should have a clear and practical company password policy, which should be distributed to all users informing them not to use easy-to-guess passwords. A password policy that is too restrictive or difficult to comply with could defeat the purpose of this policy. Users will write their passwords down and leave it in an easily seen place, which means you have lost your security.

11–28

Release 4.6A/B

Chapter 11: Security Administration Operational Security

6HWWLQJ 3DVVZRUG 6WDQGDUGV 8VLQJ 7UDQVDFWLRQ 5=
:KDW

There are security parameters for the user’s password (for example, the minimum password length, the time interval that the user must change their password, etc.). The following is a list of the most important password parameters: < Minimum password length: login/min_password_lng A longer password is more difficult to break or guess, so the standard is usually five (5) characters. Password expiration time: login/password_expiration_time This time period is the limit before users must change their password. Œ Auditors usually recommend 30 days. Œ A practical number that customers use is 90 days. Password lockout: login/fails_to_user_lock This parameter locks out users who, after a specified number of times, try to logon with an incorrect password. Users are usually locked out after three failed attempts.

<

<

:K\

Properly assigned parameters will make it more difficult to break into the system.

Your external auditors may check to see if you have set the security parameters.

+RZ

To set up password parameters, maintain system profiles with transaction RZ10 (for more information on this transaction, see chapter 20). (OLPLQDWLQJ 6RPH (DV\ 3DVVZRUGV
:KDW

There are certain passwords (for example, 123, QWERTY, abc, sex, sap, <your company name>) that are well known or easy to guess. You can prevent these passwords from being used by loading them into a table (USR40) that the system checks when the user attempts to save a new password. Table USR40 is only a basic level of password security and is maintained manually. There are third-party password security programs that can be integrated into R/3.

System Administration Made Easy

11–29

Chapter 11: Security Administration Operational Security

:K\

A password is the key to enter the system, similar to the key you use to enter your home. If users choose easy-to-guess or well-known passwords, security is compromised and your system is potentially at risk.

Your external auditors may check to see if you have a mechanism to secure against users with “easy-to-guess” passwords.

+RZ

By maintaining the table of prohibited passwords. 0DLQWDLQLQJ D 7DEOH RI 3URKLELWHG 3DVVZRUGV
:KDW

A table of prohibited passwords is a user-defined list of passwords that are prohibited from being used in the R/3 System. This table is not a substitute for good password policies and practices by the users. Interaction occurs between a system profile parameter and the table of prohibited passwords. If the minimum password length is set to five characters, there is no reason to prohibit passwords like “123” or “SAP,” because these passwords would fail the minimum length test. However, if company security policy requires it, you could include all passwords that are considered “risky” in the table. The following is a list of easily guessed passwords that cannot be put into any table: < < < < < < < <your name> <your spouse’s name> <your child’s name> <your pet’s name> <your car’s license plate> <your driver’s license number> <your social security number>

:K\

There are many lists circulating of commonly used user passwords. If one of these passwords is used, the chances of an unauthorized person accessing a user’s account increases.
+RZ

Changes will be made to table USR40 using transaction SM31, the general table maintenance transaction. (For more information on this transaction, see chapter 19, Change Management:

11–30

Release 4.6A/B

Chapter 11: Security Administration Operational Security

Table Maintenance.). This change creates a transport that can then be transported throughout the landscape.

Keep a log of changes made to this table in your security log. A few suggestions for table entries are: < < < < < < < < < < < SAP GOD ABC QWERTY SEX XYZ PASSWORD 123 12345* 54321* *12345*

Other table entries include: < < < < < < Days of the week (Monday*, Tuesday*, Mon*, Tue*, etc.) Months of the year (January*, February*, Jan*, Feb*, etc.) <your company name> <your product names> <competitors names> <competitors products names>

5HFRUGLQJ 6\VWHP 3DVVZRUGV We recommend that you never write down passwords, except for the: < < < Critical nature of the R/3 System. Many systems, clients, and all the other areas where passwords are required. Need to access the system if the SAP system administrator(s) is not available.

System Administration Made Easy

11–31

Chapter 11: Security Administration Operational Security

5HFRPPHQGHG 3URFHVV

<

All passwords for all system IDs should be: ΠRecorded ΠPlaced in a sealed envelope ΠPut in a company safe (possibly both an onsite and offsite safe) that has restricted access. Only a select list of company personnel should have access to this information. User IDs that are used or needed to maintain the R/3 System include: ΠSAP* ΠDDIC ΠSAPCPIC (see note 29276) ΠEarlyWatch (client 066) ΠAll user-created administrative IDs ΠAny other non-SAP user ID that is required to operate the system, such as for the operating system, the database, and other related applications. The password list should be updated and replaced whenever passwords are changed.

<

<

Two people should prepare the list, change the password, and verify the new password— one user ID at a time. If the recorded password is wrong, those “keys” are lost, and you may not be able to log on to the system. Following are sample password tables: Server SAPR3T SID TST Client 000 User ID SAP* DDIC <SID>ADM SAPCPIC 001 SAP* DDIC <SID>ADM SAPCPIC 066 SAP* <SID>ADM Earlywatch 100 SAP* DDIC Password Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass

11–32

Release 4.6A/B

Chapter 11: Security Administration Operational Security

Server

SID

Client

User ID BATCH1 <SID>ADM SAPCPIC

Password Newpass Newpass Newpass

All systems should have entries for clients 000 and 001. In addition, the production system should have an entry for client 066. Clients 000 and 001 are default clients in all systems, and client 066 is the EarlyWatch client and may not exist in every system.

Where NT

User ID Finance/DEVADM Finance/PRDADM

Password Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass Newpass

SQLserver

sa sapr3

UNIX

root <SID>ADM

Oracle

system SYS OPS$<SID>ADM OPS$SAPSERVICE<SID> SAPR3

System Administration Made Easy

11–33

Chapter 11: Security Administration Operational Security

*XLGHG 7RXU

To change the password for a user ID: 1. In each instance and each client, log on under the user ID to change the password. 2. In Client, enter the client number (for example, 500). 3. In User, enter the user ID you want to change (for example, sap*). 4. In Password, enter the current password. 5. Choose New password.
5

2 3 4

6. Enter the new password twice in the popup window.
6

7

Be careful when you enter the new password. It is easy to enter the password incorrectly or to make the same error twice (for example, user versus users and the versus teh). 7. Choose .

At this point the logon will proceed as normal.

11–34

Release 4.6A/B

Chapter 11: Security Administration Operational Security

8. Record the new password in the password table. 9. Log on using the new password to verify it. At this point, if the new password fails, use another administrative user ID to reset the password. This reason is why password changes should be made one user ID at a time.

This process must be repeated for every system and client in which the user ID has an entry. With Central User Management, you can manage users across all systems (for more information, see Authorizations Made Easy, Release 4.6). 2SHUDWLQJ 6\VWHP /HYHO At the operating system level, the following user IDs should have their passwords changed: 17 In some places, NT is case sensitive (for example, at the initial login screen).
8VHU ,'V

< <

<SID>ADM SAPService<SID>

6HUYLFHV

<

SAP These services will either use user ID <SID>ADM or SAPService<SID> ΠSAP<SID>_<instance> ΠSAPOsCol ΠSAProuter Oracle ΠOracleService<sid> ΠOracleTNSListener80 The default user that the Oracle services runs under is system SQLserver MSSQLServer ΠSQLServerAgent
Œ

<

<

The user ID that they run under is either <SID>ADM or SAPService<SID> < Informix ΠINFORMIX-OnLineDynamicServer ΠINFORMIX-OnLineMessageService DB2 DB2-DB2DA400

<

System Administration Made Easy

11–35

Chapter 11: Security Administration Operational Security

81,;
8VHU ,'V

< <

<sid>adm root

6HUYLFHV

ora<sid> 'DWDEDVHV For the databases, the following user IDs should have their passwords changed: '% NT/DB2 (see SAP note 80292) ,QIRUPL[ See note 15399 0LFURVRIW 64/ 6HUYHU < < < See SAP note 28893 sa sapr3

2UDFOH81,; User IDs: < < < SAPR3 SYS SYSTEM

8VHIXO 6$3 1RWHV IRU 2UDFOH81,;

SAP Note # 117736 101318 086857

Description (Release) 4.5A 4.0B 4.0A

11–36

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

Use the program chdbpass to change the passwords. This program automatically updates the SAPUSER table and enables the user <sapsid>adm to access the database. 2UDFOH17 < system < sys < op$<sid>adm < ops$sapservice<sid> < sapr3

$XGLW 7RROV
$XGLW ,QIRUPDWLRQ 6\VWHP 7UDQVDFWLRQ 6(&5
:KDW

The Audit Information System (AIS) is designed for the system and business audits and will likely be requested to be run by internal or external auditors. It puts into one place many of the R/3 security tools. The center of the AIS is the Audit report tree. AIS uses standard R/3 reports and transactions to conduct the review and is a standard component in Release 4.6A. However, you can import the AIS into your system back to Release 3.0D or higher. AIS also provides an interface to export data to an external auditing system that analyzes financial statements.
:K\

Auditors examine the results of automated and manual financial and system procedures to ensure that there is a checks-and-balances infrastructure to prevent fraud, etc. AIS enables the auditors to test transactions and run reports during the inspection.
+RZ

There are two ways to conduct an audit: < Complete < User defined

System Administration Made Easy

11–37

Chapter 11: Security Administration Audit Tools

&RPSOHWH $XGLW In the Command field, enter transaction SECR and choose Enter (or from the SAP standard menu, choose Information Systems → SECR-Audit Info System). 1. Select Complete audit. 2. Choose .
2 1

A complete audit consists of a system audit and business audit. The structure on this screen is Audit_All with a standard view. 3. Click the node (+) to expand the following: < System Audit < Business Audit

3

11–38

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

6\VWHP $XGLW

The following example shows how to use the AIS. 1. Under System Audit, click the node (+) next to Repository / Tables.

1

2. Click the node (+) next to Table Information. 3. Choose next to Data Dictionary display.

2 3

System Administration Made Easy

11–39

Chapter 11: Security Administration Audit Tools

4. When the transaction executes, you will see this screen. From here, you will execute the transaction normally. 5. Choose Back.
5

11–40

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

%XVLQHVV $XGLW

1. Under Business Audit, click the node (+) next to Closing (FI-GL). 2. Click the node (+) next to Balance Sheet/ P&L/ Balances. 3. Click the node (+) next to Balance Sheet/ P&L. You can execute different reports to inspect the financial balances. 4. Choose next to Profit and Loss Projection.

1 2 3 4

5. On this screen, you can enter criteria for your report then choose . 6. Choose Back.
6 5

System Administration Made Easy

11–41

Chapter 11: Security Administration Audit Tools

8VHU 'HILQHG $XGLW You can also conduct a user-defined audit by creating a view or subset of a complete audit. 1. In the Command field, enter transaction SECR and choose Enter (or from the SAP standard menu, choose Information Systems → SECR-Audit Info System) 2. Select User-defined audit. 3. Under User-defined audit, enter a view name (for example, ZVUE). 4. Choose .
4 2 3

View names must start with “Y” or “Z.”

5. In Name, under New view, enter the name of the view (for example, ZVUE). 6. Under Select using, select Manual selection. You will select the procedures that will be included in the view. 7. Choose .
5

When you are creating a view and you entered a different name in Name, the name of the view is what was entered in the main screen.

6 7

We want to include all the procedures for a system audit in this view. 8. Select System Audit. 9. Choose 10. Choose . .

9 10

8

11–42

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

The message in the status bar indicates that the generation was successful. 11. Choose Back.
11

12. Choose Display to check the view of this structure.

12

13. Click on the System Audit node (+) to expand it.

13

System Administration Made Easy

11–43

Chapter 11: Security Administration Audit Tools

These are all the procedures for the Audit_All structure with a ZVUE view.

Ã

6HFXULW\ $XGLW /RJ 60
:KDW

The Security Audit Log records the security-related activities of users in the system. These activities include successful and failed: < < < < < Dialog logon attempts Report and transaction starts RFC/CPIC logons Locked transactions or users Changed or deleted: ΠAuthorizations ΠAuthorization profiles ΠUser master records Changes to the audit configuration

Other events written into the log are:

<

The log is created each day, and previous logs are neither deleted nor overwritten. The log files can become numerous and large, so we recommend that the logs be periodically archived before being manually purged. An audit analysis report can be generated from the audit logs. You can analyze a local server, a remote server, or all the servers in an R/3 System.
:K\

Based on certain criteria, the information in the security audit files can be manipulated to tailor the audit analysis report. The report assists the administrator: < < Reconstruct or analyze incidents Improve security by recognizing inadequate measures

11–44

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

< <

Trace unusual user activities Understand the impact of changes to transactions or users

+RZ

To start a security audit, you can do one of the following: < < < Set the profile parameter rsau/enable to 1 (For more information, see the section on RZ10 in chapter 20.) Dynamically start it using transaction SM19. You may choose to set the maximum space for the security audit file in parameter rsau/max_diskspace/local. When the limit has been reached, logging will end. You can define the size of an individual security log file to fit in the chosen archiving media. This definition means that the system produces several log files each a day and these files can be, for example, archived periodically into CDs. The profile parameter is rsau/max_diskspace/per_file, and the maximum size per file is 2 GB. 1RWH You cannot set both parameters. You have to choose the method by which the audit files are created.

The number of audit logs created by the system depend on the following:

<

System Administration Made Easy

11–45

Chapter 11: Security Administration Audit Tools

5XQQLQJ WKH $XGLW /RJ
Ã

*XLGHG 7RXU

This procedure assumes that the audit has been running for some time and that audit logs have been created. 1. In the Command field, enter transaction SM20 and choose Enter (or from the SAP standard menu, choose Tools → Administration → Monitor → Security Audit log → SM20-Analysis). 2. Complete the steps below: a. In From date/time, enter a time and a date (for example, 13:00). 3 b. Under Audit classes, select: < Dialog logon < Transaction start < Report start 3. Choose Re-read audit log. This button is used to read a log for the first time.

2a

2b

The security report is displayed. 4. To see the details of an audit message, select a line and choose .
4

11–46

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

5. Documentation for the message and technical details are revealed. This screen is most useful when displaying negative messages such as failed logins or locked transactions.

6HWWLQJ 6HFXULW\ $XGLW /RJ 3DUDPHWHUV 60
:KDW

The audit log parameters are the criteria used to write the types of audit messages into the audit log file. The parameters are grouped into audit profiles that can be activated at the next system startup (configuration status) or applied “on the fly” (dynamic configuration).
:K\

Audit profiles need to be first created before audit logs can be written. These profiles limit the amount and type of data written into the security audit files, which makes the subsequent security reports more meaningful to the administrator.
+RZ

Decide what to audit and set selection criteria at the database level or dynamically at the application server level: < If the audit configuration is permanently stored at the database level, all application servers use the identical criteria to save events in the audit log. The settings take effect at the next application server start. < At the application server level, however, dynamic changes can be set to individual application servers and distributed to the entire system. The new criteria will remain in effect until the server is brought down. You can define up to 5 sets of selection criteria or filters. The system parameter, rsau/selection_slots (that defines the number of filters has a default value of 2). You can activate an audit in the dynamic configuration using transaction SM19.

System Administration Made Easy

11–47

Chapter 11: Security Administration Audit Tools

*XLGHG 7RXU

1. In the Command field, enter transaction SM19 and choose Enter (or from the SAP standard menu, choose Tools → Administration → Monitor → Security Audit log → SM19-Configuration). Configuration status refers to the storage of the parameters in the database. 2. Choose .
2

3. Enter a profile name (for example, audprof1). 4. Choose .
3

4

11–48

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

5. In this screen, you may specify two filter groups and define the types of audit messages that will be written into the log.

'HILQH )LOWHU *URXS  6. Choose Filter 1. 7. Under Selection criteria, in: < Client, enter * < User Names, enter * 8. In Audit classes, select: < Dialog Logon < Transaction Start 9. Under Events, select All. 10. Select Filter active.
10 7 8 9 6

System Administration Made Easy

11–49

Chapter 11: Security Administration Audit Tools

'HILQH )LOWHU *URXS  11. Choose Filter 2. This filter traces the reports started by one user. 12. Under Selection criteria: < < In Client, enter *. In User Names, enter a user ID (for example, GARYN).
11 15 13 14 16

13. In Audit Classes, select Report start. 14. Under Events, select Severe and critical. 15. Deselect Filter active. This setting allows you to save the filter settings 12 but does not activate them. 16. Choose Detail setting to drill down the audit class and event class categories. 17. Scroll down to Report start. Notice that the category is automatically chosen based on the earlier selection of Event type and Audit class type. 18. Choose .
18

17

11–50

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

19. The general categories are cleared indicating that settings were browsed or defined at the detail level. 20. Choose Save.

20

19

21. A message at the bottom of the screen notifies the user that the profile was successfully saved. 22. Choose .
22

21

System Administration Made Easy

11–51

Chapter 11: Security Administration Audit Tools

23. The profile name is now in the Active profile field, and the message in the status bar indicates that the profile will be activated when the application server is restarted. 24. To dynamically change the selection criteria for one or more application servers in a running system, choose the Dynamic configurat (Dynamic configuration) tab.

24

23

25. In this example, the audit has been running for some time (indicated by the current file size greater than zero) before being stopped briefly. 26 The red square indicates that the audit is inactive. 26. Choose .
25 25

11–52

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

5XQQLQJ DQ $XGLW RQ D 'LIIHUHQW 8VHU

*XLGHG 7RXU

In this procedure, we will run an audit on a different user and check on all the reports that were started. 1. Under Selection criteria, in: < < Client, enter *. User names, enter a user ID (for example, Patricia).
5

2. Under Audit classes, select Report start. 3. Under Events, select All. 4. Under Filter 1, select Filter active. 5. Choose .

4 1 2 3

6. Choose Yes.

6

System Administration Made Easy

11–53

Chapter 11: Security Administration Audit Tools

7. A green dot appears in the Stat (Status) column and the message at the bottom of the screen indicates that the configuration was activated.

7

7

8VHU 6HFXULW\ $XGLW -REV
Many of these reports are included as part of the AIS.
:KDW

There are several predefined SAP security reports, including: < < < < < < < < < RSUSR003 RSUSR005 RSUSR006 RSUSR007 RSUSR008 RSUSR009 RSUSR100 RSUSR101 RSUSR102 Checks for default password on user IDs SAP* and DDIC Lists users with critical authorizations Lists users who are locked due to incorrect logon This report should be scheduled to run each day, just before midnight. Lists users with incomplete address data Lists users with critical combinations of authorizations or transactions Lists users with critical authorizations, with the option to select the critical authorizations Lists change documents for users and shows changes made to a user’s security Lists change documents for profiles and shows changes made to security profiles Lists change documents for authorizations and shows changes made to security authorizations

Some of these reports have parameter tables that need to be properly maintained. Review and analyze these reports based on your knowledge of the company. However, be aware

11–54

Release 4.6A/B

Chapter 11: Security Administration Audit Tools

that security issues may exist. If you have a small company, these issues cannot be avoided because “one person often must wear many different hats.”
:K\

Your external auditors may require some of these reports to be executed as part of the annual financial audit.

+RZ

You can use either of the following transactions: < < SA38 (ABAP: Execute Program) This transaction only allows the program to be executed. SE38 (ABAP Editor) With this transaction, if the user has the security authorization, the user can execute and change the program.
6$ ² $%$3 ([HFXWH 3URJUDP

1. In the Command field, enter transaction SA38 and choose Enter. 2. In Program, enter the report name. 3. Choose .
3

2

System Administration Made Easy

11–55

Chapter 11: Security Administration Audit Tools

6( ² $%$3 (GLWRU

1. In the Command field, enter transaction SE38 and choose Enter. 2. In Program enter the report name . 3. Choose .
3 2

1RWHV IRU 6SHFLILF 5HSRUWV

RSUSR008 (lists critical combinations of authorizations or transactions): < < These combinations are maintained on table SUKRI. Dangerous combinations include the following transactions: ΠRZ02 (with anything) ΠRZ03 (with anything) ΠSE14 (with anything) ΠSU01 (with security, users, and profiles) ΠSU02 (with security, users, and profiles)

11–56

Release 4.6A/B

Chapter 11: Security Administration Audit Tasks

$XGLW 7DVNV
5HYLHZ WKDW DOO 1DPHG 8VHUV DUH 9DOLG
:KDW

All users who have left the company should have their R/3 access terminated immediately. By locking or deleting these user IDs, you limit access to only those users who should have access to R/3. Periodic review assures that the task of locking or deleting has been completed.
:K\

Proper audit control requires that a user who no longer has a valid business need to access R/3 should not be allowed to do so. Deleting or locking these user IDs also prevents anyone who had been using the terminated user ID from accessing the system with that ID.

One of the audit procedures that your external auditors will use is to test whether a person who does not need to access R/3 has a live user ID.

+RZ

*XLGHG 7RXU

1. In the Command field, enter transaction SU01 and choose Enter (or from the SAP standard menu, choose Tools → Administration → User maintenance → SU01-Users). 2. Choose .

2

System Administration Made Easy

11–57

Chapter 11: Security Administration Audit Tasks

Review the active users and verify that these users are valid.

In a large company, you should do a random audit on at least 20 users. The minimum number should be determined by your auditors.

For additional information on how to “lock” a user, see chapter 12, User Administration.

5HYLHZLQJ 3URILOHV IRU $FFXUDF\ DQG 3HUPLVVLRQ &UHHS
:KDW

A “permission creep” is an incremental increase in permission and is given to a user over time. If left unchecked, increased permissions may grant a user more authority in the system than is required or intended.
:K\

Users may have undesirable authorization(s) or combinations.

Your external auditors may have an audit step to check for permission creep.
+RZ

You can conduct a spot audit of: < Individuals 1. Review the security forms for a user 2. Compare these forms to the activity groups and profiles assigned to that user 3. Investigate inconsistencies

11–58

Release 4.6A/B

Chapter 11: Security Administration Audit Tasks

4. Review the activity groups and profiles assigned to the individual for reasonableness. Reasonableness is defined as, “Does it make sense?” 5. Review the individual profiles assigned for content and check to see if the profile has been recently changed. < Profiles (transaction SU02) and authorizations (transaction SU03) Check if the change date is recent. You can also execute the following audit reports: < < < RSUSR100 (user changes) RSUSR101 (profile changes) RSUSR102 (authorization changes)

For additional information on these reports, see the User Security Audit on page 11–54.

System Administration Made Easy

11–59

Chapter 11: Security Administration Audit Tasks

11–60

Release 4.6A/B

Sign up to vote on this title
UsefulNot useful