위협 조사 및 대응

이 주제에서는 위협을 조사하고 대응하며, 추가 리소스를 사용하여 Security Command Center 결과에 컨텍스트를 추가하는 데 도움이 되는 비공식적인 가이드를 제공합니다. 다음 단계에 따라 잠재적인 공격으로 발생한 상황에 대해 이해하고 영향을 받은 리소스에 대해 가능한 응답을 개발할 수 있습니다.

이 페이지의 기법이 과거, 현재 또는 미래의 모든 위협에 대해 효과적이라고 보장할 수는 없습니다. Security Command Center에서 위협에 대한 공식 해결 방법을 제공하지 않는 이유를 알아보려면 위협 해결을 참조하세요.

시작하기 전에

발견 항목 및 로그를 보거나 수정하고 Google Cloud 리소스를 수정하려면 적절한 Identity and Access Management(IAM) 역할이 필요합니다. Security Command Center에서 액세스 오류가 발생하면 관리자에게 지원을 요청하고 액세스 제어에서 역할에 대해 알아보세요. 리소스 오류를 해결하려면 영향을 받는 제품 관련 문서를 참조하세요.

위협 발견 항목 이해

Event Threat Detection은 Cloud Logging 로그 스트림의 이벤트를 알려진 침해 지표(IoC)와 일치시켜 보안 발견 항목을 생성합니다. 내부 Google 보안 소스에서 개발한 IoC는 잠재적인 취약점과 공격을 식별합니다. 또한 Event Threat Detection은 로깅 스트림에서 알려진 적대 전략, 기술, 절차를 식별하고 조직 또는 프로젝트의 과거 동작에서 편차를 감지하여 위협을 감지합니다. 조직 수준에서 Security Command Center 프리미엄 등급을 활성화하면 Event Threat Detection에서 Google Workspace 로그를 검사할 수도 있습니다.

Container Threat Detection은 컨테이너의 게스트 커널에서 하위 수준의 관찰된 동작을 수집하고 분석하여 발견 항목을 생성합니다.

발견 항목은 Security Command Center에 기록됩니다. 조직 수준에서 Security Command Center 프리미엄 등급을 활성화하면 발견 항목이 Cloud Logging에 기록되도록 구성할 수도 있습니다.

발견 항목 검토

Google Cloud 콘솔에서 위협 발견 항목을 검토하려면 다음 단계를 수행합니다.

Google Cloud 콘솔에서 Security Command Center 발견 항목 페이지로 이동합니다.
발견 항목으로 이동
필요한 경우 Google Cloud 프로젝트, 폴더, 조직을 선택합니다.
빠른 필터 섹션에서 발견 항목 쿼리 결과 테이블에서 필요한 발견 항목을 표시하기 위해 적합한 필터를 클릭합니다. 예를 들어 소스 표시 이름 하위 섹션에서 Event Threat Detection 또는 Container Threat Detection을 선택하면 선택한 서비스의 발견 항목만 결과에 표시됩니다.

테이블은 선택한 소스의 발견 항목으로 채워집니다.
특정 발견 항목의 세부정보를 보려면 Category에서 '발견 항목 이름'을 클릭합니다. 발견 항목 세부정보 창이 확장되어 발견 항목 세부정보 요약이 표시됩니다.
발견 항목의 JSON 정의를 보려면 JSON 탭을 클릭합니다.

발견 항목은 환경 변수 및 애셋 속성과 함께 이슈와 관련된 리소스의 이름 및 숫자 식별자를 제공합니다. 이 정보를 사용하여 영향을 받는 리소스를 신속하게 격리하고 이벤트의 잠재적 범위를 결정할 수 있습니다.

조사에 도움이 되도록 위협 발견 항목에는 다음 외부 리소스에 대한 링크도 포함됩니다.

MITRE ATT&CK 프레임워크 항목입니다. 이 프레임워크는 클라우드 리소스에 대한 공격의 기술을 설명하고 문제 해결 방법을 제공합니다.
VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.

다음 섹션에서는 위협 발견 항목에 대한 잠재적 응답을 간략하게 설명합니다.

위협 발견 항목 비활성화

위협 발견 항목을 트리거한 문제가 해결된 후 Security Command Center는 발견 항목의 상태를 INACTIVE로 자동으로 설정하지 않습니다. state 속성을 INACTIVE로 수동으로 설정하지 않는 한 위협 발견 항목의 상태는 ACTIVE로 유지됩니다.

거짓양성의 경우 발견 항목 상태를 ACTIVE로 두고, 대신 발견 항목을 숨기는 것이 좋습니다.

지속적이거나 반복되는 거짓양성의 경우 숨기기 규칙을 만듭니다. 숨기기 규칙을 설정하면 관리해야 하는 발견 항목 수가 줄어들기 때문에 실제 위협이 발생할 때 더 쉽게 식별할 수 있습니다.

실제 위협의 경우 발견 항목 상태를 INACTIVE로 설정하기 전에 위협을 제거하고 감지된 위협, 침입 범위, 기타 관련 발견 항목을 조사하세요.

발견 항목을 숨기거나 상태를 변경하려면 다음 주제를 참조하세요.

Event Threat Detection 대응

Event Threat Detection에 대한 상세 설명은 Event Threat Detection 작동 방식을 참조하세요.

이 섹션에는 Event Threat Detection용 커스텀 모듈에 의해 생성된 발견 항목에 대한 응답은 포함되지 않습니다. 이러한 감지기에 대한 권장 조치는 조직이 정의하기 때문입니다.

`Evasion: Access from Anonymizing Proxy`

익명처리 프록시에서 비정상적인 액세스는 Tor IP 주소와 같은 익명 프록시 IP 주소에서 발생한 Google Cloud 서비스 수정에 대한 Cloud 감사 로그를 검사하여 감지됩니다.

이러한 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Evasion: Access from Anonymizing Proxy 발견 항목을 엽니다. 발견 항목 세부정보 패널이 열리고 요약 탭이 표시됩니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션에 나열된 값을 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 변경을 수행한 계정(잠재적으로 도용된 계정)
  - IP: 변경사항이 수행된 프록시 IP 주소
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
선택적으로 JSON 탭을 클릭하여 추가 발견 항목 필드를 확인합니다.

2단계: 공격 및 대응 방법 조사하기

프록시: 멀티 홉 프록시 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목의 검토합니다.
principalEmail 필드에서 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Defense Evasion: Breakglass Workload Deployment Created`

Breakglass Workload Deployment Created는 Cloud 감사 로그를 검사하여 breakglass 플래그를 사용하여 Binary Authorization 제어를 재정의하는 워크로드에 대한 배포가 있는지 확인하여 감지됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Defense Evasion: Breakglass Workload Deployment Created 발견 항목을 엽니다. 발견 항목 세부정보 패널이 열리고 요약 탭이 표시됩니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 기본 이메일: 수정을 수행한 계정
  - 메서드 이름: 호출된 메서드
  - Kubernetes 포드: 포드 이름 및 네임스페이스입니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 배포가 발생한 GKE 네임스페이스입니다.
- 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 로그 확인하기

Google Cloud 콘솔의 발견 항목 세부정보 요약탭에서 Cloud Logging URI 필드의 링크를 클릭하여 로그 탐색기로 이동합니다.
protoPayload.resourceName 필드의 값을 확인하여 특정 인증서 서명 요청을 식별합니다.
다음 필터를 사용하여 주 구성원이 수행한 다른 작업을 확인합니다.
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  다음을 바꿉니다.
- CLUSTER_NAME: 발견 항목 세부정보의 리소스 표시 이름 필드에서 확인한 값입니다.
- PRINCIPAL_EMAIL: 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값입니다.

3단계: 공격 및 대응 방법 조사하기

방어 회피: Breakglass 워크로드 배포 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토하세요.
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Defense Evasion: Breakglass Workload Deployment Updated`

Breakglass Workload Deployment Updated는 Cloud 감사 로그를 검사하여 breakglass 플래그를 사용하여 Binary Authorization 제어를 재정의하는 워크로드에 대한 업데이트가 있는지 확인하여 감지됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Defense Evasion: Breakglass Workload Deployment Updated 발견 항목을 엽니다. 발견 항목 세부정보 패널이 열리고 요약 탭이 표시됩니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 기본 이메일: 수정을 수행한 계정
  - 메서드 이름: 호출된 메서드
  - Kubernetes 포드: 포드 이름 및 네임스페이스입니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 업데이트가 발생한 GKE 네임스페이스입니다.
- 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 로그 확인하기

Google Cloud 콘솔의 발견 항목 세부정보 요약탭에서 Cloud Logging URI 필드의 링크를 클릭하여 로그 탐색기로 이동합니다.
protoPayload.resourceName 필드의 값을 확인하여 특정 인증서 서명 요청을 식별합니다.
다음 필터를 사용하여 주 구성원이 수행한 다른 작업을 확인합니다.
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  다음을 바꿉니다.
- CLUSTER_NAME: 발견 항목 세부정보의 리소스 표시 이름 필드에서 확인한 값입니다.
- PRINCIPAL_EMAIL: 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값입니다.

3단계: 공격 및 대응 방법 조사하기

방어 회피: Breakglass 워크로드 배포 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토하세요.
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Defense Evasion: Manually Deleted Certificate Signing Request (CSR)`

누군가 인증서 서명 요청(CSR)을 수동으로 삭제했습니다. CSR은 가비지 컬렉션 컨트롤러에 의해 자동으로 삭제되지만 악의적인 행위자가 감지를 회피하기 위해 CSR을 수동으로 삭제할 수 있습니다. 삭제된 CSR이 승인 및 발급된 인증서에 대한 것이면 잠재적인 악의적 행위자는 이제 클러스터에 액세스할 수 있는 추가 인증 방법을 갖게 됩니다. 인증서에 연결된 권한은 포함된 주체에 따라 다르지만 권한이 높을 수 있습니다. Kubernetes는 인증서 취소를 지원하지 않습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

Cloud Logging의 감사 로그와 이 CSR과 관련된 기타 이벤트에 대한 추가 알림을 검토하여 CSR이 approved되었는지, CSR 생성이 주 구성원에 의한 예상된 활동인지 확인하세요.
Cloud Logging의 감사 로그에서 주 구성원에 의한 다른 악의적인 활동 징후가 있는지 확인하세요. 예를 들면 다음과 같습니다.
- CSR을 삭제한 주 구성원이 CSR을 만들거나 승인한 주 구성원과 다르나요?
- 주 구성원이 다른 CSR을 요청, 생성, 승인 또는 삭제하려고 시도했나요?
CSR 승인이 예상되지 않았거나 악의적인 것으로 확인되면 인증서를 무효화하기 위해 클러스터에 사용자 인증 정보 순환이 필요합니다. 클러스터 사용자 인증 정보 순환을 수행하는 방법에 대한 안내를 검토하세요.

`Defense Evasion: Modify VPC Service Control`

프로젝트 수준의 활성화에는 이 발견 항목을 사용할 수 없습니다.

감사 로그를 검사하여 해당 경계에서 제공하는 보호의 축소로 이어질 수 있는 VPC 서비스 제어 경계의 변경사항을 감지합니다. 다음은 몇 가지 예입니다.

프로젝트가 경계에서 삭제됨
액세스 수준 정책이 기존 경계에 추가됨
액세스 가능한 서비스 목록에 하나 이상의 서비스가 추가됨

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Defense Evasion: Modify VPC Service Control 발견 항목을 엽니다. 발견 항목 세부정보 패널이 열리고 요약 탭이 표시됩니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 기본 이메일: 수정을 수행한 계정
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 수정된 VPC 서비스 제어 경계의 이름
- 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- sourceProperties
  - properties
    - name: 수정된 VPC 서비스 제어 경계의 이름
    - policyLink: 경계를 제어하는 액세스 정책 링크
    - delta: 보호를 축소한 경계에 대한 REMOVE 또는 ADD의 변경사항
    - restricted_resources: 이 경계의 제한사항을 따르는 프로젝트. 프로젝트를 삭제하면 보호 기능이 축소됨.
    - restricted_services: 이 경계의 제한사항에 의해 실행이 금지되는 서비스. 제한된 서비스를 삭제하면 보호 기능이 축소됨.
    - allowed_services: 이 경계의 제한사항에 따라 실행할 수 있는 서비스. 허용된 서비스를 추가하면 보호 기능이 축소됨.
    - access_levels: 경계에 따라 리소스에 대한 액세스를 허용하도록 구성된 액세스 수준. 액세스 수준을 추가하면 보호 기능이 축소됨.

2단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
다음 필터를 사용하여 VPC 서비스 제어 변경사항과 관련된 관리자 활동 로그를 찾습니다.
- protoPayload.methodName:"AccessContextManager.UpdateServicePerimeter"
- protoPayload.methodName:"AccessContextManager.ReplaceServicePerimeters"

3단계: 공격 및 대응 방법 조사하기

방어 회피: 인증 프로세스 수정 유형의 발견 항목에 대한 MITRE ATT&CK 프레임워크 항목을 검토하세요.
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

4단계: 대응 구현하기

다음의 응답 계획이 이 발견 항목에 적합할 수 있지만 작업에도 영향을 줄 수 있습니다. 조사에서 수집한 정보를 신중하게 평가하여 발견 항목을 해결할 최선의 방법을 결정해야 합니다.

VPC 서비스 제어 정책 및 경계의 소유자에게 문의하세요.
조사가 완료될 때까지 경계에 대한 변경사항을 되돌리는 것이 좋습니다.
조사가 완료될 때까지 경계를 수정한 주 구성원에서 Access Context Manager 역할을 취소하는 것이 좋습니다.
축소된 보호 기능이 어떻게 사용되었는지 조사합니다. 예를 들어 'BigQuery Data Transfer Service API'가 사용 설정되어 있거나 허용된 서비스로 추가된 경우 해당 서비스를 사용하기 시작한 사람과 전송하는 항목을 확인합니다.

`Defense Evasion: Potential Kubernetes Pod Masquerading`

누군가 GKE가 일반 클러스터 운영을 위해 만드는 기본 워크로드와 유사한 이름 지정 규칙으로 포드를 배포했습니다. 이러한 기법을 가장이라고 합니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

포드가 정당한지 확인하세요.
Cloud Logging의 감사 로그에서 포드 또는 주 구성원의 다른 악의적인 활동 징후가 있는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)이 아닌 경우 계정 소유자에게 연락하여 정당한 소유자가 작업을 수행했는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)인 경우 작업 소스를 식별하여 정당성을 확인하세요.
포드가 정당하지 않은 경우 워크로드에서 사용하고 생성을 허용한 연결된 RBAC 바인딩 및 서비스 계정과 함께 이 포드를 삭제하세요.

`Discovery: Can get sensitive Kubernetes object check`

잠재적인 악의적 행위자가 kubectl auth can-i get 명령어를 사용하여 쿼리할 수 있는 GKE의 민감한 객체를 확인하려고 시도했습니다. 구체적으로 설명하자면, 행위자가 다음 명령어를 실행했습니다.

kubectl auth can-i get '*'
kubectl auth can-i get secrets
kubectl auth can-i get clusterroles/cluster-admin

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Discovery: Can get sensitive Kubernetes object check 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.
- 감지된 항목에서 다음을 확인합니다.
  - Kubernetes 액세스 검토: SelfSubjectAccessReview k8s 리소스를 기준으로 요청된 액세스 검토 정보입니다.
  - 주 구성원 이메일: 호출을 수행한 계정입니다.
- 영향을 받는 리소스에서 다음을 확인합니다.
  - 리소스 표시 이름: 작업이 수행된 Kubernetes 클러스터
- 관련 링크에서 다음을 확인합니다.
  - Cloud Logging URI: Logging 항목의 링크

2단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
로드되는 페이지에서 다음 필터를 사용하여 주 구성원이 수행한 다른 작업을 확인합니다.
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  다음을 바꿉니다.
- CLUSTER_NAME: 발견 항목 세부정보의 리소스 표시 이름 필드에서 확인한 값입니다.
- PRINCIPAL_EMAIL: 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값입니다.

3단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(탐색)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
쿼리된 객체의 민감도를 확인하고 로그에서 주 구성원에 의한 다른 악의적인 활동의 징후가 있는지 확인합니다.
발견 항목 세부정보의 주 구성원 이메일 행에서 확인한 계정이 서비스 계정이 아니면 계정 소유자에게 연락하여 적합한 소유자가 작업을 수행했는지 여부를 확인합니다.

주 구성원 이메일이 서비스 계정(IAM 또는 Kubernetes)인 경우 액세스 검토 소스를 확인하여 적법성을 결정합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Execution: Kubernetes Pod Created with Potential Reverse Shell Arguments`

누군가 일반적으로 리버스 셸과 연관된 명령어나 인수가 포함된 포드를 만들었습니다. 공격자는 리버스 셸을 사용하여 클러스터에 대한 초기 액세스를 확장 또는 유지하고 임의 명령어를 실행합니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

포드에 이러한 명령어와 인수를 지정할 정당한 이유가 있는지 확인하세요.
Cloud Logging의 감사 로그에서 포드 또는 주 구성원의 다른 악의적인 활동 징후가 있는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)이 아닌 경우 계정 소유자에게 연락하여 정당한 소유자가 작업을 수행했는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)인 경우 서비스 계정에서 이 작업을 수행하게 한 원인의 정당성을 확인하세요.
포드가 정당하지 않은 경우 워크로드에서 사용하고 생성을 허용한 연결된 RBAC 바인딩 및 서비스 계정과 함께 이 포드를 삭제하세요.

`Execution: Suspicious Exec or Attach to a System Pod`

누군가 exec 또는 attach 명령어를 사용하여 셸을 가져오거나 kube-system 네임스페이스에서 실행 중인 컨테이너에서 명령어를 실행했습니다. 이러한 메서드는 합법적인 디버깅 목적으로 사용되기도 합니다. 그러나 kube-system namespace는 Kubernetes에서 만든 시스템 객체용이며 예상치 못한 명령 실행이나 셸 생성은 검토해야 합니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

Cloud Logging의 감사 로그를 검토하여 주 구성원에 의한 예상된 활동인지 확인하세요.
로그에서 주 구성원에 의한 다른 악성 활동 징후가 있는지 확인합니다.

이 액세스를 허용한 RBAC 역할 및 클러스터 역할의 최소 권한의 원칙 사용에 대한 안내를 검토하세요.

`Exfiltration: BigQuery Data Exfiltration`

Exfiltration: BigQuery Data Exfiltration으로 반환된 발견 항목에는 두 가지 하위 규칙 중 하나가 포함됩니다. 각 하위 규칙의 심각도가 다릅니다.

심각도 = HIGH인 하위 규칙 exfil_to_external_table:
- 리소스가 조직 또는 프로젝트 외부에 저장되었습니다.
심각도 = LOW인 하위 규칙 vpc_perimeter_violation:
- VPC 서비스 제어가 복사 작업 또는 BigQuery 리소스 액세스 시도를 차단했습니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Exfiltration: BigQuery Data Exfiltration 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션에 나열된 값을 검토합니다.
- 감지된 항목:
  - 심각도: 심각도는 하위 규칙 exfil_to_external_table의 경우 HIGH, 하위 규칙 vpc_perimeter_violation의 경우 LOW입니다.
  - 주 구성원 이메일: 데이터를 유출하는 데 사용된 계정
  - 유출 소스: 데이터가 유출된 테이블에 대한 세부정보
  - 유출 대상: 유출된 데이터가 저장된 테이블에 대한 세부정보
- 영향을 받는 리소스:
  - 리소스 전체 이름: 데이터가 유출된 프로젝트, 폴더, 조직의 전체 리소스 이름
- 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
  - Chronicle: Google SecOps에 대한 링크입니다.
소스 속성 탭을 클릭하고 특히 다음과 같은 표시된 필드를 검토합니다.
- detectionCategory:
  - subRuleName: exfil_to_external_table 또는 vpc_perimeter_violation입니다.
- evidence:
  - sourceLogId:
    - projectId: 소스 BigQuery 데이터 세트가 포함된 Google Cloud 프로젝트
- properties
  - dataExfiltrationAttempt
    - jobLink: 데이터를 유출한 BigQuery 작업의 링크
    - query: BigQuery 데이터 세트에서 실행되는 SQL 쿼리
원하는 경우 발견 항목의 JSON 속성 전체 목록을 보려면 JSON 탭을 클릭합니다.

2단계: Google Security Operations에서 조사

Google Security Operations를 사용하여 이 발견 항목을 조사할 수 있습니다. Google SecOps는 통합 타임라인에서 위협을 조사하고 관련 항목을 피벗할 수 있게 해주는 Google Cloud 서비스입니다. Google SecOps는 발견 항목 데이터를 보강하여 사용자가 관심 지표를 식별하고 조사를 간소화할 수 있도록 합니다.

조직 수준에서 Security Command Center를 활성화하는 경우에만 Google SecOps를 사용할 수 있습니다.

Google Cloud 콘솔에서 Security Command Center 발견 항목 페이지로 이동합니다.

발견 항목으로 이동
빠른 필터 패널에서 소스 표시 이름으로 스크롤합니다.
소스 표시 이름 섹션에서 Event Threat Detection을 선택합니다.

테이블에 Event Threat Detection의 발견 항목이 채워집니다.
테이블의 카테고리에서 Exfiltration: BigQuery Data Exfiltration 발견 항목을 클릭합니다. 발견 항목의 세부정보 패널이 열립니다.
발견 항목 세부정보 패널의 관련 링크 섹션에서 Chronicle에서 조사를 클릭합니다.
Google SecOps의 가이드가 포함된 사용자 인터페이스의 안내를 따릅니다.

Google SecOps에서 조사를 수행하려면 다음 가이드를 사용하세요.

3단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 발견 항목 JSON의 projectId 필드에 나열된 프로젝트를 선택합니다.
표시되는 페이지의 필터 상자에서 주 구성원 이메일에 나열된 이메일 주소를 입력하고 계정에 할당되는 권한을 확인합니다.

4단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
다음 필터를 사용하여 BigQuery 작업과 관련된 관리자 활동 로그를 찾습니다.
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

5단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목 검토: 웹 서비스를 통한 유출: Cloud Storage로 유출
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 인스턴스 및 네트워크의 동일한 발견 유형입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

6단계: 대응 구현하기

