Policy Document in SAP Administration

a) SAP Users Management

b) Roles & Authorization Creation and Assignments
c) TRs (Transport Requests) Movement
d) Password Policy
e) SECURITY Audit Logs
f) Downtime policy
g) SSL Creation

a) SAP Users Management

This Identity & User Management Policy establishes the standards for the
creation, administration, use, and removal of User Accounts.
A User is an individual person will be granted access to SAP application with
Frontend Tool (SAP GUI/portal).
SCCL adopted Role based user creation in ABAP systems, employees wise in ESS Portal.

Users Creation in ABAP Systems

Initially (during SAP implementation) user’s creation was done based on
the requirements collected from Mines/ Departments. Thereafter for any new
User ID creation, request will come from Mines/Departments either with
approval from competent authority or through mail to PM, ERP. PM, ERP will
examine the requirement with respective functional team member and will
approve & forward mail to BASIS team for creation SAP User(s) in respective
systems.
Users Deletion in ABAP Systems
Recommendation will come from respective Mines/Depts. when user is
not in optimal use. PM, ERP will recommend to delete the SAP User by
forwarding the mail to Basis Team.
Users Creation / Deletion in ESS Portal
EE Cell will recommends ESS users creation / deletion based on new
employment and on superannuation / resignation / termination etc. PM, ERP
will review and approves the EE Cell recommendations. On approval from PM,
ERP, Basis team will create /deletes the ESS Users in ABAP System. Enter
Prise Portal Admin will create the same in Portal

Password reset
End user mail to Basis team for resetting the password. After resetting,
new password will be initiated through mail to corresponding users.
Users unlock
End user will mails to Basis team for Unlocking the user whenever user
is locked due to wrong attempts.
As a policy, if any dialog user is not login into SAP System for more than 90
days, Admin will lock the User ID. In case of ESS User is not login into EPP
portal for more than 365 days, User will be locked by Admin. Same will be
unlocked after receiving mail from respective HOD with proper justification why
it’s not being used and also with PM, ERP approval.

b) Roles & Authorization Creation and Assignments

Role is a set of Transaction codes with authorization objects grouped together.

Roles and Authorizations allow the users to access SAP Standard as well as
custom Transactions in a secure way. This prevents un-necessary access of
data, which enable privacy and secure of data.

Roles creation and assignment

Functional team members will define authorizations to be given to users by
assessing their role and responsibilities.
Functional team will send mail to PM, ERP with TCODES & Authorization
objects to be allowed for each individual users. On approval from PM, ERP,
Basis team will create a role with given Tcodes & Authorization objects and
assigns to respective users.

c) Transport request

An SAP Transport is a package which is used to transfer data from one SAP
installation to another (One server to another server). This change can be from
a small change to major change. It can be considered as an “update”, with the
only difference being that SAP transports are made by the SAP users
themselves. Each TR contains one or more change jobs, also known as change
Tasks. All the Tasks are stored inside a TR for eg multiple files stored in some
folder.

Types of transport change request

Workbench Request - Workbench requests are cross-client. Changes done in

one client are automatically reflected in all other clients generally ABAP
Programs.
Customizing Request - Customizing requests are client specific. The
changes will not be reflected in other clients. For e. g a change done in ECC
Dev system will not be reflected in other clients in the same ECC Dev system.
We have to do a client copy using T-code SCC1. You can see the client number
next to this type of request.

All TRs are created in Development Server, after testing by respective teams,
Functional / ABAPERS team will send mail to Basis Teams for moving the
TRs to Quality /TEST Server (SBX).

For Production, after testing TRs in Quality/ TEST Server (SBX), Functional
team will give mail to PM, ERP for approval, on approval from PM, ERP, TRs
will be moved to Production server by Basis team.

d) Password Policy
A password policy is a set of rules designed to enhance computer security by
encouraging users to employ strong passwords and use them properly.
Passwords are an important aspect of computer security. A poorly chosen
password may result in unauthorized access and/or exploitation of
Company's resources. All users with access to Company ERP systems are
responsible for taking the appropriate steps, as outlined below, to select and
secure their passwords

The purpose of this policy is to establish a standard for creation of strong

passwords, the protection of those passwords, and the frequency of change.

Policy: All system-level passwords (e.g., root, user accounts, console

accounts etc.) & User level Passwords must confirm to the guidelines below.

 The password length must be at least eight characters

 Password should not be a dictionary word
 Password should not be a common word such as company name,
birthdate, names of family, pets, movie characters, phone numbers
and patterns like ‘qwerty’ etc.
 Passwords should not be any of the above spelled backwards.
 Passwords should not be any of the above preceded or followed by a
digit
 Passwords should be changed every 90 days except system passwords
and for Development server 180 days.
 Last 5 passwords are not allowed.
 Passwords should never be shared with any one including
