Checklists |
Introduction |
You can use this appendix to verify that security issues are being addressed as appropriate for your environment and goals. Not all measures are relevant in all deployments. It is a good practice to review your security configuration on a periodic basis.
General Measures |
Make sure that the configuration directories are protected by appropriate operating system permissions. See the table Recommended and Default Operating System Protections in the SAS Intelligence Platform: System Administration Guide.
If your deployment includes sensitive data, review host access to SAS data and evaluate the workspace server pooling configuration. See Server Configuration, Data Retrieval, and Risk.
If your deployment includes sensitive data, make sure that the SAS Web Report Studio query cache library (wrstemp) is protected by appropriate operating system permissions. See Manage Host Access to the Query Cache Directory in the SAS Intelligence Platform: Web Application Administration Guide.
If your deployment includes sensitive data, make sure that the SAS Web Report Studio distribution library (wrsdist) is protected by appropriate operating system permissions. See Verifying Permissions for the Distribution Library in the SAS Intelligence Platform: Web Application Administration Guide.
On Windows, minimize availability of the privilege Log on as batch job. See Windows Privileges.
For industry-standard encryption, license SAS/SECURE. See About SAS/SECURE.
If your deployment includes the SAS Anonymous Web user, determine whether it is necessary and appropriate to keep that identity in place. See About PUBLIC Access and Anonymous Access.
Consider tracking changes to server logging levels. See Audit Server Logging Changes in the SAS Intelligence Platform: System Administration Guide.
Consider limiting the scope of trusted peer connections. See Trusted Peer Connections.
Metadata Layer Measures |
Limit the WriteMetadata permission on servers. See Permissions on Servers.
Limit the WriteMetadata permission on ACTs. In general, only the SAS Administrators group has a grant of the WriteMetadata permission on the Authorization tab of an ACT.
Limit the WriteMetadata permission on custom folders. To reduce the chance of inadvertent or deliberate changes to a custom folder, grant WriteMemberMetadata (instead of WriteMetadata) to users who should contribute only content. See Using WriteMetadata and WriteMemberMetadata Permissions.
Review the WriteMetadata permission on OLAP schemas and libraries. To prevent someone from adding cubes to an OLAP schema or tables to a library, set denials of the WriteMetadata permission on the schema or library. Remember to preserve access for administrators as appropriate.
Review the permission pattern of each of your ACTs. See Permission Patterns of Selected ACTs.
Review who has privileged user status from metadata memberships. See Distribution of Selected Privileges.
Review who has privileged user status from the adminUsers.txt file. See Distribution of Selected Privileges.
Consider reducing WriteMetadata access to the user definitions for any unrestricted users. This prevents restricted user administrators from updating an unrestricted user's definition and then logging on as that unrestricted user. To add this protection, access the Authorization tab of each unrestricted user and add an explicit denial of the WriteMetadata permission for PUBLIC.
Consider tracking changes to metadata layer permissions and ACTs. See Security Report Macros.
Consider limiting the locations from which SAS Web Report Studio uses information maps. See Limiting the Availability of Relational Information Maps in the SAS Intelligence Platform: Web Application Administration Guide.
Enhanced Protections for Passwords |
If you have SAS/SECURE, upgrade encryption strength for passwords in configuration files (from SASProprietary to AES). See Password Updates for Service Accounts.
If you have SAS/SECURE, upgrade encryption strength for outbound passwords in transit (from SASProprietary to AES). See How to Increase Encryption Strength for Outbound Passwords in Transit.
Consider preventing users from saving their passwords in their desktop connection profiles by setting SASSEC_LOCAL_PW_SAVE="N" (or ="0" or ="F") in the metadata server's omaconfig.xml file.
Consider strengthening password policies for internal accounts. See How to Change Internal Account Policies.
Consider removing the SAS Trusted User's password from some configuration files. See How to Reduce Exposure of the SASTRUST Password.
Copyright © 2011 by SAS Institute Inc., Cary, NC, USA. All rights reserved.