Company shall implement, maintain, and comply with its Security and Privacy Documentation.
At Amsterdam Software 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 FBO One software-as-a-service is referred to as “the service” below.
Provider
The primary service runs on Amazon AWS and the secondary disaster recovery services runs on Microsoft Azure. The AWS services are in Ireland, EU and the Microsoft Azure services are in USA East Region. AWS and Azure are certified under several global compliance programmes and more information may be found at aws.amazon.com and azure.microsoft.com
High Availability
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.
Disaster Recovery
Data and system configuration is continuously replicated to the Azure Disaster Recovery Environment. In the event of an outage in the AWS primary region, the replicated environment will be brought online to restore the service.
Monitoring and Auditing
The service is continuously monitored for performance and security events. A log of all successful and failed login attempts to production infrastructure is maintained. Periodically, Amsterdam Software hires outside security firms to conduct reviews of our security posture and conduct penetration tests against our production systems.
Encryption
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.
Authentication
The service is a multi-tenant offering where each company shares the Amsterdam Software’s infrastructure resources such as CPU, memory, or disk space of the underlying servers. Each tenant is accessing a distinct service instance isolated from other tenants. Each tenant’s data is isolated between tenants in distinct database instances.
Each tenant accesses the service via a dedicated URL address (optionally IP whitelisted) SSL always encrypted.
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 unique tokens which must be presented on all API requests. These accounts follow the same authorization principles as the individual person accounts.
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 “Front office” or “Backoffice”, grants access to a particular aspect of the service. Permission changes take effect immediately.
Backup and Retention
Databases used by the service are backed up on a near-continuous basis. Data backups are stored encrypted at rest. The backups are divided in two categories such as long-term backups – done monthly and may be retained for as long as five years and near real-time backups – done every 15 minutes and rotating every three days. The backups are continuously monitored for restoration health. Documents and files uploaded to the service are also kept in multiple geographically redundant regions.
Confidentiality and Integrity
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.
Isolation
The service is a multi-tenant application sharing CPU, memory, and disk space resources. The tenant data records, such as a handling orders, invoices, or master data such as aircraft, products, contacts, price agreements etc, are owned by the tenant and isolated from other tenants by distinct databases. When a user authenticates, their session is connected only to the specific tenant database. All requests to the service via the dedicated application URL are connecting to that tenant’s database.
Export
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.