Assessment Questions & Answers

LogShip ERP is a multi-tenant web-based enterprise resource planning system built by LogYou GmbH (Germany). It provides warehouse management, order fulfillment, invoicing, and multi-channel e-commerce operations.

• Our customers are Amazon sellers, warehouse operators, and e-commerce businesses in the EU who use our platform to manage their orders, create accounting invoices, generate shipping labels, and handle fulfillment across multiple sales channels
• Our customers use LogShip to create invoices for their Amazon orders (for accounting and tax purposes) and upload those VAT invoices to Amazon for EU marketplace compliance
• The application is accessed via https://app.logship.de by authorized users with role-based permissions. Each customer operates within their own organization context with isolated data

Our integration covers order fulfillment workflows:

• Orders API (/orders/v0/orders) — Import Amazon orders including customer shipping/billing details for fulfillment
• Feeds API (/feeds/2021-06-30/) — Upload VAT invoices (UPLOAD_VAT_INVOICE feed type) for EU marketplace compliance
• Sellers API (/sellers/v1/marketplaceParticipations) — Connection testing to verify credentials
• LWA Token Endpoint (api.amazon.com/auth/o2/token) — OAuth refresh token flow for short-lived access tokens

We do not use: Catalog API, Notifications API, Advertising API, or any analytics/performance endpoints.

EU marketplaces only:

• DE (A1PA6795UKMFR9), FR (A13V1IB3VIYZZH), IT (APJ6JRA9NG5V4), ES (A1RKKUPIHCS9HS)
• NL (A1805IZSGTT6HS), BE (AMEN7PMS3EDWL), UK (A1F83G8C2ARO7P), PL (A1C3SOZRARQ6R3)
• SE (A2NODRKZP88ZB9), AT (A2CVHYRTWLQO9T)

All calls go to the EU endpoint: sellingpartnerapi-eu.amazon.com

We store customer PII required for order fulfillment (shipping labels and invoices):

• Customer name — Stored encrypted (AES-256) in the business partner table for shipping labels and invoices
• Email address — Stored encrypted for shipping notifications and delivery confirmation
• Phone number — Stored encrypted for shipping label requirements (required by carriers)
• Shipping & billing address — Stored encrypted for label creation and invoice generation
• Amazon Order ID — Stored as a reference to link our records to Amazon orders
• Upload status flag — Boolean indicating whether an invoice has been uploaded to Amazon
• Marketplace configuration — SP-API credentials (Client ID, Client Secret, Refresh Token) stored encrypted for authorized admin use

We do NOT store: payment/financial data, product catalog data, customer purchase history beyond the specific order, or seller performance metrics. All PII is encrypted at rest using AES-256.

Our architecture is a single dedicated server in an EU datacenter (Germany):

• Nginx — Reverse proxy, TLS termination, only port 443 open to internet
• OPNsense Firewall — Dedicated firewall appliance with stateful packet inspection, IDS/IPS, and automatic firmware updates. Only HTTPS passes through
• Nuxt 3 application (Node.js) — Serves the frontend and handles all API calls server-side. Runs on PM2 with 2 cluster instances on localhost:3001
• iDempiere ERP (Java) — Core business logic and data management, runs on localhost only
• Laravel (PHP) — Internal supplementary API, runs on a separate server in the same private subnet, not publicly accessible
• PostgreSQL — Primary database with encryption at rest, runs on localhost:5432 only
• Elasticsearch 8 — Product search, runs on localhost only
• Strapi CMS — Media management, runs on localhost only
• Proxmox VE — All servers run as VMs on Proxmox hypervisor. Proxmox management is not accessible from public internet

Key point: All traffic passes through OPNsense firewall first. Only Nginx receives inbound HTTPS. All backend services are on localhost or private subnet. The browser never directly contacts any backend service or external API — everything goes through the Nuxt server. The entire infrastructure runs on Debian Linux with automated security updates.

Yes. Our security governance follows these principles:

• Principle of least privilege — Users and services only have access to data they need for their role
• Defense in depth — Multiple security layers (firewall, TLS, auth, RBAC, localhost isolation)
• Data minimization — We only collect and store data that is necessary for business operations
• Encryption in transit — All external communication uses TLS 1.2+
• Regular updates — Server OS and dependencies are regularly patched

