Criar uma arquitetura do workspace do Log Analytics

Artigo
11/28/2023

Um único workspace do Log Analytics pode ser suficiente para muitos ambientes que usam o Azure Monitor e o Microsoft Sentinel. Mas muitas organizações criarão vários espaços de trabalho para otimizar os custos e atender melhor aos diferentes requisitos de negócios. Este artigo aborda um conjunto de critérios para determinar se deve usar um único espaço de trabalho ou vários espaços de trabalho. Ele também discute a configuração e o posicionamento desses espaços de trabalho para atender aos seus requisitos, otimizando seus custos.

Observação

Este artigo discute o Azure Monitor e o Microsoft Sentinel porque muitos clientes precisam considerar ambos em seu design. A maioria dos critérios de decisão se aplica a ambos os serviços. Se você usar apenas um desses serviços, poderá ignorar o outro em sua avaliação.

Este vídeo aborda os conceitos básicos dos logs do Azure Monitor, as práticas recomendadas e as considerações de design para criar uma implantação de logs do Azure Monitor:

Estratégia de design

Seu design deve começar sempre com um único espaço de trabalho para reduzir a complexidade do gerenciamento de vários espaços de trabalho e da consulta de dados. Não há limitações de desempenho da quantidade de dados no espaço de trabalho. Vários serviços e fontes de dados podem enviar dados para o mesmo espaço de trabalho. À medida que você identifica critérios para criar mais espaços de trabalho, seu design deve usar o menor número que corresponderá aos seus requisitos.

A criação de uma configuração de espaço de trabalho inclui a avaliação de vários critérios. Mas alguns dos critérios podem estar em conflito. Por exemplo, você pode reduzir os encargos de saída criando um espaço de trabalho separado em cada região do Azure. A consolidação em um único espaço de trabalho pode permitir que você reduza ainda mais os encargos com um nível de compromisso. Avalie cada um dos critérios de forma independente. Considere seus requisitos e prioridades para determinar qual design será mais eficaz para seu ambiente.

Critérios de design

A tabela a seguir apresenta critérios a serem considerados ao projetar sua arquitetura de espaço de trabalho. As seções a seguir descrevem os critérios.

Critérios	Descrição
Dados operacionais e de segurança	Você pode optar por combinar dados operacionais do Azure Monitor no mesmo workspace que os dados de segurança do Microsoft Sentinel ou separar cada um em seu próprio workspace. Combiná-los oferece uma melhor visibilidade em todos os seus dados, enquanto seus padrões de segurança podem exigir a separação deles para que sua equipe de segurança tenha um workspace dedicado. Você também pode ter implicações de custo para cada estratégia.
Locatários do Azure	Se você tiver vários locatários do Azure, geralmente criará um espaço de trabalho em cada um deles. Várias fontes de dados só podem enviar dados de monitoramento para um espaço de trabalho no mesmo locatário do Azure.
Regiões do Azure	Cada espaço de trabalho reside em uma região específica do Azure. Você pode ter requisitos regulatórios ou de conformidade para armazenar dados em locais específicos.
Propriedade de dados	É possível optar por criar espaços de trabalho separados para definir a propriedade dos dados. Por exemplo, você pode criar espaços de trabalho por subsidiárias ou empresas afiliadas.
Cobrança dividida	Ao colocar workspaces em assinaturas separadas, eles podem ser faturados para diferentes partes.
Arquivamento e retenção de dados	Você pode definir configurações de retenção diferentes para cada workspace e cada tabela em um workspace. É necessário um espaço de trabalho separado se precisar de configurações de retenção diferentes para recursos diferentes que enviam dados para as mesmas tabelas.
Níveis de compromisso	Os níveis de compromisso permitem reduzir o custo de ingestão comprometendo-se com uma quantidade mínima de dados diários em um único workspace.
Limitações do agente herdado	Os agentes herdados de máquinas virtuais têm limitações no número de workspaces aos quais podem se conectar.
Controle de acesso a dados	Configure o acesso ao workspace e a tabelas e dados diferentes de recursos diferentes.
Resiliência	Para garantir que os dados em seu workspace estejam disponíveis em caso de falha na região, você pode ingerir dados em vários workspaces em regiões diferentes.

Dados operacionais e de segurança

A decisão de combinar seus dados operacionais do Azure Monitor no mesmo workspace que os dados de segurança do Microsoft Sentinel ou separar cada um em seu próprio workspace depende de seus requisitos de segurança e das possíveis implicações de custo para seu ambiente.

Workspaces dedicados A criação de workspaces dedicados para o Azure Monitor e o Microsoft Sentinel permitirá separar a propriedade dos dados entre as equipes operacionais e de segurança. Essa abordagem também pode ajudar a otimizar custos pois quando o Microsoft Sentinel estiver habilitado em um espaço de trabalho, todos os dados nele estarão sujeitos aos preços do Microsoft Sentinel mesmo que sejam dados operacionais coletados pelo Azure Monitor.