유출된 데이터가 있는 프로젝트의 소유자에게 문의하세요.
조사가 완료될 때까지 userEmail에 대한 권한을 취소하는 것이 좋습니다.
추가 유출을 방지하려면 영향을 받는 BigQuery 데이터 세트(exfiltration.sources 및 exfiltration.targets)에 제한된 IAM 정책을 추가하세요.
영향을 받는 데이터 세트에서 민감한 정보를 스캔하려면 Sensitive Data Protection를 사용합니다. 또한 Sensitive Data Protection 데이터를 Security Command Center로 전송할 수도 있습니다. 정보의 양에 따라 Sensitive Data Protection 비용이 크게 증가할 수 있습니다. Sensitive Data Protection 비용 적절하게 유지하기 권장사항을 따릅니다.
BigQuery API에 대한 액세스를 제한하려면 VPC 서비스 제어를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Exfiltration: BigQuery Data Extraction`

다음 두 가지 시나리오에서 감사 로그를 검사하여 BigQuery의 데이터 유출을 감지합니다.

리소스가 조직 외부의 Cloud Storage 버킷에 저장됩니다.
리소스는 조직에서 소유한 공개적으로 액세스 가능한 Cloud Storage 버킷에 저장됩니다.

Security Command Center 프리미엄 등급의 프로젝트 수준 활성화의 경우 표준 등급이 상위 조직에서 사용 설정된 경우에만 이 발견 항목을 사용할 수 있습니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Exfiltration: BigQuery Data Extraction 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션에 나열된 값을 검토합니다.
- 감지된 항목:
  - 주 구성원 이메일: 데이터를 유출하는 데 사용된 계정
  - 유출 소스: 데이터가 유출된 테이블에 대한 세부정보
  - 유출 대상: 유출된 데이터가 저장된 테이블에 대한 세부정보
- 영향을 받는 리소스:
  - 리소스 전체 이름: 데이터가 유출된 BigQuery 리소스의 이름
  - 프로젝트 전체 이름: 소스 BigQuery 데이터 세트가 포함된 Google Cloud 프로젝트
- 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
발견 항목 세부정보 패널에서 JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- sourceProperties:
  - evidence:
    - sourceLogId:
    - projectId: 소스 BigQuery 데이터 세트가 포함된 Google Cloud 프로젝트
  - properties:
    - extractionAttempt:
    - jobLink: 데이터를 유출한 BigQuery 작업의 링크

2단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 발견 항목 JSON의 projectId 필드에 나열된 프로젝트를 선택합니다(1단계).
표시되는 페이지의 필터 상자에 주 구성원 이메일에 나열된 이메일 주소를 입력하고(1단계) 계정에 할당된 권한을 확인합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
다음 필터를 사용하여 BigQuery 작업과 관련된 관리자 활동 로그를 찾습니다.
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목 검토: 웹 서비스를 통한 유출: Cloud Storage로 유출
발견 항목 세부정보의 요약 탭에서 관련 발견 항목 행을 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 인스턴스 및 네트워크의 동일한 발견 유형입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

유출된 데이터가 있는 프로젝트의 소유자에게 문의하세요.
조사가 완료될 때까지 발견 항목 세부정보의 요약 탭에서 주 구성원 이메일 행에 나열된 주 구성원에 대해 권한을 취소하는 것이 좋습니다.
추가 유출을 방지하려면 발견 항목 세부정보의 요약 탭에서 유출 소스 필드에 식별된 영향을 받는 BigQuery 데이터 세트에 제한된 IAM 정책을 추가합니다.
영향을 받는 데이터 세트에서 민감한 정보를 스캔하려면 Sensitive Data Protection를 사용합니다. 또한 Sensitive Data Protection 데이터를 Security Command Center로 전송할 수도 있습니다. 정보의 양에 따라 Sensitive Data Protection 비용이 크게 증가할 수 있습니다. Sensitive Data Protection 비용 적절하게 유지하기 권장사항을 따릅니다.
BigQuery API에 대한 액세스를 제한하려면 VPC 서비스 제어를 사용하세요.
버킷 소유자인 경우 공개 액세스 권한을 취소하는 것이 좋습니다.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Exfiltration: BigQuery Data to Google Drive`

다음 시나리오에 대해 감사 로그를 검사하여 BigQuery에서 데이터 유출을 감지합니다.

리소스는 Google 드라이브 폴더에 저장됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Exfiltration: BigQuery Data to Google Drive 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션의 정보를 검토합니다.
- 다음을 포함하는 발견된 항목:
  - 주 구성원 이메일: 데이터를 유출하는 데 사용된 계정
  - 유출 소스: 데이터가 유출된 BigQuery 테이블에 대한 세부정보
  - 유출 대상: Google Drive의 대상에 대한 세부정보
- 다음을 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 데이터가 유출된 BigQuery 리소스의 이름
  - 프로젝트 전체 이름: 소스 BigQuery 데이터 세트가 포함된 Google Cloud 프로젝트
- 다음을 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
자세한 내용을 보려면 JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- sourceProperties:
  - evidence:
    - sourceLogId:
    - projectId: 소스 BigQuery 데이터 세트가 포함된 Google Cloud 프로젝트
  - properties:
    - extractionAttempt:
    - jobLink: 데이터를 유출한 BigQuery 작업의 링크

2단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 발견 항목 JSON의 projectId 필드에 나열된 프로젝트를 선택합니다(1단계).
표시되는 페이지의 필터 상자에 1단계의 access.principalEmail에 나열된 이메일 주소를 입력하고 계정에 할당된 권한을 확인합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
다음 필터를 사용하여 BigQuery 작업과 관련된 관리자 활동 로그를 찾습니다.
- protoPayload.methodName="Jobservice.insert"
- protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목 검토: 웹 서비스를 통한 유출: Cloud Storage로 유출
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 인스턴스 및 네트워크의 동일한 발견 유형입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

유출된 데이터가 있는 프로젝트의 소유자에게 문의하세요.
조사가 완료될 때까지 access.principalEmail 필드에서 주 구성원에 대해 권한을 취소하는 것이 좋습니다.
추가 유출을 방지하려면 영향을 받는 BigQuery 데이터 세트(exfiltration.sources)에 제한된 IAM 정책을 추가하세요.
영향을 받는 데이터 세트에서 민감한 정보를 스캔하려면 Sensitive Data Protection를 사용합니다. 또한 Sensitive Data Protection 데이터를 Security Command Center로 전송할 수도 있습니다. 정보의 양에 따라 Sensitive Data Protection 비용이 크게 증가할 수 있습니다. Sensitive Data Protection 비용 적절하게 유지하기 권장사항을 따릅니다.
BigQuery API에 대한 액세스를 제한하려면 VPC 서비스 제어를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Exfiltration: Cloud SQL Data Exfiltration`

다음 두 가지 시나리오에서 감사 로그를 검사하여 Cloud SQL의 데이터 무단 반출을 감지합니다.

조직 외부의 Cloud Storage 버킷으로 내보내는 실시간 인스턴스 데이터
조직에서 소유하고 공개적으로 액세스할 수 있는 Cloud Storage 버킷으로 내보내는 실시간 인스턴스 데이터

모든 Cloud SQL 인스턴스 유형이 지원됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Exfiltration: Cloud SQL Data Exfiltration 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 데이터를 유출하는 데 사용된 계정
  - 유출 소스: 데이터가 유출된 Cloud SQL 인스턴스에 대한 세부정보
  - 유출 대상: 데이터를 내보낸 Cloud Storage 버킷에 대한 세부정보
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 데이터가 유출된 Cloud SQL의 리소스 이름
  - 프로젝트 전체 이름: 소스 Cloud SQL 데이터가 포함된 Google Cloud 프로젝트
- 다음을 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
JSON 탭을 클릭합니다.
발견 항목의 JSON에서 다음 필드를 확인합니다.
- sourceProperties:
  - evidence:
  - sourceLogId:
    - projectId: 소스 Cloud SQL 인스턴스가 포함된 Google Cloud 프로젝트
  - properties
  - bucketAccess: Cloud Storage 버킷에 공개적으로 액세스할 수 있는지 또는 조직 외부에 있는지 여부
  - exportScope: 내보낸 데이터 양(예: 전체 인스턴스, 데이터베이스 한 개 이상, 테이블 한 개 이상, 쿼리에서 지정한 하위 집합)

2단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 발견 항목 JSON의 projectId 필드에 나열된 인스턴스의 프로젝트를 선택합니다(1단계).
표시되는 페이지의 필터 상자에서 발견 항목 세부정보의 요약 탭에서 주 구성원 이메일 행에 나열된 이메일 주소를 입력합니다(1단계). 계정에 할당된 권한을 확인합니다.

3단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기로 이동합니다(1단계). 로그 탐색기 페이지에는 관련 Cloud SQL 인스턴스와 관련된 모든 로그가 포함되어 있습니다.

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목 검토: 웹 서비스를 통한 유출: Cloud Storage로 유출
1단계에서 설명된 관련 발견 항목 행의 링크를 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목에는 동일한 Cloud SQL 인스턴스에서 같은 발견 항목 유형이 있습니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

유출된 데이터가 있는 프로젝트의 소유자에게 문의하세요.
조사가 완료될 때까지 access.principalEmail에 대한 권한을 취소하는 것이 좋습니다.
추가 유출을 방지하려면 영향을 받는 Cloud SQL 인스턴스에 제한된 IAM 정책을 추가하세요.
Cloud SQL Admin API에 액세스와 내보내기를 제한하려면 VPC 서비스 제어를 사용합니다.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Exfiltration: Cloud SQL Restore Backup to External Organization`

Cloud SQL 백업의 데이터 무단 반출은 감사 로그를 검사하여 백업의 데이터가 조직 또는 프로젝트 외부의 Cloud SQL 인스턴스로 복원되었는지 확인함으로써 감지됩니다. 모든 Cloud SQL 인스턴스 및 백업 유형이 지원됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Exfiltration: Cloud SQL Restore Backup to External Organization 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 데이터를 유출하는 데 사용된 계정
  - 유출 소스: 백업이 생성된 Cloud SQL 인스턴스에 대한 세부정보
  - 유출 대상: 백업 데이터가 복원된 Cloud SQL 인스턴스에 대한 세부정보
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 복원된 백업의 리소스 이름
  - 프로젝트 전체 이름: 백업이 생성된 Cloud SQL 인스턴스를 포함하는 Google Cloud 프로젝트
특히 다음 필드를 포함하는 관련 링크:
- Cloud Logging URI: Logging 항목의 링크
- MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
- 관련 발견 항목: 모든 관련 발견 항목의 링크
JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- resource:
  - parent_name: 백업이 생성된 Cloud SQL 인스턴스의 리소스 이름
- evidence:
  - sourceLogId:
    - projectId: 소스 BigQuery 데이터 세트가 포함된 Google Cloud 프로젝트
- properties:
  - restoreToExternalInstance:
    - backupId: 복원된 백업 실행의 ID

2단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 발견 항목 JSON의 projectId 필드에 나열된 인스턴스의 프로젝트를 선택합니다(1단계).
표시되는 페이지의 필터 상자에서 주 구성원 이메일에 나열된 이메일 주소를 입력하고(1단계) 계정에 할당된 권한을 확인합니다.

3단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기로 이동합니다(1단계). 로그 탐색기 페이지에는 관련 Cloud SQL 인스턴스와 관련된 모든 로그가 포함되어 있습니다.

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목 검토: 웹 서비스를 통한 유출: Cloud Storage로 유출
관련 발견 항목 행의 링크를 클릭하여 관련 발견 항목을 검토합니다. (1단계) 관련 발견 항목에는 동일한 Cloud SQL 인스턴스에서 같은 발견 항목 유형이 있습니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

유출된 데이터가 있는 프로젝트의 소유자에게 문의하세요.
조사가 완료될 때까지 발견 항목 세부정보의 요약 탭에서 주 구성원 이메일 행에 나열된 주 구성원에 대해 권한을 취소하는 것이 좋습니다.
추가 유출을 방지하려면 영향을 받는 Cloud SQL 인스턴스에 제한된 IAM 정책을 추가하세요.
Cloud SQL Admin API에 대한 액세스를 제한하려면 VPC 서비스 제어를 사용합니다.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Exfiltration: Cloud SQL Over-Privileged Grant`

PostgreSQL 데이터베이스(또는 데이터베이스의 모든 함수 또는 프로시저)에 대한 모든 권한이 한 명 이상의 데이터베이스 사용자에게 부여된 경우를 감지합니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Exfiltration: Cloud SQL Over-Privileged Grant 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 데이터베이스 표시 이름: 영향을 받은 Cloud SQL PostgreSQL 인스턴스의 데이터베이스 이름
  - 데이터베이스 사용자 이름: 초과 권한을 부여한 PostgreSQL 사용자
  - 데이터베이스 쿼리: 권한을 부여한 실행된 PostgreSQL 쿼리
  - 데이터베이스 피부여자: 과도한 권한 피부여자
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받은 Cloud SQL PostgreSQL 인스턴스의 리소스 이름
  - 상위 전체 이름: Cloud SQL PostgreSQL 인스턴스의 리소스 이름
  - 프로젝트 전체 이름: Cloud SQL PostgreSQL 인스턴스를 포함하는 Google Cloud 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 데이터베이스 권한 검토

PostgreSQL 데이터베이스에 연결합니다.
다음에 대한 액세스 권한을 나열하고 표시합니다.
- 데이터베이스. \l 또는 \list 메타 명령어를 사용하여 데이터베이스 표시 이름에 나열된 데이터베이스에 할당된 권한을 확인합니다(1단계).
- 함수 또는 프로시져. \df 메타 명령어를 사용하고 데이터베이스 표시 이름에 나열된 데이터베이스에서 함수 또는 프로시져에 할당된 권한을 확인합니다(1단계).

3단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기로 이동합니다(1단계). 로그 탐색기 페이지에는 관련 Cloud SQL 인스턴스와 관련된 모든 로그가 포함되어 있습니다.
로그 탐색기에서 다음 필터를 사용하여 데이터베이스에 실행된 쿼리를 기록하는 PostgreSQL pgaudit 로그를 확인합니다.
- protoPayload.request.database="var class="edit">database"

4단계: 공격 및 대응 방법 조사하기

웹 서비스를 통한 유출 유형의 발견 항목에 대한 MITRE ATT&CK 프레임워크 항목을 검토하세요.
추가 해결 단계가 필요한지 확인하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

과도하게 부여된 권한 부여는 인스턴스 소유자에게 문의하세요.
조사가 완료될 때까지 데이터베이스 피부여자에 나열된 피부여자에 대해 모든 권한을 취소하는 것이 좋습니다.
데이터베이스 액세스를 제한하려면(1단계의 데이터베이스 표시 이름) 피부여자에게서 불필요한 권한을 취소합니다(1단계의 데이터베이스 피부여자).

`Initial Access: Database Superuser Writes to User Tables`

Cloud SQL 데이터베이스 수퍼유저 계정(PostgreSQL용 postgres 및 MySQL용 root)이 사용자 테이블에 쓰는 경우를 감지합니다. 수퍼유저(매우 광범위한 액세스 권한이 있는 역할)는 일반적으로 사용자 테이블에 쓰는 데 사용해서는 안 됩니다. 일반적인 일상 활동에는 액세스가 제한된 사용자 계정을 사용해야 합니다. 수퍼유저가 사용자 테이블에 작성하면 공격자가 권한을 에스컬레이션했거나 기본 데이터베이스 사용자의 보안을 침해하여 데이터를 수정하고 있음을 의미할 수 있습니다. 또한 정상일지라도 안전하지 않은 관행입니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Initial Access: Database Superuser Writes to User Tables 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 데이터베이스 표시 이름: 영향을 받은 Cloud SQL PostgreSQL 또는 MySQL 인스턴스의 데이터베이스 이름
  - 데이터베이스 사용자 이름: 수퍼유저
  - 데이터베이스 쿼리: 사용자 테이블에 쓰는 동안 실행된 SQL 쿼리
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받은 Cloud SQL 인스턴스의 리소스 이름
  - 상위 전체 이름: Cloud SQL 인스턴스의 리소스 이름
  - 프로젝트 전체 이름: Cloud SQL 인스턴스를 포함하는 Google Cloud 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 로그 확인하기

Google Cloud 콘솔에서 cloudLoggingQueryURI의 링크(1단계)를 클릭하여 로그 탐색기로 이동합니다. 로그 탐색기 페이지에는 관련 Cloud SQL 인스턴스와 관련된 모든 로그가 포함되어 있습니다.
다음 필터를 사용하여 수퍼유저가 실행한 쿼리가 포함된 PostgreSQL pgaudit 로그 또는 MySQL용 Cloud SQL 감사 로그를 확인합니다.
- protoPayload.request.user="SUPERUSER"

3단계: 공격 및 대응 방법 조사하기

웹 서비스를 통한 유출 유형의 발견 항목에 대한 MITRE ATT&CK 프레임워크 항목을 검토하세요.
추가 해결 단계가 필요한지 확인하려면 조사 결과를 MITRE 연구와 결합합니다.

4단계: 대응 구현하기

데이터베이스 연결이 허용된 사용자를 검토합니다.
- PostgreSQL의 경우 사용자 만들기 및 관리를 참조하세요.
- MySQL의 경우 기본 제공 인증으로 사용자 관리를 참조하세요.
수퍼유저의 비밀번호를 변경하는 것이 좋습니다.
- PostgreSQL의 경우 기본 사용자의 비밀번호 설정을 참조하세요.
- MySQL의 경우 기본 사용자의 비밀번호 설정을 참조하세요.
인스턴스에서 사용되는 다양한 유형의 쿼리에 대해 액세스가 제한된 사용자를 새로 만드는 것이 좋습니다.
- 새 사용자에게 쿼리를 실행하는 데 필요한 권한만 부여합니다.
  - PostgreSQL의 경우 권한 부여(명령어)를 참조하세요.
  - MySQL의 경우 액세스 제어 및 계정 관리를 참조하세요.
- Cloud SQL 인스턴스에 연결하는 클라이언트의 사용자 인증 정보 업데이트

`Initial Access: Anonymous GKE resource created from the internet`

잠재적인 악의적 행위자가 다음 Kubernetes 기본 사용자 또는 사용자 그룹 중 하나를 사용하여 클러스터에 새 Kubernetes 리소스를 만든 경우를 감지합니다.

system:anonymous
system:authenticated
system:unauthenticated

이러한 사용자 및 그룹은 사실상 익명입니다. 클러스터의 역할 기반 액세스 제어(RBAC) 바인딩은 클러스터에서 리소스를 만들 수 있는 사용자 권한을 부여했습니다.

생성된 리소스와 연결된 RBAC 바인딩을 검토하여 바인딩이 필요한지 확인합니다. 바인딩이 필요하지 않으면 삭제합니다. 자세한 내용은 이 발견 항목의 로그 메시지를 참조하세요.

이 문제를 완화하려면 기본 역할 및 그룹 사용 안 함을 참조하세요.

`Initial Access: GKE resource modified anonymously from the internet`

잠재적인 악의적 행위자가 다음 Kubernetes 기본 사용자 또는 사용자 그룹 중 하나를 사용하여 클러스터의 Kubernetes 리소스를 수정한 경우를 감지합니다.

system:anonymous
system:authenticated
system:unauthenticated

이러한 사용자 및 그룹은 사실상 익명입니다. 클러스터의 역할 기반 액세스 제어(RBAC) 바인딩은 클러스터의 리소스를 수정할 수 있는 사용자 권한을 부여했습니다.

수정된 리소스와 연결된 RBAC 바인딩을 검토하여 바인딩이 필요한지 확인합니다. 바인딩이 필요하지 않으면 삭제합니다. 자세한 내용은 이 발견 항목의 로그 메시지를 참조하세요.

이 문제를 완화하려면 기본 역할 및 그룹 사용 안 함을 참조하세요.

`Initial Access: Dormant Service Account Action`

휴면 사용자 관리 서비스 계정이 작업을 트리거한 이벤트를 감지합니다. 이 경우 서비스 계정은 180일 이상 비활성 상태인 경우 휴면으로 간주됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Initial Access: Dormant Service Account Action 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 주 구성원 이메일: 작업을 수행한 휴면 서비스 계정
- 서비스 이름: 서비스 계정으로 액세스한 Google Cloud 서비스의 API 이름
- 메서드 이름: 호출된 메서드입니다.

2단계: 공격 및 대응 방법 조사하기

활동 분석기와 같은 서비스 계정 도구를 사용하여 휴면 서비스 계정의 활동을 조사합니다.
주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 애플리케이션에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 애플리케이션을 식별하고 애플리케이션 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원팀의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Initial Access: Dormant Service Account Key Created`

휴면 사용자 관리형 서비스 계정 키가 생성된 이벤트를 감지합니다. 이 경우 서비스 계정은 180일 이상 비활성 상태인 경우 휴면으로 간주됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Initial Access: Dormant Service Account Key Created 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 기본 이메일: 서비스 계정 키를 만든 사용자
영향을 받는 리소스에서 다음을 확인하세요.
- 리소스 표시 이름: 새로 생성된 휴면 서비스 계정 키
- 프로젝트 전체 이름: 휴면 서비스 계정이 있는 프로젝트

2단계: 공격 및 대응 방법 조사하기

