Aplicar procedimientos recomendados de seguridad para Azure Storage

  • 8 minutos

Hemos revisado cómo crear y trabajar con una firma de acceso compartido (SAS) y las ventajas que puede proporcionar a la solución de seguridad de almacenamiento.

Es importante comprender que, al usar una SAS en la aplicación, puede haber riesgos potenciales.

  • Si una SAS está en peligro, cualquier persona que la obtenga puede acceder al almacenamiento.

  • Si una SAS proporcionada para una aplicación cliente expira y la aplicación no puede recuperar una nueva SAS del servicio, la funcionalidad de la aplicación puede verse afectada.

Vea este vídeo para obtener más ideas sobre cómo proteger el almacenamiento. Este vídeo se basa en Sugerencias y trucos de Azure #272: Procedimientos recomendados de seguridad de Azure.

Recomendaciones para administrar riesgos

Echemos un vistazo a algunas recomendaciones que pueden ayudar a mitigar los riesgos al trabajar con una SAS.

Recomendación Descripción
Uso siempre de HTTPS para la creación y distribución Si se pasa una SAS a través de HTTP, un atacante podría interceptarla y usarla. Estos ataques de tipo Man in the middle pueden poner en peligro los datos confidenciales o permitir que un usuario malintencionado dañe los datos.
Haga referencia a las directivas de acceso almacenadas cuando sea posible. Las directivas de acceso almacenadas le ofrecen la posibilidad de revocar permisos sin tener que volver a generar las claves de cuenta de almacenamiento. Establezca una fecha de expiración futura para la clave de la cuenta de almacenamiento.
Establecer tiempos de expiración a corto plazo para una SAS no planeada Si una SAS está en peligro, puede mitigar los ataques limitando la validez de SAS a un breve tiempo. Este procedimiento es importante si no puede hacer referencia a una directiva de acceso almacenada. Las expiraciones a corto plazo también limitan la cantidad de datos que puede escribirse en un blob mediante la limitación del tiempo disponible para cargarlos.
Requerir que los clientes renueven automáticamente la SAS. Requiera a los clientes que renueven la SAS antes de la fecha de expiración. Al renovar anticipadamente, da margen para diversos reintentos si el servicio que proporciona la SAS no está disponible.
Planear cuidadosamente la hora de inicio de SAS Si establece la hora de inicio de la SAS en ahora, pueden producirse errores intermitentes durante los primeros minutos debido al sesgo del reloj (diferencias en la hora actual según las distintas máquinas). En general, establezca la hora de inicio sea al menos 15 minutos en el pasado. O bien, no establezca una hora de inicio específica, lo que hace que la SAS sea válida inmediatamente en todos los casos. Las mismas condiciones se aplican generalmente a la hora de expiración. Puede observar hasta 15 minutos de sesgo del reloj en cualquier dirección de cualquier solicitud. Para los clientes con una versión API REST anterior a 2012-02-12, la duración máxima de una SAS que no hace referencia a una directiva de acceso almacenada es de 1 hora. Se produce un error en las directivas que especifican un período más largo.
Definir los permisos de acceso de los recursos Un procedimiento recomendado de seguridad es proporcionar al usuario los privilegios mínimos necesarios. Si un usuario solo necesita acceso de lectura en una única entidad, concédale acceso de lectura a esa única entidad y no acceso de lectura, escritura o eliminación a todas las entidades. Esta práctica también ayuda a reducir los daños si se pone en peligro una SAS porque esta tiene menos poder en manos de un atacante.
Descripción de la facturación de la cuenta para el uso, incluida una SAS Proporcione permisos limitados para ayudar a mitigar acciones potenciales de usuarios malintencionados. Los permisos de lectura y escritura pueden provocar cargos de facturación. Use una SAS de corta duración para reducir esta amenaza.
Validar los datos escritos mediante una SAS Cuando una aplicación cliente escribe datos en la cuenta de almacenamiento de Azure, tenga en cuenta que pueden existir problemas con esos datos. Si la aplicación requiere datos validados o autorizados, valide los datos después de escribirlos, pero antes de usarlos. Esta práctica también le protege frente a los datos erróneos o malintencionados que se escriben en la cuenta, ya sea mediante un usuario que adquirió correctamente la SAS o un usuario que aproveche una SAS errónea.
No dar por sentado que una SAS siempre será la opción correcta En algunas ocasiones, los riesgos asociados a una operación determinada en la cuenta de almacenamiento superan las ventajas del uso de una SAS. Para esas operaciones, cree un servicio de nivel medio que escriba en la cuenta de almacenamiento después de llevar a cabo una auditoría, autenticación o validación de la regla de negocio. A veces también es más sencillo administrar el acceso de otras formas. Si desea que todos los blobs de un contenedor puedan leerse públicamente, puede hacer que el contenedor sea público en lugar de proporcionar un SAS a cada cliente para obtener acceso.
Supervisar las aplicaciones con Azure Storage Analytics Puede usar el registro y las métricas para observar cualquier pico en los errores de autenticación. Es posible que vea picos de una interrupción en el servicio del proveedor de SAS o la eliminación involuntaria de una directiva de acceso almacenada.