Um espaço de trabalho com o Microsoft Sentinel obtém três meses de retenção de dados gratuita em vez de 31 dias. Esse cenário normalmente resulta em custos mais altos para dados operacionais em um espaço de trabalho sem o Microsoft Sentinel. Confira Detalhes de preço dos Logs do Azure Monitor.

Workspace combinado Combinar seus dados do Azure Monitor e do Microsoft Sentinel no mesmo workspace oferece uma melhor visibilidade em todos os seus dados, permitindo que você combine facilmente consultas e pastas de trabalho. Se o acesso aos dados de segurança deve ser limitado a uma equipe específica, você pode usar o RBAC no nível da tabela para bloquear usuários específicos de tabelas com dados de segurança ou limitar os usuários a acessar o workspace usando o contexto de recurso.

Essa configuração poderá resultar em economia de custos se ajudar você a alcançar uma camada de compromisso, que fornece um desconto para seus encargos de ingestão. Por exemplo, considere uma organização que tem dados operacionais e de segurança, cada um ingerindo cerca de 50 GB por dia. A combinação dos dados no mesmo espaço de trabalho permitiria um nível de compromisso de 100 GB por dia. Esse cenário forneceria um desconto de 15% para o Azure Monitor e um desconto de 50% para o Microsoft Sentinel.

Se você criar espaços de trabalho separados para outros critérios, geralmente criará mais pares de espaços de trabalho. Por exemplo, se você tiver dois locatários do Azure, poderá criar quatro espaços de trabalho com um espaço de trabalho operacional e de segurança em cada locatário.

Se você usar o Azure Monitor e o Microsoft Sentinel: Considere separar cada um em um workspace dedicado, se exigido por sua equipe de segurança ou se isso resultar em uma economia de custos. Considere combinar os dois para obter uma melhor visibilidade dos dados de monitoramento combinados ou se eles ajudarem você a alcançar um nível de compromisso.
Se você usar o Microsoft Sentinel e o Microsoft Defender para Nuvem: considere usar o mesmo espaço de trabalho para ambas as soluções para manter os dados de segurança em um só lugar.

Locatários do Azure

A maioria dos recursos só pode enviar dados de monitoramento para um workspace no mesmo locatário do Azure. Máquinas virtuais que usam o Agente do Azure Monitor ou os agentes do Log Analytics podem enviar dados para os espaços de trabalho em locatários separados do Azure. Considere esse cenário como um provedor de serviços.

Se você tiver um único locatário do Azure: crie um único espaço de trabalho para esse locatário.
Se você tiver vários locatários do Azure: crie um espaço de trabalho para cada locatário. Para ver outras opções, incluindo estratégias para provedores de serviços, consulte Estratégias com múltiplos locatários.

Regiões do Azure

Cada workspace do Log Analytics reside em uma região específica do Azure. Você pode ter finalidades regulatórias ou de conformidade para manter os dados em uma região específica. Por exemplo, uma empresa internacional pode localizar um espaço de trabalho em cada região geográfica principal, como os Estados Unidos e a Europa.

Se você tiver requisitos para manter os dados em uma determinada localização geográfica: crie um espaço de trabalho separado para cada região com esses requisitos.
Se você não tiver requisitos para manter os dados em uma determinada localização geográfica: use um único espaço de trabalho para todas as regiões.

Considere também possíveis encargos de largura de banda que podem ser aplicados ao enviar dados para um espaço de trabalho de um recurso em outra região. Esses encargos geralmente são menores em relação aos custos de ingestão de dados para a maioria dos clientes. Normalmente, esses encargos resultam do envio de dados para o espaço de trabalho de uma máquina virtual. O monitoramento de dados de outros recursos do Azure usando configurações de diagnóstico não incorre em encargos de saída.

Use a calculadora de preços do Azure para estimar o custo e determinar quais regiões você precisa. Considere workspaces em várias regiões se os encargos de largura de banda forem significativos.

Se os encargos de largura de banda forem altos o suficiente para justificar a complexidade extra: crie um espaço de trabalho separado para cada região com máquinas virtuais.
Se os encargos de largura de banda não forem altos o suficiente para justificar a complexidade extra: use um único espaço de trabalho para todas as regiões.

Propriedade dos dados

Talvez seu requisito seja separar dados ou definir limites com base na propriedade. Por exemplo, você pode ter subsidiárias ou empresas afiliadas diferentes que exigem a delineação de seus dados de monitoramento.

Se você precisar de segregação de dados: use um espaço de trabalho separado para cada proprietário de dados.
Se você não precisar de segregação de dados: use um único espaço de trabalho para todos os proprietários de dados.

