---
title: Administração
slug: Lseo-administracao
createdAt: 2026-10-23T17:05:49.825Z
---

## <font color="#22C55E">Pessoas e convites</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/shAHid294IWhuQEUVZVGZ_image.png" size="137" caption="Tela: Pessoas e convites" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

**Admin › Usuários e perfis** é onde os administradores decidem quem usa o Hive. A aba **Pessoas&#x20;**&#x63;onvida por e-mail e muda perfis e situação; **Equipes** agrupa pessoas para compartilhar painéis; **Grupos do diretório** dá acesso automático aos membros de grupos do diretório (just-in-time) e configura o provisionamento SCIM. Ninguém precisa de senha criada à mão. Perfis e métodos de login têm abas próprias: veja Perfis e permissões e Métodos de login.

***

### O que você pode fazer aqui

- &#x20;Convidar uma ou várias pessoas de uma vez e escolher os perfis delas.
- &#x20;Buscar pessoas por nome ou e-mail e filtrar pela **Situação** (Ativa, Convidada, Desativada).
- &#x20;**Editar** uma pessoa: mudar perfis, desativar ou religar o acesso.
- &#x20;**Reenviar convite** para quem ainda não entrou.
- &#x20;**Zerar autenticador** de quem perdeu o celular.
- &#x20;Criar **Equipes** para compartilhar painéis com várias pessoas de uma vez.
- &#x20;Mapear **Grupos do diretório** para perfis, ver a prévia de quem ganharia acesso e criar tokens SCIM.

***

### Convidar pessoas

Clique em **Convidar pessoas** na aba **Pessoas**. O assistente tem três passos.

Digite um ou mais endereços em **Endereços de e-mail**, um por linha. Quem já tem acesso é ignorado e listado à parte no final.

Escolha um ou mais **Perfis**. O primeiro perfil vira o ativo. Dá para mudar os perfis depois com **Editar**.

Revise e envie. Se as contas locais estiverem ligadas, cada pessoa recebe um e-mail para definir a senha. Só com SSO, nenhum e-mail é enviado: compartilhe o endereço de entrada mostrado no final— as pessoas entram com a conta da empresa e são reconhecidas pelo e-mail.

No final o Hive mostra " pessoas convidadas.", se os e-mails foram enviados, quem **Já tinham acesso (ignoradas)** e o **Endereço de entrada da sua empresa** com botão de copiar, caso algum e-mail não chegue.

***

### Editar, desativar e zerar

1. Na linha da pessoa, clique em **Editar**. A janela **Acesso de&#x20;**&#x20;lista os perfis em cartões; os privilegiados dizem "Privilegiado: sempre pede MFA."
   2\. Marque ou desmarque perfis. As mudanças valem na próxima ação da pessoa, sem novo login.
2. Use a chave **Ativa / Desativada** para cortar o acesso. Confirme **Desativar acesso**: a entrada para na hora, no Hive e na conta local; o histórico e a auditoria ficam. Religue do mesmo jeito. 4. **Reenviar convite** aparece só para pessoas com situação **Convidada**.
3. **Zerar autenticador** aparece para pessoas ativas (não para você mesmo). As sessões da pessoa terminam e ela cadastra o aplicativo de novo na próxima entrada.

***

### Equipes

Equipes são grupos de pessoas usados para compartilhar painéis.

1. Abra a aba **Equipes** e clique em **Nova equipe**.
2. Preencha **Nome** e **Descrição**, procure pessoas em **Procurar pessoas** e marque-as ("Pessoas na equipe (n)").
3. Clique em **Salvar**. Excluir uma equipe faz os painéis compartilhados com ela deixarem de aparecer para as pessoas dela, a não ser que tenham sido compartilhados com elas diretamente.

***

### Grupos do diretório, prévia do escopo e SCIM

Na aba **Grupos do diretório**:

1. Clique em **Incluir grupo**, digite o nome do **Grupo do diretório** e escolha o **Perfil concedido**. Repita para outros grupos e clique em **Salvar mapeamentos**.
2. Quem entra com a conta da empresa e está num grupo mapeado ganha o perfil sem convite manual (JIT). Quem sai do grupo perde no próximo acesso.
3. **Prévia do escopo** › **Ver prévia** mostra, com o mapeamento da tela (mesmo antes de salvar), quantas **Contas habilitadas no diretório** existem, quem **Entrariam**, quem **Ficam de fora (sem grupo mapeado)**, quem está **Em mais de um perfil**, quem **Já são pessoas no Hive** e os grupos com gente e sem perfil — pelo que a sincronização do Active Directory trouxe.
4. **Provisionamento SCIM (Entra ID, Okta, Google)**: digite um **Nome** e clique em **Criar token SCIM**. Copie na hora a **URL do locatário (base do SCIM)** e o **Token secreto** — o token aparece só esta vez — e cole no provisionamento automático do provedor. O provedor passa a criar, atualizar e desativar pessoas no Hive; os grupos dele viram perfis pelo mesmo mapeamento.

Pessoa removida no provedor é desativada no Hive (o histórico fica). **Revogar** interrompe o provisionamento até um novo token ser criado.

***

### Exemplo prático: convidar a Ana Souza para o service desk

Ana Souza entra no service desk da Aurora na segunda-feira. A empresa usa contas locais, e o perfil **Service desk N1** já existe (veja Perfis e permissões).

1. Abra **Admin › Usuários e perfis › Pessoas** e clique em **Convidar pessoas**.
2. Em **Endereços de e-mail** digite ana.souza\@aurora.example e avance.
3. Em **Perfis** marque só **Service desk N1** e avance.
4. Revise e envie. O Hive mostra "1 pessoa convidada. Cada pessoa recebe um e-mail para definir a senha." e o endereço de entrada https\://aurora.hive.example .
5. A lista Pessoas mostra ana.souza\@aurora.example com situação **Convidada** e "ainda não" em **Último acesso**. O cartão **Convites ainda não aceitos** do Início conta a Ana até ela entrar.&#x20;
6. Abra a aba **Equipes**, clique em **Nova equipe**, nome Service desk , descrição Analistas N1 e N2 , procure ana , marque a Ana Souza e clique em **Salvar** ("Equipe salva").
7. Um supervisor compartilha o painel **Service desk — alertas abertos** com a equipe **Service desk**: a Ana vê o painel assim que entrar.
8. Na terça a Ana ainda não tinha o e-mail (foi para o spam). Clique em **Reenviar convite** na linha dela ("Convite reenviado para ana.souza\@aurora.example."). O link do convite vale por 72 horas.
9. A Ana cria a senha; a situação vira **Ativa** e **Último acesso** mostra quando ela entrou.

***

### Exemplo prático: dar acesso por grupo do diretório

A Aurora quer que todo membro do grupo do AD GG-ServiceDesk ganhe **Service desk N1** sem convites.

