O que é uma conta de serviço gerenciada pelo desenvolvedor?

Última atualização
Salvar como PDF

Para desenvolvedores que criam aplicativos usando componentes de conexão de dados, recomendamos aproveitar o novo recurso DMSA (Contas de serviço gerenciadas pelo desenvolvedor) como uma abordagem simplificada para fornecer aos administradores do Procore a capacidade de instalar e provisionar facilmente aplicativos de conexão de dados em suas contas empresariais. O recurso DMSA permite que os desenvolvedores especifiquem as permissões exatas da ferramenta no nível de empresa e de projeto para que seu aplicativo seja executado corretamente na plataforma do Procore. Os administradores da empresa definem quais projetos o aplicativo pode acessar usando essas permissões. Os desenvolvedores utilizam DMSAs para fornecer uma alternativa mais conveniente e segura às contas de serviço tradicionais. Os administradores da empresa se beneficiam dos DMSAs por meio de gestão aprimorada de aplicativos e melhor visibilidade sobre o uso dos aplicativos.

Todas as contas de serviço tradicionais terão o fim do contrato em 31 de dezembro de2024.

As contas de serviço tradicionais foram descontinuadas em 9 de dezembro de 2021. A partir de 1.º de outubro de 2024, não permitiremos mais a criação de novas contas de serviço tradicionais. As contas de serviço tradicionais existentes continuarão funcionando até 31 de dezembro de 2024.

De acordo com esta linha do tempo, os desenvolvedores de aplicativos de conexão de dados que atualmente usam contas de serviço tradicionais são obrigados a atualizar seus aplicativos para usar <a target="_blank" title=" " href.path="//faq/what-is-developer-managed-service-account" href.nome de arquivo..."> Contas de serviço gerenciadas pelo Usuário, e os clientes deverão instalar esses aplicativos atualizados antes da data de desmarcação. Todos os aplicativos de conexão de dados não migrados pela data de desmarcando deixarão de funcionar. Qualquer aplicativo listado no App Marketplace do Procore que não esteja usando um método compatível para acessar a API Procore será removido pela data de desativação. Consulte Migrando aplicativos de conexão de dados para usar DMSAs para obter informações adicionais.

Benefícios do uso de DMSAs

O uso de DMSAs em contas de serviço tradicionais proporciona uma série de benefícios:

Gestão simplificada de aplicativos: DMSAs são instalados e gerenciados por administradores da empresa usando o recurso Gestão de aplicativos na ferramenta Administrador da empresa. O usuário do Diretório associado ao DMSA é criado automaticamente como parte do processo de instalação do aplicativo. Nas contas de serviço tradicionais, os administradores da empresa precisam criar e gerenciar manualmente a conta e suas permissões de acesso, o que requer comunicação e coordenação adicionais com o desenvolvedor terceirizado para instalar e configurar o aplicativo.
Gestão mais segura de permissões: todas as permissões de ferramentas necessárias no nível de empresa e de projeto para um determinado aplicativo DMSA são definidas em um manifesto do aplicativo que é aplicado à conta empresarial durante o processo de instalação. Quando um aplicativo incorporar uma nova funcionalidade e lançar uma versão atualizada, o desenvolvedor poderá solicitar a análise e aprovação de novas permissões por meio do processo de atualização.
Controle de acesso aprimorado ao projeto: durante o processo de instalação e configuração, os administradores da empresa selecionam exatamente quais projetos o aplicativo DMSA pode usar. Com contas de serviço tradicionais, o acesso ao projeto é configurado e gerenciado manualmente pelo administrador da empresa, o que pode ser demorado e caro, além de ser menos seguro, conforme descrito abaixo.
Melhores insights sobre o uso do aplicativo: como os DMSAs são instalados usando a Gestão de aplicativos, os administradores da empresa têm visibilidade sobre o uso do aplicativo na forma de métricas do aplicativo, como o número de solicitações de API, quais usuários instalaram e/ou usaram um aplicativo, quais projetos têm permissão para usar um aplicativo e muito mais. Com as contas de serviço tradicionais, essas métricas não são coletadas nem ficam acessíveis.

Riscos associados a contas de serviço tradicionais

O processo de instalação e uso de aplicativos que utilizam contas de serviço tradicionais apresenta os seguintes riscos:

Transmissão não segura de credenciais de API: como uma conta de serviço tradicional é criada manualmente no Procore por um administrador da empresa, o conjunto exclusivo de credenciais de API geradas (client_id e client_secret) precisa ser fornecido ao desenvolvedor para concluir a configuração de integração com êxito. Infelizmente, a transmissão dessas informações sigilosas pode ocorrer por meios não seguros, como e-mail, mensagem de texto etc., deixando os dados da empresa potencialmente vulneráveis.
Falta de dados sobre o uso: se uma conta de serviço tradicional for comprometida, será difícil rastrear onde ela está sendo usada, porque a conta não gera dados de uso.
Potencial de erro humano: a necessidade de configurar e gerenciar manualmente as permissões associadas a uma conta de serviço tradicional pode ser propensa a erros e levar a um comportamento inesperado do aplicativo.

Qual a diferença do DMSA para uma conta de serviço tradicional?

Aqui estão algumas das principais diferenças entre DMSAs e contas de serviço tradicionais.

	Conta de serviço gerenciada pelo desenvolvedor	Conta de serviço tradicional
