Security in Posit Workbench relies on standard Linux-based security models, and it gives administrators and security teams full control over their instances. This article explains Posit Workbench's security features, and also points out some steps that particularly security-conscious organizations may want to adopt.
In rare cases, organizations doing penetration or other sorts of testing find vulnerabilities in the Posit Workbench software itself; if that occurs, please get in touch. We always appreciate feedback on how to make our products better!
Recommendations
Server administrators have full control over how secure to make any particular Posit Workbench instance. This article identifies settings that can enhance security in Posit Workbench, but it bears repeating that much of Workbench’s security is the result of implementing Linux-based security models.
To secure external access and ensure appropriate user control, we recommend that all organizations use
- HTTPS with a valid SSL certificate from a trusted certificate authority[1]
- A robust authentication scheme
- Posit Professional Drivers using secured credentials for database connections
- A firewall configured to expose only necessary ports
- Linux file permissions that permit activity only within a user’s designated home directory
Some organizations may also wish to
- Only allow certain IP addresses
To simplify R package management, especially in a validated or air-gapped environment, we recommend
Organizations attempting to stop potential insider threats may wish to
- Disable ACLs and project sharing
- Disable other IDE features to obscure shell execution abilities
- Enable console auditing to detect unauthorized system access
Details
Securely connecting to Posit Workbench (previously RStudio Server Pro)
Workbench connections are made in a standard web browser via HTTP or HTTPS. We recommend using HTTPS with SSL encryption.[1] Workbench supports encrypted traffic using SSLv3, TLSv1, TLSv1.1, and TLSv1.2.
Workbench uses cookies encrypted via SHA256 to save session information (username, domain, and timestamp). They are dropped at authentication and when accessing the admin dashboard, and are required for load balancing configurations.
Workbench supports LDAP, Active Directory, Google Account, and local account authentication schemes, and has full support for Pluggable Authentication Modules (PAM) and for Kerberos via PAM. It can also be configured for custom authentication via a proxied HTTP header.
Securing database access
Database access from Workbench is usually managed via Posit's Professional Drivers (Database Connectors), which are professional products built with security in mind. They are configurable via the Unix ODBC driver manager, and the best practice is to securely store credentials elsewhere on the system so there’s no risk of raw credentials accidentally appearing in R code.
Disabling project sharing
Workbench’s project sharing feature allows developers to edit the same code in real-time. It is enabled by default, and R developers often find it to be one of Workbench’s most useful features. It requires the use of Linux Access Control Lists (ACLs) on shared Network File Storage (NFS), and can be disabled as an option within the IDE. ACLs can be disabled at the system level by a Linux administrator.
Restricting IP addresses
Some organizations want to allow access from only particular physical locations, which can be accomplished by permitting access to Workbench only from specified IP addresses.
Disabling other IDE features
We often hear from organizations who work with particularly sensitive data and are concerned with mitigating the potential for bad actors to do harm if they were to gain access to Workbench.
These organizations are frequently concerned about IDE features, including the version control and terminal windows, and the ability to do package installation, file uploads and downloads, and publishing within the IDE. These IDE features can be disabled via configuration files, but the IDE features are just graphical interfaces to capabilities always present in the R and Python programming languages.
In particular, developers can submit shell commands using the system and system2 commands in R and using the os module in Python. Organizations that are worried about developers running unauthorized or malicious shell commands should both disable IDE features and activate console auditing so that all commands run on RStudio Workbench are written to a central location where they can be reviewed for unauthorized activity.
Other considerations
Securing sessions
Workbench runs most processes as a non-root user (default: rstudio-server), but requires root privileges at installation and at runtime in order to start user sessions on behalf of users. Once started, root privileges are dropped and user sessions always run as the user who initiated the session.
Local accounts and permissions
Workbench requires that every user have a local account, which can be created manually or via PAM. Therefore, controlling user permissions to data and other systems is accomplished through the system’s Linux-based security rules.
Package validation
Some organizations require central validation of R packages, or run in an air-gapped environment. Validating R packages depends on individual organizations and their specific requirements. Posit Package Manager is a great way to administer the process of validating, hosting, and serving packages to R developers.
Data collection and license activation
We do not collect data on Workbench users, and Workbench requires internet access only to verify license status. Offline activation is possible for Workbench instances running in an air-gapped environment via the use of a license file.
Security Checks
Workbench passes internal checks, but it does not use 3rd-party software certification at this time.
Many organizations have a formal security review for on-boarding new software. If you have specific requirements please contact us. We will be happy to make sure you have the information you need so that you can comply with your security requirements. Please review the references below first, since they may contain the answers you are seeking.
References
[1] We generally recommend buying a certificate from a certificate authority if possible. Using a self-signed SSL certificate can often be a hassle.
Comments
0 comments
Article is closed for comments.