Esta página foi traduzida pela API Cloud Translation.

Como configurar o acesso TLS a uma API para a nuvem privada

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

Um host virtual no Edge define os domínios e as portas em que um proxy de API é exposto e, , o URL que os apps usam para acessar um proxy de API.

Um host virtual também define se o proxy de API será acessado usando o protocolo HTTP ou pelo protocolo HTTPS criptografado que usa TLS. Ao configurar um host virtual para usar HTTPS e TLS, você cria um host virtual no Edge e o configura para usar um keystore e Truststore.

Saiba mais:

Observações:

Este artigo do produto do Cloud lista criptografias SSL válidas para o TLS 1.2: Empirical Analysis of Valid Values for VirtualHost ssl_ciphers for Testing TLS 1.2.
A partir do Edge para a nuvem privada versão 4.16.01, é preciso especificar um alias de host ao criar um host virtual. Nas versões anteriores à 4.16.01, o alias de host era opcional.
A combinação de nome de alias de host e número de porta para o host virtual deve ser exclusiva de todos os hosts virtuais na instalação do Edge.
Se você configurar um número de porta (que não seja 80 ou 443), ele deverá ser único e não poderá ter uma configuração de porta sobreposta com um host atual.
Se a instalação usa um balanceador de carga, e ele for responsável por lidar com o tráfego criptografado, você ainda precisará criar o host virtual. No entanto, sua configuração de rede vai determinar se o host virtual precisa ou não oferecer suporte TLS entre o balanceador de carga e o roteador. Consulte Como usar TLS em uma instalação de nuvem privada.

Do que você precisa para criar um host virtual

Antes de criar um host virtual, você deve ter as seguintes informações:

O nome de domínio público do host virtual. Por exemplo, você deve saber se o nome exibido ao público é api.myCompany.com, myapi.myCompany.com etc. Essa informação é usado quando você cria o host virtual e também quando cria o registro DNS para o host virtual.
Para TLS unidirecional, é necessário criar um keystore que contenha o seguinte:
- Certificado TLS: um certificado assinado por uma autoridade de certificação (CA, na sigla em inglês) ou uma cadeia de certificados em que o último é assinado por uma AC.
- Chave privada: o Edge oferece suporte a tamanhos de chave de até 2.048 bits. A senha longa é opcional.
Para TLS bidirecional, é necessário um keystore e um truststore para manter os do cliente e, opcionalmente, à cadeia da AC do certificado. Você precisa do truststore, mesmo que O certificado é assinado por uma AC.

Consulte Keystores e Truststores para mais informações sobre como criar keystores e truststores.

Configuração de host virtual para TLS

Para criar um host virtual, crie um objeto XML que defina o host virtual. O objeto XML a seguir usa o elemento <SSLInfo> para definir um objeto host para uma configuração de TLS unidirecional sobre HTTPS:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
</VirtualHost>

Observação: como o Edge era originalmente compatível com SSL, a tag que você usa para configurar o TLS é chamado de <SSLInfo>.

Neste exemplo, o elemento <Enabled> é definido como verdadeiro para ativar o TLS unidirecional, e os elementos <KeyStore> e <KeyAlias> especificam o keystore e a chave usada pela conexão TLS.

Para ativar o TLS bidirecional, defina o elemento <ClientAuthEnabled> como true e especificar um truststore usando <TrustStore>. . O truststore detém o certificado do cliente e, opcionalmente, a CA do certificado corrente

Decidir como especificar o nome do keystore e do truststore no host virtual

No exemplo de host virtual acima, você especificou o keystore usando uma referência. Um reference é uma variável que contém o nome do keystore, em vez de especificar o o nome do keystore.

A vantagem de usar uma referência é que você pode alterar o valor dela para alterar o keystore usado pelo host virtual, geralmente porque o certificado no keystore atual é expira em breve. Alterar o valor da referência não exige que você reinicie o roteador de borda.

Como alternativa, use um nome de keystore literal no host virtual. No entanto, se você alguma vez modificar o host virtual para alterar o nome do keystore, será necessário reiniciar os roteadores de borda.

Restrições no uso de referências a keystores e truststore

Você deve levar em consideração a seguinte restrição ao usar referências a keystores e truststores:

Você só pode usar referências de keystore e truststore em hosts virtuais se oferecer suporte a SNI e você encerra o SSL nos roteadores da Apigee.
Se você tiver um balanceador de carga na frente dos roteadores da Apigee e encerrar o TLS nos balanceador de carga, não será possível usar referências de keystore e truststore host.

Como modificar um host virtual existente para usar referências ao keystore e ao truststore

A Apigee recomenda que os hosts virtuais usem referências a keystores e truststores. As referências permitem alterar o keystore e o truststore usados pelo host virtual sem os roteadores de borda.

