Projetar uma arquitetura de espaço de trabalho do Log Analytics

Artigo
11/05/2024

Um único espaço de trabalho do Log Analytics pode ser suficiente para muitos ambientes que usam o Azure Monitor e o Microsoft Sentinel. Mas muitas organizações criam vários espaços de trabalho para otimizar custos e atender melhor a diferentes requisitos de negócios. Este artigo apresenta um conjunto de critérios para determinar se deve ser usado 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 às suas necessidades e, ao mesmo tempo, otimizar seus custos.

Nota

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 aplica-se a ambos os serviços. Se utilizar apenas um destes serviços, pode ignorar o outro na sua avaliação.

Aqui está um vídeo sobre os fundamentos dos Logs do Azure Monitor e as práticas recomendadas e considerações de design para projetar sua implantação do Azure Monitor Logs:

Estratégia de design

Seu design deve sempre começar 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 deles. Não há limitações de desempenho da quantidade de dados em seu 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 de espaços de trabalho para atender às suas necessidades.

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 as cobranças 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 é mais eficaz para seu ambiente.

Critérios de conceção

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

Critérios	Description
Dados operacionais e de segurança	Você pode optar por combinar dados operacionais do Azure Monitor no mesmo espaço de trabalho que os dados de segurança do Microsoft Sentinel ou separar cada um em seu próprio espaço de trabalho. Combiná-los oferece uma melhor visibilidade de todos os seus dados, enquanto seus padrões de segurança podem exigir separá-los para que sua equipe de segurança tenha um espaço de trabalho 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. 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 dos dados	Você pode 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.
Faturação dividida	Ao colocar espaços de trabalho em assinaturas separadas, eles podem ser cobrados para partes diferentes.
Retenção de dados	Você pode definir configurações de retenção diferentes para cada espaço de trabalho e cada tabela em um espaço de trabalho. Você precisará de 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	As camadas de compromisso permitem reduzir o custo de ingestão ao se comprometer com uma quantidade mínima de dados diários em um único espaço de trabalho.
Limitações do agente legado	Os agentes de máquina virtual herdados têm limitações no número de espaços de trabalho aos quais podem se conectar.
Controlo de acesso a dados	Configure o acesso ao espaço de trabalho e a diferentes tabelas e dados de diferentes recursos.
Resiliência	Para garantir que os dados em seu espaço de trabalho estejam disponíveis no caso de uma falha de região, você pode ingerir dados em vários espaços de trabalho em regiões diferentes.

Dados operacionais e de segurança

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

Espaços de trabalho dedicados A criação de espaços de trabalho dedicados para o Azure Monitor e o Microsoft Sentinel permitirá segregar a propriedade dos dados entre as equipes operacionais e de segurança. Essa abordagem também pode ajudar a otimizar os custos, já que quando o Microsoft Sentinel está habilitado em um espaço de trabalho, todos os dados nesse espaço de trabalho estã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 recebe 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. Veja Detalhes de preços dos Registos do Azure Monitor.

Espaço de trabalho combinado: combinar seus dados do Azure Monitor e do Microsoft Sentinel no mesmo espaço de trabalho oferece 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 espaço de trabalho usando contexto de recurso.

Essa configuração pode resultar em economia de custos se ajudar você a alcançar um nível de compromisso, que fornece um desconto para suas taxas de ingestão. Por exemplo, considere uma organização que tem dados operacionais e dados de segurança ingerindo cada um cerca de 50 GB por dia. A combinação dos dados no mesmo espaço de trabalho permitiria uma camada 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 espaço de trabalho dedicado, se exigido pela sua equipe de segurança ou se isso resultar em uma economia de custos. Considere combinar os dois para uma melhor visibilidade dos seus dados de monitorização combinados ou se isso o ajudar a alcançar um nível de compromisso.
Se você usa o Microsoft Sentinel e o Microsoft Defender for Cloud: 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 espaço de trabalho no mesmo locatário do Azure. As máquinas virtuais que usam o Azure Monitor Agent ou os agentes do Log Analytics podem enviar dados para espaços de trabalho em locatários do Azure separados. Você pode considerar 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 outras opções, incluindo estratégias para provedores de serviços, consulte Estratégias de vários locatários.

Regiões do Azure

Cada espaço de trabalho do Log Analytics reside em uma região específica do Azure. Você pode ter fins regulatórios ou de conformidade para manter 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 importante, como os Estados Unidos e a Europa.

Se você tiver requisitos para manter dados em uma geografia específica: crie um espaço de trabalho separado para cada região com esses requisitos.
Se você não tiver requisitos para manter dados em uma determinada geografia: use um único espaço de trabalho para todas as regiões.
Se você estiver enviando dados para uma geografia ou região fora da região do seu espaço de trabalho, independentemente de o recurso de envio residir ou não no Azure: considere usar um espaço de trabalho na mesma geografia ou região que seus dados.

