Arkhivio Backup Framework — GDPR Compliance Report

All S3 transfers use HTTPS via boto3 (TLS 1.2+). MongoDB connections use TLS when MONGO_OPTIONS includes the appropriate flags. config.py emits a WARNING log event at startup if TLS appears disabled on a non-local connection — the misconfiguration is surfaced before any data is processed.

S3 credentials stored in MongoDB are encrypted with Fernet AES-128-CBC + HMAC (crypto_utils.py) — the database alone cannot reach storage. Backup data encryption is delegated to the S3 bucket: SSE-KMS with a customer-managed key must be enabled on the bucket. No framework code change is required; this is a one-time bucket configuration.

Web dashboard enforces role-based access control (auth.py): admin — full CRUD on jobs and buckets; operator — read-only dashboards, history, monitor. Two authentication backends: local (timing-safe secrets.compare_digest) and Active Directory (ldap3 LDAP bind + memberOf group lookup). Sessions are signed with HMAC-SHA256 via itsdangerous. Startup validation (_validate_config()) raises RuntimeError before the server accepts connections if authentication is misconfigured.

CRC32 checksum computed for every file at scan time, stored in MongoDB and in the S3 object's x-amz-meta-crc32 header. audit.py provides three independent checks on demand: (1) file catalogue existence, (2) S3 metadata CRC match without downloading, (3) random file download with full CRC re-computation. All checks produce structured JSON output suitable as audit evidence.

S3-only disaster recovery path (restore_onlys3.py) requires only S3 credentials — no framework binary, no MongoDB needed. Every backed-up file is a plain object at {host}/{absolute/path}, listable and downloadable with aws s3 cp, rclone, or any S3 browser. S3 versioning, Object Lock (WORM), and cross-region replication can be independently enabled on the bucket.

Minimal data model: MongoDB stores only file metadata (path, size, mtime, CRC32) — no file content. S3 credentials masked in all API responses (_serialize_bucket() strips access_key and secret_key). Encryption key loadable from 6 secrets-manager integrations (AWS SM, Azure KV, GCP, IBM, HashiCorp Vault, OpenBao), keeping secrets entirely off disk.

The tooling for deletion exists and is tested: delete.py removes specific files from S3 and marks them deleted in MongoDB. The gap is procedural, not technical — the framework has no built-in mechanism to locate all objects belonging to a specific data subject. The operator must maintain a mapping of data-subject identity → backed-up file paths in their application layer, then invoke delete.py with those paths. No code change to the framework is required.

Every backed-up file is a raw, unmodified object at a predictable S3 path. The files.json.gz inventory published after every run lists all files with path, size, mtime, and CRC32 in an open JSON schema. No proprietary format, no deduplication index, and no framework binary are required to read or copy the data.

Every operation emits a structured UTC-timestamped JSON log event (logger.py). CRC mismatches, S3 drift, and reconciler anomalies are detected and logged with distinct event names. The gap is that no alerting pipeline is built in — connecting the log stream to Loki, Splunk, CloudWatch, or Prometheus (all documented in ALERTING.md) and defining incident-response runbooks is an operational step. S3 Access Logs and AWS CloudTrail should also be enabled on the bucket.

The framework itself is self-hosted Python and does not require a DPA. A DPA must be signed with each cloud provider used to store personal data: AWS (Standard Contractual Clauses / DPA for S3), Cloudflare (R2 DPA), MongoDB Atlas (Atlas DPA). All three providers offer standard DPA addenda.