Security Policy

1. Network Protection (DPP §1.1)

1.1 Production Infrastructure (Hetzner Cloud VPS)

• Perimeter firewall + ACLs: Hetzner Cloud Firewall enforces default-deny baseline. Only TCP 80/443 inbound from 0.0.0.0/0. SSH (22) restricted via ACL to a fixed admin IP allowlist. All other ports denied.
• Network segmentation: Hetzner private network separates public-facing DMZ (Caddy reverse proxy) from internal application and database subnet. Docker user-defined bridge networks further isolate web, application, and worker containers with explicit inter-container ACLs. No direct public access to data services.
• Signature-based IDS/IPS: CrowdSec deployed with community signature collections (linux, sshd, http-cve, base-http-scenarios, caddy) for pattern-based detection of CVE exploitation, credential-stuffing, and scanner activity. Malicious IPs are auto-blocked at the firewall layer via iptables bouncer.
• Brute-force protection: fail2ban as a complementary layer on SSH and web auth endpoints.
• Anti-malware (server): ClamAV with freshclam daily definition updates; weekly full scans scheduled; on-access scanning enabled. Disabling clamav-daemon requires root privileges. All sudo actions are logged.
• Database isolation: PostgreSQL bound to 127.0.0.1 only — no public exposure. No publicly exposed file servers; static assets served exclusively via Caddy reverse proxy.
• TLS termination: Caddy reverse proxy enforces TLS 1.3 with HSTS; older protocols disabled.
• SSH hardening: Key-only authentication; password auth disabled; root login disabled; fail2ban + CrowdSec active on SSH service.

1.2 Developer / Desktop Endpoint

• Disk encryption: macOS FileVault full-disk encryption enabled on the developer workstation.
• Host firewall: macOS Application Firewall enabled in stealth mode; all inbound connections blocked by default.
• Endpoint anti-malware: macOS built-in XProtect, Gatekeeper, and MRT active with automatic signature updates. Disabling these controls requires admin password (MDM profile enforced).
• OS patching: Automatic macOS security updates enforced.
• No production credentials on workstation: Secrets are injected at runtime on the server. No plaintext credentials on developer disk. Credential manager (Bitwarden) with MFA enforced.
• Production access: Servers reachable only via SSH from a fixed IP allowlist using hardware-key-backed SSH credentials. No direct database access from developer endpoint.

1.3 Defense-in-Depth Summary

Perimeter firewall + ACLs → CrowdSec signature IDS/IPS → fail2ban brute-force layer → Caddy TLS 1.3 + HSTS → application-level auth + rate limiting → PostgreSQL bound to localhost + field-level AES-256-GCM encryption. No single layer failure exposes Amazon Information.

2. Access Management (DPP §1.2)

• Approved Users: System access is restricted to the sole Approved User (founder, coding and development responsibilities). No shared accounts. No third-party or personal device access.
• MFA: Multi-factor authentication enforced on all admin interfaces: Hetzner, GitHub, Bitwarden, Amazon Seller Central, Amazon Developer Console.
• Account lockout: 5 failed login attempts triggers lockout on all admin interfaces.
• Access revocation: All access revocable within 24 hours.
• Quarterly access review: Access rights reviewed quarterly; unnecessary access removed.
• Annual training: The Approved User completes annual data protection and IT security awareness training. Training records retained.
• Training completed: Mahmut Fuat Sahin — AWS Cloud Security Essentials for Executives (AWS Training & Certification), completed 2026-05-18. Next training due: 2027-05-18. Certificate on file with IMPOC.

3. Credential Management (DPP §1.4)

• All credentials stored in macOS Keychain (system-level AES-256 encrypted credential store, protected by macOS login + Touch ID).
• No plaintext secrets on disk or in version control. Pre-commit hooks block credential commits.
• Minimum 14-character passwords; no reuse of last 12 passwords; NIST SP 800-63B compliant.
• API keys and tokens stored as environment variables; never in source code.
• Amazon SP-API refresh tokens encrypted at rest using libsodium (AES-256-GCM).

4. Data Encryption (DPP §1.5)

• All data encrypted at rest using AES-256-GCM.
• All data in transit protected by TLS 1.3.
• PII (shipping addresses, buyer contact) stored in encrypted fields; never in logs.
• Database backups encrypted before storage.

5. Logging & Monitoring (DPP §2.6)

• All access to Amazon Information logged with user ID, timestamp, action, and outcome.
• PII excluded from application logs.
• CrowdSec console provides centralized log aggregation and automated alerting.
• Logs retained for 12 months minimum; reviewed bi-weekly.
• Security alerts reviewed within 24 hours of generation.

6. Vulnerability Management (DPP §2.7)

• Dependency vulnerability scans every 30 days (npm audit + Dependabot).
• SAST integrated into CI pipeline (pre-merge).
• Annual penetration test; critical findings remediated within 7 days, high within 30 days.
• OS and package security patches applied within 30 days of release; critical patches within 7 days.

7. Data Retention (DPP §1.7)

• PII (shipping addresses, buyer contact) retained for a maximum of 30 days after confirmed delivery, then permanently deleted or irreversibly anonymized.
• Non-PII order metadata (order IDs, amounts, SKUs) retained up to 5 years per Turkish Commercial Code (TTK Art. 82).
• No PII included in long-term records.

8. Multi-Tenant Architecture & Data Isolation

• Tenant identification: Each seller account is isolated by a unique tenant_id. All SP-API calls, refresh tokens, and cached data are tagged with tenant_id at every layer.
• Database isolation: PostgreSQL row-level security (RLS) policies enforce tenant boundaries at the database layer. Cross-tenant queries are blocked by the database; application-layer bugs cannot cause tenant data leakage.
• Per-tenant token storage: Each seller's Amazon refresh_token is encrypted with libsodium AES-256-GCM using tenant-specific key derivation. One tenant's token cannot be decrypted to access another tenant's account.
• Restricted Data Token (RDT) delegation: PII access is delegated to Shipentegra via RDT. PII is never persistently stored in Kayistra's infrastructure — it flows in-transit only from Amazon to Shipentegra.
• Tenant lifecycle: New tenant onboarding begins with the OAuth flow; an encrypted row is created the moment a refresh_token is issued. On offboarding, all tenant data (PII, tokens, cached orders) is permanently deleted within 30 days and the Amazon refresh_token is revoked.
• Per-tenant access logging: All SP-API calls are logged with tenant_id, timestamp, endpoint, and outcome. Logs are queryable per tenant; cross-tenant log aggregation is authorized to IMPOC only.
• Breach impact assessment: In the event of an incident, affected tenants are identified via tenant_id-based forensics. Breach notifications are sent only to affected sellers; other tenants are not impacted.
• Rate limiting per tenant: Token-bucket rate limiting is applied per tenant. One tenant's excessive API usage cannot affect the availability or performance of other tenants' operations.

9. Incident Response (DPP §1.6)

• Documented 6-phase incident response plan: Preparation, Detection, Containment, Eradication, Recovery, Post-Incident Review.
• IMPOC (Information Management Point of Contact): Mahmut Fuat Sahin, info@kayistra.com.
• Amazon notified within 24 hours of confirmed breach involving Amazon Information.
• Affected parties and authorities notified within 72 hours per applicable law.

10. Contact

Security inquiries and data requests:

Mahmut Fuat Sahin — IMPOC
Kayistra, Istanbul, Turkey
info@kayistra.com