administrative assistants
SCCL Follows
 8 character password with combination of alpha, digits, and special
chars.
 Password will expire for every 90 days
 Not allows previous 5 passwords.
 Not allows standard default password like company name, area
names, common password etc. list of not allowed password are
maintained, systems prevent when setting the new password.
 Password will be locked after 5 failed attempts.
 Password will be deactivated with users with initial password for
more than 14 days.

e) SECURITY AUDIT LOG

Audit logging is the process of documenting activity within the software
systems used across the organization. Audit logs record the occurrence of an
event, the time at which it occurred, the responsible user or service, and the
impacted entity.
The SAP System logs all system errors, warnings, user locks and also provides
information about who has accessed the system and what operations he or
she has performed during a given period of time.

The system also collects the messages from the other application servers and
writes these messages to the central log

Security audit logs are stored on the file system and not on the database, they
don’t have a performance impact. The main consideration is storage
requirements. Based on the activated event types (audit classes), data volume
may vary.
Retention period of Audit Logs is 6 months.
BASIS Daily Monitoring in SECURITY AUDIT LOG
 If any user is trying to connect / operate from different location other
than user location
 If any user is trying to connect / operate odd hours other than SD users
 If any user is trying to connect / operate critical t-codes / Un-
authorized T-codes like SCC4, SE06, SE16N, SM30, SU01, PFCG,
ST06, SM21 etc.,
 Alerting Area-IT through mail, For those systems with blank Physical
location details in Central-HW-DB (http://webhyd.scclmines.com/hw),
about to get the details of Physical location of the systems.
 On request of User, Providing Audit log details like Operated T-code,
System-IPs, Timing details etc.,
f) Downtime policy

Downtime defines the time during which you cannot use a system or a
resource productively. A breakdown of one or several components
always requires action. To cope with these exceptional situations, it is
imperative to ensure that the necessary resources are available in the
event of malfunctions, problems, queries, such as an SAP specialist or
a network administrator.
There are two types of downtimes described in the following sections:

 Planned Downtimes
 Unplanned Downtimes

Planned Downtimes

Planned downtime is the time for scheduled maintenance and upgrade

during which a system cannot be used for normal productive
operations. This time is used for a variety of purposes so that a system
can function optimally and reliably, such as:

 Parameter change
 Update to Support Packages (SPs) or patches
 Hardware maintenance
 Landscape reorganization by adding/removing an instance (to
the Core Server system)
 Landscape transfer, by copying a Core Server system from one
landscape to another
 Upgrades to new releases of SAP application components,
database or operating system
 Database reorganization / Database backup
 Archiving of business data objects

Unplanned Downtimes

Unplanned downtime is the time during which a system cannot be

used for normal productive operations due to unforeseen failure in
hardware or software components, or operator mistakes.

Unplanned downtime can be extremely costly to an organization. The

source of unplanned downtime can be in any of the layers that make
up the complete software and hardware environment:

 Front-end and middleware services for connection to the web,

including the Internet Transaction Server (ITS), the SAP Web
Application Server (SAP Web AS), and the SAP Enterprise Portal
 SAP system services of the individual application components of
the SAP Business Suite – such as the Business Warehouse (BW),
Business-to-Business Procurement (BBP) – and the SAP kernel
  Underlying hardware and software services, such as the database
services, network and operating system services, and various
hardware services, including servers, disks, memory, and
uninterruptible power supply (UPS)

The risk of unplanned downtimes occurring can be minimized by

avoiding single point of failures (SPOFs) in a complex system
landscape. For the different components in a complex system
landscape, there are several ways of avoiding these SPOFs.

SCCL Follows

Will take prior approval for planned downtime activities, duration of

activity will defined based on Dev & Quality systems. On approval of
downtime intimation will be sent to all GMs / HODs/ Quality / ATB
Cells etc. 2 days prior to the activity, downtime message with date,
time & duration will populated in SAP Server for every 3 hours.

All pre-requisite checks will be done before doing the activity and
after the downtime activity system will be thoroughly tested in
technical aspect before released to users

Incase of Unplanned activity RCA for downtime will be prepared and

will take care not to repeat the same further.

f) SSL Creation
SSL (Secure Sockets Layer) is a communication method whereby secure
communication between system entities is accomplished by the use of
encryption facilitated by X.509 certificates published by Certificate
Authorities (CA) in tandem with public and private decryption keys.
Procedure

 Create the SSL server PSEs. ...

 Generate a certificate request for each SSL server PSE. ...
 Send the certificate requests to a CA to be signed. ...
 Import the certificate request responses into the SSL server PSEs of
the server. ...
 Maintain the certificate list of the SSL server PSE.

Presently SSL is using for i) ESS portal ii) BW Dev & Production server
for SAC and iii) for PWC E-invoice & E-waybill API interface