High Security Settings - Deny or Allow Access?

richelle_pivec · ‎08-11-2014

I enabled the High Security Settings on our Development Instance this morning. I then went through and made a grid of all the applications/modules/related lists that various user-types couldn't access. For my next step I was going to figure out how to make the ACLs work for those areas (the catalog and homepages and some related lists).

I was just reading more in the high security wiki book and there is the section about changing the Default Mode from Deny Access to Allow Access. When I make that change, everything starts working again for the users, and they are still constrained to the roles they have for what pages they can see, catalog items they can use, applications available, etc...

Is there any reason why I have to go back to the Deny Access option and manually put in the ACLs?

My next step is to build a CMS portal, and I was told I should have High Security in place before I do that. I'm just wondering if I have to Deny Access and build the access in our if it's okay to Allow Access and use the roles to block access (as we have been doing for a while now with contextual security).

Has anyone else gone to High Security and left the Default Mode as Allow Access?

thanks, Richelle

jfarrer · ‎08-11-2014

There's a couple things that come in with High Security, the default deny ACL's is the main part of it, but it also includes some other functionality like elevated privileges. Before the High Security plugin permissions were default allow. While you can change the property to set it back to default allow, it essentially puts you back to where you were before the plugin and largely defeats the purpose of enabling the plugin as it can leave a large number of tables unprotected from a security perspective.

It can certainly be a lengthy process of going through and verifying every table that you use to make sure users have access to what they need after switching to a default deny security paradigm. Overall, however, it's a much safer approach as it helps ensure that data that is intended to be private starts locked down.

In most cases to open up access to the tables you'll just need to add record level read and write access to the appropriate roles.

From the CMS perspective for the most part the underlying permissions are used to secure data. The high security plugin just helps to make sure data that should be private stays that way.

At the end of the day, it depends on how restrictive you want to be. Keeping things open and accessible means greater ease, but often at a cost of less control and data integrity. Locking things down just swings the pendulum, so it's a balancing act of finding the right place in the middle.

View solution in original post

jfarrer · ‎08-11-2014

There's a couple things that come in with High Security, the default deny ACL's is the main part of it, but it also includes some other functionality like elevated privileges. Before the High Security plugin permissions were default allow. While you can change the property to set it back to default allow, it essentially puts you back to where you were before the plugin and largely defeats the purpose of enabling the plugin as it can leave a large number of tables unprotected from a security perspective.

It can certainly be a lengthy process of going through and verifying every table that you use to make sure users have access to what they need after switching to a default deny security paradigm. Overall, however, it's a much safer approach as it helps ensure that data that is intended to be private starts locked down.

In most cases to open up access to the tables you'll just need to add record level read and write access to the appropriate roles.

From the CMS perspective for the most part the underlying permissions are used to secure data. The high security plugin just helps to make sure data that should be private stays that way.

At the end of the day, it depends on how restrictive you want to be. Keeping things open and accessible means greater ease, but often at a cost of less control and data integrity. Locking things down just swings the pendulum, so it's a balancing act of finding the right place in the middle.

Michael Bachme1 · ‎06-03-2015

Do you know if there is any impact on user licensing if the setting is changed to 'Allow Access'? We're considering this option as an interim step in a phased approach to the eventual 'Deny Access'.

Regards,

Michael Bachmeyer

jfarrer · ‎06-03-2015

As far as I know there isn't a direct impact on licensing, but that's more a question for your account rep. From the perspective of starting with a setting of "Allow Access" it can definitely be a good approach. I don't think there's any way around the eventual need to go through the permissions in general to make sure data is properly secured.

Michael Bachme1 · ‎07-01-2015

Just a follow-up:

We upgraded to Fuji Patch 3 last week and installed High Security afterward. We changed the default setting to 'Allow Access'. It worked. However, there are new ACLs that restrict access by default. This makes sense because the system stops searching once it finds an associated ACL for activity being requested. We are modifying ACL restrictions as they are reported.

We are planning to install Patch 5 next week to resolve some high-visibility issues.

Michael Bachmeyer