활동 분석기와 같은 서비스 계정 도구를 사용하여 휴면 서비스 계정의 활동을 조사합니다.
주 구성원 이메일 필드의 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
주 구성원 이메일의 보안이 침해된 경우 소유자의 액세스 권한을 삭제합니다.
서비스 계정 페이지에서 새로 만든 서비스 계정 키를 무효화합니다.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 애플리케이션에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 애플리케이션을 식별하고 애플리케이션 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Cloud Customer Care의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Initial Access: Leaked Service Account Key Used`

유출된 서비스 계정 키를 사용해 작업을 인증하는 이벤트를 감지합니다. 이때 유출된 서비스 계정 키는 공개 인터넷에 게시되었던 키입니다. 예를 들어 서비스 계정 키가 공개 GitHub 저장소에 실수로 게시되는 경우가 많습니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Initial Access: Leaked Service Account Key Used 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 기본 이메일: 이 작업에 사용되는 서비스 계정
- 서비스 이름: 서비스 계정으로 액세스한 Google Cloud 서비스의 API 이름
- 메서드 이름: 작업의 메서드 이름
- 서비스 계정 키 이름: 이 작업을 인증하는 데 사용되는 유출된 서비스 계정 키
- 설명: 서비스 계정 키를 찾을 수 있는 공개 인터넷 상의 위치를 포함하여 감지된 항목에 대한 설명
영향을 받는 리소스에서 다음을 확인하세요.
- 리소스 표시 이름: 작업과 관련된 리소스

2단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기로 이동합니다.
Google Cloud 콘솔 툴바에서 프로젝트 또는 조직을 선택합니다.
로드된 페이지에서 다음 필터를 사용하여 관련 로그를 찾습니다.
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
- protoPayload.authenticationInfo.serviceAccountKeyName="SERVICE_ACCOUNT_KEY_NAME"
PRINCIPAL_EMAIL을 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값으로 바꿉니다. SERVICE_ACCOUNT_KEY_NAME을 발견 항목 세부정보의 서비스 계정 키 이름 필드에 기록해 둔 값으로 바꿉니다.

3단계: 대응 구현하기

서비스 계정 페이지에서 서비스 계정 키를 즉시 취소합니다.
서비스 계정 키가 게시된 웹페이지 또는 GitHub 저장소를 중단합니다.
침해된 서비스 계정은 삭제하는 것이 좋습니다.
침해 가능성이 있는 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제합니다. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 애플리케이션에서 액세스 권한을 잃게 됩니다. 삭제하기 전에 보안팀은 영향을 받는 모든 애플리케이션을 식별하고 애플리케이션 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Cloud Customer Care의 알림에 응답합니다.

`Initial Access: Excessive Permission Denied Actions`

주 구성원이 여러 메서드 및 서비스에서 권한 거부 오류를 반복적으로 트리거하는 이벤트를 감지합니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Initial Access: Excessive Permission Denied Actions 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 주 구성원 이메일: 여러 권한 거부 오류를 트리거한 주 구성원입니다.
- 서비스 이름: 마지막 권한 거부 오류가 발생한 Google Cloud 서비스의 API 이름
- 메서드 이름: 마지막 권한 거부 오류가 발생할 때 호출되는 메서드
발견 항목 세부정보의 소스 속성 탭에서 JSON의 다음 필드 값을 확인합니다.
- properties.failedActions: 권한 거부 오류가 발생했습니다. 각 항목의 세부정보에는 서비스 이름, 메서드 이름, 실패한 시도 횟수, 오류가 마지막으로 발생한 시간이 포함됩니다. 최대 10개의 항목이 표시됩니다.

2단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기로 이동합니다.
Google Cloud 콘솔 툴바에서 프로젝트를 선택합니다.
로드된 페이지에서 다음 필터를 사용하여 관련 로그를 찾습니다.
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
- protoPayload.status.code=7
PRINCIPAL_EMAIL을 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값으로 바꿉니다.

3단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정: 클라우드 계정
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

4단계: 대응 구현하기

주 구성원 이메일 필드의 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
생소한 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자 등 해당 계정이 만든 프로젝트 리소스를 삭제합니다.
해당 계정이 있는 프로젝트 소유자에게 연락하여 계정을 삭제하거나 사용 중지하세요.

`Brute Force: SSH`

호스트에서 SSH의 성공적인 무작위 공격을 감지합니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Brute Force: SSH 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 호출자 IP: 공격을 시작한 IP 주소
  - 사용자 이름: 로그인한 계정
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
  - Chronicle: Google SecOps에 대한 링크입니다.
JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- sourceProperties:
  - evidence:
    - sourceLogId: 로그 항목을 식별하는 프로젝트 ID 및 타임스탬프
    - projectId: 발견 항목을 포함하는 프로젝트
  - properties:
    - attempts:
    - Attempts: 로그인 시도 횟수
      - username: 로그인한 계정
      - vmName: 가상 머신 인스턴스의 이름
      - authResult: SSH 인증 결과

2단계: Google Security Operations에서 조사

Google Security Operations를 사용하여 이 발견 항목을 조사할 수 있습니다. Google SecOps는 사용하기 쉬운 타임라인에서 위협을 조사하고 관련 항목을 피벗할 수 있게 해주는 Google Cloud 서비스입니다. Google SecOps는 발견 항목 데이터를 보강하여 사용자가 관심 지표를 식별하고 조사를 간소화할 수 있도록 합니다.

조직 수준에서 Security Command Center를 활성화하는 경우에만 Google SecOps를 사용할 수 있습니다.

Google Cloud 콘솔에서 Security Command Center 발견 항목 페이지로 이동합니다.

발견 항목으로 이동
빠른 필터 패널에서 소스 표시 이름으로 스크롤합니다.
소스 표시 이름 섹션에서 Event Threat Detection을 선택합니다.

테이블에 선택한 소스 유형의 발견 항목이 채워집니다.
테이블의 카테고리에서 Brute Force: SSH 발견 항목을 클릭합니다. 발견 항목의 세부정보 패널이 열립니다.
발견 항목 세부정보 패널의 관련 링크 섹션에서 Chronicle에서 조사를 클릭합니다.
Google SecOps의 가이드가 포함된 사용자 인터페이스의 안내를 따릅니다.

Google SecOps에서 조사를 수행하려면 다음 가이드를 사용하세요.

3단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 대시보드로 이동합니다.

대시보드로 이동
projectId에 지정된 프로젝트를 선택합니다.
리소스 카드로 이동하여 Compute Engine을 클릭합니다.
vmName의 이름 및 영역과 일치하는 VM 인스턴스를 클릭합니다. 네트워크 및 액세스 설정을 포함한 인스턴스 세부정보를 검토합니다.
탐색 창에서 VPC 네트워크를 클릭한 다음 방화벽을 클릭합니다. 포트 22에서 과도한 권한이 부여된 방화벽 규칙을 삭제하거나 사용 중지합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기로 이동합니다.
로드되는 페이지에서 다음 필터를 사용하여 발견 항목 세부정보의 요약 탭에서 주 구성원 이메일 행에 나열된 IP 주소와 관련된 VPC 흐름 로그를 찾습니다.
- logName="projects/projectId/logs/syslog"
- labels."compute.googleapis.com/resource_name"="vmName"

5단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정: 로컬 계정.
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 발견 유형과 동일한 인스턴스 및 네트워크입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

6단계: 대응 구현하기

무작위 공격 시도가 성공한 프로젝트 소유자에게 문의하세요.
도용 가능성이 있는 인스턴스를 조사하고 발견된 멀웨어를 삭제합니다. 감지 및 삭제를 지원하려면 엔드포인트 감지 및 응답 솔루션을 이용하세요.
VM에 대한 SSH 액세스를 사용 중지합니다. SSH 키 사용 중지에 대한 자세한 내용은 VM에서 SSH 키 제한을 참조하세요. 이 단계로 VM에 대해 승인된 액세스가 중단될 수 있으므로 계속하기 전에 조직의 요구사항을 고려해야 합니다.
승인된 키에만 SSH 인증을 사용하세요.
방화벽 규칙을 업데이트하거나 Google Cloud Armor를 사용하여 악성 IP 주소를 차단합니다. Security Command Center 통합 서비스 페이지에서 Google Cloud Armor를 사용 설정할 수 있습니다. 정보 양에 따라 Google Cloud Armor 비용이 크게 증가할 수 있습니다. 자세한 내용은 Google Cloud Armor 가격 책정 가이드를 참조하세요.

`Credential Access: External Member Added To Privileged Group`

프로젝트 수준의 활성화에는 이 발견 항목을 사용할 수 없습니다.

외부 구성원이 권한 있는 Google 그룹(중요한 역할 또는 권한이 부여된 그룹)에 추가될 때 이를 감지합니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Credential Access: External Member Added To Privileged Group 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 변경을 수행한 계정입니다.
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
세부정보 패널에서 JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- groupName: 변경사항이 적용된 Google 그룹
- externalMember: 새로 추가된 외부 구성원
- sensitiveRoles: 이 그룹과 관련된 중요한 역할

2단계: 그룹 구성원 검토

Google 그룹스로 이동합니다.

Google 그룹스로 이동
검토할 그룹의 이름을 클릭합니다.
탐색 메뉴에서 구성원을 클릭합니다.
새로 추가된 외부 구성원이 이 그룹에 속하지 않아야 하는 경우 구성원 이름 옆의 체크박스를 클릭한 다음 구성원 삭제 또는 회원 차단을 선택합니다.

구성원을 제거하거나 추가하려면 Google Workspace 관리자이거나 Google 그룹의 소유자나 관리자 역할이 할당된 사용자여야 합니다. 자세한 내용은 그룹 구성원에게 역할 할당을 참조하세요.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
필요한 경우 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 Google 그룹 멤버십 변경사항 로그를 확인합니다.
- protoPayload.methodName="google.apps.cloudidentity.groups.v1.MembershipsService.UpdateMembership"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정.
추가 해결 단계가 필요한지 확인하려면 조사 결과를 MITRE 연구와 결합합니다.

`Credential Access: Failed Attempt to Approve Kubernetes Certificate Signing Request (CSR)`

누군가 인증서 서명 요청(CSR)을 수동으로 승인하려고 했지만 실패했습니다. 클러스터 인증을 위한 인증서를 만드는 것은 공격자가 손상된 클러스터에 영구적으로 액세스하기 위해 흔히 사용하는 방법입니다. 인증서에 연결된 권한은 포함된 주체에 따라 다르지만 권한이 높을 수 있습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

Cloud Logging의 감사 로그와 기타 CSR 관련 이벤트에 대한 추가 알림을 검토하여 CSR이 approved 및 발급되었는지, CSR 관련 작업이 주 구성원에 의한 예상된 활동인지 확인하세요.
Cloud Logging의 감사 로그에서 주 구성원에 의한 다른 악의적인 활동 징후가 있는지 확인하세요. 예를 들면 다음과 같습니다.
- CSR을 승인하려고 시도한 주 구성원이 CSR을 생성한 주 구성원과 다른가요?
- 주 구성원이 다른 CSR을 요청, 생성, 승인 또는 삭제하려고 시도했나요?
CSR 승인이 예상되지 않았거나 악의적인 것으로 확인되면 인증서를 무효화하기 위해 클러스터에 사용자 인증 정보 순환이 필요합니다. 클러스터 사용자 인증 정보 순환을 수행하는 방법에 대한 안내를 검토하세요.

`Credential Access: Manually Approved Kubernetes Certificate Signing Request (CSR)`

누군가 인증서 서명 요청(CSR)을 수동으로 승인했습니다. 클러스터 인증을 위한 인증서를 만드는 것은 공격자가 손상된 클러스터에 영구적으로 액세스하기 위해 흔히 사용하는 방법입니다. 인증서에 연결된 권한은 포함된 주체에 따라 다르지만 권한이 높을 수 있습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

Cloud Logging의 감사 로그와 기타 CSR 관련 이벤트에 대한 추가 알림을 검토하여 CSR 관련 작업이 주 구성원에 의한 예상된 활동인지 확인하세요.
Cloud Logging의 감사 로그에서 주 구성원에 의한 다른 악의적인 활동 징후가 있는지 확인하세요. 예를 들면 다음과 같습니다.
- CSR을 승인한 주 구성원이 CSR을 생성한 주 구성원과 다른가요?
- CSR에서 기본 제공 서명자를 지정했으나 서명자의 기준을 충족하지 않아 궁극적으로 수동 승인이 필요한가요?
- 주 구성원이 다른 CSR을 요청, 생성, 승인 또는 삭제하려고 시도했나요?
CSR 승인이 예상되지 않았거나 악의적인 것으로 확인되면 인증서를 무효화하기 위해 클러스터에 사용자 인증 정보 순환이 필요합니다. 클러스터 사용자 인증 정보 순환을 수행하는 방법에 대한 안내를 검토하세요.

`Credential Access: Privileged Group Opened To Public`

프로젝트 수준의 활성화에는 이 발견 항목을 사용할 수 없습니다.

권한 있는 Google 그룹(중요한 역할 또는 권한이 부여된 그룹)이 일반 대중에 액세스 가능하도록 변경되었을 때 이를 감지합니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Credential Access: Privileged Group Opened To Public 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 변경을 수행한 계정(도용된 계정일 수 있음)
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
1. JSON 탭을 클릭합니다.
2. JSON에서 다음 필드를 확인합니다.
- groupName: 변경사항이 적용된 Google 그룹
- sensitiveRoles: 이 그룹과 관련된 중요한 역할
- whoCanJoin: 그룹의 조인 가능성 설정

2단계: 그룹 액세스 설정 검토

Google 그룹스의 관리 콘솔로 이동합니다. 콘솔에 로그인하려면 Google Workspace 관리자여야 합니다.

관리 콘솔로 이동
탐색창에서 디렉터리를 클릭한 후 그룹스를 선택합니다.
검토할 그룹의 이름을 클릭합니다.
액세스 설정을 클릭한 다음 그룹에 가입할 수 있는 사용자에서 그룹의 조인 가능성 설정을 검토합니다.
필요한 경우 드롭다운 메뉴에서 조인 가능성 설정을 변경합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
필요한 경우 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 Google 그룹 설정 변경사항 로그를 확인합니다.
- protoPayload.methodName="google.admin.AdminService.changeGroupSetting"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정.
추가 해결 단계가 필요한지 확인하려면 조사 결과를 MITRE 연구와 결합합니다.

`Credential Access: Secrets Accessed in Kubernetes Namespace`

포드의 default Kubernetes 서비스 계정이 클러스터의 보안 비밀 객체에 액세스하는 데 사용된 시기를 감지합니다. Role 객체 또는 ClusterRole 객체를 사용하여 액세스 권한을 명시적으로 부여해야 default Kubernetes 서비스 계정이 Secret 객체에 액세스할 수 있습니다.

`Credential Access: Sensitive Role Granted To Hybrid Group`

외부 구성원이 있는 Google 그룹에 중요한 역할 또는 권한이 부여될 때 이를 감지합니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Credential Access: Sensitive Role Granted To Hybrid Group 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 변경을 수행한 계정(도용된 계정일 수 있음)
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 새 역할이 부여된 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
1. JSON 탭을 클릭합니다.
2. JSON에서 다음 필드를 확인합니다.
- groupName: 변경사항이 적용된 Google 그룹
- bindingDeltas: 이 그룹에 새로 부여된 중요한 역할

2단계: 그룹 권한 검토

Google Cloud 콘솔의 IAM 페이지로 이동합니다.

IAM으로 이동
groupName에 나열된 계정 이름을 필터 필드에 입력합니다.
그룹에 부여된 중요한 역할을 검토합니다.
새로 추가된 중요한 역할이 필요하지 않으면 역할을 취소합니다.

조직이나 프로젝트의 역할을 관리하려면 특정 권한이 필요합니다. 자세한 내용은 필수 권한을 참조하세요.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
필요한 경우 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 Google 그룹 설정 변경사항 로그를 확인합니다.
- protoPayload.methodName="SetIamPolicy"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정.
추가 해결 단계가 필요한지 확인하려면 조사 결과를 MITRE 연구와 결합합니다.

`Malware: Cryptomining Bad IP`

VPC 흐름 로그 및 Cloud DNS 로그에서 알려진 명령어 연결, 제어 도메인 및 IP 주소를 검사하여 멀웨어가 있는지 감지합니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Malware: Cryptomining Bad IP 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 소스 IP: 의심스러운 암호화폐 채굴 IP 주소
  - 소스 포트: 연결의 소스 포트(있는 경우)
  - 목적지 IP: 목적지 IP 주소
  - 목적지 포트: 연결의 목적지 포트(사용 가능한 경우)
  - 프로토콜: 연결과 관련된 IANA 프로토콜
- 영향을 받는 리소스
- 다음 필드를 포함하는 관련 링크:
  - Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
발견 항목의 세부정보 보기에서 소스 속성 탭을 클릭합니다.
속성을 확장하고 다음 필드에서 프로젝트 및 인스턴스 값을 확인합니다.
- instanceDetails: 프로젝트 ID와 Compute Engine 인스턴스의 이름을 모두 확인합니다. 프로젝트 ID와 인스턴스 이름은 다음 예시와 같이 표시됩니다.
```
/projects/PROJECT_ID/zones/ZONE/instances/INSTANCE_NAME
```
발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.

대시보드로 이동
properties_project_id에 지정된 프로젝트를 선택합니다.
리소스 카드로 이동하여 Compute Engine을 클릭합니다.
properties_sourceInstance와 일치하는 VM 인스턴스를 클릭합니다. 도용 가능성이 있는 인스턴스에서 멀웨어를 조사합니다.
탐색 창에서 VPC 네트워크를 클릭한 다음 방화벽을 클릭합니다. 과도한 권한이 부여된 방화벽 규칙을 삭제하거나 사용 중지합니다.

3단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
Google Cloud 콘솔 툴바에서 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 Properties_ip_0와 관련된 VPC 흐름 로그를 찾습니다.
- logName="projects/properties_project_id/logs/compute.googleapis.com%2Fvpc_flows"
- (jsonPayload.connection.src_ip="Properties_ip_0" OR jsonPayload.connection.dest_ip="Properties_ip_0")

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목 검토: 리소스 도용
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

멀웨어가 포함된 프로젝트의 소유자에게 문의합니다.
도용 가능성이 있는 인스턴스를 조사하고 발견된 멀웨어를 삭제합니다. 감지 및 삭제를 지원하려면 엔드포인트 감지 및 응답 솔루션을 이용하세요.
필요한 경우 침해된 인스턴스를 중지하고 새 인스턴스로 바꿉니다.
방화벽 규칙을 업데이트하거나 Google Cloud Armor를 사용하여 악성 IP 주소를 차단합니다. Security Command Center 통합 서비스 페이지에서 Google Cloud Armor를 사용 설정할 수 있습니다. 데이터 볼륨에 따라 Google Cloud Armor 비용이 크게 증가할 수 있습니다. 자세한 내용은 Google Cloud Armor 가격 책정 가이드를 참조하세요.

`Initial Access: Log4j Compromise Attempt`

이 발견 항목은 헤더 또는 URL 매개변수 내에서 JNDI(Java Naming and Directory Interface) 조회가 감지되는 경우에 생성됩니다. 이러한 조회는 Log4Shell 악용 시도가 있었음을 나타낼 수 있습니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 세부정보 검토의 지시에 따라 Initial Access: Log4j Compromise Attempt 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 감지된 항목
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
- 발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
- JSON에서 다음 필드를 확인합니다.
- properties
  - loadBalancerName: JNDI 조회를 수신한 부하 분산기의 이름입니다.
  - requestUrl: HTTP 요청의 요청 URL입니다. 이 필드가 있는 경우 여기에 JNDI 조회가 포함됩니다.
  - requestUserAgent: HTTP 요청을 전송한 사용자 에이전트입니다. 이 필드가 있는 경우 여기에 JNDI 조회가 포함됩니다.
  - refererUrl: HTTP 요청을 전송한 페이지의 URL입니다. 이 필드가 있는 경우 여기에 JNDI 조회가 포함됩니다.

2단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 필드(1단계)의 링크를 클릭하여 로그 탐색기로 이동합니다.
로드되는 페이지에서 httpRequest 필드를 확인하여 악용 시도를 나타내는 것일 수 있는 ${jndi:ldap://와 같은 문자열 토큰을 찾습니다.

검색할 예시 문자열 및 예시 쿼리는 로깅 문서의 CVE-2021-44228: Log4Shell 취약점 공격 감지를 참조하세요.

3단계: 공격 및 대응 방법 조사하기

MITRE ATT&CK 프레임워크 항목에서 공개 애플리케이션 악용 발견 항목 유형을 검토합니다.
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 발견 유형과 동일한 인스턴스 및 네트워크입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

4단계: 대응 구현하기

최신 버전의 Log4j2로 업그레이드합니다.
'Apache Log4j 2' 취약점 조사 및 대응을 위한 Google Cloud 권장사항을 따릅니다.
권장되는 완화 기술을 Apache Log4j 보안 취약점에 구현합니다.
Google Cloud Armor를 사용하는 경우 cve-canary rule을 새로운 Google Cloud Armor 보안 정책에 배포합니다. 자세한 내용은 Apache Log4j 취약점을 완화하는 Google Cloud Armor WAF 규칙을 참조하세요.

`Active Scan: Log4j Vulnerable to RCE`

지원되는 Log4j 취약점 스캐너는 HTTP 매개변수, URL, 텍스트 필드에 스캐너로 제어되는 도메인에 대한 콜백과 함께 난독화된 JNDI 조회를 삽입합니다. 이 발견 항목은 난독화되지 않은 도메인에 대한 DNS 쿼리를 발견하는 경우에 생성됩니다. 이러한 쿼리는 JNDI 조회가 성공한 경우에만 발생하며, 이는 활성 Log4j 취약점을 나타냅니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 세부정보 검토의 지시에 따라 Active Scan: Log4j Vulnerable to RCE 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 감지된 항목
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: Log4j RCE에 취약한 Compute Engine 인스턴스의 전체 리소스 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- properties
  - scannerDomain: 스캐너가 JNDI 조회의 일부로 사용한 도메인. 이를 통해 취약점을 발견한 스캐너를 식별할 수 있습니다.
  - sourceIp: DNS 쿼리를 수행하는 데 사용한 IP 주소
  - vpcName: DNS 쿼리가 수행된 인스턴스의 네트워크 이름

2단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 필드(1단계)의 링크를 클릭하여 로그 탐색기로 이동합니다.
로드되는 페이지에서 httpRequest 필드를 확인하여 악용 시도를 나타내는 것일 수 있는 ${jndi:ldap://와 같은 문자열 토큰을 찾습니다.

검색할 예시 문자열 및 예시 쿼리는 로깅 문서의 CVE-2021-44228: Log4Shell 취약점 공격 감지를 참조하세요.

3단계: 공격 및 대응 방법 조사하기

MITRE ATT&CK 프레임워크 항목에서 원격 서비스 악용 발견 항목 유형을 검토합니다.
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 발견 유형과 동일한 인스턴스 및 네트워크입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

4단계: 대응 구현하기

최신 버전의 Log4j2로 업그레이드합니다.
'Apache Log4j 2' 취약점 조사 및 대응을 위한 Google Cloud 권장사항을 따릅니다.
권장되는 완화 기술을 Apache Log4j 보안 취약점에 구현합니다.
Google Cloud Armor를 사용하는 경우 cve-canary rule을 새로운 Google Cloud Armor 보안 정책에 배포합니다. 자세한 내용은 Apache Log4j 취약점을 완화하는 Google Cloud Armor WAF 규칙을 참조하세요.

`Leaked credentials`

프로젝트 수준의 활성화에는 이 발견 항목을 사용할 수 없습니다.

Google Cloud 서비스 계정 사용자 인증 정보가 온라인에서 유출되거나 침해된 경우 이 발견 항목이 생성됩니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 세부정보 검토의 지시에 따라 account_has_leaked_credentials 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.

감지된 항목
영향을 받는 리소스

소스 속성 탭을 클릭하고 다음 필드를 확인합니다.
- Compromised_account: 침해 가능성이 있는 서비스 계정
- Project_identifier: 유출 가능성이 있는 계정 사용자 인증 정보가 포함된 프로젝트
- URL: GitHub 저장소 링크
발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 프로젝트 및 서비스 계정 권한 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 Project_identifier에 나열된 프로젝트를 선택합니다.
표시되는 페이지의 필터 상자에서 Compromised_account에 나열된 계정 이름을 입력하고 할당된 권한을 선택합니다.
Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.

서비스 계정으로 이동
표시되는 페이지의 필터 상자에서 침해된 서비스 계정 이름을 입력하고 서비스 계정의 키 및 키 생성 날짜를 확인합니다.

3단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
Google Cloud 콘솔 툴바에서 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 새 IAM 리소스 또는 업데이트된 IAM 리소스의 활동 로그를 확인합니다.
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- resource.type="gce_instance" AND log_name="projects/Project_identifier/logs/cloudaudit.googleapis.com%2Factivity"
- protoPayload.methodName="InsertProjectOwnershipInvite"
- protoPayload.authenticationInfo.principalEmail="Compromised_account"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정: 클라우드 계정
relatedFindingURI의 링크를 클릭하여 관련된 발견 항목을 검토합니다. 관련 발견 항목은 동일한 발견 유형과 동일한 인스턴스 및 네트워크입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

사용자 인증 정보가 유출된 프로젝트 소유자에게 문의하세요.
침해된 서비스 계정을 삭제하고 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 리소스를 식별하고 리소스 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.
URL 링크를 열고 유출된 사용자 인증 정보를 삭제합니다. 도용된 계정에 대한 추가 정보를 수집하고 소유자에게 문의합니다.

`Malware`

VPC 흐름 로그 및 Cloud DNS 로그에서 알려진 명령어 연결, 제어 도메인 및 IP 주소를 검사하여 멀웨어가 있는지 감지합니다. 현재 Event Threat Detection은 일반적인 멀웨어 감지(Malware: Bad IP 및 Malware: Bad Domain)와 특히 Log4j 관련 멀웨어(Log4j Malware: Bad IP 및 Log4j Malware: Bad Domain) 감지기를 제공합니다.

다음 단계에서는 IP 기반 발견 항목을 조사하고 대응하는 방법을 설명합니다. 해결 단계는 도메인 기반 발견 항목과 비슷합니다.

1단계: 발견 항목 세부정보 검토하기

관련 멀웨어 발견 항목을 엽니다. 다음 단계에서는 발견 항목 검토의 지시에 따라 Malware: Bad IP 발견 항목을 사용합니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 표시기 도메인: Bad domain 발견 항목의 경우 발견 항목을 트리거한 도메인
  - 표시기 IP: Bad IP 발견 항목의 경우 발견 항목을 트리거한 IP 주소
  - 소스 IP: Bad IP 발견 항목의 경우 알려진 멀웨어 명령어 및 제어 IP 주소
  - 소스 포트: Bad IP 발견 항목의 경우 연결의 소스 포트
  - 목적지 IP: Bad IP 발견 항목의 경우 멀웨어의 목적지 IP 주소
  - 목적지 포트: Bad IP 발견 항목의 경우 연결의 목적지 포트
  - 프로토콜: Bad IP 발견 항목의 경우 연결과 연결된 IANA 프로토콜 번호
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받는 Compute Engine 인스턴스의 전체 리소스 이름
  - 프로젝트 전체 이름: 발견 항목이 포함된 프로젝트의 전체 리소스 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
  - Chronicle: Google SecOps에 대한 링크입니다.
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
1. JSON 탭을 클릭하고 다음 필드를 확인합니다.
  - evidence:
  - sourceLogId:
    - projectID: 문제가 감지된 프로젝트의 ID
  - properties:
  - InstanceDetails: Compute Engine 인스턴스의 리소스 주소

2단계: Google Security Operations에서 조사

조직 수준에서 Security Command Center를 활성화하는 경우에만 Google SecOps를 사용할 수 있습니다.

Google Cloud 콘솔에서 Security Command Center 발견 항목 페이지로 이동합니다.

발견 항목으로 이동
빠른 필터 패널에서 소스 표시 이름으로 스크롤합니다.
소스 표시 이름 섹션에서 Event Threat Detection을 선택합니다.

테이블에 선택한 소스 유형의 발견 항목이 채워집니다.
테이블의 카테고리에서 Malware: Bad IP 발견 항목을 클릭합니다. 발견 항목의 세부정보 패널이 열립니다.
발견 항목 세부정보 패널의 관련 링크 섹션에서 Chronicle에서 조사를 클릭합니다.
Google SecOps의 가이드가 포함된 사용자 인터페이스의 안내를 따릅니다.

Google SecOps에서 조사를 수행하려면 다음 가이드를 사용하세요.

3단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.

대시보드로 이동
요약 탭의 프로젝트 전체 이름 행에 지정된 프로젝트를 선택합니다.
리소스 카드로 이동하여 Compute Engine을 클릭합니다.
리소스 전체 이름에서 이름 및 영역이 일치하는 VM 인스턴스를 클릭합니다. 네트워크 및 액세스 설정을 포함한 인스턴스 세부정보를 검토합니다.
탐색 창에서 VPC 네트워크를 클릭한 다음 방화벽을 클릭합니다. 과도한 권한이 부여된 방화벽 규칙을 삭제하거나 사용 중지합니다.

4단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
로드되는 페이지에서 다음 필터를 사용하여 소스 IP의 IP 주소와 관련된 VPC 흐름 로그를 찾습니다.
- logName="projects/projectId/logs/compute.googleapis.com%2Fvpc_flows" AND (jsonPayload.connection.src_ip="SOURCE_IP" OR jsonPayload.connection.dest_ip="destIP")
  
  다음을 바꿉니다.
  - PROJECT_ID를 projectId에 나열된 프로젝트로 바꿉니다.
  - SOURCE_IP를 발견 항목 세부정보의 요약 탭에 있는 소스 IP 행에 나열된 IP 주소로 바꿉니다.

5단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목(Dynamic Resolution 및 명령 및 제어)을 검토합니다.
발견 항목 세부정보의 요약 탭에 있는 관련 발견 항목 행에서 관련 발견 항목 링크를 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 발견 유형과 동일한 인스턴스 및 네트워크입니다.
VirusTotal 표시기에서 링크를 클릭하여 VirusTotal에서 신고된 URL과 도메인을 확인합니다. VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

6단계: 대응 구현하기

멀웨어가 포함된 프로젝트의 소유자에게 문의합니다.
도용 가능성이 있는 인스턴스를 조사하고 발견된 멀웨어를 삭제합니다. 감지 및 삭제를 지원하려면 엔드포인트 감지 및 응답 솔루션을 이용하세요.
멀웨어 삽입을 허용하는 활동 및 취약점을 추적하려면 침해된 인스턴스와 연결된 감사 로그와 syslog를 확인하세요.
필요한 경우 침해된 인스턴스를 중지하고 새 인스턴스로 바꿉니다.
방화벽 규칙을 업데이트하거나 Google Cloud Armor를 사용하여 악성 IP 주소를 차단합니다. Security Command Center 통합 서비스 페이지에서 Google Cloud Armor를 사용 설정할 수 있습니다. 데이터 볼륨에 따라 Google Cloud Armor 비용이 크게 증가할 수 있습니다. 자세한 내용은 Google Cloud Armor 가격 책정 가이드를 참조하세요.
VM 이미지의 액세스와 사용을 제어하려면 보안 VM과 신뢰할 수 있는 이미지 IAM 정책을 사용합니다.

`Persistence: IAM Anomalous Grant`

감사 로그를 조사하여 의심스러운 것으로 간주될 수 있는 IAM(IAM) 역할 부여가 추가되었는지 감지합니다.

다음은 비정상적인 권한 부여의 예시입니다.

Google Cloud 콘솔에서 gmail.com 사용자와 같은 외부 사용자를 프로젝트 소유자로 초대
민감한 권한을 부여하는 서비스 계정
민감한 권한을 부여하는 커스텀 역할
조직 또는 프로젝트 외부에서 추가된 서비스 계정

IAM Anomalous Grant 발견 항목은 이 발견 항목의 각 인스턴스에 대한 더 구체적인 정보를 제공하는 하위 규칙이 포함되어 있다는 점에서 독특합니다. 이 발견 항목의 심각도 분류는 하위 규칙에 따라 다릅니다. 하위 규칙마다 다른 응답이 필요할 수 있습니다.

다음 목록에는 가능한 모든 하위 규칙과 심각도가 나와 있습니다.

external_service_account_added_to_policy:
- HIGH: 매우 민감한 역할이 부여되었거나 조직 수준에서 중간 민감도 역할이 부여된 경우. 자세한 내용은 매우 민감한 역할을 참조하세요.
- MEDIUM: 중간 민감도 역할이 부여된 경우. 자세한 내용은 중간 민감도 역할을 참조하세요.
external_member_invited_to_policy: HIGH
external_member_added_to_policy:
- HIGH: 매우 민감한 역할이 부여되었거나 조직 수준에서 중간 민감도 역할이 부여된 경우. 자세한 내용은 매우 민감한 역할을 참조하세요.
- MEDIUM: 중간 민감도 역할이 부여된 경우. 자세한 내용은 중간 민감도 역할을 참조하세요.
custom_role_given_sensitive_permissions: MEDIUM
service_account_granted_sensitive_role_to_member: HIGH
policy_modified_by_default_compute_service_account: HIGH

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Persistence: IAM Anomalous Grant 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 기본 이메일: 역할을 할당한 사용자 또는 서비스 계정의 이메일 주소
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
  - Chronicle: Google SecOps에 대한 링크입니다.
JSON 탭을 클릭합니다. 발견 항목의 전체 JSON이 표시됩니다.
발견 항목의 JSON에서 다음 필드를 확인합니다.
- detectionCategory:
  - subRuleName: 발생한 비정상적인 권한 부여 유형에 대한 보다 구체적인 정보. 하위 규칙에 따라 이 발견 항목의 심각도 분류가 결정됩니다.
- evidence:
  - sourceLogId:
  - projectId: 허브가 포함된 프로젝트의 ID
- properties:
  - sensitiveRoleGrant:
    - bindingDeltas:
    - Action: 사용자가 수행한 작업
    - Role: 사용자에게 할당된 역할
    - member: 역할을 수신한 사용자의 이메일 주소

2단계: Google Security Operations에서 조사

프로젝트 수준에서 Security Command Center를 활성화하면 Chronicle의 Security Command Center 발견 항목을 조사할 수 없습니다.

Google Cloud 콘솔에서 Security Command Center 발견 항목 페이지로 이동합니다.

발견 항목으로 이동
빠른 필터 패널에서 소스 표시 이름으로 스크롤합니다.
소스 표시 이름 섹션에서 Event Threat Detection을 선택합니다.

테이블에 선택한 소스 유형의 발견 항목이 채워집니다.
테이블의 카테고리에서 Persistence: IAM Anomalous Grant 발견 항목을 클릭합니다. 발견 항목의 세부정보 패널이 열립니다.
발견 항목 세부정보 패널의 관련 링크 섹션에서 Chronicle에서 조사를 클릭합니다.
Google SecOps의 가이드가 포함된 사용자 인터페이스의 안내를 따릅니다.

Google SecOps에서 조사를 수행하려면 다음 가이드를 사용하세요.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
로드되는 페이지에서 다음 필터를 사용하여 새 리소스 또는 업데이트된 IAM 리소스를 찾습니다.
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정: Cloud 계정
발견 항목 세부정보의 요약 탭에서 관련 발견 항목 행을 클릭하여 관련 발견 항목을 검토합니다. 관련 발견 항목은 동일한 발견 유형과 동일한 인스턴스 및 네트워크입니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

침해된 계정이 있는 프로젝트의 소유자에게 문의하세요.
침해된 서비스 계정을 삭제하고 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제합니다. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다.
익숙하지 않은 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자와 같이 승인되지 않은 계정에 의해 생성된 프로젝트 리소스를 삭제합니다.
gmail.com 사용자 추가를 제한하려면 조직 정책을 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Persistence: Impersonation Role Granted for Dormant Service Account`