1. Em **Grupos do diretório**, clique em **Incluir grupo**, digite GG-ServiceDesk e escolha **Service desk N1**.
2. Clique em **Ver prévia** antes de salvar: 42 contas habilitadas no diretório, 18 entrariam, 24 ficam de fora, 0 em mais de um perfil, 3 já são pessoas no Hive.
3. Clique em **Salvar mapeamentos** ("1 mapeamento salvo."). Na próxima vez que um dos 18 entrar com a conta da empresa, a pessoa aparece em **Pessoas** com **Service desk N1**.

***

### Cuidados e limites

- &#x20;Toda pessoa precisa de pelo menos um perfil.
- &#x20;Você não pode desativar o próprio acesso, e o Hive nunca deixa desativar o último administrador ativo.
- &#x20;O plano da sua empresa pode limitar o número de pessoas; um convite além do limite é recusado com uma mensagem clara — desative quem saiu.
- &#x20;Equipes só compartilham painéis; o acesso às telas vem sempre dos perfis.
- &#x20;A prévia do escopo usa o que a sincronização do Active Directory já trouxe; grupos que a sincronização não leu aparecem como "não está no diretório".
- &#x20;Cada ação (convite, reenvio, mudança de perfil, desativação, mudança de mapeamento, provisionamento SCIM) fica na Trilha de auditoria.

***

### Relacionados

- &#x20;Perfis e permissões
- &#x20;Métodos de login
- &#x20;Como entrar
- &#x20;Diretório e máquinas sem agente

***

## <font color="#22C55E">Perfis e permissões</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/_s2kWckFgPUKDi-DaeX9I_image.png" size="137" caption="Tela: Perfis e permissões" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

Um perfil diz quais telas a pessoa vê, o que ela pode mudar nelas, quais ações sensíveis pode executar e quais dados alcança (escopo). Uma pessoa pode ter vários perfis e trocar o ativo no menu do usuário. Os perfis ficam em **Admin › Usuários e perfis › Perfis**.

***

### O que você pode fazer aqui

- &#x20;Ver cada perfil com o tipo (**Padrão** ou **Criado pela empresa**), a etiqueta **Privilegiado · MFA sempre**, quantas pessoas o têm, quantas permissões e a política de MFA.
- &#x20;Criar um perfil com **Novo perfil**, ou partir de um existente com **Duplicar e ajustar**.
- &#x20;Editar um perfil: nome, permissões por tela, marca de privilegiado, política de MFA e escopo de dados.
- &#x20;Comparar versões campo a campo e restaurar uma antiga.
- &#x20;Definir o nível do operador do perfil (T0, T1, T2).
- &#x20;Excluir um perfil criado pela empresa que ninguém tenha.

***

### Perfis padrão

Toda empresa começa com: Administrador da plataforma, Analista de infraestrutura / NOC, Analista de segurança, Técnico de suporte (N1/N2), Gestor de licenças (SAM), Analista de ativos (HAM), Gestor / executivo, Auditor e Usuário final. Administrador da plataforma, Analista de segurança e Auditor são privilegiados. Perfis padrão podem ser editados mas não excluídos; "Perfis padrão podem ser duplicados e ajustados; o original nunca muda."

***

### Criar ou editar um perfil

Clique em **Novo perfil** (ou em **Editar** / **Duplicar e ajustar** numa linha). O editor é um assistente.

Dê ao perfil um **Nome do perfil** claro e diga **Para quem é**.

Marque na matriz as telas que o perfil pode **Ver** e **Editar** e as ações específicas dele. Marque **Perfil privilegiado (sempre exige MFA)** quando ele puder mudar acessos ou executar ações sensíveis: perfis privilegiados sempre exigem o aplicativo autenticador.

Limite os dados que o perfil vê por **Sites**, **Tags** e **Grupos**. Deixe vazio para ver tudo.

O último passo, **Revisar**, mostra o perfil inteiro antes de salvar. Um perfil novo é salvo com a primeira versão; na edição, **Salvar alterações** cria uma versão nova ("Perfil salvo (versão n). Vale na próxima ação de cada pessoa.") com **Desfazer** na mensagem.

***

### A matriz de permissões

- &#x20;A matriz lista todas as telas do menu, agrupadas por espaço (Ativos, Mapas, Monitorar, Segurança, Governança, Entrega, Integrações, Admin).
- &#x20;Colunas: **Tela**, **Ver**, **Editar** e **Ações específicas** (por exemplo **Aprovar acesso sem assistência&#x20;**&#x65;m Acesso remoto, **Exportar auditoria** na Trilha de auditoria, **Aprovar suporte do fornecedor&#x20;**&#x65;m Configurações da empresa).
- &#x20;Marcar **Editar** ou uma ação também marca **Ver**; desmarcar **Ver** limpa a linha. A caixa na linha do espaço marca a coluna inteira daquele espaço.
- &#x20;**Procurar tela ou ação** filtra as linhas, **Só marcadas** esconde o que está desligado, e o contador mostra " de  marcadas".
- &#x20;Ações com escudo são sensíveis: "Ações sensíveis devem ficar só em perfis privilegiados, que sempre exigem MFA."
- &#x20;Telas não marcadas somem do menu de quem tem o perfil; um link direto mostra "Esta tela não está disponível para o seu perfil".

***

### Versões e nível do operador

Ao editar um perfil existente, dois painéis aparecem ao lado do assistente:

- &#x20;**Versões**: cada salvamento é uma versão (v1, v2…, a mais nova marcada **atual**). Clique numa anterior para comparar campo a campo (permissões, escopo, MFA em nomes legíveis) e clique em **Restaurar a versão n**. A restauração vira uma versão nova, então dá para voltar de novo.
- &#x20;**Nível do operador**: escolha o **Nível deste perfil** — "T2 · Estações", "T1 · Servidores" ou "T0 · Tier 0" — ou **Sem restrição de camada**. Um operador T2 age só em estações de trabalho, T1 só em servidores e T0 só no Tier 0. Uma pessoa pode ter um nível próprio, que vale mais que o do perfil.

***

### Exemplo prático: um perfil "Service desk N1"

A Aurora quer que os analistas de primeiro nível vejam ativos e alertas e abram sessões remotas, mas não aprovem acesso sem assistência e não vejam mais nada.

1. Abra **Admin › Usuários e perfis › Perfis** e clique em **Novo perfil**.
2. **Nome**: **Nome do perfil**Service desk N1 ; **Para quem é**Analistas do service desk de primeiro nível .&#x20;
3. **Permissões**: digite ativos em **Procurar tela ou ação** e marque **Ver** em **Todos os ativos**. Limpe a busca e marque **Ver** em **Alertas e eventos** (Monitorar) e **Ver** e **Editar** em **Acesso remoto&#x20;**(Segurança). Deixe **Aprovar acesso sem assistência** desmarcado. O contador mostra "4 de … marcadas".
4. Deixe **Perfil privilegiado** desligado e escolha **Política de MFA** "Obrigatório fora da rede da empresa".
5. **Escopo dos dados**: em **Sites** digite São Paulo para que os analistas vejam só esse escritório.&#x20;
6. **Revisar** e salve: "Perfil Service desk N1 salvo. Ele está na trilha de auditoria e já tem a primeira versão."
7. Convide a Ana Souza com esse perfil (veja Pessoas e convites). Quando ela entra, o menu mostra só Início, **Ativos › Todos os ativos**, **Monitorar › Alertas e eventos**, **Segurança ›** **Acesso remoto** e Ajuda. Ela pode iniciar uma sessão remota, mas aprovar acesso sem assistência não aparece para ela; se abrir /settings por um link, vê "Esta tela não está disponível para o seu perfil".

