Information Security Policy

1. Purpose & Scope

This policy establishes the information security framework for LogYou GmbH's LogShip ERP platform and all associated systems. It applies to all employees, contractors, and systems that process, store, or transmit business data, including data received from third-party integrations such as the Amazon Selling Partner API (SP-API).

The policy ensures compliance with:

• EU General Data Protection Regulation (GDPR)
• Amazon Data Protection Policy (DPP)
• Amazon Acceptable Use Policy (AUP)
• Industry security best practices (OWASP, CIS Benchmarks)

2. Security Principles

All security decisions are guided by the following principles:

• Least Privilege: Users and services receive only the minimum access required to perform their function
• Defense in Depth: Multiple security layers protect data at each tier (network, application, database)
• Data Minimization: Only necessary data is collected, processed, and retained
• Encryption by Default: Data is encrypted in transit (TLS 1.2+) and at rest (AES-256)
• Separation of Concerns: Backend services are isolated from each other and from public access
• Continuous Monitoring: Systems are monitored for anomalies and security events

3. Infrastructure Security

3.1 Hosting Environment

All systems are hosted at Hetzner, a German datacenter provider with ISO 27001 certification and SOC compliance. Servers are located in Germany, ensuring EU data residency.

3.2 Virtualization

All servers run as isolated virtual machines on Proxmox VE hypervisor. The Proxmox management interface is restricted to the internal network and is not accessible from the public internet. VM isolation ensures that compromise of one service does not affect others.

3.3 Network Security

• OPNsense Firewall: A dedicated OPNsense firewall appliance protects all inbound and outbound traffic. It provides stateful packet inspection, intrusion detection and prevention (IDS/IPS), and is automatically updated with the latest firmware and threat signatures.
• Default-Deny Policy: Only HTTPS (port 443) is allowed inbound. All other ports are blocked.
• Service Isolation: All backend services (iDempiere, PostgreSQL, Elasticsearch, Strapi, PostgREST) bind to localhost only. Laravel runs on a separate server in the same private subnet. No backend service is accessible from the public internet.
• Nginx Reverse Proxy: TLS 1.2+ termination with modern cipher suites. Security headers (X-Frame-Options, X-Content-Type-Options, HSTS, X-XSS-Protection) applied to all responses.

3.4 Operating System Hardening

• Operating system: Debian Linux
• Automatic security updates via unattended-upgrades (daily execution)
• SSH: Key-based authentication only, root login disabled, IP whitelisting
• Unnecessary services and packages are removed
• File permissions follow the principle of least privilege

4. Data Protection

4.1 Encryption in Transit

• All client-to-server communication: TLS 1.2+ (HTTPS)
• All outbound API calls (Amazon SP-API, DHL, Sendcloud, Shopify): HTTPS/TLS
• Internal service communication: Occurs over localhost or private subnet (no network traversal)

4.2 Encryption at Rest

• Database credentials and API secrets: Encrypted using AES-256 before storage
• SP-API credentials (Client ID, Client Secret, Refresh Token): Encrypted in the application database. Decryption occurs in-memory only at the moment of use
• Environment configuration files: Stored with restricted file permissions (600), readable only by the application service user
• Encryption keys: Stored separately from encrypted data

4.3 Data Classification

Classification	Examples	Controls
Confidential	API credentials, encryption keys, database passwords	Encrypted at rest, encrypted in transit, restricted access, never logged
Internal	Business records, order data, partner information	Encrypted in transit, role-based access, audit logging
Public	Company website, tracking pages	Standard web security controls

5. Access Control

5.1 Authentication

• JWT-based authentication with short-lived access tokens and refresh tokens
• Token validation on every API request (server-side middleware)
• Automatic session expiration with forced re-authentication
• Failed authentication attempts are logged and monitored

5.2 Role-Based Access Control (RBAC)

• iDempiere provides comprehensive RBAC with role, organization, and client-level permissions
• Users are assigned specific roles that define accessible data and operations
• SP-API credential management restricted to admin-level roles
• Organization-level data isolation ensures users only access their assigned organization's data

5.3 Access Lifecycle

• Provisioning: New users are created by administrators with appropriate role assignment
• Review: Access rights are reviewed by management periodically
• Revocation: When a team member departs, their user account is immediately deactivated, SSH keys removed, and active sessions invalidated

5.4 Server Access

• SSH access via key-based authentication only (no passwords)
• IP whitelist restricts SSH access to authorized locations
• Root login is disabled; privileged operations require explicit sudo
• All SSH sessions are logged in system auth logs