Cobrança dividida

Talvez seja necessário dividir a cobrança entre partes diferentes ou executar a cobrança retroativa para um cliente ou uma unidade de negócios interna. Use o Gerenciamento de Custos e Cobrança do Azure, para exibir os encargos por espaço de trabalho. Você também pode usar uma consulta de log para exibir o volume de dados faturável por recurso, grupo de recursos ou assinatura do Azure. Essa abordagem pode ser suficiente para seus requisitos de cobrança.

Se você não precisar dividir a cobrança ou executar a cobrança retroativa: use um único espaço de trabalho para todos os proprietários de custo.
Se você precisar dividir a cobrança ou executar a cobrança retroativa: considere se o Gerenciamento de Custos e Cobrança do Azure ou uma consulta de log fornece relatórios de custos granulares o suficiente para seus requisitos. Caso contrário, use um workspace separado para cada proprietário de custo.

Arquivamento e retenção de dados

Você pode definir as configurações padrão de retenção e arquivamento de dados para um workspace ou definir configurações diferentes para cada tabela. Você pode exigir configurações diferentes para diferentes conjuntos de dados em uma tabela específica. Nesse caso, você precisará separar esses dados em espaço de trabalho diferentes, cada um com configurações de retenção exclusivas.

Se você puder usar as mesmas configurações de retenção e arquivamento para todos os dados em cada tabela: use um único espaço de trabalho para todos os recursos.
Se você puder exigir diferentes configurações de retenção e arquivamento para recursos diferentes na mesma tabela: use um espaço de trabalho separado para recursos diferentes.

Níveis de compromisso

Níveis de compromisso fornecem um desconto para os custos de ingestão do espaço de trabalho quando você se compromete com uma quantidade específica de dados diários. Você pode optar por consolidar dados em um único espaço de trabalho para atingir o nível de uma camada específica. Esse mesmo volume de dados distribuídos em vários espaços de trabalho não seria qualificado para o mesmo nível, a menos que você tenha um cluster dedicado.

Se você puder confirmar a ingestão diária de pelo menos 100 GB por dia, deverá implementar um cluster dedicado que forneça funcionalidade e desempenho extras. Os clusters dedicados também permitem combinar os dados de vários workspaces no cluster para atingir o nível de um nível de compromisso.

Se você ingerir pelo menos 100 GB por dia em todos os recursos: crie um cluster dedicado e defina o nível de compromisso apropriado.
Se você ingerir pelo menos 100 GB por dia entre os recursos: considere combiná-los em um único espaço de trabalho para aproveitar um nível de compromisso.

Limitações do agente herdado

Você deva evitar o envio de dados duplicados para vários espaços de trabalho devido aos encargos extras, você mas é possível ter máquinas virtuais conectadas a vários espaços de trabalho. O cenário mais comum é um agente conectado a workspaces separados para o Azure Monitor e o Microsoft Sentinel.

O Agente do Azure Monitor e o agente do Log Analytics para Windows podem se conectar a vários espaços de trabalho. O agente do Log Analytics para Linux só pode se conectar a um único espaço de trabalho.

Se você usar o agente do Log Analytics para Linux: migre para o Agente do Azure Monitor ou verifique se seus computadores do Linux exigem apenas acesso a um único espaço de trabalho.

Controle de acesso a dados

Ao conceder a um usuário acesso a um espaço de trabalho, o usuário tem acesso a todos os dados nesse espaço de trabalho. Esse acesso é apropriado para um membro de uma equipe de segurança ou administração central que deve acessar dados para todos os recursos. O acesso ao espaço de trabalho também é determinado pelo RBAC (controle de acesso baseado em função) de contexto de recurso e pelo RBAC no nível da tabela.

RBAC de contexto de recurso: por padrão, se um usuário tiver acesso de leitura a um recurso do Azure, ele herdará permissões para qualquer um dos dados de monitoramento desse recurso enviados para o espaço de trabalho. Esse nível de acesso permite que os usuários acessem informações sobre os recursos que eles gerenciam sem ter acesso explícito ao espaço de trabalho. Se você precisar bloquear esse acesso, poderá alterar o modo de controle de acesso para exigir permissões explícitas de workspace.

Se você quiser que os usuários possam acessar dados para seus recursos: mantenha o modo de controle de acesso padrão de Usar permissões de recurso de uso ou espaço de trabalho.
Se você quiser atribuir explicitamente permissões para todos os usuários: altere o modo de controle de acesso para Exigir permissões de espaço de trabalho.

RBAC no nível da tabela: com o RBAC no nível da tabela, você pode conceder ou negar acesso a tabelas específicas no espaço de trabalho. Dessa forma, você pode implementar permissões granulares necessárias para situações específicas em seu ambiente.