***

### Exemplo prático: desfazer uma mudança errada

Duas semanas depois alguém marca **Editar** em **Todos os ativos** no **Service desk N1** por engano.

1. Abra o perfil com **Editar**; o painel **Versões** mostra v2 (atual) e v1.
2. Clique em v1: a comparação mostra a permissão que entrou na v2.
3. Clique em **Restaurar a versão 1** e confirme. O Hive responde "Versão restaurada como v3."; os valores da v1 voltam a valer e toda a história fica na lista e na Trilha de auditoria.

***

### Cuidados e limites

- &#x20;Um perfil precisa de pelo menos uma permissão.
- &#x20;Perfis padrão não podem ser excluídos. Um perfil da empresa só pode ser excluído quando ninguém o tem ("Move them to another profile first." — mova as pessoas para outro perfil antes).
- &#x20;O perfil Administrador da plataforma precisa manter a administração de usuários e de perfis; o Hive recusa mudanças (ou restaurações) que deixariam os administradores sem acesso.
- &#x20;Nesta versão a entrada exige o autenticador só para perfis privilegiados. Os outros valores da política de MFA ("Sempre obrigatório", "Obrigatório fora da rede da empresa", "Como o provedor de identidade decidir") ficam salvos e aparecem no perfil, mas não bloqueiam a entrada sozinhos. Marque o perfil como privilegiado quando o MFA precisar ser obrigatório.
- &#x20;As mudanças valem na próxima ação de cada pessoa; ninguém precisa entrar de novo.
- &#x20;Restaurar uma versão exige permissão para mudar configuração.

***

### Relacionados

- &#x20;Pessoas e convites
- &#x20;Métodos de login
- &#x20;Acesso remoto
- &#x20;Trilha de auditoria

***

## <font color="#22C55E">Métodos de login</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/UiWAyj0oqwBW1nlzaPLHG_image.png" size="137" caption="Tela: Métodos de login" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

**Admin › Usuários e perfis › Autenticação** decide como as pessoas entram na sua empresa. O Hive tem a própria página de entrada: senhas, códigos do autenticador, convites e trocas de senha acontecem nela, sem mandar as pessoas para outro lugar. Só os métodos de conta da empresa (OIDC e SAML) vão ao provedor de identidade e voltam. O Keycloak também pode ser usado só como **fonte de usuários**: o Hive lê as contas e confere a senha lá, e as pessoas nunca veem a tela do Keycloak.

***

### O que você pode fazer aqui

- &#x20;Ligar ou desligar cada método: **OIDC / OAuth 2.0**, **SAML 2.0**, **LDAP / Active Directory** e **Conta local + MFA**. Pelo menos um método sempre fica ligado.
- &#x20;**Configurar** OIDC e SAML com um assistente e testar a entrada.
- &#x20;Usar o **Keycloak como fonte de usuários** e **Trazer agora** as contas.
- &#x20;Ver a **Política de MFA por perfil**.
- &#x20;Decidir os pedidos de acesso de suporte do provedor de serviços (veja Acesso de suporte do provedor de serviços).

***

### OIDC / OAuth 2.0

Clique em **Configurar** no cartão **OIDC / OAuth 2.0**.

Escolha o **Provedor de identidade**: Microsoft Entra ID, Google, Okta, Keycloak, Auth0 ou qualquer provedor OIDC. **Texto do botão (opcional)** muda o que o botão de entrada diz.

Cole o **Endereço de descoberta** do provedor (termina em /.well-known/openid-configuration ), o **ID do cliente** e o **Segredo do cliente (guardado no cofre)**. O segredo vai para o cofre e nunca mais aparece.

Depois de **Revisar**, o Hive mostra o endereço de retorno para cadastrar no provedor ("é a única coisa para copiar") e **Testar a entrada**: abra o endereço numa janela anônima e escolha "Entrar com a conta da empresa". O método fica salvo e ligado.

***

### SAML 2.0

Clique em **Configurar** no cartão **SAML 2.0**. O Hive conversa direto com o provedor SAML (ADFS, Entra, Okta e outros).

Informe o **Endereço dos metadados do provedor**: o Hive lê sozinho o endereço de login e o certificado de assinatura. No provedor, cadastre o Hive com os nossos metadados, em
/api/v1/public/auth/\<empresa>/saml/metadata , e envie o e-mail como NameID (e, se quiser, os grupos num atributo "groups"). O Hive confere a assinatura, a validade, o público e o pedido de cada resposta. Asserções criptografadas não são aceitas.

### LDAP / Active Directory

Usuário e senha do domínio digitados na página do Hive. O **coletor** da conexão do Active Directory confere a senha no controlador de domínio via LDAPS (com o certificado fixado) e devolve só "confere ou não", com nome, e-mail e grupos; a senha não fica guardada em lugar nenhum. Quem ainda não tem acesso entra se um dos seus grupos do AD estiver mapeado para um perfil; conta desativada no AD perde o acesso no Hive.

Nesta versão o cartão mostra "Aplicado pelo coletor — chega na F1." e o botão **Configurar** fica desabilitado. O Hive só aceita este método quando existe uma conexão do Active Directory com coletor ("Connect the Active Directory first.").

***

### Conta local + MFA

As pessoas entram com e-mail e senha na página do Hive. O convite chega por e-mail com um link para criar a senha; perfis privilegiados cadastram o aplicativo autenticador na primeira entrada. Em **Pessoas**, **Zerar autenticador** ajuda quem perdeu o celular. Use para instalações sem provedor de identidade, contas de emergência e auditores externos.

***

### Keycloak como fonte de usuários

1. Clique em **Conectar na Central de integrações**. Na conexão do Keycloak preencha **Endereço do Keycloak**, **Realm**, **ID do cliente (conta de serviço com view-users e concessão de senha)** e **Segredo do cliente**, e ligue o uso **Usuários da plataforma**.
2. De volta a **Autenticação**, clique em **Trazer agora** ou espere: o Hive traz as contas de hora em hora. O resultado diz "Lidas  · novas  · desativadas  · sem grupo mapeado ".
3. Mapeie os grupos do Keycloak para perfis em **Grupos do diretório**. Quem está num grupo mapeado ganha acesso; quem foi desativado no Keycloak perde.
4. As pessoas digitam a senha do Keycloak na página do Hive; o Hive confere no Keycloak por trás. Perfis e permissões ficam só no Hive, e nada é gravado no Keycloak.

O Keycloak também aparece como provedor OIDC. Escolha essa opção só se quiser que as pessoas vão à página do Keycloak para entrar; para manter a página de entrada do Hive, use o Keycloak como fonte de usuários.

***

### Política de MFA por perfil

