Å·ÃÀÈÕb´óƬ

Purpose

The following policy and procedural requirements have been established to maintain the security of the University of Å·ÃÀÈÕb´óƬ'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
• Definitions
• Requirements
• Procedural Requirements
• Access Management

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.

Return to top

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

1. Developers should be authorized to access only the specific database tables within a given application needed to perform their jobs.
    
2. To facilitate trouble shooting, developers should be provided with appropriate "view only" access application data.
    
3. 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.
    
4. 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 responsibilities, and must be documented and approved by the application lead.

Exceptions

Application and functional leads are responsible for authorizing and documenting justification for exceptions, and for closely monitoring database update activities while exceptions are in place.

Return to top

Procedural Requirements

All database update activities must be documented in the change tracking application as either individual update entries or through daily entries representing multiple updates. EAS will provide a common tool to document database update and auditing activities. Administrative application developers, functional leads, and application leads will jointly use the following control procedures for database updates:

1. Authorize/Request--All updates should be requested or authorized by a functional or application lead. If neither lead is available, a developer can request authorization from an administrative application manager. Developers cannot obtain authorization from another developer.
    
2. Execute--Developers execute updates and retain evidence of the affected table rows (e.g.; SQL logs, row counts, SQL statements).
    
3. Verify--Functional leads must verify all update requests against administrative application logs to ensure that the work completed matches the work requested and that no unauthorized updates are executed.
    
4. Management Review--Application leads will at least monthly, spot check database update documentation and system logs to ensure that work performed matches the work authorized and to ensure adherence to the procedures established in this document. Application leads must also document the management review with a signature and date.

Return to top

Access Management

Granting Update Access to Tables

A functional lead or application lead in the functional lead's absence must authorize a developer's database update access requests. The request should be for specific tables and only within the application(s) for which the functional or application lead administers.

Table Access Review and Revocation

The functional or application lead must request revocation of access. Functional and/or application leads are responsible for alerting the EAS Security Team as soon as possible when circumstances warrant revocation of access.

Standard Table Access Review Procedures

1. The EAS Security Team must review employment terminations daily and revoke database access privileges as appropriate.
    
2. The EAS Security Team will provide a list of developer access monthly to each functional lead/manager. This list will include:
   • the name of each developer
   • the specific table(s) each developer has authorization to update
   • the last date that a developer modified each table
3. Application and/or functional leads will validate that each developer has appropriate access and eliminate access to unnecessary tables or request removal of a developer's access.

Return to top