Secure Configuration Overview
As explained in the Service Security Features Chapter, the Oracle Fusion Transportation Management Cloud Service has many different administrator user accessible security configuration mechanisms to configure the service for users accessing the service. This section outlines the secure configurations and describes several recommendations.
There is never a one size fits all secure configuration for all of the Oracle Fusion Transportation Management Cloud Service clients however there are definitely general recommendations and general Dos and Do Nots that can be given.
Failure to follow these recommendations may lead to bad configurations, unintended access, data access, and performance issues or data corruption.
User Roles
Recommendations
- Use caution in giving out the DBA.ADMIN user role ability to individual users. This is a super user role and has privileges to everything within the service.
- Use caution in giving out the ADMIN user role to individual users. This is an elevated user role and has service privileges to everything but reduced domain data visibility.
- It is not recommended to use the DEFAULT user role since this is a pretty broad service privileged user role.
- It is recommended to create custom user roles for every role within your organization so that you can easily control and maintain groups of users’ service privileges and data visibility.
- Do not create a custom "DBA.ADMIN" or "ADMIN" user roles as this will just sidestep built in service constraints. Do this at your own risk.
- Do not modify the "DBA.ADMIN" or "ADMIN" user roles.
- Do not change the DBA.ADMIN user's user role.
- User names cannot end with "ADMIN."
- Do not give
<DOMAIN NAME>.ADMIN
user names a Nickname.
Users
Recommendations
- Don't use commonly known or previously known passwords for Oracle Transportation Management Users. Use a strong and unique password by at least using the default BASIC POLICY Account Policy.
- Don't use commonly known or previously known passwords. Use a strong and unique password.
- Don't share the DBA.ADMIN user account. Instead give individual users the DBA.ADMIN user role as their default role or provide them ability to change to the DBA.ADMIN user role by granting it to their default user role.
- Don't change the DBA.ADMIN user's user role.
- Don't use the
<DOMAIN_NAME>.ADMIN
user account(s). - Expire or delete only unneeded Oracle Transportation Management Users.
- Don't expire or delete users who have recurring processes.
- Only enabled OBIEE Non-SSO User for users who require access to OAS.
- Only grant Business Intelligence Applications and Business Intelligence Roles to users who require it.
- Don't use the External User field as there's no such thing as an external user.
Access Control Lists (ACL)
Recommendations
- Don't use assign the same ACL at both the User Role and the User level. As a bad and not recommended example, a user has the DEFAULT user role and then the DEFAULT ACL assign to the individual user. This is redundant and will cause performance overhead.
- Don't use assign the same ACL at both the User Role and the Child ACL level. As a bad and not recommended example, a user has a custom user role which has the DEFAULT ACL assigned and then has the DEFAULT ACL assign to the custom ACL as a child ACL. This is redundant and will cause performance overhead.
- Create custom ACLs that only contain the entry points required for a given set of business functionality access(es) required.
- Use caution in granting the "ADMIN" ACL since this almost contains every child ACL and allows privileges to everything within the service.
- Use caution in giving out the child "Administration" ACL since this only contains administration entry points.
- Do not create a custom "COMMON" ACL by copying "COMMON". By doing this, you will miss any new child ACLs granted or additional entry points grouped into "COMMON" in future releases. Do this at your own risk.
- Do not modify the "COMMON" ACL.
- Make sure that the "COMMON" ACL is in the hierarchy of child ACLs preferably assigned to the User role.
- Do not grant "ADMIN", "DEFAULT", and "COMMON" ACL directly to the user. This is not needed at all.
- Do not grant the "everyone" ACL.
- Be consistent in how you grant ACLs. It is recommended to stay consistent in your ACL structure. If you have a custom ACL that contains child ACLs continue to grant new child ACLs instead of starting to grant directly at the User or User Role.
- In order to create a custom ACL, use the pre-defined ACL(s) as an example in order to gain an understanding on which individual entry points are required.
User Access
Recommendations
- Create custom menus for users based on individual roles. These custom Menus should only contain what you want the user to see.
- Create custom Screen Sets for users based on roles. These custom Screen Sets should hide fields and available actions you don't want users to see.
- Create custom Manager Layouts for users based on roles. These custom Manager Layouts should hide fields you don't want users to see.
- When allowing users to change user role that change business domains by use of the VPD Domain, ensure to have equivalent user access records in the domain being changed to.
VPD
Recommendations
- Create custom VPD Profiles to be assigned to the custom user roles you defined.
- Use External Predicate Rules and create External Predicates to restrict data.
- It is recommended to block every table that is not required with a predicate that will never be true like (1=2).
- Do not modify the DBA and OTM-GUEST VPD Profiles.
- Take precaution in creating External Predicates to restrict data visibility when a certain join or condition may not exist prior to business actions completing.
Account Policies
Recommendations
- Use the default "BASIC POLICY" Account Policy for users or create an even stronger custom account policy based on the default password rules. This will ensure a strong Oracle Transportation Management user password.
- Don't use the "NO RESTRICTIONS" Account Policy.
- Don't use the "NO DORMANCY" Account Policy.
- Don't modify the default Account Policies.
General
Recommendations
- "Menu Security" is not security; it is obfuscation at best. While most interactive end users will not stray outside of URL menu links presented, users could potentially still gain access if they know the service resource URLs.
- Use caution when granting access to use SQL Execution Interface tool.
- Use caution when granting access to upload files into the service.
- Use caution when granting access to upload raw data via CSV or DB.XML.
- Use caution when granting access to use any external integration functionality.
- Use caution when granting abilities to define External Systems
- Disable or delete obsolete and unused External Systems to prevent accidental usage.