Preparing Policies, Procedures, Guidelines and Forms Guidelines

Oracle RAC Environment Access Control Policy

Version 1.0 TRIM file number Short description A policy on access to the Oracle RAC database environment Relevant to All CSU employees Authority This Policy has been approved by Office of Executive Director, Division of Information Technology Responsible officer Senior Technical Specialist - Databases Responsible office Office of Executive Director, Division of Information Technology Date introduced 30 May 2013 Date(s) modified Next scheduled review date May 2015 Related University documents Related legislation Privacy Act 1988 Key words Oracle, security, authorised, access.

Oracle RAC Access Control Policy Page 1 1.0 – 30 May 2013 1. PURPOSE

1.1 Charles Sturt University’s information resources are a valuable asset. Increasingly, these information resources are stored in the CSU/DIT Oracle RAC database environment. This policy defines what, who and how access to this database environment is to be controlled, provisioned, managed and logged.

1.2 The objectives of this policy are to:

(a) Define the controls used to protect CSU’s stored information assets from unauthorised disclosure, use, loss or damage.

(b) Preserve the integrity and availability of those information assets.

(c) Ensure compliance with the Privacy Act 1988 (changes coming in 2014!)

2. SCOPE

2.1. This policy applies to:

(a) CSU and 3rd party application and database administrators, developers or technical staff.

(b) Consuming applications and systems

2.2. This policy does not apply to:

(a) Information assets stored outside the CSU Oracle RAC database environment.

3. REFERENCES

This policy should be read in conjunction with:

(a) The Charles Sturt University “Policy for the Use of University Computing Communication Facilities” (b) The Charles Sturt University Information Security Policy (c) Unix Administrator Access Control Policy (d) The Charles Sturt University Information Security Management System Policy (e) CSU Data standards (f) TRIM Access and Security Policy (g) Other policies as published at: http://www.csu.edu.au/division/dit/about/policy.htm

Oracle RAC Access Control Policy Page 2 1.0 – 30 May 2013 4. DEFINITIONS

4.1 DIT – Division of Information Technology 4.2 Oracle RAC environment – High availability database solution. 4.3 Consuming application/system – Any application or system that accesses, reads, writes, processes or interacts with any data in the Oracle RAC environment 4.4 Production data – Any data outside the Devel and QA environments. 4.5 Devel environment – application and systems development only 4.6 QA environment - application and systems quality assurance only 4.7 Admin VPN – Special full access Virtual private network service 4.8 Host – A server that comprises part of the Oracle RAC environment. 4.9 DBA – DIT Database administrator 4.10 UNIX admin – DIT UNIX system administrator 4.11 SD – Service Delivery 4.12 TI – Technology Integration. 4.13 DDL – Data Definition Language 4.14 DML – Data Manipulation Language

5. RESPONSIBILITIES

SD-systems – provisioning accounts on hosts SD-networks – network layer access control management SD and TI database administrators – Overall management of the RAC environment. Provision individual access to data in the RAC environment as approved. TI-systems – Defining host access via host based ACLs TI-networks – defining DIT staff subnets. Team leader SD systems – approval for DIT production data access. Approval for non-DIT Devel and QA access.

6. ACCESS CONTROLS

6.1 With the exception of individuals approved as per sections 6.3 and 6.4, no individual will have direct access to production data hosted within the Oracle RAC environment. This includes read, write, change or any other access.

6.2 All access to data in the Oracle RAC production environment shall be via the provisioning or consuming system or application only.

6.3 Individual access to the database with the schema owner shall only be where a structure change (ddl) is required.

6.4 Individual access to production data will be provisioned and de-provisioned as required and approved – (see appendices)

6.5 Direct Devel, Prod and QA database SQL access is restricted to DIT staff as defined by DIT network subnets.

6.6 Direct Devel, Prod and QA database SQL access for non-DIT staff is normally via the admin VPN and will be provisioned on a case by case basis by request. If necessary, Devel and QA data will be refreshed from Prod.

Oracle RAC Access Control Policy Page 3 1.0 – 30 May 2013 6.7 Only identified and approved DBA’s and UNIX administrators shall have SSH access enabled on their accounts for Oracle RAC hosts.

6.8 All user, administrator, individual and application access request to data in the Oracle RAC environment will be logged.

6.9 Password management will align with the Unix systems Administrator access control policy – section 6.4

APPENDICES

1. Process - Provisioning Individual DIT Staff Access to Production data

1.1 A DIT Maintenance account is available upon request to view data.

1.2 If changes are to be made to production data, the standard RFC process will be followed.

1.3 Individuals requiring access to production data will apply for access via an email request to the Team Leader Service Delivery or delegate. The email request needs to specify a relevant incident or RFC number.

1.4 Requests for access will be reviewed and approved by the Team Leader Service Delivery or delegate.

1.5 Approved requests will be forwarded to the appropriate CSU DBA for actioning.

1.6 If a data change (dml) is required, appropriate grants will be added to the maintenance account to allow this to happen once approval is provided and will be revoked once the change has been made.

2. Process - Provisioning Individual DIT Staff Access to Devel and QA data

2.1 The relevant maintenance account should be the preferred access option and will be left unlocked for the purposes of standard devel and qa data access.

Table of amendments

Version Date Short description of amendment number 1.0 7 May 2013 Initial policy 1.0 8 May 2013 Review by LW and HC. 1.0 30 May 2013 CAB approval

Oracle RAC Access Control Policy Page 4 1.0 – 30 May 2013