A successful security strategy should include a close look at the broader security environment in which you’re doing your reporting. To make sure you have all your bases covered, we recommend taking the following steps when building a security strategy for your institutional data.

Step One: Complete a Security Inventory

Like with any institutional decision-making, let the data drive your security decisions. Before you get into the finer points of your security structure, it’s important to take stock of all the people and programs that will need to be accounted for.

• Identify the systems you wish to use with Argos: As an enterprise tool, Argos can be used to report against a variety of systems. Create a list of these systems and verify that MAPS and Argos are capable of working with them.
• Identify the owners of the systems: It is important to identify the individuals responsible for the systems you wish to use for reporting. Some systems may have multiple owners, or ownership may be fragmented, with a variety of individuals having responsibility for different parts of the system. (This setup will likely be prevalent for cloud-based applications.) These owners can explain the existing security setup for their systems. This is important information that will be used to configure MAPS and Argos security.
• Identify the users of the system and the roles they will fill: You are certain to have a variety of users with different needs and skills. While it is not necessary to identify every individual user of the system at this stage, it will be useful to know the different types of users and how they will be using the system. The applications may offer different roles or levels of access. Start dividing the users into roles according to the tasks they perform and the level of access they will need. These roles will be used to set up the MAPS and Argos security roles later on.

Step Two: Review Your Security Goals & Policies

As you are setting up a new software environment, you’ll want to take the opportunity to review the relevant security policies at your institution. Based on that review, you can establish some goals that your security setup will help you achieve.

• Review your existing policies and procedures as they relate to data access: It is tempting to study the dozens of security features in MAPS and Argos and simply start implementing those that sound most useful. This approach can be counterproductive. We encourage you to implement the policies you have, rather than try to invent new policies around the features in MAPS. Working with the system owners identified above, you should clearly define the security policies you would like to enforce. This will guide your choice of security configuration.
• Clearly define your specific security goals: These goals should reflect your security policies. For example, you might have a policy that only Human Resources personnel are allowed to see Social Security Numbers. This would be reflected in the goal, “Restrict access to any tables containing SSNs to only Human Resources staff.”

Step Three: Establish Your Security Framework

Once you have the broader details worked out, it’s time to start building a security framework into your applications. Here is an overview of this step.

• Determine if you intend to create MAPS users, use existing LDAP users or implement federated SSO: If you have an LDAP server that contains your users, this greatly eases setup and maintenance, as you can simply add the desired LDAP users to MAPS. If you have existing LDAP groups that reflect your organizational structure, you may be able to simply import these groups instead of the individual users. If using federated SSO, MAPS needs to know the AD group of the user, which is passed back in a SAML attribute.
• Determine whether object-level security is sufficient to meet your goals: Object-level security is powerful, flexible, and usually easy to maintain. You may be able to meet most of your security goals by simply ensuring that users or groups are only able to access the appropriate folders and objects.
• Determine what database permissions DataBlock Designers should have: Since Report Viewers and Writers cannot create new queries, you can generally meet your security goals for these users using only object-level security. DataBlock Designers, however, pose an additional problem as they are able to create new queries and objects. Carefully examine your policies as it relates to these users and configure your database connections to enforce these policies. For example, if a subset of your DataBlock Designers will only be working in the Payroll area, you can make sure that these users connect to the database with an account restricted to only Payroll tables.

Conclusion

Implementing security while still allowing your organization’s users access to the systems they need is not easy. Hopefully, by following the recommendations above, you will soon be enjoying the benefits of a more secure reporting environment.