Cloud services typically use techniques like caching, replication, and load balancing to facilitate service scalability, deliver content faster, and mitigate the impacts of volumetric attacks. Disabled or misconfigured availability features degrade service performance, but immediate effects are often not apparent until extreme events such as traffic spikes and hardware failures occur.

Cloud services typically use techniques like caching, replication, and load balancing to facilitate service scalability, deliver content faster, and mitigate the impacts of volumetric attacks. Disabled or misconfigured availability features degrade service performance, but immediate effects are often not apparent until extreme events such as traffic spikes and hardware failures occur.

Cloud services typically use techniques like caching, replication, and load balancing to facilitate service scalability, deliver content faster, and mitigate the impacts of volumetric attacks. Disabled or misconfigured availability features degrade service performance, but immediate effects are often not apparent until extreme events such as traffic spikes and hardware failures occur.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Customer-managed keys are not used to encrypt data at rest.

By default, AWS uses AWS-managed keys to encrypt data at rest if encryption is enabled. Customer-managed keys enable organizations to use cryptographic keys of their choice to encrypt data. This gives organizations better control over and logging of encryption processes.

As such, customer-managed keys are often part of the solution to address requirements that include but are not limited to:
- Audit logs for sensitive data access
- Data residency
- Replacing, disabling, or destroying keys

Note that keys with the format aws/service-name are reserved for AWS-managed keys.

Weak authentication mechanisms expose organizations to unauthorized access.

Authentication mechanisms can fail for various reasons, such as:
- Weak passwords
- Improper validation
- Weak credential management

Authentication is an essential aspect of security. The authentication process's reliability depends on the login credentials' safety and strength. Password policies ensuring users create strong passwords are crucial to deploying secure websites. Password strength is a measure of the effectiveness it provides in resisting guessing and brute force attacks. Some parameters that help define password strength include password characteristics such as password length, complexity, and randomness.

Apache Axis 2 provides developers with a utility to monitor incoming and outgoing SOAP messages through a Java applet. The SOAP Monitor will show all SOAP messages used to invoke a Web Service. Attackers may use the utility to eavesdrop on traffic between a Web Service and its clients.

If a service relays messages to other services, the messages are exposed to the weakest transport mechanism used between relay points. REST by itself does not include any security mechanisms, so this service relies on the transport layer for message integrity and confidentiality.

The following configuration enables REST:

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

WS-Security is an enhancement to SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and secures the message itself.

The absence of an InflowSecurity parameter in the Apache Axis 2 configuration file indicates that inbound message security is not enabled.

The following Apache Axis 2 Rampart configuration does not require inbound messages to be encrypted since the <items> tag does not contain an Encrypt directive:

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

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Any part of a message that is not signed has the potential to be intercepted and modified without being detected by the receiver. Without a signature, a receiver cannot cryptographically verify that the contents of a message are authentic.

The following service provider configuration tells Axis 2 to accept unsigned messages:

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

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, it might be possible to intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following Apache Axis 2 Rampart configuration omits the Timestamp directive from the <items> tag, so the service does not require requests to contain timestamps.

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

Encryption at the SOAP message level ensures true end-to-end confidentiality. SOAP messages can be sent over a number transport protocols such as HTTPS, HTTP, TCP, SMTP, UDP, etc. Message-level encryption ensures the confidentiality of the message regardless of the transport protocol. A common scenario among web services is to relay SOAP messages between services, so message-level encryption means message senders and receivers do not need to worry about all transport security between any relay points.

Example 1: The following Apache Axis 2 Rampart configuration does not require outbound messages to be encrypted since the <items> tag does not contain an Encrypt directive:

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

Any part of a message that is not signed has the potential to be intercepted and modified without the modification being detected by the receiver. Without a signature, a receiver cannot cryptographically verify the integrity or origin of the message contents.

The following service provider configuration tells Axis 2 to send unsigned timestamps:

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

A Security timestamp indicates the freshness of a message's security data. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker could intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may trick a recipient into accepting a malicious message.

The following Apache Axis 2 Rampart configuration omits the Timestamp directive from the <items> tag, so the service does not send messages with timestamps.

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

WS-Security is an extension of SOAP that provides end-to-end message integrity and confidentiality regardless of the transport protocol. When WS-Security is not used, messages rely on transport security for integrity and confidentiality. If a service relays messages to other services, messages are exposed to the weakest transport mechanism used between relay points. WS-Security removes the transport security dependency and secures the message itself.

. The absence of an OutflowSecurity parameter in the Apache Axis 2 configuration file indicates that outbound message security is not enabled.

A Security timestamp indicates a message's freshness. If an attacker intercepts a message retransmits it at a later time, the receiver can reject the replay attack because the timestamp will indicate that the message is stale. Optionally, timestamps can include an expiration attribute which places a hard limit on how long security semantics are valid.

To prevent attackers from tampering with timestamps, timestamps should be signed. Without a signed timestamp, an attacker may intercept a SOAP message, modify the timestamp, and send the message on without the receiver's knowledge. Under these circumstances, an attacker may potentially trick a recipient into accepting a malicious message.

The following service provider configuration tells Axis 2 to accept messages with unsigned timestamps:

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