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 personalizadas protegidas e os campos de API de metadados personalizados protegidos podem ser utilizados para armazenar segredos.

Armazenar segredos de aplicativo no Salesforce

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

Isso é fácil, pois a Salesforce Platform tem vários recursos que podem ser utilizados para armazenar e proteger segredos. Confira alguns dos recursos:

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

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

Credenciais nomeadas

Uma credencial nomeada especifica a URL de um ponto de extremidade de callout e seus parâmetros de autenticação obrigatórios em uma definição. 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 em seu 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 especialmente úteis quando se trata de 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 cada solicitação inclua 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. Considere o código de exemplo a seguir.

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 seja realmente uma solução direta, existem três problemas principais nessa abordagem.

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 no código, você pode usar credenciais nomeadas para armazenar segredos, permitindo que elas sejam referenciadas para acessar o valor do segredo como se fossem outra variável no seu código.

Se você usar uma credencial nomeada em vez do próprio valor, somente os usuários com perfil de administrador do sistema e os que tiverem permissões de Visualizar Todos os Dados e Modificar Todos os Dados poderão acessar esse valor.

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. Assim, as instâncias no seu código que fizerem referência ao segredo jamais manterão dados desatualizados, já que a referência é diretamente para a credencial nomeada.

Onde usar Credenciais nomeadas

Embora seja bastante simples configurar credenciais nomeadas, elas não são necessariamente uma boa solução para todos os casos de uso. As credenciais nomeadas são mais adequadas para esquemas de autenticação simples, como nome de usuário e senha ou OAuth 2.0.

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 Modificar todos os dados ou Autor Apex 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 de forma privada com o próprio serviço de nuvem — 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.

Proteger segredos distribuídos

As credenciais nomeadas são perfeitas para situações em que os callouts são feitos para serviços externos em uma organização cujos administradores têm acesso aos 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.

Eles têm a mecânica necessária para enviar atualizações, patches e correções por push 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 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 talvez ela seja criada para armazenar uma lista de nomes de produto que são referenciados em várias páginas diferentes, para agilizar e facilitar o acesso. 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 de metadados personalizados podem ser utilizados para armazenamento de segredos de maneira semelhante às configurações personalizadas. Para o devido sigilo, defina a visibilidade como “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 quando você usa 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 Configuração acessando Quick Find (Busca rápida) > Custom Settings (Configurações personalizadas) e clicando em New (Novo). Defina um rótulo, nome de objeto, tipo de configuração e visibilidade (defina como Protected [Protegido]). Depois de clicar em Save (Salvar), você estará pronto para adicionar campos personalizados e armazenar os segredos.

Captura de tela das configurações personalizadas. Laptop aberto na página Definição de Configurações personalizadas com campos Rótulo, Nome do objeto, Tipo de configuração, Visibilidade e Descrição.

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:

getAll()
getValues()
getOrgDetails()
getInstance(Profile_ID)

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

Map<String, CustomSettingName__c> mcs = CustomSettingName__c.getAll();

Tipos de metadados personalizados

Os tipos de metadados personalizados protegidos também podem ser definidos para manter segredos, da mesma forma que definimos anteriormente a configuração personalizada. Como explicamos, 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.

Isto pode muitas vezes se revelar vantajoso. Imagine que você é um desenvolvedor criando um novo aplicativo em sua organização de empacotamento Developer Edition. Esse aplicativo tem vários tipos de 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 qual é o erro dessa 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 ao mesmo tempo. 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 codificar 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 algum tipo de 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 precisa ser atualizado com frequência e deve 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.