주 구성원이 휴면 상태의 사용자 관리 서비스 계정을 가장하도록 허용하는 가장 권한이 주 구성원에게 부여된 이벤트를 감지합니다. 이 발견 항목에서 휴면 서비스 계정은 영향을 받은 리소스이며, 180일 이상 비활성 상태인 서비스 계정은 휴면 상태로 간주됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Persistence: Impersonation Role Granted for Dormant Service Account 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 주 구성원 이메일: 부여 작업을 수행한 사용자
- 잘못된 액세스 부여.주 구성원 이름: 가장 역할이 부여된 주 구성원
영향을 받는 리소스에서 다음을 확인하세요.
- 리소스 표시 이름: 리소스로 사용되는 휴면 서비스 계정
- 프로젝트 전체 이름: 휴면 서비스 계정이 있는 프로젝트

2단계: 공격 및 대응 방법 조사하기

활동 분석기와 같은 서비스 계정 도구를 사용하여 휴면 서비스 계정의 활동을 조사합니다.
주 구성원 이메일 필드의 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 관련 링크 아래에 있는 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.

4단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
주 구성원 이메일의 보안이 침해된 경우 소유자의 액세스 권한을 삭제합니다.
대상 구성원에서 새로 부여된 가장 역할을 삭제합니다.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 애플리케이션에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 애플리케이션을 식별하고 애플리케이션 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Cloud Customer Care의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Persistence: Unmanaged Account Granted Sensitive Role`

비관리 계정에 중요한 역할이 부여된 이벤트를 감지합니다. 비관리 계정은 시스템 관리자가 제어할 수 없습니다. 예를 들어 해당 직원이 퇴사한 경우 관리자는 계정을 삭제할 수 없습니다. 따라서 비관리 계정에 중요한 역할을 부여하면 조직에 잠재적인 보안 위험을 초래합니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Persistence: Unmanaged Account Granted Sensitive Role 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 주 구성원 이메일: 부여 작업을 수행한 사용자
- 잘못된 액세스 권한 부여.주 구성원 이름: 권한을 받는 비관리 계정
- 잘못된 액세스 권한 부여됨: 중요한 역할이 부여됨

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
잘못된 액세스 권한 부여.주 구성원 이름 필드의 소유자에게 확인하고 비관리 계정의 출처를 파악합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 관련 링크 아래에 있는 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.

4단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
주 구성원 이메일의 보안이 침해된 경우 소유자의 액세스 권한을 삭제합니다.
비관리 계정에서 새로 부여된 중요한 역할을 삭제합니다.
이전 도구를 사용하여 비관리 계정을 관리 계정으로 전환하고 시스템 관리자의 관리 하에 이 계정을 이동하는 것이 좋습니다.

`Persistence: New API Method`

악의적인 행위자의 이상 관리자 활동이 조직, 폴더, 프로젝트에서 감지되었습니다. 이상 활동은 다음 중 하나일 수 있습니다.

조직, 폴더, 프로젝트에 있는 주 구성원의 새 활동
조직, 폴더, 프로젝트의 주 구성원에 의해 한 동안 표시되지 않은 활동

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Persistence: New API Method 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.
- 감지된 항목에서 다음을 확인합니다.
  - 주 구성원 이메일: 호출을 수행한 계정입니다.
  - 서비스 이름: 작업에 사용되는 Google Cloud 서비스의 API 이름입니다.
  - 메서드 이름: 호출된 메서드입니다.
- 영향을 받는 리소스에서 다음을 확인합니다.
  - 리소스 표시 이름: 선택한 리소스의 이름이며, 조직, 폴더, 프로젝트 이름과 동일할 수 있습니다.
  - 리소스 경로: 활동이 수행된 리소스 계층 구조의 위치입니다.

2단계: 공격 및 대응 방법 조사하기

지속성 발견 항목 유형에 대해 MITRE ATT&CK 프레임워크 항목을 검토합니다.
조직, 폴더, 프로젝트에서 작업이 보증되었는지 그리고 적법한 계정 소유자가 작업을 수행했는지 여부를 조사합니다. 조직, 폴더, 프로젝트가 리소스 경로 행에 표시되고 계정이 주 구성원 이메일 행에 표시됩니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Persistence: New Geography`

프로젝트 수준의 활성화에는 이 발견 항목을 사용할 수 없습니다.

IAM 사용자 또는 서비스 계정이 요청 IP 주소의 위치정보를 토대로 비정상적인 위치에서 Google Cloud에 액세스합니다.

1단계: 발견 항목 세부정보 검토하기

이 페이지 앞부분의 발견 항목 세부정보 검토에 설명된 대로 Persistence: New Geography 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.

특히 다음 필드를 포함하는 감지된 항목:
- 주 구성원 이메일: 잠재적으로 도용된 사용자 계정
특히 다음 필드를 포함하는 영향을 받는 리소스:
- 프로젝트 전체 이름: 잠재적으로 도용된 사용자 계정을 포함하는 프로젝트
특히 다음 필드를 포함하는 관련 링크:
- Cloud Logging URI: Logging 항목의 링크
- MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
- 관련 발견 항목: 모든 관련 발견 항목의 링크

발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
JSON에서 다음 sourceProperties 필드를 확인합니다.
- affectedResources:
  - gcpResourceName: 영향을 받는 리소스
- evidence:
  - sourceLogId:
  - projectId: 허브가 포함된 프로젝트의 ID
- properties:
  - anomalousLocation:
  - anomalousLocation: 사용자의 현재 예상 위치
  - callerIp: 외부 IP 주소
  - notSeenInLast: 정상 동작의 기준을 설정하는 데 사용되는 기간
  - typicalGeolocations: 사용자가 일반적으로 Google Cloud 리소스에 액세스하는 위치

2단계: 프로젝트 및 계정 권한 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 발견 항목 JSON의 projectID 필드에 나열된 프로젝트를 선택합니다.
표시되는 페이지의 필터 상자에서 주 구성원 이메일에 나열된 계정 이름을 입력하고 부여된 역할을 확인합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
필요한 경우 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 새 IAM 리소스 또는 업데이트된 IAM 리소스의 활동 로그를 확인합니다.
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정: 클라우드 계정
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

침해된 계정이 있는 프로젝트의 소유자에게 문의하세요.
anomalousLocation, typicalGeolocations, notSeenInLast 필드를 검토하여 액세스가 비정상적인지와 계정이 침해되었는지 확인합니다.
익숙하지 않은 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자와 같이 승인되지 않은 계정에 의해 생성된 프로젝트 리소스를 삭제합니다.
새 리소스 생성을 특정 리전으로 제한하려면 리소스 위치 제한을 참조하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Persistence: New User Agent`

프로젝트 수준의 활성화에는 이 발견 항목을 사용할 수 없습니다.

IAM 서비스 계정이 비정상적인 사용자 에이전트가 나타내는 것과 같은, 의심스러운 소프트웨어를 사용하여 Google Cloud에 액세스하고 있습니다.

1단계: 발견 항목 세부정보 검토하기

이 페이지 앞부분의 발견 항목 세부정보 검토에 설명된 대로 Persistence: New User Agent 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 잠재적으로 도용된 서비스 계정
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 프로젝트 전체 이름: 잠재적으로 도용된 서비스 계정을 포함하는 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
1. 발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
2. JSON에서 다음 필드를 확인합니다.
- projectId: 침해 가능성이 있는 서비스 계정이 포함된 프로젝트
- callerUserAgent: 비정상적인 사용자 에이전트
- anomalousSoftwareClassification: 소프트웨어 유형
- notSeenInLast: 정상 동작의 기준을 설정하는 데 사용되는 기간

2단계: 프로젝트 및 계정 권한 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 projectId에 나열된 프로젝트를 선택합니다.
표시되는 페이지의 필터 상자에서 발견 항목 세부정보의 요약 탭에 있는 주 구성원 이메일 행에 나열된 계정 이름을 입력하고 부여된 역할을 확인합니다.
Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.

서비스 계정으로 이동
표시되는 페이지의 필터 상자에서 발견 항목 세부정보의 요약 탭에 있는 주 구성원 이메일 행에 나열된 계정 이름을 입력합니다.
서비스 계정의 키 및 키 생성 날짜를 확인합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
필요한 경우 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 새 IAM 리소스 또는 업데이트된 IAM 리소스의 활동 로그를 확인합니다.
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- protoPayload.methodName="google.iam.admin.v1.UpdateRole"
- protoPayload.methodName="google.iam.admin.v1.CreateRole"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 유효한 계정: 클라우드 계정
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

침해된 계정이 있는 프로젝트의 소유자에게 문의하세요.
anomalousSoftwareClassification, callerUserAgent, behaviorPeriod 필드를 검토하여 액세스가 비정상적인지와 계정이 침해되었는지 확인합니다.
익숙하지 않은 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자와 같이 승인되지 않은 계정에 의해 생성된 프로젝트 리소스를 삭제합니다.
새 리소스 생성을 특정 리전으로 제한하려면 리소스 위치 제한을 참조하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Privilege Escalation: Changes to sensitive Kubernetes RBAC objects`

권한을 에스컬레이션하기 위해 잠재적 악의적인 행위자가 PUT 또는 PATCH 요청을 사용하여 민감한 cluster-admin의 ClusterRole, RoleBinding, 또는 ClusterRoleBinding 역할 기반 액세스 제어(RBAC) 객체를 수정하려고 시도했습니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Changes to sensitive Kubernetes RBAC objects 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 호출을 수행한 계정입니다.
  - 메서드 이름: 호출된 메서드
  - Kubernetes 바인딩: 수정된 민감한 Kubernetes 바인딩 또는 ClusterRoleBinding
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 작업이 수행된 Kubernetes 클러스터
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
감지된 항목 섹션에서 Kubernetes 바인딩 행의 바인딩 이름을 클릭합니다. 바인딩 세부정보가 표시됩니다.
표시된 바인딩에서 바인딩 세부정보를 확인합니다.

2단계: 로그 확인하기

Google Cloud 콘솔의 발견 항목 세부정보 요약탭에서 Cloud Logging URI 필드의 링크를 클릭하여 로그 탐색기로 이동합니다.
메서드 이름의 값이 PATCH 메서드인 경우 요청 본문을 확인하여 어떤 속성이 수정되었는지 확인하세요.

update(PUT) 호출에서 전체 객체가 요청에서 전송되므로 변경사항이 명확하지 않습니다.
다음 필터를 사용하여 주 구성원이 수행한 다른 작업을 확인합니다.
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  다음을 바꿉니다.
- CLUSTER_NAME: 발견 항목 세부정보의 리소스 표시 이름 필드에서 확인한 값입니다.
- PRINCIPAL_EMAIL: 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값입니다.

3단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형 권한 에스컬레이션의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
객체의 민감도를 확인하고 수정이 정당한지를 확인하세요.
바인딩의 경우 제목을 확인하고 제목에 바인딩된 역할이 필요한지 조사할 수 있습니다.
로그에서 주 구성원에 의한 다른 악성 활동 징후가 있는지 확인합니다.
주 구성원 이메일이 서비스 계정이 아닌 경우 계정 소유자에게 연락하여 적법한 소유자가 작업을 수행했는지 확인합니다.

주 구성원 이메일이 서비스 계정(IAM 또는 Kubernetes)인 경우 수정 소스를 확인하여 적법성을 결정합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Privilege Escalation: Create Kubernetes CSR for master cert`

권한을 에스컬레이션하기 위해 잠재적인 악의적 행위자가 Kubernetes 마스터 인증서 서명 요청(CSR)을 만들어 cluster-admin 액세스 권한을 부여했습니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Create Kubernetes CSR for master cert 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 호출을 수행한 계정입니다.
  - 메서드 이름: 호출된 메서드
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 작업이 수행된 Kubernetes 클러스터
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 로그 확인하기

Google Cloud 콘솔의 발견 항목 세부정보 요약탭에서 Cloud Logging URI 필드의 링크를 클릭하여 로그 탐색기로 이동합니다.
protoPayload.resourceName 필드의 값을 확인하여 특정 인증서 서명 요청을 식별합니다.
다음 필터를 사용하여 주 구성원이 수행한 다른 작업을 확인합니다.
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  다음을 바꿉니다.
- CLUSTER_NAME: 발견 항목 세부정보의 리소스 표시 이름 필드에서 확인한 값입니다.
- PRINCIPAL_EMAIL: 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값입니다.

3단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형 권한 에스컬레이션의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
cluster-admin 액세스 권한 부여가 보장되었는지 여부를 조사합니다.
주 구성원 이메일이 서비스 계정이 아닌 경우 계정 소유자에게 연락하여 적법한 소유자가 작업을 수행했는지 확인합니다.

주 구성원 이메일이 서비스 계정(IAM 또는 Kubernetes)인 경우 작업의 소스를 확인하여 적법성을 결정합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Privilege Escalation: Creation of sensitive Kubernetes bindings`

권한을 에스컬레이션하기 위해 잠재적인 악의적 행위자가 cluster-admin 역할에 새 RoleBinding 또는 ClusterRoleBinding 객체를 만들려고 시도했습니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Creation of sensitive Kubernetes bindings 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 호출을 수행한 계정입니다.
  - Kubernetes 바인딩: 생성된 민감한 Kubernetes 바인딩 또는 ClusterRoleBinding
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 작업이 수행된 Kubernetes 클러스터
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 로그 확인하기

Google Cloud 콘솔의 발견 항목 세부정보 요약탭에서 Cloud Logging URI 필드의 링크를 클릭하여 로그 탐색기로 이동합니다.
다음 필터를 사용하여 주 구성원이 수행한 다른 작업을 확인합니다.
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  다음을 바꿉니다.
- CLUSTER_NAME: 발견 항목 세부정보의 리소스 표시 이름 필드에서 확인한 값입니다.
- PRINCIPAL_EMAIL: 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값입니다.

3단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형 권한 에스컬레이션의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
생성된 바인딩의 민감도를 확인하고 주제에 역할이 필요한지 확인합니다.
바인딩의 경우 제목을 확인하고 제목에 바인딩된 역할이 필요한지 조사할 수 있습니다.
로그에서 주 구성원에 의한 다른 악성 활동 징후가 있는지 확인합니다.
주 구성원 이메일이 서비스 계정이 아닌 경우 계정 소유자에게 연락하여 적법한 소유자가 작업을 수행했는지 확인합니다.

주 구성원 이메일이 서비스 계정(IAM 또는 Kubernetes)인 경우 작업의 소스를 확인하여 적법성을 결정합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Privilege Escalation: Effectively Anonymous Users Granted GKE Cluster Access`

누군가 다음 사용자 또는 그룹 중 하나를 참조하는 RBAC 바인딩을 만들었습니다.

system:anonymous
system:authenticated
system:unauthenticated

이러한 사용자 및 그룹은 사실상 익명이므로 RBAC 역할에 대한 역할 바인딩 또는 클러스터 역할 바인딩을 만들 때는 피해야 합니다. 바인딩이 필요한지 검토합니다. 바인딩이 필요하지 않으면 삭제합니다. 자세한 내용은 이 발견 항목의 로그 메시지를 참조하세요.

system:anonymous 사용자, system:unauthenticated group 또는 system:authenticated 그룹에 권한을 부여한 생성된 바인딩을 검토합니다.
Cloud Logging의 감사 로그에서 주 구성원에 의한 다른 악의적인 활동 징후가 있는지 확인하세요.

악의적인 활동 징후가 있는 경우 이 액세스를 허용한 바인딩의 조사 및 삭제에 대한 안내를 검토하세요.

`Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials`

권한을 에스컬레이션하기 위해 잠재적인 악의적 행위자가 손상된 부트스트랩 사용자 인증 정보를 사용하여 kubectl 명령어로 인증서 서명 요청(CSR)을 쿼리했습니다.

다음은 이 규칙이 감지하는 명령어의 예시입니다.

kubectl --client-certificate kubelet.crt --client-key kubelet.key --server YOUR_SERVER get csr CSR_NAME

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 호출을 수행한 계정입니다.
  - 메서드 이름: 호출된 메서드
- 영향을 받는 리소스에서 다음을 확인합니다.
  - 리소스 표시 이름: 작업이 수행된 Kubernetes 클러스터
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 로그 확인하기

발견 항목 세부정보의 메서드 이름 필드에 기록한 메서드 이름이 GET 메서드인 경우 다음을 수행합니다.

Google Cloud 콘솔의 발견 항목 세부정보 요약탭에서 Cloud Logging URI 필드의 링크를 클릭하여 로그 탐색기로 이동합니다.
protoPayload.resourceName 필드의 값을 확인하여 특정 인증서 서명 요청을 식별합니다.

3단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형 권한 에스컬레이션의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
특정 CSR이 로그 항목에 제공되면 인증서의 민감도 및 작업이 보증되었는지 여부를 조사합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Privilege Escalation: Launch of privileged Kubernetes container`

