Implementing a Security Strategy
This Blog briefly explains about the course involved in implementing a Security strategy. Most of the content is from Methodology from Solution manager system which has been consolidated here for an easy reference.
Implementing a strong Security strategy with policy adherence is requisite to manage compliance, minimize risks and to setup a secure and efficient authorization concept with process efficiency and adoption which can be based on organizational structures; business processes and Role based Authorization Concept.
The following activities should be conducted:
• Review the implementation scope and user role report to determine the necessary project team to manage end-user role and authorization profile creation and design
• Produce an enterprise-wide role matrix, a document that describes authorizations, detailing roles and their assignments to transactions, reports, menu paths, and organizational levels
• Draft a technical design document of user roles and authorizations, providing the development details for the implementation of the roles
• Generate a user authorization strategy and management procedures, detailing the responsibilities and procedures employed for user and authorization administration
• Define the role implementation framework prototype, which is a preliminary implementation of the user role and authorization concept
Determine Scale and Scope of Authorization Requirements
The purpose of this task is to identify the impacted business areas and to confirm security requirements in each business area in the enterprise. The security requirements and control mechanisms may vary from business area to business area. For example, the HR department usually has stronger security concerns than other departments. Therefore, it is essential to identify the required security level.
Consider that different levels of security are required for the production, test, and development environments. Also, we usually have different user roles distributed across the system landscape, which might look different in respect of functionality and authorizations, depending on the system type.
The following procedures are required:
1. Determine the scope of the authorization concept
Identify the business areas that are impacted by the SAP software system implementation. For each business area, identify the data owner. The data owner is responsible for the definition of security requirements and user roles in his or her business area
- 2. Determine the scale of the authorization concept
To Ask the data owners for their high-level security requirements, and review the existing security philosophy
What is the security policy in your organization?
What level of security does your data require?
How much risk can you permit?
For each business area, determine on which organizational level (such as company code, cost center, or plant) a segregation of duties has to be implemented.
- 3. Document the authorization requirements
The best method of documenting the authorization requirements is to use a risk control matrix.
- 4. Review the authorization requirements with internal auditors
To meet with the internal auditors to ensure that the requirements of the business department fulfill the enterprise requirements for control
Enterprise-Wide Role Matrix
The enterprise-wide role matrix is a document that helps describe the authorization concept by detailing the assignment of roles to the following items:
• Menu paths, levels of navigation, tabs, and accessible content
• Organizational levels
Organizational levels are company codes, plants, and so on.
Here solution Manager will have an “Authorization Matrix “suggesting different role in accordance with the proposed BPPs specified in SOLAR02.
Hence “Enterprise-Wide Role Matrix” maintained in solution manager
As a result Role Implementation Framework Prototype will be standardized.
Here we can just specify restrictions at functional and data level for that transaction code in the given role. Gathering functional and data level authorization requirements can also be done.
• Clicking on the listed Transactions (in Authorization Matrix) against the roles, would take you to the screen of the Tx. • We should be able to select access (including data level) to be given for this Tx. • Org Unit and Master Data level Auth can be specified for a given role using “Org Units” And “Master Data” nodes. As a Result Auth requirements are gathered and documented. This data can be used to implement and review security.
Global Delivery Considerations
Defining documentation standards, the global delivery team can deliver the process/strategy for changing/enhancing the authorization concept and following user management tasks. The team can do these using predefined templates, such as the following:
• User creation
• Role assignment
• Granting/revoking of authorizations
• Role enhancements
Conduct security Kick-off Meeting
Meet with the functional Business Process Owners (BPO) to discuss the SAP authorization concept and explain that security implementation is a cross-application responsibility functional people will know what R/3 transaction codes each job role will require.
Identify General Information Access and Service Usage
Discuss organizational information that will be common to all security roles like company codes, purchasing groups, etc. and have then decide what standard values will be used.
Conduct Authorization Interview with Data Owner
To have the BPM or functional team member create matrix detailing what employee jobs or functional roles require which security roles.
Role Implementation Framework Prototype
The role implementation framework prototype is a preliminary implementation of the user role and authorization concept. The prototype does not contain organization-level restrictions and serves as a verification of the technical design. The prototype allows for early recognition and correction of mistakes in the design of the user role and authorization concept.
Define Role Implementation Framework
The purpose of this task is to define how the user roles and authorizations are technically implemented.
In SAP NetWeaver Portal component the user roles are technically implemented with the portal role editor. The portal role editor creates two levels of navigation, the navigation panel, and any required iViews.
The following procedures are required:
1. Define naming conventions
Technically, each element of the authorization concept needs to be supplied with a unique identifier.
Naming conventions can be built on the basis of different criteria — for example, country or business area (such as financial accounting, controlling, and so on).
Naming conventions are also required for administration purposes if you want to decentralize your user and authorization administration. In this case, the decentralized administrators should have access only to those roles that belong to a certain business area, thus operating only in a restricted name range.
2 Determine roles for application access
To determine the roles to be implemented, proceed as follows:
• Review the user role matrix to identify functions that are common to several user roles in a business area
• For each business area, summarize transactions and reports that logically belong together in activity clusters
Each activity cluster must be implemented as a role.
Determine roles for general information access and service use
Identify the needs of users to access functions that are not directly related to their user role. Such functions can be access to online documentation, or access to the SAP Service Marketplace. Use the corresponding predefined role template from SAP and determine whether you can adapt it to your needs.
3. Document the role structure
Document the resulting single roles, together with the derivations required in the enterprise-wide user role matrix. Specify the required composite roles that are used to summarize single and derived roles to user roles.
We can use the predefined user role templates from SAP.
User Authorization and Strategy Management Procedures
The user authorization strategy and management procedures output is a document detailing the responsibilities and procedures for user and authorization administration. It defines how to perform user management tasks, such as new-user creation, role assignment, and granting or revoking of authorizations. It also defines documentation standards and how to change or enhance the authorization concept.
User Role and Authorization Concept Technical Design
The technical design of the user role and authorization concept is a document that defines how the role and authorization concept will be implemented. The document includes decisions made on how to use the role editor and how to define user menus. Further, naming conventions and grouping of generic user roles and authorizations are defined.
Determine User Roles
The purpose of this task is to identify user roles in the organization. For each business area, you must identify user roles, along with the required authorizations, to define SAP application access.
A user role can be characterized as a collection of related activities that are necessary to comprise a job position. Usually, a user role corresponds to an element of the organizational structure. Note that each user has at least one role but might have more than one.
The following procedures are required:
- 1. Identify user roles
Meet with the business area leads to identify the roles in the organization. Analyze the organizational structure of each business area in order to identify user roles. Verify if you can make use of the predefined user role templates from SAP. However, even if you don’t want to use the predefined user role templates, they might at least help you to get an idea about possible user roles for an application area. Determine whether your roles will be generic across locations or organizational units.
- 2. Document the user roles in an enterprise-wide user role matrix (authorization list)
For each business area, document the previously identified roles in an enterprise-wide user role matrix (authorization list). The user role matrix is refined during the design.
Security Organization Hierarchy
SAP Security Organization Hierarchy is the ability to secure by different organizational levels
To ensure the SAP Security Team implements agency restrictions that should be in place, the SAP Security
Team will work with the functional teams to obtain the SAP Security Organization Hierarchy Requirements.
The requirements needed include the following:
· Gain an understanding of which agencies should and should not see or update another agency’s data.
SAP has provided a means for the SAP Security Team to secure agency restrictions from an update or a
· Gain an understanding of these organization hierarchy restrictions based on the SAP transactions or
functions. SAP has provided a means to secure by functions.
· Gain an understanding of organization hierarchy restrictions within an agency. Depending on the
module being implemented and what is configured, SAP has provided a means to secure within an agency.
Transaction to Role Mapping
Security Matrices are used during the design phase to help establish the security design. The Security Matrix lists the mapping of transaction codes and info types to simple roles.
The Security Matrix helps to view the roles in an easy-to-read format and helps the SAP Security Team communicate to the functional teams the security roles being configured.
The functional teams can use the security matrix to assist in adding theroles to their BPPs (business process procedures). The BPPs are used for building training and integration testing scenarios.
Role to Position Mapping
Once the simple security roles have been defined, the SAP Security Team will work with the Change team for
“Simple Role to Position to User Mapping”
It also achieves our understanding of what access is required for each user.
where have you copied the text from? It is clearly formatted as something else... Even if you didn't copy it, why didn't you take your time and make it readable?
Why not help the reader a bit? Maybe you can consider that for the next time.