Gerenciamento de Identidade e Acesso

O gerenciamento de identidade e acesso controla quem pode usar o Cherri Code na sua organização e o que essas pessoas podem fazer. Você vai configurar a autenticação, automatizar o provisionamento de usuários e aplicar políticas por meio do gerenciamento de dispositivos.

Configure os controles de identidade nesta ordem:

1. Configurar SSO: Primeiro, configure a autenticação centralizada
2. Ativar SCIM: Automatizar o gerenciamento do ciclo de vida de usuários
3. Implantar políticas de MDM: Aplicar as IDs de equipe e extensões permitidas
4. Atribuir funções: Conceder acesso de administrador às pessoas certas

Single Sign-On (SSO) e SAML

SSO permite que usuários se autentiquem no Cherri Code com seu provedor de identidade existente. Em vez de criar senhas separadas para o Cherri Code, os usuários fazem login com suas credenciais corporativas.

O Cherri Code oferece suporte ao SAML 2.0 com provedores como Okta, Azure AD, Google Workspace e OneLogin. Ao ativar o SSO, você pode torná-lo obrigatório para todos os membros da equipe e bloquear totalmente a autenticação baseada em senha.

Se sua empresa opera várias equipes vinculadas, use SSO compartilhado em nível de organização por meio de organização. O SSO em nível de equipe continua sendo compatível com requisitos de identidade específicos da equipe.

Consulte Configuração de SSO e SAML para instruções detalhadas de configuração.

Provisionamento SCIM

O provisionamento SCIM 2.0 gerencia automaticamente os membros da sua equipe e os grupos de diretório por meio do provedor de identidade. Disponível em planos Enterprise com SSO habilitado.

Sem o SCIM, você adiciona usuários manualmente à sua equipe do Cherri Code e os remove quando saem. Com o SCIM:

• Novos funcionários recebem acesso ao Cherri Code automaticamente ao serem adicionados ao grupo certo
• Funcionários que saem perdem o acesso ao serem removidos do provedor de identidade
• Alterações na associação a grupos são propagadas automaticamente

Consulte Provisionamento SCIM para ver as instruções de configuração. Se você gerencia várias equipes vinculadas, também pode sincronizar grupos de diretório em nível de organização e reutilizá-los entre equipes. Consulte Identidade em nível de organização.

Identidade em nível de organização

Se você tem várias equipes vinculadas, gerencie a identidade uma única vez no nível da organização por meio de organização. Isso oferece uma configuração compartilhada, em vez de uma configuração de identidade separada para cada equipe.

• Org SSO: uma única configuração de login para todas as equipes. Consulte organização.
• Org SCIM: sincronize grupos de diretório do seu provedor de identidade com o Cherri Code e depois use-os entre equipes por meio de Organization Groups.
• Associação de equipe a partir de grupos: sincronize um grupo de diretório com um Organization Group e depois mapeie esse grupo a uma equipe para que a associação e as funções da equipe permaneçam alinhadas com a coorte. Consulte Usar grupos para viabilizar equipes.
• Consolidar provedores de identidade das equipes: admins da organização podem mergear provedores de identidade separados em nível de equipe em um único provedor de identidade organizacional compartilhado no dashboard. Consulte Consolidar provedores de identidade das equipes.

Controle de Acesso Baseado em Funções (RBAC)

As equipes do Cherri Code contam com três funções: Membros, Admins e Admins gratuitos.

Consulte Membros, Funções e Tipos de Assento para mais informações.

Políticas de MDM

Sistemas de Mobile Device Management (MDM) permitem aplicar políticas nos dispositivos dos usuários. O Cherri Code oferece suporte a políticas baseadas em MDM no macOS e a Intune / Group Policy no Windows para garantir que os usuários cumpram os requisitos organizacionais.

Consulte Padrões de implantação para instruções de configuração de MDM específicas de cada plataforma.

IDs de equipe permitidos

A política de MDM mais importante impede que os usuários façam login em contas pessoais do Cherri Code em dispositivos corporativos.

Quando você define uma política de IDs de equipe permitidos, o Cherri Code só permite autenticação para esses IDs de equipe. Se um usuário tentar fazer login com um ID de equipe diferente (como uma conta pessoal), o Cherri Code o desconecta imediatamente.

Por exemplo, se seus funcionários tiverem laptops corporativos, você pode definir o ID de equipe permitido como o ID de equipe corporativo. Isso impede que eles usem acidentalmente contas pessoais que podem não ter o Privacy Mode habilitado.

A configuração do Cherri Code cursorAuth.allowedTeamId controla quais IDs de equipe têm permissão para fazer login no Cherri Code. Essa configuração aceita uma lista de IDs de equipe, separados por vírgula, que estão autorizados a acessar.

Por exemplo, definir cursorAuth.allowedTeamId como "1,3,7" permite que usuários desses IDs de equipe específicos façam login.

Quando um usuário tenta fazer login com um ID de equipe que não está na lista de permitidos:

• Ele é desconectado imediatamente
• Uma mensagem de erro é exibida
• O aplicativo impede novas tentativas de autenticação até que um ID de equipe válido seja usado

