Multi-Tenant Security

One of the obvious goals of a multi-tenant cloud is providing adequate segregation between the tenants. Our cloud platform provides this isolation by allowing all users of the cloud the ability to create their own dedicated cloud VLANs. These VLANs are terminated completely inside of the cloud. This allows customer of the cloud to create multiple service on a layer 2 network fabric much like they would in the physical world. Each customer can create as many or as few of these VLANs to meet their business objective. No VLANs created by one customer can be viewed or accessed by another tenant. We achieve this by taking strict control over the layer 2 network fabric.

Secure console access to cloud is controlled by a secure key exchange that occurs between a logged in client of the cloud platform portal and the console server itself. These keys are generated when the session is initiated, so the key no longer valid after a session has been closed.

Data security is extremely important in multitenant cloud. We control access to all cloud images and data on the customer`s behalf. There is no way that a customer can access another costumer`s data. As with any cloud computing or IaaS platform, data security is in the eye of the beholder. Best practice would dictate that the customer encrypts all highly confidential data at the application level.

Edge Security

Edge security should be analyzed on a per case basis. Depending on the customer base and the services offered, the approach to securing the edge of the cloud may vary greatly. Our cloud platform comes equipped with a fully featured firewall that stands at the edge of all cloud services.

Securing the edge of the cloud for public cloud is very difficult because the service provider typically knows very little about the services that the customer will be offering with the cloud. This makes port based policy control almost impossible. For these types of installations it is recommended that the customer deploy a virtual security device in their own virtual datacenter. Because each customer has the ability to create multi-tier networks, it is easy to create DMZ segment that is secured by a virtual firewall. This can be controlled by the service provider or can be deployed self-service by the customer.

Optionally, the service provider can be provided no public access to the internet. In this case, customer would make connectivity requests directly to the service provider and the service provider will manually configure the proper policies in our firewall. Finally, at the service provider`s discretion, our firewall can pass traffic through to a security device managed outside of the cloud. Some customer implementations terminate our cloud on a private IP network. The private IP Addresses are manually mapped to true public addresses on the datacenter router using Network Address Translation.

Compliance

Achieving audit compliance is a matter of implementation and best practices. When talking about compliance, application level security is the most important consideration. Our cloud platform has been deployed in a multitude of configurations to meet many compliance objectives. At this time, we do not encrypt network traffic for back-end communication. If encryption is required to meet compliance, it is recommended that customer implement an encryption scheme on their cloud infrastructure. This ensures that encryption keys reside with the customer themselves.

Back-End Security

From an administrator perspective, access to our cloud platform hardware must be strictly controlled. Our platform is designed to automate most tasks and to be managed by a minimum of administrators. If customers of the cloud neglect their duty to secure their own data, it is possible that unauthorized access could occur on the back-end. Best practice dictates that all our cloud servers be physically secured and that administrator passwords only be given to individuals that absolutely require access to the system.