A tabela lista cada perfil e a política de MFA dele; perfis privilegiados sempre exigem MFA, mesmo que o provedor de identidade não peça. Mude a política no editor do perfil (veja Perfis e permissões).

***

### Exemplo prático: entrada com Entra ID na Aurora

1. No Entra ID, registre um aplicativo "Hive", anote o ID do cliente e crie um segredo.
2. No Hive, abra **Admin › Usuários e perfis › Autenticação** e clique em **Configurar** em **OIDC / OAuth 2.0**.
3. **Provedor de identidade**: Microsoft Entra ID; **Texto do botão (opcional)**: Conta Aurora .&#x20;
4. **Endereço de descoberta**: https\://login.microsoftonline.com/\<tenant-id>/v2.0/.well-known/openid- configuration ; **ID do cliente** e **Segredo do cliente**.
5. Revise e salve: "Microsoft Entra ID salvo e ligado." Copie o endereço de retorno mostrado e inclua-o como URI de redirecionamento do aplicativo no Entra.
6. Abra o endereço da empresa numa janela anônima: o botão **Conta Aurora** aparece acima dos campos de e-mail e senha. Entre para testar.
7. Mapeie o grupo do Entra GG-Hive-NOC para **Analista de infraestrutura / NOC** em **Grupos do diretório**: os analistas do NOC ganham acesso na primeira entrada.

***

### Exemplo prático: Keycloak como única fonte de contas

A Aurora guarda as contas no Keycloak em https\://sso.aurora.example , realm aurora .

1. Conecte o Keycloak na Central de integrações com um cliente que tenha view-users e a concessão de senha, e ligue **Usuários da plataforma**.
2. Ligue **Conta local + MFA** (os campos de e-mail e senha são onde a senha do Keycloak é digitada).
3. Clique em **Trazer agora**: "Lidas 120 · novas 118 · desativadas 2 · sem grupo mapeado 40". 4. Mapeie o grupo hive-admins para Administrador da plataforma. Os membros digitam e-mail e senha do Keycloak na página do Hive e cadastram o aplicativo autenticador na primeira entrada, porque o perfil é privilegiado.

***

### Cuidados e limites

- &#x20;O Hive sempre mantém pelo menos um método ligado; desligar o último é recusado.
- &#x20;Desligar um método pede confirmação: "Quem entra por este método vai precisar de outro."
- &#x20;O segredo do cliente nunca mais aparece; para trocá-lo, rode **Configurar** de novo.
- &#x20;O provedor de serviços pode restringir de quais redes as pessoas e integrações entram (os agentes não são afetados); fora delas o acesso é recusado antes de conferir a senha.
- &#x20;O plano pode limitar agentes e pessoas; um agente ou convite além do limite é recusado com uma mensagem clara.
- &#x20;Cada mudança de método vai para a Trilha de auditoria e para o Histórico de configuração como versão de "Método de login".

***

### Relacionados

- &#x20;Como entrar
- &#x20;Pessoas e convites
- &#x20;Perfis e permissões
- &#x20;Central de integrações

***

## <font color="#22C55E">Acesso de suporte do provedor de serviços</font>

A equipe do provedor de serviços nunca vê os dados da sua empresa por conta própria. Quando precisa ajudar, ela envia um pedido e **o seu administrador decide**. Os pedidos aparecem em **Admin ›Usuários e perfis › Autenticação**, na seção **Pedidos de acesso de suporte do provedor de serviços**, e os pendentes são contados no Início em **Pedidos de acesso de suporte**.

***

### O que você pode fazer aqui

- &#x20;Ver cada pedido com quem pede, o motivo, quando foi pedido e a situação (**Aguardando aprovação**, **Aprovado**, **Recusado**, **Revogado**, **Vencido**).
- &#x20;**Aprovar por  min** um pedido pendente, ou **Recusar**.
- &#x20;**Revogar agora** um acesso aprovado antes do fim do prazo.
- &#x20;Acompanhar tudo o que o provedor fez na trilha de auditoria.

***

### Aprovar ou recusar

1. Abra o Início e clique em **Pedidos de acesso de suporte** em **O que precisa de atenção**, ou vá direto para **Admin › Usuários e perfis › Autenticação**.
2. Leia a linha: quem pede, motivo, "pedido ".
3. Clique em **Aprovar por  min**. A confirmação diz "Acesso só de leitura por  minutos. Cada ação fica na sua trilha de auditoria; dá para revogar a qualquer momento." Clique em **Aprovar**.
4. Ou clique em **Recusar** e confirme: "A equipe do provedor não verá os seus dados."

Depois da aprovação a linha mostra **Aprovado**, "até " e "decidido por ".

***

### Durante o acesso

O acesso de suporte é só de leitura: qualquer tentativa de mudar algo é recusada ("Support access is read-only."). Cada chamada feita pela equipe do provedor fica na sua trilha de auditoria como "Chamada feita em modo suporte".

***

### Revogar

Clique em **Revogar agora** numa linha aprovada e confirme: o acesso termina na hora, mesmo antes do prazo pedido. Quando o prazo acaba, o acesso termina sozinho e a situação vira **Vencido**.

***

### Exemplo prático: uma sessão de suporte de 60 minutos

A Aurora abriu um chamado com o provedor porque um painel não mostra dados.

1. Às 14:00 o analista do provedor pede acesso: motivo "Verificar painel NOC TV sem dados", 60 minutos.
2. O administrador da Aurora vê **Pedidos de acesso de suporte 1** no Início, abre o pedido e clica em **Aprovar por 60 min** e depois em **Aprovar**. A linha diz **Aprovado** · até 15:00 · decidido por marina.castro\@aurora.example.
3. O analista lê as configurações do painel e encontra a causa. A trilha de auditoria mostra cada chamada com a ação "Chamada feita em modo suporte".
4. Às 14:25 o problema está entendido; o administrador clica em **Revogar agora**. A situação muda para **Revogado** e a próxima chamada do analista é recusada.

***

### Cuidados e limites

- &#x20;O provedor pede entre 15 e 480 minutos; você não muda a duração, só aprova, recusa ou revoga.
- &#x20;Só perfis com a permissão de aprovar o suporte do provedor (a ação sensível **Aprovar suporte do fornecedor**) veem os botões; os outros veem a lista só para leitura.
- &#x20;O acesso de suporte nunca permite mudanças, mesmo aprovado.
- &#x20;Pedidos, aprovações, recusas e revogações ficam todos na Trilha de auditoria (grupo **Acesso de suporte**).

***

### Relacionados

&#x20;Trilha de auditoria

&#x20;Métodos de login

&#x20;Perfis e permissões

***

## <font color="#22C55E">Conformidade e hardening</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/HPka6Y73CZ_IY9EHVyXI9_image.png" size="137" caption="Tela: Conformidade e hardening" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

**Governança › Conformidade** mede normas com o que o Hive sabe do seu parque e transforma benchmarks CIS em perfis de configuração. A aba **Normas** pontua ISO/IEC 27001:2022 (Annex A), PCI DSS v4.0, LGPD / GDPR, HIPAA Security Rule e CIS Controls v8; a aba **Benchmarks CIS** cria perfis de hardening para Windows, Linux, macOS, nginx e Apache. É evidência técnica para a auditoria, não uma certificação.

