Log Analytics 작업 영역 아키텍처 디자인

아티클
10/15/2024

Azure Monitor 및 Microsoft Sentinel을 사용하는 많은 환경에는 단일 Log Analytics 작업 영역이면 충분할 수 있습니다. 그러나 많은 조직은 비용을 최적화하고 다양한 비즈니스 요구 사항을 더 잘 충족하기 위해 여러 작업 영역을 만들게 될 것입니다. 이 문서에서는 단일 작업 영역을 사용할지 또는 여러 작업 영역을 사용할지 여부를 결정하기 위한 가이드라인을 제시합니다. 또한 비용을 최적화하면서 요구 사항까지 충족하기 위한 작업 영역의 구성 및 배치에 대해서도 설명합니다.

참고 항목

이 문서에서는 Azure Monitor와 Microsoft Sentinel 둘 다에 대해 설명합니다. 많은 고객이 디자인 단계에서 두 가지를 모두 고려해야 하기 때문입니다. 대부분의 결정 조건은 두 서비스 모두에 적용됩니다. 이러한 서비스 중 하나만 사용하는 경우 평가의 다른 서비스는 무시해도 됩니다.

이 비디오는 Azure Monitor Logs 배포를 디자인하기 위한 Azure Monitor Logs의 기본 사항과 모범 사례 및 디자인 고려 사항을 다룹니다.

디자인 전략

디자인은 여러 작업 영역을 관리하고 데이터를 쿼리해야 하는 복잡성을 줄이기 위해 항상 단일 작업 영역에서부터 시작하여야 합니다. 작업 영역의 데이터 양에 따른 성능 제한은 없습니다. 여러 서비스 및 데이터 원본이 동일한 작업 영역에 데이터를 보낼 수 있습니다. 더 많은 작업 영역을 만들기 위한 기준을 식별할 때, 디자인에서는 최소한의 작업 영역을 사용하여 요구 사항을 충족해야 합니다.

작업 영역 구성 디자인에는 여러 조건에 대한 평가가 포함됩니다. 그러나 일부 조건은 상충될 수 있습니다. 예를 들어, 각 Azure 지역에 별도의 작업 영역을 만들어 송신 요금을 줄일 수 있습니다. 단일 작업 영역으로 통합하면 약정 계층으로 요금을 훨씬 더 줄일 수 있습니다. 각 조건을 독립적으로 평가합니다. 요구 사항과 우선 순위를 고려하여 환경에 가장 효과적인 디자인을 결정합니다.

디자인 조건

다음 표는 작업 영역 아키텍처를 설계할 때 고려해야 할 조건을 나타냅니다. 다음 섹션에서는 조건을 설명합니다.

조건	설명
운영 및 보안 데이터	Microsoft Sentinel의 보안 데이터와 동일한 작업 영역에서 Azure Monitor의 운영 데이터를 결합하거나 자체 작업 영역으로 분리하도록 선택할 수 있습니다. 이를 결합하면 모든 데이터에 대해 더 나은 가시성을 얻을 수 있지만 보안 표준은 보안 팀이 전용 작업 영역을 유지하도록 구분해야 할 수 있습니다. 각 전략에 비용이 영향을 미칠 수도 있습니다.
Azure 테넌트	여러 Azure 테넌트가 있는 경우 일반적으로 각각에 작업 영역을 만듭니다. 여러 데이터 원본은 동일한 Azure 테넌트의 작업 영역에만 모니터링 데이터를 보낼 수 있습니다.
Azure 지역	각 작업 영역은 특정 Azure 지역에 있습니다. 특정 위치에 데이터를 저장하기 위한 규제 또는 규정 준수 요구 사항이 있을 수 있습니다.
데이터 소유권	데이터 소유권을 정의하기 위해 별도의 작업 영역을 만들도록 선택할 수 있습니다. 예를 들어, 자회사 또는 계열사별로 작업 영역을 만들 수 있습니다.
분할 청구	작업 영역을 별도의 구독에 배치하면 여러 당사자에게 비용을 청구할 수 있습니다.
데이터 보존	작업 영역의 각 작업 영역 및 각 테이블에 대해 서로 다른 보존 설정을 지정할 수 있습니다. 동일한 테이블에 데이터를 전송하는 서로 다른 리소스에 대해 서로 다른 보존 설정이 필요한 경우 별도의 작업 영역이 필요합니다.
약정 계층	약정 계층을 사용하면 단일 작업 영역에서 최소 크기의 일별 데이터를 커밋하여 수집 비용을 줄일 수 있습니다.
레거시 에이전트 제한 사항	레거시 가상 머신 에이전트는 연결할 수 있는 작업 영역 수가 제한됩니다.
데이터 액세스 제어	다른 리소스에서 작업 영역, 다른 테이블 및 데이터에 대한 액세스를 구성합니다.
복원력	지역 오류가 발생할 경우 작업 영역의 데이터를 사용할 수 있도록 하기 위해 다른 지역의 여러 작업 영역으로 데이터를 수집할 수 있습니다.

