Access and availability
- Which Jamf products support BYOK?
- BYOK is currently supported in Jamf Pro and the declarative storage service.
- Can Jamf employees see my data?
- No. Although Jamf applications can view and operate on your data, Jamf employees cannot read the data in its unencrypted state. Additionally, Jamf employees do not have access to the credentials provided that are used to interact with your encryption key.
- What regions is BYOK available in?
- BYOK is currently available in the United States and Canada.
Encryption and architecture
- How does BYOK encrypt my data?
BYOK uses a per-tenant key. When BYOK is enabled:
Application data is encrypted using a randomly generated Data Encryption Key (DEK).
The DEK is encrypted using your intermediate Leased Key (LK), which is encrypted with your key, producing an Encrypted DEK (EDEK).
The EDEK is stored alongside the encrypted data. It cannot be decrypted without interacting with your KMS.
Encryption cannot be applied at different levels of granularity. See Database Encryption in the Jamf Pro Security Overview.
- Is there a diagram of the BYOK architecture?
- The following diagram illustrates how Jamf interacts with your KMS to enable application-layer encryption in a typical BYOK implementation:
Key management
- Does Jamf host a KMS or HSM for BYOK?
- No. Jamf does not host its own KMS or HSM for BYOK.
- Does BYOK support automatic key rotation?
- Yes. You can configure an automatic key rotation schedule in your KMS.
Performance and availability
- What is key leasing and how does it work?
To reduce latency and improve availability, Jamf uses a technique called key leasing rather than calling your KMS for every encryption or decryption operation. Key leasing is required to ensure system performance and stability and also reduces the number of direct calls to your KMS.
Key leasing works as follows:
A Tenant Security Proxy (TSP) creates an intermediate Leased Key (LK) that is encrypted by your KMS.
The LK is used to wrap and unwrap DEKs for a limited period of time.
Decrypted LKs are cached in protected memory on secure machines for up to four hours, with your KMS checked at least every ten minutes to confirm the key is still authorized.
If a KMS check fails, all cached LKs associated with your key are dropped from memory immediately, which automatically revokes Jamf's application access to your data.
- How does BYOK impact performance?
- Impact to performance is negligible. Because of key leasing, decryption occurs locally using cached keys rather than requiring a call to your KMS for every operation.
- What happens if the connection to my KMS goes down?
- Key leases are cached for up to four hours with revocation checks every ten minutes. A sustained outage between Jamf Cloud and your KMS would need to last over four hours before impacting service availability.
Auditing
- How can I monitor access to my encryption keys?
You have two ways to monitor access to your encryption keys:
- KMS access logs
- Use the native access logs provided by your KMS to track all requests made to your key.
- Real-time security events
- Configure Jamf to push detailed audit trails to your logging or SIEM system in near real-time. These events include metadata about each request, such as the user or service making the request and the type of data being accessed. This provides significantly more detail than KMS logs alone, giving your SIEM richer information for detecting anomalous behavior and supporting compliance requirements. Supported log destinations include Splunk and GCP Stackdriver.
Third-party integration
- Does Jamf use a third-party vendor for BYOK?
Jamf uses a specialized third-party vendor, IronCore Labs, to power the BYOK feature. This approach provides the following advantages:
A single point of integration that abstracts the complexity of individual KMS APIs
Independently audited, security-focused implementation
Ability to adapt to evolving cloud security standards and regulations
The vendor never has access to your unencrypted keys, credentials, or data. All encryption and decryption occurs in Jamf's infrastructure or, for configuration credentials, in your web browser.