• Administrator overview
• Managing users and permissions
  • User roles and access permissions
  • Creating users
  • Editing users
  • Unlocking a user account
  • Resending a user activation link
  • Deleting or deactivating users
  • Using groups
  • Managing departments
  • Managing passwords and password policies
  • Setting account-wide access policies
  • Changing a resource owner
  • Using Single Sign-On (SSO)
    • Using Single Sign-on (SSO) with Azure Active Directory (AAD)
    • Configuring an ADFS claim rule for SSO
• Managing account-wide settings
  • Adding container registries
• Managing public IP addresses
• Managing WANs
  • Overview: VPNs
    • Creating a VPN
      • VPN configuration parameters
        • AWS VPC: VPN configuration example
        • Azure VPN: VPN configuration example
        • Cisco ASA: VPN configuration example
        • Cisco IOS: VPN configuration example
        • Juniper SRX: VPN configuration example
        • pfSense: VPN configuration example
        • strongSwan: VPN configuration example
  • Overview: Skytap on Azure ExpressRoute connections
    • Creating a Skytap on Azure ExpressRoute connection
    • Creating a customer-managed Skytap on Azure ExpressRoute connection
  • Testing the WAN
    • Troubleshooting VPN test failures
  • Connecting an environment network to a WAN
  • Configuring WAN access controls
  • Editing an existing WAN connection
  • Disable a WAN
• Managing Metered RAM and storage usage
  • How usage is calculated
  • Viewing current usage and enabling pay-as-you-go capacity
  • Reserved capacity for Skytap on Azure
  • Reserved capacity for Skytap on IBM Cloud
  • Setting usage limits
  • Setting up notifications
  • VM pinning
• Reporting overview
  • Viewing and exporting user information
  • Viewing and exporting group information
  • Generating department reports
  • Generating audit reports
    • Configuring the webhook service for audit data
  • Viewing usage data
    • Using labels for in-depth reporting
    • Creating usage label categories
    • Configuring the webhook service for usage data
  • Enabling other users to generate reports
• Security best practices
• Other best practices
• Sharing templates with users in other Skytap accounts
• Finding the source environment from a sharing portal URL
• Including your logo in the Skytap interface

Security best practices

Skytap has several default security features that control access across your account and virtual machines. In addition to these default security controls, Skytap also has a wide-range of optional security features that can be implemented at the account, user, and environment level. This guide provides some best practices for using these features.

Some of the steps in this article must be performed by an account administrator.

Security overview

By default, Skytap implements the following security controls:

• Each customer’s account is completely segregated from other customer accounts. There are no shared resources, and no other customer can see resources in your account.
• Each user has unique sign-in credentials with an assigned permission level. We have multiple permission levels so that you can set the right level of access for each user within your account. Additionally, access to specific Skytap resources can be set with granular controls via the projects feature. For more information, see Sharing resources with projects.
• All users must verify their accounts using browser activation. Browser activation ensures the user logging in has control over the associated email address.
• Each virtual environment is isolated from other environments. One or more networks can be created within an environment, but the networks are isolated from other Skytap or external networks by default. Network connectivity to external networks, other Skytap environments, or the public Internet must be explicitly enabled.
• Each Skytap environment is owned by a specific user. The environment isn’t shared unless that user grants permission to another user or set of users through projects.
• Actions within Skytap are audited. Account administrators can review an audit trail of these actions, which ensures accountability for all users in your account.

• Skytap follows security best practices and standards for developing and operating the Skytap platform. This includes:

  • Acquiring third-party security certifications. For more information, see https://www.skytap.com/product/#security.
  • Performing routine penetration tests and vulnerability scans.
  • Performing background checks on personnel who have access to service infrastructure.
  • Requiring formal authorization or tickets for accessing service infrastructure.
  • Logging access to service infrastructure, and retaining those logs for at least 90 days.

Best practices for account security

Skytap requires each user to have unique sign-in credentials. Administrators can further restrict account access with the following options and settings:

• Use single sign-on (SSO) with two-factor authentication.

  Skytap supports single sign-on utilizing SAML 2.0. With SSO, users can access Skytap using their corporate directory credentials and applications such as Microsoft Active Directory Federation Services or Ping Identity’s PingFederate. You can further secure your account by implementing a two-factor authentication solution that integrates with your SSO solution. For more information, see Using Single Sign-on (SSO).

• If you aren’t using SSO, set a strict password policy for your Skytap account.

  Using the settings described at Managing passwords and password policies, apply the most restrictive password policy for your users:

  • Set user passwords to expire in 30 days. Choose the option to enforce a password history; this will require users to set unique passwords.
  • Require a minimum password length of 10 characters (default is 8 characters).
  • Require a complex password that includes uppercase, lowercase, numeric, and special characters. See Password policy options.
  • Set a low number of maximum invalid login attempts and a long lockout effective period; this will help protect your account against brute force sign-in attempts.
  • Set a short session expiration time so that your users don’t stay logged in during periods of inactivity (default is 15 minutes).

• Use IP-based access controls.

  You can limit access to your account based on a user’s inbound IP address. This can be useful for restricting access to Skytap from users on your corporate network. You can extend these settings so that they are applied to access via sharing portals, as well. To set IP address restrictions, see Setting access policies. For more information about sharing portals, see Sharing VMs and environments with sharing portals.

• Require API tokens for API access.

  API tokens are long, randomly-generated character strings that are difficult to guess. They can be reset by administrators and changed independently of account passwords. To require API tokens for API authentication, see Setting access policies.