운영 및 보안 데이터

Microsoft Sentinel의 보안 데이터와 동일한 작업 영역에 Azure Monitor의 운영 데이터를 결합할지 또는 각각을 고유한 작업 영역으로 분리할지에 대한 결정은 보안 요구 사항 및 환경에 대한 잠재적 비용 영향에 따라 달라집니다.

전용 작업 영역 Azure Monitor 및 Microsoft Sentinel용 전용 작업 영역을 만들면 운영 팀과 보안 팀 간에 데이터 소유권을 분리할 수 있습니다. 이 접근 방식은 작업 영역에서 Microsoft Sentinel을 사용하도록 설정하면 Azure Monitor에서 수집한 운영 데이터인 경우에도 해당 작업 영역의 모든 데이터에 Microsoft Sentinel 가격 책정이 적용되므로 비용을 최적화하는 데 도움이 될 수 있습니다.

Microsoft Sentinel이 있는 작업 영역은 31일이 아닌 3개월의 무료 데이터 보존 기간을 갖습니다. 일반적으로 이 시나리오에서는 Microsoft Sentinel이 없는 작업 영역의 작동 데이터 비용이 높아집니다. Azure Monitor 로그 가격 책정 세부 정보를 참조하세요.

결합된 작업 영역 Azure Monitor와 Microsoft Sentinel의 데이터를 동일한 작업 영역에 결합하면 모든 데이터에 대해 더 나은 가시성을 제공하여 쿼리와 통합 문서 모두를 쉽게 결합할 수 있습니다. 보안 데이터에 대한 액세스를 특정 팀으로 제한해야 하는 경우 테이블 수준 RBAC를 사용하여 보안 데이터가 있는 테이블에서 특정 사용자를 차단하거나 사용자가 resource-context를 사용하여 작업 영역에 액세스하도록 제한할 수 있습니다.

이 구성은 수집 요금에 대한 할인을 제공하는 약정 계층에 도달하는 데 도움이 되는 경우 비용 절감 효과를 가져올 수 있습니다. 예를 들어 매일 약 50GB를 수집하는 운영 데이터 및 보안 데이터가 있는 조직을 고려해 보세요. 동일한 작업 영역에서 데이터를 결합하면 하루당 100GB의 약정 계층이 허용됩니다. 이 시나리오에서는 Azure Monitor에 대해 15% 할인을 제공하고 Microsoft Sentinel에 대해 50% 할인을 제공합니다.

다른 조건에 대해 별도의 작업 영역을 만드는 경우 일반적으로 더 많은 작업 영역 쌍을 만듭니다. 예를 들어, 두 개의 Azure 테넌트가 있는 경우 각 테넌트에 운영 및 보안 작업 영역이 있는 4개의 작업 영역을 만들 수 있습니다.

