Security is a top priority at Hyperspace and is taken seriously. This document describes the current state of security of Hyperspace. This information can change rapidly, as we are constantly improving our security and as we continue to build our product. Hyperspace follows industry standards and guidelines for security compliance and successfully undergoes security approvals with Fortune 500 and Global 1000 organizations on a monthly basis, Hyperspace sees value in streamlining approvals with SOC2 Type II and ISO 27001 certification and will pursue these in due course.
Use Of Cloud Infrastructure
Hyperspace is a data processor. All data loaded into Hyperspace is owned by the customer. Hyperspace indexes and stores all the data to allow database queries, but the data is always owned by the customer.
Hyperspace uses cloud native best practices and leverages the underlying security policies of the public cloud it is hosted on. Architecturally, Hyperspace is designed to be cloud agnostic and may be run on Google Cloud, Azure, AWS or other public clouds in the future. However, currently, all of Hyperspace's services are run and hosted in Google Cloud Platform (GCP), hence our security policies follow GCP best practices at this time. Any time this document mentions Hyperspace servers, it means instances in GCP. Hyperspace does not operate any physical hosting facilities or physical computer hardware of its own. You can view the GCP security processes document here: https://cloud.google.com/security
Security Features
Role Based Access Control
Role-based access control (RBAC) helps you manage user privileges in your organization by enforcing least privileged access to all resources within Hyperspace. Specify roles and privileges to ensure that you limit access to your data to the individuals that need it.
Hyperspace grants access to data and actions through role-based authorization and provides built-in roles that provide the different levels of access commonly needed in a metaverse. A role grants privileges to perform sets of actions in a defined metaverse world. A role can grant access down to a space level of granularity https://hyperspace.mv/academy/user-roles/ .
Security Architecture
Data In Flight
Data in flight from customers to Hyperspace and from Hyperspace back to customers is encrypted via TLS. Hyperspace currently uses the TLSv1.2_2021 security policy for our HTTPS load balancers.
Cloudflare distributions terminate TLS connections to our website and Dashboard.
Within Hyperspace's Virtual Private Cloud (VPC), data is transmitted unencrypted between Hyperspace's internal services. Unencrypted data will never be sent outside of Hyperspace's VPC.
The only entry-points to the VPC are through the Hyperspace API and VPN for Hyperspace operations staff. Access to these is described in the following sections.
Data At Rest
Data is persisted in two places within Hyperspace:
On our servers, which mount GCP SSD persistent volumes, are encrypted using AES256.
To learn more, visit:
- https://cloud.google.com/docs/security/encryption/default-encryption
In S3 storage buckets, that are used for user scenes and media assets. This data is encrypted both in transit and at rest, using AES-256 block cypher.
To learn more, visit:
- https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html
In all cases, the encryption keys are managed by GCP & AWS Key Management Service (KMS). The master keys are never exposed to anyone (not even Hyperspace), as they never leave the KMS hardware. For some specific commercial installations, Hyperspace will provide a way for customers to provide their own master key. All customer API keys and integration credentials are stored in a secure admin database that is encrypted at rest.
Access Controls
The only ways to access any stored data, servers, or services running inside Hyperspace's VPC are through VPN servers for the Hyperspace operations staff and the Hyperspace API endpoints.
Access to the VPN server requires a TLS auth key, a CA certificate, and the user's individual credentials. Access to the VPN server also requires a hardware token for two-factor authentication. There are no shared passwords for accessing the VPN server. Only employees that require development and administrative access will receive credentials to access the VPN server. Access to resources in the VPN is controlled on a per user basis. For example only required individuals have the ability to send SSH traffic. VPN access for each individual employee can be quickly revoked if necessary.
Access to Hyperspace servers are controlled by a configuration management system that distributes public SSH keys to certain employees with allowed access to certain servers, configures the UNIX group that each employee belongs to, and configures sudoers files to grant access to run commands to each employee. SSH private keys only live on the employee's laptop. SSH keys can be quickly removed and rotated on all servers in the event that the laptop is lost or the key is compromised. Only SSH key pairs are used for SSH access, not passwords. SSHing as root is also disabled. All laptops have anti-virus software with automated updates of virus and malware signature definitions, and have Mobile Device Management (MDM) enabled which enforces alphanumeric password of at least 12 characters, auto screen lock after 10 minutes, network firewall enabled, disk encryption enabled, the ability to remotely lock or wipe the computer, and periodic scans to ensure the above are in compliance.
Within the VPC, Hyperspace defines specific network security groups for instances depending on the services running on the network. By default, none of them are publicly reachable via the Internet. Only the VPN servers are reachable directly via the Internet, and security groups are locked down so that only the ports necessary to access the given service are allowed, and only from sources that require this access. Network access per security group is given only on an as needed basis (allowlist only the needed ports/protocols/sources as opposed to blocklist). There are Internet-facing load balancers that service the API and Dashboard endpoints. These load balancers only accept inbound traffic over the HTTPS protocol and port 443, and automatically redirect HTTP traffic to HTTPS. There are also Cloudflare endpoints that service traffic to our website and Dashboard, and terminate TLS connections for those services. These endpoints also redirect HTTP traffic to HTTPS.
Access to Hyperspace's Dashboard is based on having valid user credentials that have been granted access to the Dashboard. Hyperspace relies on OAuth 2.0 for user authorization both for internal accounts and customers' own IdP. It is possible to configure per customer authentication using Google Authentication, Okta Single Sign On, or any identity service that can federate via SAML.
Access to Hyperspace's API is based on API keys, which can only be created in the Dashboard or the Hyperspace API. Each API key can only access the resources granted to the user that created the key. All customer API keys and integration credentials are stored in a secure admin database that is encrypted at rest.
Access to GCP and AWS resources is provisioned through GCP and AWS Identity and Access Management (IAM) users and roles. Our instances are granted some access required for processes running on them to function (such as access to a specific set of S3 buckets) through instance roles. Developers and administrators who require access are each granted access using service accounts which require a token for two-factor authentication, and use separate authorizations for the production accounts.
Access to our cluster manager API is done through a role based access control mechanism tied to the GCP or AWS SSO user.
Confidentiality
Confidentiality is maintained by only allowing those users, non user accounts, and employees access to systems, services, and data when they need it. Secrets that are needed by Hyperspace’s services during runtime are stored in GCP as Kubernetes Secrets, with access to those secrets provisioned via Kubernetes roles. Secrets needed by employees to access various third party services are stored in 1Password. Hyperspace usernames and passwords are stored in an encrypted database which uses AES256 for data at-rest.
Audit Logging
Hyperspace uses GCP Cloud Logging to log all actions taken on our cloud infrastructure. For each GCP cluster Hyperspace uses (including production), all logs are shipped to a GCP Cloud Storage bucket in a completely separate security account. This bucket only grants write (not read) access.
Defense In Depth
Hyperspace uses a “defense in depth” strategy to protect its assets. Two-factor authentication is required for access, and for operations which require elevated privileges. The networks are segregated so development and production systems are isolated. We employ the principle of least privilege so the employee accounts do not have permission to perform privileged operations, and to gain elevated privileges users are required to use two-factor authentication.
We use an Intrusion Detection System to monitor all development and production environments, and immediately alert the security team of anomalies.