SAS Security Design Best Practices, Validation and Monitoring

Size: px

Start display at page:

Download "SAS Security Design Best Practices, Validation and Monitoring"

Pearl Burns
5 years ago
Views:

1 SAS Security Design Best Practices, Validation and Monitoring Today s event will begin at 3:00 PM ET. Audio will remain muted until the event begins. When we begin, audio will be heard through your computer speakers. To access audio by phone, dial the number below followed by the access code and #: US Toll-free: Toll/International: Access Code: # If you experience any technical difficulties, please contact WebEx Technical Support at Copyright SAS Institute Inc. All rights reserved.

3 Presenters Michelle Homes Founder and Business Development Manager, Metacoda Angie Hedberg Technical Consulting Manager, SAS Shelley Sessoms Community Manager, SAS External Communications Copyright SAS Institute Inc. All rights reserved.

SAS Administration & Deployment Community Online. Everyday.

5 Copyr i g ht 2015, SAS Ins titut e Inc. All rights res er ve d. SAS, VALIDATION, AND MONITORING

6 SAS SECURITY DESIGN BEST PRACTICES INTRODUCTION Key highlights for today s presentation: SAS Metadata Security Design Best Practices Validation and monitoring techniques using Metacoda to ensure adherence to metadata security best practices File System Security Design Best Practices Based on security design best practices used within U.S. SAS Consulting SAS Global Forum 2017 Paper: Getting Started with Designing and Implementing a SAS 9.4 Metadata and File System Security Design (Authors: Angie Hedberg and Phil Hopkins) Assumption that attendees have basic knowledge of SAS security framework

7 METADATA #1: DEFINE AND IMPLEMENT PERSONAS Categorize all users in your organization based on their job function and usage of SAS software Define tasks that each persona will perform within SAS and list all SAS client applications that each persona may use Define functional security requirements for each persona For example: Administrators, Developers, Analysts, Report Creators, Consumers

8 METADATA #1: DEFINE AND IMPLEMENT PERSONAS For example: Administrators: Administrators will have full access to the SAS environment. They will perform user management, configure security, apply software upgrades and hotfixes, monitor the system, and troubleshoot end user issues. Administrators have full access to all SAS client applications. Developers: Developers will use a wide variety of SAS tools to create data, perform adhoc analysis and reporting, and generate data or reports to share with others. SAS client applications used by this persona might include: SAS Data Integration Studio, SAS Enterprise Guide, SAS Studio, and SAS Visual Analytics. Consumers: Consumers are read-only users that will consume web-based reports created by Developers. Consumers cannot create reports. Consumers will use the following SAS applications: SAS Visual Analytics and SAS Mobile BI.

METADATA #2: CREATE CUSTOM GROUPS AND ROLES FOR SIMPLICITY Default SAS groups and roles are typically narrowly focused on individual applications Create custom metadata groups that map to defined

9 METADATA #2: CREATE CUSTOM GROUPS AND ROLES FOR SIMPLICITY Default SAS groups and roles are typically narrowly focused on individual applications Create custom metadata groups that map to defined personas Create a custom role for each persona Assign capabilities across all relevant applications for each custom role Role object Group assigned to Role ROLE: Developer Developers Assign capabilities across applications

10 METADATA #2: CREATE CUSTOM GROUPS AND ROLES FOR SIMPLICITY Benefits: Simplifies the onboarding process of a new user by adding them to a single group which then grants all privileges they need in the system Allows SAS Administrators the ability to see all capabilities for a given persona by viewing a single role Note: there are some required roles with implicit capabilities, such as the Metadata Server roles. These roles must be included in your security design as well.

11 METADATA #3: USE ACTS INSTEAD OF ACES Access Control Entries (ACEs): explicit permission for some identity applied to some object Access Control Templates (ACTs): collection of ACEs saved as a pattern of permissions which can be applied to multiple objects The use of ACEs can be unmanageable, and lead to confusion or incorrect effective permissions due to user error ACTs are easier to design, implement, understand, and manage over time

12 METADATA #3: USE ACTS INSTEAD OF ACES Inherited Permission Directly applied via ACT X Directly applied via ACE

13 METADATA #4: ONLY USE GROUPS FOR ACTS Only identity groups should be used for building the rules within ACTs, never individual users This is a common best practice in any security model, but it is an important best practice and worth noting Allows for users to be easily added and removed from the system without impacting security implementation