***

### O que você pode fazer aqui

- &#x20;Ver a pontuação de cada norma e quantos controles estão **Atendido**, **Parcial** ou **Não atendido**.
- &#x20;Ler a evidência de cada controle, medição por medição.
- &#x20;**Exportar CSV** de uma norma para o auditor.
- &#x20;Transformar um benchmark CIS em perfil de configuração com **Criar perfil**, no modo "só avisar" ou "corrigir", para alguns locais e tags ou para todas as máquinas.
- &#x20;Guardar as chaves de recuperação do BitLocker no cofre e mostrar uma com motivo.

***

### Normas

1. Abra **Governança › Conformidade**. A aba **Normas** mostra um chip por norma com a pontuação, por exemplo "ISO/IEC 27001:2022 (Annex A) · 72%".
2. Clique num chip. Os cartões mostram **Pontuação**, **Atendido**, **Parcial** e **Não atendido**.&#x20;
3. A tabela lista cada **Controle**, a **Situação** e a **Evidência**: uma etiqueta por medição (Inventário, Inventário de software, Antivírus, Firewall, Criptografia de disco, Atualizações do sistema, Patches de segurança, Vulnerabilidades exploradas, Perfis de configuração, Administradores locais, Controle de USB, Controle de aplicativos, Chaves de recuperação no cofre, Dados sensíveis, Certificados, MFA, Trilha de auditoria, EDR) com o detalhe.
4. Clique em **Exportar CSV** para baixar controle, descrição, situação, medição, situação da medição e evidência.

Como é calculado:

- &#x20;Uma medição de cobertura fica **Atendido** com 95% ou mais das máquinas, **Parcial** a partir de 70%, **Não atendido** abaixo de 70%.
- &#x20;Um controle fica **Atendido** quando todas as medições dele estão atendidas, **Não atendido&#x20;**&#x71;uando todas estão não atendidas, e **Parcial** nos outros casos.
- &#x20;Pontuação = (atendidos + metade dos parciais) ÷ controles medidos.

### Benchmarks CIS

1. Abra a aba **Benchmarks CIS**. Cada benchmark mostra o sistema, " controles", a lista de controles e quantos perfis já foram criados a partir dele.
2. Clique em **Criar perfil**. Defina o **Nome do perfil**, o **Modo** — **Só avisar (recomendado para começar)** ou **Corrigir** — e, se quiser, **Locais (vazio: todos)** e **Tags (vazio: todas)**.
3. Clique em **Criar**. O Hive abre o novo perfil de configuração, onde você pode ajustá-lo.

Benchmarks disponíveis: CIS Windows 10/11 Nível 1 (essencial), CIS Ubuntu/Debian/RHEL Nível 1 (essencial), CIS macOS Nível 1 (essencial), Endurecimento de servidor web: nginx, e Endurecimento de servidor web: Apache.

***

### Criptografia de disco e chaves de recuperação

O item de configuração "Criptografia de disco obrigatória" confere BitLocker, FileVault ou LUKS; no Windows, no modo corrigir, ele liga o BitLocker. Todo dia o Hive lê a chave de recuperação do BitLocker das máquinas Windows criptografadas e guarda no cofre. Na máquina, o painel **Chave de**
**recuperação do BitLocker** mostra "Guardada no cofre " e oferece **Ler a chave agora**, **Trocar chave** e **Mostrar a chave** (que pede um **Motivo** e vai para a trilha de auditoria; a chave é trocada assim que a máquina voltar a ficar online). Veja Criptografia de disco.

***

### Exemplo prático: ISO 27001 antes da auditoria

1. Abra **Governança › Conformidade › Normas** e clique em "ISO/IEC 27001:2022 (Annex A)". Ela mostra 11 controles: 6 **Atendido**, 4 **Parcial**, 1 **Não atendido** — pontuação (6 + 2) ÷ 11 = 72,7%.
2. O controle A.8.1 está **Parcial**: a medição **Criptografia de disco** diz "82/100 computers ok" (82%: Parcial, entre 70% e 95%).
3. Crie um perfil de configuração com "Criptografia de disco obrigatória" no modo corrigir para a tag notebooks (veja Perfis de configuração).
4. Uma semana depois a criptografia chega a "97/100 computers ok": **Criptografia de disco** vira **Atendido**; A.8.1 vira **Atendido** se as outras medições dele estiverem atendidas, e a pontuação sobe.
5. Clique em **Exportar CSV** e envie iso27001.csv ao auditor junto com o pacote de evidências da Trilha de auditoria.

***

### Exemplo prático: CIS Windows em duas fases

1. Em **Benchmarks CIS**, clique em **Criar perfil** em "CIS Windows 10/11 Nível 1 (essencial)".&#x20;
2. **Nome do perfil**CIS Windows N1 — piloto , **ModoSó avisar (recomendado para começar)**, **Tags&#x20;**&#x70;iloto-cis . Clique em **Criar** ("Perfil criado.").
3. Depois de alguns dias, o perfil mostra quais máquinas do piloto diferem de cada um dos 12 controles, sem mudar nada.
4. Quando as diferenças estiverem entendidas, edite o perfil e passe para o modo corrigir; depois amplie as tags para todas as estações.

***

### Cuidados e limites

- &#x20;As medições usam só dados que o Hive já coleta. Antivírus, firewall, criptografia de disco e atualizações do sistema contam só os computadores que informam proteção; sem nenhum, a medição fica "Não se aplica". O inventário conta os computadores vistos nos últimos 7 dias.
- &#x20;Controles sem nenhuma medição aplicável ficam "Não se aplica" e não entram na pontuação.
- &#x20;Os resultados seguem o escopo de dados do seu perfil ativo.
- &#x20;**Criar perfil** exige permissão para mudar configuração; ler as abas exige permissão de leitura de relatórios ou de configuração.
- &#x20;Locais e tags vazios aplicam o perfil a todas as máquinas; dá para mudar o escopo no perfil depois.
- &#x20;Mostrar uma chave de recuperação sempre exige um motivo e fica registrado na trilha de auditoria.

***

### Relacionados

- &#x20;Perfis de configuração
- &#x20;Criptografia de disco
- &#x20;Trilha de auditoria
- &#x20;Vulnerabilidades

***

## <font color="#22C55E">Perfis DISA STIG e checklists</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/1Nq4l36XfW4Q2gvO7PX8A_image.png" size="137" caption="Tela: Perfis DISA STIG e checklists" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

A aba **DISA STIG** de **Governança › Conformidade** fica ao lado da aba **Benchmarks CIS** e transforma os Security Technical Implementation Guides da DISA em perfis de configuração. O Hive então mostra, por dispositivo, quais regras do STIG passam e quais estão abertas, e exporta a evidência no formato que os auditores esperam, incluindo o checklist do STIG Viewer ( .ckl ).

***

### O que você pode fazer aqui

