Security Rules: Which is a better way to write this security rule? Any advice?

[mwallman]

I want to create a security rule which will restrict access to a specific data connection to 6 users.

From the two options below, which is better, more efficient, better quality?

Option A)

UserID1

OR

UserID2

OR

UserID3

OR

UserID4

OR

UserID5

OR

UserID6

Option B)

Write it useing a Custom Property where a value is assigned to the 6 users in the Users page and write a security rule restricting on that value.

Are there any other better ways?

[Anil_Babu_Samineni]

I would rather think option C

1) Create AD group and add 6 users into AD groups

2) Align that AD group to the custom property of functions like Apps, Data connections etc.

Then, Create the rule as follows (user.group=resource.@ADGroup)

Here ADGroup is something the name from customer property.

[mwallman]

Hi Anil,

We don't have an option to create AD Groups that easily unfortunately.

[Anil_Babu_Samineni]

I am not that familiar who have rights to create, But phenomenal Windows team can help (This is straight forward)

Coming to your options, I never recommend personally due to users list is huge. If you think that only 6 users you want to produce, There is no mean that Option B has issue? 

[Levi_Turner]

> which is better

Not really an answerable question. The best security policy is one which is used. The policy is more apt to be used if it's relatively simple to use.

> more efficient

Option B

> better quality?

Option B

Ultimately if this case is a one-off then investing the mental energy in designing a scalable rule isn't worth it. But that is a rare scenario, typically this schema of how to provision access will be re-used across other rules. A simple rule which uses custom properties (or more ideally AD groups like @Anil_Babu_Samineni mentions) allows for an easy provisioning of access across multiple users and data connections (e.g. resource.@DataConnectionAccess  = user.@DataConnectionAccess  ). Are there more efficient ways of doing this? Yes, groups would be more efficient (e.g. resource.@DataConnectionAccess  = user.group) but it sounds like that isn't a live option for this organization at the current time.  

[mwallman]

Hi @Levi_Turner and @Anil_Babu_Samineni 

Totally understand the points. In this case I wanted to understand in terms of performance which might be better, A or B, or whether it's so marginal it doesn't make much difference.

To open up the question more, if AD groups was an option, would that be the most recommended way?

In terms of requirements I don't really see the users (6 of them) shrinking or growing in size in the future.

[ChotanaBI]

Hi there

+1 to Levi's answer

I also add that it's easier to manage by yourself via the QMC rather than asking your IT to create and manage the AD groups.

Whenever you have to change/add/remove a user, then it's easier and faster via the QMC.

Doing this, you'll be able to create more groups and split the teams.

In terms of performance, I don't think there'll be any difference ; it'll be a matching between properties in the system.