Arkhivio Backup Framework — NIST Compliance Report

Two distinct account types — "admin" (full CRUD) and "operator" (read-only) — are provisioned via environment variables or Active Directory group membership (auth.py). AD backend delegates account lifecycle management (creation, disabling, removal) to the directory service. Startup validation in _validate_config() rejects incomplete account configurations before the server accepts connections.

All API write endpoints are gated by the require_admin() FastAPI dependency (main.py). Operator accounts receive HTTP 403 on any attempt to invoke write operations. Read-only endpoints use require_auth(). Unauthenticated requests return HTTP 401 or redirect to the login page. Bucket credentials (access_key, secret_key) are stripped from all API responses by _serialize_bucket(), preventing privilege escalation through information disclosure.

SessionMiddleware configured with max_age=SESSION_TIMEOUT_SECONDS (default 3,600 s). Set SESSION_TIMEOUT_SECONDS=900 in .env for a 15-minute lock consistent with NIST moderate-baseline guidance. The server rejects replayed cookies past max_age; explicit logout clears the session immediately.

Local backend enforces unique usernames per role with timing-safe comparison via secrets.compare_digest() (auth.py:121–130), preventing timing-based credential inference. AD backend binds each user individually via LDAP UPN, providing per-user unique identification backed by the enterprise directory.

Session cookies are signed with HMAC-SHA256 via itsdangerous using SESSION_SECRET; the application fails fast at startup if this secret is absent. The Fernet encryption key (BACKUP_SECRET_KEY) is validated at module load time. Key storage hardening is a configuration task: the framework supports 6 secrets-manager backends (AWS Secrets Manager, Azure Key Vault, GCP, IBM, HashiCorp Vault, OpenBao) via the SECRETS_PROVIDER env var.

The framework authenticates with username + password only. NIST SP 800-63B and the SP 800-53 moderate baseline require MFA for privileged (admin) accounts. The framework does not implement MFA natively, but the deployment architecture allows this to be satisfied externally.

Every significant event emits a structured JSON log record via log_event() (logger.py:70–86) containing ts (ISO-8601 UTC), event name, and contextual fields. All 6 privileged write endpoints emit named audit_* events with the acting user identity. Sample:

Events cover the full operation lifecycle: configuration changes, authentication, upload, scan, reconcile, delete, restore, and error conditions. No credentials or key material are ever written to logs.

Logs are written to stdout and optionally to a rotating file via RotatingFileHandler (logger.py:46–53, default 10 × 50 MB = 500 MB on disk). NIST SP 800-53 AU-11 requires retention aligned with organisational policy; for federal systems this is typically 3 years. The rotation scheme alone does not guarantee this.

In transit: All S3 operations use HTTPS (TLS 1.2+) via boto3. Web dashboard traffic is TLS-terminated by nginx with TLS 1.2+ enforced, ECDHE cipher suites, HSTS (2-year, preload), and HTTP→HTTPS hard redirect. MongoDB TLS is configurable via MONGO_OPTIONS and warned on at startup when absent. At rest: S3 credentials stored in MongoDB are encrypted with Fernet (AES-128-CBC + HMAC-SHA256) via crypto_utils.py. Backup data encryption at rest requires SSE-KMS on the S3 bucket — a cloud-console configuration, not a code change.

The Docker deployment isolates the application on an internal bridge network (docker-compose.yml). The uvicorn process listens on port 8000 but is not exposed to the host; only the nginx container on the same internal network can reach it. External traffic enters only on ports 80 (immediate HTTP→HTTPS redirect) and 443 (HTTPS). Nginx sets server_tokens off, X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, and Strict-Transport-Security headers. The container runs as non-root user appuser.

Administrative functions (job CRUD, bucket CRUD, auth configuration page) are guarded by require_admin(). Operator-accessible pages (dashboard, history, monitor) use require_auth(). The CLI pipeline (cli.py, scanner.py, uploader.py) is fully decoupled from the web dashboard and does not share session state, reducing the attack surface of the management interface.

API request bodies are validated via Pydantic BaseModel schemas (JobCreateRequest, BucketCreateRequest, etc.) in main.py. job_manager.py validates directory existence, threshold ordering (warning < critical, all > 0), and exclude-dir containment before writing to MongoDB. Invalid inputs return HTTP 422 with structured error detail.

CRC32 checksums are computed for every file at scan time (scanner.py), stored in MongoDB, and written to S3 object metadata on upload (uploader.py). audit.py provides three independent integrity checks on demand: (1) latest snapshot existence, (2) cross-validation of MongoDB CRC32 vs S3 x-amz-meta-crc32 metadata without downloading, (3) random file download with full CRC re-computation. reconciler.py detects MongoDB/S3 key-set drift and optionally corrects it.

All production dependencies are pinned to minimum versions in requirements.txt (e.g. cryptography>=40.0.0, pymongo>=4.0.0). The Dockerfile uses a multi-stage build with python:3.12-slim to minimise the installed surface. Automated dependency scanning is a configuration task — no scanner runs in CI by default.

Core purpose of the framework. Multi-job, multi-host backup pipeline stores every file as a plain S3 object at {host}/{absolute/path}. CRC32 metadata is stored alongside each object. The files.json.gz inventory is published to S3 after each run. S3 versioning and cross-region replication can be independently enabled on the bucket for additional redundancy.

restore.py provides multi-threaded restore with conflict handling, dry-run preview, and original path preservation. restore_onlys3.py provides an independent recovery path requiring only S3 credentials — no framework binary or MongoDB needed. reconciler.py detects and fixes consistency drift between MongoDB and S3 before or after a recovery event.

audit.py automates three-layer backup verification: snapshot catalogue check, S3 metadata CRC cross-validation, and random file download with CRC re-computation. Output is structured JSON suitable as evidence in a contingency plan test report. Documented as a weekly operational practice in USER_MANUAL.md.

No automated vulnerability scanner is included in the project. The codebase does ship with a full test suite (tests/) covering authentication, pipeline, compression, MongoDB, and restore+audit flows. Periodic dependency and container vulnerability scanning is a configuration task.

The framework emits rich structured events for all operations (uploads, errors, reconciler drift, auth failures, config warnings). ALERTING.md defines alert rules and runbooks. The gap is that no monitoring pipeline is activated by default — the log stream must be connected to a SIEM or metrics platform to fulfil CA-7.

Risk assessments and System Security Plans (SSPs) are organisational artefacts outside the scope of the framework. The codebase supports the evidence-gathering process: audit.py --json produces machine-readable integrity evidence, all configuration warnings are structured log events, and the deployment documentation (SETUP.md, USER_MANUAL.md) provides an accurate description of controls implemented.

The framework surfaces incident-relevant signals (anomalous CRC mismatches, reconciler drift, auth failures, S3 SlowDown events) as distinct structured log events. Translating those signals into an incident response workflow — classification, escalation, notification, and post-incident review — is an organisational procedure. ALERTING.md provides the starting-point alert rules to feed into an incident management system.