If you read the Oracle documentation on Oracle Analytics with the intent of coming away with a basic understanding of how to plan and execute security, you might find yourself feeling lost. While the documentation provides a wealth of technical information, and even includes a great roadmap for implementing a security policy, it is a daunting amount of information to absorb. The documentation does not provide an easy to understand, high-level overview of the various security concepts and how they work together. 

Oracle Analytics is a reporting and data analysis tool. When you are creating a security plan, it helps to remember the basics of reporting: 

1. Collect the data
2. Arrange and format the data
3. Present the data

Keeping these three steps in mind, you have a basic framework on which to build an understanding of Oracle Analytics security: 

1. Secure the data
2. Secure the tool
3. Secure the catalog objects

Securing the Data

A typical user population will have different levels of data access requirements. Executives may need to see high-level numbers that may be very sensitive, like total quarterly profits. Human Resource managers may need to see salaries, home addresses, and Social Security numbers. A sales representative may need access to contact information for leads. Oracle Analytics provides granular data access management. User access to data can be limited by data source, tables, rows, and columns. Questions to consider include:

• Should the user’s data access be filtered in some way, by row, or only certain elements?
• Will the user only be allowed to see data in specific subject areas?
• Can users be grouped in some way that simplifies the security setup?

Securing the data is controlled by the data rights that an individual user has against the data source (typically controlled by the database).

Securing the Tool

Oracle Analytics provides a platform for the creation of dashboards, analyses, reports, and visualizations. These creations can then be shared and distributed through your organization via prompted dashboards, social media, scheduled email deliveries, or even print. Some users of Oracle Analytics may be limited to consuming pre-generated reports. Others may be empowered to create interactive analytics to be accessed by your entire organization. Many of your users may be somewhere in between. You have many options for changing what each user can do in Analytics, including:

• Will the user only look at reports and dashboards?
• Can the user create a visualization, report, or a dashboard (objects)?
• Will the user be able to export to Excel?
• Are there groups of users that need to collaborate on certain visualizations, reports, or dashboards?

For Oracle Analytics, Application Roles control what rights a given user has, e.g. BI Consumer, BI Content Author, or BI Service Administrator.

Securing the Catalog Objects

Last but not least, you must secure the various objects created within Oracle Analytics. These are the reports, visualizations, projects, and dashboards that are the work product of using Analytics. A user may only need to see a narrow set of pre-determined dashboards, or they may need to edit reports that are to be used enterprise-wide. Questions to ask here include:

• Which analyses does a user need to see?
• Does the user need to be able to edit a specific dashboard?
• Can user-created objects be immediately seen by others, or must they be approved first?

For Oracle Analytics, object security is controlled by granting access to various user and groups and roles by inspecting the catalog in Oracle Analytics.

Obviously, these considerations are only the first steps in creating a security policy. If you have any questions about this entry, or are working through your own security process, please do not hesitate to email me at jclark@vlamis.com or use the Contact link above.