Technical Summary

1. Purpose and Core Principles

• Control: changes are tied to defined rules and permissions.
• Auditability: logging of key events and traceability.
• Integrity: verification of source code and configuration integrity.
• On-prem operation: data is not transferred to external providers by default.

2. Functional Overview

2.1 File and Configuration Management

• Browsing, searching, and sorting directories and files.
• Controlled changes tied to authorization levels.
• Download and backup (ZIP) options (environment-dependent).

2.2 Document Vault

• Isolated document area (e.g. inbox, archive) with permissions.
• Upload, move, delete, download, and print (in Vault-only view).
• Operations are logged (audit) to support traceability.

2.3 Audit and Traceability

• Append-only style audit logging (action, target resource, timestamp, user, IP).
• Logging of access denials, failed logins, and privileged operations.

2.4 Permissions and Roles

• Role-based access (e.g. admin / manager / editor / viewer).
• Capability-based permissions/denies (e.g. vault.delete).
• Optional user-specific restrictions (“deny”) via configuration.

3. Security Layers

3.1 Authentication and 2FA

• Basic Auth with multi-user mode (depending on configuration).
• Optional email-based one-time code (OTP/2FA) for admin role.
• Login events are logged (successful/failed attempts).

3.2 CSRF and Rate Limiting

• CSRF token protection for state-changing (POST) actions.
• Rate limiting (flood protection) for uploads and selected actions.

3.3 Integrity Verification

• The system performs integrity checks to detect unauthorized changes.
• In case of integrity breach, operation may become risky and support may be restricted.

4. Deployment Models – In Brief

4.1 On-Premises (Local Deployment)

• The software runs in your infrastructure (own server/VM/VPS, own network).
• Data typically remains local.
• Operations are handled by you or your designated operator.
• Easier integration with internal systems.

4.2 Cloud-Hosted (Customer-Managed Cloud)

• The software runs on cloud infrastructure (e.g. AWS/Azure/Google), potentially within the Customer’s own cloud account.
• Scalability and fast expansion.
• Data handling and compliance require additional attention.

Note: a “cloud” solution can be SaaS, but it can also be cloud-hosted in the Customer’s own cloud account (customer-managed cloud). M-Explorer’s default delivery model is on-premises (not SaaS).

5. System Requirements (Indicative)

M-Explorer can be deployed in enterprise environments. Exact requirements are defined during technical coordination based on the target environment; the items below are for guidance.

5.1 Recommended Minimum (Small Environment)

• 1–2 vCPU
• 2–4 GB RAM
• SSD/NVMe storage (preferred due to logs and indexes)
• Stable network access to relevant data sources

5.2 Typical Profile (General Enterprise Use)

• 2–4 vCPU
• 4–8 GB RAM
• NVMe storage + regular backups
• Dedicated operations owner / designated admin is recommended

5.3 Runtime Environment

• Dedicated server or VM.
• Stable network access to the involved systems and directories.

5.4 Permissions and Operations

• Role-based access; admin and operator roles are recommended.
• Version updates, backup routines, and log management.

6. Vault – Formats and Execution Blocking

6.1 Allowed File Formats in the Vault (General Use)

The Vault area is not format-free, but it is also not a strictly document-only storage. The Vault may accept document formats (e.g. PDF), images (e.g. JPG, PNG), text files, and source-code files (e.g. PHP), provided that execution is technically blocked.

Important: files placed in the Vault must not be executable under any circumstances. Execution is blocked at both server and application level. Allowing a file format does not imply execution rights.

6.1.1 Limitations for Scan-Based Document Intake

Documents imported via scanning fall under a separate rule set. For scan-based intake, the system accepts only passive document formats:

• PDF
• JPG / JPEG

This limitation supports legally credible document handling, signed paperwork management, and the exclusion of active or hidden content.

6.2 Execution Blocking Within the Vault Area

Execution is not permitted throughout the entire Vault directory structure: no script execution, no server-side running of files. Files are only viewable, downloadable, or archivable according to permissions. This remains true even if the uploaded file type would normally be executable elsewhere (e.g. PHP).

7. Offline Handover and Emergency Backup (Optional)

Upon request, an offline backup of the completed system can be created at the end of installation (e.g. to a USB drive), handed over in a sealed envelope to the Customer’s managing director or an authorized person. The purpose is to provide a controlled, network-independent emergency restore option.