잠재적인 악의적 행위자가 권한이 있는 컨테이너나 권한 에스컬레이션 기능이 있는 컨테이너를 포함하는 포드를 만들었습니다.

권한이 있는 컨테이너에는 privileged 필드가 true로 설정되어 있습니다. 권한 에스컬레이션 기능이 있는 컨테이너에서는 allowPrivilegeEscalation 필드가 true로 설정되어 있습니다. 자세한 내용은 Kubernetes 문서의 SecurityContext v1 코어 API 참조를 확인하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Launch of privileged Kubernetes container 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: 호출을 수행한 계정입니다.
  - Kubernetes 포드: 권한이 있는 컨테이너가 포함된 새로 만든 포드입니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 작업이 수행된 Kubernetes 클러스터
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
JSON 탭에서 발견 항목 필드의 값을 확인합니다.
- findings.kubernetes.pods[].containers: 포드 내에서 설정된 권한 있는 컨테이너입니다.

2단계: 로그 확인하기

Google Cloud 콘솔의 발견 항목 세부정보 요약탭에서 Cloud Logging URI 필드의 링크를 클릭하여 로그 탐색기로 이동합니다.
다음 필터를 사용하여 주 구성원이 수행한 다른 작업을 확인합니다.
- resource.labels.cluster_name="CLUSTER_NAME"
- protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"
  
  다음을 바꿉니다.
- CLUSTER_NAME: 발견 항목 세부정보의 리소스 표시 이름 필드에서 확인한 값입니다.
- PRINCIPAL_EMAIL: 발견 항목 세부정보의 주 구성원 이메일 필드에 기록해 둔 값입니다.

3단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형 권한 에스컬레이션의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
생성된 컨테이너에 호스트 리소스 및 커널 기능에 대한 액세스 권한이 필요한지 확인하세요.
로그에서 주 구성원에 의한 다른 악성 활동 징후가 있는지 확인합니다.
주 구성원 이메일이 서비스 계정이 아닌 경우 계정 소유자에게 연락하여 적법한 소유자가 작업을 수행했는지 확인합니다.

주 구성원 이메일이 서비스 계정(IAM 또는 Kubernetes)인 경우 작업의 소스를 확인하여 적법성을 결정합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

`Privilege Escalation: Dormant Service Account Granted Sensitive Role`

중요한 IAM 역할이 휴면 사용자 관리형 서비스 계정에 부여된 이벤트를 감지합니다. 이 경우 서비스 계정은 180일 이상 비활성 상태인 경우 휴면으로 간주됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Dormant Service Account Granted Sensitive Role 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 주 구성원 이메일: 부여 작업을 수행한 사용자
- 잘못된 액세스 부여.주 구성원 이름: 민감한 역할을 수신한 휴면 서비스 계정
- 잘못된 액세스 권한 부여됨: 할당된 민감한 IAM 역할
영향을 받는 리소스에서 다음을 확인하세요.
- 리소스 표시 이름: 민감한 IAM 역할이 휴면 서비스 계정에 부여된 조직, 폴더 또는 프로젝트

2단계: 공격 및 대응 방법 조사하기

활동 분석기와 같은 서비스 계정 도구를 사용하여 휴면 서비스 계정의 활동을 조사합니다.
주 구성원 이메일 필드의 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 관련 링크 아래에 있는 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.

4단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
주 구성원 이메일의 보안이 침해된 경우 소유자의 액세스 권한을 삭제합니다.
휴면 서비스 계정에서 새로 할당된 중요한 IAM 역할을 삭제합니다.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 리소스를 식별하고 리소스 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Cloud Customer Care의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity`

관리자 활동 감사 로그에서 서비스 계정 가장 요청에서 이상이 발생했는지 확인하여 비정상적인 서비스 계정 가장이 감지됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: Google Cloud에 액세스하는 데 사용된 가장 요청의 최종 서비스 계정
  - 서비스 이름: 명의 도용과 관련된 Google Cloud 서비스의 API 이름
  - 메서드 이름: 호출된 메서드
  - 서비스 계정 위임 정보: 위임 체인에 있는 서비스 계정 세부정보. 목록 하단의 주 구성원은 가장 요청의 호출자입니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 클러스터의 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
위임 체인에 있는 주 구성원을 조사하여 요청이 비정상적인지, 계정이 침해되었는지 확인합니다.
서비스 계정 위임 정보 목록에서 가장 호출자의 소유자에게 연락합니다. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 리소스를 식별하고 리소스 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원팀의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity`

Anomalous Multistep Service Account Delegation은 관리자 활동 감사 로그에서 서비스 계정 가장 요청에 이상이 발생했는지 확인하여 감지됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Anomalous Multistep Service Account Delegation for Admin Activity 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: Google Cloud에 액세스하는 데 사용된 가장 요청의 최종 서비스 계정
  - 서비스 이름: 명의 도용과 관련된 Google Cloud 서비스의 API 이름
  - 메서드 이름: 호출된 메서드
  - 서비스 계정 위임 정보: 위임 체인에 있는 서비스 계정 세부정보. 목록 하단의 주 구성원은 가장 요청의 호출자입니다.
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
위임 체인에 있는 주 구성원을 조사하여 요청이 비정상적인지, 계정이 침해되었는지 확인합니다.
서비스 계정 위임 정보 목록에서 가장 호출자의 소유자에게 연락합니다. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 리소스를 식별하고 리소스 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원팀의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access`

Anomalous Multistep Service Account Delegation은 데이터 액세스 감사 로그에서 서비스 계정 가장 요청에 이상이 발생했는지 확인하여 감지됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: Google Cloud에 액세스하는 데 사용된 가장 요청의 최종 서비스 계정
  - 서비스 이름: 명의 도용과 관련된 Google Cloud 서비스의 API 이름
  - 메서드 이름: 호출된 메서드입니다.
  - 서비스 계정 위임 정보: 위임 체인에 있는 서비스 계정 세부정보. 목록 하단의 주 구성원은 가장 요청의 호출자입니다.
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
위임 체인에 있는 주 구성원을 조사하여 요청이 비정상적인지, 계정이 침해되었는지 확인합니다.
서비스 계정 위임 정보 목록에서 가장 호출자의 소유자에게 연락합니다. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 리소스를 식별하고 리소스 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원팀의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity`

Anomalous Service Account Impersonator은 관리자 활동 감사 로그에서 서비스 계정 가장 요청에 이상이 발생했는지 확인하여 감지됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 주 구성원 이메일: Google Cloud에 액세스하는 데 사용된 가장 요청의 최종 서비스 계정
  - 서비스 이름: 명의 도용과 관련된 Google Cloud 서비스의 API 이름
  - 메서드 이름: 호출된 메서드입니다.
  - 서비스 계정 위임 정보: 위임 체인에 있는 서비스 계정 세부정보. 목록 하단의 주 구성원은 가장 요청의 호출자입니다.
- 영향을 받는 리소스
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
위임 체인에 있는 주 구성원을 조사하여 요청이 비정상적인지, 계정이 침해되었는지 확인합니다.
서비스 계정 위임 정보 목록에서 가장 호출자의 소유자에게 연락합니다. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 리소스를 식별하고 리소스 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원팀의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Privilege Escalation: Anomalous Service Account Impersonator for Data Access`

데이터 액세스 감사 로그에서 서비스 계정 가장 요청에서 이상이 발생했는지 확인하여 비정상적인 서비스 계정 가장이 감지됩니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: Anomalous Service Account Impersonator for Data Access 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 주 구성원 이메일: Google Cloud에 액세스하는 데 사용된 가장 요청의 최종 서비스 계정
- 서비스 이름: 명의 도용과 관련된 Google Cloud 서비스의 API 이름
- 메서드 이름: 호출된 메서드입니다.
- 서비스 계정 위임 정보: 위임 체인에 있는 서비스 계정 세부정보. 목록 하단의 주 구성원은 가장 요청의 호출자입니다.

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.
위임 체인에 있는 주 구성원을 조사하여 요청이 비정상적인지, 계정이 침해되었는지 확인합니다.
서비스 계정 위임 정보 목록에서 가장 호출자의 소유자에게 연락합니다. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 리소스를 식별하고 리소스 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원팀의 알림에 응답합니다.
서비스 계정을 만들 수 있는 사용자를 제한하려면 조직 정책 서비스를 사용하세요.
과도한 권한이 부여된 역할을 식별하고 수정하려면 IAM 추천자를 사용합니다.

`Privilege Escalation: ClusterRole with Privileged Verbs`

누군가 bind, escalate 또는 impersonate 동사가 포함된 RBAC ClusterRole을 만들었습니다. 이러한 동사로 역할에 바인딩된 주체는 더 높은 권한을 가진 다른 사용자를 가장하거나, 추가 권한이 포함된 추가 Role 또는 ClusterRole 객체에 바인딩하거나, 자체 ClusterRole 권한을 수정할 수 있습니다. 이로 인해 해당 주체가 cluster-admin 권한을 얻게 될 수 있습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

ClusterRole 및 연결된 ClusterRoleBindings를 검토하여 주체에 이러한 권한이 실제로 필요한지 확인합니다.
가능하면 bind, escalate 또는 impersonate 동사가 포함된 역할을 만들지 마세요.
Cloud Logging의 감사 로그에서 주 구성원에 의한 다른 악의적인 활동 징후가 있는지 확인하세요.
RBAC 역할에 권한을 할당할 때 최소 권한의 원칙에 따라 작업 수행에 필요한 최소 권한을 부여하세요. 최소 권한의 원칙을 사용하면 클러스터의 보안이 침해되었을 때 권한 에스컬레이션 가능성이 줄어들고 과도한 액세스로 인한 보안 사고가 발생할 가능성이 줄어듭니다.

`Privilege Escalation: ClusterRoleBinding to Privileged Role`

누군가 기본 system:controller:clusterrole-aggregation-controller ClusterRole을 참조하는 RBAC ClusterRoleBinding을 만들었습니다. 이 기본 ClusterRole에는 사용자가 자신의 역할 권한을 수정하여 권한 에스컬레이션을 허용하는 escalate 동사가 있습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

system:controller:clusterrole-aggregation-controller ClusterRole을 참조하는 ClusterRoleBinding을 검토합니다.
system:controller:clusterrole-aggregation-controller ClusterRole의 모든 수정사항을 검토합니다.
Cloud Logging의 감사 로그에서 ClusterRoleBinding을 만든 주 구성원에 의한 다른 악의적인 활동 징후가 있는지 확인하세요.

`Privilege Escalation: Suspicious Kubernetes Container Names - Exploitation and Escape`

누군가 컨테이너 이스케이프에 사용되는 일반적인 도구와 유사한 이름 지정 규칙으로 포드를 배포했거나 클러스터에서 다른 공격을 실행했습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

포드가 정당한지 확인하세요.
Cloud Logging의 감사 로그에서 포드 또는 주 구성원의 다른 악의적인 활동 징후가 있는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)이 아닌 경우 계정 소유자에게 연락하여 정당한 소유자가 작업을 수행했는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)인 경우 작업 소스를 식별하여 정당성을 확인하세요.
포드가 정당하지 않은 경우 워크로드에서 사용하고 생성을 허용한 연결된 RBAC 바인딩 및 서비스 계정과 함께 이 포드를 삭제하세요.

`Privilege Escalation: Workload Created with a Sensitive Host Path Mount`

누군가 호스트 노드의 파일 시스템에서 민감한 경로에 hostPath 볼륨 마운트를 포함하는 워크로드를 만들었습니다. 호스트 파일 시스템의 이러한 경로에 대한 액세스 권한은 노드에서 권한이 있거나 민감한 정보에 액세스하고 컨테이너 이스케이프 처리하는 데 사용될 수 있습니다. 가능하면 클러스터에서 hostPath 볼륨을 허용하지 마세요. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

워크로드를 검토하여 의도한 기능에 이 hostPath 볼륨이 필요한지 확인하세요. 필요하다면 경로가 가능한 한 가장 구체적인 디렉터리로 설정되어 있는지 확인하세요. 예를 들어 / 또는 /etc 대신 /etc/myapp/myfiles를 사용합니다.
Cloud Logging의 감사 로그에서 이 워크로드와 관련된 다른 악의적인 활동 징후가 있는지 확인하세요.

클러스터에서 hostPath 볼륨 마운트를 차단하려면 포드 보안 표준 적용에 대한 안내를 참조하세요.

`Privilege Escalation: Workload with shareProcessNamespace enabled`

누군가 모든 컨테이너가 동일한 Linux 프로세스 네임스페이스를 공유할 수 있도록 shareProcessNamespace 옵션을 true로 설정하여 워크로드를 배포했습니다. 이렇게 하면 신뢰할 수 없거나 손상된 컨테이너가 다른 컨테이너에서 실행되는 프로세스의 환경 변수, 메모리, 기타 민감한 정보에 액세스하고 이를 제어하여 권한을 에스컬레이션할 수 있습니다. 로그 처리 사이드카 컨테이너 또는 디버깅 컨테이너와 같이 타당한 이유로 이 기능이 작동해야 하는 일부 워크로드가 있을 수 있습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

워크로드의 모든 컨테이너에 공유 프로세스 네임스페이스에 대한 액세스가 워크로드에 실제로 필요한지 확인하세요.
Cloud Logging의 감사 로그에서 주 구성원에 의한 다른 악의적인 활동 징후가 있는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)이 아닌 경우 계정 소유자에게 연락하여 소유자가 작업을 수행했는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)인 경우 서비스 계정에서 이 작업을 수행하게 한 원인의 정당성을 확인하세요.

`Service account self-investigation`

서비스 계정 사용자 인증 정보가 동일한 서비스 계정과 연결된 역할 및 권한을 조사하는 데 사용됩니다. 이 발견 항목은 서비스 계정 사용자 인증 정보가 손상되었을 수 있으며 즉각적인 조치를 취해야 함을 나타냅니다.

1단계: 발견 항목 세부정보 검토하기

이 페이지 앞부분의 발견 항목 세부정보 검토에 설명된 대로 Discovery: Service Account Self-Investigation 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 심각도: 발견 항목에 할당된 위험 수준. 이 발견 항목을 트리거한 API 호출이 승인되지 않아서 서비스 계정에 projects.getIamPolicy API로 자체 IAM 권한을 쿼리할 수 있는 권한이 없으면 심각도가 HIGH입니다.
  - 주 구성원 이메일: 잠재적으로 도용된 서비스 계정
  - 호출자 IP: 내부 또는 외부 IP 주소
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름:
  - 프로젝트 전체 이름: 잠재적으로 유출된 계정 세부정보를 포함하는 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
1. 발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 프로젝트 및 서비스 계정 권한 검토하기

Google Cloud 콘솔에서 IAM 페이지로 이동합니다.

IAM으로 이동
필요한 경우 발견 항목 JSON의 projectID 필드에 나열된 프로젝트를 선택합니다.
표시되는 페이지의 필터 상자에서 주 구성원 이메일에 나열된 계정 이름을 입력하고 할당된 권한을 확인합니다.
Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.

서비스 계정으로 이동
표시되는 페이지의 필터 상자에서 침해된 서비스 계정 이름을 입력하고 서비스 계정의 키 및 키 생성 날짜를 확인합니다.

3단계: 로그 확인하기

발견 항목 세부정보 패널의 요약 탭에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기를 엽니다.
필요한 경우 프로젝트를 선택합니다.
로드되는 페이지에서 다음 필터를 사용하여 새 IAM 리소스 또는 업데이트된 IAM 리소스의 활동 로그를 확인합니다.
- proto_payload.method_name="google.iam.admin.v1.CreateServiceAccount"
- protoPayload.methodName="SetIamPolicy"
- protoPayload.authenticationInfo.principalEmail="principalEmail"

4단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(권한 그룹 검색: 클라우드 그룹)에 대한 MITRE ATT&CK 프레임워크 항목을 검토하세요.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

침해된 계정이 있는 프로젝트의 소유자에게 문의하세요.
침해된 서비스 계정을 삭제하고 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제합니다. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 리소스에서 액세스 권한을 잃게 됩니다.
익숙하지 않은 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자처럼 도용된 계정이 만든 프로젝트 리소스를 삭제합니다.

`Inhibit System Recovery: Deleted Google Cloud Backup and DR host`

Event Threat Detection은 감사 로그를 검사하여 백업 및 DR 서비스로 보호되는 애플리케이션을 실행하는 호스트의 삭제를 감지합니다. 호스트가 삭제된 후에는 호스트와 연결된 애플리케이션을 백업할 수 없습니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Deleted Google Cloud Backup and DR host 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 애플리케이션 이름: 백업 및 DR에 연결된 데이터베이스 또는 VM의 이름
  - 호스트 이름: 백업 및 DR에 연결된 호스트의 이름
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 호스트가 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

다음의 응답 계획이 이 발견 항목에 적합할 수 있습니다. 조사에서 수집한 정보를 신중하게 평가하여 발견 항목을 해결할 최선의 방법을 결정해야 합니다.

작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다.
삭제된 호스트가 더 이상 백업 및 DR 호스트 목록에 없는지 확인합니다.
호스트 추가 옵션을 선택하여 삭제된 호스트를 다시 추가합니다.

`Inhibit System Recovery: Google Cloud Backup and DR remove plan`

Security Command Center는 감사 로그를 검사하여 애플리케이션에 백업 정책을 적용하는 데 사용되는 백업 및 DR 서비스 백업 계획의 비정상적인 삭제를 감지합니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR remove plan 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 애플리케이션 이름: 백업 및 DR에 연결된 데이터베이스 또는 VM의 이름
  - 프로필 이름: 애플리케이션 및 VM 데이터의 백업에 대한 스토리지 대상 지정
  - 템플릿 이름: 백업 빈도, 일정, 보관 기간을 정의하는 정책 집합의 이름
- 영향을 받는 리소스
  - 리소스 표시 이름: 계획이 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다.
앱 관리자 탭에서 영향을 받는 애플리케이션 중 더 이상 보호되지 않는 애플리케이션을 찾고 각 애플리케이션의 백업 정책을 검토합니다.

`Inhibit System Recovery: Google Cloud Backup and DR delete template`

Security Command Center는 감사 로그를 검사하여 템플릿의 비정상적인 삭제를 감지합니다. 템플릿은 여러 애플리케이션에 적용할 수 있는 백업의 기본 구성입니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR delete template 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 템플릿 이름: 백업 빈도, 일정, 보관 기간을 정의하는 정책 집합의 이름
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 템플릿이 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다.
앱 관리자 탭에서 영향을 받는 애플리케이션 중 더 이상 보호되지 않는 애플리케이션을 찾고 각 애플리케이션의 백업 정책을 검토합니다.
템플릿을 다시 추가하려면 백업 계획 탭으로 이동하고 템플릿을 선택한 후 템플릿 만들기 옵션을 선택합니다.

`Inhibit System Recovery: Google Cloud Backup and DR delete policy`

감사 로그를 조사하여 정책 삭제를 감지합니다. 정책은 백업 수행 방법과 저장 위치를 정의합니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR delete policy 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 정책 이름: 백업 빈도, 일정, 보관 기간을 정의하는 단일 정책의 이름
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 정책이 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

다음의 응답 계획이 이 발견 항목에 적합할 수 있습니다. 조사에서 수집한 정보를 신중하게 평가하여 발견 항목을 해결할 최선의 방법을 결정해야 합니다. 1. 작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다. 2. 앱 관리자 탭에서 영향을 받은 애플리케이션을 선택하고 해당 애플리케이션에 적용된 정책 설정을 검토합니다.

`Inhibit System Recovery: Google Cloud Backup and DR delete profile`

감사 로그를 조사하여 프로필 삭제를 감지합니다. 프로필은 백업을 저장하는 데 사용되는 스토리지 풀을 정의합니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR delete profile 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로필 이름: 애플리케이션 및 VM 데이터의 백업에 대한 스토리지 대상 지정
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 프로필이 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

다음의 응답 계획이 이 발견 항목에 적합할 수 있습니다. 조사에서 수집한 정보를 신중하게 평가하여 발견 항목을 해결할 최선의 방법을 결정해야 합니다. 1. 작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다. 2. 백업 계획 탭에서 프로필을 선택하여 모든 프로필 목록을 봅니다. 3. 프로필을 검토하여 모든 필수 프로필이 준비되었는지 확인합니다. 4. 삭제된 프로필이 실수로 삭제된 경우 프로필 만들기를 선택하여 백업 및 DR 어플라이언스의 스토리지 대상을 정의합니다.

`Inhibit System Recovery: Google Cloud Backup and DR delete storage pool`

감사 로그를 조사하여 스토리지 풀 삭제를 감지합니다. 스토리지 풀은 Cloud Storage 버킷을 백업 및 DR과 연결합니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR delete storage pool 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 스토리지 풀 이름: 백업이 저장되는 스토리지 버킷의 이름
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 스토리지 풀이 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

다음의 응답 계획이 이 발견 항목에 적합할 수 있습니다. 조사에서 수집한 정보를 신중하게 평가하여 발견 항목을 해결할 최선의 방법을 결정해야 합니다. 1. 작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다. 2. 관리 탭에서 스토리지 풀을 선택하여 모든 스토리지 풀 목록을 봅니다. 3. Backup Appliance와 스토리지 풀의 연결을 검토합니다. 4. 활성 어플라이언스에 연결된 스토리지 풀이 없으면 OnVault 풀 추가를 선택하여 다시 추가합니다.

`Data Destruction: Google Cloud Backup and DR expire image`

잠재적인 악의적 행위자가 백업 이미지 삭제를 요청했습니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR expire image 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 정책 이름: 백업 빈도, 일정, 보관 기간을 정의하는 단일 정책의 이름
  - 템플릿 이름: 백업 빈도, 일정, 보관 기간을 정의하는 정책 집합의 이름
  - 프로필 이름: 애플리케이션 및 VM 데이터의 백업에 대한 스토리지 대상 지정
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 백업 이미지가 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

다음의 응답 계획이 이 발견 항목에 적합할 수 있습니다. 조사에서 수집한 정보를 신중하게 평가하여 발견 항목을 해결할 최선의 방법을 결정해야 합니다. 1. 작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다. 2. 모니터 탭으로 이동하고 작업을 선택하여 백업 삭제 작업의 상태를 검토합니다. 3. 삭제 작업이 승인되지 않은 경우 IAM 권한으로 이동하여 백업 데이터에 대한 액세스 권한이 있는 사용자를 검토합니다.

`Data Destruction: Google Cloud Backup and DR expire all images`

잠재적인 악의적 행위자가 애플리케이션과 연결된 모든 백업 이미지를 삭제하도록 요청했습니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR expire all images 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 정책 이름: 백업 빈도, 일정, 보관 기간을 정의하는 단일 정책의 이름
  - 템플릿 이름: 백업 빈도, 일정, 보관 기간을 정의하는 정책 집합의 이름
  - 프로필 이름: 애플리케이션 및 VM 데이터의 백업에 대한 스토리지 대상 지정
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 백업 이미지가 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

`Data Destruction: Google Cloud Backup and DR remove appliance`

감사 로그를 조사하여 백업 및 복구 어플라이언스 삭제를 감지합니다. 백업 및 복구 어플라이언스는 백업 작업에 중요한 구성요소입니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Inhibit System Recovery: Google Cloud Backup and DR remove appliance 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 어플라이언스 이름: 백업 및 DR에 연결된 데이터베이스 또는 VM의 이름
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자
- 영향을 받는 리소스
  - 리소스 표시 이름: 어플라이언스가 삭제된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

다음의 응답 계획이 이 발견 항목에 적합할 수 있습니다. 조사에서 수집한 정보를 신중하게 평가하여 발견 항목을 해결할 최선의 방법을 결정해야 합니다. 1. 작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다. 2. 앱 관리자 탭에서 영향을 받는 애플리케이션 중 더 이상 보호되지 않는 애플리케이션을 찾고 각 애플리케이션의 백업 정책을 검토합니다. 3. 새 어플라이언스를 만들고 보호되지 않는 앱에 보호 조치를 다시 적용하려면 Google Cloud 콘솔에서 백업 및 DR로 이동하고 다른 백업 또는 복구 어플라이언스 배포 옵션을 선택합니다. 4. 스토리지 메뉴에서 스토리지 대상을 사용하여 각각의 새 어플라이언스를 구성합니다. 어플라이언스를 구성한 후에는 애플리케이션의 프로필을 만들 때 옵션으로 표시됩니다.

`Impact: Google Cloud Backup and DR reduced backup expiration`

Event Threat Detection은 감사 로그를 조사하여 백업 및 DR 서비스 어플라이언스의 백업 만료일이 단축되었는지 확인합니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Impact: Google Cloud Backup and DR reduced backup expiration 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 설명: 감지에 대한 정보
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자 또는 서비스 계정
- 영향을 받는 리소스
  - 리소스 표시 이름: 백업 만료일이 앞당겨진 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 주체 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다.
앱 관리자 탭에서 영향을 받는 애플리케이션 중 백업 만료일이 앞당겨진 애플리케이션을 찾고 주 구성원이 의도한 것인지 확인합니다.
애플리케이션의 새 백업을 시작하려면 백업 구성 관리를 선택하여 주문형 백업을 만들거나 새 백업을 예약합니다.

`Impact: Google Cloud Backup and DR reduced backup frequency`

Event Threat Detection은 감사 로그를 검사하여 백업 빈도를 줄이기 위해 백업 계획이 수정되었는지 감지합니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Impact: Google Cloud Backup and DR reduced backup frequency 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 설명: 감지에 대한 정보
  - 주 구성원 주체: 작업을 성공적으로 실행한 사용자 또는 서비스 계정
- 영향을 받는 리소스
  - 리소스 표시 이름: 백업 빈도가 감소한 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - MITRE ATTACK 메서드: MITRE ATT&CK 문서의 링크
  - Logging URI: 로그 탐색기를 여는 링크

2단계: 공격 및 대응 방법 조사하기

주 구성원 주체 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트에서 관리 콘솔로 이동합니다.
앱 관리자 탭에서 영향을 받는 애플리케이션 중 백업 빈도가 줄어든 애플리케이션을 찾고 주 구성원이 의도한 것인지 확인합니다.
애플리케이션의 새 백업을 시작하려면 백업 구성 관리를 선택하여 주문형 백업을 만들거나 새 백업을 예약합니다.

`Impact: Suspicious Kubernetes Container Names - Coin Mining`

누군가 일반적인 암호화폐 코인 채굴기와 유사한 이름 지정 규칙으로 포드를 배포했습니다. 클러스터에 대한 초기 액세스 권한을 얻은 공격자가 암호화폐 채굴에 클러스터 리소스를 사용하려는 시도일 수 있습니다. 자세한 내용은 이 알림의 로그 메시지를 참조하세요.

포드가 정당한지 확인하세요.
Cloud Logging의 감사 로그에서 포드 또는 주 구성원의 다른 악의적인 활동 징후가 있는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)이 아닌 경우 계정 소유자에게 연락하여 정당한 소유자가 작업을 수행했는지 확인하세요.
주 구성원이 서비스 계정(IAM 또는 Kubernetes)인 경우 작업 소스를 식별하여 정당성을 확인하세요.
포드가 정당하지 않은 경우 워크로드에서 사용하고 생성을 허용한 연결된 RBAC 바인딩 및 서비스 계정과 함께 이 포드를 삭제하세요.

`Lateral Movement: Modified Boot Disk Attached to Instance`

감사 로그를 조사하여 Compute Engine 인스턴스 리소스 간에 의심스러운 디스크 이동을 감지합니다. 수정되었을 수 있는 부팅 디스크가 Compute Engine에 연결되었습니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토에 설명된 대로 Lateral Movement: Modify Boot Disk Attaching to Instance 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 필드 값을 확인합니다.

감지된 항목에서 다음을 확인합니다.
- 주 구성원 이메일: 작업을 수행한 서비스 계정
- 서비스 이름: 서비스 계정으로 액세스한 Google Cloud 서비스의 API 이름
- 메서드 이름: 호출된 메서드입니다.

2단계: 공격 및 대응 방법 조사하기

활동 분석기와 같은 서비스 계정 도구를 사용하여 연결된 서비스 계정의 활동을 조사합니다.
주 구성원 이메일 필드의 서비스 계정 소유자에게 문의하세요. 적법한 소유자가 작업을 수행했는지 확인합니다.

3단계: 대응 구현하기

작업이 수행된 프로젝트의 소유자에게 문의하세요.
Compute Engine VM 인스턴스에 보안 부팅을 사용하는 것이 좋습니다.
잠재적으로 침해된 서비스 계정을 삭제하고 잠재적으로 침해된 프로젝트의 모든 서비스 계정 액세스 키를 순환 및 삭제하세요. 삭제 후에는 인증을 위해 서비스 계정을 사용하는 애플리케이션에서 액세스 권한을 잃게 됩니다. 계속하기 전에 보안팀은 영향을 받는 모든 애플리케이션을 식별하고 애플리케이션 소유자와 협력하여 비즈니스 연속성을 보장해야 합니다.
보안팀과 협력하여 Compute Engine 인스턴스, 스냅샷, 서비스 계정, IAM 사용자를 포함하여 익숙하지 않은 리소스를 확인합니다. 승인된 계정으로 생성되지 않은 리소스를 삭제합니다.
Google Cloud 지원팀의 알림에 응답합니다.

`Privilege Escalation: AlloyDB Over-Privileged Grant`

PostgreSQL용 AlloyDB 데이터베이스(또는 데이터베이스의 모든 함수 또는 프로시저)에 대한 모든 권한이 한 명 이상의 데이터베이스 사용자에게 부여된 경우를 감지합니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: AlloyDB Over-Privileged Grant 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 데이터베이스 표시 이름: 영향을 받은 PostgreSQL용 AlloyDB 인스턴스의 데이터베이스 이름
  - 데이터베이스 사용자 이름: 초과 권한을 부여한 PostgreSQL 사용자
  - 데이터베이스 쿼리: 권한을 부여한 실행된 PostgreSQL 쿼리
  - 데이터베이스 피부여자: 과도한 권한 피부여자
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받은 PostgreSQL용 AlloyDB 인스턴스의 리소스 이름
  - 상위 전체 이름: PostgreSQL용 AlloyDB 인스턴스의 리소스 이름
  - 프로젝트 전체 이름: PostgreSQL용 AlloyDB 인스턴스를 포함하는 Google Cloud 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 데이터베이스 권한 검토

PostgreSQL용 AlloyDB 인스턴스에 연결합니다.
다음에 대한 액세스 권한을 나열하고 표시합니다.
- 데이터베이스. \l 또는 \list 메타 명령어를 사용하여 데이터베이스 표시 이름에 나열된 데이터베이스에 할당된 권한을 확인합니다(1단계).
- 함수 또는 프로시져. \df 메타 명령어를 사용하고 데이터베이스 표시 이름에 나열된 데이터베이스에서 함수 또는 프로시져에 할당된 권한을 확인합니다(1단계).

3단계: 로그 확인하기

Google Cloud 콘솔에서 Cloud Logging URI 링크를 클릭하여 로그 탐색기로 이동합니다(1단계). 로그 탐색기 페이지에는 관련 Cloud SQL 인스턴스와 관련된 모든 로그가 포함되어 있습니다.
로그 탐색기에서 다음 필터를 사용하여 데이터베이스에 실행된 쿼리를 기록하는 PostgreSQL pgaudit 로그를 확인합니다.
- protoPayload.request.database="var class="edit">database"

4단계: 공격 및 대응 방법 조사하기

웹 서비스를 통한 유출 유형의 발견 항목에 대한 MITRE ATT&CK 프레임워크 항목을 검토하세요.
추가 해결 단계가 필요한지 확인하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

과도하게 부여된 권한 부여는 인스턴스 소유자에게 문의하세요.
조사가 완료될 때까지 데이터베이스 피부여자에 나열된 피부여자에 대해 모든 권한을 취소하는 것이 좋습니다.
데이터베이스 액세스를 제한하려면(1단계의 데이터베이스 표시 이름) 피부여자에게서 불필요한 권한을 취소합니다(1단계의 데이터베이스 피부여자).

`Privilege Escalation: AlloyDB Database Superuser Writes to User Tables`

PostgreSQL용 AlloyDB 데이터베이스 수퍼유저 계정(postgres)이 사용자 테이블에 쓰는 경우를 감지합니다. 수퍼유저(매우 광범위한 액세스 권한이 있는 역할)는 일반적으로 사용자 테이블에 쓰는 데 사용해서는 안 됩니다. 일반적인 일상 활동에는 액세스가 제한된 사용자 계정을 사용해야 합니다. 수퍼유저가 사용자 테이블에 작성하면 공격자가 권한을 에스컬레이션했거나 기본 데이터베이스 사용자의 보안을 침해하여 데이터를 수정하고 있음을 의미할 수 있습니다. 또한 정상일지라도 안전하지 않은 관행입니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Privilege Escalation: AlloyDB Database Superuser Writes to User Tables 발견 항목을 엽니다.
발견 항목 세부정보 패널의 요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 데이터베이스 표시 이름: 영향을 받은 PostgreSQL용 AlloyDB 인스턴스의 데이터베이스 이름
  - 데이터베이스 사용자 이름: 수퍼유저
  - 데이터베이스 쿼리: 사용자 테이블에 쓰는 동안 실행된 SQL 쿼리
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받은 PostgreSQL용 AlloyDB 인스턴스의 리소스 이름
  - 상위 전체 이름: PostgreSQL용 AlloyDB 인스턴스의 리소스 이름
  - 프로젝트 전체 이름: PostgreSQL용 AlloyDB 인스턴스를 포함하는 Google Cloud 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 로그 확인하기

Google Cloud 콘솔에서 cloudLoggingQueryURI의 링크(1단계)를 클릭하여 로그 탐색기로 이동합니다. 로그 탐색기 페이지에는 관련 PostgreSQL용 AlloyDB 인스턴스와 관련된 모든 로그가 포함되어 있습니다.
다음 필터를 사용하여 수퍼유저가 실행한 쿼리가 포함된 PostgreSQL pgaudit 로그를 확인합니다.
- protoPayload.request.user="postgres"

3단계: 공격 및 대응 방법 조사하기

웹 서비스를 통한 유출 유형의 발견 항목에 대한 MITRE ATT&CK 프레임워크 항목을 검토하세요.
추가 해결 단계가 필요한지 확인하려면 조사 결과를 MITRE 연구와 결합합니다.

4단계: 대응 구현하기

데이터베이스 연결이 허용된 사용자를 검토합니다.
수퍼유저의 비밀번호를 변경하는 것이 좋습니다.
인스턴스에서 사용되는 다양한 유형의 쿼리에 대해 액세스가 제한된 사용자를 새로 만드는 것이 좋습니다.
- 새 사용자에게 쿼리를 실행하는 데 필요한 권한만 부여합니다.
- PostgreSQL용 AlloyDB 인스턴스에 연결하는 클라이언트의 사용자 인증 정보를 업데이트합니다.

Compute Engine 관리자 메타데이터 감지

`Persistence: GCE Admin Added SSH Key`

설명 작업

설명	작업
설정된 인스턴스에서 `ssh-keys` Compute Engine 인스턴스 메타데이터 키가 변경되었습니다.	Compute Engine 인스턴스 메타데이터 키 `ssh-keys`가 7일보다 더 오래 전에 생성된 인스턴스에서 수정되었습니다. 의도적으로 구성원이 수행한 변경인지 또는 조직에서 새로운 액세스 권한을 도입하기 위해 공격자가 구현했는지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.instance_id=INSTANCE_ID` `protoPayload.serviceName="compute.googleapis.com"` `(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 다음을 바꿉니다. `INSTANCE_ID`: 발견 항목에 나열된 `gceInstanceId` `ORGANIZATION_ID`: 조직 ID
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1098/004/

설정된 인스턴스에서 ssh-keys Compute Engine 인스턴스 메타데이터 키가 변경되었습니다.

Compute Engine 인스턴스 메타데이터 키 ssh-keys가 7일보다 더 오래 전에 생성된 인스턴스에서 수정되었습니다. 의도적으로 구성원이 수행한 변경인지 또는 조직에서 새로운 액세스 권한을 도입하기 위해 공격자가 구현했는지 확인합니다.

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

(protoPayload.metadata.instanceMetaData.addedMetadataKey : "ssh-keys" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "ssh-keys" )

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

다음을 바꿉니다.

INSTANCE_ID: 발견 항목에 나열된 gceInstanceId
ORGANIZATION_ID: 조직 ID

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1098/004/

`Persistence: GCE Admin Added Startup Script`

설명 작업

설명	작업
설정된 인스턴스에서 `startup-script` 또는 `startup-script-url` Compute Engine 인스턴스 메타데이터 키가 변경되었습니다.	Compute Engine 인스턴스 메타데이터 키 `startup-script` 또는 `startup-script-url`이 7일보다 더 오래 전에 생성된 인스턴스에서 수정되었습니다. 의도적으로 구성원이 수행한 변경인지 또는 조직에서 새로운 액세스 권한을 도입하기 위해 공격자가 구현했는지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.instance_id=INSTANCE_ID` `protoPayload.serviceName="compute.googleapis.com"` `((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )` `OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 다음을 바꿉니다. `INSTANCE_ID`: 발견 항목에 나열된 `gceInstanceId` `ORGANIZATION_ID`: 조직 ID
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1098/004/

설정된 인스턴스에서 startup-script 또는 startup-script-url Compute Engine 인스턴스 메타데이터 키가 변경되었습니다.

Compute Engine 인스턴스 메타데이터 키 startup-script 또는 startup-script-url이 7일보다 더 오래 전에 생성된 인스턴스에서 수정되었습니다. 의도적으로 구성원이 수행한 변경인지 또는 조직에서 새로운 액세스 권한을 도입하기 위해 공격자가 구현했는지 확인합니다.

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.instance_id=INSTANCE_ID

protoPayload.serviceName="compute.googleapis.com"

((protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script" )

OR (protoPayload.metadata.instanceMetaData.addedMetadataKey : "startup-script-url" OR protoPayload.metadata.instanceMetaData.modifiedMetadataKey : "startup-script-url" ))

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

다음을 바꿉니다.

INSTANCE_ID: 발견 항목에 나열된 gceInstanceId
ORGANIZATION_ID: 조직 ID

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1098/004/

Google Workspace 로그 감지

Google Workspace 로그를 Cloud Logging과 공유하면 Event Threat Detection에서 여러 Google Workspace 위협에 대한 발견 항목을 생성합니다. Google Workspace 로그는 조직 수준에 있으므로 조직 수준에서 Security Command Center를 활성화하는 경우에만 Event Threat Detection이 이러한 로그를 검사할 수 있습니다.

Event Threat Detection은 로그 이벤트를 보강하고 발견 항목을 Security Command Center에 기록합니다. 다음 표에는 Google Workspace 위협, 관련 MITRE ATT&CK Framework 항목, 결과를 트리거하는 이벤트에 대한 세부정보가 포함되어 있습니다. 특정 필터를 사용하여 로그를 확인하고 모든 정보를 결합하여 Google Workspace 위협에 대응할 수도 있습니다.

`Initial Access: Disabled Password Leak`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

비밀번호 유출이 감지되어 구성원의 계정이 사용 중지되었습니다.

문제가 발생한 계정의 비밀번호를 재설정하고 회원에게 회사 계정에 강력하고 고유한 비밀번호를 사용하도록 권장합니다.

설명	작업
비밀번호 유출이 감지되어 구성원의 계정이 사용 중지되었습니다.	문제가 발생한 계정의 비밀번호를 재설정하고 회원에게 회사 계정에 강력하고 고유한 비밀번호를 사용하도록 권장합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` `ORGANIZATION_ID`를 조직 ID로 바꿉니다.
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1078/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID를 조직 ID로 바꿉니다.

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1078/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_password_leak

