Os serviços em nuvem normalmente usam técnicas como cache, replicação e balanceamento de carga para facilitar a escalabilidade do serviço, entregar conteúdo mais rapidamente e mitigar os impactos de ataques volumétricos. Recursos de disponibilidade desabilitados ou mal configurados degradam o desempenho do serviço, mas os efeitos imediatos geralmente não são aparentes até que ocorram eventos extremos, como picos de tráfego e falhas de hardware.

Os serviços em nuvem normalmente usam técnicas como cache, replicação e balanceamento de carga para facilitar a escalabilidade do serviço, entregar conteúdo mais rapidamente e mitigar os impactos de ataques volumétricos. Recursos de disponibilidade desabilitados ou mal configurados degradam o desempenho do serviço, mas os efeitos imediatos geralmente não são aparentes até que ocorram eventos extremos, como picos de tráfego e falhas de hardware.

Os serviços em nuvem normalmente usam técnicas como cache, replicação e balanceamento de carga para facilitar a escalabilidade do serviço, entregar conteúdo mais rapidamente e mitigar os impactos de ataques volumétricos. Recursos de disponibilidade desabilitados ou mal configurados degradam o desempenho do serviço, mas os efeitos imediatos geralmente não são aparentes até que ocorram eventos extremos, como picos de tráfego e falhas de hardware.

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

Por padrão, a AWS usa chaves gerenciadas pela AWS para criptografar dados em repouso se a criptografia estiver habilitada. As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle e registro de processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

Observe que as chaves com o formato aws/service-name são reservadas para chaves gerenciadas pela AWS.

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

Por padrão, a AWS usa chaves gerenciadas pela AWS para criptografar dados em repouso se a criptografia estiver habilitada. As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle e registro de processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

Observe que as chaves com o formato aws/service-name são reservadas para chaves gerenciadas pela AWS.

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

Por padrão, a AWS usa chaves gerenciadas pela AWS para criptografar dados em repouso se a criptografia estiver habilitada. As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle e registro de processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

Observe que as chaves com o formato aws/service-name são reservadas para chaves gerenciadas pela AWS.

As chaves gerenciadas pelo cliente não são usadas para criptografar dados em repouso.

Por padrão, a AWS usa chaves gerenciadas pela AWS para criptografar dados em repouso se a criptografia estiver habilitada. As chaves gerenciadas pelo cliente permitem que as organizações usem chaves criptográficas de sua escolha para criptografar dados. Isso dá às organizações melhor controle e registro de processos de criptografia.

Assim, as chaves gerenciadas pelo cliente geralmente fazem parte da solução para atender aos requisitos que incluem, mas não estão limitados a:
- Logs de auditoria para acesso a dados confidenciais
- Residência de dados
- Substituição, desabilitação ou destruição de chaves

Observe que as chaves com o formato aws/service-name são reservadas para chaves gerenciadas pela AWS.

Mecanismos de autenticação fracos expõem as organizações a acesso não autorizado.

Os mecanismos de autenticação podem falhar por vários motivos, como:
- Senhas fracas
- Validação imprópria
- Gerenciamento de credenciais fraco

A autenticação é um aspecto essencial da segurança. A confiabilidade do processo de autenticação depende da segurança e da força das credenciais de login. As políticas de senha que garantem que os usuários criem senhas fortes são cruciais para a implantação de sites seguros. A força da senha é uma medida da eficácia que ela oferece em resistir a adivinhações e ataques de força bruta. Alguns parâmetros que ajudam a definir a força da senha incluem características de senha, como comprimento, complexidade e aleatoriedade da senha.

O Apache Axis 2 fornece aos desenvolvedores um utilitário para monitorar mensagens SOAP de entrada e saída por meio de um applet Java. O monitor SOAP mostrará todas as mensagens SOAP usadas para invocar um serviço web. Os invasores podem usar o utilitário para interceptar o tráfego entre um serviço da Web e seus clientes.

Se um serviço retransmitir mensagens para outros serviços, as mensagens serão expostas ao mecanismo de transporte mais fraco usado entre os pontos de retransmissão. O REST por si só não inclui nenhum mecanismo de segurança, portanto, esse serviço depende da camada de transporte para integridade e confidencialidade da mensagem.

A seguinte configuração ativa o REST:

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

O WS-Security é um aprimoramento do SOAP que fornece integridade e confidencialidade da mensagem de ponta a ponta, independentemente do protocolo de transporte. Quando o WS-Security não é usado, as mensagens contam com a segurança do transporte para integridade e confidencialidade. Se um serviço retransmitir mensagens para outros serviços, as mensagens serão expostas ao mecanismo de transporte mais fraco usado entre os pontos de retransmissão. O WS-Security elimina a dependência de segurança do transporte e protege a mensagem em si.

