Fortanix generally does not recommend configuring a WAF with Self-Defending KMS. The Self-Defending KMS architecture ensures that sensitive information is always encrypted in transit (using TLS), and on the server-side, while stored and in use (using Fortanix Runtime Encryption® technology).
The vast majority of WAF features require decrypting the TLS traffic in transit, which would potentially expose key material and sensitive plaintext. Configuring a WAF with Fortanix Self-Defending KMS results in the following limitations:
- Sensitive data may be leaked:
- Data, such as the input to encrypt, sign and verify operations, and the output to decrypt operations.
- Imported and exported key material.
- No support from Fortanix:
- The Fortanix Quality Assurance team does not test software releases with WAF configuration, including releases providing urgent security updates.
- The Fortanix Customer Success team cannot help in designing or configuring a system that includes a WAF.
- The current or future functionality of Fortanix Self-Defending KMS may be degraded or non-functional, including but not limited to:
- Audit logs will show an incorrect source IP address.
- Apps cannot use certificate-based authentication (mutual TLS), including KMIP.
Instead of relying on heuristic rules such as those normally implemented by WAFs, Fortanix prefers to implement security by eliminating exploitation points in our architecture. For example, Fortanix mitigates the following common web application issues:
- Database queries: The Self-Defending KMS backend only uses parameterized queries.
- Command injection: The Self-Defending KMS backend environment can't execute processes.
- XSS Prevention: The Self-Defending KMS backend generally doesn't render HTML pages.
- HTTP processing: The Self-Defending KMS backend relies on Rust's memory- and type-safety to parse and interpret untrusted input.
Firewalls or other network security tools that only operate on Layer 4 and below may be configured for use with Self-Defending KMS.