`Initial Access: Suspicious Login Blocked`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

구성원의 계정에 대한 의심스러운 로그인이 감지되어 차단되었습니다.

상대가 이 계정을 타겟팅할 수 있습니다. 사용자 계정이 안전한 비밀번호 및 다단계 인증을 위해 조직의 보안 가이드라인을 준수하는지 확인합니다.

설명	작업
구성원의 계정에 대한 의심스러운 로그인이 감지되어 차단되었습니다.	상대가 이 계정을 타겟팅할 수 있습니다. 사용자 계정이 안전한 비밀번호 및 다단계 인증을 위해 조직의 보안 가이드라인을 준수하는지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` `ORGANIZATION_ID`를 조직 ID로 바꿉니다.
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1078/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID를 조직 ID로 바꿉니다.

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1078/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

`Initial Access: Account Disabled Hijacked`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

의심스러운 활동으로 인해 회원의 계정이 정지되었습니다.

계정이 도용되었습니다. 계정 비밀번호를 재설정하고 사용자가 회사 계정에 강력하고 고유한 비밀번호를 만들도록 권장합니다.

설명	작업
의심스러운 활동으로 인해 회원의 계정이 정지되었습니다.	계정이 도용되었습니다. 계정 비밀번호를 재설정하고 사용자가 회사 계정에 강력하고 고유한 비밀번호를 만들도록 권장합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` `ORGANIZATION_ID`를 조직 ID로 바꿉니다.
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1078/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID를 조직 ID로 바꿉니다.

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1078/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#account_disabled_hijacked

`Impair Defenses: Two Step Verification Disabled`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

구성원이 2단계 인증을 사용 중지했습니다.

사용자가 2단계 인증을 사용 중지하려고 하는지 확인합니다. 조직에서 2단계 인증을 요구하는 경우 사용자가 즉시 2단계 인증을 사용 설정했는지 확인합니다.

설명	작업
구성원이 2단계 인증을 사용 중지했습니다.	사용자가 2단계 인증을 사용 중지하려고 하는지 확인합니다. 조직에서 2단계 인증을 요구하는 경우 사용자가 즉시 2단계 인증을 사용 설정했는지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` `ORGANIZATION_ID`를 조직 ID로 바꿉니다.
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1562/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID를 조직 ID로 바꿉니다.

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1562/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#2sv_disable

`Initial Access: Government Based Attack`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

정부 지원 해킹 공격자가 구성원 계정이나 컴퓨터를 도용하려고 했을 수 있습니다.

상대가 이 계정을 타겟팅할 수 있습니다. 사용자 계정이 안전한 비밀번호 및 다단계 인증을 위해 조직의 보안 가이드라인을 준수하는지 확인합니다.

설명	작업
정부 지원 해킹 공격자가 구성원 계정이나 컴퓨터를 도용하려고 했을 수 있습니다.	상대가 이 계정을 타겟팅할 수 있습니다. 사용자 계정이 안전한 비밀번호 및 다단계 인증을 위해 조직의 보안 가이드라인을 준수하는지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="login.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access` `ORGANIZATION_ID`를 조직 ID로 바꿉니다.
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1078/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="login.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

ORGANIZATION_ID를 조직 ID로 바꿉니다.

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1078/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#gov_attack_warning

`Persistence: SSO Enablement Toggle`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

관리자 계정의 SSO(싱글 사인온) 사용 설정이 사용 중지되었습니다.

조직의 SSO 설정이 변경되었습니다. 의도적으로 구성원이 수행한 변경인지 또는 조직에서 새로운 액세스 권한을 도입하기 위해 공격자가 구현했는지 확인합니다.

설명	작업
관리자 계정의 SSO(싱글 사인온) 사용 설정이 사용 중지되었습니다.	조직의 SSO 설정이 변경되었습니다. 의도적으로 구성원이 수행한 변경인지 또는 조직에서 새로운 액세스 권한을 도입하기 위해 공격자가 구현했는지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="admin.googleapis.com"` `protopayload.metadata.event.parameter.value=DOMAIN_NAME` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 다음을 바꿉니다. `DOMAIN_NAME`: 발견 항목에 나열된 `domainName` `ORGANIZATION_ID`: 조직 ID
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1098/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

다음을 바꿉니다.

DOMAIN_NAME: 발견 항목에 나열된 domainName
ORGANIZATION_ID: 조직 ID

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1098/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

`Persistence: SSO Settings Changed`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

관리자 계정의 SSO 설정이 변경되었습니다.

설명	작업
관리자 계정의 SSO 설정이 변경되었습니다.	조직의 SSO 설정이 변경되었습니다. 의도적으로 구성원이 수행한 변경인지 또는 조직에서 새로운 액세스 권한을 도입하기 위해 공격자가 구현했는지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="admin.googleapis.com"` `protopayload.metadata.event.parameter.value=DOMAIN_NAME` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` 다음을 바꿉니다. `DOMAIN_NAME`: 발견 항목에 나열된 `domainName` `ORGANIZATION_ID`: 조직 ID
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1098/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="admin.googleapis.com"

protopayload.metadata.event.parameter.value=DOMAIN_NAME

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

다음을 바꿉니다.

DOMAIN_NAME: 발견 항목에 나열된 domainName
ORGANIZATION_ID: 조직 ID

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1098/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#CHANGE_SSO_SETTINGS

`Impair Defenses: Strong Authentication Disabled`

프로젝트 수준에서 Security Command Center를 활성화하면 이 발견 항목을 사용할 수 없습니다.

설명 작업

조직의 2단계 인증이 사용 중지되었습니다.

조직에서 2단계 인증이 더 이상 필요하지 않습니다. 관리자가 의도적으로 변경한 정책인지 아니면 악의적 사용자가 계정을 더 쉽게 도용하도록 하는 것인지 확인합니다.

설명	작업
조직의 2단계 인증이 사용 중지되었습니다.	조직에서 2단계 인증이 더 이상 필요하지 않습니다. 관리자가 의도적으로 변경한 정책인지 아니면 악의적 사용자가 계정을 더 쉽게 도용하도록 하는 것인지 확인합니다.	다음 필터를 사용하여 로그를 확인합니다. `protopayload.resource.labels.service="admin.googleapis.com"` `logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity` `ORGANIZATION_ID`를 조직 ID로 바꿉니다.
이 발견 항목을 트리거하는 연구 이벤트: MITRE: https://attack.mitre.org/techniques/T1562/ 작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

다음 필터를 사용하여 로그를 확인합니다.

protopayload.resource.labels.service="admin.googleapis.com"

logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity

ORGANIZATION_ID를 조직 ID로 바꿉니다.

이 발견 항목을 트리거하는 연구 이벤트:

MITRE: https://attack.mitre.org/techniques/T1562/
작업공간 이벤트 세부정보: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-security-settings#ENFORCE_STRONG_AUTHENTICATION

Google Workspace 위협에 대응하기

Google Workspace의 발견 항목은 Security Command Center의 조직 수준 활성화에만 사용할 수 있습니다. 프로젝트 수준 활성화를 위해 Google Workspace 로그를 스캔할 수 없습니다.

Google Workspace 관리자는 서비스의 보안 도구를 사용하여 이러한 위협을 해결할 수 있습니다.

이러한 도구에는 알림, 보안 대시보드, 보안 권장사항이 포함되며 위협을 조사하고 해결하도록 도와줍니다.

Google Workspace 관리자가 아닌 경우 다음을 수행하세요.

계정에 액세스할 수 있으면 비밀번호를 변경하거나 재설정한 다음 2단계 인증을 사용 설정하세요.
Google Workspace 관리자 또는 회사의 Google Workspace 계정을 관리하는 팀에 문의하세요. 이러한 발견 항목을 사용하여 계정이 손상되었을 수 있음을 나타냅니다.

Cloud IDS 위협 감지

`Cloud IDS: THREAT_ID`

Cloud IDS 발견 항목은 위협을 감지하기 위해 Google Cloud 리소스와 주고받는 트래픽을 모니터링하는 보안 서비스인 Cloud IDS에 의해 생성됩니다. Cloud IDS에서 위협을 감지하면 소스 IP 주소, 대상 주소, 포트 번호와 같은 위협에 대한 정보를 Event Threat Detection으로 전송하고 위협 발견 항목을 생성합니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Cloud IDS: THREAT_ID 발견 항목을 엽니다.
발견 항목 세부정보의 요약 탭에서 다음 섹션에 나열된 값을 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로토콜: 사용된 네트워크 프로토콜
  - 이벤트 시간: 이벤트가 발생한 시간
  - 설명: 발견 항목에 대한 추가 정보
  - 심각도: 알림의 심각도
  - 목적지 IP: 네트워크 트래픽의 목적지 IP
  - 목적지 포트: 네트워크 트래픽의 목적지 포트
  - 소스 IP: 네트워크 트래픽의 소스 IP
  - 소스 포트: 네트워크 트래픽의 소스 포트
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 위협이 있는 네트워크가 포함된 프로젝트
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Cloud IDS Logging 항목의 링크 - 이 항목에는 Palo Alto Networks의 위협 Vault를 검색하는 데 필요한 정보가 있습니다.
- 감지 서비스
  - 발견 항목 카테고리 Cloud IDS 위협 이름
발견 항목의 전체 JSON을 보려면 JSON 탭을 클릭합니다.

2단계: 공격 및 대응 방법 찾기

발견 항목 세부정보를 검토한 후 위협 알림 조사에 대한 Cloud IDS 문서를 참조하여 적절한 대응책을 확인합니다.

발견 항목 세부정보에서 Cloud Logging URI 필드의 링크를 클릭하여 원래 로그 항목에서 감지된 이벤트에 대한 자세한 정보를 확인할 수 있습니다.

Container Threat Detection 대응

Container Threat Detection에 대한 자세한 내용은 Container Threat Detection 작동 방식을 참조하세요.

`Added Binary Executed`

원본 컨테이너 이미지에 포함되지 않은 바이너리가 실행되었습니다. 공격자는 일반적으로 초기 침해 후 익스플로잇 도구와 멀웨어를 설치합니다. 컨테이너를 변경할 수 없도록 하는 것은 중요한 권장사항입니다. 조직에서 이 권장사항을 따르지 않을 수 있으므로 심각도가 낮은 발견 항목입니다. 바이너리의 해시가 알려진 침해 지표(IoC)인 경우 상응하는 Execution: Added Malicious Binary Executed 발견 항목이 있습니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Added Binary Executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 추가된 바이너리의 절대 경로
  - 인수: 추가된 바이너리를 호출할 때 제공되는 인수
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
JSON을 클릭하고 다음 필드를 확인합니다.
- resource:
  - project_display_name: 클러스터가 포함된 프로젝트 이름
- sourceProperties:
  - Pod_Namespace: 포드의 Kubernetes 네임스페이스 이름
  - Pod_Name: GKE 포드의 이름
  - Container_Name: 영향을 받는 컨테이너의 이름
  - Container_Image_Uri: 배포 중인 컨테이너 이미지의 이름
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름
이 컨테이너에서 비슷한 시간에 발생한 다른 발견 항목을 식별합니다. 관련 발견 항목은 권장사항을 따르지 않은 것이 아니라 악의적인 활동이었음을 의미할 수 있습니다.

2단계: 클러스터 및 노드 검토하기

Google Cloud Console에서 Kubernetes 클러스터 페이지로 이동합니다.
Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.
Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스로 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화 를 클릭합니다.
다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
리전 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
다음을 바꿉니다.
- cluster_name: resource.labels.cluster_name에 나열된 클러스터
- location: resource.labels.location에 나열된 위치
- project_name: resource.project_display_name에 나열된 프로젝트 이름
다음을 실행하여 추가된 바이너리를 검색합니다.
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
local_file을 추가된 바이너리를 저장할 로컬 파일 경로로 바꿉니다.
다음을 실행하여 컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(인그레스 도구 전송, 기본 API)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

7단계: 대응 구현하기

바이너리가 컨테이너에 포함되도록 의도된 경우 바이너리가 포함된 컨테이너 이미지를 다시 빌드합니다. 이렇게 하면 컨테이너를 변경할 수 없게 됩니다.
그 외의 경우 침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Added Library Loaded`

원본 컨테이너 이미지에 포함되지 않은 라이브러리가 로드되었습니다. 공격자는 코드 실행 보호를 우회하고 악성 코드를 숨기기 위해 기존 프로그램에 악성 라이브러리를 로드할 수 있습니다. 컨테이너를 변경할 수 없도록 하는 것은 중요한 권장사항입니다. 조직에서 이 권장사항을 따르지 않을 수 있으므로 심각도가 낮은 발견 항목입니다. 바이너리의 해시가 알려진 침해 지표(IoC)인 경우 상응하는 Execution: Added Malicious Library Loaded 발견 항목이 있습니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Added Library Loaded 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 라이브러리를 로드한 프로세스 바이너리의 전체 경로
  - 라이브러리: 추가된 라이브러리에 대한 세부정보
  - 인수: 프로세스 바이너리를 호출할 때 제공되는 인수
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 클러스터의 전체 리소스 이름
JSON 탭을 클릭하고 다음 필드를 확인합니다.
- resource:
  - project_display_name: 애셋이 포함된 프로젝트 이름
- sourceProperties:
  - Pod_Namespace: 포드의 Kubernetes 네임스페이스 이름
  - Pod_Name: GKE 포드의 이름
  - Container_Name: 영향을 받는 컨테이너의 이름
  - Container_Image_Uri: 실행 중인 컨테이너 이미지의 이름
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름
이 컨테이너에서 비슷한 시간에 발생한 다른 발견 항목을 식별합니다. 관련 발견 항목은 권장사항을 따르지 않은 것이 아니라 악의적인 활동이었음을 의미할 수 있습니다.

2단계: 클러스터 및 노드 검토하기

Google Cloud Console에서 Kubernetes 클러스터 페이지로 이동합니다.
Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
resource.name에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.
Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스로 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화를 클릭합니다.

다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

리전 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

다음을 실행하여 추가된 라이브러리를 검색합니다.
```
  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
```
local_file을 추가된 라이브러리를 저장할 로컬 파일 경로로 바꿉니다.
다음을 실행하여 컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(인그레스 도구 전송, 공유 모듈)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

7단계: 대응 구현하기

라이브러리가 컨테이너에 포함되도록 의도된 경우 라이브러리가 포함된 컨테이너 이미지를 다시 빌드합니다. 이렇게 하면 컨테이너를 변경할 수 없게 됩니다.
그 외의 경우 침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Execution: Added Malicious Binary Executed`

원본 컨테이너 이미지에 포함되지 않은 악성 바이너리가 실행되었습니다. 공격자는 일반적으로 초기 침해 후 악용 도구와 멀웨어를 설치합니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Added Malicious Binary Executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 추가된 바이너리의 절대 경로
  - 인수: 추가된 바이너리를 호출할 때 제공되는 인수
  - 컨테이너: 영향을 받는 컨테이너의 이름
  - 컨테이너 URI: 배포 중인 컨테이너 이미지의 이름
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
JSON 탭을 클릭하고 다음 필드를 확인합니다.
- sourceProperties:
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름

2단계: 클러스터 및 노드 검토하기

Google Cloud Console에서 Kubernetes 클러스터 페이지로 이동합니다.
Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.
Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스로 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화 를 클릭합니다.
다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
리전 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
다음을 바꿉니다.
- cluster_name: resource.labels.cluster_name에 나열된 클러스터
- location: resource.labels.location에 나열된 위치
- project_name: resource.project_display_name에 나열된 프로젝트 이름
추가된 악성 바이너리를 검색합니다.
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
local_file을 추가된 악성 바이너리를 저장할 로컬 경로로 바꿉니다.
컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(인그레스 도구 전송, 기본 API)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.
VirusTotal 표시기에서 링크를 클릭하여 VirusTotal에서 악성으로 표시된 바이너리의 SHA-256 해시 값을 확인합니다. VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Execution: Added Malicious Library Loaded`

원본 컨테이너 이미지에 포함되지 않은 악성 라이브러리가 로드되었습니다. 공격자는 코드 실행 보호를 우회하고 악성 코드를 숨기기 위해 기존 프로그램에 악성 라이브러리를 로드할 수 있습니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Added Malicious Library Loaded 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 라이브러리를 로드한 프로세스 바이너리의 전체 경로
  - 라이브러리: 추가된 라이브러리에 대한 세부정보
  - 인수: 프로세스 바이너리를 호출할 때 제공되는 인수
  - 컨테이너: 영향을 받는 컨테이너의 이름
  - 컨테이너 URI: 배포 중인 컨테이너 이미지의 이름
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 클러스터의 전체 리소스 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
JSON 탭을 클릭하고 다음 필드를 확인합니다.
- sourceProperties:
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름

2단계: 클러스터 및 노드 검토하기

Google Cloud Console에서 Kubernetes 클러스터 페이지로 이동합니다.
Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.
Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스로 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화를 클릭합니다.

다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

리전 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

추가된 악성 라이브러리를 검색합니다.
```
  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
```
local_file을 추가된 악성 라이브러리를 저장할 로컬 경로로 바꿉니다.
컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(인그레스 도구 전송, 공유 모듈)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.
VirusTotal 표시기에서 링크를 클릭하여 VirusTotal에서 악성으로 표시된 라이브러리의 SHA-256 해시 값을 확인합니다. VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Execution: Built in Malicious Binary Executed`

다음을 충족하는 바이너리와 함께 실행된 바이너리:

원본 컨테이너 이미지에 포함됨
위협 인텔리전스를 기반으로 악성으로 식별됨

공격자는 컨테이너 이미지에 악성 바이너리가 삽입된 컨테이너 이미지 저장소 또는 생성 파이프라인을 제어할 수 있습니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Built in Malicious Binary Executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 기본 제공 바이너리의 절대 경로
  - 인수: 기본 제공 바이너리를 호출할 때 제공되는 인수
  - 컨테이너: 영향을 받는 컨테이너의 이름
  - 컨테이너 URI: 배포 중인 컨테이너 이미지의 이름
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
JSON을 클릭하고 다음 필드를 확인합니다.
- sourceProperties:
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름

2단계: 클러스터 및 노드 검토하기

Google Cloud Console에서 Kubernetes 클러스터 페이지로 이동합니다.
Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.
Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스로 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화 를 클릭합니다.
다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
리전 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
다음을 바꿉니다.
- cluster_name: resource.labels.cluster_name에 나열된 클러스터
- location: resource.labels.location에 나열된 위치
- project_name: resource.project_display_name에 나열된 프로젝트 이름
기본 제공 악성 바이너리를 검색합니다.
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
local_file을 기본 제공되는 tin 악성 바이너리를 저장할 로컬 경로로 바꿉니다.
컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(인그레스 도구 전송, 기본 API)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.
VirusTotal 표시기에서 링크를 클릭하여 VirusTotal에서 악성으로 표시된 바이너리의 SHA-256 해시 값을 확인합니다. VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Execution: Malicious Python executed`

머신러닝 모델에서 실행된 Python 코드를 악성으로 식별했습니다. 공격자는 Python을 사용하여 도구를 전송하고 바이너리 없이 명령어를 실행할 수 있습니다. 컨테이너를 변경할 수 없도록 하는 것은 중요한 권장사항입니다. 스크립트를 사용하여 도구를 전송하면 인그레스 도구 전송의 공격자 기법을 모방하여 원치 않는 감지를 할 수 있습니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Malicious Python executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 스크립트를 호출한 인터프리터에 대한 세부정보
  - 스크립트: 디스크에 있는 스크립트 이름의 절대 경로. 이 속성은 디스크에 작성된 스크립트에만 표시되며 리터럴 스크립트 실행에는 표시되지 않습니다(예: python3 -c).
  - 인수: 스크립트를 호출할 때 제공된 인수
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- finding:
  - processes:
  - script:
    - contents: 실행된 스크립트의 콘텐츠로, 성능상의 이유로 잘릴 수 있습니다. 조사에 도움이 될 수 있습니다
    - sha256: script.contents의 SHA-256 해시
- resource:
  - project_display_name: 애셋이 포함된 프로젝트 이름
- sourceProperties:
  - Pod_Namespace: 포드의 Kubernetes 네임스페이스 이름
  - Pod_Name: GKE 포드의 이름
  - Container_Name: 영향을 받는 컨테이너의 이름
  - Container_Image_Uri: 실행 중인 컨테이너 이미지의 이름
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름
이 컨테이너에서 비슷한 시간에 발생한 다른 발견 항목을 식별합니다. 예를 들어 스크립트가 바이너리를 삭제하는 경우 바이너리와 관련된 발견 항목을 확인합니다.

2단계: 클러스터 및 노드 검토하기

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.

Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 resource.name에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스를 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
resource.labels.cluster_name에 표시된 클러스터의 이름을 클릭합니다.
클러스터 페이지에서 연결을 클릭한 후 Cloud Shell에서 실행을 클릭합니다.

Cloud Shell이 터미널에서 클러스터에 대한 명령어를 시작하고 추가합니다.
Enter 키를 누르고 Cloud Shell 승인 대화상자가 나타나면 승인을 클릭합니다.
다음 명령어를 실행하여 컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MITRE ATT&CK 프레임워크 항목을 검토합니다. 명령 및 스크립트 해석, 인그레스 도구 전송
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

7단계: 대응 구현하기

Python에서 컨테이너에 의도된 변경사항을 적용한 경우 변경할 필요가 없도록 컨테이너 이미지를 다시 빌드합니다. 이렇게 하면 컨테이너를 immutable 됩니다.
그 외의 경우 침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Execution: Modified Malicious Binary Executed`

다음을 충족하는 바이너리와 함께 실행된 바이너리:

원본 컨테이너 이미지에 포함됨
컨테이너 런타임 중에 수정됨
위협 인텔리전스를 기반으로 악성으로 식별됨

공격자는 일반적으로 초기 침해 후 악용 도구와 멀웨어를 설치합니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Modified Malicious Binary Executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 수정된 바이너리의 절대 경로
  - 인수: 수정된 바이너리를 호출할 때 제공되는 인수
  - 컨테이너: 영향을 받는 컨테이너의 이름
  - 컨테이너 URI: 배포 중인 컨테이너 이미지의 이름
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
JSON을 클릭하고 다음 필드를 확인합니다.
- sourceProperties:
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름

2단계: 클러스터 및 노드 검토하기

Google Cloud Console에서 Kubernetes 클러스터 페이지로 이동합니다.
Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.
Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스로 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화 를 클릭합니다.
다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --zone location --project project_name
```
리전 클러스터의 경우:
```
  gcloud container clusters get-credentials cluster_name --region location --project project_name
```
다음을 바꿉니다.
- cluster_name: resource.labels.cluster_name에 나열된 클러스터
- location: resource.labels.location에 나열된 위치
- project_name: resource.project_display_name에 나열된 프로젝트 이름
수정된 악성 바이너리를 검색합니다.
```
  kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
```
local_file을 수정된 악성 바이너리를 저장할 로컬 경로로 바꿉니다.
컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(인그레스 도구 전송, 기본 API)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.
VirusTotal 표시기에서 링크를 클릭하여 VirusTotal에서 악성으로 표시된 바이너리의 SHA-256 해시 값을 확인합니다. VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Execution: Modified Malicious Library Loaded`

다음을 충족하는 라이브러리와 함께 로드된 라이브러리:

원본 컨테이너 이미지에 포함됨
컨테이너 런타임 중에 수정됨
위협 인텔리전스를 기반으로 악성으로 식별됨

공격자는 코드 실행 보호를 우회하고 악성 코드를 숨기기 위해 기존 프로그램에 악성 라이브러리를 로드할 수 있습니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Modified Malicious Library Loaded 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 라이브러리를 로드한 프로세스 바이너리의 전체 경로
  - 라이브러리: 수정된 라이브러리에 대한 세부정보
  - 인수: 프로세스 바이너리를 호출할 때 제공되는 인수
  - 컨테이너: 영향을 받는 컨테이너의 이름
  - 컨테이너 URI: 배포 중인 컨테이너 이미지의 이름
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 클러스터의 전체 리소스 이름
- 특히 다음 필드를 포함하는 관련 링크:
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
JSON 탭을 클릭하고 다음 필드를 확인합니다.
- sourceProperties:
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름

2단계: 클러스터 및 노드 검토하기

Google Cloud Console에서 Kubernetes 클러스터 페이지로 이동합니다.
Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
resource.name에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.
Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스로 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화를 클릭합니다.

다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

리전 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

수정된 악성 라이브러리를 검색합니다.
```
  kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
```
local_file을 수정된 악성 라이브러리를 저장할 로컬 경로로 바꿉니다.
컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(인그레스 도구 전송, 공유 모듈)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.
VirusTotal 표시기에서 링크를 클릭하여 VirusTotal에서 악성으로 표시된 라이브러리의 SHA-256 해시 값을 확인합니다. VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Malicious Script Executed`

머신러닝 모델이 실행된 Bash 코드를 악성으로 식별했습니다. 공격자는 Bash를 사용하여 도구를 전송하고 바이너리 없이 명령어를 실행할 수 있습니다. 컨테이너를 변경할 수 없도록 하는 것은 중요한 권장사항입니다. 스크립트를 사용하여 도구를 전송하면 인그레스 도구 전송의 공격자 기법을 모방하여 원치 않는 감지를 할 수 있습니다.

이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Malicious Script Executed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 스크립트를 호출한 인터프리터에 대한 세부정보
  - 스크립트: 디스크에 있는 스크립트 이름의 절대 경로. 이 속성은 디스크에 작성된 스크립트에만 표시되며 리터럴 스크립트 실행에는 표시되지 않습니다(예: bash -c).
  - 인수: 스크립트를 호출할 때 제공된 인수
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 프로젝트 번호, 위치, 클러스터 이름을 포함한 클러스터의 전체 리소스 이름
발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
JSON에서 다음 필드를 확인합니다.
- finding:
  - processes:
  - script:
    - contents: 실행된 스크립트의 콘텐츠로, 성능상의 이유로 잘릴 수 있습니다. 조사에 도움이 될 수 있습니다
    - sha256: script.contents의 SHA-256 해시
- resource:
  - project_display_name: 애셋이 포함된 프로젝트 이름
- sourceProperties:
  - Pod_Namespace: 포드의 Kubernetes 네임스페이스 이름
  - Pod_Name: GKE 포드의 이름
  - Container_Name: 영향을 받는 컨테이너의 이름
  - Container_Image_Uri: 실행 중인 컨테이너 이미지의 이름
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름
이 컨테이너에서 비슷한 시간에 발생한 다른 발견 항목을 식별합니다. 예를 들어 스크립트가 바이너리를 삭제하는 경우 바이너리와 관련된 발견 항목을 확인합니다.

2단계: 클러스터 및 노드 검토하기

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.

Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 resource.name에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스를 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
resource.labels.cluster_name에 표시된 클러스터의 이름을 클릭합니다.
클러스터 페이지에서 연결을 클릭한 후 Cloud Shell에서 실행을 클릭합니다.

Cloud Shell이 터미널에서 클러스터에 대한 명령어를 시작하고 추가합니다.
Enter 키를 누르고 Cloud Shell 승인 대화상자가 나타나면 승인을 클릭합니다.
다음 명령어를 실행하여 컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(명령어 및 스크립팅 인터프리터, 인그레스 도구 전송)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

7단계: 대응 구현하기

스크립트에서 컨테이너에 의도된 변경사항을 적용한 경우 변경할 필요가 없도록 컨테이너 이미지를 다시 빌드합니다. 이렇게 하면 컨테이너를 변경할 수 없게 됩니다.
그 외의 경우 침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Malicious URL Observed`

Container Threat Detection이 실행 가능한 프로세스의 인수 목록에서 악의적인 URL을 관찰했습니다. 공격자가 악의적인 URL을 통해 멀웨어 또는 악성 라이브러리를 로드할 수 있습니다.

이 발견 항목에 대응하려면 다음 단계를 수행합니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Malicious URL Observed 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - URI: 관찰된 악성 URI입니다.
  - 추가된 바이너리: 악성 URL이 포함된 인수가 수신된 프로세스 바이너리의 전체 경로입니다.
  - 인수: 프로세스 바이너리를 호출할 때 제공되는 인수
  - 환경 변수: 프로세스 바이너리가 호출되었을 때 적용된 환경 변수입니다.
  - 컨테이너: 컨테이너 이름입니다.
  - Kubernetes 포드: 포드 이름 및 네임스페이스입니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 영향을 받는 리소스의 이름
  - 리소스 전체 이름: 클러스터의 전체 리소스 이름 전체 리소스 이름에는 다음 정보가 포함됩니다.
    - 클러스터를 포함하는 프로젝트: projects/PROJECT_ID
    - 클러스터가 있는 위치: zone/ZONE 또는 locations/LOCATION
    - 클러스터의 이름: projects/CLUSTER_NAME
JSON 탭의 sourceProperties 속성에서 VM_Instance_Name 속성 값을 확인합니다.

2단계: 클러스터 및 노드 검토하기

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 리소스 전체 이름(resource.name)에 표시되는 프로젝트를 선택합니다. 프로젝트 이름은 전체 리소스 이름에서 /projects/ 다음에 표시됩니다.
발견 항목 요약의 리소스 표시 이름(resource.display_name)에서 확인한 클러스터 이름을 클릭합니다. 클러스터 페이지가 열립니다.
**클러스터 세부정보 페이지의 메타데이터 섹션에서 위협 해결에 도움이 될 수 있는 사용자 정의 정보(예: 클러스터 소유자 식별)를 확인합니다.
노드 탭을 클릭합니다.
나열된 노드에서 앞의 발견 항목 JSON에서 확인한 VM_Instance_Name 값과 일치하는 노드를 선택합니다.
주석 섹션의 노드 세부정보 페이지의 세부정보 탭에서 container.googleapis.com/instance_id 주석 값을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.

Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 발견 항목 요약의 리소스 전체 이름(resource.name)에서 기록한 프로젝트를 선택합니다.
시스템 워크로드 표시를 클릭합니다.
발견 항목 요약의 리소스 전체 이름(resource.name)에 기록한 클러스터 이름과 필요한 경우 기록한 포드 네임스페이스(kubernetes.pods.ns)를 기준으로 워크로드 목록을 필터링합니다.
앞의 발견 항목 JSON에서 확인한 VM_Instance_Name 속성 값과 일치하는 워크로드 이름을 클릭합니다. 포드 세부정보 페이지가 열립니다.
포드 세부정보 페이지에서 위협 해결에 도움이 되는 포드에 대한 모든 정보를 기록합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 리소스 전체 이름(resource.name)에 표시되는 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 포드(kubernetes.pods.name)의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="PROJECT_ID"
  - resource.labels.location="LOCATION"
  - resource.labels.cluster_name="CLUSTER_NAME"
  - resource.labels.namespace_name="NAMESPACE_NAME"
  - resource.labels.pod_name="POD_NAME"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/PROJECT_NAME/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="PROJECT_ID"
  - resource.labels.location="LOCATION_OR_ZONE"
  - resource.labels.cluster_name="CLUSTER_NAME/var>"
  - POD_NAME
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="INSTANCE_ID"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
resource.labels.cluster_name에 표시된 클러스터의 이름을 클릭합니다.
클러스터 페이지에서 연결을 클릭한 후 Cloud Shell에서 실행을 클릭합니다.

Cloud Shell이 터미널에서 클러스터에 대한 명령어를 시작하고 추가합니다.
Enter 키를 누르고 Cloud Shell 승인 대화상자가 나타나면 승인을 클릭합니다.
다음 명령어를 실행하여 컨테이너 환경에 연결합니다.
```
  kubectl exec --namespace=POD_NAMESPACE -ti POD_NAME -c CONTAINER_NAME -- /bin/sh
```
CONTAINER_NAME을 이전 발견 항목 요약에서 확인한 컨테이너 이름으로 바꿉니다.

이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

세이프 브라우징 사이트 상태를 확인하여 URL이 악성으로 분류된 이유를 자세히 알아봅니다.
이 발견 항목 유형 인그레스 도구 전송의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Reverse Shell`