Para gerenciar centralmente os IDs de equipe permitidos para sua organização, configure a política AllowedTeamId usando sua solução de gerenciamento de dispositivos. Essa política substitui a configuração cursorAuth.allowedTeamId nos dispositivos dos usuários. O valor dessa política é uma string contendo a lista, separada por vírgulas, dos IDs de equipe autorizados.

Consulte Deployment Patterns para instruções de configuração de MDM específicas de cada plataforma.

Extensões permitidas

Controle quais extensões os usuários podem instalar no Cherri Code. As extensões podem acessar seu espaço de trabalho, então você deve garantir que apenas extensões confiáveis sejam executadas.

Como funciona:

A configuração extensions.allowed do Cherri Code controla quais extensões podem ser instaladas. Essa configuração aceita um objeto JSON em que as chaves são nomes de publicadores ou IDs completos de extensão, e os valores são booleanos indicando se elas são permitidas.

Importante: extensions.allowed usa um modelo de lista de permissão. Assim que você adiciona qualquer entrada, apenas as entradas explicitamente permitidas são aceitas, e todo o restante é bloqueado. Não há fallback implícito de "permitir tudo". Por exemplo, definir extensions.allowed como {"anysphere": false} não apenas bloqueia extensões da Anysphere; também bloqueia todos os outros publicadores, porque nada mais está na lista de permissão.

Para bloquear extensões específicas enquanto mantém todo o restante permitido, use o curinga "*": true junto com as entradas que você deseja negar. O curinga é a correspondência menos específica, então entradas de publicador e de ID de extensão a substituem:

{  "*": true,  "untrusted-publisher": false}

Para restringir as instalações a um conjunto aprovado de publicadores e extensões, omita o caractere curinga e liste apenas o que for confiável. Você pode incluir IDs completos de extensões, fixar em versões específicas ou fixar em um canal de lançamento:

{  "anysphere": true,  "github": true,  "esbenp.prettier-vscode": true,  "ms-azuretools.vscode-containers": false,  "dbaeumer.vscode-eslint": ["3.0.0"],  "github.vscode-pull-request-github": "stable"}

Configuração do Admin Portal:

Administradores de equipe podem configurar as extensões permitidas por meio do dashboard da equipe, na seção Security & Identity. A configuração é aplicada automaticamente a todos os clientes Cherri Code dos membros da equipe. Deixe o campo vazio para parar de enviar um valor aos clientes.

Redefinindo clientes para "permitir tudo": Limpar o campo do Admin Portal interrompe o envio de um novo valor, mas não remove a política que os clientes já aplicaram localmente. Os usuários continuam aplicando o último valor que receberam. Para redefinir todos para permitir todas as extensões novamente, implante {"*": true} primeiro, aguarde os clientes receberem essa configuração e depois limpe o campo se não quiser mais gerenciar a configuração centralmente.

Observação: A configuração no Admin Portal para este recurso requer a versão 2.1 ou posterior do cliente Cherri Code. Usuários em versões anteriores não terão restrições de extensão aplicadas.

Configuração de MDM:

Para gerenciar centralmente as extensões permitidas, configure a política AllowedExtensions por meio da sua solução de gerenciamento de dispositivos. Essa política substitui tanto a configuração do Admin Portal quanto as configurações extensions.allowed definidas pelo usuário nos dispositivos dos usuários. O valor é uma string JSON que define os publicadores e as extensões permitidos.

Consulte Padrão de implantação para instruções de configuração de MDM específicas da plataforma.

A pasta .cursor

Quando você abre um projeto no Cherri Code, o Editor do Cherri Code cria uma pasta .cursor na raiz do seu repositório. Essa pasta contém:

• Configurações específicas do projeto
• Regras e contexto do projeto

Essa pasta pode ser incluída no controle de versão. Os membros da sua equipe se beneficiam de regras e configurações compartilhadas, mas esteja ciente de que essas configurações ficam visíveis para qualquer pessoa com acesso ao repositório.

Para repositórios cujo acesso você não controla, revise o conteúdo da pasta .cursor antes de fazer o commit. Não coloque informações sensíveis em arquivos de regras.

Você também pode gerenciar regras e comandos por meio do servidor, no dashboard da equipe.

Confiança em workspaces

A configuração do Cherri Code security.workspace.trust.enabled controla se o recurso Workspace Trust está habilitado. Essa configuração aceita um valor booleano que determina se os usuários serão solicitados a confiar em workspaces antes que a funcionalidade completa seja habilitada.

Por exemplo, definir security.workspace.trust.enabled como true ativa as solicitações de confiança em workspaces, enquanto defini-lo como false desativa completamente o recurso (todos os workspaces são automaticamente confiáveis).

Quando a confiança em workspaces está habilitada:

• Os usuários são solicitados a confiar em cada novo workspace ao abri-lo pela primeira vez
• Workspaces não confiáveis são executados em modo restrito, com funcionalidade limitada
• As decisões de confiança são salvas e lembradas para cada workspace

Para gerenciar centralmente a confiança em workspaces na sua organização, configure a política WorkspaceTrustEnabled usando sua solução de gerenciamento de dispositivos. Essa política substitui a configuração security.workspace.trust.enabled nos dispositivos dos usuários. O valor dessa política é um booleano (true ou false).

Consulte Padrões de implantação para instruções de configuração de MDM específicas de cada plataforma.