 |
|
| Managing a SAS/SHARE Server (Server Administrators) |
Server Security
| Controlling Administrator Access to a Server |
By default, any user can send administrator requests to a SAS/SHARE server to stop the server or to display and modify its characteristics, such as who can access the server and what SAS libraries it can serve. To prevent unauthorized users from sending these types of requests, you can assign an administrator password to a server when you start it by using the OAPW= option in the PROC SERVER statement. Here is an example:
proc server id=share1 oapw=blue31;
To specify an administrator password when you use PROC OPERATE to send administrator commands to the server, you must use the SAPW= option. For example:
proc operate id=share1 sapw=blue31;
You can also specify an administrator password in each PROC OPERATE server management command. For details, see Displaying Information about a Server.
| Controlling Access to Data through a Server |
Setting Server Security
A SAS/SHARE server must have valid access permission to read and write data that is requested by any of the server's clients. Usually, this means that a server is authorized to access more libraries and data sets than any one of its clients. For this reason, you might want to set server security to prevent unauthorized access to data through the server by using one or more of the following:
Assigning a User Password to a Server
The simplest method that you can use to limit access to data through a server is to assign a user password to the server when you start the server. This password must be supplied whenever a client connects to the server. This method offers the broadest control over who can access data through the server. It applies to all users regardless of the data that they access or the operations that they perform.
To assign a user password to a server, use the UAPW= option in the PROC SERVER statement. Here is an example:
proc server id=share1 uapw=hotwings; run;
When a user specifies the server for the first time in a LIBNAME statement or in a PROC SQL CONNECT TO statement, use the SAPW= option to specify the user password. Here is an example:
libname invoice server=share1 sapw=hotwings;
Limiting the Libraries a Server Can Access
To prevent unauthorized access to libraries or data sets that should not be accessed through a specific server, use the operating environment or file system security software to deny access by the server to those libraries or files.
You can also use the NOALLOC option in the PROC SERVER statement to limit users to accessing only those libraries that you predefine. For more information, see Predefining SAS Libraries to the Server and Limiting Users to Predefined Libraries.
Operating Environment or File System Protections
When a user reads or writes SAS libraries and SAS files, most operating environments and file systems validate the user's authority to read from or write to that data.
Because a server is interposed between a user and the data, checking access permissions, which is usually performed by the operating environment or the file system security software, must be performed in the server's session to protect access to that data through the server. For this reason, a SAS/SHARE server calls the operating environment or the file system to validate a user's authority whenever an attempt is made to read from or write to a library through the server.
Providing a validated user ID and password as arguments in the LIBNAME statement, the ALLOCATE LIBRARY command in the PROC OPERATE statement, or the Remote SQL Pass-Through statement preempts earlier SAS methods of supplying a user ID and password by using a communications access method. Regardless of the method used for collecting a user ID and password, the server uses the validated user ID in making the authority check. To permit access by user IDs that are not validated, you can use the AUTHENTICATE=OPTIONAL option in the PROC SERVER statement. For more information about setting options in the PROC SERVER statement, see The SERVER Procedure. For more information about user IDs and passwords, see LIBNAME Statement, Syntax: RSPT SQL Procedure, or The OPERATE Procedure.
In order to validate a user ID, most access methods require using an access method-specific mechanism to provide the user ID and corresponding password for the server operating environment. The access method encrypts the user ID and password and transmits them to the server session to be validated. For information about the mechanisms that control whether an access method validates connecting users and the mechanisms by which users can provide their user IDs and passwords, see Communications Access Methods for SAS/CONNECT and SAS/SHARE.
On most operating environments, to validate a user ID and to verify access permissions, a SAS/SHARE server calls the operating environment or the file system directly. Under UNIX, the server performs these functions by calling an external program (that is, not a SAS application) that you can modify.
Ensuring That User IDs Are Valid
Because a SAS/SHARE server calls the operating environment or the file system to verify a user's access permission to data, the accuracy of the user ID that the server presents to the operating environment or to the file system determines whether a user is allowed to access data.
When all communications access methods are configured (see Communications Access Methods for SAS/CONNECT and SAS/SHARE), on most operating environments each user ID is validated by the communications access methods when a user connects to the server. That validation is used for the duration of the connection. The server presents that user ID to the operating environment or to the file system whenever the user attempts to access data through the server.
Specifying the option AUTHENTICATE=OPTIONAL in a PROC SERVER statement bypasses the requirement that the access methods validate a connecting user ID. Use the option AUTHENTICATE=OPTIONAL to get a server running quickly with an absolute minimum of work. Also, this use shows the value of configuring production servers to run without the option AUTHENTICATE=OPTIONAL, which means that production servers can run unattended while only allowing users to access data that they have permission to access.
If you are running a SAS/SHARE server in an operating environment that does not have a security facility that controls user access to files, or if you are running a SAS/SHARE server in an operating environment in which every user should have full access to every file that is available to the server, you might want to use the option AUTHENTICATE=OPTIONAL instead of implementing security for each of the access methods that is used by the server. For example, if a SAS/SHARE server is running under UNIX without a security facility installed, it is not possible for communications access methods to validate connecting user IDs, nor is it possible for the server to verify access to files for each individual user ID.
| Using Encryption Services |
As an alternate form of security, you can implement encryption services that protect data that is sent between operating environments across a network. For details, see Data Security Technologies in SAS.
|
|
Copyright © 2007 by SAS Institute Inc., Cary, NC, USA. All rights reserved.