chibenwa commented on code in PR #2505: URL: https://github.com/apache/james-project/pull/2505#discussion_r1858204354
########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. Review Comment: ```suggestion To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. Moreover it pushes synchronous concepts like `InputStream` into an otherwize reactive interface. ``` ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. Review Comment: "the team" have no meaning in an ASF context. Prefer using "we". ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. + +## Decision + +Integrate SSE-C with S3 Object Storage in Apache James to improve user data security. +James will manage the master key and salt, using them to create customer keys when calling S3 APIs, such as PUT, GET, and HEAD on objects. + +Two approaches are proposed for providing the customer key: + +1. Single customer key: A single master key and salt will be used across all objects in the system. These values will be configured in the configuration file, similar to the current `AESBlobStoreDAO` approach. + +2. Derived customer key: A more secure option where the master key and salt are dynamic, based on the bucketName and blobId. This approach generates a unique customer key for each different blobId, enhancing security. However, it also has a higher CPU resource impact and depends on the configured key generation algorithm. + +The current library (`awssdk s3`), fully supports the required APIs for this feature, enabling seamless integration of SSE-C without any compatibility issues. + +Enabling SSE-C is fully optional. By default, it is disabled and requires configuration changes to activate, allowing users to retain their existing configuration without enabling SSE-C automatically. + +## Consequences + +### Benefits + +- Performance Improvement: SSE-C takes advantage of S3’s security capabilities without taxing James’s CPU. +- Security: Provides robust security without fully shifting encryption to the client or to S3 alone. + +### Limitations + +- Incompatibility with Deduplication feature. +- Data Migration Challenges: Currently, S3 APIs do not support migrating encrypted data from AESBlobStoreDAO (client-side encryption) to the new SSE-C endpoint. +- Replication: SSE-C does not support bucket replication. Review Comment: Is this always true? I suspect this might only be an OVH limitation... ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. + +## Decision + +Integrate SSE-C with S3 Object Storage in Apache James to improve user data security. +James will manage the master key and salt, using them to create customer keys when calling S3 APIs, such as PUT, GET, and HEAD on objects. + +Two approaches are proposed for providing the customer key: + +1. Single customer key: A single master key and salt will be used across all objects in the system. These values will be configured in the configuration file, similar to the current `AESBlobStoreDAO` approach. + +2. Derived customer key: A more secure option where the master key and salt are dynamic, based on the bucketName and blobId. This approach generates a unique customer key for each different blobId, enhancing security. However, it also has a higher CPU resource impact and depends on the configured key generation algorithm. + +The current library (`awssdk s3`), fully supports the required APIs for this feature, enabling seamless integration of SSE-C without any compatibility issues. + +Enabling SSE-C is fully optional. By default, it is disabled and requires configuration changes to activate, allowing users to retain their existing configuration without enabling SSE-C automatically. + +## Consequences + +### Benefits + +- Performance Improvement: SSE-C takes advantage of S3’s security capabilities without taxing James’s CPU. Review Comment: Have that been measured? ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. + +## Decision + +Integrate SSE-C with S3 Object Storage in Apache James to improve user data security. +James will manage the master key and salt, using them to create customer keys when calling S3 APIs, such as PUT, GET, and HEAD on objects. + +Two approaches are proposed for providing the customer key: + +1. Single customer key: A single master key and salt will be used across all objects in the system. These values will be configured in the configuration file, similar to the current `AESBlobStoreDAO` approach. + +2. Derived customer key: A more secure option where the master key and salt are dynamic, based on the bucketName and blobId. This approach generates a unique customer key for each different blobId, enhancing security. However, it also has a higher CPU resource impact and depends on the configured key generation algorithm. + +The current library (`awssdk s3`), fully supports the required APIs for this feature, enabling seamless integration of SSE-C without any compatibility issues. + +Enabling SSE-C is fully optional. By default, it is disabled and requires configuration changes to activate, allowing users to retain their existing configuration without enabling SSE-C automatically. + +## Consequences + +### Benefits + +- Performance Improvement: SSE-C takes advantage of S3’s security capabilities without taxing James’s CPU. +- Security: Provides robust security without fully shifting encryption to the client or to S3 alone. + +### Limitations + +- Incompatibility with Deduplication feature. +- Data Migration Challenges: Currently, S3 APIs do not support migrating encrypted data from AESBlobStoreDAO (client-side encryption) to the new SSE-C endpoint. +- Replication: SSE-C does not support bucket replication. +- SSE-C is less secure than AESBlobStoreDAO (Client-Side Encryption). Review Comment: Explain why! ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. + +## Decision + +Integrate SSE-C with S3 Object Storage in Apache James to improve user data security. +James will manage the master key and salt, using them to create customer keys when calling S3 APIs, such as PUT, GET, and HEAD on objects. + +Two approaches are proposed for providing the customer key: + +1. Single customer key: A single master key and salt will be used across all objects in the system. These values will be configured in the configuration file, similar to the current `AESBlobStoreDAO` approach. + +2. Derived customer key: A more secure option where the master key and salt are dynamic, based on the bucketName and blobId. This approach generates a unique customer key for each different blobId, enhancing security. However, it also has a higher CPU resource impact and depends on the configured key generation algorithm. Review Comment: Make it an interface to allow other possible implementations of salt / key derivation? ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. Review Comment: I expect the context to explain in ~1 line what is SSEC. > the team has decided This is the decision. Move it. > This will allow ... And this repeats impact ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. + +## Decision + +Integrate SSE-C with S3 Object Storage in Apache James to improve user data security. +James will manage the master key and salt, using them to create customer keys when calling S3 APIs, such as PUT, GET, and HEAD on objects. + +Two approaches are proposed for providing the customer key: + +1. Single customer key: A single master key and salt will be used across all objects in the system. These values will be configured in the configuration file, similar to the current `AESBlobStoreDAO` approach. + +2. Derived customer key: A more secure option where the master key and salt are dynamic, based on the bucketName and blobId. This approach generates a unique customer key for each different blobId, enhancing security. However, it also has a higher CPU resource impact and depends on the configured key generation algorithm. + +The current library (`awssdk s3`), fully supports the required APIs for this feature, enabling seamless integration of SSE-C without any compatibility issues. + +Enabling SSE-C is fully optional. By default, it is disabled and requires configuration changes to activate, allowing users to retain their existing configuration without enabling SSE-C automatically. + +## Consequences + +### Benefits + +- Performance Improvement: SSE-C takes advantage of S3’s security capabilities without taxing James’s CPU. +- Security: Provides robust security without fully shifting encryption to the client or to S3 alone. + +### Limitations + +- Incompatibility with Deduplication feature. Review Comment: No, this is only incompatible if input of the derivation are not function of the content. Here that's not the case. This is the case only when the key derivation is factor of the domain. ########## src/adr/0071-objectstorage-sse-c.md: ########## @@ -0,0 +1,50 @@ +# 71. SSE-C for S3 Object Storage + +Date: 2024-11-15 + +## Status + +Accepted (lazy consensus) + +## Context + +To enhance data security for users, Apache James currently supports client-side encryption through AESBlobStoreDAO. However, this solution consumes significant CPU resources for encryption and decryption, impacting overall system performance. + +To provide a more efficient encryption option, the team has decided to integrate Server-Side Encryption with Customer-provided keys (SSE-C) for S3 Object Storage. This will allow for enhanced security with optimized performance. SSE-C provides high-level security without the CPU overhead experienced with client-side encryption in James. + +## Decision + +Integrate SSE-C with S3 Object Storage in Apache James to improve user data security. +James will manage the master key and salt, using them to create customer keys when calling S3 APIs, such as PUT, GET, and HEAD on objects. + +Two approaches are proposed for providing the customer key: + +1. Single customer key: A single master key and salt will be used across all objects in the system. These values will be configured in the configuration file, similar to the current `AESBlobStoreDAO` approach. + +2. Derived customer key: A more secure option where the master key and salt are dynamic, based on the bucketName and blobId. This approach generates a unique customer key for each different blobId, enhancing security. However, it also has a higher CPU resource impact and depends on the configured key generation algorithm. + +The current library (`awssdk s3`), fully supports the required APIs for this feature, enabling seamless integration of SSE-C without any compatibility issues. + +Enabling SSE-C is fully optional. By default, it is disabled and requires configuration changes to activate, allowing users to retain their existing configuration without enabling SSE-C automatically. + +## Consequences + +### Benefits + +- Performance Improvement: SSE-C takes advantage of S3’s security capabilities without taxing James’s CPU. +- Security: Provides robust security without fully shifting encryption to the client or to S3 alone. + +### Limitations + +- Incompatibility with Deduplication feature. +- Data Migration Challenges: Currently, S3 APIs do not support migrating encrypted data from AESBlobStoreDAO (client-side encryption) to the new SSE-C endpoint. +- Replication: SSE-C does not support bucket replication. +- SSE-C is less secure than AESBlobStoreDAO (Client-Side Encryption). + +## Alternatives + +- Continue using client-side encryption with AESBlobStoreDAO. +- Using SSE-S3 (Server-Side Encryption with S3-managed keys) for enhanced security without the need for client-side management. Review Comment: How is this defferent from SSEC? Why does it make it more secure? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@james.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@james.apache.org For additional commands, e-mail: notifications-h...@james.apache.org
