Cuando usas S3 SSE, cualquier persona con las credenciales IAM adecuadas puede leer y / o escribir tus objetos S3, como si no estuvieras usando SSE. A primera vista, parece que el único beneficio adicional es que los datos están protegidos de situaciones en las que alguien obtiene acceso a S3 de forma desconectada, como unidades de disco o copias de seguridad (lo cual dudo que haga AWS, es mucho más probable que confíen en) sólo replicación). Sin embargo, creo que necesita compararlo con la alternativa para obtener los beneficios reales:
Hay dos componentes necesarios para el cifrado del lado del cliente con S3: una clave de cifrado y credenciales IAM para la autenticación y autorización. Cuando utilice el cifrado del lado del servidor, solo necesita las credenciales IAM.
Al usar el cifrado del lado del cliente, debe distribuir la clave de cifrado a todas las máquinas que tengan acceso de lectura y escritura a los datos cifrados en S3. En ambos casos, también debe distribuir las credenciales de IAM.
Si sus máquinas están comprometidas, su clave de cifrado está comprometida. Puede invalidar las credenciales de IAM tan pronto como sepa de la interrupción, y si usa roles de IAM o credenciales de IAM temporales, el atacante solo tendrá acceso a sus datos siempre que tengan el control de la máquina (lo que es suficientemente malo, pero Puede que no sea el fin del mundo, también debes pensar en lo que sucederá a continuación. Con el cifrado del lado del cliente, el atacante tendrá su clave de cifrado, y todos los datos cifrados con la clave de cifrado comprometida deben volver a cifrarse. Con el cifrado del lado del servidor, no tendrá que volver a cifrar sus datos, ya que ni usted ni el atacante tendrán la clave de cifrado.
Incluso si no tiene una interrupción, hay situaciones en las que su clave de cifrado puede verse comprometida, si se pierde o le roban una computadora portátil, si alguien que no sabe mejor se la envía por correo electrónico a alguien o si alguien deja de fumar y no puedes estar completamente seguro de que no se llevaron cosas con ellos. En este punto, su clave de cifrado está comprometida y probablemente debería volver a cifrar todos sus datos. Eso puede ser mucho trabajo. Con el cifrado del lado del servidor, todo lo que tiene que hacer es invalidar las credenciales de IAM y emitir nuevas.
Probablemente hay maneras de mitigar los problemas con el cifrado del lado del cliente que he mencionado anteriormente, pero para mí es como si usar SSE con S3 tenga menos inconvenientes que administrarlo usted mismo.
Finalmente, está el problema de lo seguro que es permitir que AWS administre sus claves de cifrado:
Según AWS, el sistema que administra las claves de cifrado es independiente de S3, con la intención de que si alguien ingresa al S3 desde el exterior no obtendrá sus datos porque no tendrán las claves de cifrado. Si se introducen solo en el sistema de administración de claves (al que probablemente no se puede acceder directamente desde el exterior), no tendrán sus datos porque no tienen acceso a ellos en S3. Deben entrar en ambos S3 y el sistema de administración de claves para obtener sus datos.
Si, por el contrario, ingresan al centro de datos físico, podrían obtener acceso al sistema de administración de claves y al S3 al mismo tiempo, pero la pregunta es si esto facilita las cosas o no. Creo que primero debemos confiar en que AWS tiene implementadas las medidas de seguridad adecuadas para impedir que las personas ingresen a sus centros de datos y, en segundo lugar, que para obtener las claves del sistema de administración de claves, tendría que hacer algo más que simplemente jala algunas unidades de disco. Por lo que he visto, AWS no publica exactamente cómo se protege el sistema de administración de claves, más que decir que está protegido con varias capas de seguridad. Es una especulación, pero el cifrado del disco es probablemente uno de estos.