Protecting Sensitive Data from the CAS Superuser
I’ve taught at a few sites now where the administrators work with sensitive data, and a common question that inevitably gets asked is, “My enterprise works with X data, and I don’t want the liability of the SAS Viya administrators looking inside that data. How can I prevent this?” The purpose of this post is to explore just that.
Substitute X for any of the following: Healthcare data that might contain personally-identifying-information, financial systems that might contain highly sensitive data, or government data that might rely on specific clearances to access. That’s fine—SAS Viya has access controls, right? We’ll just use the SAS Viya Cloud Analytics Services Authorization layer and set proper permissions so that our administrators cannot access the data.
Except that there’s an issue--Any SAS Viya administrator can promote themselves to become the CAS Superuser. The CAS Superuser is exempt from any access controls placed on CAS libraries (caslibs) or the tables stored within those caslibs. (Note: I've since updated this article with information about the Select permission at the bottom. Scroll down to learn more. The CAS Superuser does obey the Select permission.)
Now, I’m not implying anything about the trustworthiness or character of administrators. Administrators are crucial individuals responsible for maintaining these platforms. Rather, it’s a fundamental practice in data security to mitigate risks to a company and comply with privacy regulations. By implementing security measures that limit direct access to sensitive data, organizations are proactively safeguarding against internal and external threats. This approach is based on the principle of least privilege, where individuals are granted the minimum level of access necessary to perform their job duties.
Meet Susan. She’s the person cleared to access the sensitive data in our organization.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
We’ll use Host Access Controls to Secure the sensitive data at the source, limiting access to specific users. By default, the CAS Server in SAS Viya launches its sessions as a shared user. We’re going to deny the shared service account access. And grant access only to the users who are allowed to access that sensitive data. In this example, we’ll grant Susan the required access and deny others at the host level.
Then we configure SAS Viya to launch its CAS Sessions as each individual user, using a technique called Host launch. Host launch is configured by including an overlay in the environment’s kustomization.yaml file, and then placing Susan in a special custom group named CASHostAccountRequired. Further details can be found in the readme file located in the directory: $deploy/sas-bases/examples/cas/configure/readme.md
Next, the administrator defines a caslib, or a pointer to the data, for Susan to use. We’ll name it susandata. Even at this step, when the administrator attempts to test their access to the data source, they will get an error. Anyone except for Susan will be denied access. However, we have defined the connection to the data source, so let’s move on and grant Susan access in SAS Viya.
Granting Susan's access and ensuring that Administrators have none. Administrators are already denied access
at the data source, but we can never be too careful.
We define CAS Authorization access controls so that Susan can access the susandata caslib and any tables that exist in the data location. You’ll notice that I denied access for SAS Administrators—this is redundant due to the lack of access at the host level, but still a good practice.
If the administrator tests their access, even using the CAS Superuser role they are denied access.
I have assumed the CAS Superuser role and am still being denied access.
This is exactly what we want!
Susan gets to work. She tests her access and loads the table into memory to perform her analyses. In the SAS Data Explorer, the Available tab shows all tables that are loaded in memory on the server. I assume the CAS Superuser role and can see the table name and column headings that exist on the table that contains sensitive data. Uh oh, is all this post going to be for nothing? Luckily no. The CAS Superuser is prohibited from viewing the contents of that secure CUSTOMERS table.
The CAS Superuser can see the column headings and the title of the table if it is loaded
into memory but is denied access to any of its contents.
SAS Administrators, including the CAS Superuser, do not have access to this sensitive data table. The risk and information security teams can sleep soundly. Thanks for exploring this with me. The walkthrough above only uses a single user example, but you could modify this to secure data for multiple users or groups as well.
(Update)
One additional item of note: even without implementing Host Launch and changing the permissions on-disk to source files, the CAS Superuser is still subject to the Select permission in the CAS Authorization layer, even when they have assumed the superuser role.
CAS Superuser Role
If the administrator’s account is not already granted Select on a table, they would still need to explicitly give themselves this permission before being allowed to read rows from the table. As a superuser, they can of course give themselves a grant of Select on any caslib or table within a caslib, however this action will be logged and can be audited for review later.
Some supplemental reading:
- @StuartRogers' post on SAS Viya 2021.1.3 CAS Security Changes
- @GerryNelson's post on Securing OS Resources in SAS Viya
- SAS Documentation for more information on The CASHostAccountRequired Custom Group
Find more articles from SAS Global Enablement and Learning here.
