Bring Your Own Key (BYOK) encryption for Confluence is now available

[Ashwini Rattihalli]

We are thrilled to announce that Bring Your Own Key (BYOK) encryption for Confluence is now available to all customers with Enterprise plans.

For customers who need to implement BYOK encryption, the Atlassian BYOK encryption program allows you to utilize your own key space for encrypting and decrypting data at rest. This empowers you with increased control, ensuring greater confidence in meeting necessary compliance or security standards.

To get started with BYOK encryption, please reach out to your account representative.

Beyond the initial general availability scope, our team is dedicated to advancing our BYOK encryption journey and delivering additional data protection benefits to our customers. We encourage you to share your BYOK security guidelines with us for consideration in our future roadmap.

To learn more, please refer to our BYOK encryption documentation. If you have any further questions, please leave a comment below.

Cheers

Ashwini

[Jim Knepley - ReleaseTEAM]

Related to the BYOK encryption announcement for Jira in October 2023, and my related question, the Confluence implementation seems similar to the Jira implementation in that the CloudFormation template doesn't include encryption or decryption operations.

Does anyone have details about how this feature is implemented on either platform? 

[Hui Ren]

Jim - Thanks for the question. IAM role in the template essentially allows to create grant operations including encryption and decryption.

To the earlier question where you linked, Atlassian does not and cannot import master key materials from AWS KMS. By AWS design, master keys will never leave KMS, and its key material is never exposed in plaintext.

[Jim Knepley - ReleaseTEAM]

Thanks for the explanation @Hui Ren

I see that "kms:Create*" covers the CreateGrant operation, which can grant Decrypt and Encrypt operations. Can you go into some detail about when those operations are performed since KMS is a paid service?

Does Atlassian recommend any specific practices to have the atlassian-key-management-access policy apply to more specific resources than "*" ?

[Hui Ren]

@Jim Knepley - ReleaseTEAM 

"Can you go into some detail about when those operations are performed since KMS is a paid service?"

- There are multiple aspects to your question. If you are inquiring about the timing of these operations, it’s possible that you are interested in understanding how Atlassian encryption works. For an overview of Atlassian Cryptor and its default encryption in Atlassian Cloud with Atlassian’s KMS account, you may find this engineering blog helpful (see reference links below). It is worth noting that the same underlying implementation also supports BYOK encryption using a specific customer’s KMS account.

- As for KMS being a paid service, if you are referring to potential billing implications for customers, it’s important to note that customers will be billed based on the number of keys stored, while API requests are billed to the API requestor - in this case, Atlassian.

"have the atlassian-key-management-access policy apply to more specific resources than "*" "

- The existing policy needs to be incorporated as specified in the template for the Atlassian BYOK solution to facilitate operations.

- In line with this, the Atlassian Encryption Pillar team is actively developing a more restrictive key model, which is in its early stages of development. If you are interested, we encourage you to get in touch with your Atlassian contact to arrange a technical deep dive if necessary.

References:

1. https://www.atlassian.com/engineering/multi-region-kms-encryption-at-scale
2. https://support.atlassian.com/security-and-access-policies/docs/set-up-an-aws-account-and-create-iam-roles/#Expected-AWS-costs
3. https://aws.amazon.com/kms/pricing/

[Jim Knepley - ReleaseTEAM]

"API requests are billed to the API requestor - in this case, Atlassian."

Ah, there it is in the documentation "note 2". Thank you for reiterating.