• Infrastructure isolation — Single-server architecture means the attack surface is limited to one Nginx entry point
• Dependency management — We use npm audit to track known vulnerabilities in Node.js dependencies
• Access reviews — User access and roles are reviewed by management. Departing team members have access revoked immediately
• Credential rotation — API credentials can be updated through the admin interface at any time

Yes. As a German company, we comply with GDPR (General Data Protection Regulation). Our privacy policy covers:

• Data collection and processing purposes
• Data subject rights (access, rectification, deletion)
• Data retention periods
• Third-party data sharing disclosures
• Data protection officer contact

Dedicated infrastructure hosted at Hetzner (German datacenter provider).

• Hosting provider: Hetzner (German datacenter provider, ISO 27001 certified, SOC 1 & SOC 2 compliant)
• Virtualization: Proxmox VE hypervisor — all servers run as isolated virtual machines. Proxmox management interface is not accessible from the public internet
• Operating system: Debian Linux with unattended-upgrades for automatic security patching
• Firewall: OPNsense appliance with IDS/IPS, stateful packet inspection, automatic firmware updates
• All data stays within the EU, compliant with GDPR data residency requirements

• OPNsense Firewall: Dedicated firewall appliance in front of the server. Stateful packet inspection, IDS/IPS capabilities, automatic firmware updates. Only HTTPS (port 443) allowed inbound
• Proxmox isolation: All servers run as VMs on Proxmox VE. The hypervisor management interface is restricted to internal network only
• Nginx reverse proxy: TLS 1.2+ termination with modern cipher suites. Security headers applied (X-Frame-Options, X-Content-Type-Options, HSTS, etc.)
• Service isolation: iDempiere, PostgreSQL, Elasticsearch, Strapi bind to localhost only. Laravel runs on a separate server in the same private subnet — all completely inaccessible from the internet
• SSH hardening: Key-based authentication, IP whitelisting, no root login
• OS patching: Debian with unattended-upgrades — automatic security updates applied daily

• The server runs Linux, which has a significantly lower malware risk than Windows servers
• We use firewall rules and service isolation as primary defense mechanisms
• File uploads are validated and restricted by type/size in the application layer
• Only authorized personnel have SSH access to the server

• PM2 process manager runs the Nuxt application in cluster mode (2 instances) for reliability
• Node.js v20 LTS — Long-term support version with security patches
• Deployment via Git-based workflow: code is reviewed, built, and deployed to the production server
• No public CI/CD pipeline — deployments are controlled by authorized developers

Yes, all external communication is encrypted.

• Browser ↔ Server: TLS 1.2+ via Nginx with modern cipher suites. HTTPS enforced (HTTP redirects to HTTPS)
• Server ↔ Amazon SP-API: HTTPS/TLS to sellingpartnerapi-eu.amazon.com and api.amazon.com
• Server ↔ DHL/Sendcloud/Shopify: All outbound API calls use HTTPS/TLS
• Internal services: Communicate over localhost (no network traversal), so TLS is not needed for inter-service calls

• Database: PostgreSQL uses encrypted storage for sensitive data. The database is only accessible via localhost — it cannot be reached from the network. Database backups are also encrypted
• Filesystem: The Proxmox VM storage provides an additional layer of isolation. Server storage is managed within the datacenter with physical security controls
• PII encryption: All Amazon customer PII (names, addresses, emails, phone numbers) is encrypted at rest using AES-256 encryption in the iDempiere database
• Credentials: All API secrets (including SP-API credentials) are encrypted at rest using AES-256 encryption before being stored in the database
• Environment configuration: Server-side configuration files containing infrastructure credentials are stored with restricted file permissions (readable only by the application user)
• Amazon data scope: We store customer PII only for operational necessity (shipping labels and invoices). No payment data, product catalog data, or purchase history is stored