Azure Monitor와 Microsoft Sentinel을 모두 사용하는 경우: 보안 팀이 요구하거나 비용 절감 효과를 얻을 수 있는 경우 전용 작업 영역으로 각각을 분리하는 것이 좋습니다. 결합된 모니터링 데이터의 가시성을 향상시키거나 약정 계층에 도달하는 데 도움이 되는 경우 두 가지를 결합하는 것이 좋습니다.
Microsoft Sentinel 및 클라우드용 Microsoft Defender를 모두 사용하는 경우: 보안 데이터를 한 곳에 유지하기 위해 두 솔루션 모두 동일한 작업 영역을 사용하는 것이 좋습니다.

Azure 테넌트

대부분의 리소스는 동일한 Azure 테넌트에 있는 작업 영역에만 모니터링 데이터를 보낼 수 있습니다. Azure Monitor 에이전트 또는 Log Analytics 에이전트를 사용하는 가상 머신은 별도의 Azure 테넌트에 있는 작업 영역으로 데이터를 보낼 수 있습니다. 이 시나리오를 서비스 공급자로 간주할 수 있습니다.

단일 Azure 테넌트가 있는 경우: 해당 테넌트에 대한 단일 작업 영역을 만듭니다.
여러 Azure 테넌트가 있는 경우: 테넌트마다 작업 영역을 만듭니다. 서비스 공급자를 위한 전략을 비롯한 기타 옵션은 여러 테넌트 전략을 참조하세요.

Azure 지역

각 Log Analytics 작업 영역은 특정 Azure 지역에 있습니다. 특정 지역에 데이터를 보관하기 위한 규제 또는 규정 준수 목적이 있을 수 있습니다. 예를 들어 국제 기업은 미국 및 유럽과 같은 각 주요 지역에서 작업 영역을 찾을 수 있습니다.

특정 지역에 데이터를 보관하기 위한 요구 사항이 있는 경우: 이러한 요구 사항을 사용하여 각 지역에 대해 별도의 작업 영역을 만듭니다.
특정 지역에 데이터를 보관하기 위한 요구 사항이 없는 경우 모든 지역에 단일 작업 영역을 사용합니다.
작업 영역 지역과 다른 지리적 위치 또는 지역으로 데이터를 전송하는 경우 전송 리소스가 Azure에 있는지 여부에 관계없이 데이터와 동일한 지리적 위치 또는 지역에 있는 작업 영역을 사용하는 것이 좋습니다.

또한 다른 지역의 리소스에서 작업 영역으로 데이터를 보낼 때 적용될 수 있는 대역폭 요금도 고려합니다. 일반적으로 이러한 요금은 대부분의 고객의 데이터 수집 요금에 비하면 미미한 수준입니다. 이러한 요금은 일반적으로 가상 머신에서 작업 영역으로 데이터를 전송하여 발생합니다. 진단 설정을 사용하여 다른 Azure 리소스에서 데이터를 모니터링하면 송신 요금이 발생하지 않습니다.

Azure 가격 책정 계산기를 사용하여 비용을 예상하고 필요한 지역을 결정합니다. 대역폭 요금이 상당히 큰 경우 여러 지역의 작업 영역을 고려합니다.

대역폭 요금이 추가 복잡성을 정당화할 만큼 충분히 큰 경우: 가상 머신이 있는 각 지역에 대해 별도의 작업 영역을 만듭니다.
추가적인 복잡성을 정당화할 만큼 대역폭 요금이 크지 않은 경우: 모든 지역에 대해 단일 작업 영역을 사용합니다.

데이터 소유권

소유권에 따라 데이터를 분리하거나 경계를 정의해야 하는 요구 사항이 있을 수 있습니다. 예를 들어 모니터링 데이터의 경계가 필요한 다른 자회사 또는 계열사가 있을 수 있습니다.

데이터 분리가 필요한 경우: 각 데이터 소유자에 대해 별도의 작업 영역을 사용합니다.
데이터 분리가 필요하지 않은 경우: 모든 데이터 소유자에 대해 단일 작업 영역을 사용합니다.

분할 청구