Por exemplo, você pode conceder acesso apenas a tabelas específicas coletadas pelo Microsoft Sentinel a uma equipe de auditoria interna. Ou você pode negar acesso a tabelas relacionadas à segurança aos proprietários de recursos que precisam de dados operacionais relacionados aos seus recursos.

Se você não precisar de controle de acesso granular por tabela: conceda à equipe de operações e segurança acesso aos seus recursos e permita que os proprietários de recursos usem o RBAC de contexto de recurso para seus recursos.
Se você precisar de controle de acesso granular por tabela: conceda ou negue acesso a tabelas específicas usando o RBAC no nível da tabela.

Resiliência

Para garantir que dados críticos em seu workspace estejam disponíveis no caso de uma falha na região, você pode ingerir alguns ou todos os seus dados em vários workspaces em regiões diferentes.

Essa opção requer o gerenciamento da integração com outros serviços e produtos separadamente para cada workspace. Embora os dados estejam disponíveis no workspace alternativo em caso de falha, os recursos que dependem dos dados, como alertas e pastas de trabalho, não saberão alternar para o workspace alternativo. Considere armazenar modelos do ARM para recursos críticos com configuração para o workspace alternativo no Azure DevOps ou como políticas desabilitadas que podem ser habilitadas rapidamente em um cenário de failover.

Trabalhando com vários espaços de trabalho

Muitos designs incluirão vários espaços de trabalho, portanto, o Azure Monitor e o Microsoft Sentinel incluem recursos para ajudar você a analisar esses dados nos espaços de trabalho. Para obter mais informações, consulte:

Estratégias com múltiplos locatários

Ambientes com vários locatários do Azure, incluindo MSPs (provedores de serviços da Microsoft), ISVs (fornecedores de software independentes) e grandes empresas, geralmente exigem uma estratégia em que uma equipe de administração central tem acesso para administrar espaços de trabalho localizados em outros locatários. Cada um dos locatários pode representar clientes separados ou unidades de negócios diferentes.

Observação

Para parceiros e provedores de serviços que fazem parte do programa CSP (Provedor de Soluções de Nuvem), o Log Analytics no Azure Monitor é um dos serviços do Azure disponíveis em assinaturas do Azure CSP.

Duas estratégias básicas para essa funcionalidade são descritas nas seções a seguir.

Arquitetura distribuída

Em uma arquitetura distribuída, um workspace do Log Analytics é criado em cada locatário do Azure. Essa opção é a única que você pode usar se estiver monitorando serviços do Azure que não sejam máquinas virtuais.

Há duas opções para permitir que os administradores do provedor de serviços acessem os espaços de trabalho nos locatários do cliente:

Use o Azure Lighthouse para acessar o locatário de cada cliente. Os administradores do provedor de serviços são incluídos em um grupo de usuários do Microsoft Entra no locatário do provedor de serviços. Esse grupo recebe acesso durante o processo de integração para cada cliente. Os administradores podem acessar os espaços de trabalho de cada cliente de dentro de seu próprio locatário do provedor de serviços, em vez de precisar entrar no locatário de cada cliente individualmente. Para saber mais, confira Monitorar recursos do cliente em escala.
Adicione usuários individuais do provedor de serviços como usuários convidados do Microsoft Entra (B2B). Os administradores de locatários do cliente gerenciam o acesso individual para cada administrador do provedor de serviços. Os administradores do provedor de serviços devem conectar ao diretório de cada locatário no portal do Azure para acessar esses espaços de trabalho.

As vantagens dessa estratégia:

Os logs podem ser coletados de todos os tipos de recursos.
O cliente pode confirmar níveis específicos de permissões com o gerenciamento de recursos delegados do Azure. Ou o cliente pode gerenciar o acesso aos logs usando seu próprio RBAC do Azure.
Cada cliente pode ter configurações diferentes para seu espaço de trabalho, como retenção e limitação de dados.
Isolamento entre os clientes para fins de regulamentação e conformidade.
O preço de cada espaço de trabalho é incluído na fatura da assinatura do cliente.

As desvantagens dessa estratégia:

A visualização central e a análise de dados entre locatários de clientes com ferramentas como as pastas de trabalho do Azure Monitor podem resultar em experiências mais lentas. Esse é o caso especialmente ao analisar dados em mais de 50 espaços de trabalho.
Se os clientes não estiverem integrados ao gerenciamento de recursos delegados do Azure, os administradores do provedor de serviços deverão ser provisionados no diretório do cliente. Esse requisito torna mais difícil para o provedor de serviços gerenciar muitos locatários de clientes ao mesmo tempo.

Centralizado

Um único workspace é criado na assinatura do provedor de serviços. Essa opção só pode coletar dados de máquinas virtuais do cliente. Os agentes instalados nas máquinas virtuais são configurados para enviar seus logs para esse workspace central.