• SP-API credentials (Client ID, Client Secret, Refresh Token) are stored encrypted (AES-256) in the iDempiere database in the c_ordersource table
• Encryption workflow: Credentials are encrypted before writing to the database and decrypted in-memory only at the moment of use. Encryption keys are stored separately from the database in secured environment configuration
• Access control: Only admin-role users can view or modify marketplace configurations through the ERP interface. Credentials are masked in the UI
• Server-side only: Credentials are fetched and decrypted server-side when an invoice upload is triggered. They never reach the browser or client-side code
• Database isolation: PostgreSQL runs on localhost:5432, behind OPNsense firewall and Proxmox VM isolation. Not accessible from the internet
• LWA access tokens: Short-lived tokens obtained per-operation. They are held in server memory only and never persisted to disk
• Environment variables: Infrastructure credentials are stored in secured environment files with restricted file permissions (600), not in source code. Git repository excludes all environment files

No. Neither SP-API credentials nor Amazon customer PII are in source code. SP-API credentials are stored encrypted in the iDempiere database and entered by admin users through the ERP interface. Customer PII is imported at runtime via the Orders API and stored encrypted. The .env files (which contain infrastructure config) are excluded from version control via .gitignore.

• OPNsense Firewall: Dedicated firewall appliance with IDS/IPS, stateful packet inspection, and automatic updates. Default-deny policy — only HTTPS (443) allowed inbound
• Proxmox VM isolation: All servers are virtualized on Proxmox VE. Each service runs in its own isolated VM. Proxmox management is internal-only
• No public service ports: PostgreSQL (5432), Elasticsearch (9200), and all other services are bound to localhost or private subnet
• Single public entry point: All traffic enters through OPNsense → Nginx. Nginx acts as a reverse proxy and TLS terminator
• Private subnet: Backend services communicate over localhost or private subnet (Laravel). No public network traversal between services

• OS level: Debian with unattended-upgrades — automatic daily security updates. Critical patches applied immediately
• OPNsense: Automatic firmware updates ensure firewall rules and IDS/IPS signatures are current
• Proxmox: Hypervisor updated regularly with enterprise repository access
• Node.js: Running LTS version (v20) with scheduled updates when new LTS versions are released
• Dependencies: npm audit used to identify and resolve known vulnerabilities in JavaScript packages
• Nginx: Updated with OS packages. TLS configuration reviewed for deprecated ciphers
• iDempiere: Updated when new versions are released by the iDempiere community

• We perform regular dependency audits using npm audit
• Our architecture inherently minimizes attack surface: only one port (443) is exposed, and all backend services are on localhost
• We monitor for known CVEs in our technology stack (Node.js, Nginx, PostgreSQL)

• Version control: All code is managed in Git with branch-based development
• Code review: Changes are reviewed before merging to the main branch
• Environment separation: Development (dev-app.logship.de) and production (app.logship.de) environments are separate
• No secrets in code: Environment variables and database-stored credentials keep secrets out of the codebase

• XSS: Vue.js / Nuxt automatically escapes template output. Server-side rendering adds another safety layer
• CSRF: Cookie-based auth with SameSite attributes. Server validates tokens on every request
• SQL Injection: Not applicable — we use OData queries to iDempiere's REST API, not raw SQL. PostgreSQL access is through PostgREST with parameterized functions
• Auth bypass: Server-side middleware checks authentication on every protected route. Client-side redirects are backed by server-side checks
• Sensitive data exposure: All external API calls are server-side only. Credentials never reach the browser

• Changes follow a Git workflow: dev branch for development, main branch for production
• Features are developed on feature branches and merged after review
• Deployments to production are manual and controlled by authorized developers
• Rollback is possible via Git history and PM2 process management

• Role-Based Access Control (RBAC): iDempiere provides comprehensive RBAC. Users are assigned roles that define what data and functions they can access
• Organization-level isolation: Users can only access data for their assigned organization(s). The logship_organization_id cookie and server-side checks enforce this
• Authentication flow: JWT-based authentication with access tokens and refresh tokens. Session management through HTTP cookies
• SP-API credential access: Only users with admin roles can view, create, or modify marketplace configurations (order sources)

• User passwords are managed by the iDempiere authentication system
• JWT tokens have expiration times — access tokens are short-lived, refresh tokens have longer validity
• When a token expires, the system automatically attempts refresh. If refresh fails, the user is logged out
• Server access (SSH) uses key-based authentication, not passwords

• Their iDempiere user account is deactivated immediately (IsActive = false)
• Their SSH key is removed from the server
• Any active sessions are invalidated by the token expiration mechanism
• Access removal is verified by management