Se os hosts virtuais estiverem configurados para usar o nome literal do keystore ou truststore, é possível convertê-los para usar referências. Para isso, atualize o host virtual para usar e reinicie os roteadores de borda.

Como definir as criptografias e os protocolos TLS para o Edge 4.15.07 e versões anteriores

Se você estiver usando o Edge versão 4.15.07 e anterior, defina o protocolo TLS e as criptografias usada pelo host virtual com as tags filhas <Ciphers> e <Protocols> do tag <SSLInfo>. Essas tags estão descritos na tabela abaixo.

Exemplo:

    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>myTestKeystore</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
        <SSLInfo>
            <Enabled>true</Enabled>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <KeyStore>myTestKeystore</KeyStore>
            <KeyAlias>myKeyAlias</KeyAlias>
            <Ciphers>
                <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</Cipher>
                <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</Cipher>
            </Ciphers>
            <Protocols>
                <Protocol>TLSv1.2</Protocol>
            </Protocols>
        </SSLInfo>
   </SSLInfo>

A tag <Cipher> usa o nome Java e JSSE da cifra. Por exemplo, para Java 8, consulte http://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#ciphersuites.

Como especificar as criptografias e os protocolos TLS para o Edge 4.16.01 a 4.16.09

Do Edge 4.16.01 a 4.16.09, você define as criptografias e os protocolos padrão para hosts virtuais globalmente no roteador. Esses padrões se aplicam a todos os hosts virtuais.

Use tokens para especificar os protocolos e as criptografias padrão:

Para especificar os protocolos padrão, use o token conf_load_balancing_load.balancing.driver.server.ssl.protocols
Para especificar as criptografias padrão do roteador, use o token conf_load_balancing_load.balancing.driver.server.ssl.ciphers

O valor padrão do token conf_load_balancing_load.balancing.driver.server.ssl.protocols é:

conf_load_balancing_load.balancing.driver.server.ssl.protocols=TLSv1 TLSv1.1 TLSv1.2

Essa configuração especifica que o roteador é compatível com as versões 1.0, 1.1 e 1.2 do TLS. Especifique um lista de valores delimitados por espaço ao token.

O valor padrão do token conf_load_balancing_load.balancing.driver.server.ssl.ciphers é:

conf_load_balancing_load.balancing.driver.server.ssl.ciphers=HIGH:!aNULL:!MD5:!DH+3DES:!RSA+3DES

Essa configuração especifica:

Comprimento de chave de 128 bits ou mais obrigatório (HIGH).
Excluir criptografias sem autenticação (!aNULL)
Excluir pacotes de criptografia usando MD5 (!MD5)
Excluir pacotes de criptografia usando DH (incluindo DH anônimo, DH efêmero e DH fixo) E DES triplo (!DH+3DES)
Excluir pacotes de criptografia usando a troca de chave RSA E o DES triplo (!RSA+3DES)

Para mais informações sobre a sintaxe e os valores permitidos por esse token, consulte Criptografias OpenSSL. Observe que esse token usa os nomes de criptografia OpenSSL, como AES128-SHA256, e não o Nomes de criptografia Java/JSSE, como TLS_RSA_WITH_AES_128_CBC_SHA256.

Para definir o token do roteador:

Editar /opt/apigee/customer/application/router.properties . Se esse arquivo não existir, crie-o.
Defina o conf_load_balancing_load.balancing.driver.server.ssl.ciphers com base no token correto anterior. Por exemplo, para especificar apenas TLSv1.2 e excluir pacotes de criptografia que usam chaves pré-compartilhadas, adicionar !PSK:
```
conf_load_balancing_load.balancing.driver.server.ssl.protocols=TLSv1.2
conf_load_balancing_load.balancing.driver.server.ssl.ciphers=HIGH:!aNULL:!MD5:!DH+3DES:!RSA+3DES:!PSK
```

Verificar se o arquivo router.properties pertence a apigee:

chown apigee:apigee /opt/apigee/customer/application/router.properties

Reinicie o Edge Router:

/opt/apigee/apigee-service/bin/apigee-service edge-router restart

Verifique o valor do token:

/opt/apigee/apigee-service/bin/apigee-service edge-router configure -search conf_load_balancing_load.balancing.driver.server.ssl.ciphers

Ambiente Parâmetros de host virtual TLS para o Edge versão 4.17.01 e mais recentes

Se estiver usando o Edge versão 4.17.01 e posterior, poderá definir algumas propriedades TLS para host virtual individual, como protocolo e criptografia TLS, usando a tag filha <Properties> do <VirtualHost> tag. Essas tags são descritas em Referência de propriedades de host virtual.

