amazon-s3 - servidor - tipos de almacenamiento s3
Problemas con la polĂtica del cubo de cifrado del lado del servidor de Amazon S3 (1)
En mi humilde opinión, no hay manera de decirle automáticamente a Amazon S3 que active la SSE para cada solicitud de PUT. Entonces, lo que investigaría es lo siguiente:
escribe una secuencia de comandos que enumera tu cubo
para cada objeto, obtenga los metadatos
si la SSE no está habilitada, use la API PUT COPY ( http://docs.aws.amazon.com/AmazonS3/latest/API/RESTObjectCOPY.html ) para agregar SSE "(...) Al copiar un objeto, puede preservar la mayoría de los metadatos (por defecto) o especificar nuevos metadatos (...) "
Si la operación PUT tuvo éxito, use la API DELETE del objeto para eliminar el objeto original
Luego ejecute ese script cada hora o diariamente, dependiendo de los requisitos de su negocio. Puede usar la API S3 en Python ( http://boto.readthedocs.org/en/latest/ref/s3.html ) para que sea más fácil escribir la secuencia de comandos.
Si esta solución de "cambiar después de escribir" no es válida para usted, puede trabajar a diferentes niveles
utilice un proxy entre su cliente API y la API S3 (como un proxy inverso en su sitio) y configúrelo para agregar el encabezado HTTP SSE para cada solicitud PUT / POST. El desarrollador debe pasar por el proxy y no estar autorizado para emitir solicitudes contra los puntos finales de la API S3
escriba una biblioteca contenedora para agregar los metadatos SSE automáticamente y obligue al desarrollador a usar su biblioteca sobre el SDK.
Los últimos días son una cuestión de disciplina en la organización, ya que no es fácil hacerlos cumplir a nivel técnico.
Seb
Estoy usando una política de depósito que niega cualquier comunicación que no sea SSL y UnEncryptedObjectUploads.
{
"Id": "Policy1361300844915",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyUnSecureCommunications",
"Action": "s3:*",
"Effect": "Deny",
"Resource": "arn:aws:s3:::my-bucket",
"Condition": {
"Bool": {
"aws:SecureTransport": false
}
},
"Principal": {
"AWS": "*"
}
},
{
"Sid": "DenyUnEncryptedObjectUploads",
"Action": "s3:PutObject",
"Effect": "Deny",
"Resource": "arn:aws:s3:::my-bucket/*",
"Condition": {
"StringNotEquals": {
"s3:x-amz-server-side-encryption": "AES256"
}
},
"Principal": {
"AWS": "*"
}
}
]
}
Esta política funciona para aplicaciones que admiten configuraciones SSL y SSE, pero solo para los objetos que se cargan.
Me encontré con estos problemas:
- CloudBerry Explorer y S3 Browser fallaron durante las carpetas y archivos RENAME en el depósito con esa Política de depósito. Después de aplicar solo el requisito de SSL en la política de depósito, esos navegadores completaron con éxito el cambio de nombre de archivo / carpeta.
CloudBerry Explorer fue capaz de RENOMBRAR objetos con la política completa de cubo SSL / SSE solo después de habilitar en Opciones - Amazon S3 Copiar / Mover a través de la computadora local (más lento y cuesta dinero).
Todo copiar / mover dentro de Amazon S3 falló debido a esa política restrictiva.
Eso significa que no podemos controlar el proceso de copiar / mover que no se origina en la aplicación que manipula los objetos locales. Al menos las Opciones de CloudBerry mencionadas anteriormente lo demostraron.
Pero podría estar equivocado, es por eso que estoy publicando esta pregunta.
- En mi caso, con esa política de cubo habilitada, S3 Management Console se vuelve inútil. Los usuarios no pueden crear carpetas, eliminarlas, lo que pueden es solo cargar archivos.
¿Hay algún problema con mi política de depósito? No conozco los mecanismos de Amazon S3 que se usan para manipular objetos.
¿Amazon S3 trata las solicitudes externas (encabezados API / http) y las solicitudes internas de forma diferente?
¿Es posible aplicar esta política solo a las cargas y no a Amazon S3 GET / PUT interno, etc.? He intentado http referer con la URL del cubo en vano.
La política de depósito con requisitos de SSL / SSE es obligatoria para mi implementación.
Cualquier idea sería apreciada.
Gracias de antemano.