- &#x20;Navegar pelos STIGs: **Microsoft Windows 11 STIG**, **Microsoft Windows Server 2022 STIG**, **Red Hat Enterprise Linux 9 STIG** e **Canonical Ubuntu 22.04 LTS STIG**. Abaixo de cada nome aparecem o sistema operacional, a versão (por exemplo "Versão V1R2"), o número de regras e quantos perfis já o usam.
- &#x20;Clicar em **Regras (n)** para listar as regras: categoria (**CAT I**, **CAT II** ou **CAT III**), Vul ID (V-xxxxx) e título. O Rule ID, o SRG ID, o texto de verificação e o texto de correção vão na API e no arquivo .ckl .
- &#x20;**Aplicar** um STIG: o Hive cria um perfil de configuração a partir dele.
- &#x20;Clicar em **Evidência** para ver o resultado por dispositivo e regra, e exportar **CSV**, **Imprimir / PDF&#x20;**&#x6F;u **Checklist (.ckl)** por dispositivo.

***

### Como funciona

Cada STIG traz um pequeno subconjunto representativo das regras do STIG (cinco ou seis por STIG): as que o Hive consegue verificar com as verificações dos perfis de configuração — valores de registro, parâmetros sysctl, linhas em arquivos de configuração e serviços.

1. **Aplicar** abre uma janela com **Nome do perfil** e **Modo**: **Só auditar** (apenas relata) ou **Aplicar a configuração** (o agente também corrige o que estiver diferente). **Criar perfil** cria o perfil, ativo, com escopo vazio — ou seja, todos os dispositivos daquele sistema operacional — e intervalo de verificação de 1440 minutos (uma vez por dia). Em seguida o Hive abre o perfil novo, onde vocêrestringe o escopo (localidades, tags, grupos) e muda o intervalo.
2. O agente confere o perfil no intervalo do perfil e relata cada item.
3. O Hive converte o resultado de cada item na situação do STIG:

| **Resultado do item**               | **Situação no STIG**                  |
| ----------------------------------- | ------------------------------------- |
| ok, corrigido                       | **Conforme** ( NotAFinding )          |
| divergência                         | **Aberto** ( Open )                   |
| não se aplica                       | **Não se aplica** ( Not\_Applicable ) |
| erro, ou sem resultado para a regra | **Não revisado** ( Not\_Reviewed )    |

A tabela de **Evidência** tem as colunas **Dispositivo**, **Regra**, **Situação**, **Esperado**, **Encontrado** e **Verificado**. Só aparecem os dispositivos que já relataram o perfil.

***

### Exemplo prático: STIG do RHEL 9 para uma auditoria

1. Abra **Governança › Conformidade** e a aba **DISA STIG**. Em "Red Hat Enterprise Linux 9 STIG" clique em **Regras (6)** e encontre a regra **CAT II** que exige net.ipv4.conf.all.accept\_redirects = 0 .
2. Clique em **Aplicar**. Mantenha o nome, deixe o **Modo** em **Só auditar** e clique em **Criar perfil**. O Hive abre o novo perfil de configuração.
3. No perfil, defina o escopo na tag linux-prod e salve, para que só esses servidores sejam verificados.
4. Depois da próxima verificação do agente, volte à aba **DISA STIG** e clique em **Evidência**: para SRV-DB-02 a maioria das regras está **Conforme**; a regra de redirecionamento está **Aberto** com **Esperado**0 e **Encontrado**1 .
5. Converse com os responsáveis pelos servidores, mude o perfil para o modo que aplica a configuração e salve. Na próxima verificação a regra passa a **Conforme** e a mudança vai para a trilha de auditoria.
6. Clique em **Checklist (.ckl) · SRV-DB-02** e abra o arquivo no DISA STIG Viewer, ou entregue-o ao auditor junto com o **CSV** de todos os dispositivos.

***

### Cuidados e limites

- &#x20;Cada STIG é um pequeno subconjunto do guia, não o guia completo; todas as outras regras precisam ser avaliadas à mão no STIG Viewer.
- &#x20;A janela de **Aplicar** não tem campo de escopo: o perfil nasce ativo para todos os dispositivos daquele sistema operacional. Restrinja o escopo no perfil logo em seguida — sobretudo antes de escolher **Aplicar a configuração**.
- &#x20;O checklist é um arquivo por dispositivo.
- &#x20;Compare a versão mostrada abaixo do nome do STIG com a que o seu auditor exige.
- &#x20;Um dispositivo que ainda não relatou o perfil não aparece na evidência (e não tem .ckl ); uma regra com erro ou sem resultado mostra **Não revisado**.
- &#x20;**Aplicar** exige a permissão de alterar configuração ( config\:write ); ver os STIGs e exportar a evidência exige a permissão de leitura de configuração ( config\:read ).

***

### Relacionados

- &#x20;Conformidade e hardening
- &#x20;Perfis de configuração
- &#x20;Criptografia de disco
- &#x20;Trilha de auditoria

***

## <font color="#22C55E">Trilha de auditoria</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/6B0j-IOTF1U7uiFX8dfPp_image.png" size="137" caption="Tela: Trilha de auditoria (1/2)                  " isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/OjinFQJoM6VC0JOVIo5DQ_image.png" size="137" caption="Tela: Trilha de auditoria (2/2)" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

**Admin › Trilha de auditoria** registra tudo o que é feito no Hive — por pessoas, contas de integração, o sistema ou a equipe de suporte do provedor de serviços — com quem, quando, de onde (IP) e em qual objeto. Cada registro é encadeado ao anterior por um hash, então uma mudança feita fora do Hive aparece. **Admin › Histórico de configuração** reúne toda mudança de configuração numa só linha do tempo, com o que mudou campo a campo e o caminho de volta.

***

### O que você pode fazer aqui

- &#x20;Filtrar a trilha por **Pessoa ou conta**, **Ação** e **Objeto**, e carregar registros mais antigos.
- &#x20;**Verificar o encadeamento** de todos os registros.
- &#x20;Baixar um **Pacote de evidências** (ZIP assinado) de um período, para auditores de SOC 2 / ISO 27001.
- &#x20;**Enviar para o SIEM** (abre a integração Syslog na Central de integrações).
- &#x20;No **Histórico de configuração**: filtrar por **Tipo**, buscar, escolher o **Período**, abrir **O que mudou&#x20;**&#x65; **Restaurar** uma versão.

***

### Ler e filtrar a trilha

1. Abra **Admin › Trilha de auditoria**. A tabela mostra **Data e hora**, **Quem**, **Ação**, **O quê**, **Origem (IP)** e **Encadeamento**.
2. Digite um e-mail ou nome de conta em **Pessoa ou conta** (por exemplo marina.castro\@aurora.example ).
3. Escolha um grupo de **Ação** (Pessoas, Perfis, Métodos de entrada, Integrações, Contas de integração (API), Configurações da empresa, Acesso de suporte, Versões de configuração, Grupos do diretório, Modelos) e um **Objeto** (Pessoa, Perfil, Método de entrada…).&#x20;
4. No fim da lista, carregue registros mais antigos até aparecer "Fim da lista".

***

### Verificar o encadeamento

