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.
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.
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.
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 |
|
|
| Autorização |
|
|
| Permissões |
|
|
| Configuração do projeto |
|
|
| Gestão de aplicativos |
|
|
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.
O gerenciamento de permissões para uma DMSA (Conta de serviço gerenciada pelo desenvolvedor) envolve uma consideração cuidadosa para garantir a funcionalidade do aplicativo e a segurança da conta. Veja abaixo práticas recomendadas e importantes considerações para gerenciar permissões de forma eficaz.
Use a guia Permissões para associação ao projeto: para gerenciar o acesso ao projeto DMSA, incluindo adicionar ou remover associações de projeto, utilize a guia Permissões no aplicativo em Gestão de aplicativos. Essa opção está disponível para administradores da empresa.
Reconfiguração de permissões na atualização ou reinstalação de aplicativos: sempre que um aplicativo for atualizado ou reinstalado, os administradores da empresa precisarão reconfigurar a lista de projetos permitidos. Projetos futuros que exijam acesso DMSA também devem ser adicionados manualmente à lista de permitidos.
Usando a ferramenta Diretório para modelos de permissões: alguns administradores usam a ferramenta Diretório com um modelo de permissões para simplificar o gerenciamento de DMSA:
Evitar atualizações manuais nas permissões DMSA: o ajuste manual das permissões DMSA na ferramenta Diretório geralmente é desencorajado, pois pode levar a inconsistências e complicar o gerenciamento de contas.
Limitar o acesso do DMSA à ferramenta Diretório de nível de empresa - Evite conceder acesso de nível de administrador à ferramenta Diretório de nível de empresa para o usuário do DMSA. Esse nível de acesso permite alterações em vários projetos e ferramentas em sua conta Procore, o que pode afetar os fluxos de trabalho da sua organização. Só permita esse nível de acesso se for absolutamente necessário para a integração e garanta que você entenda completamente as implicações.
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:
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).
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.