folder architecture and security -recommendations

[ANLYNG]

We are moving to a new platform and need to decide how the folder/security setup is best handled.

We have some confident data which only a few of our DI developers must see and develop on. However there is a lot of other data all developers are allowed to see.

How is that managed best in the DWH folder structure as we do not want to minimize time on security issues…?? please specify in detail the security setup what model is best and why ?

Thanks in advance.

It looks like this today:

Solution 1

DWH

- data

       ---subject1

       ---subject2

       ---subject3

       ---subject4

       --confident subject1

       --confident subject2

- jobs

       ---subject1

       ---subject2

       ---subject3

       ---subject4

       --confident subject1

       --confident subject2

Could it be better with this solution as the secuty could be set on higher level and I do not need to use a di developer denied?? On the confident folders on solution 1??

Solution 2

DWH

- data

       ---subject1

       ---subject2

       ---subject3

       ---subject4

- jobs

       ---subject1

       ---subject2

       ---subject3

       ---subject4

DWH_confident

- data

       --confident subject1

       --confident subject2

- jobs

       --confident subject1

       --confident subject2

[MichaelLarsen]

I would prefer your solution 2.

I will always try to set the security on as high a folder level as possible and since solution 2 only requires you to set it on the DWH_confident folder.

Another variation might be this:

DWH

  -subject1

     - data

     - jobs 

  -subject2

     - data

     - jobs 

  -subject3

     - data

     - jobs 

  -confident_subject1

     - data

     - jobs 

  -confident_subject2

     - data

     - jobs 

Then security would be DI Developers on the DWH folder and on the confident_subjectX folders.

I still like the solution 2 the best.

[CJac73]

Solution 2 is your best option and easiest to maintain going forward. Set security at the highest folder, and as new data is added it carries the rights within the folders

[Quentin]

Solution 2 is nice, as long as you know that:

1. you will always want all developers to be able to see all of the DWH data.
2. you will always want the same subset of developers to be able to view all of the DWH_confident data

So solution 2 would break down if you add a third confidential subject, and it's you want a different subset of developers to be able to see that data than can see confidential subject1.

If the number of subjects is low, I tend to use:

DWH

  -subject1

     - data

     - jobs 

  -subject2

     - data

     - jobs 

  -subject3

     - data

     - jobs 

  -confident_subject1

     - data

     - jobs 

  -confident_subject2

     - data

     - jobs

That way all of the subjects can inherit security from the DWH folder, and each subject can impose stricter security. The cost is that each time you create a new confidential subject, you need to specify the group(s) that can see it rather than rely on the inherited security.

[ErikLund_Jensen]

Hi @ANLYNG 

We use a structure, where we rely on heritance from the top level, and it works very well. We never need to set individual permissions on any object apart from defining and setting a new Protected-AD group on a new subject in the protected area. All Protected-AD groups contain an Administrator group together with individual members or Organizational groups, and all group maintenance is done i AD by the user Administration Department and updated i SAS in daily batch.

The logical structure is mirrored in the physical data structure, where we use inheritance as well, and the maintenance is limited to setting the new AD group on a new subject folder in the protected area.

The protected area (SAS Data Beskyt) is separate from the unprotected (SAS Data Integration Studio Custom Tree) area at root level.

Note: Beskyt means protect in danish.

Basically we work with 3 main levels in the data warehouse: Staging, Data Warehouse and Data Mart.

The organization is different in the protected and the unprotected area, because of the need for inheritance in the protected area:

The protected area is organized as Subject - DWH Level - Data/Jobs.

The unprotected area  is organized as DWH Level - Subject - Data/Jobs.

So in principle, the structure is as follows:

Example of a structure in the protected area:

[SimonWilliams]

This may not be specific enough for what you are trying to achieve but i think it's worth mentioning in the grand discussion of authorization.

There are some useful materials which talk about this subject. See:

SUGA presentation SAS® Security Design Best Practices, Validation and Monitoring: 

https://communities.sas.com/kntur85557/attachments/kntur85557/library/2413/1/SEP2017SUGA-Presentatio...

Five papers on Recommended SAS 9.4 Security Model Design:

https://communities.sas.com/t5/SAS-Communities-Library/Five-papers-on-Recommended-SAS-9-4-Security-M...

https://communities.sas.com/t5/SAS-Communities-Library/Five-papers-on-Recommended-SAS-9-4-Security-M...

[MichelleHomes]

Thanks @SimonWilliams for mentioning @angieh and my SUGA presentation.

@ANLYNG you may also want to look at Angie's 2017 SAS Global Forum paper (and supporting document) , "Getting Started with Designing and Implementing a SAS 9.4 Metadata and File System Security Design", that goes into more detail

https://communities.sas.com/t5/SAS-Global-Forum-2017/If-you-are-interested-in-SAS-Metadata-Security-...

Kind Regards,

Michelle

[sunfly818]

Just a suggestion from experience and practical customer applications.  Data usually lives longer than a project or could cross many projects/departments.  I usually separate my data libraries away from any projects or departments and then assign the security as interest in the data grows (morphs).  I document who the owns the data such as using the description to put in business owner name for the folder or library for a quick reference so that I can contact them for approval grants of access of the data and for auditing.   If you move the data under projects or departments, you run the risk of lots of duplicate data, stale data and inaccurate reporting, and hard to manage security as well.  I just try to think of each data library as like a datamart and treat it as such.

- Data

  - library

  - library2

  -etc

projects (cross dept)

  -project

  -project2

department (only)

    - branch or group

    - branch 

        - project

        - project2