Considere também possíveis cobranças de largura de banda que podem ser aplicadas quando você está enviando dados para um espaço de trabalho a partir de um recurso em outra região. Estes encargos são geralmente menores em relação aos custos de ingestão de dados para a maioria dos clientes. Essas cobranças geralmente resultam do envio de dados para o espaço de trabalho a partir de uma máquina virtual. O monitoramento de dados de outros recursos do Azure usando configurações de diagnóstico não incorre em cobranças de saída.

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

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

Propriedade dos dados

Você pode ter um requisito para segregar dados ou definir limites com base na propriedade. Por exemplo, você pode ter diferentes subsidiárias ou empresas afiliadas que exigem a delimitaçã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.

Faturação dividida

Talvez seja necessário dividir o faturamento entre diferentes partes ou realizar o chargeback para um cliente ou unidade de negócios interna. Você pode usar o Azure Cost Management + Billing para exibir cobranças por espaço de trabalho. Você também pode usar uma consulta de log para exibir o volume de dados faturáveis por recurso, grupo de recursos ou assinatura do Azure. Esta abordagem pode ser suficiente para os seus requisitos de faturação.

Se você não precisar dividir o faturamento ou executar o chargeback: use um único espaço de trabalho para todos os proprietários de custo.
Se você precisar dividir a cobrança ou executar o chargeback: considere se o Azure Cost Management + Billing ou uma consulta de log fornece relatórios de custos granulares o suficiente para suas necessidades. Caso contrário, use um espaço de trabalho separado para cada proprietário de custo.

Retenção de dados

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

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

Camadas de compromisso

As camadas de compromisso fornecem um desconto nos custos de ingestão do seu 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 alcançar o nível de uma camada específica. Esse mesmo volume de dados espalhados por vários espaços de trabalho não seria elegível para a mesma camada, a menos que você tenha um cluster dedicado.

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

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

Limitações do agente legado

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

O Azure Monitor Agent 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 Azure Monitor Agent ou certifique-se de que suas máquinas Linux exijam acesso apenas a um único espaço de trabalho.

Controlo de acesso a dados

Quando você concede 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 administração central ou equipe de segurança 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) baseado em função de contexto de recurso e 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 gerenciam sem que lhes seja concedido acesso explícito ao espaço de trabalho. Se precisar bloquear esse acesso, você pode alterar o modo de controle de acesso para exigir permissões explícitas de espaço de trabalho.

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 ou espaço de trabalho.
Se você quiser atribuir permissões explicitamente 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 a apenas tabelas específicas coletadas pelo Microsoft Sentinel a uma equipe de auditoria interna. Ou você pode negar o acesso a tabelas relacionadas à segurança para 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 RBAC de contexto de recursos para seus recursos.
Se você precisar de controle de acesso granular por tabela: conceda ou negue acesso a tabelas específicas usando RBAC no nível de tabela.

Para obter mais informações, consulte Gerenciar o acesso aos dados do Microsoft Sentinel por recurso.

Resiliência

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

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

Trabalhar com vários espaços de trabalho

Muitos projetos incluem vários espaços de trabalho. Por exemplo, uma equipe central de operações de segurança pode usar seus próprios espaços de trabalho do Microsoft Sentinel para gerenciar artefatos centralizados, como regras de análise ou pastas de trabalho.

O Azure Monitor e o Microsoft Sentinel incluem recursos para ajudá-lo a analisar esses dados em espaços de trabalho. Para obter mais informações, consulte:

Ao nomear cada espaço de trabalho, recomendamos incluir um indicador significativo no nome para que você possa identificar facilmente a finalidade de cada espaço de trabalho.

Várias estratégias de locatário

Ambientes com vários locatários do Azure, incluindo provedores de serviços Microsoft (MSPs), fornecedores independentes de software (ISVs) e grandes empresas, geralmente exigem uma estratégia em que uma equipe de administração central tenha 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.

Nota

Para parceiros e provedores de serviços que fazem parte do programa CSP (Provedor de Soluções na Nuvem), o Log Analytics no Azure Monitor é um dos serviços do Azure disponíveis nas 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 espaço de trabalho 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 diferentes de 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 cada locatário do cliente. Os administradores do provedor de serviços estão incluídos em um grupo de usuários do Microsoft Entra no locatário do provedor de serviços. Este grupo recebe acesso durante o processo de integração para cada cliente. Os administradores podem então 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 ter que entrar no locatário de cada cliente individualmente. Para obter mais informações, consulte 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 entrar no diretório de cada locatário no portal do Azure para acessar esses espaços de trabalho.

Vantagens desta 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 Azure RBAC.
Cada cliente pode ter configurações diferentes para seu espaço de trabalho, como retenção e limite de dados.
Isolamento entre clientes para fins regulatórios e de conformidade.
A cobrança por cada espaço de trabalho está incluída na fatura da assinatura do cliente.

Desvantagens desta estratégia:

A visualização e a análise centralizadas de dados entre locatários de clientes com ferramentas como pastas de trabalho do Azure Monitor podem resultar em experiências mais lentas. Este é o caso, especialmente ao analisar dados em mais de 50 espaços de trabalho.
Se os clientes não estiverem integrados para o 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 espaço de trabalho é 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 espaço de trabalho central.