Data Integrity and Security Protecting Connection Information 23
the DATASETS procedure’s MODIFY statement.
The syntax for using PROC DATASETS to assign a password to an access descriptor,
a view descriptor, or a SAS data file is as follows:
PROC DATASETS LIBRARY=libref MEMTYPE=member-type;
MODIFY member-name (password-level = password-modification);
RUN;
The password-level argument can have one or more of the following values: READ=,
WRITE=, ALTER=, or PW=. PW= assigns read, write, and alter privileges to a
descriptor or data file. The password-modification argument enables you to assign a
new password or to change or delete an existing password. For example, this PROC
DATASETS statement assigns the password MONEY with the ALTER level of
protection to the access descriptor ADLIB.SALARIES:
proc datasets library=adlib memtype=access;
modify salaries (alter=money);
run;
In this case, users are prompted for the password whenever they try to browse or
update the access descriptor or try to create view descriptors that are based on
ADLIB.SALARIES.
In the next example, the PROC DATASETS statement assigns the passwords MYPW
and MYDEPT with READ and ALTER levels of protection to the view descriptor
VLIB.JOBC204:
proc datasets library=vlib memtype=view;
modify jobc204 (read=mypw alter=mydept);
run;
In this case, users are prompted for the SAS password when they try to read the DBMS
data or try to browse or update the view descriptor VLIB.JOBC204. You need both
levels to protect the data and descriptor from being read. However, a user could still
update the data accessed by VLIB.JOBC204, for example, by using a PROC SQL
UPDATE. Assign a WRITE level of protection to prevent data updates.
Note: When you assign multiple levels of passwords, use a different password for
each level to ensure that you grant only the access privileges that you intend.
To delete a password, put a slash after the password:
proc datasets library=vlib memtype=view;
modify jobc204 (read=mypw/ alter=mydept/);
run;
Protecting Connection Information
In addition to directly controlling access to data, you can protect the data indirectly
by protecting the connection information that SAS/ACCESS uses to reach the DBMS.
Generally, this is achieved by not saving connection information in your code.
One way to protect connection information is by storing user name, password, and
other connection options in a local environment variable. Access to the DBMS is denied
unless the correct user and password information is stored in a local environment
variable. See the documentation for your DBMS to determine whether this alternative
is supported.
Another way to protect connection information is by requiring users to manually
enter it at connection time. When you specify DBPROMPT=YES in a SAS/ACCESS
LIBNAME statement, each user has to provide DBMS connection information in a
