Purpose
The following policy and procedural requirements have been established to maintain the security of the University of Missouri's Administrative Applications/Systems. These procedures are intended to promote segregation of duties and the principle of least privilege, and also provide a method for quality assurance and management oversight.
Scope
This policy applies to all enterprise administrative systems. This policy establishes the methods and procedures database programmers, developers and application managers (functional and technical) must use to apply database updates against production databases.
Definitions
Note: The role definitions in this document describe the function of each role and do not represent specific job titles.
Administrative Applications/Systems: A set of functional applications within the University's enterprise administrative systems. Examples of such systems include but are not limited to PeopleSoft Student Administration, Financials and Human Resources and Alumni and Development's Advance system.
Application Lead: The application lead serves in a functional role and has overall responsibility for ensuring that an administrative application supports the routine operations of the University. The application lead is the next level of authority above a functional lead.
Developer: Any authorized university staff member, consultant or contractor who can execute changes against the university's administrative application databases. This includes, but is not limited to developers, production support personnel, and database administrators working for Enterprise Application Services (EAS) as well as those working within other university departments.
Enterprise Applications Services (EAS): The Division of Information Technology unit responsible for the operational and strategic management of the university's administrative applications.
Enterprise Application Services Security Team: A team of individuals within EAS who work exclusively on managing PeopleSoft application and system permissions.
Functional Lead: Any university staff member, consultant or contractor responsible for ensuring that a functional administrative application supports the routine operations of the university.
Requirements
All university employees, consultants and contractors involved in processes that modify administrative application databases are responsible for ensuring adherence to the principles and procedures established in this policy.
All administrative applications must adhere to the following standards and procedures:
Database Access
- Developers should be authorized to access only the specific database tables within a given application needed to perform their jobs.
- To facilitate trouble shooting, developers should be provided with appropriate "view only" access application data.
- Developers should apply database updates in a test environment prior to being applied to production. They must also document and execute all updates to production databases using a process that encourages separation of roles, ensures quality control and provides a method to identify rogue or unauthorized activity. See the "Procedural Requirements" section below.
- Developers should not have access to tools to apply ad hoc database updates that cannot be audited (e.g.; Data Mover). The developer's functional or application lead must approve all requests for access, including a final review/approval from the EAS security team.
Web Application Access
Developers should not have update access to production instances via application web-based interfaces, other than the self-service access granted to regular end-users (such as, entering one's own payroll time or travel reimbursement request, or enrolling as a student in a course). Any additional access to Web application interface(s) granted to a developer, must be tied directly to their support re