서로 다른 당사자 간에 청구를 분할하거나 고객 또는 내부 사업부에 요금을 다시 청구해야 할 수 있습니다. Azure Cost Management + Billing을 사용하여 작업 영역별 요금을 볼 수 있습니다. 또한 로그 쿼리를 사용하여 Azure 리소스, 리소스 그룹 또는 구독별로 청구 가능한 데이터 볼륨을 볼 수 있습니다. 이 방식은 청구 요구 사항에 충분할 수 있습니다.

청구를 분할하거나 요금을 다시 청구할 필요가 없는 경우 모든 비용 소유자에 대해 단일 작업 영역을 사용합니다.
청구를 분할하거나 환불을 수행해야 하는 경우: Azure Cost Management + Billing 또는 로그 쿼리가 요구 사항에 충분히 세분화된 요금 보고를 제공하는지 여부를 고려합니다. 그렇지 않은 경우 각 비용 소유자에 대해 별도의 작업 영역을 사용합니다.

데이터 보존

작업 영역에 대한 기본 데이터 보존 설정을 구성하거나 각 테이블에 대해 서로 다른 설정을 구성할 수 있습니다. 특정 테이블의 데이터 집합마다 다른 설정이 필요할 수 있습니다. 그렇다면 해당 데이터를 각각 고유한 보존 설정이 있는 서로 다른 작업 영역으로 분리해야 합니다.

각 테이블의 모든 데이터에 대해 동일한 보존 설정을 사용할 수 있는 경우: 모든 리소스에 대해 단일 작업 영역을 사용합니다.
동일한 테이블의 다양한 리소스에 대해 서로 다른 보존 설정이 필요한 경우: 다양한 리소스에 대해 별도의 작업 영역을 사용합니다.

약정 계층

약정 계층은 일일 데이터의 특정 양을 약정할 때 작업 영역 수집 비용을 할인해 줍니다. 특정 계층 수준에 도달하기 위해 단일 작업 영역에서 데이터를 통합하도록 선택할 수 있습니다. 전용 클러스터가 없는 한, 여러 작업 영역에 분산된 이러한 동일한 양의 데이터가 동일한 계층에 적합하지 않을 수 있습니다.

매일 최소 100GB의 일별 수집을 약속할 수 있는 경우 추가 기능과 성능을 제공하는 전용 클러스터를 구현해야 합니다. 전용 클러스터를 사용하면 클러스터의 여러 작업 영역에서 있는 데이터를 결합하여 약정 계층 수준에 도달할 수도 있습니다.

모든 리소스에서 매일 최소 100GB를 수집하는 경우: 전용 클러스터를 만들고 적절한 약정 계층을 설정합니다.
리소스에서 하루 100GB 이상을 수집하는 경우 약정 계층을 활용하기 위해 단일 작업 영역으로 결합하는 것이 좋습니다.

레거시 에이전트 제한 사항

추가 요금 때문에 중복 데이터를 여러 작업 영역에 보내지 않는 것이 좋지만 가상 머신이 여러 작업 영역에 연결되어 있을 수 있습니다. 가장 일반적인 시나리오는 Azure Monitor 및 Microsoft Sentinel에 대한 별도의 작업 영역에 연결된 에이전트입니다.

Azure Monitor 에이전트 및 Windows용 Log Analytics 에이전트는 여러 작업 영역에 연결할 수 있습니다. Linux용 Log Analytics 에이전트는 단일 작업 영역에만 연결할 수 있습니다.

Linux용 Log Analytics 에이전트를 사용하는 경우Azure Monitor 에이전트로 마이그레이션하거나 Linux 머신이 단일 작업 영역에만 액세스하면 되는지 확인합니다.

데이터 액세스 제어

사용자에게 작업 영역에 대한 액세스 권한을 부여하면 사용자는 해당 작업 영역의 모든 데이터에 액세스할 수 있습니다. 이 액세스는 모든 리소스에 대한 데이터에 액세스해야 하는 중앙 관리 또는 보안 팀의 멤버에 적합합니다. 작업 영역에 대한 액세스는 리소스 컨텍스트 RBAC(역할 기반 액세스 제어) 및 테이블 수준 RBAC에 의해서도 결정됩니다.