Clique em **Verificar o encadeamento**. O Hive lê todos os registros, recalcula a cadeia de hashes e responde "Trilha íntegra: nenhum dos  registros foi alterado." ou "O encadeamento estáquebrado no registro : um registro foi alterado fora do Hive. Guarde a evidência e fale com o provedor de serviços."

***

### Pacote de evidências

1. Clique em **Pacote de evidências**.
2. Preencha **De** e **Até** como AAAA-MM-DD .
3. Clique em **Gerar pacote assinado**. Um ZIP é baixado com a trilha encadeada do período e a verificação, as mudanças de configuração, os acessos privilegiados (suporte do provedor, dupla aprovação, segredos revelados, MFA), a revisão de acessos atual e cada backup com o sha256. O manifesto é assinado com Ed25519. A própria exportação vai para a trilha.

***

### Histórico de configuração

**Admin › Histórico de configuração** mostra uma versão a cada mudança de: regras de alerta, perfis de acesso, templates de monitoração, políticas de mudanças e de integridade, grupos, sub-redes, painéis, relatórios, métodos de login, perfis de ITSM, configuração da IA, configuração de
vulnerabilidades e escalas de plantão.

1. Escolha um **Tipo** (ou **Todos os tipos**), digite em **Buscar (nome, autor, observação)** e escolha o **Período**: últimos 7, 30, 90 ou 365 dias.
2. Cada linha mostra o nome, a versão, o autor, **Criada** ou **Alterada**, e **atual** ou **apagada**.&#x20;
3. Clique em **O que mudou** para ver **Campo**, **Antes** e **Depois**; **Esconder** fecha.
4. Nos tipos que permitem, clique em **Restaurar** numa versão anterior e confirme: "A configuração volta para aquela versão agora; fica registrada como versão nova e na auditoria."

***

### Exemplo prático: quem desligou o SAML?

Na segunda-feira as pessoas reclamam que o botão "Entrar com a conta da empresa (SAML)" sumiu.

1. Abra **Admin › Trilha de auditoria** e escolha a **Ação** "Métodos de entrada".
2. A primeira linha: domingo 22:14, rafael.lima\@aurora.example , "Método de entrada desligado", objeto saml , origem 203.0.113.40 .
3. Abra **Admin › Histórico de configuração**, **Tipo** "Método de login", **Período** "últimos 7 dias". A linha "Sign-in: saml" mostra a versão nova como **atual**; **O que mudou** mostra o campo enabled passando de true para false .
4. Métodos de login não têm o botão **Restaurar**; então ligue o SAML de novo em **Admin › Usuários e perfis › Autenticação**. Isso cria outra versão no histórico e uma linha "Método de entrada ligado" na trilha.

***

### Exemplo prático: restaurar um perfil pelo histórico

1. No **Histórico de configuração**, escolha o **Tipo** "Perfil de acesso" e busque Service desk .&#x20;
2. **Service desk N1** mostra as versões 3 (atual), 2 e 1. **O que mudou** na versão 3 mostra o campo permissions com screen\:assets.inventory\:edit a mais (Editar em Todos os ativos).
3. Clique em **Restaurar** na versão 2 e confirme. O Hive responde "Service desk N1 restaurada para a versão 2."; a restauração vira a versão 4 e uma linha "Versão restaurada" na trilha.

***

### Exemplo prático: evidências para o auditor da ISO 27001

1. O auditor pede as evidências do terceiro trimestre.
2. Clique em **Pacote de evidências**, **De**2026-07-01 , **Até**2026-09-30 , **Gerar pacote assinado**.&#x20;
3. O arquivo hive-evidence-instance-2026-07-01\_2026-09-30.zip é baixado ("Pacote de evidências baixado. A exportação foi para a trilha."). Envie ao auditor; o manifesto assinado prova que nada foi mudado depois.
4. Clique em **Verificar o encadeamento** e anexe o resultado "Trilha íntegra" ao relatório da auditoria.

***

### Cuidados e limites

- &#x20;A trilha não pode ser editada nem apagada pelo Hive; qualquer mudança direta no banco quebra o encadeamento e aparece na verificação.
- &#x20;Abrir a trilha exige permissão de leitura da auditoria; **Exportar auditoria** é uma ação à parte do perfil.
- &#x20;**Restaurar** no histórico de configuração só aparece nos tipos que permitem e só em versões que não são a atual, e exige permissão para mudar configuração.
- &#x20;As datas do pacote de evidências precisam usar AAAA-MM-DD .

***

### Relacionados

- &#x20;Perfis e permissões
- &#x20;Conformidade e hardening
- &#x20;Acesso de suporte do provedor de serviços
- &#x20;Enviar eventos ao SIEM

***

## <font color="#22C55E">Configurações da empresa e identidade visual</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/IBXJYpEhbhjFdqU5RyiQh_image.png" size="137" caption="Tela: Configurações da empresa e identidade visual" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

**Admin › Configurações da empresa** define como o Hive aparece para todos da sua empresa (marca própria) e o idioma padrão: nome da empresa, nome do produto exibido, logotipo e cor principal, com prévia ao vivo nos modos claro e escuro. A região dos dados e o plano são definidos pelo provedor de serviços. A licença do próprio Hive está em Licença do produto e modo de implantação.

***

### O que você pode fazer aqui

- &#x20;Mudar o **Nome da empresa** e o **Nome do produto exibido**.
- &#x20;Enviar um logotipo (**Enviar imagem**) ou apontar para um com **Ou endereço do logotipo (https)**; trocar ou remover.
- &#x20;Escolher a **Cor principal** nas amostras ou em **Outra:**, com verificação de contraste AA.
- &#x20;Definir o **Idioma padrão da empresa**.
- &#x20;Ver o resultado na **Prévia ao vivo** antes de salvar, e desfazer logo depois de salvar.

***

### Mudar a marca

1. Abra **Admin › Configurações da empresa**.
2. Em **Marca**, digite o **Nome da empresa** (aparece na barra superior, no início e na página de entrada) e o **Nome do produto exibido** (barra superior, tela de entrada e aba do navegador; até40 caracteres).
3. Logotipo: clique em **Enviar imagem** e escolha um PNG, JPEG, WebP ou SVG de até 512 KB. Vale na hora, também na tela de entrada ("Logotipo enviado"). **Trocar imagem** e **Remover&#x20;**&#x61;parecem depois de um envio. Sem imagem enviada, você pode digitar um endereço https em **Ou endereço do logotipo (https)**; o logotipo novo aparece depois de salvar.
4. **Cor principal**: clique numa amostra ou em **Outra:** para escolher qualquer cor. Se o contraste com texto branco for menor que 4,5:1, o Hive avisa "Contraste insuficiente com texto branco" e oferece **Usar a variação sugerida**; senão mostra "Contraste AA ok".
5. Confira a **Prévia ao vivo** (clara e escura). No modo escuro o Hive usa uma versão mais clara da cor para manter o contraste.
6. Clique em **Salvar configurações**. A mudança vale na hora e vai para a trilha de auditoria; a mensagem "Configurações salvas." tem **Desfazer**.

***

