IRM - Security Procedures on Banner Development Instances

Security Procedures on Banner Development Instances

1.0     Procedures

Technical leaders for the project area can assign access and give developers the ability to create objects in the Banner development instances as needed.

If grant privileges are misused or the DBA cannot do future installs into this instance, then this policy may be revoked.

1.1     IRM gives the BANINST1 id and an area-specific BANSECR account (i.e., BANSECR_FINANCE, BANSECR_HR, BANSECR_STUDENT, etc.) to each technical leader who will act as the application security administrator.

1.2     The technical leader will use BANINST1 to:

1. Grant roles as needed to developers
2. Make explicit grants of objects to appropriate developers. IRM recommends using scripts for these explicit grants so that they can be recreated as needed.
   NOTE: The technical leader is responsible for coordinating with other technical leaders for any tables they need to access from another area.

1.3     The BANINST1 id has select access on all tables in the database and update access on all Banner tables. The id should only be shared with:

1. a backup person for issuing grants
2. developers needing to create pl/sql packages
   NOTE: As the application security administrator, the technical leader is ultimately responsible for the BANINST1 id should it be compromised. The technical leader should use discretion in sharing this id.

1.4     The BANSECR_area id should be used to assign access within the Banner application only (i.e., the technical leader must log into Banner forms in order to activate the privileges associated with the BANSECR account). The security that may be defined/assigned using the BANSECR account includes defining Banner objects, creating classes, assigning Banner objects to classes, assigning classes to users.

1.5     IRM provides an APPLICATION_OWNER_ROLE with the following privileges granted to it:

• CREATE VIEW
• CREATE PROCEDURE
• CREATE PUBLIC SYNONYM
• CREATE SEQUENCE
• CREATE SYNONYM
• CREATE TABLE
• CREATE TRIGGER
• DROP PUBLIC SYNONYM

This role should be assigned to the area-specific ids that will own the objects for that area (i.e., VTPAYROLL, VTALUMNI, VTFINANCE, etc.).

1.6     IRM provides a DEVELOPER_PACKAGES_ROLE with all packages, procedures, and functions owned by BANINST1 granted to the role. This role may be granted to developers for the purpose of compiling programs.

1.7     IRM will continue to create new users and create new Oracle roles in the development instances. DBMS will continue to create any new schemas (users that own Oracle objects).

1.8     Each area will be responsible for keeping the Banner_develop (DEVL and FDEV) instances up-to-date and in-sync with production in preparation for new Banner installs.

1.9      Execute on all packages, functions, and procedures owned by BANINST1 (except web packages - see note below) must be granted to the following ids and roles:

• ALUMNI
• FIMSMGR
• GENERAL
• POSNCTL
• PAYROLL
• TAISMGR
• FAISMGR
• SATURN
• WTAILOR
• BAN_DEFAULT_M
• BAN_DEFAULT_Q
• DEVELOPER_PACKAGES_ROLE (development instances only)

NOTE: Execute on web packages, functions and procedures must be granted to OWA_USER. DO NOT grant execute to public.

Revised: September 5, 2000

• Virginia Tech Home
• Information Technology
• IT Security

Last updated February 9th, 2007