Los servicios en la nube suelen utilizar técnicas como el almacenamiento en caché, la replicación y el equilibrio de carga para facilitar la escalabilidad del servicio, entregar contenido más rápido y mitigar el impacto de los ataques volumétricos. Las funciones de disponibilidad deshabilitadas o mal configuradas degradan el rendimiento del servicio, pero los efectos inmediatos a menudo no son evidentes hasta que ocurren eventos extremos, como picos de tráfico y errores de hardware.

Los servicios en la nube suelen utilizar técnicas como el almacenamiento en caché, la replicación y el equilibrio de carga para facilitar la escalabilidad del servicio, entregar contenido más rápido y mitigar el impacto de los ataques volumétricos. Las funciones de disponibilidad deshabilitadas o mal configuradas degradan el rendimiento del servicio, pero los efectos inmediatos a menudo no son evidentes hasta que ocurren eventos extremos, como picos de tráfico y errores de hardware.

Los servicios en la nube suelen utilizar técnicas como el almacenamiento en caché, la replicación y el equilibrio de carga para facilitar la escalabilidad del servicio, entregar contenido más rápido y mitigar el impacto de los ataques volumétricos. Las funciones de disponibilidad deshabilitadas o mal configuradas degradan el rendimiento del servicio, pero los efectos inmediatos a menudo no son evidentes hasta que ocurren eventos extremos, como picos de tráfico y errores de hardware.

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

De forma predeterminada, AWS utiliza claves administradas por AWS para cifrar datos en reposo si el cifrado está habilitado. Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Tenga en cuenta que las claves con el formato aws/service-name están reservadas para las claves administradas por AWS.

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

De forma predeterminada, AWS utiliza claves administradas por AWS para cifrar datos en reposo si el cifrado está habilitado. Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Tenga en cuenta que las claves con el formato aws/service-name están reservadas para las claves administradas por AWS.

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

De forma predeterminada, AWS utiliza claves administradas por AWS para cifrar datos en reposo si el cifrado está habilitado. Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Tenga en cuenta que las claves con el formato aws/service-name están reservadas para las claves administradas por AWS.

Las claves administradas por el cliente no se utilizan para cifrar datos en reposo.

De forma predeterminada, AWS utiliza claves administradas por AWS para cifrar datos en reposo si el cifrado está habilitado. Las claves administradas por el cliente permiten a las organizaciones usar claves criptográficas de su elección para cifrar datos. Esto brinda a las organizaciones un mejor control y registro de los procesos de cifrado.

De este modo, las claves administradas por el cliente suelen ser parte de la solución para satisfacer requisitos que incluyen, entre otros:
- Registros de auditoría para el acceso a datos confidenciales
- Residencia de datos
- Reemplazo, deshabilitación o destrucción de claves

Tenga en cuenta que las claves con el formato aws/service-name están reservadas para las claves administradas por AWS.

Los mecanismos de autenticación débiles exponen a las organizaciones a accesos no autorizados.

Los mecanismos de autenticación pueden fallar por varias razones, tales como:
- Contraseñas débiles
- Validación incorrecta
- Gestión de credenciales débiles

La autenticación es un aspecto esencial de la seguridad. La fiabilidad del proceso de autenticación depende de la seguridad y solidez de las credenciales de inicio de sesión. Las políticas de contraseñas que garantizan que los usuarios creen contraseñas seguras son cruciales para implementar sitios web seguros. La seguridad de la contraseña es una medida de la eficacia que proporciona para resistir ante posibles ataques de adivinación y de fuerza bruta. Algunos parámetros que ayudan a definir la seguridad de la contraseña incluyen características de contraseña como la longitud, la complejidad y la aleatoriedad de la contraseña.

Apache Axis 2 proporciona a los desarrolladores una utilidad para supervisar los mensajes SOAP entrantes y salientes mediante un applet de Java. SOAP Monitor mostrará todos los mensajes SOAP utilizados para invocar un servicio web. Los atacantes pueden emplear la utilidad para espiar el tráfico entre un servicio web y sus clientes.

Si un servicio retransmite mensajes a otros servicios, los mensajes se exponen al mecanismo de transporte más débil utilizado entre los puntos de retransmisión. REST por sí solo no incluye ningún mecanismo de seguridad, por lo que la integridad y confidencialidad de los mensajes depende de la capa de transporte.

La siguiente configuración habilita REST:

<axisconfig name="AxisJava2.0">
...
    <parameter name="disableREST" locked="true">false</parameter>
...
</axisconfig>

WS-Security es una mejora de SOAP que proporciona integridad y confidencialidad de los mensajes de un extremo a otro, independientemente del protocolo de transporte. Cuando no se utiliza WS-Security, la integridad y confidencialidad de los mensajes dependen de la seguridad del transporte. Si un servicio retransmite mensajes a otros servicios, los mensajes se exponen al mecanismo de transporte más débil utilizado entre los puntos de retransmisión. WS-Security elimina la dependencia de la seguridad del transporte y protege el mensaje en sí.

La ausencia de un parámetro InflowSecurity en el archivo de configuración de Apache Axis 2 indica que la seguridad de los mensajes entrantes no está habilitada.