리소스 컨텍스트 RBAC: 기본적으로 Azure 리소스에 대한 읽기 권한이 있는 경우 작업 영역으로 전송된 해당 리소스의 모니터링 데이터 권한을 상속합니다. 이 수준의 액세스를 통해 사용자는 작업 영역에 대한 명시적 액세스 권한을 부여받지 않고도 자신이 관리하는 리소스에 대한 정보에 액세스할 수 있습니다. 이 액세스를 차단해야 하는 경우 명시적 작업 영역 권한을 요구하도록 액세스 제어 모드를 변경할 수 있습니다.

사용자가 리소스에 대한 데이터에 액세스할 수 있도록 하려면 리소스 또는 작업 영역 사용 권한의 기본 액세스 제어 모드를 유지합니다.
모든 사용자에 대한 사용 권한을 명시적으로 할당하려면 액세스 제어 모드를 작업 영역 권한 필요로 변경합니다.

테이블 수준 RBAC: 테이블 수준 RBAC를 사용하면 작업 영역의 특정 테이블에 대한 액세스 권한을 부여하거나 거부할 수 있습니다. 이러한 방식으로 환경의 특정 상황에 필요한 세분화된 권한을 구현할 수 있습니다.

예를 들어, Microsoft Sentinel에서 수집한 특정 테이블에 대한 액세스 권한만 내부 감사 팀에 부여할 수 있습니다. 또는 리소스와 관련된 작동 데이터가 필요한 리소스 소유자의 보안 관련 테이블에 대한 액세스 권한을 거부할 수 있습니다.

테이블별로 세분화된 액세스 제어가 필요하지 않은 경우: 운영 및 보안 팀에게 해당 리소스에 대한 액세스 권한을 부여하고 리소스 소유자가 리소스에 리소스 컨텍스트 RBAC를 사용하도록 허용합니다.
테이블별로 세분화된 액세스 제어가 필요한 경우 테이블 수준 RBAC를 사용하여 특정 테이블에 대한 액세스 권한을 부여하거나 거부합니다.

자세한 내용은 리소스별로 Microsoft Sentinel 데이터에 대한 액세스 관리를 참조하세요.

복원력

지역 오류가 발생할 경우 작업 영역의 중요 데이터를 사용할 수 있도록 하기 위해 다른 지역의 여러 작업 영역으로 일부 또는 전체 데이터를 수집할 수 있습니다.

이 옵션을 사용하려면 다른 서비스 및 제품과의 통합을 작업 영역마다 별도로 관리해야 합니다. 오류가 발생하는 경우 대체 작업 영역에서 데이터를 사용할 수 있지만 경고 및 통합 문서와 같은 데이터를 사용하는 리소스는 대체 작업 영역으로 전환해야 할지 모릅니다. Azure DevOps의 대체 작업 영역에 대한 구성을 사용하여 또는 장애 조치(failover) 시나리오에서 빠르게 사용하도록 설정할 수 있는 비활성화된 정책으로 중요한 리소스에 ARM 템플릿을 저장하는 것이 좋습니다.

여러 작업 영역에서 작업

많은 디자인에는 여러 개의 작업 영역이 포함되어 있습니다. 예를 들어, 중앙 보안 운영 팀은 자체 Microsoft Sentinel 작업 영역을 사용하여 분석 규칙이나 통합 문서와 같은 중앙 집중식 아티팩트를 관리할 수 있습니다.

Azure Monitor와 Microsoft Sentinel에는 모두 여러 작업 영역에서 데이터를 분석하는 데 도움이 되는 기능이 포함되어 있습니다. 자세한 내용은 다음을 참조하세요.

각 작업 영역의 이름을 지정할 때는 의미 있는 표시를 이름에 포함하여 각 작업 영역의 목적을 쉽게 파악할 수 있도록 하는 것이 좋습니다.

