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.
All aspects of the service are multiply redundant. In the event of an individual system failure within the primary region system activity will be transparently distributed to the redundant systems.
Data and system configuration is continuously replicated to a secondary region. In the event of an outage in the primary region, the replicated copies will be brought online to restore the service.
Avinode Group continuously monitors the service for performance and security events. A log of all successful and failed login attempts to production infrastructure is maintained.
Periodically, Avinode Group hires outside security firms to conduct reviews of our security posture and conduct penetration tests against our production systems.
All connections and data transfer to or from the service are secured via TLS 1.2 encryption. Within the service, connections between the application servers and databases are secured via TLS 1.2 encryption. All databases and data stores used by the service are encrypted at rest.
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 on a near-continuous basis. Data backups are stored in multiple geographically-redundant regions. Data backups may be retained for as long as one year. Documents and files uploaded to the service are also kept in multiple geographically-redundant regions.
The service uses a fine grained permission model. User accounts must be granted appropriate permissions to view or edit data records.
Changes to 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, such as a flight or a contact, 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 requested records, failing if they do not.
The service provides optional integrations with other electronic systems commonly used by business aviation businesses. Tenant data will only be exported through such integrations when the integration has been enabled by a user whose account has been granted appropriate permissions to do so.