1

So - I have been doing research regarding Salesforce platform encryption, and am struggling to find the actual "button pushing" steps to accomplish the BYOK plan. Please correct these following steps if I am misunderstanding:

  1. Key Management --> Bring Your Own Key --> then either Create CA-Signed Certificate or Create Self-Signed Certificate. Assuming I select Create CA-Signed Certificate, I enter the information to generate a unique certificate, I then go to the certificates list, and download certificate signing request and send it to my CA.

  2. Once I receive the signed certificate back, go back to Certificate and Key Management, click the name of the certificate, then click Upload Signed Certificate. I am getting this information Here, and this is where I begin to get confused. Do I need to upload this CA signed certificate to the Certificate and key management section, or do I take it, and use it to wrap an OpenSSL certificate, mentioned Here? , then upload it into the Key Management section

  3. .Assuming I Opt out of key derivation, do I have to repeat this process each time I rotate the keys?

Any guidance/insight anyone can provide will be greatly appreciated. This Information can also be found here: https://blog.bessereau.eu/assets/pdfs/salesforce_platform_encryption_implementation_guide.pdf

Improve this question

1 Answer 1

Reset to default
2

In step two you upload the signed cert to certificate and key management. You then need to take that certificate and use the public key to wrap the key material you wish to upload (which is not an OpenSSL certificate). On the page you linked to there's a link to a sample script we provided to illustrate the process of generating the key material and wrapping it for upload to Salesforce. You can find that script here.

If you choose to use BYOK, you will need to follow the process for generating key material and wrapping it with a public key from a certificate every time you rotate keys (regardless of whether you opt out of key derivation). If the certificate you created here is still valid, however, you can re-use the same certificate - it's not necessary to create a new certificate every time unless it is expired, revoked, or otherwise invalid.

Improve this answer
5
  • Hi John, thanks for the clarification. I misspoke earlier, I should have said a tenant secret that could be generated using OpenSSL, rather than an OpenSSL certificate
    – TestMcTesterson
    Commented Apr 10, 2019 at 18:58
  • As long as the encryption method(probabilistic/Deterministic) is the same, I would imagine the testing would yield the same impacts whether we had salesforce generate the secret, or we used BYOK. Is that the correct understanding? Thanks!!! @John
    – TestMcTesterson
    Commented Apr 15, 2019 at 13:51
  • Correct - same impact regardless of whether you use BYOK or salesforce generated keys. BYOK just gives you additional control over the key material.
    – John Whelan
    Commented Apr 15, 2019 at 16:52
  • Thanks @John! For testing purposes - if we follow this: trailhead.salesforce.com/en/content/learn/modules/spe_admins/…, do all we need to do is hit the generate tenant secret button, then choose fields to encrypt? That trailhead states "It’s as easy as that. Now you have a tenant secret that the Salesforce key management service can use to create the keys. Those keys encrypt and decrypt the clinic’s data." Is that something SF does in the background? Or does a similar secret wrapping effort need to occur? We are wanting to test the impacts on our test environment. Thanks for all the help!!!!
    – TestMcTesterson
    Commented Apr 15, 2019 at 17:02
  • 1
    Yeah, if you just want to test encryption impact then you can generate a tenant secret in salesforce and then set up your encryption policy . No need to do BYOK and the secret wrapping effort at that point, though you certainly could if you wanted.
    – John Whelan
    Commented Apr 15, 2019 at 18:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .