클라우드용 Microsoft Defender 문제 해결 가이드

이 가이드는 조직에서 클라우드용 Microsoft Defender와 관련된 문제를 해결해야 하는 IT 전문가, 정보 보안 분석이 및 클라우드 관리자를 위한 것입니다.

팁

문제가 발생하거나 지원 팀의 조언이 필요한 경우 Azure Portal의 문제 진단 및 해결 섹션에서 솔루션을 찾을 수 있습니다.

감사 로그를 사용하여 문제 조사

문제 해결 정보를 찾는 첫 번째 장소는 실패한 구성 요소에 대한 감사 로그입니다. 감사 로그에서 다음과 같은 세부 정보를 볼 수 있습니다.

• 수행된 작업입니다.
• 작업을 시작한 사람입니다.
• 작업이 발생한 시간
• 작업의 상태입니다.

감사 로그에는 리소스에서 수행된 모든 쓰기 작업(PUT, POST, DELETE)이 포함되지만 읽기 작업(GET)은 포함되지 않습니다.

커넥터 문제 해결

클라우드용 Defender는 커넥터를 사용하여 AWS(Amazon Web Services) 계정 및 GCP(Google Cloud Platform) 프로젝트에서 모니터링 데이터를 수집합니다. 커넥터에 문제가 있거나 AWS 또는 GCP의 데이터가 표시되지 않는 경우 다음 문제 해결 팁을 검토합니다.

일반적인 커넥터 문제에 대한 팁

• 커넥터와 연결된 구독이 Azure Portal의 디렉터리 + 구독 섹션에 있는 구독 필터에서 선택되어 있는지 확인합니다.
• 보안 커넥터에 표준을 할당해야 합니다. 확인하려면 클라우드용 Defender 왼쪽 메뉴에서 환경 설정으로 이동하여 커넥터를 선택한 다음 설정을 선택합니다. 표준이 할당되지 않은 경우 세 개의 점을 선택하여 표준을 할당할 권한이 있는지 확인합니다.
• Azure Resource Graph에 커넥터 리소스가 있어야 합니다. 다음 Resource Graph 쿼리를 사용하여 확인합니다. resources | where ['type'] =~ "microsoft.security/securityconnectors".
• 컨트롤 플레인에 대한 위협 탐지 경고를 받을 수 있도록 AWS 또는 GCP 커넥터에서 Kubernetes 감사 로그 보내기가 설정되어 있는지 확인합니다.
• Microsoft Defender 센서와 Azure Arc 지원 Kubernetes 확장에 대한 Azure Policy가 Amazon Elastic Kubernetes Service(EKS) 및 GKE(Google Kubernetes Engine) 클러스터에 성공적으로 설치되었는지 확인합니다. 다음 클라우드용 Defender 권장 사항을 사용하여 에이전트를 확인하고 설치할 수 있습니다.
  • EKS 클러스터에는 Azure Arc용 Microsoft Defender의 확장이 설치되어 있어야 합니다.
  • EKS 클러스터에는 Azure Arc용 Microsoft Defender의 확장이 설치되어 있어야 함
  • Azure Arc 지원 Kubernetes 클러스터에 Azure Policy 확장이 설치되어 있어야 합니다.
  • GKE 클러스터에는 Azure Policy 확장이 설치되어 있어야 합니다.
• AWS 또는 GCP 커넥터를 삭제하는 데 문제가 발생하는 경우 잠금 장치가 있는지 확인합니다. Azure 활동 로그의 오류는 잠금이 있음을 암시할 수 있습니다.
• AWS 계정 또는 GCP 프로젝트에 워크로드가 있는지 확인합니다.

AWS 커넥터 문제에 대한 팁

• CloudFormation 템플릿 배포가 성공적으로 완료되었는지 확인합니다.
• AWS 루트 계정을 만든 후 최소 12시간을 기다립니다.
• EKS 클러스터가 Azure Arc 지원 Kubernetes에 성공적으로 연결되었는지 확인합니다.
• 클라우드용 Defender에 AWS 데이터가 표시되지 않으면 클라우드용 Defender로 데이터를 보내는 데 필요한 AWS 리소스가 AWS 계정에 있는지 확인합니다.

AWS에 대한 API 호출이 비용에 미치는 영향

AWS 단일 또는 마스터 계정을 온보딩하면 클라우드용 Defender의 검사 서비스가 환경에 대한 즉시 검사를 시작합니다. 검색 서비스는 Azure가 보호하는 데 도움이 되는 모든 리소스를 발견하기 위해 다양한 서비스 엔드포인트에 대한 API 호출을 실행합니다.

이 초기 검사 이후 서비스는 온보딩 중에 구성한 간격으로 환경을 주기적으로 계속 검사합니다. AWS에서는 계정에 대한 각 API 호출이 CloudTrail 리소스에 기록되는 조회 이벤트를 생성합니다. CloudTrail 리소스에는 비용이 발생합니다. 가격 책정에 대한 자세한 내용은 Amazon AWS 사이트의 AWS CloudTrail 가격 책정 페이지를 참조하세요.

CloudTrail을 GuardDuty에 연결한 경우 관련 비용도 사용자가 부담해야 합니다. Amazon AWS 사이트의 GuardDuty 설명서에서 이러한 비용을 확인할 수 있습니다.

네이티브 API 호출 수 가져오기

클라우드용 Defender에서 수행한 호출 수를 가져오는 방법에는 두 가지가 있습니다.

• 기존 Athena 테이블을 사용하거나 새 테이블을 만듭니다. 자세한 내용은 Amazon AWS 사이트에서 AWS CloudTrail 로그 쿼리를 참조하세요.
• 기존 이벤트 데이터 저장소를 사용하거나 새 저장소를 만듭니다. 자세한 내용은 Amazon AWS 사이트에서 AWS CloudTrail Lake 작업을 참조하세요.

두 방법 모두 AWS CloudTrail 로그 쿼리를 사용합니다.

호출 수를 가져오려면 Athena 테이블 또는 이벤트 데이터 저장소로 이동하여 필요에 따라 다음과 같은 미리 정의된 쿼리 중 하나를 사용합니다. <TABLE-NAME>을 Athena 테이블 또는 이벤트 데이터 저장소의 ID로 바꿉니다.

• 클라우드용 Defender의 전체 API 호출 수를 나열합니다.

  SELECT COUNT(*) AS overallApiCallsCount FROM <TABLE-NAME> 
  WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
  AND eventTime > TIMESTAMP '<DATETIME>' 
  

• 날짜별로 집계된 클라우드용 Defender의 전체 API 호출 수를 나열합니다.

  SELECT DATE(eventTime) AS apiCallsDate, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME> 
  WHERE userIdentity.arn LIKE 'arn:aws:sts:: <YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
  AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY DATE(eventTime)
  

• 이벤트 이름별로 집계된 클라우드용 Defender의 전체 API 호출 수를 나열합니다.

  SELECT eventName, COUNT(*) AS apiCallsCountByEventName FROM <TABLE-NAME> 
  WHERE userIdentity.arn LIKE 'arn:aws:sts::<YOUR-ACCOUNT-ID>:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
  AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY eventName     
  

• 지역별로 집계된 클라우드용 Defender의 전체 API 호출 수를 나열합니다.

  SELECT awsRegion, COUNT(*) AS apiCallsCountByRegion FROM <TABLE-NAME> 
  WHERE userIdentity.arn LIKE 'arn:aws:sts::120589537074:assumed-role/CspmMonitorAws/MicrosoftDefenderForClouds_<YOUR-AZURE-TENANT-ID>' 
  AND eventTime > TIMESTAMP '<DATETIME>' GROUP BY awsRegion
  

GCP 커넥터 문제에 대한 팁

• GCP Cloud Shell 스크립트가 성공적으로 완료되었는지 확인합니다.
• GKE 클러스터가 Azure Arc 지원 Kubernetes에 성공적으로 연결되었는지 확인합니다.
• Azure Arc 엔드포인트가 방화벽 허용 목록에 있는지 확인합니다. GCP 커넥터는 이러한 엔드포인트에 대한 API 호출을 수행하여 필요한 온보딩 파일을 가져옵니다.
• GCP 프로젝트 온보딩에 실패하면 온보딩 프로세스에 대한 서비스 주체를 만들 수 있는 compute.regions.list 권한과 Microsoft Entra 권한이 있는지 확인합니다. GCP 리소스 WorkloadIdentityPoolId, WorkloadIdentityProviderId 및 ServiceAccountEmail이 GCP 프로젝트에서 만들어졌는지 확인합니다.

GCP에 대한 Defender API 호출

GCP 단일 프로젝트 또는 조직을 온보딩하면 클라우드용 Defender의 검사 서비스가 환경에 대한 즉시 검사를 시작합니다. 검색 서비스는 Azure가 보호하는 데 도움이 되는 모든 리소스를 발견하기 위해 다양한 서비스 엔드포인트에 대한 API 호출을 실행합니다.

이 초기 검사 이후 서비스는 온보딩 중에 구성한 간격으로 환경을 주기적으로 계속 검사합니다.

클라우드용 Defender가 실행한 네이티브 API 호출 수를 가져오려면 다음을 수행합니다.

1. 로깅>로그 탐색기로 이동합니다.

2. 원하는 대로 날짜를 필터링합니다(예: 1d).

3. 클라우드용 Defender가 실행한 API 호출을 표시하려면 다음 쿼리를 실행합니다.

   protoPayload.authenticationInfo.principalEmail : "microsoft-defender"
   

시간 경과에 따른 호출 수를 보려면 히스토그램을 참조하세요.

Log Analytics 에이전트 문제를 해결합니다.

클라우드용 Defender는 Log Analytics 에이전트를 사용하여 데이터를 수집하고 저장합니다. 이 문서의 정보는 Log Analytics 에이전트로 전환한 후 클라우드용 Defender 기능을 나타냅니다.

경고 형식은 다음과 같습니다.

• VMBA(Virtual Machine 동작 분석)
• 네트워크 분석
• Azure SQL Database 및 Azure Synapse Analytics 분석
• 컨텍스트 정보

경고 형식에 따라 다음 리소스를 사용하여 경고를 조사하는 데 필요한 정보를 수집할 수 있습니다.

• Windows VM(가상 머신) 이벤트 뷰어의 보안 로그
• Linux의 감사 디먼(auditd)
• Azure 활동 로그 및 공격 리소스에 대한 진단 로그를 사용하도록 설정합니다.

경고 설명 및 관련성에 대한 피드백을 공유할 수 있습니다. 경고로 이동하여 이 정보가 유용했나요? 단추를 선택하고 이유를 선택한 다음 피드백을 의견을 입력하여 피드백을 설명합니다. 이 피드백 채널을 지속적으로 모니터링하여 경고를 개선하고 있습니다.

Log Analytics 에이전트 프로세스 및 버전 확인

Azure Monitor와 마찬가지로 클라우드용 Defender는 Log Analytics 에이전트를 사용하여 Azure Virtual Machines에서 보안 데이터를 수집합니다. 데이터 수집을 사용하도록 설정하고 대상 컴퓨터에 에이전트를 올바르게 설치한 후에는 HealthService.exe 프로세스가 실행되어야 합니다.

서비스 관리 콘솔(services.msc)을 열어 Log Analytics 에이전트 서비스가 실행 중인지 확인합니다.

사용 중인 에이전트 버전을 확인하려면 작업 관리자를 엽니다. 프로세스 탭에서 Log Analytics 에이전트 서비스를 찾아 마우스 오른쪽 단추로 클릭한 다음 속성을 선택합니다. 세부 정보 탭에서 파일 버전을 찾습니다.

Log Analytics 에이전트 설치 시나리오 확인

컴퓨터에 Log Analytics 에이전트를 설치하는 경우 다른 결과를 생성할 수 있는 두 가지 설치 시나리오가 있습니다. 지원되는 시나리오는 다음과 같습니다.

• 클라우드용 Defender에 의해 자동으로 설치된 에이전트: 클라우드용 Defender 및 로그 검색에서 경고를 볼 수 있습니다. 리소스가 속한 구독에 대한 보안 정책에서 구성한 이메일 주소로 이메일 알림을 받습니다.

• Azure에 있는 VM에 수동으로 설치된 에이전트: 이 시나리오에서 2017년 2월 이전에 수동으로 다운로드하고 설치한 에이전트를 사용하는 경우 작업 영역이 속한 구독에서 필터링할 때에만 클라우드용 Defender 포털의 경고를 볼 수 있습니다. 리소스가 속한 구독에서 필터링하는 경우 경고가 표시되지 않습니다. 작업 영역이 속한 구독에 대한 보안 정책에서 구성한 이메일 주소로 이메일 알림을 받습니다.

  필터링 문제를 방지하려면 최신 버전의 에이전트를 다운로드합니다.

에이전트의 네트워크 연결 문제 모니터링

에이전트가 클라우드용 Defender에 연결하고 등록하려면 Azure 네트워크 리소스에 대한 DNS 주소 및 네트워크 포트에 액세스할 수 있어야 합니다. 이 액세스를 사용하도록 설정하려면 다음 작업을 수행합니다.

• 프록시 서버를 사용하는 경우 에이전트 설정에서 적절한 프록시 서버 리소스가 올바르게 구성되었는지 확인합니다.
• Log Analytics에 대한 액세스를 허용하도록 네트워크 방화벽을 구성합니다.

Azure 네트워크 리소스는 다음과 같습니다.

에이전트 리소스	포트	HTTPS 검사 안 함
*.ods.opinsights.azure.com	443	예
*.oms.opinsights.azure.com	443	예
*.blob.core.windows.net	443	예
*.azure-automation.net	443	예

Log Analytics 에이전트 온보딩에 문제가 있는 경우 Operations Management Suite 온보딩 문제 해결을 참조하세요.

부적절하게 작동하는 맬웨어 방지 보호 문제 해결

