Systems Security and Integrity Policy
This policy describes the technical organization put in place to protect the workstations, the servers, and the cloud environments used and operated by Obscreen to deliver the Obscreen Cloud platform and its supporting services (license issuance, update / status APIs, public websites). It complements the Information Security Policy, the Privacy Policy, the Terms of Service, and the Subprocessors page.
Scope note. Unless explicitly stated otherwise, the measures described below apply to the systems operated by Obscreen. For self-hosted deployments of the Obscreen software, the configuration and security of the underlying systems (workstations, servers, network, backups, recovery) are the sole responsibility of the customer, in accordance with the Terms of Service.
1. User Workstations, Identity, and Access
1.1 Workstation Environment
- Workstations used to operate Obscreen are based on macOS and Linux.
- Workstations are configured with automatic screen locking and an up-to-date operating system. No customer or production data is stored locally, so the security model does not rely on full-disk encryption being enabled by default.
- No third-party EDR / antivirus solution is deployed on workstations at this time; Obscreen relies on operating-system level protections, hardened configurations, and the access controls described below.
1.2 Local Data
- No customer, billing, or production data is stored locally on workstations.
- Workstations are used exclusively as access terminals to source code, documentation, and remote infrastructure.
- Sensitive material (signing keys, secrets, customer database extracts) must never be downloaded to a workstation.
1.3 Identity Management
- Each user has a personal, named account on every system; shared accounts are prohibited.
- Access is granted following the principle of least privilege.
- Rights are revoked immediately upon departure of a person or change of role.
1.4 Password Management and Strong Authentication
A centralized password vault is used to manage all credentials related to Obscreen operations.
Password policy:
- One unique password per service.
- Minimum length: 26 characters.
- Composition: alphanumeric with special characters.
- Automatic generation via the password vault.
- No local or unencrypted storage of passwords.
Multi-factor authentication (2FA):
- 2FA is enabled on the password vault itself.
- 2FA is enabled on every service and tool wherever it is technically possible.
- Access to critical cloud, DevOps, license issuance, payment, and DNS / domain registrar services requires strong authentication.
1.5 Technical Access
- Access to technical environments (Hetzner, Cloudflare, AWS, container orchestration, databases, license issuance systems, payment integrations, administration tools) is:
- Restricted to authorized technical workstations.
- Only possible through a VPN tunnel (WireGuard) or an equivalent secure bastion.
- Without an active VPN session, no access to critical resources is allowed.
- Production access is logged and reviewed periodically.
This organization significantly limits the impact of a compromised workstation.
2. Server and Cloud Environment Security
2.1 Threat Detection
Server security relies on centralized detection on the cloud side, complemented by application-level monitoring.
- Tools used: native provider threat detection (such as Hetzner network protections, Cloudflare WAF and bot management, and equivalent capabilities of any other provider used) combined with centralized log and metrics monitoring.
- Critical alerts are routed to the on-call channel and reviewed by the Information Security Officer.
2.2 Monitoring Perimeter
The detection perimeter covers:
- The production and disaster-recovery accounts on each cloud provider used.
- API calls and audit logs on each cloud provider used.
- Network flows on critical subnets.
- Application logs, error rates, and abuse signals on customer-facing endpoints (
obscreen.io,lic.obscreen.io,motd.obscreen.io,updates.obscreen.io,support.obscreen.io). (plus all .com derived domains)
2.3 Update Policy
- Underlying services rely on managed offerings from our Subprocessors (Hetzner, Cloudflare, AWS, and others) whenever possible.
- Operating systems and runtime images are rebuilt and redeployed regularly to integrate security patches.
- Updates of managed components are applied automatically by the providers; their status is supervised by the Information Security Officer.
Any critical alert may trigger the incident response procedure and, where required, the activation of the Business Continuity Plan (BCP).
3. Business Continuity (Code)
3.1 General Principle
The application components of Obscreen Cloud (Studio control plane, license issuance services, public websites) are hosted on cloud infrastructure provided by our subprocessors, primarily Hetzner, with redundancy across multiple data centers and providers.
3.2 Environment Locations
- Primary environment:
- Hetzner (Germany).
- Disaster-recovery environment:
- A secondary location in the European Union, kept in standby and synchronized with the primary environment.
3.3 Disaster-Recovery Environment
- Standby Kubernetes (or equivalent) cluster ready to be activated.
- Application images and configurations synchronized with production.
- Identical security policies applied to both environments.
- Access strictly subject to VPN authentication.
3.4 Code Failover
- In nominal operation:
- The disaster-recovery environment is kept in standby and continuously updated.
- In case of a major incident:
- Activation by the DevOps team according to the documented runbook.
- Application traffic is redirected via DNS or load-balancer reconfiguration.
- Functional validation is performed after failover.
For self-hosted deployments, business continuity of the application is the sole responsibility of the customer, in accordance with the Terms of Service.
4. Business Continuity (Data)
4.1 General Principle
Application data of Obscreen Cloud (account databases, license records, billing metadata, customer media metadata) is hosted on infrastructure operated within the European Union: PostgreSQL databases on Hetzner (Germany), object storage on Cloudflare R2 (WEUR), and database backups stored on AWS S3 in Paris (eu-west-3).
4.2 Environment Locations
- Primary database environment:
- PostgreSQL on Hetzner (Germany).
- Primary object storage:
- Cloudflare R2, Western Europe region (
WEUR).
- Cloudflare R2, Western Europe region (
- Database backups:
- AWS S3 in Paris (
eu-west-3), providing redundancy on a separate provider while remaining within the European Union.
- AWS S3 in Paris (
4.3 Backup and Secondary Environment
- Automated and encrypted backups of databases stored on AWS S3 in Paris (
eu-west-3). - Replication and / or validated backups maintained in an EU location distinct from the primary one.
- Regular restoration tests.
- Access restricted via VPN authentication.
4.4 Data Failover
- In nominal operation:
- Replication and backups are continuously active.
- In case of a major incident:
- Restoration from validated backups. Backups are taken once per day and retained for a period sufficient to cover recent recovery scenarios.
- Failover to the secondary environment when necessary.
- Functional and data integrity validation after restoration.
For self-hosted deployments, backup and recovery of customer data is the sole responsibility of the customer.
5. Consistency with the Business Continuity Plan
The organization described above ensures:
- Compliance with the Maximum Tolerable Downtime (MTD) and Recovery Time Objectives (RTO) defined in the Business Continuity Plan.
- Coverage of the main risk scenarios: regional outage, cyberattack, and provider failure.
- A coordinated recovery of the Code and Data layers.
Code and Data failover tests are integrated into the annual Business Continuity Plan tests.
6. Contact
For any question regarding this Systems Security and Integrity Policy, or to report a security incident or vulnerability, please contact us at [email protected].