6. Application Security

6.1 Secure Development Practices

• Version Control: All code managed in Git with branch-based development workflow
• Code Review: Changes reviewed before merging to production branch
• Environment Separation: Separate development and production environments with different credentials
• Dependency Auditing: Regular npm audit scans for known vulnerabilities
• No Secrets in Code: Credentials stored in encrypted database or secured environment files, never in source code

6.2 OWASP Protection

• XSS Prevention: Vue.js/Nuxt automatic output escaping with server-side rendering
• CSRF Protection: Cookie attributes (SameSite, HttpOnly) and server-side token validation
• Injection Prevention: OData queries to iDempiere REST API (no raw SQL); parameterized functions via PostgREST
• Authentication Bypass: Server-side auth middleware on every protected route
• Sensitive Data Exposure: All external API calls server-side; credentials never sent to browser

6.3 Server-Side Architecture

All sensitive operations, including Amazon SP-API calls, are executed server-side in Nuxt API routes. The browser client never receives API credentials, access tokens, or direct access to backend services. This architecture eliminates client-side credential exposure risk.

7. Amazon SP-API Data Handling

7.1 Purpose Limitation

Amazon SP-API integration is used for order fulfillment and accounting workflows:

• Order import: Customer PII (name, address, email, phone) is imported from Amazon orders to enable shipping label creation and invoice generation
• Invoice creation: Our customers (Amazon sellers) create accounting invoices for their Amazon orders within LogShip, using customer billing data for proper invoicing
• Invoice upload: VAT invoices are uploaded to Amazon via the Feeds API (UPLOAD_VAT_INVOICE) for EU marketplace tax compliance
• Shipping label generation: Customer delivery addresses are used to create shipping labels via DHL/Sendcloud
• Delivery confirmation: Tracking information and delivery status are reported back to Amazon

No Amazon data is used for marketing, analytics, profiling, or any purpose beyond order fulfillment and accounting.

7.2 PII Data Inventory

Data	Stored?	Encryption	Purpose	Retention
Customer Name	Yes	AES-256	Shipping labels, invoices	Business lifecycle / deletion request
Email Address	Yes	AES-256	Shipping notifications	Business lifecycle / deletion request
Phone Number	Yes	AES-256	Shipping labels (carrier requirement)	Business lifecycle / deletion request
Shipping Address	Yes	AES-256	Shipping labels	Business lifecycle / deletion request
Billing Address	Yes	AES-256	Invoice generation	Business lifecycle / deletion request
Amazon Order ID	Yes	AES-256	Order linking	Business lifecycle
SP-API Credentials	Yes	AES-256	API authentication	Until admin removes
LWA Access Tokens	No (in-memory)	N/A	Per-operation auth	Discarded after use
Payment/Financial Data	No	N/A	Not accessed	N/A

7.3 PII Encryption

• All customer PII fields are encrypted at rest using AES-256 before storage in the PostgreSQL database
• Decryption occurs in server memory only at the moment of use (label creation, invoice generation)
• Decrypted PII is never written to disk, logs, or temporary files
• PII is transmitted to shipping carriers (DHL, Sendcloud) only via HTTPS/TLS-encrypted connections

7.4 Credential Security

• SP-API credentials are encrypted (AES-256) before storage in the database
• Decryption occurs in server memory only at the moment of API call
• LWA access tokens are short-lived and not persisted
• Only admin-role users can manage marketplace configurations
• Credentials are masked in the application UI

7.5 Third-Party PII Sharing

Amazon customer PII is shared with the following third parties, exclusively for order fulfillment:

Recipient	PII Shared	Purpose	Security
DHL	Name, address, email, phone	Shipping label creation	HTTPS/TLS + OAuth 2.0
Sendcloud	Name, address	Multi-carrier label creation	HTTPS/TLS + Basic Auth
Amazon (SP-API)	Invoice with billing details	VAT compliance upload	HTTPS/TLS + LWA OAuth

Both DHL and Sendcloud are GDPR-compliant EU service providers. No Amazon PII is shared with analytics, marketing, advertising, or any non-operational service.

7.6 Data Deletion

Amazon customer PII can be deleted through the admin interface at any time. When a seller revokes SP-API authorization or the business relationship ends, all associated customer records, order data, and marketplace credentials are removed from the system. Individual customer records can be deactivated or fully purged by authorized admin users. We comply with both Amazon's Data Protection Policy and GDPR Article 17 (right to erasure), subject to legal retention obligations under German tax law (10-year retention for financial records).

