At Avinode Group we take the security and availability of your data seriously. We consistently review and enhance our processes and systems to ensure that we remain secure. Our various software-as-a-service offerings are collectively referred to as “the service” below.
The service runs on Microsoft Azure in East US as the primary region and West US as the secondary region. Microsoft Azure is certified under a number of global compliance programmes. More information may be found at Microsoft.com.
Avinode strives for redundancy and high availability within our primary region.
Avinode has a documented disaster recovery strategy based on primary and secondary regions within Azure.
All connections and data transfer to or from the service are secured via TLS encryption. Within the service, connections between the application servers and databases are secured via TLS encryption. All databases and data stores used by the service are encrypted at rest.
Periodically, Avinode Group hires outside security firms to conduct reviews of our security posture and conduct penetration tests against our production systems.
The service is a multi-tenant offering where each company is it’s own tenant.
Each tenant using the service will designate one or more company administrator accounts. A company administrator account may be used to create or remove other user accounts in that tenant.
Each user account is secured by mandatory password authentication. Tenants may optionally enable two-factor authentication for increased security. Tenants may optionally enable federated authentication to authenticate against their corporate account directory.
Each user creates his or her own password, which is stored as a salted cryptographic hash. Each user must provide a unique security email address. A user’s password can be reset after verification that the user has control of the security email account.
Tenants may optionally create a special form of user accounts not tied to an individual person. These are API accounts and commonly referred to as “service principals” in applications. These service principals are designed to access the APIs of the service. Each API account is secured by two unique tokens which must be presented on all API requests.
The service uses a fine grained permission model. User accounts must be granted appropriate permissions to view or edit data records.
Company administrators may grant or revoke permissions from individual accounts in their tenant. Each permission, such as “Invoicing” or “Flight Logs”, grants access to a particular aspect of the service. Permission changes take effect immediately.
Databases used by the service are backed up and/or replicated to multiple redundant regions as appropriate to preserve data for restore. Documents and files uploaded to the service are also backed up and/or replicated to multiple redundant regions to preserve data for restore.
The service uses a fine grained permission model. User accounts must be granted appropriate permissions to view or edit data records.
Changes to some tenant data within the service are recorded in an audit log containing the user account that made the change, the date and time at which the change was made and the content of the change.
The service is a multi-tenant application. Tenant data records that are private to the tenant, such as a scheduled flight or a customer, are assigned to the tenant that owns them. When a user authenticates, their session is placed into the specific tenant associated with their account. All requests to the service validate that the current session’s tenant matches the tenant that owns the private records, failing if they do not.