A ausência de um parâmetro InflowSecurity no arquivo de configuração do Apache Axis 2 indica que a segurança da mensagem recebida não está ativada.

A seguinte configuração do Apache Axis 2 Rampart não requer que mensagens de entrada sejam criptografadas, já que a tag <items> não contém uma diretiva Encrypt:

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

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem ser detectada pelo destinatário. Sem uma assinatura, um destinatário não pode verificar criptograficamente se o conteúdo de uma mensagem é autêntica.

A seguinte configuração do provedor de serviços diz ao Axis 2 para aceitar mensagens não assinadas:

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

Um carimbo de data/hora de segurança indica a atualização de uma mensagem. Se um invasor interceptar uma mensagem e retransmiti-la posteriormente, o receptor pode rejeitar o ataque de repetição porque o carimbo de data/hora indicará que a mensagem é obsoleta. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

Para evitar que invasores adulterem os carimbos de data/hora, os carimbos de data/hora devem ser assinados. Sem um carimbo de data/hora assinado, pode ser possível interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do Rampart do Apache Axis 2 omite a diretiva Timestamp da tag <items> para que o serviço não exija que as solicitações contenham carimbos de data/hora.

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

A criptografia no nível da mensagem SOAP garante a verdadeira confidencialidade de ponta a ponta. As mensagens SOAP podem ser enviadas por meio de vários protocolos de transporte, como HTTPS, HTTP, TCP, SMTP, UDP, etc. A criptografia no nível da mensagem garante a confidencialidade da mensagem, independentemente do protocolo de transporte. Um cenário comum entre os serviços da Web é retransmitir mensagens SOAP entre os serviços, portanto, a criptografia no nível da mensagem significa que os remetentes e destinatários das mensagens não precisam se preocupar com toda a segurança de transporte entre os pontos de retransmissão.

Exemplo 1: A seguinte configuração do Apache Axis 2 Rampart não requer que mensagens de saída sejam criptografadas, pois a tag <items> não contém uma diretiva Encrypt:

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

Qualquer parte de uma mensagem que não seja assinada tem a possibilidade de ser interceptada e modificada sem a modificação ser detectada pelo destinatário. Sem uma assinatura, um receptor não pode verificar criptograficamente a integridade ou origem do conteúdo da mensagem.

A seguinte configuração do provedor de serviços diz ao Axis 2 para enviar carimbos de data/hora não assinados:

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

Um carimbo de data/hora de segurança indica a atualização dos dados de segurança de uma mensagem. Se um invasor interceptar uma mensagem e retransmiti-la posteriormente, o receptor pode rejeitar o ataque de repetição porque o carimbo de data/hora indicará que a mensagem é obsoleta. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

Para evitar que invasores adulterem os carimbos de data/hora, os carimbos de data/hora devem ser assinados. Sem um carimbo de data/hora assinado, um invasor pode interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor pode induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do Rampart do Apache Axis 2 omite a diretiva Timestamp da tag <items>, então o serviço não envia mensagens com carimbos de data/hora.

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

WS-Security é uma extensão do SOAP que fornece integridade e confidencialidade da mensagem de ponta a ponta, independentemente do protocolo de transporte. Quando o WS-Security não é usado, as mensagens contam com a segurança do transporte para integridade e confidencialidade. Se um serviço retransmitir mensagens para outros serviços, as mensagens serão expostas ao mecanismo de transporte mais fraco usado entre os pontos de retransmissão. O WS-Security elimina a dependência de segurança do transporte e protege a mensagem em si.

. A ausência de um parâmetro OutflowSecurity no arquivo de configuração do Apache Axis 2 indica que a segurança da mensagem enviada não está ativada.

Um carimbo de data/hora de segurança indica a atualização de uma mensagem. Se um invasor interceptar uma mensagem e retransmiti-la posteriormente, o receptor pode rejeitar o ataque de repetição porque o carimbo de data/hora indicará que a mensagem é obsoleta. Opcionalmente, os carimbos de data/hora podem incluir um atributo de expiração que impõe um limite rígido sobre a validade da semântica de segurança.

Para evitar que invasores adulterem os carimbos de data/hora, os carimbos de data/hora devem ser assinados. Sem um carimbo de data/hora assinado, um invasor poderia interceptar uma mensagem SOAP, modificar o carimbo de data/hora e enviar a mensagem sem o conhecimento do receptor. Nessas circunstâncias, um invasor tem a possibilidade de induzir um destinatário a aceitar uma mensagem mal-intencionada.

A seguinte configuração do provedor de serviços diz ao Axis 2 para aceitar mensagens com carimbos de data/hora sem assinatura:

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