Best practices for user management

In addition to restricting how users access Skytap, you can limit the access that your users have once they are logged in. We recommend that you use the following best practices for managing and monitoring users:

• Grant each user the least amount of privilege necessary for his or her role.

  For example, if a user only needs to run or view an environment, administrators can set his or her user role as restricted user. For an overview of user roles and permission levels, see User roles and access permissions.

• Use the projects feature to further restrict user access to specific environments, templates, or assets.

  Projects allow you to share resources with select users in your account. While this is a great collaborative feature, you can also use projects to limit a user’s permission over environments. For example, if you want users to be able to view, but not run, a set of environments, you can create a new project, assign the user a Viewer role in the project, and then add the set of environments to the project. Users can be assigned to multiple projects where they can have different permissions over different environments. For more information about projects and project roles, see Sharing resources with projects.

• Routinely review your auditing reports.

  This gives administrators visibility over the account. For more information about viewing auditing reports, see Generating audit reports.

Best practices for securely accessing VMs and environments

Skytap offers several methods you can use to access your VMs. The most secure access method is provided by default: Secure Remote Access (SRA) browser client. If security is your highest priority, we recommend that you only use this connection method. It provide access to your VMs over the Skytap infrastructure, without exposing ports or access methods to the public Internet.

If you would like to use other access methods to share your VMs with clients or other users, we recommend the following in order from more secure to less secure:

• Sharing portals – Sharing portals are unique URLs that grant access to a specific Skytap VM or environment. Sharing portals allow you to share VM access with other users, even if they don’t have an account in Skytap. They contain a set of features that you can use to restrict access; we recommend that you use these settings to tightly control when and how your sharing portal can be used.

  For example:

  • Provide access to only the select VMs that the user needs (rather than provide access to the entire environment).
  • Limit the user’s ability to use or control the VM.
  • Require a password of at least 10 characters, or use SSO to restrict access.
  • Set a runtime limit, expiration date, and/or date and time restrictions to limit access and validity duration of the sharing portal.

  For more information, see Sharing VMs and environments with sharing portals.

• Published Services – Published services are generally used to permit Internet access to specific VMs via protocols like RDP and SSH. By creating a published service, you open a single port between on the VM (for example, 3389); this is translated to a higher port opening that is exposed on the public Internet (for example, 31299). Although Skytap obscures the specific port that is open, a published service exposes the VM to the public Internet. If you create a published service, we recommend that you take additional precautions to protect your VM. For more information, see Securing VMs exposed to the public internet.

• Public IP addresses – Public IP addresses provide complete, non-secured access to a VM, making every port on the VM available to the public Internet. While this provides the most access to a VM, it’s also the least secure access method. Because we want you to be able to tightly control public IP addresses, we don’t place these in your account by default. You must enable them with a sales representative. If you use public IP addresses, we recommend that you tightly monitor the public IP addresses and secure the VMs to which they are attached. Here are some suggested security enhancements:

  • Set notifications on the percentage of your public IP addresses in use. For more information, see Setting up usage notification emails.
  • Secure your VMs with strong passwords and anti-virus software. For more information, use the best practices listed at Securing VMs exposed to the public internet.
  • Be aware of the connection between VMs with public IP addresses and other VMs in the environment. You can use multiple networks within the same environment to create segregation, if needed. For more information, see Using multiple networks in an environment.

Best practices for securing VMs and environments

Environments are isolated on their own networks within Skytap. Administrators and users can further secure VMs and environments with the following best practices:

• Enable the built-in setting to disable outbound Internet traffic from your environment. For more information, see Blocking outbound access to the public Internet from VMs in an environment.
• Secure your VMs guest operating systems as if you were using physical computers on your corporate network. For more information, use the best practices recommended in Securing VMs exposed to the public internet.
• If you’re using a VPN to connect to your corporate network, use a single VPN remote subnet set to 0.0.0.0 This will route all outbound traffic from the VM through your VPN, and prevent your VMs from accessing non-secured Internet sites.

• Use Skytap networking features to isolate network traffic and secure VMs. Skytap supports complicated network configurations for multi-tiered applications or when additional network security is desired. For example, you can:

  • Use multiple networks within the same environment to create network VLANs or zones. Skytap doesn’t support native network bridging, so each network zone will require distinct IP address space.

    If you’re using multiple networks to create segregated zones within an environment, make sure the Allow all traffic between networks in this environment checkbox is cleared on the environment’s Network Settings page. If this option is checked, the Skytap gateway will act as a router between each of your networks within the environment and pass traffic directly between connected virtual machines.

  • Place a virtual machine on multiple networks, and then use that VM to pass traffic from one network. This option requires a VM with multiple networks adapters attached to the desired networks. Then this VM can be, or act as, a firewall or router appliance between its networks.

  • Place virtual machines on multiple networks, and then interact with these VMs differently depending on which network and network adapter you’re connecting to. For example, you could connect a utility VM with management NICs to multiple networks within an environment or across environments.

REST API – Automated Security Scripts

The Skytap REST API supports the development of custom scripts you can use to automate security checks or apply security settings across your account. We have several sample security scripts on our GitHub account at https://github.com/skytap/sample-api/tree/master/Utility_Scripts; these scripts show administrators how to disable outbound Internet access on all environments or automatically delete all published services and sharing portals.

If you use the Skytap REST API, we strongly recommend that you configure an API token expiration policy for your account.