Version 1.0 – 15 May 2019
This policy outlines:
Without limiting any provision of the Envizage Terms of Service, we will implement reasonable and appropriate measures designed to help you secure Your Content against accidental or unlawful loss, access or disclosure.
Our documentation may specify restrictions on how the API may be configured, or specifications for your instance. You agree to comply with any such restrictions or specifications.
You are responsible for properly configuring and using the Instance and taking your own steps to maintain appropriate security, which may include the use of strong passwords and secure storage of your client ID and client secret according to Oauth2 best practices.
Envizage access credentials generated by the API are for your internal use only. You may not sell, transfer or sublicense them to any other entity or person, except that you may disclose your client ID and secret to your agents and subcontractors performing work on your behalf.
You will not use the API to create, receive, maintain, or transmit GDPR Personal Data without the corresponding agreement legal agreement (GDPR data protection agreement) in place between you and Envizage.
You may conduct penetration tests of the API. To do so, please contact us with the following information:
If you discover a potential security vulnerability, please see our policy on Responsible Disclosure. We strongly prefer that you notify us in private. Publicly disclosing a security vulnerability without informing us first puts the community at risk. When you notify us of a potential problem, we will work with you to make sure we understand the scope and cause of the issue. Thank you!
Envizage runs on the Amazon Web Services global infrastructure platform.
AWS publishes an “Overview of Security Processes” whitepaper that serves as the reference material for this section. SOC 2 reports are available directly from AWS upon request.
AWS computing environments are continuously audited, with certifications from accreditation bodies across geographies and verticals, including ISO 27001, FedRAMP, DoD CSM, and PCI DSS. Additionally AWS also has assurance programs that provide templates and control mappings to help customers establish the compliance of their environments running on AWS against 20+ standards, including the HIPAA, CESG (UK), and Singapore Multi-tier Cloud Security (MTCS) standards.
AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff.
AWS data center environmental controls include:
The Envizage platform is comprised of three separate AWS Virtual Private Clouds which are connected between them using VPC Peering. A VPC Peering connection is a networking connection between two VPCs that enables you to route traffic between them privately, inside the AWS infrastructure.
The three VPCs correspond to (a) a Kubernetes cluster running Ingress endpoints and performing orchestration of various microservices, (b) a MongoDB database cluster and (c) a RabbitMQ message oriented middleware cluster. Additionally, traffic between the microservices and the MongoDB database cluster and traffic between the microservices and the RabbitMQ message oriented middleware is performed only using SSL/TLS.
Exposure to the Internet is done only through SSL/TLS endpoints and a bastion host. Backend users connect to the system through the bastion host, which logs activity for review. User based encrypted traffic is first routed through the AWS Elastic Load Balancers, then through our Internal Ingress Controllers and finally reaches the microservices.
No public-facing EC2 instances except the bastion servers and those running our ingress controllers. The bastion host allows SSH traffic restricted to the Envizage Virtual Private Network (VPN).
Envizage runs a series of services following security best practices for intrusion detection and prevention.
Amazon Cloudwatch monitors the hardened bastion hosts and will detect potential intrusions and other anomalous activities.
The Envizage Security Team monitors and investigates each event to determine the legitimacy of all activity. Crucially, the Envizage Security Team immediately responds to and resolves any issues that are discovered through investigation of anomalous activity and will notify you of any remediation steps taken.
Envizage’s VPC-based approach means that most components are not accessible from the Internet, and cannot be targeted directly by a DDoS attack.
Envizage SSL/TLS endpoints include an AWS Elastic Load Balancer, which only supports valid TCP requests, meaning DDoS attacks such as UDP and SYN floods will not reach the API layer. Additionally, the Ingress controllers use the rate limiting capability of Nginx. We have in place both a limit for concurrent open connections per IP and a maximum number of requests per second for new connections.
AWS monitors and stops unauthorized port scanning. Because most of an Envizage stack is private, and all hosts run strict firewalls, port scanning is generally ineffective.
The AWS network prohibits a host from sending traffic with a source IP or MAC address other than its own. The AWS hypervisor will also not deliver any traffic to a host the traffic is not addressed to, meaning even an instance running in promiscuous mode will not receive or be able to “sniff” traffic intended for other hosts.
Envizage partner Comsec is contracted for periodically scanning the perimeter network for vulnerabilities.
Technical Architecture diagram
Our service catalog is served over SSL/TLS connections using SHA-2 certificate. SSL offloading happen on the kubernetes ingress controllers and requests are proxied back to the microservices over HTTP.
Envizage uses stateless session management leveraging JWT (JSON web tokens) signed with RSA 2048 bits key.
Envizage installations are multi-tenant supporting multiple tenants on a single instance, each having its own users, configuration, analytics and service accounts.
The only supported authorisation mechanism is the OAuth 2.0. Each tenant will use the OAuth2 authorisation flows to access the API.
All activity by accounts with elevated privileges (admins, client admins and client accounts) are automatically recorded in an audit trails database collection.
The activity is anonymised before it’s recorded by stripping out any personal identifiable data from the request.
Login attempts are being monitored and logged. Consecutive failed attempts will result in automatic blacklisting of the user’s IP for a period of time and notification will reach an email address that is monitored by the management team.
The Envizage platform implements the OAuth 2.0 specification, which defines a delegation protocol that is useful for conveying authorization decisions across a network of web-enabled applications and APIs. OAuth is used in a wide variety of applications, including providing mechanisms for user authentication and resource authorisation.
The Envizage platform defines a comprehensive list of admin and user authorities for fine grained access control.
All tenants (clients) of our system use the same database instance. There is a rigorously tested logical layer which keeps the tenants isolated from each other. There is no hard segregation in the environment between clients. The segregation is ensured by a set of filters that act as a switch to authorise access to resources based on a client.
3.G – Inter-process communication
Inter-process communication may happen with 2 mechanisms
Envizage are running the service in a highly available kubernetes cluster. We run multiple instances (containers in kubernetes Pods) of each microservice for load balancing and high availability. Computational nodes that run our instances span across multiple availability zones.
4.B – Zero-downtime deployments
Readiness probes are configured on all microservices for zero-downtime deployments. Requests are only routed to newly spawned containers after readiness probe validates that the microservice is fully bootstrapped and ready to service requests.
4.C – Self-healing
Liveness probes are configured for all microservices. Malfunctioning pods are timely and automatically identified and restarted by the kubernetes replication controllers constantly getting the server to a stable state.
4.D – Rolling upgrades, Canary releases & Blue-Green deployments
Envizage employs rolling upgrades, canary releases and blue-green deployments when appropriate to ensure uninterrupted service even while doing multiple production releases each day.
Fully automated CI/CD pipelines ensure that each release will be promoted sequentially between testing, staging, pre-production and production servers running automated functional tests and manual tests on one or more stages of the pipeline before the final promotion to the production server is made.
MongoDB Atlas continuous backups take incremental backups of data in our cluster, ensuring your backups are typically just a few seconds behind the operational system. Atlas continuous backups allows for restore from stored snapshots or from a selected point in time within the last 24 hours.
AWS data centers are clustered into regions, and sub-clustered into availability zones, each of which is designed as an independent failure zone, meaning they are:
Microservice containers are scheduled by the kubernetes scheduler across multiple availability zones.
Envizage monitors the stability and availability of the infrastructure and will respond timely in the event of a disaster. Envizage will restore latest database backup that should be a few seconds behind the operational system. Precise cluster structure and docker image versions of each microservice is persisted in a git repository and can be recreated.