Proteger segredos usando recursos da plataforma

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

Listar as opções e práticas recomendadas para armazenar segredos em pacotes gerenciados.
Criar credenciais nomeadas para definir pontos de extremidade de callout e seus parâmetros de autenticação associados de forma segura.
Descrever como as configurações e os campos de API de metadados personalizados protegidos podem ser usados para armazenar segredos.

Armazenar segredos de aplicativo no Salesforce

Na unidade anterior, você aprendeu a identificar segredos e quem deve ter acesso a eles. A próxima etapa é aprender a protegê-los.

Esta Salesforce Platform tem vários recursos que podem ser usados para armazenar e proteger segredos, incluindo:

Credenciais nomeadas
Configurações personalizadas (protegida, não protegida, gerenciada e não gerenciada)
Tipos de metadados personalizados

Nesta unidade, você vai aprender sobre cada uma dessas opções de armazenamento de segredos para que você possa restringir as informações confidenciais adequadamente.

Credenciais nomeadas

As credenciais nomeadas são um mecanismo para gerenciar com segurança os valores de autenticação para provedores e serviços externos. Eles fornecem processos de implementação de autenticação padrão em um conjunto de entidades seguras e gerenciáveis. O Salesforce gerencia toda a autenticação dos callouts do Apex que especificam uma credencial nomeada como ponto de extremidade de callout, e você não precisa adicionar outra lógica de autenticação no seu código do Apex. As credenciais nomeadas podem ser definidas para oferecer uma maneira segura e prática de configurar esses tipos de callout. Depois de criadas, você pode substituir referências a URL com código por referências às credenciais nomeadas, o que resulta em código mais conciso, mais simples e mais seguro.

As credenciais nomeadas são úteis quando é preciso definir pontos de extremidade de callout referenciados no seu pacote gerenciado. Sem elas, o desenvolvedor precisa executar as tarefas adicionais a seguir para configurar um callout autenticado.

Referenciar a URL como o ponto de extremidade de callout.
Registrar a URL nas suas configurações do site remoto.
Adicionar código personalizado para tratar de tarefas de autenticação associadas.

Por exemplo, digamos que você tem um aplicativo que se conecta a um serviço externo regularmente para recuperar dados. Entretanto, esse serviço externo exige que todas as solicitações incluam uma chave API para autenticação. Uma forma comum de os desenvolvedores satisfazerem esta exigência é embutir a chave no código fonte para que possa ser usada em cada solicitação. Veja este exemplo de código.