• SSH access to the server uses key-based authentication (equivalent security to MFA)
• The iDempiere system supports role-based and organization-based access restrictions
• Application access is further protected by the fact that all backend services are localhost-only

• Application logs: All API requests and responses are logged by the Nuxt server (with sensitive data like Bearer tokens redacted)
• PM2 monitoring: PM2 provides process monitoring, automatic restarts on crash, and log management
• Nginx access/error logs: All incoming requests are logged with timestamps, IPs, and response codes
• iDempiere audit trail: iDempiere maintains its own audit log of data changes
• System logs: Linux system logs (syslog, auth.log) capture system-level events including SSH access attempts

Yes, our incident response process includes:

• Detection: Monitoring logs for unusual activity, failed auth attempts, unexpected API errors
• Assessment: Evaluate severity and scope of the incident
• Containment: Isolate affected services, revoke compromised credentials, block suspicious IPs
• Notification: If Amazon seller data is affected, we will notify Amazon and affected sellers within 24 hours, as required by the Data Protection Policy
• Recovery: Restore from backups if needed, deploy fixes, verify resolution
• Post-mortem: Document lessons learned and implement preventive measures

• Auth failure logging: The application logs all authentication failures and forced logouts
• Nginx logs: Monitoring for unusual request patterns, high error rates, or suspicious user agents
• SSH logs: Linux auth.log records all SSH login attempts and failures
• Token refresh failures: The application tracks when token refreshes fail, which could indicate credential compromise

As a German company, GDPR compliance is fundamental to our operations:

• Data minimization: We only collect data necessary for order fulfillment. From Amazon, we store customer name, address, email, and phone — the minimum required for shipping labels and invoices. No payment data or purchase history is stored
• Purpose limitation: Amazon data is used exclusively for invoice management and VAT compliance
• Data subject rights: We support access, rectification, and deletion requests
• Data residency: All data is stored in the EU (German datacenter)
• Processing records: We maintain records of data processing activities as required by GDPR Article 30

• Amazon customer PII (business partner records, locations, contact details) can be deactivated or fully purged through the admin interface
• Marketplace configurations including SP-API credentials can be removed at any time by authorized admin users
• We comply with Amazon's Data Protection Policy requirement to delete data when it is no longer needed or when access is revoked
• GDPR data subject deletion requests (Article 17) are honored, subject to legal retention obligations (German tax law requires 10-year retention of financial records)
• When a seller revokes SP-API authorization, all associated customer records and credentials are removed from the system

Our Amazon data lifecycle covers order fulfillment:

1. Collection (Order Import): When an Amazon order is imported, customer PII is extracted:
   • Customer name, email, marketplace username → stored encrypted in Business Partner record
   • Shipping address (street, city, postal, country, phone) → stored encrypted in Location record
   • Billing address (if different) → stored encrypted in separate Location record
   • Amazon Order ID → stored as reference on the order
2. Processing (Fulfillment & Invoicing):
   • Shipping labels: Customer name, address, email, and phone are decrypted server-side and transmitted via HTTPS to DHL/Sendcloud for label creation
   • Invoice creation: Our customers (Amazon sellers) create accounting invoices for their Amazon orders within LogShip. These invoices contain customer billing name, address, and order details — generated server-side using the stored PII
   • Invoice upload to Amazon: The invoice PDF is uploaded to Amazon via SP-API Feeds (UPLOAD_VAT_INVOICE) for EU VAT compliance. This is a requirement for sellers operating in EU Amazon marketplaces
   • Delivery confirmation: Tracking data and delivery status sent back to Amazon via server-side API
3. Storage: All PII is encrypted at rest (AES-256) in the iDempiere PostgreSQL database on localhost
4. Deletion: Customer records can be deactivated or fully purged by admin users. When a seller revokes authorization, all associated data is removed