Criação de conta	Um usuário de diretório associado ao DMSA é criado automaticamente na ferramenta Diretório da empresa e/ou do projeto.	Uma conta de serviço tradicional precisa ser criada e gerenciada manualmente por um administrador da empresa.
Autorização	Um único conjunto de credenciais (client_id, client_secret) é usado para acessar todas as empresas nas quais o aplicativo está instalado.	Cada conta de serviço criada em uma empresa por um administrador tem um conjunto exclusivo de credenciais, exigindo coordenação manual com o desenvolvedor para uma integração bem-sucedida.
Permissões	As permissões necessárias são definidas pelo desenvolvedor no manifesto do aplicativo e aplicadas automaticamente durante a instalação.	As permissões para cada conta de serviço precisam ser configuradas manualmente por um administrador da empresa.
Configuração do projeto	Durante a instalação, você pode selecionar em quais projetos o aplicativo DMSA pode ser executado. Após a instalação do aplicativo, é possível adicionar ou remover projetos os permitidos conforme necessário.	O acesso ao projeto precisa ser configurado e gerenciado manualmente pelo administrador da empresa.
Gestão de aplicativos	Os aplicativos habilitados para DMSA são facilmente instalados no App Marketplace ou como uma instalação personalizada. A ferramenta Administrador da empresa (Gestão de aplicativos) é usada para desinstalar/reinstalar.	Todos os aspectos da instalação e gerenciamento de conta de serviço tradicional precisam ser tratados manualmente por um administrador da empresa.

O que verei em minha conta após instalar um aplicativo que usa DMSA?

Durante o processo de instalação, um novo cadastro de usuário poderá ser criado na ferramenta Diretório da empresas e/ou do projeto que representa o DMSA. O nome de contato do DMSA segue um formato distinto com o nome do aplicativo convertido em letras minúsculas e separado por hifens seguido por um id de oito caracteres gerado aleatoriamente. Por exemplo, a instalação do aplicativo My DMSA Test App criaria o usuário my-dmsa-test-app-469b1f7f no Diretório da empresa. É importante que você não edite nem exclua os usuários do diretório criados pelas instalações do aplicativo DMSA, pois isso pode causar problemas na operação do aplicativo.

Implicações sobre a concessão de permissões de administrador de diretório para aplicativos

Os administradores da empresa são veementemente advertidos contra a concessão de acesso de administrador à ferramenta Diretório de nível de empresa para aplicativos que usam DMSAs ou contas de serviço tradicionais. Os aplicativos com esse nível mais alto de acesso têm a capacidade de fazer alterações que podem afetar adversamente todas as ferramentas em um projeto inteiro ou todos os projetos em toda a conta empresarial Procore da sua organização. Embora alguns aplicativos possam exigir isso para funcionar, recomendamos revisar minuciosamente a necessidade da integração e entender o impacto antes de conceder tal permissão.

Compreendendo a autenticação da API do Procore

Os aplicativos criados na plataforma Procore usam o padrão do setor OAuth 2.0 Authorization Framework para autenticação com a API (Interface de programação de aplicativos). A API do Procore é compatível com os dois tipos de concessão de autorização ou fluxos de autenticação a seguir:

Credenciais de cliente (DMSAs e contas de serviço tradicionais): a maioria dos aplicativos de conexão de dados usa esse tipo de concessão para autenticação com a API. Com o tipo de concessão de credenciais do cliente, um único conjunto de credenciais de API é usado (via DMSA ou conta de serviço tradicional) para fazer a autenticação com a API do Procore. O acesso a ferramentas e dados na plataforma Procore é gerenciado pelas definições de permissões associadas a essa conta. Como resultado, os desenvolvedores e administradores da empresa podem especificar as ferramentas e projetos exatos aos quais um aplicativo terá acesso. Essa é a abordagem preferencial para aplicativos de conexão de dados. Para obter mais informações sobre o tipo de concessão de credenciais de cliente, consulte Usando o tipo de concessão de credenciais de cliente para OAuth 2.0.
Código de autorização (fluxo de login do usuário): os aplicativos baseados em servidor Web e em navegador geralmente usam esse tipo de concessão para autenticação com a API. Com o tipo de concessão de código de autorização, o aplicativo opera em nome do usuário atualmente conectado ao autenticar com a API do Procore. Nesse cenário, o aplicativo assume as permissões do usuário conectado e tem acesso a qualquer ferramenta, projeto ou dados com os quais esse usuário específico tem permissão para interagir. Como a governança de permissões pode ser desafiadora sob esse tipo de concessão, ele não é recomendado para aplicativos de conexão de dados. Para obter mais informações sobre o tipo de concessão de código de autorização, consulte Fluxo de concessão de código de autorização para OAuth 2.0.

Os administradores da empresa do Procore são responsáveis por gerenciar as permissões de seus usuários de diretório, independentemente do tipo de concessão de autorização usado por uma integração: authorization_code (permissões do usuário conectado) ou client_credentials (permissões de conta de serviço/DMSA).

Modelo de segurança de responsabilidade compartilhada

Como fornecedor de SaaS (Software como serviço), o Procore segue um modelo de responsabilidade compartilhada no contexto da segurança da plataforma.

Os clientes são responsáveis pelas integrações que instalam, pelas permissões que aprovam para uso dessas integrações e por quaisquer alterações que façam em usuários do diretório (DMSA ou tradicional) associados a essas integrações além do que o Procore fornece.
Os Parceiros/Desenvolvedores são responsáveis pelo gerenciamento das credenciais, do código que chama a API e do que fazem com os dados. O cliente fornece as chaves aos Desenvolvedores para serem usadas pelos Desenvolvedores.
O Procore é responsável por fornecer aos desenvolvedores um meio de solicitar permissões de clientes usando OAuth e por fornecer aos clientes a capacidade de instalar e gerenciar aplicativos.

Pôr do sol das contas de serviço tradicionais