Exemplo:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://myTestKeystoreRef</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
    <Properties>
        <Property name="proxy_read_timeout">50</Property>
        <Property name="keepalive_timeout">300</Property>
        <Property name="proxy_request_buffering">off</Property>
        <Property name="proxy_buffering">off</Property>
        <Property name="ssl_protocols">TLSv1.2 TLSv1.1</Property>
        <Property name="ssl_ciphers">HIGH:!aNULL:!MD5:!DH+3DES:!kEDH</Property>
    </Properties>
</VirtualHost>

Para informações sobre a sintaxe e os valores permitidos pelo token ssl_ciphers, consulte as criptografias OpenSSL (link em inglês). Observe que esse token usa os nomes de criptografia do OpenSSL, como AES128-SHA256, e não os nomes de criptografia Java/JSSE, como TLS_RSA_WITH_AES_128_CBC_SHA256.

Como criar um host virtual que usa HTTPS

Este exemplo especifica o keystore para o host virtual usando uma referência. Ao usar um reference permite que você altere o keystore sem precisar reiniciar os roteadores.

Use o procedimento a seguir para criar o host virtual:

Crie e configure um keystore denominado myTestKeystore usando o descrito aqui: Keystores e Truststores (em inglês). Verificar se o keystore usa um nome de alias de myKeyAlias para o certificado e a chave privada.

Use a seguinte chamada da API POST para criar a referência chamado keystoreref para o keystore que você criou acima:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'
  -u email:password

A referência especifica o nome do keystore e o tipo de referência como KeyStore.

Use a chamada GET API a seguir para visualizar a referência:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Crie o host virtual usando o botão Criar um API Virtual Host, em que <ms-IP> é o endereço IP ou o nome do domínio do nó do servidor de gerenciamento.

Certifique-se de especificar a referência de keystore e o alias de chave corretos:
```
curl -X POST -H "Content-Type:application/xml" \
  http://<ms-IP>:8080/v1/o/{org_name}/environments/{env_name}/virtualhosts \
  -d '<VirtualHost  name="newTLSTrustStore2">
    <HostAliases>
      <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9005</Port>
    <OCSPStapling>off</OCSPStapling>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>false</ClientAuthEnabled>
      <KeyStore>ref://keystoreref</KeyStore>
      <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
  </VirtualHost>' \
  -u email:password
```
Observação : se você estiver executando TLS bidirecional com o cliente, Em seguida, defina <ClientAuthEnabled> como true e especifique o truststore usando o elemento <TrustStore>. A precisa ser configurado corretamente para TLS bidirecional, ou seja, o Edge tem um truststore contendo ao certificado e à cadeia de certificados do cliente. Criar o truststore usando o procedimento descritos aqui: Keystores e Truststores.
Crie um registro DNS para o host virtual que corresponda ao alias do host.
Se você já tiver proxies de API, adicione o host virtual ao elemento <HTTPConnection> no ProxyEndpoint. O host virtual é adicionado automaticamente a todos os novos proxies da API.

Consulte Como atualizar um proxy de API depois de criar um host virtual em Sobre hosts virtuais.

Aviso:todos os hosts virtuais são adicionados automaticamente a todos os novos proxies de API. Portanto, se você criar um novo proxy de API que não deverá ser acessível por uma um host virtual específico, edite o proxy de API para removê-lo do o ProxyEndpoint.

Depois de atualizar um proxy de API para usar o host virtual e criar o registro DNS para o host alias, você pode acessar o proxy de API como mostrado abaixo:

https://apiTLS.myCompany.com/v1/{project-base-path}/{resource-path}

Exemplo:

https://apiTLS.myCompany.com/v1/weather/forecastrss?w=12797282

Como criar e modificar referências para um keystore ou truststore

Opcionalmente, você pode configurar o host virtual para usar uma referência ao keystore ou truststore em vez disso. A vantagem de usar uma referência é que você pode atualizá-la para apontar para um keystore ou um truststore diferente para atualizar o certificado TLS sem precisar reiniciar um entre a VM e um Cloud Router.

Por exemplo, veja abaixo um host virtual que usa uma referência ao keystore:

<VirtualHost name="myTLSVHost">
    <HostAliases>
        <HostAlias>apiTLS.myCompany.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9006</Port>
    <SSLInfo>
        <Enabled>true</Enabled>
        <ClientAuthEnabled>false</ClientAuthEnabled>
        <KeyStore>ref://keystoreref</KeyStore>
        <KeyAlias>myKeyAlias</KeyAlias>
    </SSLInfo>
</VirtualHost>

Use a seguinte chamada da API POST para criar a referência chamada keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'
  -u email:password

A referência especifica o nome e o tipo do keystore.

Use a chamada GET API a seguir para visualizar a referência:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

Posteriormente, para alterar a referência e apontar para um keystore diferente, verifique se o alias tem o mesmo nome e use a seguinte chamada PUT:

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'
  -u email:password