• Customer PII (name, address, email, phone): Retained encrypted for the duration of the business relationship. Required for accounting/tax compliance under German law (10-year retention for financial records). Can be deleted upon data subject request (GDPR Article 17), subject to legal retention obligations
• Amazon Order IDs: Retained as part of the order record for business/tax compliance
• LWA access tokens: Not stored — obtained per-operation, held in memory only, discarded after use
• SP-API credentials: Retained encrypted until the marketplace configuration is deleted by an admin or the seller revokes authorization
• Feed/upload metadata: Not stored beyond the immediate operation
• Shipping carrier data: Customer data transmitted to DHL/Sendcloud is governed by their respective data protection policies. We do not control retention on their side

Yes, but only with shipping carriers for operational fulfillment. Amazon customer PII is shared with:

• DHL: Receives customer name, address, email, and phone number for shipping label creation. Transmitted via HTTPS (OAuth-authenticated API). This is operationally required — you cannot create a shipping label without a recipient address
• Sendcloud: Same as DHL — receives customer name and address for multi-carrier label creation. Transmitted via HTTPS (Basic auth)

Amazon data is NOT shared with:

• Shopify: Separate e-commerce integration. No Amazon data flows to Shopify
• Strapi CMS: Internal media management on the same server. No Amazon data involved
• Elasticsearch: Internal search indexing on localhost. Used for product search, not Amazon customer data
• Analytics/marketing services: We do not use any analytics or marketing services that receive Amazon data

Summary: Amazon customer PII is shared only with shipping carriers (DHL, Sendcloud) for the sole purpose of order fulfillment. All transmissions use HTTPS/TLS encryption. Both DHL and Sendcloud are GDPR-compliant EU service providers.

Service	Purpose	Receives Amazon PII?	Encryption
Amazon SP-API	Order import, invoice upload	Yes (invoices with customer data)	HTTPS/TLS
DHL API	Shipping labels	Yes (name, address, email, phone)	HTTPS/TLS + OAuth
Sendcloud API	Multi-carrier shipping	Yes (name, address)	HTTPS/TLS + Basic Auth
Shopify API	E-commerce channel	No	HTTPS/TLS
iDempiere	ERP backend (same server)	N/A (internal, stores PII encrypted)	localhost
Laravel	Internal API (private subnet)	N/A (internal, delivery confirmations)	Private subnet
PostgreSQL	Database (same server)	N/A (internal, PII encrypted at rest)	localhost
Elasticsearch	Search (same server)	No	localhost
Strapi	CMS (same server)	No	localhost

• Support access is through the same authenticated ERP interface as regular users
• Support staff are assigned specific roles with limited permissions matching their responsibilities
• All support actions are logged in the iDempiere audit trail
• Support does not have direct database access — they use the application interface

• Support uses the same application as regular users, with the same security controls (TLS, JWT auth, RBAC)
• No separate support tools with weaker security exist
• Amazon SP-API credentials are only visible to admin-level roles, not regular support

During screen share: Navigate to Settings > Order Sources in the ERP. Show that marketplace credentials are entered and managed through the admin interface. Explain that these are stored in the iDempiere database (PostgreSQL on localhost) and only accessible to admin-role users.

During screen share: Show the OPNsense firewall dashboard — navigate to Firewall > Rules to show that only HTTPS (443) is allowed inbound. You can also show the IDS/IPS status and automatic update configuration. On the server, run ss -tlnp to show all services bound to localhost.

During screen share: Run ss -tlnp or netstat -tlnp to show that PostgreSQL, Elasticsearch, iDempiere, etc. are bound to 127.0.0.1 (localhost) only. Only Nginx is bound to 0.0.0.0:443.

• The admin can immediately update or delete the marketplace credentials in the Order Source settings
• The seller can revoke authorization directly in Amazon Seller Central
• Since LWA access tokens are short-lived and not cached, revoking the refresh token immediately stops all access
• We would notify the affected seller and Amazon as part of our incident response process

• Database backups: PostgreSQL is backed up regularly
• Code: Full codebase in Git with complete history
• Recovery: In case of server failure, the application can be redeployed from Git and database restored from backup
• PM2: Automatic process restart on crash, with 2 cluster instances for availability

• We only access SP-API data for its stated purpose: uploading VAT invoices for EU compliance
• We do not scrape, resell, or repurpose Amazon data
• We respect rate limits — our invoice upload process includes a 3-second delay between uploads
• We only access marketplaces where the seller has explicitly authorized our application
• We will delete data and revoke access when a seller terminates the relationship