Here is an overview of the security measures that are in place on SURF Research Cloud.

Inside the workspace

General security


The operation system images that are used to create new workspaces are updated weekly.

We use the latest stable release of the respective provider.

Network ports

By default, the minimum of required ports is open for a workspace.

The ports are managed on the level of the cloud that your workspace is running on, not configurable in the workspace itself. 

If the catalog item that a workspace is based on allows it, you can add and modify open port settings ("security group rules").

(See more OS-specific information below under "Linux" and "Windows") 


SURF Research Cloud workspaces are continuously scanned for tell-tale signs of vulnerable configurations. The SURFcert service takes care of this task.

For example, ports that should not be "open to the world" will be detected and brought to the user's attention.


Logging in

On each Linux workspace, the members of the collaboration can log in with SSH.

Linux workspaces that expose a web-interface, like Jupyter Notebooks or RStudio can also be logged in to with a Time Based Password. Also the Linux Desktop applications use this style of logging in.


SSH-login on Research Cloud is always passwordless. The authentication is done through private/public keypairs that can be generated on the user's local computer with


(Linux terminal or Windows powershell)

Read more about workspace login here

Time Based Password (TOTP)

You can set up Time Based Password generation using the Research Cloud portal and your smartphone: read more
This sets up the interplay between your institution, SURFconext, SRAM and Research Cloud.

Rate Limiting

Linux workspaces are protected with Fail2Ban. This service runs locally on the workspace and can detect and mitigate a range of suspicious activities - like e.g. brute-force attacks.


By default any member of the collaboration can use the sudo command. But you can also choose applications where only the workspace owner can do this. Or you can assign members to specific collaboration groups. This installs a particular set of rights or restrictions for them.

See "working together".


Linux workspaces by default have these ports opened:

  • SSH (22)
  • HTTP/HTTPS (80/443)
  • xRDP (3389) (only for Linux desktop)

We can set custom configurations on the cloud-level, if requested.
If you have chosen an application that is fully open on the cloud-level, you can manage your ports with the local ufw ("uncomplicated firewall") command. With ufw, initially only the SSH-port (22) will be open.


While a workspace is created, the Research Cloud deployer service needs temporary access to the workspace. This happens through port 5986 which is only open to the deployer service's ip-range. When the workspace creation is finished, the port is closed.

So no "backdoor" into the workspace is left.

Still, users may decide to use disk encryption.


Logging in

Users log in to Windows workspaces with Remote Desktop Protocol (RDP), using a Time Based Password.

You can set up Time Based Password generation using the Research Cloud portal and your smartphone (read more).

This sets up the interplay between your institution, SURFconext, SRAM and Research Cloud.

RDP access can be restricted by the "co_rdp_secure" parameter.
(see catalog items)


The standard administrator account is disabled on Windows workspaces. Access to admin rights can be granted through the user's membership in a special group of the collaboration.


  • RDP (3389)
  • winRM (5986) (to Research Cloud deployer ip-address only)

Configuration account remains on workspace

The configuration account only has access to the winrm management port of the machine, and cannot be used to login through RDP.

Options on the collaboration level

Within a Research Cloud collaboration, some rights can be granted or withdrawn by placing collaboration members in specific groups.

SURF Research Cloud portal

The access to the Research Cloud portal uses SURFconext/SRAM for authentication. The authentication is token based and depends on how the user is identifying themselves to SURFconext. This may be through their institute or through eduID, for instance.

Cloud level

Research Cloud provides resources from different clouds. The access to all their interfaces is constrained by ip-range and has token-based authorization.

The services of the portal itself run on AWS. Access is among other measures restricted by ip-range.

  • No labels