La siguiente configuración de Apache Axis 2 Rampart no requiere el cifrado de mensajes entrantes debido a que la etiqueta <items> no contiene una directiva Encrypt:

<service>
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Signature</items>
			...
		</action>
	</parameter>
</service>

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Cualquier parte de un mensaje que no esté firmada podría ser interceptada y modificada sin que el receptor lo detecte. Sin una firma, un receptor no puede verificar criptográficamente que el contenido de un mensaje es auténtico.

La siguiente configuración del proveedor de servicios indica a Axis 2 que acepte mensajes sin firmar:

<service>
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</service>

Una marca de tiempo de seguridad indica la actualidad de un mensaje. Si un atacante intercepta un mensaje y lo retransmite más tarde, el receptor puede rechazar el ataque de reproducción porque la marca de tiempo indicará que el mensaje está obsoleto. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, podría ser posible interceptar un mensaje SOAP, modificar la marca de tiempo y enviar el mensaje sin el conocimiento del receptor. En estas circunstancias, un atacante puede engañar a un destinatario para que acepte un mensaje malintencionado.

La siguiente configuración de Apache Axis 2 Rampart omite la directiva Timestamp de la etiqueta <items>, por lo que el servicio no requiere que las solicitudes contengan marcas de tiempo.

<service>
...
      <action>
        <items>Signature Encrypt</items>
...
</service>

El cifrado a nivel de mensaje SOAP garantiza una verdadera confidencialidad de un extremo a otro. Los mensajes SOAP se pueden enviar a través de varios protocolos de transporte como HTTPS, HTTP, TCP, SMTP, UDP, etc. El cifrado a nivel de mensaje garantiza la confidencialidad del mensaje independientemente del protocolo de transporte. Un escenario común entre los servicios web es retransmitir mensajes SOAP entre servicios, por lo que el cifrado a nivel de mensajes significa que los remitentes y receptores de mensajes no necesitan preocuparse por la seguridad del transporte entre los puntos de retransmisión.

Ejemplo 1: La siguiente configuración de Apache Axis 2 Rampart no requiere el cifrado de mensajes salientes debido a que la etiqueta <items> no contiene una directiva Encrypt:

<service>
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Signature</items>
			...
		</action>
	</parameter>
</service>

Cualquier parte de un mensaje que no esté firmada podría ser interceptada y modificada sin que el receptor detecte la modificación. Sin una firma, un receptor no puede verificar criptográficamente la integridad o el origen del contenido del mensaje.

La siguiente configuración del proveedor de servicios indica a Axis 2 que envíe marcas de tiempo sin firmar:

<service>
...
	<parameter name="OutflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</service>

Una marca de tiempo de seguridad indica la actualidad de los datos de seguridad de un mensaje. Si un atacante intercepta un mensaje y lo retransmite más tarde, el receptor puede rechazar el ataque de reproducción porque la marca de tiempo indicará que el mensaje está obsoleto. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante podría interceptar un mensaje SOAP, modificar la marca de tiempo y enviar el mensaje sin el conocimiento del receptor. En estas circunstancias, un atacante puede engañar a un destinatario para que acepte un mensaje malintencionado.

La siguiente configuración de Apache Axis 2 Rampart omite la directiva Timestamp de la etiqueta <items>, por lo que el servicio no envía mensajes con marcas de tiempo.

<service>
...
   <parameter name="OutflowSecurity">
      <action>
        <items>Signature Encrypt</items>
...
</service>

WS-Security es una extensión de SOAP que proporciona integridad y confidencialidad de los mensajes de un extremo a otro, independientemente del protocolo de transporte. Cuando no se utiliza WS-Security, la integridad y confidencialidad de los mensajes dependen de la seguridad del transporte. Si un servicio retransmite mensajes a otros servicios, los mensajes se exponen al mecanismo de transporte más débil utilizado entre los puntos de retransmisión. WS-Security elimina la dependencia de la seguridad del transporte y protege el mensaje en sí.

. La ausencia de un parámetro OutflowSecurity en el archivo de configuración de Apache Axis 2 indica que la seguridad de los mensajes entrantes no está habilitada.

Una marca de tiempo de seguridad indica la actualidad de un mensaje. Si un atacante intercepta un mensaje y lo retransmite más tarde, el receptor puede rechazar el ataque de reproducción porque la marca de tiempo indicará que el mensaje está obsoleto. Opcionalmente, las marcas de tiempo pueden incluir un atributo de vencimiento que establece un límite estricto sobre la duración de la validez de la semántica de seguridad.

Para evitar que los atacantes manipulen las marcas de tiempo, estas deben estar firmadas. Sin una marca de tiempo firmada, un atacante puede interceptar un mensaje SOAP, modificar la marca de tiempo y enviar el mensaje sin el conocimiento del receptor. En estas circunstancias, un atacante puede engañar a un destinatario para que acepte un mensaje malintencionado.

La siguiente configuración del proveedor de servicios indica a Axis 2 que acepte mensajes con marcas de tiempo sin firmar:

<service>
...
	<parameter name="InflowSecurity">
		<action>
			<items>Timestamp Encrypt</items>
			...
		</action>
	</parameter>
</service>