14 METADATA #5: DENY BROADLY AND GRANT SPECIFICALLY ACTs should be defined by denying permissions to the broadest identity level possible and granting permissions more precisely to the groups that require access Implemented by denying PUBLIC or SASUSERS, then granting permissions selectively to groups Avoids potential permission conflicts and unintended effective permissions caused by user error Don t forget to grant back permissions to privileged identities

15 METADATA #5: DENY BROADLY AND GRANT SPECIFICALLY If your deployment requires access for PUBLIC users, then always broadly deny access to the PUBLIC identity in ACTs If your deployment does not allow any PUBLIC users, and PUBLIC users are denied all permissions on the Default ACT, or removed altogether from the Default ACT, then SASUSERS can be used for broad denial of permissions in ACTs

16 METADATA #6: IDENTIFY BUSINESS ACCESS PATTERNS AND DEFINE ACTS TO ENCAPSULATE THE PATTERNS Define business access patterns and build ACTs to implement the pattern For example: Private pattern, Write pattern, Register pattern, Update pattern By encapsulation, this means to define all permissions for all groups within a single ACT that are required to implement the access pattern The name of the ACT should clearly identify the access pattern

17 METADATA #6: IDENTIFY BUSINESS ACCESS PATTERNS AND DEFINE ACTS TO ENCAPSULATE THE PATTERNS Private Pattern: used to restrict read access to a specific group of users PUBLIC or SASUSERS: deny ReadMetadata, deny Read (d-rm, d-r) <Business Group>: grant ReadMetadata, Read (RM, R) SAS Administrators: grant ReadMetadata, Read (RM, R) SAS System Services: grant ReadMetadata, Read (RM, R) Write Pattern: enables full write access to objects PUBLIC or SASUSERS: deny WriteMetadata, deny Write, deny Create, deny Delete, and deny Administer (d-wm, d-w, d-c, d-d, d-a) <Functional Business Group>: grant WriteMetadata, Write, Create, Delete, and Administer (WM, W, C, D, A) SAS Administrators: grant Write, Create, Delete, and Administer (WM, W, C, D, A) SAS System Services: grant WriteMetadata (WM)

18 METADATA #6: IDENTIFY BUSINESS ACCESS PATTERNS AND DEFINE ACTS TO ENCAPSULATE THE PATTERNS Register Pattern: enables users to add ( register ) new objects into a metadata folder, but not update the folder itself PUBLIC or SASUSERS: deny WriteMetadata (d-wm) <Functional Business Group>: grant WriteMemberMetadata (WMM) SAS Administrators: grant WriteMetadata (WM) SAS System Services: grant WriteMetadata (WM) Update Pattern: enables users to modify metadata objects PUBLIC or SASUSERS: deny WriteMetadata (d-wm) <Functional Business Group>: grant WriteMetadata (WM) SAS Administrators: grant WriteMetadata (WM) SAS System Services: grant WriteMetadata (WM)

19 METADATA #6: IDENTIFY BUSINESS ACCESS PATTERNS AND DEFINE ACTS TO ENCAPSULATE THE PATTERNS SAS Administrators Update ACT PUBLIC or SASUSERS: deny WriteMetadata (d-wm) SAS Administrators: grant WriteMetadata (WM) SAS System Services: grant WriteMetadata (WM) Used to secure: Access Control Templates Groups and Roles Server components SAS Folders root metadata folder

20 METADATA #7: APPLY PERMISSIONS AT THE HIGHEST OBJECT LEVEL POSSIBLE ACTs should be applied on the highest object level possible to achieve the desired restrictions Define the metadata folder structure with this best practice in mind For example, apply ACT on a Reports folder and have those permissions inherit down to all reports created within the folder versus applying ACTs on each individual report object

21 METADATA #7: APPLY PERMISSIONS AT THE HIGHEST OBJECT LEVEL POSSIBLE Apply Hotels Private ACT Apply Hotels Marketing Private ACT Apply Hotels Marketing Developers Write ACT Apply Hotels Marketing Developers Register ACT

