Technical overview
The Datafisher
The overview is intended for technical, security, procurement, and implementation discussions. Confirm current hosting and provider details with Datafisher when the information is needed for a formal review.
In this section
- Main applications – understand the portal, administration panel, and API.
- Hosting and operations – review server hosting, automation, encryption, and logging.
- Security model – understand access control and tenant isolation.
- Backups and resilience – review backup layers and restore protection.
- Development and releases – understand deployment, staging, and version support.
- External services – review the service providers listed in the source overview.
Main applications
The LMS consists of three main applications:
- Learn portal – lets learners complete online and offline training, view training progress, download certificates, enroll in events, and use the training catalog.
- Administration panel – lets administrators manage LMS content, users, settings, and reports. It also gives managers access to direct-report and organization-level reporting where they have permission.
- API and back end – contains the business logic, serves data to the front-end applications, and supports integrations such as HR data import and training result export.
The Learn portal and Administration panel are browser-based front-end applications. They are served centrally through a content delivery network and do not store client data in the front-end application package.
The API handles data access, background tasks, integrations, authorization, audit logging, and the server-side behavior behind LMS actions.
The mobile Learn portal uses a mobile layout and navigation model, supports push notifications, and can be added to a phone home screen.
Hosting and operations
Most LMS servers are hosted by DigitalOcean. Another compliant provider can be used when needed.
Servers are configured and managed in bulk with automation, including most LMS version upgrades. Security updates are installed automatically where possible. Additional supporting servers are used for backups, application error analysis, logging, translation management, and continuous integration.
Data at rest and in transit is encrypted. Data moved to external systems is also encrypted unless it is sent to the external system for processing. Encryption keys are stored separately where possible.
Application logs and audit logs are continuously replicated to a central server for possible analysis.
Security model
Only authorized operations and support personnel have access to LMS servers and service provider administration consoles.
Server access uses SSH keys, with each person using their own key. Access to external service providers uses two-factor authentication where supported. Credentials are rotated regularly and stored in an access-controlled vault.
Staging and test systems are protected behind an authentication gateway that blocks unauthorized access to the LMS.
Each LMS instance is isolated from other instances. Every instance has its own databases and directories for data and temporary files, and that data is not accessible to other LMS instances on the same server.
Backups and resilience
The LMS uses multiple backup layers:
- Local backups are taken on each server every five minutes. This provides near-real-time backup access and reduces potential data loss.
- Five-minute backups are copied to an external server from a different provider in another region. The source server cannot remove those external backups.
- Daily external backups are stored with a cloud storage provider. The source server cannot remove those backups.
- The external backup server also creates daily external backups to cloud storage.
Older backups are retained with reduced granularity according to the current backup policy.
Backup and restore procedures are tested regularly.
Development and releases
Development and operations follow practices intended to reduce security risk and maintain service quality.
The software build and deployment process is automated. After a developer commits approved work to version control, production deployment can happen within minutes.
A senior developer always reviews any changes. Minor changes, bug fixes, and security fixes can be deployed directly to production. Significant new features are tested first in a staging environment, where clients can also review them for training and approval.
Staging environments are created by cloning the current production system and are protected behind an authentication gateway. External communications such as email, SMS, push notifications, and integrations are disabled in staging. Messages are routed to a common mailbox for verification.
Clients are expected to use the latest LMS version so they receive security, stability, and feature updates. The two latest versions are fully supported: the current stable version and the next version available for testing.
External services
Various external services are used, including DigitalOcean (Amsterdam), OVH (Poland), Backblaze (Amsterdam), Amazon AWS (Ireland), and CloudFlare. All services that process personal or sensitive information are based in the EU.