8. Monitoring & Incident Response

8.1 Logging

• Application logs: All API requests and responses logged with timestamps, source IPs, user identifiers, and success/fail status. Sensitive data (authorization tokens) is redacted
• Nginx logs: All inbound requests logged with IP, timestamp, response code, user agent, and request URI
• System logs: SSH access attempts, sudo usage, service events (syslog, auth.log)
• iDempiere audit trail: Data modification history maintained by the ERP system with user, timestamp, and field-level change tracking
• OPNsense logs: Firewall events, IDS/IPS alerts, blocked traffic, connection state changes
• PM2 logs: Application process monitoring, crash recovery events
• Log retention: All logs are retained for a minimum of 90 days. Log rotation is configured to preserve at least 90 days of history across all log sources
• Log protection: Log files are protected from unauthorized modification through file system permissions. Logs are backed up as part of the regular backup schedule

8.2 Incident Response Procedure

1. Detection: Monitor logs for unusual activity, failed auth attempts, unexpected errors, IDS/IPS alerts
2. Assessment: Evaluate severity, scope, and data impact. Determine if Amazon seller data is affected
3. Containment: Isolate affected services, revoke compromised credentials, block suspicious IPs via OPNsense
4. Notification: If Amazon seller data is involved, notify Amazon and affected sellers within 24 hours per DPP requirements. Notify relevant authorities per GDPR if personal data is breached (72-hour deadline)
5. Eradication: Remove threat, patch vulnerabilities, rotate affected credentials
6. Recovery: Restore services from backups if needed, verify system integrity, deploy fixes
7. Post-Mortem: Document root cause, timeline, impact, and preventive measures

Approval: This incident response plan is approved by senior management and reviewed every 6 months. Amazon will be notified at security@amazon.com within 24 hours if Amazon seller data is potentially affected.

8.3 Business Continuity

• Database backups: Regular PostgreSQL backups with encrypted storage
• Code repository: Full codebase in Git with complete history
• Process recovery: PM2 provides automatic process restart on crash (2 cluster instances for availability)
• Infrastructure recovery: Proxmox VM snapshots enable rapid restoration

9. Vulnerability Management

9.1 Scanning Schedule

• Dependency auditing: npm audit is executed regularly (minimum every 180 days) to identify known vulnerabilities in application dependencies
• OPNsense IDS/IPS: Continuous intrusion detection and prevention with automatically updated threat signatures
• OS vulnerability scanning: Debian unattended-upgrades automatically applies security patches daily. Manual review of pending updates performed weekly

9.2 Remediation Timelines

Severity	Remediation Deadline
Critical	Within 7 days
High	Within 30 days
Medium	Within 90 days
Low	Next scheduled maintenance

9.3 Penetration Testing

Application security assessments are performed periodically (minimum every 365 days), covering the public-facing HTTPS endpoint, OAuth/LWA token flows, and any backend logic processing third-party API data.

10. Privacy & GDPR Compliance

• Data residency: All data stored in Germany (Hetzner datacenter), fully within the EU
• Data subject rights: We support access, rectification, portability, and deletion requests per GDPR Articles 15-20
• Processing records: Maintained per GDPR Article 30
• Data protection: Technical and organizational measures per GDPR Article 32
• Breach notification: 72-hour notification to authorities, prompt notification to data subjects per GDPR Articles 33-34
• Amazon data: Processed under legitimate interest for invoice management and EU VAT compliance

11. Third-Party Management

External services used by the platform:

Service	Purpose	Amazon PII Shared?	Security
Amazon SP-API	Order import, invoice upload	Yes (invoices with customer data)	OAuth 2.0 / LWA, HTTPS
DHL API	Shipping labels	Yes (name, address, email, phone)	OAuth 2.0, HTTPS
Sendcloud	Multi-carrier shipping	Yes (name, address)	Basic Auth, HTTPS
Shopify	E-commerce channel	No	OAuth 2.0, HTTPS
Hetzner	Infrastructure hosting	N/A (IaaS provider)	ISO 27001, physical security

Policy: Amazon customer PII is shared exclusively with shipping carriers (DHL, Sendcloud) for the operational purpose of creating shipping labels. Both carriers are GDPR-compliant EU service providers. No Amazon data is shared with analytics, marketing, or non-operational services. All third-party API communications use encrypted HTTPS connections.

12. Policy Review

This security policy is reviewed and updated at least annually, or whenever significant changes occur to the infrastructure, application, or regulatory requirements. All team members are informed of policy updates.