Hardened Zero-Trust WordPress Server
Budget: €250 – €750 EUR
I’m standing up a brand-new WordPress box on a Linux host and need it architected from day one around a strict zero-trust stance—even the hypervisor or hosting provider must be treated as hostile.
Here is the baseline I need you to hit:
• Full-disk encryption with LUKS configured during provisioning, unlocking only through a self-hosted key management system that lives off–box (no cloud “managed” services, no HSM rental).
• The key workflow must survive reboots without ever storing secrets locally and still allow automated patching and recovery.
• WordPress itself should sit behind hardened nginx/Apache, with minimum required PHP modules, file-system permissions locked down, and Web Application Firewall rules tuned for the CMS.
• Sensitive portions of the MySQL/MariaDB database (user PII, order tables, etc.) plus audit logs must stay encrypted at runtime—either via native TDE, per-column AES functions, or another approach you can justify—without breaking core WordPress functions or plugins.
• Syslog, access logs, and wp-debug output should pipe through encrypted channels then vault off-box so root on the host still can’t read them.
• Provide Infrastructure-as-Code (Ansible, Terraform or similar) so I can recreate the stack, plus clear operational runbooks for key rotation, disaster recovery, and routine WordPress updates.
I’ll want a brief architecture diagram up front, then staged milestones: 1) base image with LUKS + remote unlock, 2) hardening & WordPress install, 3) runtime data/log encryption layer, 4) documentation and hand-off.
If you have proven experience deploying encrypted Linux servers and locking down WordPress in hostile environments, outline your plan of attack and the tools you’ll use.
Here is the baseline I need you to hit:
• Full-disk encryption with LUKS configured during provisioning, unlocking only through a self-hosted key management system that lives off–box (no cloud “managed” services, no HSM rental).
• The key workflow must survive reboots without ever storing secrets locally and still allow automated patching and recovery.
• WordPress itself should sit behind hardened nginx/Apache, with minimum required PHP modules, file-system permissions locked down, and Web Application Firewall rules tuned for the CMS.
• Sensitive portions of the MySQL/MariaDB database (user PII, order tables, etc.) plus audit logs must stay encrypted at runtime—either via native TDE, per-column AES functions, or another approach you can justify—without breaking core WordPress functions or plugins.
• Syslog, access logs, and wp-debug output should pipe through encrypted channels then vault off-box so root on the host still can’t read them.
• Provide Infrastructure-as-Code (Ansible, Terraform or similar) so I can recreate the stack, plus clear operational runbooks for key rotation, disaster recovery, and routine WordPress updates.
I’ll want a brief architecture diagram up front, then staged milestones: 1) base image with LUKS + remote unlock, 2) hardening & WordPress install, 3) runtime data/log encryption layer, 4) documentation and hand-off.
If you have proven experience deploying encrypted Linux servers and locking down WordPress in hostile environments, outline your plan of attack and the tools you’ll use.