Platform Security @ Avisi Cloud

This page describes what we do to secure the platform you trust to host your applications using the following topics:

  • Encryption
  • Back-ups & Disaster Recovery
  • Authentication & Authorization
  • Architecture
  • Supply chain Security

Should you have questions or would like to know more about how we secure our platform? Please reach out to us using the contact form.

Encryption

Avisi Cloud applies encryption of data whenever possible, both at rest and in transit. Avisi Cloud uses industry best practices to secure your data.

Encryption At Rest

  • Persistent Disks are by default encrypted.
  • Sensistive (customer) data in our databases is encrypted.
  • Data stored in remote file-systems such as S3 always make use of encryption by default.
  • Passwords, secrets or other sensitive information stored on our systems or source-control systems (such as Git) are always encrypted.

Encryption In Transit

  • Any data sent over the internet to and from our platform is secured through TLS connections.
  • Traffic sent between Cloud Providers is encrypted.
  • All traffic from and between the Kubernetes Cluster and Control plane we host for our customers are fully encrypted.

Back-ups & Disaster Recovery

Back-up strategies

We maintain strict back-up policies for all our systems, and the systems we run for our customers, such as Kubernetes Control Planes. Multiple back-up strategies are in-place for each data store, including off-site back-ups. All back-ups stored are encrypted and only accessible for disaster recovery purposes by authorized engineers.

We use the following backup strategies for our data:

  • Point in Time back-ups
  • Full & incremental backups
  • Disk snapshots
  • Off-site back-ups

Recovery

For worse case scenarios we have multiple recovery methods that are tested periodically. We have automated checks and monitoring on the health status of our back-ups. We maintain strict recovery targets in order to guarantee our systems are up-and-running quickly should the worse case happen.

Authz & Authn

Authentication

All services, including internal facing services run by Avisi Cloud require authentication. All Avisi Cloud engineers make use of Multi-Factor Authentication (MFA). Engineers use personal accounts for all login accounts. Log-in actions are audited across our platform.

  • we use security keys for MFA
  • all engineers have personal accounts
  • we use a centralized user management system for all our internal systems
  • all internal systems require authentication

Access Management

Avisi Cloud works according to the least privileged principle. Engineers & Staff only have access to systems and data required for their role.

  • in compliance with SOC-2 we regularly audit out access management
  • all engineers with production access have undergone (financial) screening
  • access to sensitive or critical systems happens with two engineers present

Architected for failure

The platform is architected to tolerate failure at multiple failure domains, such as entire datacenter(s), Cloud Provider or region. We have designed our systems to isolate failures as much as possible from impacting our services or customers.

We continously improve our architecture and software systems to improve reliablity. Avisi Cloud uses the Avisi Cloud Platform internally to host the Avisi Cloud platform. This means we benefit largely from our own engineering efforts to automate maintenance actions, upgrades and auto healing functionality for our customers.

This means we;

  • make sure features can fail gracefully,
  • data is stored in multiple availability zones,
  • test failover and restore procedures regularly,
  • develop software taking critical failure scenarios in account.

Supply Chain

At Avisi Cloud we made great efforts to secure our software supply chain. We are active advocates of tooling such as cosign, make sure all software we run come with Software Bill-of-Materials (SBOMS) and continously scan our software & dependencies for vulnerabilities and CVEs.

All our Open-Source and internal projects conform to Supply chain Levels for Software Artifacts (SLSA). This is a security framework and check-list of standards that prevents tempering and secures build artifacts.

Cosign public key

All our container images are signed using cosign from the sigstore project. This is our public key:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEzezKl0vAWSHosQ0JLEsDzNBd2nGm
08KqX+imYqq2avlbH+ehprJFMqKK0/I/bY0q5W9hQC8SLzTRJ9Q5dB9UiQ==
-----END PUBLIC KEY-----

This public key is also published on all our Open-Source Projects and Documentation websites