22 METADATA SUMMARY OF METADATA SECURITY BEST PRACTICES Define and Implement Personas Create Custom Groups and Roles for Simplicity Use ACTs instead of ACEs Only use Groups for ACTs Deny Broadly and Grant Specifically Identify Business Access Patterns and Define ACTs to Encapsulate the Patterns Apply Permissions at the Highest Object Level Possible

23 METADATA Monitoring and Validation of Metadata Security Design Best Practices

24 Where Metacoda helps SAS Apps SAS Metadata Server SAS Metadata Authorization Layer SAS Resources Metacoda helps here DB Auth Layer DB Resources Op Sys Auth Layer File / Other Resources

Metacoda Identity Sync Metacoda Security Plug-ins Metacoda Testing Framework Metacoda Utility

25 ABOUT METACODA. since 2007 Provide add-ons to SAS Software for enhanced metadata visibility and exploitation Metacoda Identity Sync Metacoda Security Plug-ins Metacoda Testing Framework Metacoda Utility Plug-ins - free Custom Tasks (for SAS Enterprise Guide & AMO) - free Goals: Improve your productivity through enhanced metadata visibility Helping to keep your SAS platform secure

26 BUSINESS PROBLEMS WE SOLVE Keeping SAS Users & Groups in sync with Active Directory Including large & complex directories all without code! Metacoda Identity Sync Knowing/documenting your SAS Metadata Security Easily showing an Auditor what someone has access to who has access to something Metacoda Security Plug-ins Verifying & proving to an Auditor your SAS Metadata Security is still intact and you can quickly detect and act on changes Metacoda Testing Framework

27 METADATA SECURITY TESTING: WHY? Over time we get changes from various user roles Production (Lev1) is it still adequately secured? tomorrow? next week? next month?

28 METADATA SECURITY TESTING: WHY? Test for consistency across multiple environments Production (Lev1) Test (Lev2) Development (Lev3) Test

29 METADATA SECURITY TESTING: WHY? Test for consistency during SAS version upgrades SAS 9.2 (Lev1) SAS 9.3 (Lev1) SAS 9.4 (Lev1) Test Test

30 TESTING A SINGLE ENVIRONMENT: TEST & REPEAT Tomorrow, Next Week, Next Month: Compare current state to desired state using previously exported Metadata Security Test XML files

31 CONSISTENCY TESTING DIFFERENT ENVIRONMENTS Export Metadata Security Test XML files from source environment to test for consistency in target environment.

32 TESTING FOR RECOMMENDED SECURITY PRACTICES Metacoda Security Testing Framework includes tests to help sites follow recommended security practices Choose from recommended practice tests you want to follow Adjust ignores list / exclusions (if necessary) Example provides in the Batch Interface package metacoda-plugins-batch\examples\sectest-run-tasks\metacoda-recommended-practices.xml

33 METADATA Demonstration

34 MULTIPLE AUTHORIZATION LAYERS There are multiple authorization layers in a SAS environment SAS Metadata Layer File System Layer Database Layer Each has its own authorization facility and permissions to consider

35 FILE SYSTEM #1: UNDERSTAND TOUCHPOINTS BETWEEN SAS METADATA AND THE FILE SYSTEM Not all metadata objects have a corresponding physical file, and not all files on the file system have a corresponding metadata object Administrators need to understand the associations between metadata objects and files so that you can intelligently define and properly secure the file system directory structure

36 FILE SYSTEM #1: UNDERSTAND TOUCHPOINTS BETWEEN SAS METADATA AND THE FILE SYSTEM Content Type Metadata Object File System File SAS Visual Analytics Report or Exploration SAS Enterprise Miner Project X X SAS Enterprise Guide Project maybe on client file system or SAS server file system SAS Data Set maybe X X SAS Program File (or Macro code) Custom Format X X SAS Data Integration Studio Job X maybe (if code deployed)

37 FILE SYSTEM #2: MIMIC THE METADATA FOLDER STRUCTURE At a high level, the metadata folder structure and the file system directory structure should mirror one another For example, if the metadata folder structure is organized by Business Units and Departments, the same organizational hierarchy should be used to define the file system directory structure Subfolders defined in metadata for specific object types might not all map to subdirectories on the file system, and vice versa for physical files that do not exist in metadata In addition, permissions should be similar between metadata and the file system This simplifies the end user experience and allows for a consistent navigation path