원격으로 연결된 소켓에 대한 스트림 리디렉션으로 프로세스가 시작되었습니다. 네트워크에 연결된 셸을 생성하면 공격자가 제한된 초기 침해 후에 임의의 작업을 수행할 수 있습니다. 이 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Reverse Shell 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 프로그램 바이너리: 원격 소켓으로의 스트림 리디렉션으로 시작하는 프로세스의 절대 경로
  - 인수: 프로세스 바이너리를 호출할 때 제공되는 인수
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 클러스터의 전체 리소스 이름
  - 프로젝트 전체 이름:
- 발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
- JSON에서 다음 필드를 확인합니다.
- resource:
  - project_display_name: 애셋이 포함된 프로젝트 이름
- sourceProperties:
  - Pod_Namespace: 포드의 Kubernetes 네임스페이스 이름
  - Pod_Name: GKE 포드의 이름
  - Container_Name: 영향을 받는 컨테이너의 이름
  - VM_Instance_Name: 포드가 실행된 GKE 노드의 이름
  - Reverse_Shell_Stdin_Redirection_Dst_Ip: 연결의 원격 IP 주소
  - Reverse_Shell_Stdin_Redirection_Dst_Port: 원격 포트
  - Reverse_Shell_Stdin_Redirection_Src_Ip: 연결의 로컬 IP 주소
  - Reverse_Shell_Stdin_Redirection_Src_Port: 로컬 포트
  - Container_Image_Uri: 실행 중인 컨테이너 이미지의 이름

2단계: 클러스터 및 노드 검토하기

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
resource.name에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.

Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
필요한 경우 resource.name에 나열된 클러스터와 Pod_Namespace에 나열된 포드 네임스페이스를 필터링합니다.
Pod_Name에 나열된 포드를 선택합니다. 포드 및 해당 소유자의 모든 메타데이터를 확인합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화를 클릭합니다.

다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

리전 클러스터의 경우:

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

다음을 실행하여 컨테이너 환경 내에서 셸을 시작합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

컨테이너에서 실행되는 모든 프로세스를 보려면 컨테이너 셸에서 다음 명령어를 실행합니다.
```
  ps axjf
```
이 명령어를 실행하려면 컨테이너에 /bin/ps가 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형(명령어 및 스크립팅 인터프리터, 인그레스 도구 전송)의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

`Unexpected Child Shell`

Container Threat Detection에서 예기치 않게 하위 셸 프로세스가 생성된 프로세스를 관찰했습니다. 이 이벤트는 공격자가 셸 명령어 및 스크립트를 악용하려고 시도 중임을 나타낼 수 있습니다.

이 발견 항목에 대응하려면 다음 단계를 수행합니다.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Unexpected Child Shell 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 상위 프로세스: 예기치 않게 하위 셸 프로세스가 생성된 프로세스입니다.
  - 하위 프로세스: 하위 셸 프로세스
  - 인수: 하위 셸 프로세스 바이너리에 제공된 인수
  - 환경 변수: 하위 셸 프로세스 바이너리의 환경 변수
  - 컨테이너: 컨테이너 이름입니다.
  - 컨테이너 URI: 컨테이너의 이미지 URI
  - Kubernetes 포드: 포드 이름 및 네임스페이스입니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 표시 이름: 영향을 받는 리소스의 이름
  - 리소스 전체 이름: 클러스터의 전체 리소스 이름 전체 리소스 이름에는 다음 정보가 포함됩니다.
    - 클러스터를 포함하는 프로젝트: projects/PROJECT_ID
    - 클러스터가 있는 위치: zone/ZONE 또는 locations/LOCATION
    - 클러스터의 이름: projects/CLUSTER_NAME
JSON 탭을 클릭하고 다음 필드를 확인합니다.

+processes: 발견 항목과 관련된 모든 프로세스가 포함된 배열. 이 배열에는 하위 셸 프로세스와 상위 프로세스가 포함됩니다. +resource: +project_display_name: 애셋이 포함된 프로젝트의 이름 +sourceProperties: +VM_Instance_Name: 포드가 실행된 GKE 노드의 이름입니다.

2단계: 클러스터 및 노드 검토하기

Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
resource.name에 나열된 클러스터를 선택합니다. 클러스터 및 해당 소유자의 모든 메타데이터를 확인합니다.
노드 탭을 클릭합니다. VM_Instance_Name에 나열된 노드를 선택합니다.
세부정보 탭을 클릭하고 container.googleapis.com/instance_id 주석을 확인합니다.

3단계: 포드 검토하기

Google Cloud 콘솔에서 Kubernetes 워크로드 페이지로 이동합니다.

Kubernetes 워크로드로 이동
필요한 경우 Google Cloud 콘솔 툴바에서 발견 항목 요약의 리소스 전체 이름(resource.name)에서 기록한 프로젝트를 선택합니다.
시스템 워크로드 표시를 클릭합니다.
발견 항목 요약의 리소스 전체 이름(resource.name)에 기록한 클러스터 이름과 필요한 경우 기록한 포드 네임스페이스(kubernetes.pods.ns)를 기준으로 워크로드 목록을 필터링합니다.
앞의 발견 항목 JSON에서 확인한 VM_Instance_Name 속성 값과 일치하는 워크로드 이름을 클릭합니다. 포드 세부정보 페이지가 열립니다.
포드 세부정보 페이지에서 위협 해결에 도움이 되는 포드에 대한 모든 정보를 기록합니다.

4단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
기간 선택을 원하는 기간으로 설정합니다.
로드되는 페이지에서 다음을 수행합니다.
1. 다음 필터를 사용하여 Pod_Name의 포드 로그를 찾습니다.
  - resource.type="k8s_container"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - resource.labels.namespace_name="Pod_Namespace"
  - resource.labels.pod_name="Pod_Name"
2. 다음 필터를 사용하여 클러스터 감사 로그를 찾습니다.
  - logName="projects/resource.project_display_name/logs/cloudaudit.googleapis.com%2Factivity"
  - resource.type="k8s_cluster"
  - resource.labels.project_id="resource.project_display_name"
  - resource.labels.location="location"
  - resource.labels.cluster_name="cluster_name"
  - Pod_Name
3. 다음 필터를 사용하여 GKE 노드 콘솔 로그를 찾습니다.
  - resource.type="gce_instance"
  - resource.labels.instance_id="instance_id"

5단계: 실행 중인 컨테이너 조사하기

컨테이너가 계속 실행 중이면 컨테이너 환경을 직접 조사할 수 있습니다.

Google Cloud 콘솔로 이동합니다.

Google Cloud 콘솔 열기
Google Cloud 콘솔 툴바에서 resource.project_display_name에 나열된 프로젝트를 선택합니다.
Cloud Shell 활성화를 클릭합니다.

다음 명령어를 실행하여 클러스터의 GKE 사용자 인증 정보를 가져옵니다.

영역 클러스터의 경우 다음을 실행합니다.

  gcloud container clusters get-credentials cluster_name --zone location --project resource.project_display_name

리전 클러스터의 경우 다음을 실행합니다.

  gcloud container clusters get-credentials cluster_name --region location --project resource.project_display_name

컨테이너 환경 내에서 셸을 실행하려면 다음을 실행합니다.
```
  kubectl exec --namespace=Pod_Namespace -ti Pod_Name -c Container_Name -- /bin/sh
```
이 명령어를 실행하려면 컨테이너의 셸이 /bin/sh에 설치되어 있어야 합니다.

컨테이너에서 실행되는 모든 프로세스를 보려면 컨테이너 셸에서 다음 명령어를 실행합니다.
```
  ps axjf
```
이 명령어를 실행하려면 컨테이너에 /bin/ps가 설치되어 있어야 합니다.

6단계: 공격 및 대응 방법 조사하기

이 발견 항목 유형의 MIT ATT&CK 프레임워크 항목을 검토합니다. 명령어 및 스크립트 해석: Unix 셸
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

7단계: 대응 구현하기

침해된 컨테이너가 있는 프로젝트 소유자에게 문의하세요.
침해된 컨테이너를 중지 또는 삭제하고 새 컨테이너로 바꿉니다.

VM Threat Detection 응답

VM Threat Detection에 대한 자세한 내용은 VM Threat Detection 개요를 참조하세요.

`Execution: Cryptocurrency Mining Hash Match`

VM Threat Detection에서 실행 중인 프로그램의 메모리 해시를 알려진 암호화폐 채굴 소프트웨어의 메모리 해시와 일치시켜 암호화폐 채굴 활동을 감지했습니다.

이러한 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Cryptocurrency Mining Hash Match 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - 바이너리 계열: 감지된 암호화폐 애플리케이션
  - 프로그램 바이너리: 프로세스의 절대 경로
  - 인수: 프로세스 바이너리를 호출할 때 제공되는 인수
  - 프로세스 이름: 감지된 서명 일치와 연결된 VM 인스턴스에서 실행 중인 프로세스의 이름
  VM Threat Detection은 주요 Linux 배포의 커널 빌드를 인식할 수 있습니다. 영향을 받는 VM의 커널 빌드를 인식할 수 있는 경우 애플리케이션의 프로세스 세부정보를 식별하고 발견 항목의 processes 필드를 채울 수 있습니다. VM Threat Detection에서 커널을 인식할 수 없는 경우(예: 커널이 커스텀 빌드된 경우) 발견 항목의 processes 필드가 채워지지 않습니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받은 VM 인스턴스의 전체 리소스 이름(해당 인스턴스가 포함된 프로젝트의 ID 등)
이 발견 항목의 전체 JSON을 보려면 발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
- indicator
  - signatures:
    - memory_hash_signature: 메모리 페이지 해시에 해당하는 서명
    - detections
      - binary: 암호화폐 애플리케이션의 바이너리 이름(예: linux--x86-64_ethminer_0.19.0_alpha.0_cuda10.0)
      - percent_pages_matched: 페이지 해시 데이터베이스의 알려진 암호화폐 애플리케이션 페이지와 일치하는 메모리의 페이지 비율

2단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
Google Cloud 콘솔 툴바에서 발견 항목 세부정보의 요약 탭의 리소스 전체 이름 행에 지정된 대로 VM 인스턴스를 포함하는 프로젝트를 선택합니다.
로그에서 영향을 받는 VM 인스턴스에 침입이 있는지 확인합니다. 예를 들어 의심스러운 활동 또는 알 수 없는 활동과 사용자 인증 정보 침해의 징후가 있는지 확인합니다.

3단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.

대시보드로 이동
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 지정된 프로젝트를 선택합니다.
리소스 카드로 이동하여 Compute Engine을 클릭합니다.
리소스 전체 이름에 식별된 프로젝트와 일치하는 VM 인스턴스를 클릭합니다. 네트워크 및 액세스 설정을 포함한 인스턴스 세부정보를 검토합니다.

4단계: 공격 및 대응 방법 조사하기

실행의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

감지 및 삭제를 지원하려면 엔드포인트 감지 및 응답 솔루션을 이용하세요.

VM 소유자에게 문의하세요.
애플리케이션이 채굴 애플리케이션인지 확인합니다.
- 감지된 애플리케이션의 프로세스 이름 및 바이너리 경로를 사용할 수 있으면 발견 항목 세부정보의 요약 탭에서 프로그램 바이너리, 인수, 프로세스 이름 행에 있는 값을 조사에 고려하세요.
- 프로세스 세부정보를 확인할 수 없다면 메모리 해시 서명의 바이너리 이름이 단서를 제공할 수 있는지 확인합니다. linux-x86-64_xmrig_2.14.1이라는 바이너리를 살펴보겠습니다. grep 명령어를 사용하면 스토리지에서 주목할 만한 파일을 검색할 수 있습니다. 검색 패턴에서 바이너리 이름의 의미 있는 부분을 사용합니다. 이 경우에는 xmrig입니다. 검색결과를 검토합니다.
- 실행 중인 프로세스, 특히 CPU 사용량이 많은 프로세스를 검사하여 알 수 없는 프로세스가 있는지 확인합니다. 연결된 애플리케이션이 마이너 애플리케이션인지 확인합니다.
- 스토리지의 파일에서 마이닝 애플리케이션이 사용하는 일반적인 문자열(예: btc.com, ethminer, xmrig, cpuminer, randomx)을 검색합니다. 검색할 수 있는 문자열의 추가 예시는 소프트웨어 이름 및 YARA 규칙과 나열된 각 소프트웨어에 대한 관련 문서를 참조하세요.
애플리케이션이 마이너 애플리케이션이며 프로세스가 계속 실행 중이면 프로세스를 종료합니다. VM 스토리지에서 애플리케이션의 실행 가능한 바이너리를 찾고 삭제합니다.
필요한 경우 침해된 인스턴스를 중지하고 새 인스턴스로 바꿉니다.

`Execution: Cryptocurrency Mining YARA Rule`

VM Threat Detection은 암호화폐 채굴 소프트웨어에서 사용하는 것으로 알려진 작업 증명 상수와 같은 메모리 패턴을 일치시켜 암호화폐 채굴 활동을 감지했습니다.

이러한 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Execution: Cryptocurrency Mining YARA Rule 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - YARA 규칙 이름: YARA 감지기에 트리거된 규칙
  - 프로그램 바이너리: 프로세스의 절대 경로
  - 인수: 프로세스 바이너리를 호출할 때 제공되는 인수
  - 프로세스 이름: 감지된 서명 일치와 연결된 VM 인스턴스에서 실행 중인 프로세스의 이름
  VM Threat Detection은 주요 Linux 배포의 커널 빌드를 인식할 수 있습니다. 영향을 받는 VM의 커널 빌드를 인식할 수 있는 경우 애플리케이션의 프로세스 세부정보를 식별하고 발견 항목의 processes 필드를 채울 수 있습니다. VM Threat Detection에서 커널을 인식할 수 없는 경우(예: 커널이 커스텀 빌드된 경우) 발견 항목의 processes 필드가 채워지지 않습니다.
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받은 VM 인스턴스의 전체 리소스 이름(해당 인스턴스가 포함된 프로젝트의 ID 등)
- 특히 다음 필드를 포함하는 관련 링크:
  - Cloud Logging URI: Logging 항목의 링크
  - MITRE ATT&CK 메서드: MITRE ATT&CK 문서의 링크
  - 관련 발견 항목: 모든 관련 발견 항목의 링크
  - VirusTotal 표시기: VirusTotal 분석 페이지 링크
  - Chronicle: Google SecOps에 대한 링크입니다.
이 발견 항목의 전체 JSON을 보려면 발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.

2단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
Google Cloud 콘솔 툴바에서 발견 항목 세부정보의 요약 탭의 리소스 전체 이름 행에 지정된 대로 VM 인스턴스를 포함하는 프로젝트를 선택합니다.
로그에서 영향을 받는 VM 인스턴스에 침입이 있는지 확인합니다. 예를 들어 의심스러운 활동 또는 알 수 없는 활동과 사용자 인증 정보 침해의 징후가 있는지 확인합니다.

3단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.

대시보드로 이동
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 리소스 이름에 지정된 프로젝트를 선택합니다.
리소스 카드로 이동하여 Compute Engine을 클릭합니다.
resourceName와 일치하는 VM 인스턴스를 클릭합니다. 네트워크 및 액세스 설정을 포함한 인스턴스 세부정보를 검토합니다.

4단계: 공격 및 대응 방법 조사하기

실행의 MITRE ATT&CK 프레임워크 항목을 검토합니다.
대응 계획을 개발하려면 조사 결과를 MITRE 연구와 결합합니다.

5단계: 대응 구현하기

감지 및 삭제를 지원하려면 엔드포인트 감지 및 응답 솔루션을 이용하세요.

VM 소유자에게 문의하세요.
애플리케이션이 채굴 애플리케이션인지 확인합니다.
- 감지된 애플리케이션의 프로세스 이름 및 바이너리 경로를 사용할 수 있으면 발견 항목 세부정보의 요약 탭에서 프로그램 바이너리, 인수, 프로세스 이름 행에 있는 값을 조사에 고려하세요.
- 실행 중인 프로세스, 특히 CPU 사용량이 많은 프로세스를 검사하여 알 수 없는 프로세스가 있는지 확인합니다. 연결된 애플리케이션이 마이너 애플리케이션인지 확인합니다.
- 스토리지의 파일에서 마이닝 애플리케이션이 사용하는 일반적인 문자열(예: btc.com, ethminer, xmrig, cpuminer, randomx)을 검색합니다. 검색할 수 있는 문자열의 추가 예시는 소프트웨어 이름 및 YARA 규칙과 나열된 각 소프트웨어에 대한 관련 문서를 참조하세요.
애플리케이션이 마이너 애플리케이션이며 프로세스가 계속 실행 중이면 프로세스를 종료합니다. VM 스토리지에서 애플리케이션의 실행 가능한 바이너리를 찾고 삭제합니다.
필요한 경우 침해된 인스턴스를 중지하고 새 인스턴스로 바꿉니다.

`Execution: cryptocurrency mining combined detection`

VM 위협 감지로 단일 일자 내에 단일 소스로부터 여러 카테고리의 발견 항목이 감지되었습니다. 단일 애플리케이션이 Execution: Cryptocurrency Mining YARA Rule 및 Execution: Cryptocurrency Mining Hash Match findings를 동시에 트리거할 수 있습니다.

조합된 발견 항목에 대응하려면 Execution: Cryptocurrency Mining YARA Rule 및 Execution: Cryptocurrency Mining Hash Match findings 모두 다음 응답 안내를 따르세요.

`Malware: Malicious file on disk (YARA)`

VM Threat Detection에서 VM의 영구 디스크에서 알려진 멀웨어 서명을 검사하여 잠재적 악성 파일을 감지했습니다.

이러한 발견 항목에 대응하려면 다음을 수행하세요.

1단계: 발견 항목 세부정보 검토하기

발견 항목 검토의 지시에 따라 Malware: Malicious file on disk (YARA) 발견 항목을 엽니다. 발견 항목의 세부정보 패널의 요약 탭이 열립니다.
요약 탭에서 다음 섹션의 정보를 검토합니다.
- 특히 다음 필드를 포함하는 감지된 항목:
  - YARA 규칙 이름: 일치하는 YARA 규칙
  - 파일: 감지된 잠재적 악성 파일의 파티션 UUID 및 상대 경로
- 특히 다음 필드를 포함하는 영향을 받는 리소스:
  - 리소스 전체 이름: 영향을 받은 VM 인스턴스의 전체 리소스 이름(해당 인스턴스가 포함된 프로젝트의 ID 등)
이 발견 항목의 전체 JSON을 보려면 발견 항목의 세부정보 보기에서 JSON 탭을 클릭합니다.
JSON에서는 다음 필드를 확인합니다.
- indicator
  - signatures:
    - yaraRuleSignature: 일치하는 YARA 규칙에 해당하는 서명

2단계: 로그 확인하기

Google Cloud 콘솔에서 로그 탐색기로 이동합니다.

로그 탐색기로 이동
Google Cloud 콘솔 툴바에서 발견 항목 세부정보의 요약 탭의 리소스 전체 이름 행에 지정된 대로 VM 인스턴스를 포함하는 프로젝트를 선택합니다.
로그에서 영향을 받는 VM 인스턴스에 침입이 있는지 확인합니다. 예를 들어 의심스러운 활동 또는 알 수 없는 활동과 사용자 인증 정보 침해의 징후가 있는지 확인합니다.

3단계: 권한 및 설정 검토하기

Google Cloud 콘솔에서 대시보드 페이지로 이동합니다.

대시보드로 이동
발견 항목 세부정보의 요약 탭에서 리소스 전체 이름 행에 나열된 리소스 이름에 지정된 프로젝트를 선택합니다.
리소스 카드로 이동하여 Compute Engine을 클릭합니다.
resourceName와 일치하는 VM 인스턴스를 클릭합니다. 네트워크 및 액세스 설정을 포함한 인스턴스 세부정보를 검토합니다.

4단계: 공격 및 대응 방법 조사하기

VirusTotal에서 악성으로 표시된 파일의 SHA-256 해시 값을 확인합니다. VirusTotal은 Alphabet 소유 서비스로 잠재적 악성 파일, URL, 도메인 및 IP 주소에 관한 컨텍스트를 제공합니다.

5단계: 대응 구현하기

VM 소유자에게 문의하세요.
필요한 경우 잠재적 악성 파일을 찾아 삭제합니다. 파일의 파티션 UUID 및 상대 경로를 확인하려면 발견 항목 세부정보의 요약 탭에 있는 파일 필드를 참조하세요. 감지 및 삭제를 지원하려면 엔드포인트 감지 및 응답 솔루션을 이용하세요.
필요한 경우 침해된 인스턴스를 중지하고 새 인스턴스로 바꿉니다.

참고: Security Command Center Enterprise 등급을 사용하면 위협 대응 플레이북을 통해 이 작업을 수행할 수도 있습니다.
포렌식 분석을 위해 가상 머신과 영구 디스크를 백업하는 것이 좋습니다. 자세한 내용은 Compute Engine 문서에서 데이터 보호 옵션을 참조하세요.
추가 조사를 위해 Mandiant와 같은 이슈 대응 서비스를 사용하는 것이 좋습니다.

위협 문제 해결

Event Threat Detection 및 Container Threat Detection 발견 항목에 대한 문제 해결은 Security Command Center에서 식별된 잘못된 구성 및 취약점을 수정하는 것만큼 간단하지 않습니다.

잘못된 구성 및 규정 준수 위반은 악용될 수 있는 리소스의 약점을 식별합니다. 일반적으로 잘못된 구성에는 방화벽 사용 설정 또는 암호화 키 순환과 같이 알려진 문제들이 쉽게 구현되어 있습니다.

위협은 동적이며 하나 이상의 리소스에서 활성 상태로 악용될 수 있다는 점에서 취약점과 다릅니다. 취약점 공격에 성공하는 데 사용된 정확한 방법이 알려지지 않았을 수 있으므로 문제 해결 권장사항은 리소스 보호에 효과적이지 않을 수 있습니다.

예를 들어 Added Binary Executed 발견 항목은 승인되지 않은 바이너리가 컨테이너에서 실행되었음을 나타냅니다. 기본 문제 해결 권장사항으로 컨테이너를 격리하고 바이너리를 삭제하도록 권할 수 있지만 공격자가 바이너리를 실행할 수 있는 근본 원인을 해결하지 못할 수도 있습니다. 취약점 공격을 해결하기 위해 컨테이너 이미지가 어떻게 손상되었는지 알아내야 합니다. 파일이 잘못 구성된 포트를 통해 추가되었는지 또는 다른 방법으로 추가되었는지 확인하려면 철저한 조사가 필요합니다. 시스템에 대한 전문가 수준의 지식이 있는 분석가가 약점을 검토해야 할 수 있습니다.

악의적인 행위자는 다양한 기법을 사용하여 리소스를 공격하므로 특정 보안 공격에 대한 수정사항을 적용할 경우 다른 변형 공격에는 효과가 없을 수 있습니다. 예를 들어 Brute Force: SSH 발견 항목에 대한 대응으로 일부 사용자 계정의 권한 수준을 낮춰 리소스에 대한 액세스를 제한할 수 있습니다. 그러나 취약한 비밀번호는 여전히 공격 경로를 제공할 수 있습니다.

공격 벡터가 넓으면 모든 상황에서 작동하는 해결 단계를 제공하기가 어렵습니다. 클라우드 보안 계획에서 Security Command Center의 역할은 거의 실시간으로 영향을 받은 리소스를 식별하고, 사용자가 겪는 위협을 알려주고, 조사에 도움이 되는 증거와 컨텍스트를 제공하는 것입니다. 하지만 보안 담당자는 Security Command Center 발견 항목에 있는 광범위한 정보를 사용하여 문제를 해결하고 향후 공격에 대비하여 리소스를 보호할 수 있는 최적의 방법을 결정해야 합니다.

다음 단계

서비스 및 이 서비스가 감지하는 위협에 대한 자세한 내용은 Event Threat Detection 개요를 참조하세요.
서비스 작동 방식은 Container Threat Detection 개요를 참조하세요.
서비스 및 이 서비스가 감지하는 위협에 대한 자세한 내용은 VM Threat Detection 개요를 참조하세요.