게스트 에이전트는 Microsoft Antimalware 확장에서 수행하는 모든 작업의 부모 프로세스입니다. 게스트 에이전트 프로세스가 실패하면 게스트 에이전트의 자식 프로세스로 실행되는 Microsoft Antimalware 보호도 실패할 수 있습니다.

다음은 몇 가지 문제 해결 팁입니다.

• 대상 VM이 사용자 지정 이미지에서 만들어진 경우 VM 작성자가 게스트 에이전트를 설치했는지 확인합니다.
• 대상이 Linux VM인 경우 맬웨어 방지 확장의 Windows 버전 설치가 실패합니다. Linux 게스트 에이전트에는 특정 OS 및 패키지 요구 사항이 있습니다.
• 이전 버전의 게스트 에이전트를 사용하여 VM을 만든 경우 이전 에이전트에는 최신 버전으로 자동 업데이트하는 기능이 없을 수 있습니다. 고유한 이미지를 만들 때는 항상 최신 버전의 게스트 에이전트를 사용합니다.
• 일부 타사 관리 소프트웨어는 게스트 에이전트를 사용하지 않도록 설정하거나 특정 파일 위치에 대한 액세스를 차단할 수 있습니다. VM에 타사 관리 소프트웨어가 설치된 경우 맬웨어 방지 에이전트가 제외 목록에 있는지 확인합니다.
• 방화벽 설정 및 네트워크 보안 그룹이 게스트 에이전트와 주고받는 네트워크 트래픽을 차단하지 않는지 확인합니다.
• 디스크 액세스를 방해하는 액세스 제어 목록이 없는지 확인합니다.
• 게스트 에이전트가 제대로 작동하려면 충분한 디스크 공간이 필요합니다.

기본적으로 Microsoft Antimalware 사용자 인터페이스는 사용하지 않도록 설정되어 있습니다. 하지만 Azure Resource Manager VM에서는 Microsoft Antimalware 사용자 인터페이스를 사용하도록 설정할 수 있습니다.

대시보드 로드 관련 문제 해결

워크로드 보호 대시보드를 로드하는 데 문제가 발생하는 경우 구독에서 클라우드용 Defender를 처음 활성화한 사용자와 데이터 수집을 켜려는 사용자에게 구독에 대한 소유자 또는 기여자 역할이 있는지 확인하세요. 그렇다면 구독에 대한 읽기 권한자 역할이 있는 사용자는 대시보드, 경고, 권장 사항 및 정책을 볼 수 있습니다.

Azure DevOps 조직의 커넥터 문제 해결

Azure DevOps 조직을 온보딩할 수 없는 경우 다음 문제 해결 팁을 시도해 보세요.

• Azure Portal의 미리 보기 버전이 아닌 버전을 사용하고 있는지 확인합니다. Azure 미리 보기 포털에서는 권한 부여 단계가 작동하지 않습니다.

• 액세스를 권한 부여할 때 어떤 계정에 로그인했는지 아는 것이 중요합니다. 왜냐하면 이 계정이 시스템이 온보딩에 사용하는 계정이 되기 때문입니다. 사용자의 계정은 동일한 이메일 주소와 연결될 수 있지만 다른 테넌트와 연결될 수도 있습니다. 올바른 계정/테넌트 조합을 선택했는지 확인합니다. 조합을 변경해야 하는 경우:

  1. Azure DevOps 프로필 페이지에서 드롭다운 메뉴를 사용하여 다른 계정을 선택합니다.

     

  2. 올바른 계정/테넌트 조합을 선택한 후 클라우드용 Defender의 환경 설정으로 이동하여 Azure DevOps 커넥터를 편집합니다. 커넥터를 다시 권한 부여하여 올바른 계정/테넌트 조합으로 업데이트합니다. 그러면 드롭다운 메뉴에 올바른 조직 목록이 표시됩니다.

• 온보딩하려는 Azure DevOps 조직에 대한 프로젝트 컬렉션 관리자 역할이 있는지 확인합니다.

• Azure DevOps 조직에 대해 OAuth를 통한 타사 애플리케이션 액세스 토글이 켜짐인지 확인합니다. OAuth 액세스 사용하도록 설정에 대해 자세히 알아봅니다.

Microsoft 지원에 문의

클라우드용 Defender Q&A 페이지에서도 클라우드용 Defender에 대한 문제 해결 정보를 찾을 수 있습니다.

추가 지원이 필요한 경우 Azure Portal에서 새 지원 요청을 열 수 있습니다. 도움말 + 지원 페이지에서 지원 요청 만들기를 선택합니다.

참고 항목

• 클라우드용 Defender에서 보안 경고를 관리하고 대응하는 방법을 알아봅니다.
• 클라우드용 Defender의 경고 유효성 검사에 대해 알아봅니다.
• 클라우드용 Defender 사용에 관한 일반적인 질문을 검토합니다.