SAS Safety Scalable Performance Data Server 4.5 用户手册

When defining user-specific ACL permissions, you can use an ACL group wherever you
can use an explicit SPD Server user ACL. Using an ACL group grants privileges to the
ACL group instead of only to a specific SPD Server user.

SPD Server allows you to control access to table contents at the column level through the
use of ACLs. Column security ACLs can be applied to individual users at the user level,
or applied to collections of users at the group level. SPD Server enforces precedence for
user and group ACL permissions: first user ACL permissions are applied, then group ACL
restrictions are applied. SPD Server user permissions override SPD Server group
permissions.

When you use an ACL statement to create a protected column in a table, all individual users
or groups are automatically denied access to the protected column until they are explicitly
granted ACL permission to access it. When you issue an ACL statement to grant or
deny the contents of a table column to a single user or user group, the protected column
automatically becomes unavailable to all individual users and user groups, unless they are
specifically given access to the protected column.

Let's examine a scenario where a testing department hires a new member, Joe. Joe has
applied for classified security clearance, but his security clearance level won't be certified
for several weeks. All members of the department use an SPD Server table TESTING that
contains a column of classified information. Joe needs access to all of the TESTING table
except the protected column, and the rest of his group needs access to the whole TESTING
table.

First, you submit a user-level ACL statement to restrict the secure column in table
TESTING from Joe. Joe is explicitly denied access, but since the column is now a protected
entity, all other TESTING table users are also denied access to the column by default. Once
a column is protected via ACL security, explicit permissions must be granted in order for
any user (or groups of users) to be able to access the column content. Instead of issuing
user-level column ACL permissions to the rest of the testing group individually, you issue
a group-level ACL column permission to the user group TESTGROUP that explicitly
grants access to the protected column.

SPD Server reads the user-level ACL permissions first, and gives Joe access to the table
TESTGROUP, but restricts him from the secure column. Then SPD Server reads the group
ACL permissions, and grants all of the TESTGROUP members access to the full table,
including the secure column. Joe is a member of TESTGROUP, but the user-level ACL
permissions maintain precedence over group-level ACL permissions. This results in all of
TESTGROUP having full table access, except Joe. Joe's user-level ACL column security
restriction prevents him from accessing the classified column.

Now consider another scenario, where John manages a group DEVGROUP whose
members record their billable project hours and codes in an SPD Server table. In that table,
manager John keeps billing rate information based on employee salaries in a protected
column RATE. Only John should be able to see the entire table, and the rest of the
DEVGROUP should be able to see the table minus the RATE column. In this case, you
create column security by protecting the RATE column with a user-level ACL permission
statement for John. The DEVGROUP members can have full table permissions at the group
level, but will not see the protected column because John's user-level column security ACLs
will override any group-level ACLs for the DEVGROUP table.

You can use generic ACL names for a class of resources that have a common prefix. You
can use the asterisk symbol "*" as a wildcard. This permits you to make a single ACL entry
instead of making explicit entries for each resource. For example, if you have tables named