String key = ’supersecurepassword’;
HttpRequest req = new HttpRequest();
req.setEndpoint(’https://www.example.com/test?APIKEY=’+key);
req.setMethod(’GET’);
Http http = new Http();
HTTPResponse res = http.send(req);
return res.getBody();

Embora embutir segredos com código seja uma solução direta, essa abordagem tem três problemas principais.

Qualquer um que possa ver o código-fonte pode ver também os segredos embutidos.
Se um segredo é atualizado, você precisará alterar todas as instâncias dele no código-fonte.
A portabilidade desse segredo entre aplicativos pode criar várias outras complicações.

É aqui que as credenciais nomeadas são a salvação da lavoura! Em vez de embutir o valor em seu código, você pode usar credenciais nomeadas para armazenar segredos. Você pode fazer referência à credencial nomeada para acessar o valor secreto como se fosse qualquer outra variável em seu código.

Benefícios das Credenciais nomeadas

Além de permitir a restrição do acesso aos segredos do seu aplicativo, as credenciais nomeadas também facilitam a manutenção desses segredos. Depois de configurar uma credencial nomeada, você pode alterá-la facilmente sempre que necessário modificando-a em suas configurações. Quaisquer instâncias no seu código que fizerem referência ao segredo sempre manterão dados atualizados, já que a referência é diretamente para a credencial nomeada.

Onde usar Credenciais nomeadas

Embora seja fácil configurar credenciais nomeadas, elas não são necessariamente a melhor solução em todos os casos. Elas são mais adequadas para protocolos de autenticação padrão, como nome de usuário e senha, OAuth 2.0, AWS Signature Version 4 e JWTs assinados.

As credenciais nomeadas foram criadas para facilitar a vida e melhorar a segurança de administradores e desenvolvedores da sua organização. Apesar disso, elas nem sempre são a melhor escolha. Como os usuários com permissão Modify All Data or Author Apex (Modificar todos os dados ou Apex do autor) podem modificar ou fazer callouts à credencial nomeada, eles também podem acessar os dados protegidos pela credencial nomeada. Ou eles podem extrair as credenciais em si. Se você precisa se proteger contra esses casos de uso — por exemplo, no caso de um fornecedor independente de software que cria um pacote que precisa se comunicar com seus serviços de nuvem de forma privada — leve em conta outras opções, como as configurações personalizadas protegidas gerenciadas ou os tipos de metadados personalizados protegidos gerenciados. Leia mais sobre isso na próxima seção.

Nova funcionalidade de Credencial nomeada/externa

A nova funcionalidade de Credencial nomeada/externa no Salesforce foi criada para aumentar a segurança e simplificar as integrações externas. As Credenciais externas representam os detalhes de como o Salesforce se autentica com um sistema externo usando um protocolo de autenticação, vinculando-se a conjuntos de permissões, perfis e cabeçalhos personalizados opcionais. Os usuários com as permissões necessárias podem visualizar, criar, editar e excluir Credenciais externas.

As Credenciais nomeadas atuam como conexões lógicas com sistemas externos, eliminando a necessidade de incorporar URLs físicas no código do Apex e gerenciar tokens de autenticação em armazenamentos de dados não criptografados. Elas especificam a URL de um ponto de extremidade de callout e seus parâmetros de autenticação obrigatórios em uma definição. As Credenciais nomeadas são compatíveis com diferentes tipos, incluindo SecuredEndpoint, PrivateEndpoint e Legacy (obsoleta).

A interação entre Credenciais nomeadas e Credenciais externas envolve primeiro a criação de uma credencial externa, especificando o protocolo de autenticação e o conjunto ou perfil de permissões. Em seguida, é criada uma Credencial nomeada, que serve como ponto de extremidade de chamada para os Serviços externos. Os detalhes de autenticação da Credencial externa são vinculados à Credencial nomeada, permitindo chamadas seguras e autenticadas.

Os Conjuntos de permissões desempenham uma função crucial no controle do acesso a serviços externos. As Credenciais externas autenticam os usuários, enquanto os Conjuntos de permissões autorizam os usuários. Os princípios nas Credenciais externas são mapeados para as permissões do usuário, garantindo que os usuários tenham a autorização necessária antes de acessar sistemas remotos. As Credenciais externas do usuário armazenam tokens criptografados, fornecendo uma maneira segura de gerenciar a autenticação específica do usuário.

Cabeçalhos personalizados podem ser adicionados a Credenciais nomeadas e Credenciais externas, permitindo que as chamadas do Salesforce para sistemas remotos incluam parâmetros personalizados necessários para responder às solicitações. Essa personalização aumenta a flexibilidade e abrange vários casos de uso e requisitos de segurança.

A Salesforce Platform recomenda a criação e a edição de Credenciais nomeadas e externas por meio da UI do Salesforce, embora isso também seja possível por meio das APIs Metadata, Tooling e Connect REST. Em geral, a funcionalidade de Credenciais nomeadas/externas oferece uma abordagem robusta e personalizável para gerenciar integrações externas seguras e autenticadas.

Proteger segredos distribuídos

As Credenciais nomeadas são perfeitas para fazer callouts a serviços externos em uma organização cujos administradores podem acessar os segredos de autenticação associados. Mas o que fazer quando você precisa impedir que os administradores visualizem os dados, ou quando deseja distribuir segredos em várias organizações do Salesforce?

Nesses casos, o código deve ser implantado como um pacote gerenciado. Você pode gerar uma organização Developer Edition gratuita para servir como organização de empacotamento do seu código. Se você é um Parceiro AppExchange, as organizações Developer Edition podem ser criadas no seu Hub do ambiente. Você também pode visitar a página de inscrição da Developer Edition. Na sua organização de empacotamento, você pode encapsular classes do Apex, acionadores do Apex, objetos do Salesforce e outras formas de metadados comuns em um pacote gerenciado que permite uma implantação fácil em qualquer outra instância ou organização do Salesforce. Pense em um pacote gerenciado como uma versão mais complexa de um arquivo zip.

Do ponto de vista da segurança, o uso de pacotes gerenciados (ao contrário de pacotes não gerenciados ou código solto) traz várias vantagens.

Os pacotes gerenciados têm a mecânica necessária para enviar atualizações automáticas, patches e correções em caso de vulnerabilidades de segurança.
Eles têm código-fonte obscurecido (com exceção das classes do Apex globais explicitamente expostas), o que significa que nenhuma lógica de negócios ou de programa pode ser alterada a ponto de parar de funcionar, ou ser modificada de maneira mal-intencionada e redistribuída. O código obscurecido também impede que os segredos contidos no pacote possam ser vistos.
Já que você precisa definir um namespace exclusivo para seu pacote gerenciado, ele evita problemas de conflitos entre namespaces. Ele também separa seu pacote do namespace local, protegendo ainda mais os segredos contidos em seu pacote. Por padrão, os segredos de pacote não podem ser acessados por código executado fora de um pacote gerenciado.

Gerenciar configurações personalizadas protegidas e tipos de metadados personalizados protegidos

Embora o empacotamento simples do seu código em um pacote gerenciado tenha várias vantagens de segurança, o uso de um pacote gerenciado também concede acesso a dois outros recursos disponíveis para armazenar e distribuir informações: configurações personalizadas protegidas e metadados personalizados protegidos.

As Custom settings (Configurações personalizadas) podem ser criadas para armazenar quase todo tipo de dados e são extremamente flexíveis em relação ao potencial de uso e de conteúdo. Resumindo, as configurações personalizadas permitem criar conjuntos de dados personalizados que são expostos ao cache do aplicativo e, portanto, você evita a repetição de consultas ao banco de dados e aumenta a eficiência do seu aplicativo. Por exemplo, uma configuração personalizada pode ser usada para armazenar um conjunto de dados que é usado para personalizar experiências de usuário com um aplicativo. Ou ela seja criada para armazenar uma lista de nomes de produto referenciados em várias páginas para fornecer acesso rápido e fácil. Em relação à segurança do aplicativo, as configurações personalizadas podem ser usadas para armazenar informações confidenciais ou segredos.

As configurações personalizadas podem ter vários níveis de visibilidade. Uma configuração personalizada protegida contida em um pacote gerenciado não fica visível para organizações assinantes pelo Apex ou pela API, tornando-a um bom lugar para armazenar determinados tipos de segredo. As configurações personalizadas definidas para visibilidade pública ou contidas em um pacote não gerenciado são visíveis através da linguagem WSDL (Web Services Description Language, Linguagem de Descrição de Serviços Web). Assim, é importante que as configurações personalizadas protegidas sejam encapsuladas em um pacote gerenciado ao abrigar informações confidenciais.

Os campos Custom metadata (Metadados personalizados) podem ser utilizados para armazenamento de segredos de maneira semelhante às configurações personalizadas. Para o devido sigilo, defina a visibilidade como Protected (Protegido) e coloque-os em um pacote gerenciado. Os campos de API de metadados personalizados protegidos são uma ótima escolha para armazenar chaves de API ou outras chaves secretas, por exemplo.

Em relação às configurações de visibilidade, tanto as configurações personalizadas quanto os campos de metadados têm várias opções.

Público (local)
Protegido (local)
Público (gerenciado)
Protegido (gerenciado)

Embora as primeiras três opções sejam viáveis para o armazenamento de dados em geral, todos na organização podem ver valores de dados ao usar essas configurações. Use-as somente quando estiver armazenando dados que podem ser acessados publicamente. Para dados confidenciais, como segredos de aplicativo, use a opção de configuração protegida gerenciada.

A opção de visibilidade obscurecida, a facilidade de acesso e a função de caching torna as configurações personalizadas e os campos de metadados opções viáveis e atraentes para o armazenamento de segredos.

Como criar configurações personalizadas protegidas gerenciadas

Você pode criar uma configuração personalizada protegida gerenciada, chamada District Secrets, que pode ser usada para armazenar segredos de forma segura. Crie uma configuração personalizada protegida em Setup (Configuração), acessando a Busca rápida de Custom Settings (Configurações personalizadas) e clicando em New (Novo). Defina um rótulo, um nome de objeto, um tipo de configuração e uma visibilidade (defina como Protegida). Depois de clicar em Salvar, você estará pronto para adicionar campos personalizados e armazenar os segredos.

Crie uma configuração personalizada protegida definindo um Label (Rótulo), Object name (Nome do objeto), Setting type (Tipo de configuração) e Visibility (Visibilidade).

Por fim, digite seus segredos nos campos personalizados protegidos. Como somente as definições de configuração estão incluídas no pacote, você precisará de script de Apex ou API para preencher os segredos quando o pacote for instalado na organização desejada ou assinante.

Como usar configurações personalizadas protegidas gerenciadas

Você pode fazer referência a configurações personalizadas da mesma maneira que referencia objetos personalizados. Para acessar as configurações personalizadas, você pode usar campos de fórmula, métodos de configuração personalizada do Apex, API SOAP, regras de validação, fluxo e assim por diante. As referências à configuração personalizada protegida só podem ser feitas a partir do mesmo pacote gerenciado — ou seja, o mesmo namespace. Alguns métodos do Apex comuns para fazer referência a configurações personalizadas incluem:

getInstance()
getInstance(userId)
getInstance(profileId)
getOrgDefaults()
getValues(userId)
getValues(profileId)

Veja um exemplo que usa getInstance() para acessar segredos armazenados como componente da configuração personalizada.

CustomSettingName__c cmcs=CustomSettingName__c.getInstance();

Tipos de metadados personalizados

Os tipos de metadados personalizados protegidos também podem ser definidos para manter segredos, da mesma forma que as configurações personalizadas podem ser definidas. Os tipos de metadados personalizados devem ser criados para inclusão em um pacote gerenciado para que possam ser devidamente obscurecidos e protegidos. A principal diferença é que os dados contidos nos tipos de metadados personalizados representam metadados em seu aplicativo.

Isso costuma ser vantajoso. Imagine que você é um desenvolvedor criando um novo aplicativo em sua organização de empacotamento Developer Edition. Esse aplicativo tem muitos recursos interessantes, inclusive uma integração à API externa com exemplo.com. Para fazer callouts a exemplo.com, você precisa armazenar uma chave de API em algum lugar. Uma opção é armazenar a chave secreta da API em um campo personalizado. Isso funciona bem com a sua própria organização DE, mas há algo errado com essa abordagem.

Além de ser uma solução insegura, há um problema com o armazenamento da chave secreta API dentro de um campo personalizado quando se trata de uma reimplantação. Quando você tenta mover todo o código e as personalizações para a organização de produção, o valor da sua chave secreta não é enviado simultaneamente. Seus dados não são movidos para a produção com seu conjunto de alterações. Você precisa inserir o valor chave no campo manualmente ou criar um script para preenchê-lo por você. Por outro lado, com um tipo de metadados personalizado, sua chave secreta de API é tratada como qualquer outra personalização e é movida para a produção. Neste cenário, você não precisa inseri-la novamente.

Lembre-se que para carregar dados em uma configuração personalizada, você precisa criar um script pós-instalação. Mas não é necessário codificar scripts com tipos de metadados personalizados protegidos. Os dados contidos em um tipo de metadados personalizados são disponibilizados como metadados diferentes, que você pode adicionar ao pacote. Isso é muito bom, certo?

Uma das coisas mais legais dos tipos de metadados personalizados é que você pode pegá-los usando SOQL, exatamente como você faria com qualquer objeto personalizado. A única diferença é que os tipos de metadados têm um sufixo __mdt em vez de __c. Se você precisasse selecionar um tipo de metadados personalizados, escreveria uma consulta assim:

SELECT Teacher__c, Coach__c, Counselor__c , Administrator__c FROM District_Profiles__mdt

Essa linha recupera todos os valores de District_Profiles__mdt. É bem fácil!

Comparar configurações personalizadas e tipos de metadados personalizados

Embora você possa usar tanto as configurações personalizadas quanto os tipos de metadados personalizados para proteger segredos, existem algumas diferenças entre os dois que devem ser observadas. Vamos rever quando usar cada um deles.

Use as configurações personalizadas protegidas quando:

O segredo deve ser atualizado com frequência e estar disponível imediatamente. Como os tipos de metadados precisam ser consultados e implantados, os segredos atualizados nos tipos de metadados não estão disponíveis de imediato. Isto faz com que uma configuração personalizada seja a melhor opção aqui.
Você deseja especificar quais perfis e usuários podem acessar quais segredos. Os tipos de metadados não oferecem a granularidade dos tipos de hierarquia de configurações personalizadas, que permitem especificar para quais perfis ou usuários os segredos devem estar disponíveis. Por isso, é melhor usar uma configuração personalizada aqui.

Use tipos de metadados personalizados quando:

Quiser implantar um segredo comum sem passar por mais etapas de configuração.
Os segredos de metadados personalizados podem ser facilmente migrados, por exemplo, de uma sandbox ou de um ambiente de desenvolvimento para um ambiente de produção. Já nas configurações personalizadas, os administradores precisam codificar scripts pós-instalação ou criar páginas e inserir e armazenar segredos manualmente no novo ambiente.

Procurando ajuda?

Descubra mais