Security in RStudio Workbench (previously RStudio Server Pro) relies on standard Linux-based security models, and it gives administrators and security teams full control over their instances. This article explains RStudio 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 RStudio Workbench software itself; if that occurs, please get in touch. We always appreciate feedback on how to make our products better!
Server administrators have full control over how secure to make any particular RStudio Workbench instance. This article identifies settings that can enhance security in RStudio Workbench, but it bears repeating that much of RStudio 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
- A robust authentication scheme
- RStudio 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
Securely connecting to RStudio Workbench (previously RStudio Server Pro)
RStudio Workbench connections are made in a standard web browser via HTTP or HTTPS. We recommend using HTTPS with SSL encryption. RStudio Workbench supports encrypted traffic using SSLv3, TLSv1, TLSv1.1, and TLSv1.2.
RStudio 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 RStudio Workbench is usually managed via RStudio’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
RStudio 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 RStudio 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 RStudio 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 RStudio 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 programming language.
In particular, R developers can submit shell commands using the `system` and `system2` commands. Organizations that are worried about R 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.
RStudio 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
RStudio 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.
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. RStudio 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 RStudio Workbench users, and RStudio Workbench requires internet access only to verify license status. Offline activation is possible for RStudio Workbench instances running in an air-gapped environment.
RStudio 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.
- Security FAQ
- RStudio Workbench Admin Guide: Access and Security
- RStudio Product Security Policy
- RStudio Workbench Requirements
 We generally recommend buying a certificate from a certificate authority if possible. Using a self-signed SSL certificate can often be a hassle.