38 FILE SYSTEM #2: MIMIC THE METADATA FOLDER STRUCTURE Mimic the Metadata folder structure on the file system X /enterprise /hotels X /shared /shared /marketing /data /data /macros /formats /data /data_integration /em_projects /formats /programs /scheduled_jobs /storedprocesses

39 FILE SYSTEM #3: DEFINE SERVICE ACCOUNTS BASED ON THE REQUIRED SECURITY GRANULARITY Define multiple service accounts according to the security granularity required For example, you can implement a unique service account per Tenant or Business Unit Service accounts are commonly used for: Scheduled jobs Stored Process Server File system directory owner (on UNIX)

40 FILE SYSTEM #4: USE SETGID PERMISSION ON DIRECTORIES (FOR UNIX) To facilitate file sharing on UNIX systems, specify the setgid permission on directories Ensures all new files created within the directory will inherit the same group owner as the parent directory The setgid permission will also inherit down to newly created subdirectories Greatly improves the end-user experience

41 FILE SYSTEM PULLING THE FILE SYSTEM BEST PRACTICES TOGETHER Directory Owner Group Owner Permissions Root Directory Subdirectories Description sas sas 755 /sasdata Root directory for SAS permanent data and code parks_srv parks 2750 /parks Line of Business specific root directory parks_srv parks 2770 /data Parks: SAS data or views parks_srv parks 2770 /data_integration Parks: DI root directory for code, data, deployed jobs parks_srv parks 2770 /em_projects Parks: shared SAS Enteprise Miner projects parks_srv parks 2770 /formats Parks: custom formats parks_srv parks 2770 /programs Parks: SAS program (code) files parks_srv parks 2770 /scheduled_jobs Parks: deployed jobs for scheduling parks_srv parks 2770 /storedprocesses Parks: stored process code files hotels_srv hotels 2750 /hotels Line of Business specific root directory hotels_srv hotels 2770 /data Hotels: SAS data or views hotels_srv hotels 2770 /data_integration Hotels: DI root directory for code, data, deployed jobs hotels_srv hotels 2770 /em_projects Hotels: shared SAS Enteprise Miner projects hotels_srv hotels 2770 /formats Hotels: custom formats hotels_srv hotels 2770 /programs Hotels: SAS program (code) files hotels_srv hotels 2770 /scheduled_jobs Hotels: deployed jobs for scheduling hotels_srv hotels 2770 /storedprocesses Hotels: stored process code files sas sas 755 /sasusers Root directory for individual personal user folders <user> sas 700 /<user> Implicit "SASUSER" library configured to this path

42 FILE SYSTEM SUMMARY OF FILE SYSTEM SECURITY BEST PRACTICES Understand Touchpoints between SAS Metadata and the File System Mimic the Metadata Folder Structure Define Service Accounts based on Required Security Granularity Use SETGID Permission on Directories (for UNIX)

43 REFERENCES PULLING METADATA AND FILE SYSTEM TOGETHER TO BUILD A SECURITY MODEL 10-Step Process for creating a SAS security model SAS Global Forum 2017 Paper: Getting Started with Designing and Implementing a SAS 9.4 Metadata and File System Security Design Additional SAS Security Resources: SAS 9.4 Intelligence Platform: Security Administration Guide Five Papers on SAS 9.4 Security Model Design (Author: David Stern) Model-Design-part-1/ta-p/ (part 1) Model-Design-part-2/ta-p/ (part 2)

44 REFERENCES POSTS AND PAPERS ON METACODA METADATA TESTING FRAMEWORK Blog: Following SAS GEL Security Rules with Metacoda Security Tests Blog: Testing Conditional Grants in SAS Visual Analytics Blog: Testing Recommended Practices with SAS Metadata Security Blog: SAS Metadata Security Testing SAS Global Forum 2014 Paper

@SASSoftware SAS Software, SASUsersgroup

47 Director+ attend for free Students attend for free (Academic Faculty = 50% off) Early Bird Discount until July 31! Register Today! C opyr i g ht 2017, SAS Ins titut e Inc. All rights res er ve d.

SAS Metadata Security 201: Security Basics for a New SAS Administrator

ABSTRACT Paper 1293-2017 SAS Metadata Security 201: Security Basics for a New SAS Administrator Charyn Faenza, F.N.B. Corporation The purpose of this paper is to provide an overview of SAS metadata security