### Idiomas

O Hive está disponível em English (padrão), Português e Español. O **Idioma padrão da empresa** é o idioma em que as pessoas novas começam; cada pessoa pode escolher outro idioma e o tema (claro, escuro ou do sistema) no menu do usuário.

***

### Exemplo prático: a marca da Aurora

1. **Nome da empresa**: Aurora Logística ; **Nome do produto exibido**: Aurora TI .
2. **Enviar imagem**: aurora-logo.svg (38 KB) — a barra superior já mostra o logotipo.
3. **Cor principal**: **Outra:**#F2C14E (amarelo). O Hive avisa "Contraste insuficiente com texto branco (1.7:1)" e sugere uma variação mais escura; clique em **Usar a variação sugerida** e a verificação vira "Contraste AA ok".
4. **Idioma padrão da empresa**: Português.
5. **Salvar configurações**. Todos passam a ver "Aurora TI" na barra superior e na página de entrada; pessoas novas começam em português. Uma colega em Madri muda para Español no menu do usuário, só para ela.
6. A cor ficou ruim na tela da sala de reunião: clique em **Desfazer** na mensagem para voltar às configurações anteriores ("Configurações anteriores restauradas.").

***

### Cuidados e limites

- &#x20;Só perfis com permissão para administrar as configurações da empresa abrem esta tela.
- &#x20;O endereço do logotipo precisa começar com https\:// ; imagens de até 512 KB.
- &#x20;Se o nome do produto ficar vazio, volta a ser "Hive".
- &#x20;A equipe de suporte do provedor de serviços pede acesso à parte; veja Acesso de suporte do provedor de serviços.
- &#x20;Cada mudança vai para a Trilha de auditoria como "Configurações da empresa alteradas".

***

### Relacionados

- &#x20;Licença do produto e modo de implantação
- &#x20;Trilha de auditoria
- &#x20;Como entrar

***

## <font color="#22C55E">Licença do produto e modo de implantação</font>

::Image[]{src="https://api.archbee.com/api/optimize/pu5VMc-2TW3GQX4ly5Xp7/IBXJYpEhbhjFdqU5RyiQh_image.png" size="137" caption="Tela: Licença do produto e modo de implantação" isUploading="false" width="1366" height="860" darkWidth="1366" darkHeight="860" showCaption="true"}

Cada instalação do Hive roda num de três modos — **demo**, **trial** ou **produção** — escolhido na instalação. No trial e na produção o número de agentes é limitado: pelo trial ou pelas chaves de licença instaladas em **Admin › Licença**. Este artigo é sobre a licença do próprio Hive; para gerenciar as licenças de software da empresa, veja Licenças.

***

### O que você pode fazer aqui

- &#x20;Ver o modo, o ID da instalação, quantos agentes estão em uso e o limite.
- &#x20;Acompanhar a contagem do trial (15 dias + 15 de carência).
- &#x20;Instalar uma chave de licença (colar o serial) e ver todas as chaves: agentes, tipo, validade e situação (ativa, pendente, vencida, substituída).

***

### Modos de implantação

| **Modo** | **Para**                                   | **Agentes**                                 | **Quando termina**                                                     |
| -------- | ------------------------------------------ | ------------------------------------------- | ---------------------------------------------------------------------- |
| Demo     | Laboratório e demonstração                 | Sem limite                                  | — (mostra a faixa "Demo")                                              |
| Trial    | Avaliar o Hive no seu ambiente, base vazia | 20 dispositivos (ajustável pelo fabricante) | 15 dias desde a primeira subida, depois 15 de carência com aviso forte |
| Produção | Uso real                                   | A soma das chaves ativas                    | Chave vencida deixa de contar                                          |

O modo é gravado na primeira subida ( HIVE\_DEPLOYMENT\_MODE da instalação) e não muda ao editar a variável depois. O trial vira produção ao instalar uma chave.

**Quando o trial e a carência acabam (ou a produção não tem chave válida)**, o Hive fica **somente leitura**: tudo continua visível e exportável, os agentes instalados seguem funcionando e enviando dados, mas alterações e novas inscrições de agentes são recusadas até instalar uma chave. **Admin ›Licença** continua aberta para isso.

***

### Chaves de licença

- &#x20;A chave é um serial assinado ( HIVE1.… ) emitido pelo gerador de licenças do fabricante e conferido sem internet pelo Hive. Traz o licenciado, o número de agentes e, opcionalmente, vencimento, início e a instalação a que está presa.
- &#x20;**Somar**: chaves válidas se somam — 500 agentes mais uma chave adicional de 200 dão **700**.
- &#x20;**Substituir**: o fabricante pode emitir uma chave que *substitui* licenças anteriores (por exemplo na renovação). As substituídas deixam de contar, mesmo se instaladas depois.
- &#x20;Chave com início futuro fica **pendente**; chave vencida deixa de contar.
- &#x20;O **coletor** não ocupa licença; agente revogado libera a dele.
- &#x20;Aos **90%** do limite aparece um aviso; **no limite** a inscrição de um novo agente é recusada com "a licença permite N agentes e M estão instalados". Agentes já instalados nunca são cortados.

***

### Passo a passo: instalar uma chave

1. Abra **Admin › Licença** (exige settings\:admin ).
2. Cole o serial recebido do fabricante em **Chave de licença** e clique em **Instalar**.
3. Confira a lista: a chave nova aparece **ativa** (ou **pendente**, se o início for futuro) e o total de agentes é atualizado.

***

### Exemplo prático: trial, depois 500 + 200 agentes, depois renovação

1. Dia 1: a instalação da Aurora é criada em **trial** com scripts/new\_installation.sh --mode trial (base vazia, só com os perfis padrão). Dá para inscrever até 20 dispositivos (agentes).
2. Dia 16: o trial acaba e começam os 15 dias de carência — uma faixa vermelha mostra os dias restantes.
3. Dia 20: a Aurora compra 500 agentes. O fabricante emite license-issuer issue -licensee "Aurora"-agents 500 -expires 2027-10-31 ; o administrador cola o serial em **Admin › Licença**. O modo vira **produção**, limite 500.
4. Seis meses depois, uma filial nova precisa de mais 200: o fabricante emite uma chave **adicional&#x20;**&#x64;e 200; instalada, o total vai a **700**.
5. Na renovação, o fabricante emite uma chave de 800 agentes que **substitui** as duas anteriores. Depois de instalada, o total é **800** (e não 700 + 800).

***

### Cuidados e limites

- &#x20;Não espere o fim da carência: depois dela o Hive fica somente leitura até instalar a chave.
- &#x20;Chave presa a outra instalação (ID da instalação ou empresa) é recusada — informe ao fabricante o **ID da instalação** mostrado na tela.
- &#x20;A instalação só aceita chaves assinadas pela chave do fabricante configurada em HIVE\_LICENSE\_PUBLIC\_KEY .
- &#x20;Limites de plano definidos por um provedor de serviço são separados da licença do produto e têm mensagem própria.

***

### Relacionados

- &#x20;Configurações da empresa e marca
- &#x20;Agentes e coletores

