4.2.6 Access Prevention

Authorized Access: Only people with a need to know or a legitimate administrative purpose should be allowed any form of access to production database.

Access Logging: All access to production databases must be logged with a specific user ID that maps to a specific individual, either staff or a vendor, including administrator login. There should be separate/dedicated DB user created for application which should not be shared or used for any other purpose.

Access Monitoring: Monitoring should be done to track non application sessions into the database and activities performed in that session. Guidelines on monitoring tool can be referred from Oracle documentation or Oracle DBA team.

Providing Access: While providing production access to any individual, process of authorization by higher level management with proper justification should be followed. The access should be controlled by timelines that certain user access will be expired after specific period and should go through renewal process to reactivate.

Restricted Access for support: The support consultants (OFSS / OFSS partner / Third party vendor / Bank IT) should have individual IDs created on database with strictly Read-Only access. Any consultant demanding for updateable/full access should be reported to senior management of respective vendor.

Restricted Access for reporting tools: All third party tools using Production database for reporting purpose (Like BO reports) should access it via a Read-only access ID meant for specific reporting tool.

Reports from Backup Schema: As much as possible, reports should be generated on backup schema and not on production schema.

Restricted Access for interfaces: If third party tool is writing into production database for processing, it should be restricted via APIs wherever applicable. There should be dedicated user created for each distinct interface and that user activity should be tracked to ensure authenticated sessions/activities.

Change Password: Database passwords should be changed at regular intervals at scheduled frequency or event basis.

Production ID restrictions: Inactive DB User Id which are not used for a specific period (say one month) should be disabled and deleted in case of say 3 months of inactivity. Any activation/recreation of such ID should follow standard process/mechanism. Password profile should be created which will automatically take care of disabling the user ids after inactivity for specified time. These are standard recommendations, bank can have their own timelines defined for these activities.

Awareness: The awareness must be created within bank's teams, whoever is having any form of access to production database, to ensure that they do not share their password and do not leave their database session unattended.

Restrict DB Sessions during EOD: Database Sessions using Toad, sql*navigator etc and running heavy queries from those sessions should be avoided during production End of Day process as it creates additional load and may lead to locks if not used properly.