The following list reviews
key guidelines and recommendations that help you minimize administrative
effort in setting up and maintaining metadata-bound libraries.
-
Use SAS (not host commands) for
management of physical data. Using host commands doesn’t compromise
security, but it can decrease clarity and create noise (warnings)
in the audit logs.
See Security Impact of Moving Tables.
Note: An exception to this guideline
is that using a host copy command to back up or restore physical data
to the same directory is not problematic.
-
Within the
/System/Secured
Libraries
folder in metadata, open up access only
as necessary. In particular, grant metadata Write access (the WriteMetadata
or WriteMemberMetadata permissions) to only administrators that should
be able to alter access to the metadata-bound data.
-
After you bind libraries to metadata,
review the metadata-layer permissions on the generated secured library
objects and secured table objects, and adjust access if needed. For
example, you can use SAS Management Console to add users or groups
to a secured table’s
Authorization tab,
and grant (or deny) the Select permission (to manage Read access to
the data).
-
If you use the metadata promotion
tools (for example, to create separate deployments for development,
test, and production environments), maintain a separate copy of your
physical data for each environment. The alternative, pointing multiple
metadata servers at the same physical data, is supported but introduces
significantly more complexity.
For more information
about promoting secured library objects, secured table objects, and
secured data folders, see “Promotion Details for Specific Object Types” in Chapter 21 of SAS Intelligence Platform: System Administration Guide.
-
Create or modify a metadata-bound
library at a time when the physical data is not being accessed by
other users. If the physical data is in use, some AUTHLIB procedure
actions on open tables might fail. Interactions with a libref that
was established before a library is bound are as follows:
-
For an existing physical table,
the pre-established libref is subject to security that is implemented
in the subsequent statement. Access that occurs in these circumstances
causes a message to be written to the log. The message explains that
the physical table is in a library that does not have a secured library
location.
-
For a new physical table, the pre-established
libref is not subject to security that is implemented through the
subsequent statement, and the new table is not bound to a secured
table object.
-
Ensure that all physical tables
within a metadata-bound library are protected by that library. This
standard, default state maximizes clarity. Special circumstances (for
example, a table that has a different, pre-existing password) can
result in a mixed state (for example, one of the tables within a metadata-bound
library is not secured). You can use the REPORT statement to verify
that this guideline is met.
-
Ensure that all physical tables
that are protected by a particular metadata-bound library remain within
that library (directory). This standard, default state maximizes clarity
and is essential for REMOVE statements to be fully effective. Special
circumstances (for example, a table that is host-copied to another
directory) can prevent a REMOVE statement from unbinding the relocated
data set.
-
If you bind data that users are
accustomed to accessing directly, inform those users that they must
establish a connection to the metadata server before they can assign
a libref against a metadata-bound library.
-
In your metadata backup strategy,
remember to consider your secured data folders, secured library objects,
and secured table objects.
See Chapter 11, “Best Practices for Backing Up and Restoring Your SAS Content,” in SAS Intelligence Platform: System Administration Guide.
-
Use the LIBNAME option AUTHADMIN=YES
when you are repairing any inconsistencies between physical data and
its corresponding secured library and secured table objects in metadata.
Do not use AUTHADMIN=YES in other circumstances.