여러 테넌트 전략

MSP(Microsoft 서비스 공급자), ISV(독립 소프트웨어 공급업체) 및 대기업을 비롯한 여러 Azure 테넌트가 있는 환경에서는 중앙 관리 팀이 다른 테넌트에 있는 작업 영역을 관리할 수 있도록 하는 전략이 필요한 경우가 많습니다. 각 테넌트는 별도의 고객 또는 다른 사업부를 나타낼 수 있습니다.

참고 항목

CSP(클라우드 솔루션 공급자) 프로그램에 참여하는 파트너 및 서비스 공급자의 경우 Azure CSP 구독에서 제공되는 Azure 서비스 중 하나로 Azure Monitor의 Log Analytics가 제공됩니다.

이 기능에 대한 두 가지 기본 전략은 다음 섹션에서 설명합니다.

분산 아키텍처

분산 아키텍처에서 Log Analytics 작업 영역은 각 Azure 테넌트에 만들어집니다. 이 옵션은 가상 머신이 아닌 Azure 서비스를 모니터링하는 경우 사용할 수 있는 유일한 옵션입니다.

서비스 공급자 관리자가 고객 테넌트에서 작업 영역에 액세스할 수 있도록 허용하는 두 가지 옵션이 있습니다.

Azure Lighthouse를 사용하여 각 고객 테넌트에 액세스합니다. 서비스 공급자 관리자는 서비스 공급자 테넌트의 Microsoft Entra 사용자 그룹에 포함됩니다. 이 그룹은 각 고객의 온보딩 프로세스 중에 액세스 권한이 부여됩니다. 그런 다음 관리자는 각 고객의 테넌트에 개별적으로 로그인하지 않고 자체 서비스 공급자 테넌트 내에서 각 고객의 작업 영역에 액세스할 수 있습니다. 자세한 내용은 대규모로 고객 리소스 모니터링을 참조하세요.
서비스 공급자의 개별 사용자를 Microsoft Entra 게스트 사용자(B2B)로 추가합니다. 고객 테넌트 관리자는 각 서비스 공급자 관리자에 대한 개별 액세스를 관리합니다. 서비스 공급자 관리자는 이러한 작업 영역에 액세스하려면 Azure Portal의 각 테넌트에 대한 디렉터리에 로그인해야 합니다.

이 전략의 장점:

로그는 모든 형식의 리소스에서 수집될 수 있습니다.
고객은 Azure 위임 리소스 관리를 통해 특정 수준의 권한을 확인할 수 있습니다. 또는 고객이 자체 Azure RBAC를 사용하여 로그에 대한 액세스를 관리할 수 있습니다.
각 고객은 보존 및 데이터 제한과 같은 해당 작업 영역의 설정이 서로 다를 수 있습니다.
규정 및 준수를 위해 고객을 서로 격리합니다.
각 작업 영역에 대한 요금이 고객의 구독에 대한 청구서에 포함됩니다.

이 전략의 단점:

Azure Monitor 통합 문서와 같은 도구를 사용하여 고객 테넌트 전체의 데이터를 중앙에서 시각화하고 분석하면 환경이 느려질 수 있습니다. 특히 50개 이상의 작업 영역에서 데이터를 분석할 때 그렇습니다.
Azure 삭제 리소스 관리를 위해 고객이 온보딩되지 않은 경우 서비스 공급자 관리자가 고객 디렉터리에 프로비전되어야 합니다. 이 요구 사항으로 인해 서비스 공급자는 한 번에 많은 고객 테넌트를 관리하기가 더 어렵습니다.

중앙 집중식

서비스 공급자의 구독에 단일 작업 영역이 만들어집니다. 이 옵션은 고객 가상 머신에서만 데이터를 수집할 수 있습니다. 가상 머신에 설치된 에이전트는 해당 로그를 이 중앙 작업 영역으로 보내도록 구성됩니다.