Security Health Analytics 발견 항목 문제 해결

이 페이지에서는 Security Command Center를 사용하여 Security Health Analytics 발견 항목을 해결하는 데 필요한 참조 가이드 및 기술 목록을 제공합니다.

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

Security Health Analytics 문제 해결

이 섹션에는 모든 Security Health Analytics 발견 항목에 대한 해결 안내가 포함되어 있습니다.

해결 후 발견 항목 비활성화

취약점 또는 잘못된 구성 발견 항목이 해결되면 Security Health Analytics는 다음 번에 발견 항목을 스캔할 때 발견 항목 상태를 INACTIVE로 자동으로 설정합니다. Security Health Analytics가 해결된 발견 항목을 INACTIVE로 설정하는 데 걸리는 시간은 발견 항목이 수정되는 시점 및 발견 항목을 감지하는 스캔 일정에 따라 다릅니다.

또한 Security Health Analytics는 스캔에서 발견 항목의 영향을 받는 리소스가 삭제된 것을 감지할 때 발견 항목의 상태를 INACTIVE로 설정합니다. Security Health Analytics에서 리소스 삭제를 감지할 때까지 기다리는 동안 삭제된 리소스의 발견 항목을 디스플레이에서 삭제하려면 발견 항목을 숨길 수 있습니다. 발견 항목을 숨기려면 Security Command Center에서 발견 항목 숨기기를 참조하세요.

기존 리소스의 해결된 발견 항목을 숨기는 데 숨기기를 사용하지 마세요. 문제가 반복되고 Security Health Analytics가 발견 항목의 ACTIVE 상태를 복원하는 경우, NOT mute="MUTED"를 지정하는 발견 항목 쿼리(예: 기본 발견 항목 쿼리)에서 숨겨진 발견 항목이 제외되기 때문에 재활성화된 발견 항목이 표시되지 않을 수 있습니다.

스캔 간격에 대한 자세한 내용은 Security Health Analytics 스캔 유형을 참조하세요.

`Access Transparency disabled`

API의 카테고리 이름: ACCESS_TRANSPARENCY_DISABLED

액세스 투명성 로그는 Google Cloud 직원이 조직 내 프로젝트에 액세스하여 지원을 제공하는 경우 사용됩니다. Google Cloud에서 누가, 언제, 왜 정보에 액세스하는지 로깅하려면 액세스 투명성을 사용 설정하세요. 자세한 내용은 액세스 투명성을 참조하세요.

프로젝트에서 액세스 투명성을 사용 설정하려면 프로젝트를 결제 계정과 연결해야 합니다.

필요한 역할

이 태스크를 수행하는 데 필요한 권한을 얻으려면 관리자에게 조직 수준의 액세스 투명성 관리자(roles/axt.admin) IAM 역할을 부여해 달라고 요청하세요. 역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

이 사전 정의된 역할에는 이 태스크를 수행하는 데 필요한 axt.labels.get 및 axt.labels.set 권한이 포함되어 있습니다. 커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이러한 권한을 얻을 수도 있습니다.

해결 단계

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

조직 수준 권한을 확인합니다.
1. Google Cloud Console에서 Identity and Access Management 페이지로 이동합니다.
  
  Identity and Access Management로 이동
2. 메시지가 표시되면 선택기 메뉴에서 Google Cloud 조직을 선택합니다.
선택기 메뉴를 사용하여 조직 내에서 Google Cloud 프로젝트를 선택합니다.

액세스 투명성은 Google Cloud 프로젝트 페이지에서 구성되지만 전체 조직에 대해 액세스 투명성을 사용 설정할 수 있습니다.
IAM 및 관리자 > 설정 페이지로 이동합니다.
액세스 투명성 사용 설정을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`AlloyDB auto backup disabled`

API의 카테고리 이름: ALLOYDB_AUTO_BACKUP_DISABLED

PostgreSQL용 AlloyDB 클러스터에는 자동 백업이 사용 설정되어 있지 않습니다.

데이터가 손실되지 않도록 클러스터의 자동 백업을 사용 설정하세요. 자세한 내용은 추가 자동 백업 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

PostgreSQL용 AlloyDB 클러스터로 이동
리소스 이름 열에서 클러스터를 클릭합니다.
데이터 보호를 클릭합니다.
자동 백업 정책 섹션의 자동 백업 행에서 수정을 클릭합니다.
백업 자동화 체크박스를 선택합니다.
업데이트를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`AlloyDB log min error statement severity`

API의 카테고리 이름: ALLOYDB_LOG_MIN_ERROR_STATEMENT_SEVERITY

PostgreSQL용 AlloyDB 인스턴스에는 log_min_error_statement 데이터베이스 플래그가 error 또는 다른 추천 값으로 설정되어 있지 않습니다.

log_min_error_statement 플래그는 오류 조건을 유발하는 SQL 문을 서버 로그에 기록할지 여부를 제어합니다. 지정된 심각도 이상의 SQL 문이 로깅됩니다. 심각도가 높을수록 기록되는 메시지가 적습니다. 심각도 수준이 너무 높게 설정되면 오류 메시지가 로깅되지 않을 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

PostgreSQL용 AlloyDB 클러스터로 이동
리소스 이름 열에서 클러스터를 클릭합니다.
클러스터의 인스턴스 섹션에서 인스턴스의 수정을 클릭합니다.
Advanced Configuration Options(고급 구성 옵션)를 클릭합니다.
플래그 섹션에서 조직의 로깅 정책에 따라 log_min_error_statement 데이터베이스 플래그를 다음 권장 값 중 하나로 설정합니다.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
- error
인스턴스 업데이트를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`AlloyDB log min messages`

API의 카테고리 이름: ALLOYDB_LOG_MIN_MESSAGES

PostgreSQL용 AlloyDB 인스턴스에는 log_min_messages 데이터베이스 플래그가 최소 warning으로 설정되어 있지 않습니다.

log_min_messages 플래그는 서버 로그에 기록되는 메시지 수준을 제어합니다. 심각도가 높을수록 기록되는 메시지가 적습니다. 기준점을 너무 낮게 설정하면 로그 스토리지 크기와 기간이 늘어나 실제 오류를 찾기가 어려워질 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

PostgreSQL용 AlloyDB 클러스터로 이동
리소스 이름 열에서 클러스터를 클릭합니다.
클러스터의 인스턴스 섹션에서 인스턴스의 수정을 클릭합니다.
Advanced Configuration Options(고급 구성 옵션)를 클릭합니다.
플래그 섹션에서 조직의 로깅 정책에 따라 log_min_messages 데이터베이스 플래그를 다음 권장 값 중 하나로 설정합니다.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
인스턴스 업데이트를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`AlloyDB log error verbosity`

API의 카테고리 이름: ALLOYDB_LOG_ERROR_VERBOSITY

PostgreSQL용 AlloyDB 인스턴스에는 log_error_verbosity 데이터베이스 플래그가 default 또는 덜 제한적인 값으로 설정되어 있지 않습니다.

log_error_verbosity 플래그는 로깅되는 메시지의 세부정보 양을 제어합니다. 세부정보 수준이 높을수록 메시지에 더 많은 세부정보가 기록됩니다. 이 플래그를 default 또는 다른 덜 제한적인 값으로 설정하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

PostgreSQL용 AlloyDB 클러스터로 이동
리소스 이름 열에서 클러스터를 클릭합니다.
클러스터의 인스턴스 섹션에서 인스턴스의 수정을 클릭합니다.
Advanced Configuration Options(고급 구성 옵션)를 클릭합니다.
플래그 섹션에서 조직의 로깅 정책에 따라 log_error_verbosity 데이터베이스 플래그를 다음 권장 값 중 하나로 설정합니다.
- default
- verbose
인스턴스 업데이트를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Admin service account`

API의 카테고리 이름: ADMIN_SERVICE_ACCOUNT

조직 또는 프로젝트의 서비스 계정에 관리자, 소유자 또는 편집자 권한이 할당되었습니다. 이러한 역할은 포괄적인 권한을 가지며, 서비스 계정에 할당되지 않아야 합니다. 서비스 계정 및 여기에 사용할 수 있는 역할에 대해 자세히 알아보려면 서비스 계정을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM 정책으로 이동
발견 항목에서 식별된 각 주 구성원에 대해 다음 안내를 따르세요.
1. 주 구성원 옆에 있는 수정 을 클릭합니다.
2. 권한을 삭제하려면 문제가 되는 역할 옆에 있는 삭제 를 클릭합니다.
3. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Alpha cluster enabled`

API의 카테고리 이름: ALPHA_CLUSTER_ENABLED

알파 클러스터 기능이 Google Kubernetes Engine(GKE) 클러스터에 대해 사용 설정되었습니다.

알파 클러스터를 통해 얼리 어답터는 새로운 기능을 사용하는 워크로드를 일반 대중에 공개되기 전에 실험해 볼 수 있습니다. 알파 클러스터에는 모든 GKE API 기능이 사용 설정되어 있지만 GKE SLA가 적용되지 않고, 보안 업데이트를 받지 않으며, 노드 자동 업그레이드와 노드 자동 복구가 사용 중지되어 있고, 업그레이드할 수도 없습니다. 또한 30일 후에 자동으로 삭제됩니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

알파 클러스터를 사용 중지할 수 없습니다. 알파 기능이 사용 중지된 상태로 새 클러스터를 만들어야 합니다.

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

Kubernetes 클러스터로 이동
만들기를 클릭합니다.
만들려는 클러스터 유형 옆에서 구성을 선택합니다.
기능 탭 아래에서 이 클러스터에서 Kubernetes 알파 기능 사용 설정이 사용 중지되었는지 확인합니다.
참고: GKE Autopilot을 선택한 경우 알파 클러스터가 지원되지 않기 때문에 이 옵션이 표시되지 않습니다.
만들기를 클릭합니다.
워크로드를 새 클러스터로 이동하려면 워크로드를 다른 머신 유형으로 마이그레이션을 참조하세요.
원본 클러스터를 삭제하려면 클러스터 삭제를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`API key APIs unrestricted`

API의 카테고리 이름: API_KEY_APIS_UNRESTRICTED

API 키가 너무 광범위하게 사용되고 있습니다.

제한되지 않은 API 키는 키가 저장된 기기에서 가져오거나 공개적으로(예: 브라우저 내에서) 표시될 수 있기 때문에 안전하지 않습니다. 최소 권한의 원칙에 따라 애플리케이션에 필요한 API만 호출하도록 API 키를 구성하세요. 자세한 내용은 API 키 제한사항 적용을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

API 키로 이동
각 API 키마다 다음을 수행합니다.
1. API를 제한해야 하는 각 API 키 행의 API 키 섹션에서 아이콘을 클릭하여 작업 메뉴를 표시합니다.
2. 작업 메뉴에서 API 키 수정을 클릭합니다. API 키 수정 페이지가 열립니다.
3. API 제한사항 섹션에서 API 제한을 선택합니다. API 선택 드롭다운 메뉴가 표시됩니다.
4. API 선택 드롭다운 목록에서 허용할 API를 선택합니다.
  
  경고: Google Cloud에서 제공되는 모든 서비스에 액세스가 허용되므로 API 제한사항을 Google Cloud API로 설정하지 마세요.
5. 저장을 클릭합니다. 설정이 적용되려면 최대 5분이 걸릴 수 있습니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`API key apps unrestricted`

API의 카테고리 이름: API_KEY_APPS_UNRESTRICTED

무제한으로 사용 중인 API 키가 있으며 신뢰할 수 없는 앱에서 사용할 수 있습니다.

제한되지 않은 API 키는 키가 저장된 기기에서 가져오거나 공개적으로 표시(예: 브라우저 내에 표시)될 수 있으므로 안전하지 않습니다. 최소 권한의 원칙에 따라 API 키 사용을 신뢰할 수 있는 호스트, HTTP 리퍼러, 앱으로 제한하세요. 자세한 내용은 API 키 제한사항 적용을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

API 키로 이동
각 API 키마다 다음을 수행합니다.
1. 애플리케이션을 제한해야 하는 각 API 키 행의 API 키 섹션에서 아이콘을 클릭하여 작업 메뉴를 표시합니다.
2. 작업 메뉴에서 API 키 수정을 클릭합니다. API 키 수정 페이지가 열립니다.
3. API 키 수정 페이지의 애플리케이션 제한사항에서 제한 카테고리를 선택합니다. 키별로 애플리케이션 제한사항 1개를 설정할 수 있습니다.
4. 제한사항을 선택할 때 나타나는 항목 추가 필드에서 항목 추가를 클릭하여 애플리케이션 요구에 따라 제한사항을 추가합니다.
5. 항목 추가가 완료되면 완료를 클릭합니다.
  
  경고: *, *.[TLD], .[TLD]/*와 같이 모든 또는 광범위한 HTTP 리퍼러에 대해 액세스가 허용되므로 HTTP 리퍼러를 와일드 카드로 설정하지 마세요. 모든 호스트를 허용하도록 IP 주소 및 리퍼러를 설정하지 마세요(0.0.0.0, ::0, 0.0.0.0/0).
6. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`API key exists`

API의 카테고리 이름: API_KEY_EXISTS

프로젝트에서 표준 인증 대신 API 키를 사용합니다.

API 키는 암호화된 간단한 문자열이고 다른 사람이 쉽게 찾아서 사용할 수 있으므로 다른 인증 방법보다 안전하지 않습니다. 이러한 키는 키가 저장된 기기에서 가져오거나 공개적으로 표시(예: 브라우저 내에 표시)될 수 있습니다. 또한 API 키는 요청을 수행하는 사용자 또는 애플리케이션을 고유하게 식별하지 않습니다. 대신 서비스 계정이나 사용자 계정으로 표준 인증 흐름을 사용할 수 있습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

애플리케이션이 대체 인증 형식으로 구성되었는지 확인합니다.
Google Cloud 콘솔에서 API 사용자 인증 정보 페이지로 이동합니다.

API 사용자 인증 정보로 이동
삭제해야 하는 각 API 키 행의 API 키 섹션에서 아이콘을 클릭하여 작업 메뉴를 표시합니다.
작업 메뉴에서 API 키 삭제를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`API key not rotated`

API의 카테고리 이름: API_KEY_NOT_ROTATED

API 키가 90일 이상 순환되지 않았습니다.

API 키는 만료되지 않으므로 도난당하면 프로젝트 소유자가 키를 취소하거나 순환하지 않는 한 무한정 사용 가능합니다. API 키를 자주 재생성하면 도난당한 API 키로 보안 침해되었거나 해지된 계정의 데이터에 액세스할 수 있는 시간이 줄어듭니다. 최소 90일마다 API 키를 순환하는 것이 좋습니다. 자세한 내용은 API 키 보안을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

API 키로 이동
각 API 키마다 다음을 수행합니다.
1. 회전해야 하는 각 API 키 행의 API 키 섹션에서 아이콘을 클릭하여 작업 메뉴를 표시합니다.
2. 작업 메뉴에서 API 키 수정을 클릭합니다. API 키 수정 페이지가 열립니다.
3. API 키 수정 페이지에서 생성일 필드의 날짜가 90일보다 오래된 경우 페이지 상단의 키 재생성을 클릭하여 키를 교체하십시오. 새 교체 키가 생성됩니다.
4. 저장을 클릭합니다.
5. 애플리케이션이 중단되지 않고 계속 작동할 수 있도록 새 API 키를 사용하도록 업데이트합니다. 이전 API 키는 24시간 동안 작동한 후 영구적으로 비활성화됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Audit config not monitored`

API의 카테고리 이름: AUDIT_CONFIG_NOT_MONITORED

로그 측정항목 및 알림은 감사 구성 변경사항을 모니터링하도록 구성되지 않습니다.

Cloud Logging은 보안 분석, 리소스 변경 추적, 규정 준수 감사를 사용 설정하는 관리자 활동 및 데이터 액세스 로그를 생성합니다. 감사 구성 변경사항을 모니터링하면 프로젝트의 모든 활동을 언제든지 감사할 수 있습니다. 자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

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

이 발견 항목을 해결하려면 필요에 따라 측정항목을 만들고 알림 정책을 만듭니다.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.
필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.
```
  protoPayload.methodName="SetIamPolicy"
  AND protoPayload.serviceData.policyDelta.auditConfigDeltas:*
```
측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Audit logging disabled`

API의 카테고리 이름: AUDIT_LOGGING_DISABLED

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

하나 이상의 Google Cloud 서비스에 감사 로깅이 사용 중지되었거나 하나 이상의 주 구성원이 데이터 액세스 감사 로깅에서 제외되었습니다.

모든 서비스가 모든 관리 활동, 사용자 데이터에 대한 읽기 액세스, 쓰기 액세스를 추적하도록 Cloud Logging을 사용 설정하세요. 정보의 양에 따라 Cloud Logging 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

주 구성원이 기본 데이터 액세스 감사 로깅 구성 또는 개별 서비스의 로깅 구성에서 데이터 액세스 감사 로깅에서 제외되는 경우 예외를 삭제하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 데이터 액세스 감사 로그 기본 구성 페이지로 이동합니다.

기본 구성으로 이동
로그 유형 탭에서 기본 구성으로 데이터 액세스 감사 로깅을 활성화합니다.
1. 관리자 읽기, 데이터 읽기, 데이터 쓰기를 선택합니다.
2. 저장을 클릭합니다.
면제된 주 구성원 탭에서 기본 구성에서 면제된 모든 사용자를 삭제하세요.
1. 각 이름 옆에 있는 삭제 를 클릭하여 나열된 각 주 구성원을 삭제합니다.
2. 저장을 클릭합니다.
감사 로그 페이지로 이동합니다.

감사 로그로 이동
개별 서비스의 데이터 액세스 감사 로그 구성에서 면제된 주 구성원을 삭제합니다.
1. 데이터 액세스 감사 로그 구성에서 제외된 주 구성원이 표시되는 각 서비스마다 서비스를 클릭하세요. 서비스에 대한 감사 로그 구성 패널이 열립니다.
2. 면제된 주 구성원 탭에서 각 이름 옆에 있는 삭제 를 클릭하여 제외된 모든 주 구성원을 삭제합니다.
3. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Auto backup disabled`

API의 카테고리 이름: AUTO_BACKUP_DISABLED

Cloud SQL 데이터베이스에는 자동 백업이 사용 설정되어 있지 않습니다.

데이터 손실 방지를 위해 SQL 인스턴스의 자동 백업을 사용 설정합니다. 자세한 내용은 온디맨드 및 자동 백업 만들기 및 관리를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 SQL 인스턴스 백업 페이지로 이동합니다.

SQL 인스턴스 백업으로 이동
설정 옆에 있는 수정 을 클릭합니다.
백업 자동화 상자를 선택합니다.
드롭다운 메뉴에서 데이터를 자동으로 백업할 기간을 선택합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Auto repair disabled`

API의 카테고리 이름: AUTO_REPAIR_DISABLED

노드를 정상 상태로 유지하는 Google Kubernetes Engine(GKE) 클러스터의 자동 복구 기능이 사용 중지됩니다.

이 기능이 사용 설정되면 GKE는 클러스터의 각 노드 상태를 주기적으로 확인합니다. 노드가 장시간 동안 연이어 상태 검사에 실패하는 경우, GKE는 노드의 복구 프로세스를 시작합니다. 자세한 내용은 노드 자동 복구를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
노드 탭을 클릭합니다.
각 노드 풀마다 다음을 수행합니다.
1. 노드 풀 이름을 클릭하여 해당 세부정보 페이지로 이동합니다.
2. 수정 을 클릭합니다.
3. 관리에서 자동 복구 사용 설정을 선택합니다.
4. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Auto upgrade disabled`

API의 카테고리 이름: AUTO_UPGRADE_DISABLED

클러스터 및 노드 풀을 Kubernetes의 최신 안정화 버전으로 유지하는 GKE 클러스터의 자동 업그레이드 기능이 사용 중지되어 있습니다.

자세한 내용은 노드 자동 업그레이드를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
클러스터 목록에서 클러스터 이름을 클릭합니다.
노드 탭을 클릭합니다.
각 노드 풀마다 다음을 수행합니다.
1. 노드 풀 이름을 클릭하여 해당 세부정보 페이지로 이동합니다.
2. 수정 을 클릭합니다.
3. 관리에서 자동 업그레이드 사용 설정을 선택합니다.
4. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`BigQuery table CMEK disabled`

API의 카테고리 이름: BIGQUERY_TABLE_CMEK_DISABLED

BigQuery 테이블은 고객 관리 암호화 키(CMEK)를 사용하도록 구성되지 않습니다.

CMEK를 사용하는 경우, Cloud KMS에서 만들고 관리하는 키가 Google Cloud에서 데이터 암호화를 위해 사용되는 키를 래핑하여 데이터 액세스 권한을 더 세밀하게 제어할 수 있습니다. 자세한 내용은 Cloud KMS 키로 데이터 보호를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

데이터 세트의 모든 새 테이블을 암호화하는 기본 CMEK 키를 설정하려면 데이터 세트 기본 키 설정을 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Binary authorization disabled`

API의 카테고리 이름: BINARY_AUTHORIZATION_DISABLED

GKE 클러스터에서 Binary Authorization이 사용 중지되었습니다.

Binary Authorization에는 개발 프로세스 중 신뢰할 수 있는 기관에서 서명된 컨테이너 이미지만 클러스터에 배포되도록 허용하여 공급망 보안을 보호하는 선택적인 기능이 포함되어 있습니다. 서명 기반 배포를 사용해서 컨테이너 환경을 더 긴밀하게 제어하고, 확인된 이미지만 배포되도록 할 수 있습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
보안 섹션의 Binary Authorization 행에서 편집 아이콘()을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없다면 몇 분 후 다시 시도하세요.
대화상자에서 Binary Authorization 사용 설정을 선택합니다.
변경사항 저장을 클릭합니다.
Binary Authorization 설정 페이지로 이동합니다.

Binary Authorization으로 이동
증명자를 필요로 하는 정책이 구성되었고 프로젝트 기본 규칙이 모든 이미지 허용으로 구성되지 않았는지 확인합니다. 자세한 내용은 GKE 설정을 참조하세요.

정책을 위반하는 이미지의 배포가 허용되고 위반 사항이 Cloud 감사 로그에 로깅되도록 하려면 테스트 실행 모드를 사용 설정할 수 있습니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Bucket CMEK disabled`

API의 카테고리 이름: BUCKET_CMEK_DISABLED

버킷이 고객 관리 암호화 키(CMEK)로 암호화되지 않습니다.

버킷에서 기본 CMEK를 설정하면 데이터 액세스를 더 세밀하게 제어할 수 있습니다. 자세한 내용은 고객 관리 암호화 키를 참조하세요.

이 발견 항목을 해결하려면 고객 관리 암호화 키 사용에 따라 버킷에 CMEK를 사용합니다. CMEK를 사용하면 Cloud KMS와 관련된 추가 비용이 발생합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Bucket IAM not monitored`

API의 카테고리 이름: BUCKET_IAM_NOT_MONITORED

로그 측정항목 및 알림은 Cloud Storage IAM 권한 변경을 모니터링하도록 구성되지 않습니다.

Cloud Storage 버킷 권한의 변경사항을 모니터링하면 다른 권한이 부여된 사용자 또는 의심스러운 활동을 식별하는 데 도움이 됩니다. 자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.
필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.
```
  resource.type=gcs_bucket
  AND protoPayload.methodName="storage.setIamPermissions"
```
측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Bucket logging disabled`

API의 카테고리 이름: BUCKET_LOGGING_DISABLED

로깅이 사용 설정되지 않은 스토리지 버킷이 있습니다.

보안 문제를 조사하고 저장용량 소비를 모니터링할 수 있도록 Cloud Storage 버킷에 대한 액세스 로그 및 저장용량 정보를 사용 설정하세요. 액세스 로그는 특정 버킷에서 이루어진 모든 요청에 대한 정보를 제공하고, 스토리지 로그는 해당 버킷의 스토리지 소비에 대한 정보를 제공합니다.

이 발견 항목을 해결하려면 사용량 로그 및 스토리지 로그 가이드를 완료하여 Security Health Analytics 발견 항목에서 지정한 버킷에 대한 로깅을 설정하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Bucket policy only disabled`

API의 카테고리 이름: BUCKET_POLICY_ONLY_DISABLED

이전에 버킷 전용 정책이라고 불렀던 버킷 수준 액세스는 구성되지 않습니다.

균일한 버킷 수준 액세스를 사용하면 객체 수준 권한(ACL)을 사용 중지하여 버킷 액세스 제어가 간소화됩니다. 사용 설정된 경우 버킷 수준 IAM 권한만 버킷 및 여기에 포함된 객체에 대한 액세스 권한을 부여합니다. 자세한 내용은 균일한 버킷 수준 액세스를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud Storage 브라우저 페이지로 이동합니다.

Cloud Storage 브라우저로 이동
버킷 목록에서 원하는 버킷 이름을 클릭합니다.
구성 탭을 클릭합니다.
권한 아래의 액세스 제어 행에서 수정 아이콘()을 클릭합니다.
대화상자에서 균일을 선택합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cloud Asset API disabled`

API의 카테고리 이름: CLOUD_ASSET_API_DISABLED

프로젝트에서 Cloud 애셋 인벤토리 서비스가 사용 설정되지 않았습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud console의 API 라이브러리 페이지로 이동합니다.

API 라이브러리로 이동
Cloud Asset Inventory을 검색합니다.
Cloud Asset API 서비스에 대한 결과를 선택합니다.
API 사용 설정됨이 표시되는지 확인합니다.

`Cluster logging disabled`

API의 카테고리 이름: CLUSTER_LOGGING_DISABLED

GKE 클러스터에 로깅이 사용 설정되지 않았습니다.

보안 문제 조사를 돕고 사용량을 모니터링하려면 클러스터에서 Cloud Logging을 사용 설정합니다.

정보의 양에 따라 Cloud Logging 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
Security Health Analytics 발견 항목 목록에 나열된 클러스터를 선택합니다.
수정을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없는 경우 몇 분 정도 기다린 후 다시 시도하세요.
기존 Stackdriver Logging 또는 Stackdriver Kubernetes Engine Monitoring 드롭다운 목록에서 사용 설정을 선택합니다.

이러한 옵션은 호환되지 않습니다. Stackdriver Kubernetes Engine Monitoring만 단독으로 사용하거나 기존 Stackdriver Logging을 기존 Stackdriver Monitoring과 함께 사용해야 합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cluster monitoring disabled`

API의 카테고리 이름: CLUSTER_MONITORING_DISABLED

Monitoring이 GKE 클러스터에서 사용 중지됩니다.

보안 문제 조사를 돕고 사용량을 모니터링하려면 클러스터에서 Cloud Monitoring을 사용 설정합니다.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
Security Health Analytics 발견 항목 목록에 나열된 클러스터를 선택합니다.
수정을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없는 경우 몇 분 정도 기다린 후 다시 시도하세요.
기존 Stackdriver Monitoring 또는 Stackdriver Kubernetes Engine Monitoring 드롭다운 목록에서 사용 설정을 선택합니다.

이러한 옵션은 호환되지 않습니다. Stackdriver Kubernetes Engine Monitoring만 단독으로 사용하거나 기존 Stackdriver Monitoring을 기존 Stackdriver Logging과 함께 사용해야 합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cluster private Google access disabled`

API의 카테고리 이름: CLUSTER_PRIVATE_GOOGLE_ACCESS_DISABLED

클러스터 호스트는 비공개 내부 IP 주소만 사용하여 Google API에 액세스하도록 구성되지 않습니다.

비공개 Google 액세스는 비공개 내부 IP 주소만 있는 가상 머신(VM) 인스턴스가 Google API 및 서비스의 공개 IP 주소에 연결되도록 허용합니다. 자세한 내용은 Google 비공개 액세스 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Virtual Private Cloud 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
네트워크 목록에서 원하는 네트워크 이름을 클릭합니다.
VPC 네트워크 세부정보 페이지에서 서브넷 탭을 클릭합니다.
서브넷 목록에서 발견 항목의 Kubernetes 클러스터와 연관된 서브넷 이름을 클릭합니다.
서브넷 세부정보 페이지에서 수정 을 클릭합니다.
비공개 Google 액세스에서 사용을 클릭합니다.
저장을 클릭합니다.
외부 트래픽만 Google API에 연결되는 VM 인스턴스에서 공개(외부) IP를 삭제하려면 정적 외부 IP 주소 할당 해제를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cluster secrets encryption disabled`

API의 카테고리 이름: CLUSTER_SECRETS_ENCRYPTION_DISABLED

애플리케이션 레이어 보안 비밀 암호화가 GKE 클러스터에서 사용 중지되었습니다.

애플리케이션 레이어 보안 비밀 암호화는 Cloud KMS 키를 사용하여 GKE 보안 비밀이 암호화되도록 합니다. 이 기능은 모두 etcd에 저장되는 민감한 정보(예: 사용자 정의 보안 비밀, 클러스터 작업에 필요한 보안 비밀, 서비스 계정 키)에 대한 추가 보안 레이어를 제공합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Cloud KMS 키로 이동
애플리케이션 키를 검토하거나 데이터베이스 암호화 키(DEK)를 만듭니다. 자세한 내용은 Cloud KMS 키 만들기를 참조하세요.
Kubernetes 클러스터 페이지로 이동합니다.

Kubernetes 클러스터로 이동
발견 항목에서 클러스터를 선택합니다.
보안의 애플리케이션 레이어 보안 비밀 암호화 필드에서 애플리케이션 레이어 보안 비밀 암호화 수정을 클릭합니다.
애플리케이션 레이어 보안 비밀 암호화 사용 설정 체크박스를 선택하고 생성한 DEK를 선택합니다.
변경사항 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cluster shielded nodes disabled`

API의 카테고리 이름: CLUSTER_SHIELDED_NODES_DISABLED

보안 GKE 노드가 클러스터에 대해 사용 설정되지 않습니다.

보안 GKE 노드가 없으면 공격자가 포드의 취약점을 악용하여 부트스트랩 사용자 인증 정보를 유출하고 클러스터에서 노드를 가장할 수 있습니다. 이 취약점은 공격자에게 클러스터 보안 비밀에 대한 액세스 권한을 부여할 수 있습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
발견 항목에서 클러스터를 선택합니다.
보안의 보안 GKE 노드 필드에서 보안 GKE 노드 수정을 클릭합니다.
보안 GKE 노드 사용 설정 체크박스를 선택합니다.
변경사항 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Compute project wide SSH keys allowed`

API의 카테고리 이름: COMPUTE_PROJECT_WIDE_SSH_KEYS_ALLOWED

프로젝트의 모든 인스턴스에 로그인할 수 있도록 프로젝트 전체 SSH 키가 사용됩니다.

프로젝트 차원의 SSH 키를 사용하면 SSH 키 관리가 쉬워지지만 보안 침해 시 프로젝트 내의 모든 인스턴스에 영향을 미칠 수 있는 보안 위험이 발생합니다. SSH 키가 손상된 경우 공격 표면을 제한하는 인스턴스별 SSH 키를 사용해야 합니다. 자세한 내용은 메타데이터에서 SSH 키 관리를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름을 클릭합니다.
VM 인스턴스 세부정보 페이지에서 수정을 클릭합니다.
참고: 인스턴스 템플릿을 사용하여 생성된 인스턴스는 수정할 수 없습니다. 인스턴스 템플릿의 구성을 변경하려면 인스턴스 템플릿 업데이트 방법을 참조하세요.
SSH 키에서 프로젝트 전체 SSH 키 차단을 선택합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Compute Secure Boot disabled`

API의 카테고리 이름: COMPUTE_SECURE_BOOT_DISABLED

보안 VM에 보안 부팅이 사용 설정되지 않습니다.

보안 부팅을 사용하면 루트킷과 부트킷으로부터 가상 머신을 보호할 수 있습니다. 일부 서명되지 않은 드라이버와 하위 소프트웨어가 호환되지 않기 때문에 기본적으로 Compute Engine은 보안 부팅을 사용 설정하지 않습니다. VM이 호환되는 소프트웨어를 사용하지 않고 보안 부팅이 사용 설정된 상태로 부팅되는 경우에는 보안 부팅을 사용하는 것이 좋습니다. Nvidia 드라이버가 포함된 타사 모듈을 사용하는 경우 사용 설정하기 전에 보안 부팅과 호환되는지 확인하세요.

자세한 내용은 보안 부팅을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름을 클릭합니다.
VM 인스턴스 세부정보 페이지에서 중지를 클릭합니다.
인스턴스가 중지된 후 수정을 클릭합니다.
보안 VM에서 보안 부팅 설정을 선택합니다.
저장을 클릭합니다.
시작을 클릭하여 인스턴스를 시작합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Compute serial ports enabled`

API의 카테고리 이름: COMPUTE_SERIAL_PORTS_ENABLED

인스턴스에 직렬 포트가 사용 설정되어 있으면 인스턴스의 직렬 콘솔 연결이 허용됩니다.

인스턴스에서 대화형 직렬 콘솔을 사용 설정하면 클라이언트가 모든 IP 주소에서 해당 인스턴스에 대한 연결을 시도할 수 있습니다. 따라서 대화형 직렬 콘솔 지원을 사용 중지해야 합니다. 자세한 내용은 프로젝트에 대한 액세스 사용 설정을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름을 클릭합니다.
VM 인스턴스 세부정보 페이지에서 수정을 클릭합니다.
원격 액세스 아래에서 직렬 포트 연결 사용 설정을 선택합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Confidential Computing disabled`

API의 카테고리 이름: CONFIDENTIAL_COMPUTING_DISABLED

Compute Engine 인스턴스에는 컨피덴셜 컴퓨팅이 사용 설정되어 있지 않습니다.

컨피덴셜 컴퓨팅은 사용 중 데이터를 암호화하여 엔드 투 엔드 암호화 스토리에 세 번째 요소를 추가합니다. Google Cloud는 컨피덴셜 컴퓨팅 및 AMD Secure Encrypted Virtualization(SEV)에서 제공하는 컨피덴셜 실행 환경을 통해 처리 중에 민감한 코드 및 기타 데이터를 메모리에 암호화된 상태로 유지합니다.

컨피덴셜 컴퓨팅은 인스턴스를 만들 때만 사용 설정할 수 있습니다. 따라서 현재 인스턴스를 삭제하고 새 인스턴스를 만들어야 합니다.

자세한 내용은 컨피덴셜 VM 및 Compute Engine을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름을 클릭합니다.
VM 인스턴스 세부정보 페이지에서 삭제를 클릭합니다.
Google Cloud 콘솔을 사용하여 컨피덴셜 VM을 만듭니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`COS not used`

API의 카테고리 이름: COS_NOT_USED

Compute Engine VM이 Google Cloud에서 Docker 컨테이너를 안전하게 실행하도록 설계된 Container-Optimized OS를 사용하지 않습니다.

Container-Optimized OS는 Google Cloud에서 컨테이너를 호스팅하고 실행하기 위한 권장 OS입니다. OS 사용 공간이 작아 보안 노출을 최소화하면서도 자동 업데이트로 보안 취약점을 시의적절하게 패치합니다. 자세한 내용은 Container-Optimized OS 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
클러스터 목록에서 발견 항목의 클러스터 이름을 클릭합니다.
노드 탭을 클릭합니다.
각 노드 풀마다 다음을 수행합니다.
1. 노드 풀 이름을 클릭하여 해당 세부정보 페이지로 이동합니다.
2. 수정 을 클릭합니다.
3. 노드 -> 이미지 유형에서 변경을 클릭합니다.
4. Container-Optimized OS를 선택한 후 변경을 클릭합니다.
5. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Custom role not monitored`

API의 카테고리 이름: CUSTOM_ROLE_NOT_MONITORED

로그 측정항목 및 알림은 커스텀 역할 변경을 모니터링하도록 구성되지 않습니다.

IAM은 특정 Google Cloud 리소스에 대해 액세스 권한을 부여하는 미리 정의된 커스텀 역할을 제공합니다. 역할 생성, 삭제, 업데이트 활동을 모니터링하면 권한이 과도하게 부여된 역할을 조기에 발견할 수 있습니다. 자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.

필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.

  resource.type="iam_role"
  AND (protoPayload.methodName="google.iam.admin.v1.CreateRole"
  OR protoPayload.methodName="google.iam.admin.v1.DeleteRole"
  OR protoPayload.methodName="google.iam.admin.v1.UpdateRole")

측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dataproc CMEK disabled`

API의 카테고리 이름: DATAPROC_CMEK_DISABLED

Dataproc 클러스터가 CMEK 암호화 구성없이 생성되었습니다. CMEK를 사용하는 경우, Cloud Key Management Service에서 만들고 관리하는 키가 Google Cloud에서 데이터 암호화를 위해 사용되는 키를 래핑하여 데이터 액세스 권한을 더 세밀하게 제어할 수 있습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud console에서 Dataproc 클러스터 페이지로 이동합니다.

Dataproc 클러스터로 이동
프로젝트를 선택하고 클러스터 만들기를 클릭합니다.
보안 관리 섹션에서 암호화를 클릭하고 고객 관리 키를 선택합니다.
목록에서 고객 관리 키를 선택합니다.

고객 관리 키가 없는 경우 사용할 키를 만들어야 합니다. 자세한 내용은 고객 관리 암호화 키를 참조하세요.
선택한 KMS 키에 Dataproc 클러스터 서비스 계정("serviceAccount:service-project_number@compute-system.iam.gserviceaccount.com")에 할당된 Cloud KMS CryptoKey 암호화/복호화 역할이 있는지 확인합니다.
클러스터가 생성되면 모든 워크로드를 이전 클러스터에서 새 클러스터로 마이그레이션합니다.
Dataproc 클러스터로 이동하고 프로젝트를 선택합니다.
이전 클러스터를 선택하고 삭제 클러스터를 클릭합니다.
선택한 프로젝트에서 사용 가능한 다른 Dataproc 클러스터에 대해 위의 모든 단계를 반복합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dataproc image outdated`

API의 카테고리 이름: DATAPROC_IMAGE_OUTDATED

Dataproc 클러스터가 Apache Log4j 2 유틸리티의 보안 취약점(CVE-2021-44228 및 CVE-2021-45046)에 영향을 받는 Dataproc 이미지 버전을 통해 생성되었습니다.

이 감지기는 Cluster의 config 속성에 있는 softwareConfig.imageVersion 필드에 영향을 받은 다음 버전이 있는지 확인하여 취약점을 발견합니다.

1.3.95 이전의 이미지 버전
1.4.77, 1.5.53, 2.0.27 이전의 하위 이미지 버전

커스텀 Dataproc 이미지의 버전 번호를 수동으로 재정의할 수 있습니다. 다음과 같은 시나리오를 가정합니다.

영향을 받는 커스텀 이미지의 버전을 영향을 받지 않도록 수정할 수 있습니다. 이 경우 이 감지기는 발견 항목을 내보내지 않습니다.
영향을 받지 않는 커스텀 이미지의 버전을 취약점이 있는 것으로 알려진 버전으로 재정의할 수 있습니다. 이 경우 이 감지기는 거짓양성 발견 항목을 내보냅니다. 이러한 거짓양성 발견 항목을 표시하지 않으려면 결과를 숨기면 됩니다.

이 발견 항목을 해결하려면 영향을 받는 클러스터를 다시 만들고 업데이트합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dataset CMEK disabled`

API의 카테고리 이름: DATASET_CMEK_DISABLED

BigQuery 데이터 세트는 기본 고객 관리 암호화 키(CMEK)를 사용하도록 구성되지 않습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

기본 암호화와 CMEK 암호화 간에 테이블을 전환할 수 없습니다. 데이터 세트의 모든 새 테이블을 암호화하는 기본 CMEK 키를 설정하려면 데이터 세트 기본 키 설정 안내를 따르세요.

기본 키를 설정해도 현재 데이터 세트에 있는 테이블이 새 키로 다시 암호화되지 않습니다. 기존 데이터에 CMEK를 사용하려면 다음을 수행합니다.

새 데이터 세트를 만듭니다.
만든 데이터 세트에서 기본 CMEK 키를 설정합니다.
CMEK 사용 설정 데이터 세트에 테이블을 복사하려면 테이블 복사 안내를 따르세요.
데이터를 복사하면 원본 데이터 세트를 삭제할 수 있습니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Default network`

API의 카테고리 이름: DEFAULT_NETWORK

프로젝트에 기본 네트워크가 있습니다.

기본 네트워크에 안전하지 않을 수 있는 방화벽 규칙과 네트워크 구성이 자동으로 생성되었습니다. 자세한 내용은 기본 네트워크를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
네트워크 목록에서 기본 네트워크 이름을 클릭합니다.
VPC 네트워크 세부정보 페이지에서 VPC 네트워크 삭제를 클릭합니다.
커스텀 방화벽 규칙을 사용하여 새 네트워크를 만들려면 네트워크 만들기를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Default service account used`

API의 카테고리 이름: DEFAULT_SERVICE_ACCOUNT_USED

Compute Engine 인스턴스가 기본 서비스 계정을 사용하도록 구성됩니다.

기본 Compute Engine 서비스 계정에는 프로젝트의 편집자 역할이 있어 대부분의 Google Cloud 서비스에 대한 읽기 및 쓰기 액세스가 허용됩니다. 권한 에스컬레이션 및 승인되지 않은 액세스로부터 보호하려면 기본 Compute Engine 서비스 계정을 사용하지 마세요. 대신 새 서비스 계정을 만들고 인스턴스에 필요한 권한만 할당합니다. 역할 및 권한에 대한 자세한 내용은 액세스 제어를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
Security Health Analytics 발견 항목과 관련된 인스턴스를 선택합니다.
로드된 인스턴스 세부정보 페이지에서 중지를 클릭합니다.
인스턴스가 중지된 후 수정을 클릭합니다.
서비스 계정 섹션에서 기본 Compute Engine 서비스 계정이 아닌 서비스 계정을 선택합니다. 먼저 새 서비스 계정을 만들어야 할 수도 있습니다. IAM 역할 및 권한에 대한 자세한 내용은 액세스 제어를 참조하세요.
저장을 클릭합니다. 인스턴스 세부정보 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Disk CMEK disabled`

API의 카테고리 이름: DISK_CMEK_DISABLED

이 VM의 디스크가 고객 관리 암호화 키(CMEK)로 암호화되지 않습니다.

CMEK를 사용하는 경우, Cloud KMS에서 만들고 관리하는 키가 Google Cloud에서 데이터 암호화를 위해 사용되는 키를 래핑하여 데이터 액세스 권한을 더 세밀하게 제어할 수 있습니다. 자세한 내용은 Cloud KMS 키로 리소스 보호를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Compute Engine 디스크 페이지로 이동합니다.

Compute Engine 디스크로 이동
디스크 목록에서 발견 항목에 표시된 디스크의 이름을 클릭합니다.
디스크 관리 페이지에서 삭제를 클릭합니다.
CMEK가 사용 설정된 새 디스크를 만들려면 고유 키로 새 영구 디스크 암호화를 참조하세요. CMEK를 사용하면 Cloud KMS와 관련된 추가 비용이 발생합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Disk CSEK disabled`

API의 카테고리 이름: DISK_CSEK_DISABLED

이 VM의 디스크는 고객 제공 암호화 키(CSEK)로 암호화되지 않습니다. 중요 VM의 디스크는 CSEK로 암호화해야 합니다.

자체 암호화 키를 제공할 경우 Compute Engine은 사용자의 키를 사용하여 데이터를 암호화 및 복호화하는 데 사용되는 Google 생성 키를 보호합니다. 자세한 내용은 고객 제공 암호화 키를 참조하세요. CSEK를 사용하면 Cloud KMS와 관련된 추가 비용이 발생합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

디스크 삭제 및 만들기

자체 키로는 새 영구 디스크만 암호화할 수 있으며, 기존 영구 디스크를 암호화할 수 없습니다.

Google Cloud 콘솔에서 Compute Engine 디스크 페이지로 이동합니다.

Compute Engine 디스크로 이동
디스크 목록에서 발견 항목에 표시된 디스크의 이름을 클릭합니다.
디스크 관리 페이지에서 삭제를 클릭합니다.
CSEK를 사용 설정하여 새 디스크를 만들려면 고객 제공 암호화 키로 디스크 암호화를 참조하세요.
남은 단계를 완료하여 검사 프로그램을 사용 설정합니다.

검사 프로그램 사용 설정

Google Cloud 콘솔에서 Security Command Center의 애셋 페이지로 이동합니다.

애셋으로 이동
빠른 필터 패널의 리소스 유형 섹션에서 compute.Disk를 선택합니다.

compute.Disk가 표시되지 않으면 더보기를 클릭하고 검색창에 Disk를 입력한 후 적용을 클릭합니다.

결과 패널이 업데이트되어 compute.Disk 리소스 유형의 인스턴스만 표시합니다.
표시 이름 열에서 CSEK로 사용하려는 디스크 이름 옆에 있는 상자를 선택한 후 보안 표시 설정을 클릭합니다.
대화상자에서 표시 추가를 클릭합니다.
키 필드에 enforce_customer_supplied_disk_encryption_keys를 입력하고 값 필드에 true를 입력합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`DNS logging disabled`

API의 카테고리 이름: DNS_LOGGING_DISABLED

Cloud DNS 로그 모니터링을 통해 VPC 네트워크 내에서 클라이언트가 요청한 DNS 이름을 파악할 수 있습니다. 비정상적인 도메인 이름이 있는지 이러한 로그를 모니터링하고 위협 인텔리전스를 기준으로 평가할 수 있습니다. VPC 네트워크에 DNS 로깅을 사용 설정하는 것이 좋습니다.

정보의 양에 따라 Cloud DNS Logging 비용이 크게 증가할 수 있습니다. 서비스 사용량 및 비용을 이해하려면 Google Cloud Observability 가격 책정: Cloud Logging을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
네트워크 목록에서 기본 VPC 네트워크 이름을 클릭합니다.
새 서버 정책을 만들거나(존재하지 않는 경우) 기존 정책을 수정합니다.
- 네트워크에 DNS 서버 정책이 없는 경우 다음 단계를 완료합니다.
  1. 수정을 클릭합니다.
  2. DNS 서버 정책 필드에서 새 서버 정책 만들기를 클릭합니다.
  3. 새 서버 정책의 이름을 입력합니다.
  4. 로그를 사용으로 설정합니다.
  5. 저장을 클릭합니다.
- 네트워크에 DNS 서버 정책이 있는 경우 다음 단계를 완료합니다.
  1. DNS 서버 정책 필드에서 DNS 정책의 이름을 클릭합니다.
  2. 정책 수정을 클릭합니다.
  3. 로그를 사용으로 설정합니다.
  4. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`DNSSEC disabled`

API의 카테고리 이름: DNSSEC_DISABLED

Domain Name System Security Extension(DNSSEC)이 Cloud DNS 영역에 대해 사용 중지됩니다.

DNSSEC는 DNS 응답을 검증하고 DNS 레코드를 암호화 방식으로 서명하여 DNS 계정 도용 및 중간자 공격과 같은 위험을 완화합니다. DNSSEC를 사용 설정해야 합니다. 자세한 내용은 DNS 보안 확장(DNSSEC) 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Cloud DNS 네트워크로 이동
발견 항목에 표시된 DNS 영역이 있는 행을 찾습니다.
행에서 DNSSEC 설정을 클릭한 후 DNSSEC에서 설정을 선택합니다.
표시되는 대화상자의 내용을 읽어보고 문제가 없으면 사용 설정을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Egress deny rule not set`

API의 카테고리 이름: EGRESS_DENY_RULE_NOT_SET

이그레스 거부 규칙은 방화벽에 설정되지 않습니다.

모든 이그레스 네트워크 트래픽을 거부하는 방화벽은 다른 방화벽에서 명시적으로 승인하는 연결을 제외하고 원치 않는 모든 아웃바운드 네트워크 연결을 방지합니다. 자세한 내용은 이그레스 사례를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 만들기를 클릭합니다.
방화벽에 이름을 지정하고 선택적으로 설명을 지정합니다.
트래픽 방향에서 이그레스를 선택합니다.
일치 시 작업에서 거부를 선택합니다.
대상 드롭다운 메뉴에서 네트워크의 모든 인스턴스를 선택합니다.
대상 필터 드롭다운 메뉴에서 IP 범위를 선택한 후 대상 IP 범위 상자에 0.0.0.0/0을 입력합니다.
프로토콜 및 포트에서 모두 거부를 선택합니다.
규칙 사용 중지를 클릭한 후 적용에서 사용 설정됨을 선택합니다.
만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Essential contacts not configured`

API의 카테고리 이름: ESSENTIAL_CONTACTS_NOT_CONFIGURED

조직에서 Google Cloud 조직 내 공격, 취약점, 데이터 이슈와 같은 중요 이벤트에 대한 Google Cloud 알림을 수신하도록 사용자 또는 그룹을 지정하지 않았습니다. 비즈니스 조직에서 한 명 이상의 사용자 또는 그룹을 필수 연락처로 지정하는 것이 좋습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud console에서 필수 연락처 페이지로 이동합니다.

필수 연락처로 이동
조직이 페이지 상단의 리소스 선택기에 표시되는지 확인합니다. 리소스 선택기는 현재 연락처를 관리 중인 프로젝트, 폴더 또는 조직을 알려줍니다.
+연락처 추가를 클릭합니다. 연락처 추가 패널이 열립니다.
이메일 및 이메일 확인 필드에 연락처의 이메일 주소를 입력합니다.
알림 카테고리 섹션에서 연락처에 커뮤니케이션을 제공하려는 알림 카테고리를 선택합니다. 다음 각 알림 카테고리에 적절한 이메일 주소가 구성되어 있는지 확인합니다.
1. 리걸
2. 보안
3. 정지
4. 기술
저장을 클릭합니다. 이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Firewall not monitored`

API의 카테고리 이름: FIREWALL_NOT_MONITORED

로그 측정항목 및 알림은 VPC 네트워크 방화벽 규칙 변경을 모니터링하도록 구성되지 않습니다.

방화벽 규칙 생성 및 업데이트 이벤트를 모니터링하면 네트워크 액세스 변경사항을 파악할 수 있으며 의심스러운 활동을 빠르게 감지할 수 있습니다. 자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.

필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.

  resource.type="gce_firewall_rule"
  AND (protoPayload.methodName:"compute.firewalls.insert"
  OR protoPayload.methodName:"compute.firewalls.patch"
  OR protoPayload.methodName:"compute.firewalls.delete")

측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Firewall rule logging disabled`

API의 카테고리 이름: FIREWALL_RULE_LOGGING_DISABLED

방화벽 규칙 로깅이 사용 중지됩니다.

방화벽 규칙 로깅을 사용하면 방화벽 규칙의 영향을 감사, 확인, 분석할 수 있습니다. 이는 네트워크 액세스를 감사하거나 네트워크가 승인되지 않은 방식으로 사용되고 있음을 미리 경고하는 데 유용할 수 있습니다. 로그 비용이 상당히 높을 수 있습니다. 방화벽 규칙 로깅 및 해당 비용에 대한 자세한 내용은 방화벽 규칙 로깅 사용을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 원하는 방화벽 규칙의 이름을 클릭합니다.
수정을 클릭합니다.
로그에서 설정을 선택합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Flow logs disabled`

API의 카테고리 이름: FLOW_LOGS_DISABLED

흐름 로그가 사용 중지된 VPC 서브네트워크가 있습니다.

VPC 흐름 로그는 VM 인스턴스에서 전송되거나 수신되는 네트워크 흐름의 샘플을 기록합니다. 이러한 로그를 네트워크 모니터링, 포렌식, 실시간 보안 분석, 비용 최적화에 사용할 수 있습니다. 흐름 로그 및 비용에 대한 자세한 내용은 VPC 흐름 로그 사용을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
네트워크 목록에서 원하는 네트워크 이름을 클릭합니다.
VPC 네트워크 세부정보 페이지에서 서브넷 탭을 클릭합니다.
서브넷 목록에서 발견 항목에 표시된 서브넷의 이름을 클릭합니다.
서브넷 세부정보 페이지에서 수정을 클릭합니다.
흐름 로그에서 켜기를 선택합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Flow logs settings not recommended`

API의 카테고리 이름: VPC_FLOW_LOGS_SETTINGS_NOT_RECOMMENDED

VPC 네트워크의 서브넷 구성에서 VPC 흐름 로그 서비스가 사용 중지되어 있거나 CIS 벤치마크 1.3 권장사항에 따라 구성되지 않았습니다. VPC 흐름 로그는 위협을 감지하는 데 사용할 수 있는 VM 인스턴스에서 전송되거나 수신되는 네트워크 흐름의 샘플을 기록합니다.

VPC 흐름 로그 및 비용에 대한 자세한 내용은 VPC 흐름 로그 사용을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
네트워크 목록에서 네트워크 이름을 클릭합니다.
VPC 네트워크 세부정보 페이지에서 서브넷 탭을 클릭합니다.
서브넷 목록에서 발견 항목에 표시된 서브넷의 이름을 클릭합니다.
서브넷 세부정보 페이지에서 수정을 클릭합니다.
흐름 로그에서 켜기를 선택합니다.
1. 필요한 경우 로그 구성 버튼을 클릭하여 탭을 펼쳐 로그 구성을 수정합니다. CIS 벤치마크에서 다음 설정을 권장합니다.
  1. 집계 간격을 5초로 설정합니다.
  2. 추가 필드 체크박스에서 메타데이터 포함 옵션을 선택합니다.
  3. 샘플링 레이트를 100%로 설정합니다.
  4. 저장 버튼을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Full API access`

API의 카테고리 이름: FULL_API_ACCESS

Compute Engine 인스턴스가 모든 Google Cloud API에 전체 액세스 권한을 가진 기본 서비스 계정을 사용하도록 구성됩니다.

기본 서비스 계정 범위인 모든 Cloud API에 전체 액세스 허용으로 구성된 인스턴스에서 사용자가 IAM 권한이 없는 작업 또는 API 호출을 수행할 수 있습니다. 자세한 내용은 Compute Engine 기본 서비스 계정을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름을 클릭합니다.
인스턴스가 현재 시작된 경우 중지를 클릭합니다.
인스턴스가 중지된 후 수정을 클릭합니다.
서비스 계정의 드롭다운 메뉴에서 Compute Engine 기본 서비스 계정을 선택합니다.
액세스 범위 섹션에서 모든 Cloud API에 대한 전체 액세스 허용이 선택되지 않았는지 확인합니다.
저장을 클릭합니다.
시작을 클릭하여 인스턴스를 시작합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`HTTP load balancer`

API의 카테고리 이름: HTTP_LOAD_BALANCER

Compute Engine 인스턴스는 대상 HTTPS 프록시 대신 대상 HTTP 프록시를 사용하도록 구성된 부하 분산기를 사용합니다.

데이터 무결성을 보호하고 침입자가 커뮤니케이션을 훼손하지 못하도록 방해하려면 HTTPS 트래픽만 허용하도록 HTTP(S) 부하 분산기를 구성합니다. 자세한 내용은 외부 HTTP(S) 부하 분산 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 대상 프록시 페이지로 이동합니다.

대상 프록시로 이동
대상 프록시 목록에서 발견 항목에 있는 대상 프록시의 이름을 클릭합니다.
URL 맵에 있는 링크를 클릭합니다.
수정을 클릭합니다.
프런트엔드 구성을 클릭합니다.
모든 프런트엔드 IP 및 HTTP 트래픽을 허용하는 포트 구성을 삭제하고 HTTPS 트래픽을 허용하는 새 구성을 만듭니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Instance OS login disabled`

API의 카테고리 이름: INSTANCE_OS_LOGIN_DISABLED

OS 로그인이 이 Compute Engine 인스턴스에서 사용 중지되었습니다.

OS 로그인은 프로젝트의 모든 인스턴스에서 IAM으로 중앙 집중식 SSH 키 관리를 사용 설정하고 메타데이터 기반 SSH 키 구성을 사용 중지합니다. OS 로그인 설정 및 구성 방법을 알아보세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름을 클릭합니다.
로드된 인스턴스 세부정보 페이지에서 중지를 클릭합니다.
인스턴스가 중지된 후에 수정을 클릭합니다.
커스텀 메타데이터 섹션에서 enable-oslogin 키가 있는 항목의 값이 TRUE인지 확인합니다.
저장을 클릭합니다.
시작을 클릭하여 인스턴스를 시작합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Integrity monitoring disabled`

API의 카테고리 이름: INTEGRITY_MONITORING_DISABLED

무결성 모니터링이 GKE 클러스터에서 사용 중지되었습니다.

무결성 모니터링을 사용하면 Monitoring을 사용하여 보안 노드의 런타임 부팅 무결성을 모니터링하고 확인할 수 있습니다. 이렇게 하면 무결성 실패에 대응하고 손상된 노드가 클러스터에 배포되지 않도록 막을 수 있습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

노드가 프로비저닝된 다음에는 무결성 모니터링을 사용 설정하도록 업데이트할 수 없습니다. 무결성 모니터링이 사용 설정된 새 노드 풀을 만들어야 합니다.

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

Kubernetes 클러스터로 이동
발견 항목에서 클러스터 이름을 클릭합니다.
노드 풀 추가를 클릭합니다.
보안 탭에서 무결성 모니터링 사용 설정이 사용 설정되어 있는지 확인합니다.
만들기를 클릭합니다.
기존의 준수하지 않는 노드 풀에서 새 노드 풀로 워크로드를 마이그레이션하려면 다른 머신 유형으로 워크로드 마이그레이션을 참조하세요.
워크로드가 이전된 후에 원래의 준수하지 않는 노드 풀을 삭제합니다.
1. Kubernetes 클러스터 페이지의 노드 풀 메뉴에서 삭제할 노드 풀의 이름을 클릭합니다.
2. 노드 풀 삭제를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Intranode visibility disabled`

API의 카테고리 이름: INTRANODE_VISIBILITY_DISABLED

GKE 클러스터에 대해 노드 내 가시성이 사용 중지되었습니다.

노드 내 가시성을 사용 설정하면 노드 내 포드 간 트래픽이 네트워킹 패브릭에 표시됩니다. 이 기능을 사용하면 VPC 흐름 로깅 또는 기타 VPC 기능을 사용하여 인트라노드 내 트래픽을 모니터링하거나 제어할 수 있습니다. 로그를 가져오려면 선택된 서브네트워크에서 VPC 흐름 로그를 사용 설정해야 합니다. 자세한 내용은 VPC 흐름 로그 사용을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
네트워킹 섹션에서 노드 내 가시성 행의 수정 아이콘()을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없다면 몇 분 후 다시 시도하세요.
대화상자에서 노드 내 가시성 사용 설정을 선택합니다.
변경사항 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`IP alias disabled`

API의 카테고리 이름: IP_ALIAS_DISABLED

별칭 IP 범위가 사용 중지된 상태로 GKE 클러스터가 생성되었습니다.

별칭 IP 범위를 사용 설정하면 GKE 클러스터가 알려진 CIDR 블록에서 IP 주소를 할당하므로, 클러스터를 확장할 수 있고 Google Cloud 제품 및 항목과의 상호작용이 향상됩니다. 자세한 내용은 별칭 IP 범위 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

별칭 IP를 사용하도록 기존 클러스터를 마이그레이션할 수 없습니다. 별칭 IP를 사용 설정하여 새 클러스터를 만들려면 다음 안내를 따르세요.

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

Kubernetes 클러스터로 이동
만들기를 클릭합니다.
탐색창의 클러스터에서 네트워킹을 클릭합니다.
고급 네트워킹 옵션에서 VPC 기반 트래픽 라우팅 사용 설정(별칭 IP 사용)을 선택합니다.
만들기를 클릭합니다.

참고: 자체 재구성 중에는 클러스터를 수정할 수 없습니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`IP forwarding enabled`

API의 카테고리 이름: IP_FORWARDING_ENABLED

IP 전달이 Compute Engine 인스턴스에 사용 설정됩니다.

VM에 대한 데이터 패킷의 IP 전달을 사용 중지하여 데이터 손실 또는 정보 공개를 방지합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름 옆에 있는 상자를 선택합니다.
삭제를 클릭합니다.
인스턴스 만들기를 선택하여 새 인스턴스를 만들어 삭제한 항목을 대체합니다.
IP 전달이 사용 중지되었는지 확인하려면 관리, 디스크, 네트워킹, SSH 키를 클릭한 후 네트워킹을 클릭합니다.
네트워크 인터페이스에서 수정을 클릭합니다.
IP 전달의 드롭다운 메뉴에서 해제가 선택되었는지 확인합니다.
다른 인스턴스 매개변수를 지정한 후 만들기를 클릭합니다. 자세한 내용은 VM 인스턴스 만들기 및 시작을 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`KMS key not rotated`

API의 카테고리 이름: KMS_KEY_NOT_ROTATED

순환게재는 Cloud KMS 암호화 키에 구성되어 있지 않습니다.

암호화 키를 정기적으로 순환하면 키가 손상될 경우를 대비하여 보호 수준을 제공하고, 특정 키 버전에 대해 암호화 분석을 수행할 수 있는 암호화된 메시지 수를 제한합니다. 자세한 내용은 키 순환을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Cloud KMS 키로 이동
발견 항목에 표시된 키링의 이름을 클릭합니다.
발견 항목에 표시된 키의 이름을 클릭합니다.
순환 기간 수정을 클릭합니다.
순환 기간을 최대 90일로 설정합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`KMS project has owner`

API의 카테고리 이름: KMS_PROJECT_HAS_OWNER

사용자가 암호화 키가 있는 프로젝트에 대해 roles/Owner 권한을 갖습니다. 자세한 내용은 권한 및 역할을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM 페이지로 이동
필요한 경우 발견 항목에서 프로젝트를 선택합니다.
소유자 역할이 할당된 각 주 구성원에 대해 다음을 수행합니다.
1. 수정을 클릭합니다.
2. 권한 수정 패널의 소유자 역할 옆에서 삭제를 클릭합니다.
3. 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`KMS public key`

API의 카테고리 이름: KMS_PUBLIC_KEY

Cloud KMS Cryptokey 또는 Cloud KMS 키링이 공개되어 있고 인터넷에서 누구나 액세스할 수 있습니다. 자세한 내용은 Cloud KMS에서 IAM 사용을 참조하세요.

Cryptokey와 관련이 있는지에 대해 이 발견 항목을 해결하려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 암호화 키 페이지로 이동합니다.

암호화 키
이름에서 Security Health Analytics 발견 항목과 관련된 암호화 키가 포함된 키링을 선택합니다.
로드된 키링 세부정보 페이지에서 암호화 키 옆의 체크박스를 선택합니다.
정보 패널이 표시되지 않으면 정보 패널 표시 버튼을 클릭합니다.
역할/주 구성원 앞에 있는 필터 상자를 사용하여 allUsers 및 allAuthenticatedUsers의 주 구성원을 검색하고 삭제 를 클릭하여 해당 주 구성원에 대한 액세스 권한을 삭제합니다.

키링과 관련이 있는지에 대해 이 문제를 해결하려면 다음 단계를 따르세요.

Google Cloud 콘솔에서 암호화 키 페이지로 이동합니다.

암호화 키
발견 항목에서 키링이 있는 행을 찾아 체크박스를 선택합니다.
정보 패널이 표시되지 않으면 정보 패널 표시 버튼을 클릭합니다.
역할/주 구성원 앞에 있는 필터 상자를 사용하여 allUsers 및 allAuthenticatedUsers의 주 구성원을 검색하고 삭제 를 클릭하여 해당 주 구성원에 대한 액세스 권한을 삭제합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`KMS role separation`

API의 카테고리 이름: KMS_ROLE_SEPARATION

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

하나 이상의 주 구성원에 Cloud KMS 권한이 여러 개 할당되어 있습니다. 계정이 다른 Cloud KMS 권한과 Cloud KMS 관리자 권한을 동시에 가지는 것은 권장되지 않습니다. 자세한 내용은 권한 및 역할을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM으로 이동
발견 항목에 나열된 각 주 구성원에 대해 다음 안내를 따르세요.
1. 상속성 열을 보고 역할이 폴더 또는 조직 리소스에서 상속되었는지 확인합니다. 열에 상위 리소스에 대한 링크가 포함된 경우 해당 링크를 클릭하여 상위 리소스의 IAM 페이지로 이동합니다.
2. 주 구성원 옆에 있는 수정 을 클릭합니다.
3. 권한을 삭제하려면 Cloud KMS 관리자 옆에 있는삭제 를 클릭합니다. 주 구성원의 모든 권한을 삭제하려면 다른 모든 권한 옆에 있는 삭제를 클릭합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Legacy authorization enabled`

API의 카테고리 이름: LEGACY_AUTHORIZATION_ENABLED

기존 승인이 GKE 클러스터에서 사용 설정됩니다.

Kubernetes에서 역할 기반 액세스 제어(RBAC)를 사용하면 권한 집합이 포함된 규칙으로 역할을 정의하고 클러스터 및 네임스페이스 수준에서 권한을 부여할 수 있습니다. 이 기능으로 사용자가 특정 리소스에 대한 액세스 권한만 가지게 되므로 보안이 강화됩니다. 기존 속성 기반 액세스 제어(ABAC)를 사용 중지하는 것이 좋습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
Security Health Analytics 발견 항목 목록에 나열된 클러스터를 선택합니다.
수정을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없는 경우 몇 분 정도 기다린 후 다시 시도하세요.
기존 승인 드롭다운 목록에서 사용 중지됨을 선택합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Legacy metadata enabled`

API의 카테고리 이름: LEGACY_METADATA_ENABLED

기존 메타데이터가 GKE 클러스터에서 사용 설정됩니다.

Compute Engine의 인스턴스 메타데이터 서버는 기존 /0.1/ 및 /v1beta1/ 엔드포인트를 노출하며, 이는 메타데이터 쿼리 헤더를 적용하지 않습니다. 이 기능은 잠재적인 공격자가 인스턴스 메타데이터를 검색하기 어렵게 만드는 /v1/ API의 기능입니다. 필요하지 않으면 기존 /0.1/ 및 /v1beta1/ API를 사용 중지하는 것이 좋습니다.

자세한 내용은 기존 메타데이터 API 사용 중지 및 전환을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

새 클러스터를 만들 때 또는 새 노드 풀을 기존 클러스터에 추가할 때 기존 메타데이터 API를 사용 중지할 수만 있습니다. 기존 메타데이터 API를 사용 중지하도록 기존 클러스터를 업데이트하려면 여러 머신 유형에 워크로드 마이그레이션을 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Legacy network`

API의 카테고리 이름: LEGACY_NETWORK

기존 네트워크가 프로젝트에 존재합니다.

기존 네트워크에서는 새로운 Google Cloud 보안 기능이 상당수 지원되지 않으므로 기존 네트워크는 권장되지 않습니다. 대신 VPC 네트워크를 사용합니다. 자세한 내용은 기존 네트워크를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
기존에 없던 새로운 네트워크를 만들려면 네트워크 만들기를 클릭합니다.
VPC 네트워크 페이지로 돌아갑니다.
네트워크 목록에서 legacy_network를 클릭합니다.
VPC 네트워크 세부정보 페이지에서 VPC 네트워크 삭제를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Load balancer logging disabled`

API의 카테고리 이름: LOAD_BALANCER_LOGGING_DISABLED

부하 분산기의 백엔드 서비스에 대한 로깅이 사용 중지되었습니다.

부하 분산기에 로깅을 사용 설정하면 웹 애플리케이션의 HTTP(S) 네트워크 트래픽을 확인할 수 있습니다. 자세한 내용은 부하 분산기를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Cloud Load Balancing으로 이동
부하 분산기의 이름을 클릭합니다.
수정 을 클릭합니다.
백엔드 구성을 클릭합니다.
백엔드 구성 페이지에서 을 클릭합니다.
로깅 섹션에서 로깅 사용 설정을 선택하고 프로젝트에 가장 적합한 샘플링 레이트를 선택합니다.
백엔드 서비스 수정을 완료하려면 업데이트를 클릭합니다.
부하 분산기 수정을 완료하려면 업데이트를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Locked retention policy not set`

API의 카테고리 이름: LOCKED_RETENTION_POLICY_NOT_SET

로그에 잠긴 보존 정책이 설정되어 있지 않습니다.

보존 정책을 잠그면 로그 덮어쓰기 및 로그 버킷 삭제가 방해됩니다. 자세한 내용은 버킷 잠금을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 스토리지 브라우저 페이지로 이동합니다.

Storage 브라우저로 이동
Security Health Analytics 발견 항목 목록에 나열된 버킷을 선택합니다.
버킷 세부정보 페이지에서 보존 탭을 클릭합니다.
보존 정책이 설정되지 않았으면 보존 정책 설정을 클릭합니다.
보존 기간을 입력합니다.
저장을 클릭합니다. 보존 정책이 보존 탭에 표시됩니다.
잠금을 클릭하여 보존 정책이 단축되거나 삭제되지 않았는지 확인합니다.

주의: 보존 정책 잠금은 되돌릴 수 없으며, 전체 버킷을 삭제해야 만 실행 취소할 수 있습니다. 자세한 내용은 버킷 잠금을 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Log not exported`

API의 카테고리 이름: LOG_NOT_EXPORTED

리소스에 적절한 로그 싱크가 구성되어 있지 않습니다.

Cloud Logging을 사용하면 시스템 및 애플리케이션에서 문제의 근본 원인을 빠르게 찾을 수 있습니다. 하지만 대부분의 로그는 기본적으로 30일 동안만 보관됩니다. 스토리지 기간을 늘리려면 모든 로그 항목의 복사본을 내보냅니다. 자세한 내용은 로그 내보내기 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 로그 라우터 페이지로 이동합니다.

로그 라우터로 이동
싱크 만들기를 클릭합니다.
모든 로그를 내보내려면 포함 및 제외 필터를 비워 둡니다.
싱크 만들기를 클릭합니다.

참고: 이 안내에서는 프로젝트 수준에서 싱크를 만듭니다. 폴더 수준 또는 조직 수준에서도 싱크를 만들 수 있습니다. 자세한 내용은 Google Cloud 콘솔을 사용하여 로그 내보내기를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Master authorized networks disabled`

API의 카테고리 이름: MASTER_AUTHORIZED_NETWORKS_DISABLED

제어 영역 승인 네트워크는 GKE 클러스터에서 사용 설정되지 않습니다.

제어 영역 승인 네트워크는 지정된 IP 주소에서 클러스터의 제어 영역에 액세스할 수 없도록 차단하여 컨테이너 클러스터의 보안을 강화합니다. 자세한 내용은 제어 영역 액세스를 위해 승인된 네트워크 추가를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
Security Health Analytics 발견 항목 목록에 나열된 클러스터를 선택합니다.
수정을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없는 경우 몇 분 정도 기다린 후 다시 시도하세요.
제어 영역 승인 네트워크 드롭다운 목록에서 사용 설정됨을 선택합니다.
승인된 네트워크 추가를 클릭합니다.
사용할 승인된 네트워크를 지정하세요.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`MFA not enforced`

API의 카테고리 이름: MFA_NOT_ENFORCED

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

조직에 있는 일부 사용자의 다단계 인증, 구체적으로는 2단계 인증(2SV)이 사용 중지되었습니다.

다단계 인증은 승인되지 않은 액세스로부터 계정을 보호하는 데 사용되며 보안 침해된 로그인 사용자 인증 정보로부터 조직을 보호하는 데 가장 중요한 도구입니다. 자세한 내용은 2단계 확인으로 비즈니스 보호하기를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

관리 콘솔로 이동
모든 조직 단위에 2단계 인증을 적용합니다.

이 유형의 발견 항목 표시 안함

이 유형의 발견 항목을 표시하지 않으려면 이 유형의 향후 발견 항목을 자동으로 숨기는 숨기기 규칙을 정의합니다. 자세한 내용은 Security Command Center에서 발견 항목 숨기기를 참조하세요.

발견 항목을 표시하지 않을 때 권장되는 방법은 아니지만 Security Health Analytics 감지기가 애셋의 보안 발견 항목을 생성하지 않도록 애셋에 전용 보안 표시를 추가할 수도 있습니다.

이러한 발견 항목이 다시 활성화되지 않도록 방지하려면 true 값을 사용해서 보안 표시 allow_mfa_not_enforced를 애셋에 추가합니다.
특정 조직 단위의 잠재적 위반을 무시하려면 값 필드의 쉼표로 구분된 조직 단위 경로 목록을 사용해서 excluded_orgunits 보안 표시를 애셋에 추가합니다. 예를 들면 excluded_orgunits:/people/vendors/vendorA,/people/contractors/contractorA입니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Network not monitored`

API의 카테고리 이름: NETWORK_NOT_MONITORED

로그 측정항목과 알림은 VPC 네트워크 변경사항을 모니터링하도록 구성되지 않습니다.

네트워크 설정의 잘못되거나 승인되지 않은 변경사항을 감지하려면 VPC 네트워크 변경사항을 모니터링합니다. 자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.

필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.

  resource.type="gce_network"
  AND (protoPayload.methodName:"compute.networks.insert"
  OR protoPayload.methodName:"compute.networks.patch"
  OR protoPayload.methodName:"compute.networks.delete"
  OR protoPayload.methodName:"compute.networks.removePeering"
  OR protoPayload.methodName:"compute.networks.addPeering")

측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Network policy disabled`

API의 카테고리 이름: NETWORK_POLICY_DISABLED

네트워크 정책은 GKE 클러스터에서 사용 중지됩니다.

기본적으로 포드 간 통신이 열립니다. 열려 있는 통신은 네트워크 주소 변환 유무에 관계없이 노드 간 직접 포드 연결을 허용합니다. NetworkPolicy 리소스는 NetworkPolicy 리소스가 연결을 명시적으로 허용하지 않는 한 포드 간 연결을 제한하는 포드 수준 방화벽과 같습니다. 네트워크 정책 정의 방법을 알아보세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
Security Health Analytics 발견 항목에 나열된 클러스터의 이름을 클릭합니다.
네트워킹 아래 Calico Kubernetes 네트워크 정책 행에서 수정을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없는 경우 몇 분 정도 기다린 후 다시 시도하세요.
대화상자에서 제어 영역의 Calico Kubernetes 네트워크 정책 사용 설정 및 노드의 Calico Kubernetes 네트워크 정책 사용 설정을 선택합니다.
변경사항 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Nodepool boot CMEK disabled`

API의 카테고리 이름: NODEPOOL_BOOT_CMEK_DISABLED

이 노드 풀에 있는 부팅 디스크가 고객 관리 암호화 키(CMEK)로 암호화되지 않습니다. CMEK는 사용자가 노드 풀의 부팅 디스크에 대해 기본 암호화 키를 구성하도록 허용합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
클러스터 목록에서 발견 항목의 클러스터 이름을 클릭합니다.
노드 탭을 클릭합니다.
각 default-pool 노드 풀에서 삭제 를 클릭합니다.
확인 메시지가 나타나면 삭제를 클릭합니다.
CMEK를 사용하여 새 노드 풀을 만들려면 고객 관리 암호화 키(CMEK) 사용을 참조하세요. CMEK를 사용하면 Cloud KMS와 관련된 추가 비용이 발생합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Nodepool secure boot disabled`

API의 카테고리 이름: NODEPOOL_SECURE_BOOT_DISABLED

GKE 클러스터에 대해 보안 부팅이 사용 중지되었습니다.

노드 부트 구성요소의 디지털 서명을 확인하려면 보안 GKE 노드에 대해 보안 부팅을 사용 설정합니다. 자세한 내용은 보안 부팅을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

노드 풀이 프로비저닝되면 보안 부팅을 사용 설정하도록 업데이트할 수 없습니다. 보안 부팅이 사용 설정된 새 노드 풀을 만들어야 합니다.

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

Kubernetes 클러스터로 이동
발견 항목에서 클러스터 이름을 클릭합니다.
노드 풀 추가를 클릭합니다.
노드 풀 메뉴에서 다음을 수행합니다.
1. 새 노드 풀의 이름을 클릭하여 탭을 펼칩니다.
2. 보안을 선택한 다음 보안 옵션에서 보안 부팅 사용 설정을 선택합니다.
3. 만들기를 클릭합니다.
4. 기존의 준수하지 않는 노드 풀에서 새 노드 풀로 워크로드를 마이그레이션하려면 다른 머신 유형으로 워크로드 마이그레이션을 참조하세요.
5. 워크로드가 이전된 후에 원래의 준수하지 않는 노드 풀을 삭제합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Non org IAM member`

API의 카테고리 이름: NON_ORG_IAM_MEMBER

조직 또는 프로젝트 외부의 사용자에게 프로젝트 또는 조직의 IAM 권한이 있습니다. IAM 권한에 대해 자세히 알아보세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM으로 이동
조직 또는 프로젝트 외부 사용자 옆의 체크박스를 선택합니다.
삭제를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Object versioning disabled`

API의 카테고리 이름: OBJECT_VERSIONING_DISABLED

싱크가 구성된 스토리지 버킷에서 객체 버전 관리가 사용 설정되어 있지 않습니다.

삭제하거나 덮어쓴 객체를 검색할 수 있도록 Cloud Storage는 객체 버전 관리 기능을 제공합니다. Cloud Storage 데이터를 덮어쓰거나 실수로 삭제하지 않도록 하려면 객체 버전 관리를 사용하세요. 객체 버전 관리 사용 설정 방법을 알아보세요.

이 발견 항목을 해결하려면 적절한 값으로 gsutil versioning set on 명령어를 사용합니다.

    gsutil versioning set on gs://finding.assetDisplayName

finding.assetDisplayName을 관련 버킷의 이름으로 바꿉니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open Cassandra port`

API의 카테고리 이름: OPEN_CASSANDRA_PORT

IP 주소가 Cassandra 포트에 연결하도록 허용하는 방화벽 규칙이 공격자에게 Cassandra 서비스를 노출할 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

Cassandra 서비스 포트는 다음과 같습니다.

TCP - 7000, 7001, 7199, 8888, 9042, 9160, 61620, 61621

규칙을 의도적으로 사용 중지한 경우에도 취약한 방화벽 규칙에 대해 이 발견 항목이 생성됩니다. 사용 중지된 방화벽 규칙에 대한 활성 발견 항목은 사용 설정된 경우 원치 않는 트래픽을 허용하는 안전하지 않은 구성을 알려줍니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open ciscosecure websm port`

API의 카테고리 이름: OPEN_CISCOSECURE_WEBSM_PORT

모든 IP 주소의 CiscoSecure/WebSM 포트 연결을 허용하는 방화벽 규칙이 CiscoSecure/WebSM 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

CiscoSecure/WebSM 서비스 포트는 다음과 같습니다.

TCP - 9090

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open directory services port`

API의 카테고리 이름: OPEN_DIRECTORY_SERVICES_PORT

모든 IP 주소의 디렉터리 포트 연결을 허용하는 방화벽 규칙이 디렉터리 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

디렉터리 서비스 포트는 다음과 같습니다.

TCP - 445
UDP - 445

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open DNS port`

API의 카테고리 이름: OPEN_DNS_PORT

모든 IP 주소의 DNS 포트 연결을 허용하는 방화벽 규칙이 DNS 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

DNS 서비스 포트는 다음과 같습니다.

TCP - 53
UDP - 53

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open Elasticsearch port`

API의 카테고리 이름: OPEN_ELASTICSEARCH_PORT

모든 IP 주소의 Elasticsearch 포트 연결을 허용하는 방화벽 규칙이 Elasticsearch 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

Elasticsearch 서비스 포트는 다음과 같습니다.

TCP - 9200, 9300

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open firewall`

API의 카테고리 이름: OPEN_FIREWALL

0.0.0.0/0과 같은 모든 IP 주소 또는 모든 포트의 연결을 허용하는 방화벽 규칙이 의도하지 않은 소스로부터의 공격에 리소스를 불필요하게 노출시킬 수 있습니다. 이러한 규칙을 삭제하거나 의도한 소스 IP 범위 또는 포트로 명시적으로 범위를 지정해야 합니다. 예를 들어 공개로 의도된 애플리케이션에서는 80 및 443과 같이 애플리케이션에 필요한 포트로 허용 포트를 제한하는 것이 좋습니다. 애플리케이션에서 모든 IP 주소 또는 포트의 연결을 허용해야 하는 경우 허용 목록에 애셋을 추가하는 것이 좋습니다. 방화벽 규칙 업데이트에 대해 자세히 알아보세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 규칙 페이지로 이동합니다.

방화벽 규칙으로 이동
Security Health Analytics 발견 항목에 나열된 방화벽 규칙을 클릭한 다음 수정을 클릭합니다.
소스 IP 범위에서 허용되는 IP 범위를 제한하도록 IP 값을 수정합니다.
프로토콜 및 포트에서 지정된 프로토콜 및 포트를 선택하고, 허용되는 프로토콜을 선택하고, 허용되는 포트를 입력합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open FTP port`

API의 카테고리 이름: OPEN_FTP_PORT

모든 IP 주소의 FTP 포트 연결을 허용하는 방화벽 규칙이 FTP 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

FTP 서비스 포트는 다음과 같습니다.

TCP - 21

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open group IAM member`

API의 카테고리 이름: OPEN_GROUP_IAM_MEMBER

조직, 프로젝트 또는 폴더에 액세스할 수 있는 하나 이상의 주 구성원은 승인 없이 조인할 수 있는 Google 그룹스 계정입니다.

Google Cloud 고객은 Google 그룹스를 사용하여 자신의 조직에 있는 구성원에 대해 역할 및 권한을 관리하거나 사용자 컬렉션에 액세스 정책을 적용할 수 있습니다. 구성원에 직접 역할을 부여하는 대신 관리자가 Google 그룹스에 역할 및 권한을 부여하고 구성원을 특정 그룹에 추가할 수 있습니다. 그룹 구성원은 구성원이 특정 리소스 및 서비스에 액세스할 수 있도록 그룹의 모든 역할 및 권한을 상속합니다.

공개 Google 그룹스 계정이 IAM 바인딩에서 주 구성원으로 사용되는 경우 누구나 하위 그룹을 통해 그룹에 직접 또는 간접적으로 가입하여 연결된 역할을 상속할 수 있습니다. 공개 그룹의 역할을 취소하거나 이러한 그룹에 대한 액세스를 제한하는 것이 좋습니다.

이 발견 항목을 해결하려면 다음 절차 중 하나를 수행합니다.

IAM 정책에서 그룹 삭제

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

IAM으로 이동
필요한 경우 발견 항목에서 프로젝트, 폴더, 조직을 선택합니다.
발견 항목에 식별된 각 공개 그룹의 역할을 취소합니다.

공개 그룹에 대한 액세스 제한

Google 그룹스에 로그인합니다.
각 공개 그룹과 하위 그룹의 설정을 업데이트하여 그룹에 가입할 수 있는 사용자와 해당 사용자를 승인해야 하는 사용자를 지정합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open HTTP port`

API의 카테고리 이름: OPEN_HTTP_PORT

모든 IP 주소의 HTTP 포트 연결을 허용하는 방화벽 규칙이 HTTP 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

HTTP 서비스 포트는 다음과 같습니다.

TCP - 80

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open LDAP port`

API의 카테고리 이름: OPEN_LDAP_PORT

모든 IP 주소의 LDAP 포트 연결을 허용하는 방화벽 규칙이 LDAP 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

LDAP 서비스 포트는 다음과 같습니다.

TCP - 389, 636
UDP - 389

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open Memcached port`

API의 카테고리 이름: OPEN_MEMCACHED_PORT

모든 IP 주소의 Memcached 포트 연결을 허용하는 방화벽 규칙이 Memcached 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

Memcach 연결 서비스 포트는 다음과 같습니다.

TCP - 11211, 11214, 11215
UDP - 11211, 11214, 11215

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open MongoDB port`

API의 카테고리 이름: OPEN_MONGODB_PORT

모든 IP 주소의 MongoDB 포트 연결을 허용하는 방화벽 규칙이 공격자에게 MongoDB 서비스를 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

MongoDB 서비스 포트는 다음과 같습니다.

TCP - 27017, 27018, 27019

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open MySQL port`

API의 카테고리 이름: OPEN_MYSQL_PORT

모든 IP 주소의 MySQL 포트 연결을 허용하는 방화벽 규칙이 MySQL 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

MySQL 서비스 포트는 다음과 같습니다.

TCP - 3306

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open NetBIOS port`

API의 카테고리 이름: `OPEN_NETBIOS_PORT

모든 IP 주소의 NetBIOS 포트 연결을 허용하는 방화벽 규칙이 NetBIOS 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

NetBIOS 서비스 포트는 다음과 같습니다.

TCP - 137, 138, 139
UDP - 137, 138, 139

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open OracleDB port`

API의 카테고리 이름: OPEN_ORACLEDB_PORT

모든 IP 주소의 OracleDB 포트 연결을 허용하는 방화벽 규칙이 OracleDB 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

OracleDB 서비스 포트는 다음과 같습니다.

TCP - 1521, 2483, 2484
UDP - 2483, 2484

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open POP3 port`

API의 카테고리 이름: OPEN_POP3_PORT

모든 IP 주소의 POP3 포트 연결을 허용하는 방화벽 규칙이 POP3 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

POP3 서비스 포트는 다음과 같습니다.

TCP - 110

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open PostgreSQL port`

API의 카테고리 이름: OPEN_POSTGRESQL_PORT

모든 IP 주소의 PostgreSQL 포트 연결을 허용하는 방화벽 규칙이 PostgreSQL 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

PostgreSQL 서비스 포트는 다음과 같습니다.

TCP - 5432
UDP - 5432

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open RDP port`

API의 카테고리 이름: OPEN_RDP_PORT

모든 IP 주소의 RDP 포트 연결을 허용하는 방화벽 규칙이 RDP 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

RDP 서비스 포트는 다음과 같습니다.

TCP - 3389
UDP - 3389

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open Redis port`

API의 카테고리 이름: OPEN_REDIS_PORT

모든 IP 주소의 Redis 포트 연결을 허용하는 방화벽 규칙이 Redis 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

Redis 서비스 포트는 다음과 같습니다.

TCP - 6379

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open SMTP port`

API의 카테고리 이름: OPEN_SMTP_PORT

모든 IP 주소의 SMTP 포트 연결을 허용하는 방화벽 규칙이 SMTP 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

SMTP 서비스 포트는 다음과 같습니다.

TCP - 25

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open SSH port`

API의 카테고리 이름: OPEN_SSH_PORT

모든 IP 주소의 SSH 포트 연결을 허용하는 방화벽 규칙이 SSH 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

SSH 서비스 포트는 다음과 같습니다.

SCTP - 22
TCP - 22

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Open Telnet port`

API의 카테고리 이름: OPEN_TELNET_PORT

모든 IP 주소의 Telnet 포트 연결을 허용하는 방화벽 규칙이 Telnet 서비스를 공격자에게 노출시킬 수 있습니다. 자세한 내용은 VPC 방화벽 규칙 개요를 참조하세요.

Telnet 서비스 포트는 다음과 같습니다.

TCP - 23

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 방화벽 페이지로 이동합니다.

방화벽으로 이동
방화벽 규칙 목록에서 발견 항목의 방화벽 규칙 이름을 클릭합니다.
수정을 클릭합니다.
소스 IP 범위에서 0.0.0.0/0을 삭제합니다.
인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
인스턴스에서 열려는 특정 프로토콜 및 포트를 추가합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Org policy Confidential VM policy`

API의 카테고리 이름: ORG_POLICY_CONFIDENTIAL_VM_POLICY

Compute Engine 리소스가 constraints/compute.restrictNonConfidentialComputing 조직 정책을 준수하지 않습니다. 이 조직 정책 제약조건에 대한 자세한 내용은 조직 정책 제약조건 적용을 참조하세요.

조직 정책에 의해 이 VM에 컨피덴셜 VM 서비스가 사용 설정되어 있어야 합니다. 이 서비스를 사용 설정하지 않은 VM은 런타임 메모리 암호화를 사용하지 않아 런타임 메모리 공격에 노출됩니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름을 클릭합니다.
VM에 컨피덴셜 VM 서비스가 필요하지 않으면 이를 새 폴더 또는 프로젝트로 이동합니다.
VM에 컨피덴셜 VM이 필요하면 삭제를 클릭합니다.
컨피덴셜 VM을 사용 설정하여 새 인스턴스를 만들려면 빠른 시작: 컨피덴셜 VM 인스턴스 만들기를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Org policy location restriction`

API의 카테고리 이름: ORG_POLICY_LOCATION_RESTRICTION

조직 정책 gcp.resourceLocations 제약조건을 사용하면 새 리소스 만들기를 선택한 Cloud 리전으로 제한할 수 있습니다. 자세한 내용은 리소스 위치 제한을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

ORG_POLICY_LOCATION_RESTRICTION 검사 프로그램이 여러 리소스 유형을 지원하며 해결 안내는 각 리소스마다 다릅니다. 위치 위반 해결에 대한 일반적인 접근 방법은 다음을 포함합니다.

리전 외부 리소스 또는 데이터를 리전 내 리소스로 복사, 이동, 백업합니다. 개별 서비스에 대한 문서를 참조하여 리소스 이동에 대한 안내를 확인하세요.
리전 외부의 원래 리소스 또는 데이터를 삭제합니다.

이 접근 방법을 모든 리소스 유형에 사용할 수는 없습니다. 안내는 발견 항목에 제공된 맞춤설정된 권장사항을 참조하세요.

추가 고려사항

이 발견 항목을 해결할 때는 다음 사항을 고려하세요.

관리형 리소스

리소스의 수명 주기는 경우에 따라 다른 리소스에서 관리 및 제어됩니다. 예를 들어 관리형 Compute Engine 인스턴스 그룹은 인스턴스 그룹의 자동 확장 정책에 따라 Compute Engine 인스턴스를 만들고 폐기합니다. 관리 및 관리 리소스가 위치 시행을 위한 범위 내에 있는 경우, 둘 다 조직 정책을 위반하는 것으로 신고될 수 있습니다. 운영 안정성을 보장하기 위한 관리형 리소스의 발견 항목에 대한 문제 해결은 리소스 관리에서 수행되어야 합니다.

사용 중인 리소스

특정 리소스는 다른 리소스에서 사용됩니다. 예를 들어 실행 중인 Compute Engine 인스턴스에 연결된 Compute Engine 디스크는 인스턴스에서 사용 중인 것으로 간주됩니다. 사용 중인 리소스가 위치 조직 정책을 위반할 경우 위치 위반을 해결하기 전 리소스가 사용 중이 아닌지 확인해야 합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`OS login disabled`

API의 카테고리 이름: OS_LOGIN_DISABLED

OS 로그인이 이 Compute Engine 인스턴스에서 사용 중지되었습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 메타데이터 페이지로 이동합니다.

메타데이터로 이동
수정을 클릭한 후 항목 추가를 클릭합니다.
enable-oslogin 키와 TRUE 값이 포함된 항목을 추가합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Over privileged account`

API의 카테고리 이름: OVER_PRIVILEGED_ACCOUNT

GKE 노드가 Compute Engine 기본 서비스 노드를 사용 중입니다. 이 노드는 기본적으로 액세스 범위가 넓으며, GKE 클러스터를 실행하기에 너무 많은 권한을 포함할 수 있습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

최소 권한 Google 서비스 계정 사용 안내를 따릅니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Over privileged scopes`

API의 카테고리 이름: OVER_PRIVILEGED_SCOPES

노드 서비스 계정에 광범위한 액세스 범위가 있습니다.

액세스 범위는 인스턴스에 권한을 지정하는 기존 방법입니다. 공격으로 권한 에스컬레이션이 발생할 가능성을 줄이기 위해 최소 권한만 있는 서비스 계정을 만들고 이 계정을 사용하여 GKE 클러스터를 실행합니다.

이 발견 항목을 해결하려면 최소 권한 Google 서비스 계정 사용 안내를 따릅니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Over privileged service account user`

API의 카테고리 이름: OVER_PRIVILEGED_SERVICE_ACCOUNT_USER

사용자에게는 특정 서비스 계정 대신 프로젝트, 폴더 또는 조직 수준의 iam.serviceAccountUser 또는 iam.serviceAccountTokenCreator 역할이 있습니다.

이 역할을 프로젝트, 폴더 또는 조직의 사용자에게 부여하면 사용자가 해당 범위의 모든 기존 서비스 계정 및 향후 서비스 계정에 액세스할 수 있습니다. 이로 인해 의도치 않은 권한 에스컬레이션이 발생할 수 있습니다. 자세한 내용은 서비스 계정 권한을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM 페이지로 이동
필요한 경우 발견 항목에서 프로젝트, 폴더, 조직을 선택합니다.
roles/iam.serviceAccountUser 또는 roles/iam.serviceAccountTokenCreator에 할당된 각 주 구성원에 다음을 수행합니다.
1. 수정을 클릭합니다.
2. 권한 수정 패널의 역할 옆에서 삭제를 클릭합니다.
3. 저장을 클릭합니다.
이 가이드에 따라 개별 사용자에게 단일 서비스 계정을 가장할 수 있는 권한을 부여합니다. 선택한 사용자의 가장을 허용하려는 각 서비스 계정에 대해 이 가이드를 따라야 합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Owner not monitored`

API의 카테고리 이름: OWNER_NOT_MONITORED

로그 측정항목 및 알림은 프로젝트 소유권 할당 또는 변경사항을 모니터링하도록 구성되지 않습니다.

IAM 소유자 역할은 프로젝트에서 가장 높은 권한 수준을 갖습니다. 리소스를 보호하려면 새 소유자가 추가되거나 삭제될 때 알림을 받도록 알림을 설정하세요. 자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.

필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.

  (protoPayload.serviceName="cloudresourcemanager.googleapis.com")
  AND (ProjectOwnership OR projectOwnerInvitee)
  OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="REMOVE"
  AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")
  OR (protoPayload.serviceData.policyDelta.bindingDeltas.action="ADD"
  AND protoPayload.serviceData.policyDelta.bindingDeltas.role="roles/owner")

측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Pod security policy disabled`

API의 카테고리 이름: POD_SECURITY_POLICY_DISABLED

GKE 클러스터에서 PodSecurityPolicy가 사용 중지됩니다.

PodSecurityPolicy는 클러스터에서 포드 생성 및 업데이트 요청을 검증하는 허용 컨트롤러 리소스입니다. 클러스터는 PodSecurityPolicy에 정의된 조건을 충족하지 않는 포드를 허용하지 않습니다.

이 발견 항목을 해결하려면 PodSecurityPolicies를 정의 및 승인하고 PodSecurityPolicy 컨트롤러를 사용 설정합니다. 자세한 내용은 PodSecurityPolicies 사용을 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Primitive roles used`

API의 카테고리 이름: PRIMITIVE_ROLES_USED

사용자에게 roles/owner, roles/editor, roles/viewer의 IAM 기본 역할 중 하나가 있습니다. 이러한 역할은 권한이 너무 크므로 사용하면 안 됩니다. 대신 프로젝트별 기준으로만 할당해야 합니다.

자세한 내용은 역할 이해하기를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM 정책으로 이동
대신 기본 역할이 할당된 각 사용자에 대해 보다 세분화된 역할을 사용하는 것이 좋습니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Private cluster disabled`

API의 카테고리 이름: PRIVATE_CLUSTER_DISABLED

GKE 클러스터에 비공개 클러스터가 사용 중지되어 있습니다.

비공개 클러스터에서는 노드에 비공개 IP 주소만 포함할 수 있습니다. 이 기능은 노드의 아웃바운드 인터넷 액세스를 제한합니다. 클러스터 노드에 공개 IP 주소가 없으면 공개 인터넷에 검색되거나 노출되지 않습니다. 내부 부하 분산기를 통해 노드에 트래픽을 계속 라우팅할 수 있습니다. 자세한 내용은 비공개 클러스터를 참조하세요.

기존 클러스터를 비공개로 설정할 수 없습니다. 이 발견 항목을 수정하려면 새 비공개 클러스터를 만듭니다.

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

Kubernetes 클러스터로 이동
클러스터 만들기를 클릭합니다.
탐색 메뉴의 클러스터에서 네트워킹을 선택합니다.
비공개 클러스터의 라디오 버튼을 선택합니다.
고급 네트워킹 옵션에서 VPC 기반 트래픽 라우팅 사용 설정(별칭 IP 사용) 체크박스를 선택합니다.
만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Private Google access disabled`

API의 카테고리 이름: PRIVATE_GOOGLE_ACCESS_DISABLED

Google 공개 API에 액세스할 수 없는 비공개 서브넷이 있습니다.

비공개 Google 액세스를 사용하면 내부(비공개) IP 주소만 있는 VM 인스턴스가 Google API 및 서비스의 공개 IP 주소에 연결할 수 있습니다.

자세한 내용은 Google 비공개 액세스 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud Console에서 VPC 네트워크 페이지로 이동합니다.

VPC 네트워크로 이동
네트워크 목록에서 원하는 네트워크 이름을 클릭합니다.
VPC 네트워크 세부정보 페이지에서 서브넷 탭을 클릭합니다.
서브넷 목록에서 발견 항목의 Kubernetes 클러스터와 연관된 서브넷 이름을 클릭합니다.
서브넷 세부정보 페이지에서 수정 을 클릭합니다.
비공개 Google 액세스에서 사용을 클릭합니다.
저장을 클릭합니다.
외부 트래픽만 Google API에 연결되는 VM 인스턴스에서 공개(외부) IP를 삭제하려면 정적 외부 IP 주소 할당 해제를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Public bucket ACL`

API의 카테고리 이름: PUBLIC_BUCKET_ACL

버킷이 공개되어 있고 인터넷에서 누구나 액세스할 수 있습니다.

자세한 내용은 액세스 제어 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 스토리지 브라우저 페이지로 이동합니다.

Storage 브라우저로 이동
Security Health Analytics 발견 항목 목록에 나열된 버킷을 선택합니다.
버킷 세부정보 페이지에서 권한 탭을 클릭합니다.
보기 기준 옆에 있는 역할을 클릭합니다.
필터 상자에서 allUsers 및 allAuthenticatedUsers를 검색합니다.
삭제 를 클릭하여 allUsers 및 allAuthenticatedUsers에 부여된 모든 IAM 권한을 삭제합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Public Compute image`

API의 카테고리 이름: PUBLIC_COMPUTE_IMAGE

Compute Engine 이미지가 공개되어 있고 인터넷의 누구나 액세스할 수 있습니다. allUsers는 인터넷의 누구나 그리고 allAuthenticatedUsers는 Google 계정으로 인증된 누구나 조직 내 사용자로 제한되지 않음을 나타냅니다.

Compute Engine 이미지에는 암호화 키 또는 라이선스 소프트웨어와 같은 민감한 정보가 포함될 수 있습니다. 이러한 민감한 정보에 공개적으로 액세스할 수 있어서는 안 됩니다. 이 Compute Engine 이미지를 공개하려는 경우 민감한 정보가 포함되어 있지 않은지 확인하세요.

자세한 내용은 액세스 제어 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Compute Engine 이미지 페이지로 이동합니다.

Compute Engine 이미지로 이동
public-image 이미지 옆에 있는 상자를 선택한 후 정보 패널 표시를 클릭합니다.
필터 상자에서 allUsers 및 allAuthenticatedUsers의 주 구성원을 검색합니다.
사용자를 삭제할 역할을 펼칩니다.
삭제를 클릭하여 역할에서 사용자를 삭제합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Public dataset`

API의 카테고리 이름: PUBLIC_DATASET

BigQuery 데이터 세트가 공개되어 있고 인터넷의 누구나 액세스할 수 있습니다. IAM 주 구성원 allUsers는 인터넷의 누구나 그리고 allAuthenticatedUsers는 Google 서비스에 로그인된 누구나 조직 내 사용자로 제한되지 않음을 나타냅니다.

자세한 내용은 데이터 세트에 대한 액세스 제어를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

BigQuery 데이터 세트로 이동
데이터 세트 목록에서 발견 항목에서 식별된 데이터 세트의 이름을 클릭합니다. 데이터 세트 정보 패널이 열립니다.
데이터 세트 정보 패널 상단에서 공유를 클릭합니다.
드롭다운 메뉴에서 권한을 클릭합니다.
데이터 세트 권한 패널에서 allUsers 및 allAuthenticatedUsers를 입력하고, 이러한 주 구성원의 액세스 권한을 삭제합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Public IP address`

API의 카테고리 이름: PUBLIC_IP_ADDRESS

Compute Engine 인스턴스에 공개 IP 주소가 있습니다.

조직의 공격 표면을 줄이기 위해서는 VM에 공개 IP 주소를 할당하지 않는 것이 좋습니다. 중지된 인스턴스는 공개 IP 발견 항목으로 계속 플래그가 지정될 수 있습니다. 예를 들어 네트워크 인터페이스가 시작 시 임시 공개 IP 주소를 할당하도록 구성되어 있는 경우가 있습니다. 중지된 인스턴스의 네트워크 구성에 외부 액세스가 포함되어서는 안 됩니다.

자세한 내용은 VM 인스턴스에 안전하게 연결을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
인스턴스 목록에서 발견 항목의 인스턴스 이름 옆에 있는 상자를 선택합니다.
수정을 클릭합니다.
네트워크 인터페이스에 있는 각 인터페이스에 대해 수정을 클릭하고 외부 IP를 없음으로 설정합니다.
완료를 클릭한 다음 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Public log bucket`

API의 카테고리 이름: PUBLIC_LOG_BUCKET

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

스토리지 버킷이 공개되어 있고 로그 싱크로 사용됩니다. 즉, 인터넷의 누구나 이 버킷에 저장된 로그에 액세스할 수 있습니다. allUsers는 인터넷의 누구나 그리고 allAuthenticatedUsers는 Google 서비스에 로그인된 누구나 조직 내 사용자로 제한되지 않음을 나타냅니다.

자세한 내용은 액세스 제어 개요를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud Storage 브라우저 페이지로 이동합니다.

Cloud Storage 브라우저로 이동
버킷 목록에서 발견 항목에 표시된 버킷의 이름을 클릭합니다.
권한 탭을 클릭합니다.
주 구성원 목록에서 allUsers 및 allAuthenticatedUsers를 삭제합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Public SQL instance`

API의 카테고리 이름: PUBLIC_SQL_INSTANCE

SQL 인스턴스에 허용되는 네트워크로 0.0.0.0/0이 추가되었습니다. 이 경우에는 모든 IPv4 클라이언트에서 네트워크 방화벽을 통과하고 인스턴스 로그인을 시도할 수 있으며 여기에는 허용할 의도가 없는 클라이언트도 포함됩니다. 클라이언트에서 인스턴스에 로그인하려면 유효한 사용자 인증 정보가 필요합니다.

자세한 내용은 승인된 네트워크로 승인을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔의 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
탐색 패널에서 연결을 클릭합니다.
승인된 네트워크에서 0.0.0.0/0을 삭제하고 인스턴스 연결을 허용하려는 특정 IP 주소 또는 IP 범위를 추가합니다.
완료를 클릭한 다음 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Pubsub CMEK disabled`

API의 카테고리 이름: PUBSUB_CMEK_DISABLED

Pub/Sub 주제는 고객 관리 암호화 키(CMEK)로 암호화되지 않습니다.

CMEK를 사용하는 경우, Cloud KMS에서 만들고 관리하는 키가 Google에서 데이터 암호화를 위해 사용되는 키를 래핑하여 데이터 액세스 권한을 더 세밀하게 제어할 수 있습니다.

이 발견 항목을 조정하려면 기존 주제를 삭제하고 새 주제를 만드세요.

Google Cloud 콘솔에서 Pub/Sub 주제 페이지로 이동합니다.

주제로 이동
필요한 경우 Pub/Sub 주제가 포함된 프로젝트를 선택합니다.
발견 항목에 나열된 주제 옆에 있는 체크박스를 선택한 후 삭제를 클릭합니다.
CMEK가 사용 설정된 새 Pub/Sub 주제를 만들려면 고객 관리 암호화 키 사용을 참조하세요. CMEK를 사용하면 Cloud KMS와 관련된 추가 비용이 발생합니다.
CMEK가 사용 설정된 Pub/Sub 주제에 발견 항목을 게시하거나 기타 데이터를 게시합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Route not monitored`

API의 카테고리 이름: ROUTE_NOT_MONITORED

로그 측정항목과 알림은 VPC 네트워크 경로 변경사항을 모니터링하도록 구성되지 않습니다.

Google Cloud Routes는 네트워크 트래픽이 VM 인스턴스에서 대상 IP로 이동하는 경로를 정의하는 대상과 홉입니다. 경로 표의 변경사항을 모니터링하면 모든 VPC 트래픽이 예상 경로를 통해 전달되도록 할 수 있습니다.

자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.

필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.

  resource.type="gce_route"
  AND (protoPayload.methodName:"compute.routes.delete"
  OR protoPayload.methodName:"compute.routes.insert")

측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Redis role used on org`

API의 카테고리 이름: REDIS_ROLE_USED_ON_ORG

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

Redis IAM 역할은 조직 또는 폴더 수준에서 할당됩니다.

다음 Redis IAM 역할은 조직 또는 폴더 수준이 아닌 프로젝트별로 할당되어야 합니다.

roles/redis.admin
roles/redis.viewer
roles/redis.editor

자세한 내용은 액세스 제어 및 권한을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM 정책으로 이동
발견 항목에 표시된 Redis IAM 역할을 삭제하고 대신 개별 프로젝트에 추가합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Release channel disabled`

API의 카테고리 이름: RELEASE_CHANNEL_DISABLED

GKE 클러스터가 출시 채널에 구독되지 않습니다.

GKE 클러스터로 버전 업그레이드를 자동화하려면 출시 채널에 구독합니다. 또한 이 기능은 기능 수 및 필요한 안정성 수준으로 버전 관리 복잡성을 줄여줍니다. 자세한 내용은 출시 채널을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Kubernetes 클러스터로 이동
클러스터 기본사항 섹션에서 출시 채널 행의 수정 아이콘()을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없다면 몇 분 후 다시 시도하세요.
대화상자에서 출시 채널을 선택한 후 구독할 출시 채널을 선택합니다.

클러스터의 제어 영역 버전을 출시 채널로 업그레이드할 수 없으면 채널이 옵션으로 사용 중지될 수 있습니다.
변경사항 저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`RSASHA1 for signing`

API의 카테고리 이름: RSASHA1_FOR_SIGNING

RSASHA1은 Cloud DNS 영역의 키 서명에 사용됩니다. 키 서명에 사용된 알고리즘은 취약해서는 안 됩니다.

이 발견 항목을 해결하려면 고급 서명 옵션 가이드에 따라 알고리즘을 권장 항목으로 바꿉니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Service account key not rotated`

API의 카테고리 이름: SERVICE_ACCOUNT_KEY_NOT_ROTATED

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

사용자 관리 서비스 계정 키가 90일 이상 순환되지 않았습니다.

일반적으로 사용자 관리 서비스 계정 키는 분실, 손상, 도용 가능성이 있는 이전 키로 데이터에 액세스할 수 없도록 최소 90일마다 순환해야 합니다. 자세한 내용은 서비스 계정 키를 순환하여 유출된 키로 인한 보안 위험 감소을 참조하세요.

공개 키/비공개 키 쌍을 직접 생성한 후 하드웨어 보안 모듈(HSM)에 비공개 키를 저장하고 공개 키를 Google에 업로드한 경우 90일마다 키를 순환하지 않아도 될 수 있습니다. 대신 키가 손상되었다고 확신하면 키를 순환할 수 있습니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.

서비스 계정으로 이동
필요에 따라 발견 항목에서 표시된 프로젝트를 선택합니다.
서비스 계정 목록에서 발견 항목에 나열된 서비스 계정을 찾고 삭제를 클릭합니다. 계속하기 전에 서비스 계정을 삭제하여 프로덕션 리소스에 미칠 수 있는 영향을 고려하세요.
기존 항목을 대신할 새 서비스 계정 키를 만듭니다. 자세한 내용은 서비스 계정 키 만들기를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Service account role separation`

API의 카테고리 이름: SERVICE_ACCOUNT_ROLE_SEPARATION

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

조직에서 1명 이상의 주 구성원에게 여러 서비스 계정 권한이 할당되었습니다. 어떤 계정도 다른 서비스 계정 권한과 함께 서비스 계정 관리자 권한을 동시에 포함하지 않아야 합니다. 서비스 계정 및 여기에 사용할 수 있는 역할에 대해 자세히 알아보려면 서비스 계정을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

IAM으로 이동
발견 항목에 나열된 각 주 구성원에 대해 다음 안내를 따르세요.
1. 상속성 열을 보고 역할이 폴더 또는 조직 리소스에서 상속되었는지 확인합니다. 열에 상위 리소스에 대한 링크가 포함된 경우 해당 링크를 클릭하여 상위 리소스의 IAM 페이지로 이동합니다.
2. 주 구성원 옆에 있는 수정 을 클릭합니다.
3. 권한을 삭제하려면 서비스 계정 관리자 옆에서 삭제 를 클릭합니다. 모든 서비스 계정 권한을 삭제하려면 다른 모든 권한 옆에 있는 삭제를 클릭합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Shielded VM disabled`

API의 카테고리 이름: SHIELDED_VM_DISABLED

이 Compute Engine 인스턴스에서 보안 VM이 사용 중지되었습니다.

보안 VM은 루트킷과 부트킷으로부터 보호하는 데 도움이 되는 보안 제어로 강화된 Google Cloud의 가상 머신(VM)입니다. 보안 VM을 사용하면 부트 로더와 펌웨어가 서명 및 인증되었는지 확인할 수 있습니다. 보안 VM에 대해 자세히 알아보기

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 VM 인스턴스 페이지로 이동합니다.

VM 인스턴스로 이동
Security Health Analytics 발견 항목과 관련된 인스턴스를 선택합니다.
로드된 인스턴스 세부정보 페이지에서 중지를 클릭합니다.
인스턴스가 중지된 후 수정을 클릭합니다.
보안 VM 섹션에서 vTPM 사용 설정 및 무결성 모니터링 사용 설정 간에 전환하여 보안 VM을 사용 설정합니다.
선택적으로 커스텀 또는 서명되지 않은 드라이버를 사용하지 않는 경우 보안 부팅도 사용 설정합니다.
저장을 클릭합니다. 인스턴스 세부정보 페이지에 새 구성이 표시됩니다.
시작을 클릭하여 인스턴스를 시작합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL CMEK disabled`

API의 카테고리 이름: SQL_CMEK_DISABLED

SQL 데이터베이스 인스턴스가 고객 관리 암호화 키(CMEK)를 사용하지 않습니다.

CMEK를 사용하는 경우, Cloud KMS에서 만들고 관리하는 키가 Google에서 데이터 암호화를 위해 사용되는 키를 래핑하여 데이터 액세스 권한을 더 세밀하게 제어할 수 있습니다. 자세한 내용은 MySQL용 Cloud SQL, PostgreSQL용 Cloud SQL, SQL Server용 Cloud SQL의 해당 제품의 CMEK 개요를 참조하세요. CMEK를 사용하면 Cloud KMS와 관련된 추가 비용이 발생합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
삭제를 클릭합니다.
CMEK가 사용 설정된 새 인스턴스를 만들려면 안내에 따라 해당 제품에 대해 CMEK를 구성합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL contained database authentication`

API의 카테고리 이름: SQL_CONTAINED_DATABASE_AUTHENTICATION

SQL Server용 Cloud SQL 데이터베이스 인스턴스에서 contained database authentication 데이터베이스 플래그가 해제로 설정되지 않았습니다.

contained database authentication 플래그는 포함된 데이터베이스를 만들거나 데이터베이스 엔진에 연결할 수 있는지 여부를 제어합니다. 포함된 데이터베이스에는 데이터베이스를 정의하는 데 필요한 모든 데이터베이스 설정과 메타데이터가 포함되며 데이터베이스가 설치된 데이터베이스 엔진의 인스턴스에 구성 종속 항목이 없습니다.

다음과 같은 이유 때문에 이 플래그를 사용 설정하지 않는 것이 좋습니다.

사용자가 데이터베이스 엔진 수준에서 인증 없이 데이터베이스에 연결할 수 있습니다.
데이터베이스 엔진에서 데이터베이스를 격리하면 데이터베이스를 SQL Server의 다른 인스턴스로 옮길 수 있습니다.

포함된 데이터베이스에는 SQL Server 데이터베이스 엔진 관리자가 파악하고 완화해야 하는 고유한 위협이 있습니다. 대부분의 위협은 데이터베이스 엔진 수준에서 데이터베이스 수준으로 인증 경계를 이동시키는 USER WITH PASSWORD 인증 프로세스에서 발생합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 contained database authentication 데이터베이스 플래그 값을 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL cross DB ownership chaining`

API의 카테고리 이름: SQL_CROSS_DB_OWNERSHIP_CHAINING

SQL Server용 Cloud SQL 데이터베이스 인스턴스에서 cross db ownership chaining 데이터베이스 플래그가 해제로 설정되지 않았습니다.

cross db ownership chaining 플래그를 사용하면 데이터베이스 수준에서 교차 데이터베이스 소유권 체이닝을 제어하거나 모든 데이터베이스 문에 교차 데이터베이스 소유권 체이닝을 허용할 수 있습니다.

SQL Server 인스턴스에서 호스팅하는 모든 데이터베이스가 교차 데이터베이스 소유권 체이닝에 참여하고 이 설정이 보안에 미치는 영향을 알고 있지 않는 한 이 플래그를 사용 설정하지 않는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 cross db ownership chaining 데이터베이스 플래그 값을 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL external scripts enabled`

API의 카테고리 이름: SQL_EXTERNAL_SCRIPTS_ENABLED

SQL Server용 Cloud SQL 데이터베이스 인스턴스에는 외부 스크립트 사용 설정됨 데이터베이스 플래그가 Off로 설정되어 있습니다.

이 설정을 활성화하면 특정 원격 언어 확장 프로그램이 있는 스크립트를 실행할 수 있습니다. 이 기능은 시스템의 보안에 부정적인 영향을 줄 수 있으므로 사용 중지하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 외부 스크립트 사용 설정됨 데이터베이스 플래그를 Off 값으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL instance not monitored`

API의 카테고리 이름: SQL_INSTANCE_NOT_MONITORED

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

로그 측정항목 및 알림은 Cloud SQL 인스턴스 구성 변경사항을 모니터링하도록 구성되지 않습니다.

SQL 인스턴스 옵션을 잘못 구성하면 보안 위험이 발생할 수 있습니다. 자동 백업 및 고가용성 옵션을 사용 중지하면 비즈니스 연속성에 영향을 줄 수 있고 승인된 네트워크를 제한하지 않으면 신뢰할 수 없는 네트워크에 대한 노출이 증가할 수 있습니다. SQL 인스턴스 구성에 대한 변경사항을 모니터링하면 잘못된 구성을 감지하고 수정하는 데 걸리는 시간을 줄일 수 있습니다.

자세한 내용은 로그 기반 측정항목 개요를 참조하세요.

정보의 양에 따라 Cloud Monitoring 비용이 크게 증가할 수 있습니다. 서비스 사용량과 비용을 파악하려면 Google Cloud Observability 비용 최적화를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

측정항목 만들기

Google Cloud 콘솔에서 로그 기반 측정항목 페이지로 이동합니다.

로그 기반 측정항목으로 이동
측정항목 만들기를 클릭합니다.
측정항목 유형에서 카운터를 선택합니다.
세부정보에서 다음을 수행합니다
1. 로그 측정항목 이름을 설정합니다.
2. 설명을 추가합니다.
3. 단위를 1로 설정합니다.

필터 선택에서 다음 텍스트를 복사하여 필터 빌드 상자에 붙여넣고, 필요에 따라 기존 텍스트를 바꿉니다.

  protoPayload.methodName="cloudsql.instances.update"
  OR protoPayload.methodName="cloudsql.instances.create"
  OR protoPayload.methodName="cloudsql.instances.delete"

측정항목 만들기를 클릭합니다. 확인이 표시됩니다.

알림 정책 만들기

Google Cloud 콘솔의 탐색 패널에서 Logging을 선택한 후 로그 기반 측정항목을 선택합니다.
로그 기반 측정항목으로 이동
사용자 정의 측정항목 섹션에서 이전 섹션에서 만든 측정항목을 선택합니다.
더보기 를 클릭한 후 측정항목에서 알림 만들기를 클릭하세요.

측정항목 및 데이터 변환 옵션이 미리 채워진 새 조건 대화상자가 열립니다.
다음을 클릭합니다.
1. 미리 채워진 설정을 검토합니다. 임곗값을 수정할 수 있습니다.
2. 조건 이름을 클릭하고 조건의 이름을 입력합니다.
다음을 클릭합니다.
알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.

이슈가 개설 및 종료될 때 알림을 받으려면 이슈 종료 시 알림을 선택하세요. 기본적으로 알림은 이슈가 열렸을 때만 전송됩니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL local infile`

API의 카테고리 이름: SQL_LOCAL_INFILE

MySQL용 Cloud SQL 데이터베이스 엔스턴스에서 local_infile 데이터베이스 플래그가 해제로 설정되지 않았습니다. local_infile 플래그와 관련된 보안 문제로 인해 이를 사용 중지해야 합니다. 자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 local_infile 데이터베이스 플래그를 Off 값으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log checkpoints disabled`

API의 카테고리 이름: SQL_LOG_CHECKPOINTS_DISABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_checkpoints 데이터베이스 플래그가 설정으로 지정되지 않았습니다.

log_checkpoints를 사용 설정하면 체크포인트와 재시작 지점이 서버 로그에 로깅됩니다. 작성된 버퍼 수와 작성 소요 시간을 포함한 일부 통계가 로그 메시지에 포함됩니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_checkpoints 데이터베이스 플래그 값을 On으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log connections disabled`

API의 카테고리 이름: SQL_LOG_CONNECTIONS_DISABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_connections 데이터베이스 플래그가 설정으로 지정되지 않았습니다.

log_connections 설정을 사용 설정하면 클라이언트 인증 완료와 함께 서버 연결 시도가 로깅됩니다. 로그는 문제를 해결하고 비정상적인 서버 연결 시도를 확인할 때 유용합니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_connections 데이터베이스 플래그 값을 On으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log disconnections disabled`

API의 카테고리 이름: SQL_LOG_DISCONNECTIONS_DISABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_disconnections 데이터베이스 플래그가 설정으로 지정되지 않았습니다.

log_disconnections 설정을 사용 설정하면 각 세션이 끝날 때 로그 항목이 생성됩니다. 로그는 문제를 해결하고 특정 기간에 걸친 비정상적인 활동을 확인할 때 유용합니다. 자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_disconnections 데이터베이스 플래그 값을 On으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log duration disabled`

API의 카테고리 이름: SQL_LOG_DURATION_DISABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_duration 데이터베이스 플래그가 On으로 지정되지 않았습니다.

log_duration을 사용 설정하면 완료된 각 문의 실행 시간과 소요 시간이 이 설정을 통해 로깅됩니다. 쿼리를 실행하는 데 걸리는 시간을 모니터링하면 느린 쿼리를 식별하고 데이터베이스 문제를 해결하는 데 매우 유용할 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_duration 데이터베이스 플래그를 On으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log error verbosity`

API의 카테고리 이름: SQL_LOG_ERROR_VERBOSITY

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에는 log_error_verbosity 데이터베이스 플래그가 default 또는 verbose로 설정되지 않습니다.

log_error_verbosity 플래그는 로깅되는 메시지의 세부정보 양을 제어합니다. 세부정보 수준이 높을수록 메시지에 더 많은 세부정보가 기록됩니다. 이 플래그를 default 또는 verbose로 설정하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_error_verbosity 데이터베이스 플래그를 default 또는 verbose로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log lock waits disabled`

API의 카테고리 이름: SQL_LOG_LOCK_WAITS_DISABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_lock_waits 데이터베이스 플래그가 설정으로 지정되지 않았습니다.

log_lock_waits 설정을 사용 설정하면 세션에서 잠금을 획득하기 위한 대기 시간이 deadlock_timeout 시간보다 길어질 경우 로그 항목이 생성됩니다. 로그는 잠금 대기로 인해 성능이 저하되는지 확인하는 데 유용합니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_lock_waits 데이터베이스 플래그 값을 On으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log min duration statement enabled`

API의 카테고리 이름: SQL_LOG_MIN_DURATION_STATEMENT_ENABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_min_duration_statement 데이터베이스 플래그가 -1로 설정되지 않았습니다.

log_min_duration_statement 플래그로 인해 지정된 시간보다 길게 실행되는 SQL 문이 로깅됩니다. SQL 문이 로깅하면 안 되는 민감한 정보를 포함할 수 있기 때문에 이 설정을 사용 중지하는 것이 좋습니다. 자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_min_duration_statement 데이터베이스 플래그를 -1 값으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log min error statement`

API의 카테고리 이름: SQL_LOG_MIN_ERROR_STATEMENT

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_min_error_statement 데이터베이스 플래그가 적절하게 설정되지 않았습니다.

log_min_error_statement 플래그는 오류 조건을 유발하는 SQL 문을 서버 로그에 기록할지 여부를 제어합니다. 지정된 심각도 이상의 SQL 문은 오류 문에 대한 메시지와 함께 로깅됩니다. 심각도가 높을수록 기록되는 메시지가 적습니다.

log_min_error_statement가 올바른 값으로 설정되지 않은 경우 메시지가 오류 메시지로 분류되지 않을 수 있습니다. 심각도를 너무 낮게 설정하면 메시지 수가 증가하고 실제 오류를 찾기가 어려워집니다. 심각도를 너무 높게 설정하면 실제 오류에 대한 오류 메시지가 로깅되지 않을 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 조직의 로깅 정책에 따라 log_min_error_statement 데이터베이스 플래그를 다음 권장 값 중 하나로 설정합니다.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
- error
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log min error statement severity`

API의 카테고리 이름: SQL_LOG_MIN_ERROR_STATEMENT_SEVERITY

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_min_error_statement 데이터베이스 플래그가 적절하게 설정되지 않았습니다.

log_min_error_statement 플래그는 오류 조건을 유발하는 SQL 문을 서버 로그에 기록할지 여부를 제어합니다. 지정된 심각도 이상으로 엄격한 SQL 문은 오류 문에 대한 메시지와 함께 로깅됩니다. 심각도가 더 엄격할수록 기록되는 메시지가 적습니다.

log_min_error_statement가 올바른 값으로 설정되지 않은 경우 메시지가 오류 메시지로 분류되지 않을 수 있습니다. 심각도를 너무 낮게 설정하면 메시지 수가 증가하고 실제 오류를 찾기가 어려워집니다. 심각도 수준이 너무 높으면(너무 엄격) 실제 오류에 대한 오류 메시지가 로깅되지 않을 수 있습니다.

이 플래그를 error 또는 더 엄격한 값으로 설정하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 조직의 로깅 정책에 따라 log_min_error_statement 데이터베이스 플래그를 다음 권장 값 중 하나로 설정합니다.
- error
- log
- fatal
- panic
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log min messages`

API의 카테고리 이름: SQL_LOG_MIN_MESSAGES

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에는 log_min_messages 데이터베이스 플래그가 최소 warning으로 설정되어 있지 않습니다.

log_min_messages 플래그는 서버 로그에 기록되는 메시지 수준을 제어합니다. 심각도가 높을수록 기록되는 메시지가 적습니다. 기준점을 너무 낮게 설정하면 로그 스토리지 크기와 기간이 늘어나 실제 오류를 찾기가 어려워질 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 조직의 로깅 정책에 따라 log_min_messages 데이터베이스 플래그를 다음 권장 값 중 하나로 설정합니다.
- debug5
- debug4
- debug3
- debug2
- debug1
- info
- notice
- warning
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log executor stats enabled`

API의 카테고리 이름: SQL_LOG_EXECUTOR_STATS_ENABLED

PostgreSQL용 Cloud SQL 데이터베이스에는 log_executor_stats 데이터베이스 플래그가 Off로 설정되어 있지 않습니다.

log_executor_stats 플래그가 활성화되면 실행자 성능 통계가 각 쿼리의 PostgreSQL 로그에 포함됩니다. 이 설정은 문제를 해결하는 데는 유용할 수 있지만 로그 수와 성능 오버헤드가 크게 증가할 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_executor_stats 데이터베이스 플래그를 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log hostname enabled`

API의 카테고리 이름: `SQL_LOG_HOSTNAME_ENABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에는 log_hostname 데이터베이스 플래그가 Off로 설정되어 있지 않습니다.

log_hostname 플래그가 활성화되면 연결 호스트의 호스트 이름이 로깅됩니다. 기본적으로 연결 로그 메시지에는 IP 주소만 표시됩니다. 이 설정은 문제를 해결하는 데 유용할 수 있습니다. 하지만 IP 주소를 호스트 이름으로 변환하려면 로깅된 각 문에 대해 DNS 변환이 필요하므로 서버 성능에 오버헤드가 발생할 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_hostname 데이터베이스 플래그를 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log parser stats enabled`

API의 카테고리 이름: SQL_LOG_PARSER_STATS_ENABLED

PostgreSQL용 Cloud SQL 데이터베이스에는 log_parser_stats 데이터베이스 플래그가 Off로 설정되어 있지 않습니다.

log_parser_stats 플래그가 활성화되면 파서 성능 통계가 각 쿼리의 PostgreSQL 로그에 포함됩니다. 이는 문제를 해결하는 데는 유용할 수 있지만 로그 수와 성능 오버헤드가 크게 증가할 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_parser_stats 데이터베이스 플래그를 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log planner stats enabled`

API의 카테고리 이름: SQL_LOG_PLANNER_STATS_ENABLED

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에는 log_planner_stats 데이터베이스 플래그가 Off로 설정되어 있지 않습니다.

log_planner_stats 플래그가 활성화되면 PostgreSQL 플래너 성능 통계를 로깅하는 적당한 프로파일링 방법이 사용됩니다. 이는 문제를 해결하는 데는 유용할 수 있지만 로그 수와 성능 오버헤드가 크게 증가할 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_planner_stats 데이터베이스 플래그를 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log statement`

API의 카테고리 이름: SQL_LOG_STATEMENT

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에는 log_statement 데이터베이스 플래그가 ddl로 설정되어 있지 않습니다.

이 플래그 값은 로깅되는 SQL 문을 제어합니다. 로깅하면 운영 문제를 해결하는 데 도움이 되며 포렌식 분석이 가능해집니다. 이 플래그가 올바른 값으로 설정되지 않은 경우 너무 많은 메시지에서 관련 정보를 건너뛰거나 숨길 수 있습니다. 조직의 로깅 정책에 의해 달리 지시하지 않는 한 ddl 값(모든 데이터 정의 문)을 사용하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_statement 데이터베이스 플래그를 ddl로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log statement stats enabled`

API의 카테고리 이름: SQL_LOG_STATEMENT_STATS_ENABLED

PostgreSQL용 Cloud SQL 데이터베이스에는 log_statement_stats 데이터베이스 플래그가 Off로 설정되어 있지 않습니다.

log_statement_stats 플래그가 활성화되면 각 쿼리의 PostgreSQL 로그에 엔드 투 엔드 성능 통계가 포함됩니다. 이 설정은 문제를 해결하는 데는 유용할 수 있지만 로그 수와 성능 오버헤드가 크게 증가할 수 있습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_statement_stats 데이터베이스 플래그를 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL log temp files`

API의 카테고리 이름: SQL_LOG_TEMP_FILES

PostgreSQL용 Cloud SQL 데이터베이스 인스턴스에서 log_temp_files 데이터베이스 플래그가 0으로 설정되지 않았습니다.

정렬, 해시, 임시 쿼리 결과를 위한 임시 파일을 만들 수 있습니다. log_temp_files 플래그를 0으로 설정하면 모든 임시 파일 정보가 로깅됩니다. 모든 임시 파일을 로깅하면 잠재적인 성능 문제를 식별하는 데 유용합니다. 자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 log_temp_files 데이터베이스 플래그를 0 값으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL no root password`

API의 카테고리 이름: SQL_NO_ROOT_PASSWORD

MySQL 데이터베이스 인스턴스에서 루트 계정에 대해 비밀번호가 설정되지 않았습니다. MySQL 데이터베이스 인스턴스에 비밀번호를 추가해야 합니다. 자세한 내용은 MySQL 사용자를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
인스턴스 세부정보 페이지가 로드되면 사용자 탭을 선택합니다.
root 사용자 옆에서 더보기 를 클릭한 후 비밀번호 변경을 선택합니다.
안전한 새 비밀번호를 입력한 후 확인을 클릭하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL public IP`

API의 카테고리 이름: SQL_PUBLIC_IP

Cloud SQL Database에는 공개 IP 주소가 있습니다.

조직의 공격 표면을 줄이려면 Cloud SQL 데이터베이스에 공개 IP 주소가 없어야 합니다. 비공개 IP 주소는 향상된 네트워크 보안을 제공하고 애플리케이션의 지연 시간을 줄여 줍니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
왼쪽 사이드 메뉴에서 연결을 클릭합니다.
네트워킹 탭을 클릭하고 공개 IP 체크박스를 선택 해제합니다.
인스턴스가 아직 비공개 IP를 사용하도록 구성되지 않았으면 기존 인스턴스에 대해 비공개 IP 구성을 참조하세요.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL remote access enabled`

API의 카테고리 이름: SQL_REMOTE_ACCESS_ENABLED

SQL Server용 Cloud SQL 데이터베이스 인스턴스에는 원격 액세스 데이터베이스 플래그가 Off로 설정되어 있지 않습니다.

활성화된 경우 이 설정으로 인해 원격 서버에서 로컬 저장 프로시저를 실행하거나 로컬 서버에서 원격 저장 프로시저를 실행할 수 있는 권한이 부여됩니다. 쿼리 처리를 대상으로 오프로드하여 원격 서버에서 서비스 거부(DoS) 공격을 실행하는 데 이 기능이 악용될 수 있습니다. 악용을 방지하려면 이 설정을 사용 중지하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
플래그 섹션에서 원격 액세스를 Off로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL skip show database disabled`

API의 카테고리 이름: SQL_SKIP_SHOW_DATABASE_DISABLED

MySQL용 Cloud SQL 데이터베이스 인스턴스에는 skip_show_database 데이터베이스 플래그가 On으로 설정되어 있지 않습니다.

이 플래그를 활성화하면 SHOW DATABASES 권한이 없는 사용자가 SHOW DATABASES 문을 사용할 수 없게 됩니다. 이 설정을 사용하면 명시적인 권한이 없는 사용자는 다른 사용자에게 속한 데이터베이스를 볼 수 없게 됩니다. 이 플래그를 사용 설정하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
플래그 섹션에서 skip_show_database를 On으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL trace flag 3625`

API의 카테고리 이름: SQL_TRACE_FLAG_3625

SQL Server용 Cloud SQL 데이터베이스 인스턴스에 3625(trace 플래그) 데이터베이스 플래그가 On으로 설정되어 있지 않습니다.

이 플래그는 별표(******)를 일부 오류 메시지의 매개변수를 마스킹하여 시스템 관리자 고정 서버 역할의 구성원이 아닌 사용자에게 반환되는 정보의 양을 제한합니다. 민감한 정보가 공개되지 않도록 이 플래그를 사용 설정하는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 3625를 On으로 설정합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL user connections configured`

API의 카테고리 이름: SQL_USER_CONNECTIONS_CONFIGURED

SQL Server용 Cloud SQL 데이터베이스 인스턴스에는 사용자 연결 데이터베이스 플래그가 구성되어 있습니다.

사용자 연결 옵션은 SQL Server 인스턴스에서 허용되는 최대 동시 사용자 연결 수를 지정합니다. 이는 동적(자체 구성) 옵션이므로 SQL Server에서 최대 사용자 연결 수를 필요에 따라 자동으로 허용되는 최댓값까지 조정합니다. 기본값은 0이며, 이 경우 최대 32,767개의 사용자 연결이 허용됩니다. 이러한 이유로 사용자 연결 데이터베이스 플래그를 구성하지 않는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 사용자 연결 옆에 있는 삭제를 클릭합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL user options configured`

API의 카테고리 이름: SQL_USER_OPTIONS_CONFIGURED

SQL Server용 Cloud SQL 데이터베이스 인스턴스에는 사용자 옵션 데이터베이스 플래그가 구성되어 있습니다.

이 설정은 모든 사용자에 해당하는 SET 옵션의 전체 기본값을 재정의합니다. 기본 데이터베이스 SET 옵션을 사용하고 있다고 사용자 및 애플리케이션이 가정할 수 있으므로 user options를 설정하면 예기치 않은 결과가 발생할 수 있습니다. 이러한 이유로 사용자 옵션 데이터베이스 플래그를 구성하지 않는 것이 좋습니다.

자세한 내용은 데이터베이스 플래그 구성을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
수정을 클릭합니다.
데이터베이스 플래그 섹션에서 사용자 연결 옆에 있는 삭제를 클릭합니다.
저장을 클릭합니다. 인스턴스 개요 페이지에 새 구성이 표시됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SQL weak root password`

API의 카테고리 이름: SQL_WEAK_ROOT_PASSWORD

MySQL 데이터베이스 인스턴스에서 루트 계정에 대해 약한 비밀번호가 설정되었습니다. 인스턴스에 대해 강력한 비밀번호를 설정해야 합니다. 자세한 내용은 MySQL 사용자를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
인스턴스 세부정보 페이지가 로드되면 사용자 탭을 선택합니다.
root 사용자 옆에서 더보기 를 클릭한 후 비밀번호 변경을 선택합니다.
안전한 새 비밀번호를 입력한 후 확인을 클릭하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`SSL not enforced`

API의 카테고리 이름: SSL_NOT_ENFORCED

Cloud SQL 데이터베이스 인스턴스는 SSL을 사용하기 위해 모든 수신 연결을 필요로 하지 않습니다.

암호화되지 않은 통신을 통해 민감한 전송 중 데이터가 노출되지 않도록 하려면 SQL 데이터베이스 인스턴스로 들어오는 모든 연결에 SSL을 사용해야 합니다. SSL/TLS 구성에 대해 자세히 알아보세요.

이러한 발견 항목을 해결하려면 SQL 인스턴스의 SSL 연결만 허용해야 합니다.

Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.

Cloud SQL 인스턴스로 이동
Security Health Analytics 발견 항목에 나열된 인스턴스를 선택합니다.
연결 탭에서 SSL 연결만 허용 또는 신뢰할 수 있는 클라이언트 인증서 필요를 클릭합니다. 자세한 내용은 SSL/TLS 암호화 적용을 참조하세요.
신뢰할 수 있는 클라이언트 인증서 필요를 선택한 경우 새 클라이언트 인증서를 만듭니다. 자세한 내용은 새 클라이언트 인증서 만들기를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Too many KMS users`

API의 카테고리 이름: TOO_MANY_KMS_USERS

암호화 키를 사용할 수 있는 주 사용자 수를 세 명으로 제한합니다. 사전 정의된 다음 역할은 암호화 키를 사용하여 데이터를 암호화 및 복호화하거나 데이터에 서명할 권한을 부여합니다.

roles/owner
roles/cloudkms.cryptoKeyEncrypterDecrypter
roles/cloudkms.cryptoKeyEncrypter
roles/cloudkms.cryptoKeyDecrypter
roles/cloudkms.signer
roles/cloudkms.signerVerifier

자세한 내용은 권한 및 역할을 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

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

Cloud KMS 키로 이동
발견 항목에 표시된 키링의 이름을 클릭합니다.
발견 항목에 표시된 키의 이름을 클릭합니다.
기본 버전 옆에 있는 상자를 선택한 후 정보 패널 표시를 클릭합니다.
데이터 암호화, 복호화, 서명 권한을 갖는 주 구성원 수를 세 명 이하로 줄입니다. 권한을 취소하려면 각 주 구성원 옆에 있는 삭제 를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`User managed service account key`

API의 카테고리 이름: USER_MANAGED_SERVICE_ACCOUNT_KEY

사용자가 서비스 계정 키를 관리합니다. 서비스 계정 키를 올바르게 관리하지 않으면 보안 위험을 초래할 수 있습니다. 가능한 한 서비스 계정 키보다 안전한 대안을 선택해야 합니다. 서비스 계정 키로 인증해야 하는 경우 비공개 키의 보안과 서비스 계정 키 관리 권장사항에 설명된 기타 작업에 대한 책임이 사용자에게 있습니다. 서비스 계정 키를 만들 수 없는 경우 서비스 계정 키 생성이 조직에 중지될 수 있습니다. 자세한 내용은 기본적으로 보안이 제공되는 조직 리소스 관리를 참조하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Google Cloud 콘솔에서 서비스 계정 페이지로 이동합니다.

서비스 계정으로 이동
필요에 따라 발견 항목에서 표시된 프로젝트를 선택합니다.
애플리케이션에서 사용되지 않는 경우 발견 항목에 표시된 사용자 관리 서비스 계정 키를 삭제합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Weak SSL policy`

API의 카테고리 이름: WEAK_SSL_POLICY

Compute Engine 인스턴스에 취약한 SSL 정책이 있거나 TLS 버전이 1.2 미만인 Google Cloud 기본 SSL 정책이 사용됩니다.

HTTPS 및 SSL 프록시 부하 분산기는 SSL 정책을 사용하여 사용자와 인터넷 사이에 설정된 TLS 연결에 사용되는 프로토콜 및 암호화 묶음을 결정합니다. 이러한 연결은 민감한 정보를 암호화하여 악의적인 침입자가 정보에 액세스하지 못하게 합니다. 취약한 SSL 정책을 사용하면 오래된 버전의 TLS를 사용하는 클라이언트가 보안 수준이 낮은 암호화 묶음 또는 프로토콜과 연결할 수 있습니다. 권장 및 오래된 암호화 스위트 목록은 iana.org TLS 매개변수 페이지를 참조하세요.

이 발견 항목의 해결 단계는 기본 Google Cloud SSL 정책 또는 취약한 암호화 스위트나 1.2 미만의 최소 TLS 버전을 허용하는 SSL 정책을 사용하여 이 발견 항목이 트리거되었는지에 따라 달라집니다. 발견 항목의 트리거에 해당하는 다음 절차를 따르세요.

기본 Google Cloud SSL 정책 해결

Google Cloud 콘솔에서 대상 프록시 페이지로 이동합니다.

대상 프록시로 이동
발견 항목에 표시된 대상 프록시를 찾고 다음에서 사용 중 열에서 전달 규칙을 확인합니다.
새 SSL 정책을 만들려면 SSL 정책 사용을 참조하세요. 정책은 최소 TLS 버전이 1.2여야 하고 최신 또는 제한된 프로필을 포함해야 합니다.
커스텀 프로필을 사용하려면 다음 암호화 스위트가 사용 중지되었는지 확인합니다.
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
앞에서 기록한 각 전달 규칙에 SSL 정책을 적용합니다.

취약한 암호화 스위트 또는 하위 수준의 TLS 버전이 허용된 해결

Google Cloud 콘솔에서 SSL 정책 페이지로 이동합니다.

SSL 정책으로 이동
다음에서 사용 중 열에 표시된 부하 분산기를 찾습니다.
정책 이름을 클릭합니다.
수정을 클릭합니다.
최소 TLS 버전을 TLS 1.2로 변경하고 프로필을 최신 또는 제한됨으로 변경합니다.
커스텀 프로필을 사용하려면 다음 암호화 스위트가 사용 중지되었는지 확인합니다.
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Web UI enabled`

API의 카테고리 이름: WEB_UI_ENABLED

GKE 웹 UI(대시보드)가 사용 설정됩니다.

상위 권한의 Kubernetes 서비스 계정은 Kubernetes 웹 인터페이스를 지원합니다. 서비스 계정이 도용되면 악용될 수 있습니다. 이미 Google Cloud 콘솔을 사용하고 있는 경우 Kubernetes 웹 인터페이스로 인해 공격에 노출되는 영역이 불필요하게 확대됩니다. Kubernetes 웹 인터페이스 사용 중지에 대해 알아보세요.

이 발견 항목을 해결하려면 Kubernetes 웹 인터페이스를 사용 중지합니다.

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

Kubernetes 클러스터로 이동
Security Health Analytics 발견 항목에 나열된 클러스터의 이름을 클릭합니다.
수정을 클릭합니다.

클러스터 구성이 최근에 변경된 경우 수정 버튼이 클릭되지 않을 수 있습니다. 클러스터 설정을 수정할 수 없는 경우 몇 분 정도 기다린 후 다시 시도하세요.
부가기능을 클릭합니다. 섹션이 확장되면서 사용 가능한 부가기능이 표시됩니다.
Kubernetes 대시보드 드롭다운 목록에서 사용 중지를 선택합니다.
저장을 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Workload Identity disabled`

API의 카테고리 이름: WORKLOAD_IDENTITY_DISABLED

워크로드 아이덴티티가 GKE 클러스터에서 사용 중지됩니다.

워크로드 아이덴티티는 향상된 보안 속성 및 관리 편의성으로 인해 GKE 내에서 Google Cloud 서비스에 액세스하는 데 권장되는 방식입니다. 사용 설정하면 클러스터에서 실행되는 사용자 워크로드에서 잠재적으로 민감한 시스템 메타데이터가 보호됩니다. 메타데이터 숨김에 대해 알아보세요.

이 발견 항목을 해결하려면 클러스터에서 워크로드 아이덴티티 사용 설정 가이드를 따르세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

AWS 구성 오류 해결

`AWS Cloud Shell Full Access Restricted`

API의 카테고리 이름: ACCESS_AWSCLOUDSHELLFULLACCESS_RESTRICTED

AWS CloudShell은 AWS 서비스에서 CLI 명령어를 편리하게 실행할 수 있는 방법입니다. 관리형 IAM 정책('AWSCloudShellFullAccess')은 CloudShell에 대한 전체 액세스 권한을 제공하므로 사용자의 로컬 시스템과 CloudShell 환경 간에 파일을 업로드하고 다운로드할 수 있습니다. CloudShell 환경 내에서 사용자는 sudo 권한을 가지며 인터넷에 액세스할 수 있습니다. 예를 들어 파일 전송 소프트웨어를 설치하고 데이터를 CloudShell에서 외부 인터넷 서버로 이동할 수 있습니다.

권장사항: AWSCloudShellFullAccess에 대한 액세스가 제한되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Access Keys Rotated Every 90 Days or Less`

API의 카테고리 이름: ACCESS_KEYS_ROTATED_90_DAYS_LESS

액세스 키는 AWS에 보낸 프로그래매틱 요청에 서명하는 데 사용되는 액세스 키 ID 및 보안 비밀 액세스 키로 구성됩니다. AWS 명령줄 인터페이스(AWS CLI), Windows PowerShell용 도구, AWS SDK에서 AWS로 프로그래매틱 호출을 수행하거나 개별 AWS 서비스용 API를 사용하여 직접 HTTP 호출을 수행하려면 AWS 사용자에게 고유한 액세스 키가 있어야 합니다. 모든 액세스 키를 정기적으로 순환하는 것이 좋습니다.

권장사항: 액세스 키가 최소 90일마다 순환되는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

Management Console(https://console.aws.amazon.com/iam)로 이동합니다.
Users를 클릭합니다.
Security Credentials를 클릭합니다.
관리자가 수행해야 할 작업
- 90일 동안 순환되지 않은 키의 경우 Make Inactive을 클릭합니다.
IAM 사용자가 수행해야 할 작업
- 90일 동안 순환 또는 사용되지 않은 키의 경우 Make Inactive 또는 Delete를 클릭합니다.
Create Access Key를 클릭합니다.
새 액세스 키 사용자 인증 정보로 프로그래매틱 호출을 업데이트합니다.

AWS CLI

첫 번째 액세스 키가 아직 활성 상태이지만 기본적으로 활성화되는 두 번째 액세스 키를 만듭니다. 다음 명령어를 실행합니다.

aws iam create-access-key

이제 사용자에게 2개의 활성 액세스 키가 있습니다.

새 액세스 키를 사용하도록 모든 애플리케이션과 도구를 업데이트합니다.
다음 명령어를 사용하여 첫 번째 액세스 키가 아직 사용 중인지 확인합니다.

aws iam get-access-key-last-used

한 가지 방법은 며칠을 기다린 후에 이전 액세스 키가 사용되지 않았는지 확인하는 것입니다.

3단계에서 이전 키가 사용되지 않은 것으로 표시되더라도 첫 번째 액세스 키를 즉시 삭제하지 않는 것이 좋습니다. 대신 다음 명령어를 사용하여 첫 번째 액세스 키의 상태를 비활성으로 변경합니다.

aws iam update-access-key

새 액세스 키만 사용하여 애플리케이션이 작동하는지 확인합니다. 여전히 원래 액세스 키를 사용하는 모든 애플리케이션과 도구는 더 이상 AWS 리소스에 액세스할 수 없으므로 이 시점에서 작동이 중지됩니다. 이러한 애플리케이션이나 도구를 찾으면 상태를 다시 활성으로 전환하여 첫 번째 액세스 키를 다시 사용 설정할 수 있습니다. 그런 다음 2단계로 돌아가서 새 키를 사용하도록 이 애플리케이션을 업데이트합니다.
일정 시간 후 모든 애플리케이션과 도구가 업데이트되었는지 확인한 후 다음 명령어를 사용하여 첫 번째 액세스 키를 삭제할 수 있습니다.

aws iam delete-access-key

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`All Expired Ssl Tls Certificates Stored Aws Iam Removed`

API의 카테고리 이름: ALL_EXPIRED_SSL_TLS_CERTIFICATES_STORED_AWS_IAM_REMOVED

AWS에서 웹사이트나 애플리케이션에 대한 HTTPS 연결을 사용 설정하려면 SSL/TLS 서버 인증서가 필요합니다. ACM 또는 IAM을 사용하여 서버 인증서를 저장하고 배포할 수 있습니다. ACM에서 지원하지 않는 리전에서 HTTPS 연결을 지원해야 하는 경우에만 IAM을 인증서 관리자로 사용합니다. IAM은 비공개 키를 안전하게 암호화하고 암호화된 버전을 IAM SSL 인증서 스토리지에 저장합니다. IAM은 모든 리전에서 서버 인증서를 배포할 수 있지만 AWS에서 사용하려면 외부 제공업체로부터 인증서를 가져와야 합니다. ACM 인증서를 IAM에 업로드할 수 없습니다. 또한 IAM 콘솔에서 인증서를 관리할 수 없습니다.

권장사항: AWS IAM에 저장된 만료 SSL/TLS 인증서가 모두 삭제되었는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console을 통한 만료된 인증서 삭제는 현재 지원되지 않습니다. AWS API를 통해 IAM에 저장된 SSL/TLS 인증서를 삭제하려면 명령줄 인터페이스(CLI)를 사용하세요.

AWS CLI

만료된 인증서를 삭제하려면 CERTIFICATE_NAME을 삭제할 인증서 이름으로 바꿔 다음 명령어를 실행합니다.

aws iam delete-server-certificate --server-certificate-name <CERTIFICATE_NAME>

위의 명령어가 성공하면 출력을 반환하지 않습니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Autoscaling Group Elb Healthcheck Required`

API의 카테고리 이름: AUTOSCALING_GROUP_ELB_HEALTHCHECK_REQUIRED

부하 분산기와 연결된 자동 확장 그룹에서 Elastic Load Balancing 상태 점검을 사용하고 있는지 확인합니다.

이렇게 하면 부하 분산기에서 제공하는 추가 테스트를 기반으로 그룹에서 인스턴스 상태를 확인할 수 있습니다. Elastic Load Balancing 상태 점검을 사용하면 EC2 자동 확장 그룹을 사용하는 애플리케이션의 가용성을 지원할 수 있습니다.

권장사항: 부하 분산기와 연결된 모든 자동 확장 그룹이 상태 점검을 사용하는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

Elastic Load Balancing 상태 점검을 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색창의 Auto Scaling(자동 확장)에서 Auto Scaling Groups(자동 확장 그룹)을 선택합니다.
그룹의 체크박스를 선택합니다.
Edit(수정)을 선택합니다.
Health checks(상태 점검)에서 상태 점검 유형으로 ELB를 선택합니다.
Health check grace period(상태 점검 유예 기간)에 300을 입력합니다.
페이지 하단에서 Update(업데이트)를 선택합니다.

자동 확장 그룹에서 부하 분산기를 사용하는 방법에 대한 자세한 내용은 AWS 자동 확장 사용자 가이드를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Auto Minor Version Upgrade Feature Enabled Rds Instances`

API의 카테고리 이름: AUTO_MINOR_VERSION_UPGRADE_FEATURE_ENABLED_RDS_INSTANCES

지정된 유지보수 기간 동안 부 엔진 업그레이드를 자동으로 수신하기 위해 RDS 데이터베이스 인스턴스에 자동 부 버전 업그레이드 플래그가 사용 설정되어 있는지 확인합니다. 따라서 RDS 인스턴스에서 데이터베이스 엔진의 새로운 기능, 버그 수정, 보안 패치를 가져올 수 있습니다.

권장사항: RDS 인스턴스에 자동 부 버전 업그레이드 기능이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/rds/의 RDS 대시보드로 이동합니다.
왼쪽 탐색 패널에서 Databases를 클릭합니다.
업데이트할 RDS 인스턴스를 선택합니다.
오른쪽 상단에 있는 Modify 버튼을 클릭합니다.
Modify DB Instance: <instance identifier> 페이지의 Maintenance 섹션에서 Auto minor version upgrade를 선택하고 Yes 라디오 버튼을 클릭합니다.
페이지 하단에서 Continue를 클릭하고 즉시 적용을 선택하여 변경사항을 즉시 적용하거나 Apply during the next scheduled maintenance window를 선택하여 다운타임을 방지합니다.
변경사항을 검토하고 Modify DB Instance를 클릭합니다. 인스턴스 상태가 사용 가능에서 수정으로 변경 후 다시 사용 가능으로 변경되어야 합니다. 기능이 사용 설정되면 Auto Minor Version Upgrade 상태가 Yes로 변경됩니다.

AWS CLI

describe-db-instances 명령어를 실행하여 선택한 AWS 리전에서 사용 가능한 모든 RDS 데이터베이스 인스턴스 이름을 나열합니다.

aws rds describe-db-instances --region <regionName> --query 'DBInstances[*].DBInstanceIdentifier'

명령어 결과는 각 데이터베이스 인스턴스 식별자를 반환해야 합니다.
modify-db-instance 명령어를 실행하여 선택한 RDS 인스턴스 구성을 수정합니다. 다음 명령어는 변경사항을 즉시 적용합니다. 다음 예약된 유지보수 기간 중에 변경사항을 적용하고 다운타임을 방지하려면 --apply-immediately를 삭제합니다.

aws rds modify-db-instance --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --auto-minor-version-upgrade --apply-immediately

명령어 결과에 RDS 인스턴스의 새 구성 메타데이터가 표시되면 AutoMinorVersionUpgrade 매개변수 값을 확인합니다.
describe-db-instances 명령어를 실행하여 자동 부 버전 업그레이드 기능이 성공적으로 사용 설정되었는지 확인합니다.

aws rds describe-db-instances --region <regionName> --db-instance-identifier <dbInstanceIdentifier> --query 'DBInstances[*].AutoMinorVersionUpgrade'

명령어 결과에 true로 설정된 기능의 현재 상태가 반환되고 기능이 enabled이면 선택한 RDS 인스턴스에 부 엔진 업그레이드가 적용됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Aws Config Enabled All Regions`

API의 카테고리 이름: AWS_CONFIG_ENABLED_ALL_REGIONS

AWS Config는 계정 내에서 지원되는 AWS 리소스의 구성 관리를 수행하고 로그 파일을 개발자에게 전송하는 웹 서비스입니다. 기록된 정보에는 구성 항목(AWS 리소스), 구성 항목 간의 관계(AWS 리소스), 리소스 간 구성 변경사항이 포함됩니다. 모든 리전에서 AWS Config를 사용 설정하는 것이 좋습니다.

권장사항: 모든 리전에 AWS Config가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

콘솔의 오른쪽 상단에서 집중하려는 리전을 선택합니다.
Services(서비스)를 클릭합니다.
Config(구성)를 클릭합니다.
이 리전에 Config 레코더가 사용 설정되어 있으면 왼쪽의 탐색 메뉴에서 Settings(설정) 페이지로 이동해야 합니다. 이 리전에 아직 Config 레코더가 사용 설정되어 있지 않으면 'Get Started(시작하기)'를 선택해야 합니다.
'Record all resources supported in this region(이 리전에서 지원되는 모든 리소스 기록)'을 선택합니다.
전역 리소스(IAM 리소스)를 포함하도록 선택합니다.
동일한 계정 또는 다른 관리형 AWS 계정에 S3 버킷을 지정합니다.
동일한 AWS 계정 또는 다른 관리형 AWS 계정에서 SNS 주제를 만듭니다.

AWS CLI

AWS Config Service 기본 요건에 따라 적절한 S3 버킷, SNS 주제, IAM 역할이 있는지 확인합니다.
다음 명령어를 실행하여 새 구성 레코더를 만듭니다.

aws configservice put-configuration-recorder --configuration-recorder name=default,roleARN=arn:aws:iam::012345678912:role/myConfigRole --recording-group allSupported=true,includeGlobalResourceTypes=true

이전에 설정한 기본 요건에서 채워진 채널 속성을 지정하는 배포 채널 구성 파일을 로컬에서 만듭니다.

{
 "name": "default",
 "s3BucketName": "my-config-bucket",
 "snsTopicARN": "arn:aws:sns:us-east-1:012345678912:my-config-notice",
 "configSnapshotDeliveryProperties": {
 "deliveryFrequency": "Twelve_Hours"
 }
}

다음 명령어를 실행하여 이전 단계에서 만든 json 구성 파일을 참조하는 새 배포 채널을 만듭니다.

aws configservice put-delivery-channel --delivery-channel file://deliveryChannel.json

다음 명령어를 실행하여 구성 레코더를 시작합니다.

aws configservice start-configuration-recorder --configuration-recorder-name default

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Aws Security Hub Enabled`

API의 카테고리 이름: AWS_SECURITY_HUB_ENABLED

Security Hub는 AWS 계정, 서비스, 지원되는 서드 파티 파트너 제품에서 보안 데이터를 수집하고 보안 추세를 분석하고 우선순위가 가장 높은 보안 문제를 식별하는 데 도움이 됩니다. Security Hub를 사용 설정하면 Amazon GuardDuty, Amazon Inspector, Amazon Macie와 같은 사용 설정한 AWS 서비스의 발견 항목을 사용, 집계, 구성하고 우선순위를 지정합니다. AWS 파트너 보안 제품과의 통합을 사용 설정할 수도 있습니다.

권장사항: AWS Security Hub가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

IAM ID의 사용자 인증 정보를 사용하여 Security Hub 콘솔에 로그인합니다.
Security Hub 콘솔을 처음 열 때는 AWS Security Hub 사용 설정을 선택합니다.
시작 페이지의 보안 표준에 Security Hub가 지원하는 보안 표준이 나열됩니다.
Security Hub 사용 설정을 선택합니다.

AWS CLI

enable-security-hub 명령어를 실행합니다. 기본 표준을 사용 설정하려면 --enable-default-standards를 포함합니다. aws securityhub enable-security-hub --enable-default-standards
기본 표준 없이 Security Hub를 사용 설정하려면 --no-enable-default-standards를 포함합니다. aws securityhub enable-security-hub --no-enable-default-standards

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cloudtrail Logs Encrypted Rest Using Kms Cmks`

API의 카테고리 이름: CLOUDTRAIL_LOGS_ENCRYPTED_REST_USING_KMS_CMKS

AWS CloudTrail은 계정에 대한 AWS API 호출을 기록하고 IAM 정책에 따라 사용자와 리소스에 해당 로그를 제공하는 웹 서비스입니다. AWS Key Management Service(KMS)는 계정 데이터 암호화에 사용되는 암호화 키를 생성 및 제어할 수 있게 해주는 관리형 서비스로, 하드웨어 보안 모듈(HSM)을 사용하여 암호화 키를 보호합니다. 서버 측 암호화(SSE) 및 KMS 고객 생성 마스터 키(CMK)를 활용하여 CloudTrail 로그를 추가로 보호하도록 CloudTrail 로그를 구성할 수 있습니다. SSE-KMS를 사용하도록 CloudTrail을 구성하는 것이 좋습니다.

권장사항: CloudTrail 로그에 KMS CMK를 사용하여 저장 데이터 암호화가 적용되는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/cloudtrail에서 CloudTrail 콘솔을 엽니다.
왼쪽 탐색창에서 Trails를 선택합니다 .
추적을 클릭합니다.
S3 섹션에서 수정 버튼(연필 아이콘)을 클릭합니다.
Advanced를 클릭합니다.
KMS key Id 드롭다운 메뉴에서 기존 CMK를 선택합니다.
- 참고: CMK가 S3 버킷과 동일한 리전에 있는지 확인하세요.
- 참고: 서비스형 CloudTrail이 제공된 CMK를 사용하여 로그 파일을 암호화 및 복호화하려면 선택한 CMK에 KMS 키 정책을 적용해야 합니다. 선택한 CMK 키 정책을 수정하는 단계는 여기에 나와 있습니다.
Save를 클릭합니다.
로그 파일을 복호화하려면 지정된 KMS 키에 대한 복호화 권한이 필요하다는 알림 메시지가 표시됩니다.
Yes를 클릭합니다.

AWS CLI

aws cloudtrail update-trail --name <trail_name> --kms-id <cloudtrail_kms_key>
aws kms put-key-policy --key-id <cloudtrail_kms_key> --policy <cloudtrail_kms_key_policy>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cloudtrail Log File Validation Enabled`

API의 카테고리 이름: CLOUDTRAIL_LOG_FILE_VALIDATION_ENABLED

CloudTrail 로그 파일 유효성 검사는 CloudTrail에서 S3에 기록하는 각 로그의 해시가 포함된 디지털 서명된 다이제스트 파일을 만듭니다. 이러한 다이제스트 파일을 사용하여 CloudTrail에서 로그를 전송한 후 로그 파일이 변경 또는 삭제되었거나 변경되지 않았는지 여부를 확인할 수 있습니다. 모든 CloudTrail에서 파일 유효성 검사를 사용 설정하는 것이 좋습니다.

권장사항: CloudTrail 로그 파일 검증이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/cloudtrail에서 IAM 콘솔을 엽니다.
왼쪽 탐색창에서 Trails을 클릭합니다.
대상 추적을 클릭합니다.
General details 섹션에서 edit을 클릭합니다.
Advanced settings 섹션에서
Log file validation 아래에서 사용 설정 체크박스를 선택합니다.
Save changes를 클릭합니다.

AWS CLI

aws cloudtrail update-trail --name <trail_name> --enable-log-file-validation

이러한 다이제스트를 사용하는 로그의 주기적인 유효성 검사는 다음 명령어를 실행하여 수행할 수 있습니다.

aws cloudtrail validate-logs --trail-arn <trail_arn> --start-time <start_time> --end-time <end_time>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cloudtrail Trails Integrated Cloudwatch Logs`

API의 카테고리 이름: CLOUDTRAIL_TRAILS_INTEGRATED_CLOUDWATCH_LOGS

AWS CloudTrail은 지정된 AWS 계정에서 수행된 AWS API 호출을 기록하는 웹 서비스입니다. 기록된 정보에는 API 호출자 ID, API 호출 시간, API 호출자의 소스 IP 주소, 요청 매개변수, AWS 서비스에서 반환한 응답 요소가 포함됩니다. CloudTrail은 로그 파일 저장과 전송에 Amazon S3를 사용하므로 로그 파일이 지속적으로 저장됩니다. 장기 분석을 위해 지정된 S3 버킷 내에서 CloudTrail 로그 캡처 외에도 로그를 CloudWatch Logs로 보내도록 CloudTrail을 구성하여 실시간 분석을 수행할 수 있습니다. 계정의 모든 리전에서 사용 설정된 추적의 경우 CloudTrail에서 모든 리전의 로그 파일을 CloudWatch Logs 로그 그룹으로 전송합니다. CloudTrail 로그를 CloudWatch Logs로 보내는 것이 좋습니다.

권장사항: CloudTrail 추적이 CloudWatch Logs와 통합되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

https://console.aws.amazon.com/cloudtrail/에서 CloudTrail 콘솔에 로그인합니다.
업데이트해야 하는 Trail을 선택합니다.
CloudWatch Logs까지 아래로 스크롤합니다.
Edit를 클릭합니다.
CloudWatch Logs 아래에서 Enabled 체크박스를 클릭합니다.
Log Group에서 새 로그 그룹을 선택하거나 기존 로그 그룹을 선택합니다.
CloudTrail과 일치하도록 Log group name을 수정하거나 기존 CloudWatch 그룹을 선택합니다.
IAM Role에서 새 항목을 선택하거나 기존 항목을 선택합니다.
CloudTrail과 일치하도록 Role name을 수정하거나 기존 IAM 역할을 선택합니다.
Save changes(변경사항 저장)를 클릭합니다.

AWS CLI

aws cloudtrail update-trail --name <trail_name> --cloudwatch-logs-log-group-arn <cloudtrail_log_group_arn> --cloudwatch-logs-role-arn <cloudtrail_cloudwatchLogs_role_arn>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cloudwatch Alarm Action Check`

API의 카테고리 이름: CLOUDWATCH_ALARM_ACTION_CHECK

알람이 'OK', 'ALARM' 또는 'INSUFFICIENT_DATA'로 전환될 때 Amazon Cloudwatch에 정의된 작업이 있는지 여부를 확인합니다.

모니터링되는 측정항목이 기준점을 위반할 때 즉각적인 응답을 트리거하려면 Amazon CloudWatch 알람에서 ALARM 상태에 대한 작업을 구성하는 것이 매우 중요합니다. 이를 통해 문제를 빠르게 해결하고 다운타임을 줄이며 자동화된 문제 해결을 사용 설정하여 시스템 상태를 유지하고 서비스 중단을 방지할 수 있습니다.

알람에 작업이 최소 하나 이상 있습니다. 알람이 다른 상태에서 'INSUFFICIENT_DATA' 상태로 전환되면 알람에 작업이 최소 하나 이상 있습니다. (선택사항) 알람이 다른 상태에서 'OK' 상태로 전환되면 알람에 작업이 최소 하나 이상 있습니다.

권장사항: CloudWatch 알람에 알람 작업 1개, INSUFFICIENT_DATA 작업 1개 또는 OK 작업 1개 이상이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

Amazon CloudWatch 알람에 대한 ALARM 작업을 구성하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/cloudwatch/에서 Amazon CloudWatch 콘솔을 엽니다.
탐색창의 'Alarms(알람)'에서 'All alarms(모든 알람)'를 선택합니다.
수정하려는 Amazon CloudWatch 알람을 선택하고 'Actions(작업)'를 선택한 다음 'Edit(수정)'을 선택합니다.
왼쪽에서 'Step 2 - optional Configure actions(2단계 - 선택적 구성 작업) '을 선택합니다.
'Alarm state trigger(알람 상태 트리거)'에 'In alarm(알람 상태)' 옵션을 선택하여 ALARM 기반 작업을 설정합니다.
새로 만든 SNS 주제에 알림을 보내려면 'Create new topic(새 주제 만들기)'을 선택합니다.
'Create new topic...(새 주제 만들기...)' 상자에 고유한 SNS 주제 이름을 지정합니다.
'Email endpoints that will receive the notification…(알림을 수신할 이메일 엔드포인트...)' 상자에 이메일 주소를 하나 이상 지정합니다.
그런 다음 'Create Topic(주제 만들기)'을 선택하여 필요한 Amazon SNS 주제를 만듭니다.
오른쪽 하단에서 'Next(다음)', 'Next(다음)'를 차례로 선택하고 'Update alarm(알람 업데이트)'을 선택하여 변경사항을 적용합니다.
이메일 클라이언트를 열고 AWS Notifications의 메일에서 링크를 클릭하여 해당 SNS 주제에 대한 구독을 확인합니다.
4~11단계를 반복하고 5단계에서 'Alarm state trigger(알람 상태 트리거)'에 'OK(확인)'와 'Insufficient data(데이터 불충분)'을 선택하여 두 상태에 대한 작업을 설정합니다.
동일한 AWS 리전 내의 다른 모든 CloudWatch 알람에 대해 이 프로세스를 반복합니다.
다른 모든 AWS 리전의 다른 모든 CloudWatch 알람에 대해 이 프로세스를 반복합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Cloudwatch Log Group Encrypted`

API의 카테고리 이름: CLOUDWATCH_LOG_GROUP_ENCRYPTED

이 검사에서는 CloudWatch 로그가 KMS로 구성되었는지 확인합니다.

로그 그룹 데이터는 항상 CloudWatch Logs에서 암호화됩니다. 기본적으로 CloudWatch Logs는 저장 로그 데이터에 서버 측 암호화를 사용합니다. 대신 이 암호화에 AWS Key Management Service를 사용할 수 있습니다. 이렇게 하면 AWS KMS 키를 통해 암호화가 수행됩니다. 로그 그룹을 만들 때나 로그 그룹이 존재한 후에 KMS 키를 로그 그룹과 연결하면 AWS KMS를 사용하는 암호화가 로그 그룹 수준에서 사용 설정됩니다.

권장사항: Amazon CloudWatch Logs의 모든 로그 그룹이 KMS로 암호화되는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`CloudTrail CloudWatch Logs Enabled`

API의 카테고리 이름: CLOUD_TRAIL_CLOUD_WATCH_LOGS_ENABLED

이 제어에서는 CloudTrail 추적이 로그를 CloudWatch Logs로 전송하도록 구성되어 있는지 확인합니다. 추적의 CloudWatchLogsLogGroupArn 속성이 비어 있으면 제어가 실패합니다.

CloudTrail은 지정된 계정에서 수행된 AWS API 호출을 기록합니다. 기록된 정보에는 다음이 포함됩니다.

API 호출자 ID
API 호출 시간
API 호출자의 소스 IP 주소
요청 매개변수
AWS 서비스에서 반환된 응답 요소

CloudTrail은 로그 파일 저장 및 전송에 Amazon S3를 사용합니다. 장기 분석을 위해 지정된 S3 버킷에서 CloudTrail 로그를 캡처할 수 있습니다. 실시간 분석을 수행하려면 CloudTrail을 구성하여 CloudWatch 로그로 로그를 전송하면 됩니다.

계정의 모든 리전에서 사용 설정된 추적의 경우 CloudTrail에서 모든 리전의 로그 파일을 CloudWatch Logs 로그 그룹으로 전송합니다.

Security Hub에서는 CloudTrail 로그를 CloudWatch Logs로 보내는 것이 좋습니다. 이 권장사항의 목적은 계정 활동을 캡처, 모니터링하고 적절하게 알람을 보내기 위함입니다. CloudWatch Logs를 사용하여 AWS 서비스로 이 작업을 설정할 수 있습니다. 이 권장사항으로 인해 다른 솔루션을 사용하지 않아도 됩니다.

CloudTrail 로그를 CloudWatch Logs로 전송하면 사용자, API, 리소스, IP 주소를 기반으로 실시간 및 이전 활동 로깅이 용이해집니다. 이 방식을 사용하여 비정상 또는 민감한 계정 활동에 대한 알람과 알림을 설정할 수 있습니다.

권장사항: 모든 CloudTrail 추적이 AWS CloudWatch로 로그를 전송하도록 구성되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`No AWS Credentials in CodeBuild Project Environment Variables`

API의 카테고리 이름: CODEBUILD_PROJECT_ENVVAR_AWSCRED_CHECK

프로젝트에 환경 변수 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY가 포함되어 있는지 확인합니다.

인증 사용자 인증 정보 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY는 일반 텍스트로 저장되어서는 안 됩니다. 의도치 않은 데이터 노출과 무단 액세스가 발생할 수 있기 때문입니다.

권장사항: 환경 변수 AWS_ACCESS_KEY_ID 및 AWS_SECRET_ACCESS_KEY가 포함된 모든 프로젝트가 일반 텍스트가 아닌지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Codebuild Project Source Repo Url Check`

API의 카테고리 이름: CODEBUILD_PROJECT_SOURCE_REPO_URL_CHECK

AWS CodeBuild 프로젝트 Bitbucket 소스 저장소 URL에 개인 액세스 토큰 또는 사용자 이름과 비밀번호가 포함되어 있는지 확인합니다. Bitbucket 소스 저장소 URL에 개인 액세스 토큰 또는 사용자 이름과 비밀번호가 포함되어 있으면 제어가 실패합니다.

로그인 사용자 인증 정보는 일반 텍스트로 저장 또는 전송되거나 소스 저장소 URL에 표시되어서는 안 됩니다. 개인 액세스 토큰이나 로그인 사용자 인증 정보 대신 CodeBuild에서 소스 제공업체에 액세스하고 Bitbucket 저장소 위치 경로만 포함되도록 소스 저장소 URL을 변경해야 합니다. 개인 액세스 토큰이나 로그인 사용자 인증 정보를 사용하면 의도치 않은 데이터 노출 또는 무단 액세스가 발생할 수 있습니다.

권장사항: GitHub 또는 Bitbucket을 소스로 사용하는 모든 프로젝트가 OAuth를 사용하는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Credentials Unused 45 Days Greater Disabled`

API의 카테고리 이름: CREDENTIALS_UNUSED_45_DAYS_GREATER_DISABLED

AWS IAM 사용자는 비밀번호 또는 액세스 키와 같은 여러 가지 유형의 사용자 인증 정보를 사용하여 AWS 리소스에 액세스할 수 있습니다. 45일 이상 사용되지 않은 모든 사용자 인증 정보를 비활성화하거나 삭제하는 것이 좋습니다.

권장사항: 45일 이상 사용되지 않은 사용자 인증 정보가 사용 중지되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

사용하지 않는 비밀번호(IAM 사용자 콘솔 액세스)를 관리하려면 다음 안내를 따르세요.

AWS Management Console에 로그인합니다.
Services를 클릭합니다.
IAM를 클릭합니다.
Users를 클릭합니다.
Security Credentials를 클릭합니다.
Console last sign-in이 45일을 초과하는 사용자를 선택합니다.
Security credentials를 클릭합니다.
Sign-in credentials, Console password 섹션에서 Manage를 클릭합니다.
Console Access(콘솔 액세스)에서 Disable을 선택합니다. 10. Apply를 클릭합니다.

액세스 키를 비활성화하려면 다음 안내를 따르세요.

AWS Management Console에 로그인합니다.
Services를 클릭합니다.
IAM를 클릭합니다.
Users를 클릭합니다.
Security Credentials를 클릭합니다.
45일 이상 경과된 액세스 키를 선택하고 액세스 키가 이미 사용되었다면 다음을 수행합니다.
- Make Inactive를 클릭합니다.
45일 이상 경과된 액세스 키를 선택하고 액세스 키가 아직 사용되지 않았다면 다음을 수행합니다.
- X를 클릭하여 Delete합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Default Security Group Vpc Restricts All Traffic`

API의 카테고리 이름: DEFAULT_SECURITY_GROUP_VPC_RESTRICTS_ALL_TRAFFIC

VPC에 초기 설정에서 모든 인바운드 트래픽을 거부하고 모든 아웃바운드 트래픽을 허용하며 보안 그룹에 할당된 인스턴스 간의 모든 트래픽을 허용하는 기본 보안 그룹이 제공됩니다. 인스턴스를 시작할 때 보안 그룹을 지정하지 않으면 인스턴스가 자동으로 이 기본 보안 그룹에 할당됩니다. 보안 그룹에서 AWS 리소스에 대한 인그레스/이그레스 네트워크 트래픽의 스테이트풀(Stateful) 필터링을 제공합니다. 기본 보안 그룹이 모든 트래픽을 제한하는 것이 좋습니다.

모든 리전의 기본 VPC에서는 이 권장사항을 준수하도록 기본 보안 그룹이 업데이트되어야 합니다. 새로 생성된 모든 VPC에는 이 권장사항을 준수하려면 해결이 필요한 기본 보안 그룹이 자동으로 포함됩니다.

참고: 이 권장사항을 구현할 때 VPC 흐름 로깅은 현재 보안 그룹에서 발생하는 모든 패킷 수락과 거부를 로깅할 수 있으므로 시스템이 제대로 작동하는 데 필요한 최소 권한 포트 액세스를 결정하는 데 매우 유용합니다. 이로 인해 최소 권한 엔지니어링에 대한 주요 장벽이 크게 낮아집니다. 즉, 환경의 시스템에 필요한 최소 포트 수를 탐색할 수 있습니다. 이 벤치마크의 VPC 흐름 로깅 권장사항이 영구 보안 조치로 채택되지 않더라도 최소 권한이 부여된 보안 그룹의 탐색 및 엔지니어링 기간 중에는 이 권장사항을 따라야 합니다.

권장사항: 모든 VPC의 기본 보안 그룹이 전체 트래픽을 제한하는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dms Replication Not Public`

API의 카테고리 이름: DMS_REPLICATION_NOT_PUBLIC

AWS DMS 복제 인스턴스가 공개 상태인지 확인하세요. 이를 위해 PubliclyAccessible 필드 값을 검사합니다.

비공개 복제 인스턴스에는 복제 네트워크 외부에서 액세스할 수 없는 비공개 IP 주소가 있습니다. 소스 데이터베이스와 대상 데이터베이스가 같은 네트워크에 있으면 복제 인스턴스에 비공개 IP 주소가 있어야 합니다. 또한 VPN, AWS Direct Connect 또는 VPC 피어링을 사용하여 네트워크를 복제 인스턴스의 VPC에 연결해야 합니다. 공개 및 비공개 복제 인스턴스에 대한 자세한 내용은 AWS Database Migration Service 사용자 가이드의 공개 및 비공개 복제 인스턴스를 참조하세요.

또한 AWS DMS 인스턴스 구성에 대한 액세스 권한이 승인된 사용자로만 제한되도록 해야 합니다. 이를 위해 AWS DMS 설정 및 리소스를 수정할 수 있는 사용자의 IAM 권한을 제한합니다.

권장사항: AWS Database Migration Service 복제 인스턴스가 공개 상태인지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Do Setup Access Keys During Initial User Setup All Iam Users Console`

API의 카테고리 이름: DO_SETUP_ACCESS_KEYS_DURING_INITIAL_USER_SETUP_ALL_IAM_USERS_CONSOLE

새 IAM 사용자를 만들 때 AWS 콘솔은 체크박스가 선택 취소된 상태로 기본 설정됩니다. IAM 사용자 인증 정보를 만들 때 필요한 액세스 유형을 결정해야 합니다.

프로그래매틱 액세스: IAM 사용자는 API 호출을 수행하거나 AWS CLI를 사용하거나 Windows PowerShell용 도구를 사용해야 할 수 있습니다. 이 경우 해당 사용자의 액세스 키(액세스 키 ID 및 보안 비밀 액세스 키)를 만듭니다.

AWS Management Console 액세스: 사용자가 AWS Management Console에 액세스해야 하는 경우 사용자의 비밀번호를 만듭니다.

권장사항: 콘솔 비밀번호가 있는 모든 IAM 사용자의 초기 사용자 설정 중에 액세스 키를 설정해서는 안 됩니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인합니다.
Services를 클릭합니다.
IAM를 클릭합니다.
Users를 클릭합니다.
Security Credentials를 클릭합니다.
관리자가 수행해야 할 작업
- 사용자 프로필과 동시에 생성되었지만 사용되지 않은 키의 경우 X(Delete)를 클릭합니다.
IAM 사용자가 수행해야 할 작업
- 사용자 프로필과 동시에 생성되었지만 사용되지 않은 키의 경우 X(Delete)를 클릭합니다.

AWS CLI

aws iam delete-access-key --access-key-id <access-key-id-listed> --user-name <users-name>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dynamodb Autoscaling Enabled`

API의 카테고리 이름: DYNAMODB_AUTOSCALING_ENABLED

Amazon DynamoDB 테이블이 필요에 따라 읽기 및 쓰기 용량을 확장할 수 있는지 확인합니다. 테이블에서 주문형 용량 모드 또는 자동 확장이 구성된 프로비저닝 모드를 사용하는 경우에는 이 제어가 통과됩니다. 수요에 따라 용량을 확장하면 예외 제한이 방지되어 애플리케이션 가용성을 유지할 수 있습니다.

주문형 용량 모드의 DynamoDB 테이블은 DynamoDB 처리량 기본 테이블 할당량에 의해서만 제한됩니다. 이러한 할당량을 늘리려면 AWS 지원팀을 통해 지원 티켓을 제출하면 됩니다.

자동 확장을 사용하는 프로비저닝 모드의 DynamoDB 테이블은 트래픽 패턴에 대응하여 프로비저닝된 처리량 용량을 동적으로 조정합니다. DynamoDB 요청 제한에 대한 자세한 내용은 Amazon DynamoDB 개발자 가이드의 요청 제한 및 버스트 용량을 참조하세요.

권장사항: DynamoDB 테이블이 수요에 맞춰 용량을 자동 확장해야 합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dynamodb In Backup Plan`

API의 카테고리 이름: DYNAMODB_IN_BACKUP_PLAN

이 제어는 DynamoDB 테이블이 백업 계획에 포함되는지 여부를 평가합니다. DynamoDB 테이블이 백업 계획에 포함되지 않으면 제어가 실패합니다. 이 제어는 ACTIVE 상태의 DynamoDB 테이블만 평가합니다.

백업은 보안 사고를 더 빠르게 복구하는 데 도움이 됩니다. 또한 시스템의 복원력을 강화합니다. 백업 계획에 DynamoDB 테이블을 포함하면 의도치 않은 손실이나 삭제로부터 데이터를 보호할 수 있습니다.

권장사항: DynamoDB 테이블이 백업 계획에 포함되어야 합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dynamodb Pitr Enabled`

API의 카테고리 이름: DYNAMODB_PITR_ENABLED

PITR(point-in-time recovery)은 DynamoDB 테이블 백업에 사용할 수 있는 메커니즘 중 하나입니다.

특정 시점 백업은 35일 동안 유지됩니다. 더 오래 보관해야 하는 경우에는 AWS 문서의 AWS Backup을 사용하여 Amazon DynamoDB에 대해 예약된 백업 설정을 참조하세요.

권장사항: 모든 AWS DynamoDB 테이블에 PITR(point-in-time recovery)이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

DynamoDB 테이블에 PITR을 설정하려면 point_in_time_recovery 블록을 설정합니다.

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  point_in_time_recovery {
    enabled = true
  }
}

AWS 콘솔

기존 테이블에 DynamoDB PITR(point-in-time recovery)을 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/dynamodb/에서 DynamoDB 콘솔을 엽니다.
작업할 테이블을 선택한 다음 Backups(백업)를 선택합니다.
PITR(point-in-time recovery) 섹션의 Status(상태)에서 Enable(사용 설정)을 선택합니다.
다시 Enable(사용 설정)을 선택하여 변경사항을 확인합니다.

AWS CLI

aws dynamodb update-continuous-backups \
  --table-name "GameScoresOnDemand" \
  --point-in-time-recovery-specification "PointInTimeRecoveryEnabled=true"

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Dynamodb Table Encrypted Kms`

API의 카테고리 이름: DYNAMODB_TABLE_ENCRYPTED_KMS

모든 DynamoDB 테이블이 고객 관리 KMS 키(기본값 아님)로 암호화되었는지 확인합니다.

권장사항: 모든 DynamoDB 테이블이 AWS Key Management Service(KMS)로 암호화되었는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

이 제어를 해결하려면 AWS KMS 키를 만든 다음 이 키를 사용해 위반 DynamoDB 리소스 암호화를 암호화합니다.

resource "aws_kms_key" "dynamodb_encryption" {
  description         = "Used for DynamoDB encryption configuration"
  enable_key_rotation = true
}

resource "aws_dynamodb_table" "example" {
  # ... other configuration ...
  server_side_encryption {
    enabled     = true
    kms_key_arn = aws_kms_key.dynamodb_encryption.arn
  }
}

AWS 콘솔

DynamoDB를 암호화하는 데 사용할 수 있는 기존 AWS KMS 키가 있다고 가정합니다.

DynamoDB 테이블 암호화를 고객이 관리하고 소유하는 KMS 키로 변경하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/dynamodb/에서 DynamoDB 콘솔을 엽니다.
작업할 테이블을 선택한 다음 Additional settings(추가 설정)를 선택합니다.
Encryption(암호화)에서 Manage encryption(암호화 관리)을 선택합니다.
Encryption at rest(저장 데이터 암호화)의 경우 개발자의 계정에 저장되고 개발자가 소유하고 관리하는 옵션을 선택합니다.
사용할 AWS 키를 선택합니다. 변경사항 저장을 클릭합니다.

AWS CLI

aws dynamodb update-table \
  --table-name <value> \
  --sse-specification "Enabled=true,SSEType=KMS,KMSMasterKeyId=<kms_key_arn>"

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ebs Optimized Instance`

API의 카테고리 이름: EBS_OPTIMIZED_INSTANCE

EBS 최적화가 가능한 EC2 인스턴스에 EBS 최적화가 사용 설정되어 있는지 확인합니다.

권장사항: EBS 최적화를 지원하는 모든 인스턴스에 EBS 최적화가 사용 설정되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ebs Snapshot Public Restorable Check`

API의 카테고리 이름: EBS_SNAPSHOT_PUBLIC_RESTORABLE_CHECK

Amazon Elastic Block Store 스냅샷이 공개 상태가 아닌지 확인합니다. 누군가 Amazon EBS 스냅샷을 복원할 수 있으면 제어가 실패합니다.

EBS 스냅샷은 특정 시점에 EBS 볼륨에 있는 데이터를 Amazon S3에 백업하는 데 사용됩니다. 스냅샷을 사용하여 EBS 볼륨의 이전 상태를 복원할 수 있습니다. 스냅샷을 공개적으로 공유하는 것은 거의 허용되지 않습니다. 일반적으로 스냅샷을 공개적으로 공유하기로 한 결정은 잘못되었거나 영향에 대한 완전한 이해 없이 진행된 것입니다. 이러한 확인은 이러한 모든 공유가 완전히 계획되고 의도한 것인지 확인하는 데 도움이 됩니다.

권장사항: Amazon EBS 스냅샷을 공개적으로 복원할 수 있어서는 안 됩니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

이 문제를 해결하려면 EBS 스냅샷을 공개 대신 비공개로 업데이트하세요.

공개 EBS 스냅샷을 비공개로 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색창의 Elastic Block Store에서 Snapshots menu(스냅샷 메뉴)를 선택한 후 공개 스냅샷을 선택합니다.
Actions(작업)에서 Modify permissions(권한 수정)를 선택합니다.
Private(비공개)을 선택합니다.
(선택사항) 스냅샷을 공유할 승인된 계정의 AWS 계정 번호를 추가하고 Add Permission(권한 추가)을 선택합니다.
Save(저장)를 선택합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ebs Volume Encryption Enabled All Regions`

API의 카테고리 이름: EBS_VOLUME_ENCRYPTION_ENABLED_ALL_REGIONS

Elastic Block Store(EBS) 서비스를 사용할 때 Elastic Compute Cloud(EC2)에서 저장 데이터를 암호화할 수 있습니다. 기본적으로 사용 중지되어 있지만 EBS 볼륨을 만들 때 암호화를 강제 적용할 수 있습니다.

권장사항: 모든 리전에 EBS 볼륨 암호화가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/ec2/를 사용하여 Amazon EC2 콘솔을 엽니다.
Account attributes 아래에서 EBS encryption을 클릭합니다.
Manage를 클릭합니다.
Enable 체크박스를 클릭합니다.
Update EBS encryption를 클릭합니다.
변경이 필요한 모든 리전에 대해 이 작업을 반복합니다.

참고: EBS 볼륨 암호화는 리전별로 구성됩니다.

AWS CLI

aws --region <region> ec2 enable-ebs-encryption-by-default를 실행합니다.
"EbsEncryptionByDefault": true가 표시되는지 확인합니다.
변경이 필요한 모든 리전에 대해 이 작업을 반복합니다.

참고: EBS 볼륨 암호화는 리전별로 구성됩니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ec2 Instances In Vpc`

API의 카테고리 이름: EC2_INSTANCES_IN_VPC

Amazon VPC는 EC2 Classic보다 더 많은 보안 기능을 제공합니다. 모든 노드가 Amazon VPC에 속하는 것이 좋습니다.

권장사항: 모든 인스턴스가 VPC에 속하는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

EC2 Classic 인스턴스가 Terraform에 정의되어 있는 경우 VPC의 일부로 리소스를 수정할 수 있습니다. 이러한 마이그레이션은 니즈에 가장 적합한 아키텍처에 따라 달라집니다. 다음은 VPC에서 공개적으로 노출된 EC2를 보여주는 간단한 Terraform 예시입니다.

  resource "aws_vpc" "example_vpc" {
    cidr_block = "10.0.0.0/16"
  }

  resource "aws_subnet" "example_public_subnet" {
    vpc_id            = aws_vpc.example_vpc.id
    cidr_block        = "10.0.1.0/24"
    availability_zone = "1a"
  }

  resource "aws_internet_gateway" "example_igw" {
    vpc_id = aws_vpc.example_vpc.id
  }

  resource "aws_key_pair" "example_key" {
    key_name   = "web-instance-key"
    public_key = "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD3F6tyPEFEzV0LX3X8BsXdMsQz1x2cEikKDEY0aIj41qgxMCP/iteneqXSIFZBp5vizPvaoIR3Um9xK7PGoW8giupGn+EPuxIA4cDM4vzOqOkiMPhz5XK0whEjkVzTo4+S0puvDZuwIsdiW9mxhJc7tgBNL0cYlWSYVkz4G/fslNfRPW5mYAM49f4fhtxPb5ok4Q2Lg9dPKVHO/Bgeu5woMc7RY0p1ej6D4CKFE6lymSDJpW0YHX/wqE9+cfEauh7xZcG0q9t2ta6F6fmX0agvpFyZo8aFbXeUBr7osSCJNgvavWbM/06niWrOvYX2xwWdhXmXSrbX8ZbabVohBK41 email@example.com"
  }

  resource "aws_security_group" "web_sg" {
    name   = "http and ssh"
    vpc_id = aws_vpc.some_custom_vpc.id

    ingress {
      from_port   = 80
      to_port     = 80
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    ingress {
      from_port   = 22
      to_port     = 22
      protocol    = "tcp"
      cidr_blocks = ["0.0.0.0/0"]
    }

    egress {
      from_port   = 0
      to_port     = 0
      protocol    = -1
      cidr_blocks = ["0.0.0.0/0"]
    }
  }

  resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    key_name               = aws_key_pair.example_key.name
    monitoring             = true
    subnet_id              = aws_subnet.example_public_subnet.id
    vpc_security_group_ids = [aws_security_group.web_sg.id]
    metadata_options {
      http_tokens = "required"
    }
  }

AWS 콘솔

EC2 Classic을 VPC로 마이그레이션하려면 EC2-Classic을 VPC로 마이그레이션을 참조하세요.

AWS CLI

이 AWS CLI 예시는 Terraform에 정의되어 있는 동일한 인프라를 보여줍니다. VPC에 공개적으로 노출된 EC2 인스턴스의 간단한 예시입니다.

VPC 만들기

  aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16

공개 서브넷 만들기

  aws ec2 create-subnet \
  --availability-zone 1a \
  --cidr-block 10.0.1.0/24 \
  --vpc-id <id_from_create-vpc_command>

인터넷 게이트웨이 만들기

  aws ec2 create-internet-gateway

VPC에 인터넷 게이트웨이 연결

  aws ec2 attach-internet-gateway \
  --internet-gateway-id <id_from_create-internet-gateway_command> \
  --vpc-id <id_from_create-vpc_command>

키 쌍 만들기 - 비공개 키를 /.ssh/web-instance-key.pem에 저장합니다.

  aws ec2 create-key-pair \
  --key-name web-instance-key \
  --query "KeyMaterial" \
  --output text > ~/.ssh/web-instance-key.pem && \
  chmod 400 ~/.ssh/web-instance-key.pem

보안 그룹 만들기

  aws ec2 create-security-group \
  --group-name "http and ssh" \
  --vpc-id <id_from_create-vpc_command>

보안 그룹 규칙 만들기 - 액세스 권한을 더 제한하려면 포트 22에서 SSH에 대해 더 제한된 CIDR을 정의하세요.

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-ingress \
  --group-id <id_from_create-security-group_command>
  --protocol tcp \
  --port 22 \
  --cidr 0.0.0.0/0

  aws ec2 authorize-security-group-egress \
  --group-id <id_from_create-security-group_command>
  --protocol -1 \
  --port 0 \
  --cidr 0.0.0.0/0

EC2 인스턴스 만들기

  aws ec2 run-instances \
  --image-id <ami_id> \
  --instance-type <instance_flavor> \
  --metadata-options "HttpEndpoint=enabled,HttpTokens=required" \
  --monitoring true \
  --key-name web-instance-key \
  --subnet-id <id_from_create-subnet_command> \
  --security-group-ids <id_from_create-security-group_command>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ec2 Instance No Public Ip`

API의 카테고리 이름: EC2_INSTANCE_NO_PUBLIC_IP

공개 IP 주소가 있는 EC2 인스턴스의 손상 위험이 증가합니다. EC2 인스턴스를 공개 IP 주소로 구성하지 않는 것이 좋습니다.

권장사항: 공개 IP가 있는 인스턴스가 없는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

aws_instance 리소스와 함께 associate_public_ip_address = false 인수를 사용하여 EC2 인스턴스가 공개 IP 주소 없이 프로비저닝되도록 합니다.


resource "aws_instance" "no_public_ip" {
  ...
  associate_public_ip_address = false
}

AWS 콘솔

기본적으로 기본값이 아닌 서브넷의 IPv4 공개 주소 속성은 false로 설정되어 있고 기본 서브넷은 이 속성이 true로 설정되어 있습니다. 예외는 Amazon EC2 시작 인스턴스 마법사에서 만든 기본값이 아닌 서브넷입니다. 마법사는 이 속성을 true로 설정합니다. Amazon VPC 콘솔을 사용하여 이 속성을 수정할 수 있습니다.

서브넷의 공개 IPv4 주소 지정 동작을 수정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.
탐색창에서 Subnets(서브넷)을 선택합니다.
서브넷을 선택하고 Actions(작업), Edit subnet settings(서브넷 설정 수정)을 선택합니다.
Enable auto-assign public IPv4 address(공개 IPv4 주소 자동 할당 사용 설정) 체크박스를 선택하면 선택된 서브넷에서 시작된 모든 인스턴스에 대한 공개 IPv4 주소를 요청합니다. 필요에 따라 체크박스를 선택하거나 선택 해제한 후 Save(저장)를 선택합니다.

AWS CLI

다음 명령어는 공개 IP 주소를 연결하지 않고 기본 서브넷에서 EC2 인스턴스를 실행합니다.

aws ec2 run-instances \
--image-id <ami_id> \
--instance-type <instance_flavor> \
--no-associate-public-ip-address \
--key-name MyKeyPair

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ec2 Managedinstance Association Compliance Status Check`

API의 카테고리 이름: EC2_MANAGEDINSTANCE_ASSOCIATION_COMPLIANCE_STATUS_CHECK

State Manager 연결은 사용자의 관리형 인스턴스에 할당된 구성입니다. 이 구성은 인스턴스에서 유지하려는 상태를 정의합니다. 예를 들어 연결에서 인스턴스에 바이러스 백신 소프트웨어를 설치 및 실행하거나 특정 포트를 닫도록 지정할 수 있습니다. AWS Systems Manager와 연결된 EC2 인스턴스는 Systems Manager의 관리를 통해 패치를 더 쉽게 적용하고 잘못된 구성을 수정하며 보안 이벤트에 대응할 수 있습니다.

권장사항: 규정 준수 상태 AWS 시스템 관리자 연결을 확인합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

다음 예시에서는 간단한 EC2 인스턴스, AWS Systems Manager(SSM) 문서, SSM과 EC2 인스턴스 간의 연결을 만드는 방법을 보여줍니다. 지원되는 문서는 Command 및 Policy 유형입니다.

resource "aws_instance" "web" {
  ami           = "<iam_id>"
  instance_type = "<instance_flavor>"
}

resource "aws_ssm_document" "check_ip" {
  name          = "check-ip-config"
  document_type = "Command"

  content = <<DOC
  {
    "schemaVersion": "1.2",
    "description": "Check ip configuration of a Linux instance.",
    "parameters": {

    },
    "runtimeConfig": {
      "aws:runShellScript": {
        "properties": [
          {
            "id": "0.aws:runShellScript",
            "runCommand": ["ifconfig"]
          }
        ]
      }
    }
  }
DOC
}

resource "aws_ssm_association" "check_ip_association" {
  name = aws_ssm_document.check_ip.name

  targets {
    key    = "InstanceIds"
    values = [aws_instance.web.id]
  }
}

AWS 콘솔

콘솔을 사용하여 AWS Systems Manager와의 연결을 구성하는 방법에 대한 자세한 내용은 AWS Systems Manager 문서의 연결 만들기를 참조하세요.

AWS CLI

SSM 문서 만들기

aws ssm create-document \
--name <document_name> \
--content  file://path/to-file/document.json \
--document-type "Command"

SSM 연결 만들기

aws ssm create-association \
--name <association_name> \
--targets "Key=InstanceIds,Values=<instance-id-1>,<instance-id-2>"

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ec2 Managedinstance Patch Compliance Status Check`

API의 카테고리 이름: EC2_MANAGEDINSTANCE_PATCH_COMPLIANCE_STATUS_CHECK

이 제어는 연결이 인스턴스에서 실행된 후 AWS Systems Manager 연결 규정 준수 상태가 COMPLIANT 또는 NON_COMPLIANT인지 여부를 확인합니다. 연결 규정 준수 상태가 NON_COMPLIANT이면 제어가 실패합니다.

State Manager 연결은 사용자의 관리형 인스턴스에 할당된 구성입니다. 이 구성은 인스턴스에서 유지하려는 상태를 정의합니다. 예를 들어 연결에서 인스턴스에 바이러스 백신 소프트웨어를 설치 및 실행하거나 특정 포트를 닫도록 지정할 수 있습니다.

State Manager 연결을 하나 이상 만들면 규정 준수 상태 정보가 자동으로 제공됩니다. 콘솔에서 또는 AWS CLI 명령어나 해당하는 Systems Manager API 작업에 대한 응답으로 규정 준수 상태를 볼 수 있습니다. 연결의 경우 구성 규정 준수에는 규정 준수 상태(준수 또는 미준수)가 표시됩니다. 연결에 할당된 심각도 수준도 표시됩니다(예: 심각 또는 중간).

State Manager 연결 규정 준수에 대한 자세한 내용은 AWS Systems Manager 사용자 가이드의 State Manager 연결 규정 준수 정보를 참조하세요.

권장사항: AWS Systems Manager 패치 규정 준수의 상태를 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ec2 Metadata Service Allows Imdsv2`

API의 카테고리 이름: EC2_METADATA_SERVICE_ALLOWS_IMDSV2

AWS EC2 인스턴스에서 메타데이터 서비스를 사용 설정할 때 사용자는 인스턴스 메타데이터 서비스 버전 1(IMDSv1, 요청/응답 메서드) 또는 인스턴스 메타데이터 서비스 버전 2(IMDSv2, 세션 중심 메서드)를 사용할 수 있습니다.

권장사항: EC2 메타데이터 서비스가 IMDSv2만 허용하는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Ec2 Volume Inuse Check`

API의 카테고리 이름: EC2_VOLUME_INUSE_CHECK

월별 AWS 청구서 비용을 낮추기 위해 AWS 계정에서 연결되지 않은(사용되지 않는) Elastic Block Store(EBS) 볼륨을 식별하고 삭제합니다. 사용하지 않는 EBS 볼륨을 삭제하면 기밀/민감한 정보가 프레미스에서 손실될 위험이 줄어듭니다. 또한 이 제어는 EC2 인스턴스가 종료 시 볼륨을 삭제하도록 구성되어 있는지 여부도 확인합니다.

기본적으로 EC2 인스턴스는 인스턴스와 연결된 모든 EBS 볼륨의 데이터를 삭제하고 인스턴스의 루트 EBS 볼륨을 삭제하도록 구성됩니다. 하지만 기본적으로 시작 시 또는 실행 중에 인스턴스에 연결된 루트가 아닌 EBS 볼륨은 종료 후에도 유지됩니다.

권장사항: EBS 볼륨이 EC2 인스턴스에 연결되어 있고 인스턴스 종료 시 삭제되도록 구성되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

Terraform을 사용하여 이 시나리오를 방지하려면 내장된 EBS 블록으로 EC2 인스턴스를 만듭니다. 이렇게 하면 ebs_block_device.delete_on_termination 속성이 true로 기본 설정되므로 인스턴스 종료 시 루트뿐만 아니라 인스턴스와 연결된 모든 EBS 블록이 삭제됩니다.

resource "aws_instance" "web" {
    ami                    = <ami_id>
    instance_type          = <instance_flavor>
    ebs_block_device {
      delete_on_termination = true # Default
      device_name           = "/dev/sdh"
    }

AWS 콘솔

콘솔을 사용하여 EBS 볼륨을 삭제하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색창에서 Volumes(볼륨)를 선택합니다.
삭제할 볼륨을 선택하고 Actions(작업), Delete volume(볼륨 삭제)을 선택합니다.
참고: 볼륨 삭제가 비활성화되면 볼륨이 인스턴스에 연결된 것입니다. 볼륨을 삭제하려면 먼저 인스턴스에서 분리해야 합니다.
확인 대화상자에서 Delete(삭제)를 선택합니다.

AWS CLI

이 예시 명령어는 볼륨 ID가 vol-049df61146c4d7901인 사용 가능한 볼륨을 삭제합니다. 명령어가 성공하면 출력이 반환되지 않습니다.

aws ec2 delete-volume --volume-id vol-049df61146c4d7901

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Efs Encrypted Check`

API의 카테고리 이름: EFS_ENCRYPTED_CHECK

Amazon EFS는 두 가지 형태의 파일 시스템 암호화 즉, 전송 중 데이터 암호화와 저장 데이터 암호화를 지원합니다. 이를 통해 계정에서 사용 설정된 모든 리전에서 모든 EFS 파일 시스템이 저장 데이터 암호화로 구성되었는지 확인합니다.

권장사항: EFS가 KMS를 사용하여 파일 데이터를 암호화하도록 구성되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

다음 코드 스니펫을 사용하여 KMS로 암호화된 EFS를 만들 수 있습니다. 참고: kms_key_id 속성은 선택사항이며 KMS 키 ID가 전달되지 않으면 키가 생성됩니다.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-kms-encrypted-efs"
  encrypted      = true
  kms_key_id     = "arn:aws:kms:us-west-2:12344375555:key/16393ebd-3348-483f-b162-99b6648azz23"

  tags = {
    Name = "MyProduct"
  }
}

AWS 콘솔

AWS 콘솔을 사용하여 암호화로 EFS를 구성하려면 콘솔을 사용하여 저장 파일 시스템 암호화를 참조하세요.

AWS CLI

Console에서 EFS를 만들 때 기본적으로 저장 데이터 암호화가 사용 설정된다는 점에 유의해야 합니다. 단, CLI, API, SDK를 사용하여 만든 EFS에는 적용되지 않습니다. 다음 예시를 사용하면 인프라에 암호화된 파일 시스템을 만들 수 있습니다.

aws efs create-file-system \
--backup \
--encrypted \
--region us-east-1 \

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Efs In Backup Plan`

API의 카테고리 이름: EFS_IN_BACKUP_PLAN

Amazon 권장사항에서는 Elastic File Systems(EFS)의 백업을 구성할 것을 권장합니다. 이를 통해 AWS 계정에서 사용 설정된 모든 리전에서 모든 EFS에 백업이 사용 설정되었는지 확인합니다.

권장사항: EFS 파일 시스템이 AWS 백업 계획에 포함되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

aws_efs_backup_policy 리소스를 사용하여 EFS 파일 시스템의 백업 정책을 구성합니다.

resource "aws_efs_file_system" "encrypted-efs" {
  creation_token = "my-encrypted-efs"
  encrypted      = true

  tags = merge({
    Name = "${local.resource_prefix.value}-efs"
    }, {
    git_file             = "terraform/aws/efs.tf"
    git_org              = "your_git_org"
    git_repo             = "your_git_repo"
  })
}

resource "aws_efs_backup_policy" "policy" {
  file_system_id = aws_efs_file_system.encrypted-efs.id

  backup_policy {
    status = "ENABLED"
  }
}

AWS 콘솔

EFS를 백업하는 데에는 AWS Backup 서비스와 EFS-EFS 백업 솔루션의 두 가지 옵션이 있습니다. 콘솔을 사용하여 백업되지 않은 EFS를 해결하려면 다음을 참조하세요.

AWS CLI

CLI를 사용하여 규정을 준수하는 EFS 파일 시스템을 만드는 방법에는 몇 가지가 있습니다.

자동 백업이 사용 설정된 EFS 만들기(One Zone 스토리지의 경우 기본값이며 AWS 리전의 백업 가용성에 따라 달라짐)
EFS 만들기 및 백업 정책 적용

하지만 기존 EFS에서 해결을 수행해야 한다고 가정할 때 가장 좋은 옵션은 백업 정책을 만들고 이를 규정 미준수 EFS에 연결하는 것입니다. 인프라의 모든 EFS에 대해 하나의 명령어가 필요합니다.

arr=( $(aws efs describe-file-systems | jq -r '.FileSystems[].FileSystemId') )
for efs in "${arr[@]}"
do
  aws efs put-backup-policy \
  --file-system-id "${efs}" \
  --backup-policy "Status=ENABLED"
done

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Elb Acm Certificate Required`

API의 카테고리 이름: ELB_ACM_CERTIFICATE_REQUIRED

Classic Load Balancer가 AWS Certificate Manager(ACM)에서 제공하는 HTTPS/SSL 인증서를 사용하는지 확인합니다. HTTPS/SSL 리스너로 구성된 Classic Load Balancer가 ACM에서 제공하는 인증서를 사용하지 않으면 제어가 실패합니다.

인증서를 만들려면 ACM 또는 OpenSSL과 같이 SSL 및 TLS 프로토콜을 지원하는 도구를 사용하면 됩니다. Security Hub에서는 ACM을 사용하여 부하 분산기의 인증서를 만들거나 가져오는 것이 좋습니다.

ACM은 Classic Load Balancer와 통합되므로 부하 분산기에 인증서를 배포할 수 있습니다. 또한 이러한 인증서를 자동으로 갱신해야 합니다.

권장사항: 모든 Classic Load Balancer가 AWS Certificate Manager에서 제공하는 SSL 인증서를 사용하는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Elb Deletion Protection Enabled`

API의 카테고리 이름: ELB_DELETION_PROTECTION_ENABLED

Application Load Balancer에 삭제 보호가 사용 설정되어 있는지 확인합니다. 삭제 보호가 구성되지 않으면 제어가 실패합니다.

Application Load Balancer가 삭제되지 않도록 보호하려면 삭제 보호를 사용 설정합니다.

권장사항: Application Load Balancer 삭제 보호가 사용 설정되어야 합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

실수로 부하 분산기가 삭제되지 않도록 하려면 삭제 방지를 사용 설정하면 됩니다. 기본적으로 부하 분산기의 삭제 방지는 사용 중지됩니다.

부하 분산기에 삭제 방지를 사용 설정한 경우에는 부하 분산기를 삭제하기 전에 삭제 방지를 사용 중지해야 합니다.

콘솔에서 삭제 방지를 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색창의 LOAD BALANCING(부하 분산)에서 Load Balancers(부하 분산기)를 선택합니다.
부하 분산기를 선택합니다.
Description(설명) 탭에서 Edit attributes(속성 수정)를 선택합니다.
Edit load balancer attributes(부하 분산기 속성 수정) 페이지에서 Enable for Delete Protection(삭제 보호 사용 설정)을 선택한 다음 Save(저장)를 선택합니다.
저장을 선택합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Elb Logging Enabled`

API의 카테고리 이름: ELB_LOGGING_ENABLED

Application Load Balancer 및 Classic Load Balancer에서 로깅이 사용 설정되었는지 여부를 확인합니다. access_logs.s3.enabled가 false이면 제어가 실패합니다.

Elastic Load Balancing은 부하 분산기로 전송된 요청에 대한 자세한 정보를 캡처하는 액세스 로그를 제공합니다. 각 로그에는 요청이 수신된 시간, 클라이언트의 IP 주소, 지연 시간, 요청 경로, 서버 응답과 같은 정보가 포함됩니다. 이러한 액세스 로그를 사용하여 트래픽 패턴을 분석하고 문제를 해결할 수 있습니다.

자세한 내용은 Classic Load Balancer 사용자 가이드의 Classic Load Balancer 액세스 로그를 참조하세요.

권장사항: Classic 및 Application Load Balancer에 로깅이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

이 문제를 해결하려면 부하 분산기를 업데이트하여 로깅을 사용 설정합니다.

액세스 로그를 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색창에서 Load balancers(부하 분산기)를 선택합니다.
Application Load Balancer 또는 Classic Load Balancer를 선택합니다.
Actions(작업)에서 Edit attributes(속성 수정)를 선택합니다.
Access logs(액세스 로그)에서 Enable(사용 설정)을 선택합니다.
S3 위치를 입력합니다. 이 위치는 이미 있을 수도 있고 만들 수도 있습니다. 프리픽스를 지정하지 않으면 액세스 로그가 S3 버킷의 루트에 저장됩니다.
저장을 선택합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Elb Tls Https Listeners Only`

API의 카테고리 이름: ELB_TLS_HTTPS_LISTENERS_ONLY

이 검사에서는 모든 Classic Load Balancer가 보안 통신을 사용하도록 구성되었는지 확인합니다.

리스너는 연결 요청을 확인하는 프로세스입니다. 이는 프런트엔드(클라이언트-부하 분산기) 연결에 사용되는 프로토콜과 포트, 백엔드(부하 분산기-인스턴스) 연결에 사용되는 프로토콜로 구성됩니다. Elastic Load Balancing에서 지원하는 포트, 프로토콜, 리스너 구성에 대한 자세한 내용은 Classic Load Balancer의 리스너를 참조하세요.

권장사항: 모든 Classic Load Balancer가 SSL 또는 HTTPS 리스너로 구성되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Encrypted Volumes`

API의 카테고리 이름: ENCRYPTED_VOLUMES

연결된 상태의 EBS 볼륨이 암호화되었는지 확인합니다. 이 검사를 통과하려면 EBS 볼륨이 사용 중이고 암호화되어야 합니다. EBS 볼륨이 연결되지 않은 경우 이 검사가 적용되지 않습니다.

EBS 볼륨의 민감한 정보에 대한 보안을 강화하려면 EBS 저장 데이터 암호화를 사용 설정해야 합니다. Amazon EBS 암호화는 EBS 리소스를 위한 직관적인 암호화 솔루션을 제공하므로 자체 키 관리 인프라를 빌드, 유지, 보호할 필요가 없습니다. 암호화된 볼륨과 스냅샷을 만들 때 KMS 키를 사용합니다.

Amazon EBS 암호화에 대한 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용자 가이드의 Amazon EBS 암호화를 참조하세요.

권장사항: 연결된 Amazon EBS 볼륨의 저장 데이터가 암호화되어야 합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

암호화되지 않은 기존 볼륨이나 스냅샷을 암호화할 수 있는 직접적인 방법은 없습니다. 새 볼륨이나 스냅샷을 만들 때만 암호화할 수 있습니다.

기본적으로 암호화를 사용 설정한 경우 Amazon EBS는 Amazon EBS 암호화의 기본 키를 사용하여 생성된 새 볼륨 또는 스냅샷을 암호화합니다. 기본적으로 암호화를 사용 설정하지 않은 경우에도 개별 볼륨이나 스냅샷을 만들 때 암호화를 사용 설정할 수 있습니다. 두 경우 모두 Amazon EBS 암호화의 기본 키를 재정의하고 고객이 관리하는 대칭 키를 선택할 수 있습니다.

자세한 내용은 Linux 인스턴스용 Amazon EC2 사용자 가이드의 Amazon EBS 볼륨 만들기 및 Amazon EBS 스냅샷 복사를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Encryption At Rest Enabled Rds Instances`

API의 카테고리 이름: ENCRYPTION_AT_REST_ENABLED_RDS_INSTANCES

Amazon RDS 암호화된 DB 인스턴스는 업계 표준 AES-256 암호화 알고리즘을 사용하여 Amazon RDS DB 인스턴스를 호스팅하는 서버에서 데이터를 암호화합니다. 데이터가 암호화되면 Amazon RDS는 성능에 미치는 영향을 최소화하면서 액세스 인증과 데이터 복호화를 투명하게 처리합니다.

권장사항: RDS 인스턴스에 저장 데이터 암호화가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/rds/에서 RDS 대시보드를 엽니다.
왼쪽 탐색 패널에서 Databases를 클릭합니다.
암호화해야 하는 데이터베이스 인스턴스를 선택합니다.
오른쪽 상단에 있는 Actions 버튼을 클릭하고 Take Snapshot을 선택합니다.
Take Snapshot(스냅샷 만들기) 페이지에서 Snapshot Name 필드에 스냅샷을 만들 데이터베이스 이름을 입력하고 Take Snapshot을 클릭합니다.
새로 만든 스냅샷을 선택하고 오른쪽 상단에 있는 Action 버튼을 클릭한 다음 작업 메뉴에서 Copy snapshot을 선택합니다.
Make Copy of DB Snapshot(DB 스냅샷의 사본 만들기) 페이지에서 다음을 수행합니다.

New DB Snapshot Identifier(새 DB 스냅샷 식별자) 필드에 new snapshot의 이름을 입력합니다.
Copy Tags를 확인합니다. 새 스냅샷에는 소스 스냅샷과 동일한 태그가 있어야 합니다.
Enable Encryption 드롭다운 목록에서 Yes를 선택하여 암호화를 사용 설정합니다. AWS 기본 암호화 키 또는 마스터 키 드롭다운 목록에서 커스텀 키를 사용할 수 있습니다.

Copy Snapshot을 클릭하여 선택한 인스턴스 스냅샷의 암호화된 사본을 만듭니다.
새 스냅샷 암호화 사본을 선택하고 오른쪽 상단에 있는 Action 버튼을 클릭하고 작업 메뉴에서 Restore Snapshot 버튼을 선택합니다. 이렇게 하면 암호화된 스냅샷이 새 데이터베이스 인스턴스로 복원됩니다.
DB 인스턴스 복원 페이지에서 DB 인스턴스 식별자 필드에 새 데이터베이스 인스턴스의 고유한 이름을 입력합니다.
인스턴스 구성 세부정보를 검토하고 Restore DB Instance를 클릭합니다.
새 인스턴스 프로비저닝 프로세스가 완료되면 새 암호화된 데이터베이스 인스턴스의 엔드포인트를 참조하도록 애플리케이션 구성을 업데이트할 수 있습니다. 애플리케이션 수준에서 데이터베이스 엔드포인트가 변경되면 암호화되지 않은 인스턴스를 삭제할 수 있습니다.

AWS CLI

describe-db-instances 명령어를 실행하여 선택한 AWS 리전에서 사용 가능한 모든 RDS 데이터베이스 이름을 나열합니다. 명령어 결과에 데이터베이스 인스턴스 식별자가 반환됩니다. aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
create-db-snapshot 명령어를 실행하여 선택한 데이터베이스 인스턴스의 스냅샷을 만듭니다. 명령어 결과에 DB 스냅샷 이름이 aws rds create-db-snapshot --region <region-name> --db-snapshot-identifier <DB-Snapshot-Name> --db-instance-identifier <DB-Name>인 new snapshot이 반환됩니다.
이제 list-aliases 명령어를 실행하여 지정된 리전에서 사용 가능한 KMS 키 별칭을 나열합니다. 명령어 결과에 각 key alias currently available이 반환됩니다. RDS 암호화 활성화 프로세스를 위해 AWS 기본 KMS 키의 ID를 찾습니다. aws kms list-aliases --region <region-name>
앞에서 반환된 RDS 인스턴스의 기본 KMS 키 ID를 사용하여 copy-db-snapshot 명령어를 실행하여 데이터베이스 인스턴스 스냅샷의 암호화된 사본을 만듭니다. 명령어 결과는 encrypted instance snapshot configuration를 반환합니다. aws rds copy-db-snapshot --region <region-name> --source-db-snapshot-identifier <DB-Snapshot-Name> --target-db-snapshot-identifier <DB-Snapshot-Name-Encrypted> --copy-tags --kms-key-id <KMS-ID-For-RDS>
restore-db-instance-from-db-snapshot 명령어를 실행하여 이전 단계에서 만든 암호화된 스냅샷을 새 데이터베이스 인스턴스로 복원합니다. 성공하면 명령어 결과에 암호화된 새 데이터베이스 인스턴스 구성이 반환됩니다. aws rds restore-db-instance-from-db-snapshot --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --db-snapshot-identifier <DB-Snapshot-Name-Encrypted>
describe-db-instances 명령어를 실행하여 선택한 AWS 리전에서 사용 가능한 모든 RDS 데이터베이스 이름을 나열합니다. 결과에 데이터베이스 인스턴스 식별자 이름이 반환됩니다. 방금 DB-Name-Encrypted라고 만든 암호화된 데이터베이스 이름을 선택합니다. aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'
앞에서 반환된 RDS 인스턴스 식별자를 사용하여 describe-db-instances 명령어를 다시 실행하여 선택한 데이터베이스 인스턴스가 암호화되었는지 확인합니다. 명령어 결과에 암호화 상태 True가 반환됩니다. aws rds describe-db-instances --region <region-name> --db-instance-identifier <DB-Name-Encrypted> --query 'DBInstances[*].StorageEncrypted'

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Encryption Enabled Efs File Systems`

API의 카테고리 이름: ENCRYPTION_ENABLED_EFS_FILE_SYSTEMS

EFS 데이터에 AWS KMS(Key Management Service)를 통해 저장 데이터 암호화가 적용되어야 합니다.

권장사항: EFS 파일 시스템에 암호화가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 Elastic File System (EFS) 대시보드로 이동합니다.
왼쪽 탐색 패널에서 File Systems를 선택합니다.
대시보드 상단 메뉴에서 Create File System 버튼을 클릭하여 파일 시스템 설정 프로세스를 시작합니다.
Configure file system access구성 페이지에서 다음 작업을 수행합니다.
VPC 드롭다운 목록에서 올바른 VPC를 선택합니다.
Create mount targets(마운트 대상 만들기) 섹션에서 선택한 VPC 내의 모든 가용성 영역(AZ)에 대한 체크박스를 선택합니다. 이것이 마운트 대상이 됩니다.
Next step을 클릭하여 계속 진행합니다.
Configure optional settings 페이지에서 다음을 수행합니다.
새 파일 시스템을 설명하는 tags를 만듭니다.
요구사항에 따라 performance mode를 선택합니다.
Enable encryption 체크박스를 선택하고 KMS 마스터 키 선택 드롭다운 목록에서 aws/elasticfilesystem을 선택하여 AWS KMS에서 제공하고 관리하는 기본 마스터 키를 사용하여 새 파일 시스템에 암호화를 사용 설정합니다.
Next step을 클릭하여 계속 진행합니다.
review and create 페이지에서 파일 시스템 구성 세부정보를 검토한 후 Create File System을 클릭하여 새 AWS EFS 파일 시스템을 만듭니다.
이전의 암호화되지 않은 EFS 파일 시스템에서 새로 생성된 암호화된 파일 시스템으로 데이터를 복사합니다.
새로 생성된 암호화된 파일 시스템으로의 데이터 마이그레이션이 완료되는 즉시 암호화되지 않은 파일 시스템을 삭제합니다.
탐색 메뉴에서 AWS 리전을 변경하고 다른 AWS 리전에 대해 전체 프로세스를 반복합니다.

From에서: 1. describe-file-systems 명령어를 실행하여 선택한(암호화되지 않은) 파일 시스템에 사용할 수 있는 구성 정보를 설명합니다(올바른 리소스를 식별하려면 감사 섹션 참조).

aws efs describe-file-systems --region <region> --file-system-id <file-system-id from audit section step 2 output>

명령어 결과는 요청된 구성 정보를 반환해야 합니다.
새 AWS EFS 파일 시스템을 프로비저닝하려면 create-file-system 명령어에 필요한 토큰을 만들기 위해 범용 고유 식별자(UUID)를 생성해야 합니다. 필요한 토큰을 만들려면 'https://www.uuidgenerator.net'에서 무작위로 생성된 UUID를 사용하면 됩니다.
이전 단계에서 만든 고유한 토큰을 사용하여 create-file-system 명령어를 실행합니다. aws efs create-file-system --region <region> --creation-token <Token (randomly generated UUID from step 3)> --performance-mode generalPurpose --encrypted
명령어 결과는 새 파일 시스템 구성 메타데이터를 반환해야 합니다.
이전 단계에서 반환된 새로 생성된 EFS 파일 시스템 ID와 마운트 대상을 나타내는 가용성 영역(AZ)의 ID를 사용하여 create-mount-target 명령어를 실행합니다.

aws efs create-mount-target --region <region> --file-system-id <file-system-id> --subnet-id <subnet-id>

명령어 결과는 새 마운트 대상 메타데이터를 반환해야 합니다.
이제 EC2 인스턴스에서 파일 시스템을 마운트할 수 있습니다.
이전의 암호화되지 않은 EFS 파일 시스템에서 새로 생성된 암호화된 파일 시스템으로 데이터를 복사합니다.
새로 생성된 암호화된 파일 시스템으로의 데이터 마이그레이션이 완료되는 즉시 암호화되지 않은 파일 시스템을 삭제합니다. aws efs delete-file-system --region <region> --file-system-id <unencrypted-file-system-id>
--region을 업데이트하여 AWS 리전을 변경하고 다른 AWS 리전에 대해 전체 프로세스를 반복합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam Password Policy`

API의 카테고리 이름: IAM_PASSWORD_POLICY

AWS는 IAM 사용자 비밀번호에 대한 복잡성 요구사항과 필수 순환 기간을 지정할 수 있도록 AWS 계정에 대한 커스텀 비밀번호 정책을 허용합니다. 커스텀 비밀번호 정책을 설정하지 않으면 IAM 사용자 비밀번호가 기본 AWS 비밀번호 정책을 충족해야 합니다. AWS 보안 권장사항에서는 다음과 같은 비밀번호 복잡성 요구사항을 권장합니다.

비밀번호에 대문자가 한 자 이상 포함되어야 합니다.
비밀번호에 소문자가 한 자 이상 포함되어야 합니다.
비밀번호에 기호가 하나 이상 포함되어야 합니다.
비밀번호에 숫자가 한 자 이상 포함되어야 합니다.
비밀번호는 14자 이상이어야 합니다.
재사용을 허용하려면 비밀번호가 24개 이상 필요합니다.
비밀번호가 만료되기 전 최소 90일 이전이어야 합니다.

이 제어는 지정된 비밀번호 정책 요구사항을 모두 확인합니다.

권장사항: IAM 사용자의 계정 비밀번호 정책이 지정된 요구사항을 준수하는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

resource "aws_iam_account_password_policy" "strict" {
  allow_users_to_change_password = true
  require_uppercase_characters   = true
  require_lowercase_characters   = true
  require_symbols                = true
  require_numbers                = true
  minimum_password_length        = 14
  password_reuse_prevention      = 24
  max_password_age               = 90
}

AWS 콘솔

커스텀 비밀번호 정책 만들려면 다음 안내를 따르세요.

AWS 관리 콘솔에 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
탐색창에서 Account settings(계정 설정)를 선택합니다.
비밀번호 정책 섹션에서 Change password policy(비밀번호 정책 변경)을 선택합니다.
비밀번호 정책에 적용할 옵션을 선택하고 Save changes(변경사항 저장)을 선택합니다.

커스텀 비밀번호 정책 변경하려면 다음 안내를 따르세요.

AWS 관리 콘솔에 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
탐색창에서 Account settings(계정 설정)를 선택합니다.
Password policy(비밀번호 정책) 섹션에서 Change(변경)를 선택합니다.
비밀번호 정책에 적용할 옵션을 선택하고 Save changes(변경사항 저장)을 선택합니다.

AWS CLI

aws iam update-account-password-policy \
--allow-users-to-change-password \
--require-uppercase-characters \
--require-lowercase-characters \
--require-symbols \
--require-numbers \
--minimum-password-length 14 \
--password-reuse-prevention 24 \
--max-password-age 90

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam Password Policy Prevents Password Reuse`

API의 카테고리 이름: IAM_PASSWORD_POLICY_PREVENTS_PASSWORD_REUSE

IAM 비밀번호 정책은 동일한 사용자가 지정된 비밀번호를 재사용하지 못하도록 할 수 있습니다. 비밀번호 정책에서 비밀번호 재사용을 방지하는 것이 좋습니다.

권장사항: IAM 비밀번호 정책이 비밀번호 재사용을 방지하는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS 콘솔에 로그인합니다(Identity Access Management 계정 설정을 볼 수 있는 적절한 권한 포함).
AWS 콘솔에서 IAM 서비스로 이동합니다.
왼쪽 창에서 Account Settings(계정 설정)를 클릭합니다.
'Prevent password reuse(비밀번호 재사용 방지)'를 선택합니다.
'Number of passwords to remember(기억할 비밀번호 수)'를 24로 설정합니다.

AWS CLI

 aws iam update-account-password-policy --password-reuse-prevention 24

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam Password Policy Requires Minimum Length 14 Greater`

API의 카테고리 이름: IAM_PASSWORD_POLICY_REQUIRES_MINIMUM_LENGTH_14_GREATER

비밀번호 정책은 부분적으로 비밀번호 복잡성 요구사항을 적용하는 데 사용됩니다. IAM 비밀번호 정책을 사용하여 비밀번호가 지정된 최소 길이 이상인지 확인할 수 있습니다. 비밀번호 정책에서 비밀번호 길이를 최소 14자 이상 요구하는 것이 좋습니다.

권장사항: IAM 비밀번호 정책이 14자(영문 기준) 이상을 요구하는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS 콘솔에 로그인합니다(Identity Access Management 계정 설정을 볼 수 있는 적절한 권한 포함).
AWS 콘솔에서 IAM 서비스로 이동합니다.
왼쪽 창에서 Account Settings(계정 설정)를 클릭합니다.
'Minimum password length(최소 비밀번호 길이)'를 14 이상으로 설정합니다.
'Apply password policy(비밀번호 정책 적용)'을 클릭합니다.

AWS CLI

 aws iam update-account-password-policy --minimum-password-length 14

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam Policies Allow Full Administrative Privileges Attached`

API의 카테고리 이름: IAM_POLICIES_ALLOW_FULL_ADMINISTRATIVE_PRIVILEGES_ATTACHED

IAM 정책은 사용자, 그룹 또는 역할에 권한이 부여되는 방법입니다. 최소 권한 즉, 태스크를 수행하는 데 필요한 권한만 부여하는 것이 좋으며 표준 보안 조언으로 간주됩니다. 사용자가 수행해야 하는 작업을 결정한 후 전체 관리 권한을 허용하는 대신 해당 태스크만 수행할 수 있게 하는 정책을 만듭니다.

권장사항: 전체 ':' 관리 권한을 허용하는 IAM 정책이 연결되지 않았는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

전체 관리 권한이 있는 정책을 분리하려면 다음을 수행하세요.

AWS Management Console에 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
탐색창에서 Policies(정책)를 클릭한 후 감사 단계에서 찾은 정책 이름을 검색합니다.
삭제해야 하는 정책을 선택합니다.
정책 작업 메뉴에서 첫 번째 Detach를 선택합니다.
이 정책이 연결된 모든 사용자, 그룹, 역할을 선택합니다.
Detach Policy를 클릭합니다.
정책 작업 메뉴에서 Detach를 선택합니다.

AWS CLI

감사 단계에서 찾은 전체 관리 권한이 있는 정책을 분리하려면 다음을 수행하세요.

지정된 관리 정책이 연결된 모든 IAM 사용자, 그룹, 역할을 나열합니다.

 aws iam list-entities-for-policy --policy-arn <policy_arn>

모든 IAM 사용자로부터 정책을 분리합니다.

 aws iam detach-user-policy --user-name <iam_user> --policy-arn <policy_arn>

모든 IAM 그룹에서 정책을 분리합니다.

 aws iam detach-group-policy --group-name <iam_group> --policy-arn <policy_arn>

모든 IAM 역할에서 정책을 분리합니다.

 aws iam detach-role-policy --role-name <iam_role> --policy-arn <policy_arn>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam Users Receive Permissions Groups`

API의 카테고리 이름: IAM_USERS_RECEIVE_PERMISSIONS_GROUPS

IAM 정책을 통해 IAM 사용자에게 서비스, 함수, 데이터에 대한 액세스 권한이 부여됩니다. 사용자 정책을 정의하는 방법에는 4가지가 있습니다. 1) 사용자 정책(인라인 또는 사용자, 정책이라고도 함)을 직접 수정합니다. 2) 정책을 사용자에게 직접 연결합니다. 3) 사용자를 연결된 정책이 있는 IAM 그룹에 추가합니다. 4) 사용자를 인라인 정책이 있는 IAM 그룹에 추가합니다.

세 번째 구현만 권장됩니다.

권장사항: IAM 사용자가 그룹을 통해서만 권한을 받는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam User Group Membership Check`

API의 카테고리 이름: IAM_USER_GROUP_MEMBERSHIP_CHECK

IAM 보안 권장사항을 준수하려면 IAM 사용자가 항상 IAM 그룹에 속해야 합니다.

사용자를 그룹에 추가하면 여러 사용자 유형 간에 정책을 공유할 수 있습니다.

권장사항: IAM 사용자가 IAM 그룹 하나 이상의 구성원인지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

resource "aws_iam_user" "example" {
  name = "test-iam-user"
  path = "/users/dev/"
}

resource "aws_iam_group" "example" {
  name = "Developers"
  path = "/users/dev/"
}

resource "aws_iam_user_group_membership" "example" {
  user   = aws_iam_user.example.name
  groups = [aws_iam_group.example.name]
}

AWS 콘솔

AWS Management Console을 사용하여 IAM 사용자를 삭제하면 IAM에서 다음 정보를 자동으로 삭제합니다.

사용자
모든 사용자 그룹 멤버십(즉, 사용자가 속한 모든 IAM 사용자 그룹에서 사용자가 삭제됨)
사용자와 연결된 모든 비밀번호
사용자에게 속한 모든 액세스 키
사용자에게 적용된 모든 인라인 정책(사용자 그룹 권한을 통해 사용자에게 적용되는 정책은 영향을 받지 않음)

IAM 사용자를 삭제하려면 다음 안내를 따르세요.

AWS 관리 콘솔에 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
탐색창에서 Users(사용자)를 선택한 다음 삭제하려는 사용자 이름 옆의 체크박스를 선택합니다.
페이지 상단에서 Delete(삭제)를 선택합니다.
확인 대화상자에서 텍스트 입력 필드에 사용자 이름을 입력하여 사용자 삭제를 확인합니다.
Delete(삭제)를 선택합니다.

IAM 사용자 그룹에 사용자를 추가하려면 다음 안내를 따르세요.

AWS 관리 콘솔에 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
탐색창에서 User groups(사용자 그룹)을 선택한 다음 그룹 이름을 선택합니다.
Users(사용자) 탭을 선택한 다음 Add users(사용자 추가)를 선택합니다. 추가하려는 사용자 옆의 체크박스를 선택합니다.
Add users(사용자 추가)를 선택합니다.

AWS CLI

Amazon Web Services Management Console과 달리 프로그래매틱 방식으로 사용자를 삭제하는 경우 사용자에게 연결된 항목을 수동으로 삭제해야 합니다. 그렇지 않으면 삭제가 실패합니다.

사용자를 삭제하기 전에 다음 항목을 삭제하세요.

비밀번호(DeleteLoginProfile)
액세스 키(DeleteAccessKey)
서명 인증서(DeleteSigningCertificate)
SSH 공개 키( DeleteSSHPublicKey)
Git 사용자 인증 정보(DeleteServiceSpecificCredential)
다중 인증(MFA) 기기(DeactivateMFADevice , DeleteVirtualMFADevice )
인라인 정책(DeleteUserPolicy)
연결된 관리 정책(DetachUserPolicy)
그룹 멤버십(RemoveUserFromGroup )

사용자를 삭제하려면 사용자에게 연결된 모든 항목을 삭제한 후 다음 안내를 따르세요.

aws iam delete-user \
  --user-name "test-user"

IAM 그룹에 IAM 사용자를 추가하려면 다음 안내를 따르세요.

aws iam add-user-to-group \
  --group-name "test-group"
  --user-name "test-user"

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam User Mfa Enabled`

API의 카테고리 이름: IAM_USER_MFA_ENABLED

다중 인증(MFA)은 사용자 이름과 비밀번호 외에 보안을 강화하는 권장사항입니다. MFA를 사용하면 사용자가 AWS Management Console에 로그인할 때 등록된 가상 기기나 실제 기기에서 제공하는 시간에 민감한 인증 코드를 제공해야 합니다.

권장사항: AWS IAM 사용자가 다중 인증(MFA)을 사용 설정했는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

Terraform의 경우 MFA 기기의 부재를 해결할 수 있는 몇 가지 옵션이 있습니다. 사용자를 그룹과 제한적인 정책으로 정리하기 위한 적절한 구조가 이미 있을 것입니다.

다음 예시에서 그 방법을 보여줍니다.

사용자를 만듭니다.
PGP 공개 키로 사용자 로그인 프로필을 만듭니다.
IAM 프로필을 직접 관리할 수 있도록 허용하는 그룹 및 그룹 정책을 만듭니다.
그룹에 사용자를 연결합니다.
사용자를 위한 가상 MFA 기기를 만듭니다.
각 사용자에게 출력 QR 코드 및 비밀번호를 제공합니다.

variable "users" {
  type = set(string)
  default = [
    "test@example.com",
    "test2@example.com"
  ]
}

resource "aws_iam_user" "test_users" {
  for_each = toset(var.users)
  name     = each.key
}

resource "aws_iam_user_login_profile" "test_users_profile" {
  for_each                = var.users
  user                    = each.key
  # Key pair created using GnuPG, this is the public key
  pgp_key = file("path/to/gpg_pub_key_base64.pem")
  password_reset_required = true
  lifecycle {
    ignore_changes = [
      password_length,
      password_reset_required,
      pgp_key,
    ]
  }
}

resource "aws_iam_virtual_mfa_device" "test_mfa" {
  for_each                = toset(var.users)
  virtual_mfa_device_name = each.key
}

resource "aws_iam_group" "enforce_mfa_group" {
  name = "EnforceMFAGroup"
}

resource "aws_iam_group_membership" "enforce_mfa_group_membership" {
  name  = "EnforceMFAGroupMembership"
  group = aws_iam_group.enforce_mfa_group.name
  users = [for k in aws_iam_user.test_users : k.name]
}

resource "aws_iam_group_policy" "enforce_mfa_policy" {
  name   = "EnforceMFAGroupPolicy"
  group  = aws_iam_group.enforce_mfa_group.id
  policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
        "Sid": "AllowViewAccountInfo",
        "Effect": "Allow",
        "Action": [
            "iam:GetAccountPasswordPolicy",
            "iam:ListVirtualMFADevices"
        ],
        "Resource": "*"
    },
    {
        "Sid": "AllowManageOwnPasswords",
        "Effect": "Allow",
        "Action": [
            "iam:ChangePassword",
            "iam:GetUser"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnAccessKeys",
        "Effect": "Allow",
        "Action": [
            "iam:CreateAccessKey",
            "iam:DeleteAccessKey",
            "iam:ListAccessKeys",
            "iam:UpdateAccessKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSigningCertificates",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSigningCertificate",
            "iam:ListSigningCertificates",
            "iam:UpdateSigningCertificate",
            "iam:UploadSigningCertificate"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnSSHPublicKeys",
        "Effect": "Allow",
        "Action": [
            "iam:DeleteSSHPublicKey",
            "iam:GetSSHPublicKey",
            "iam:ListSSHPublicKeys",
            "iam:UpdateSSHPublicKey",
            "iam:UploadSSHPublicKey"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnGitCredentials",
        "Effect": "Allow",
        "Action": [
            "iam:CreateServiceSpecificCredential",
            "iam:DeleteServiceSpecificCredential",
            "iam:ListServiceSpecificCredentials",
            "iam:ResetServiceSpecificCredential",
            "iam:UpdateServiceSpecificCredential"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnVirtualMFADevice",
        "Effect": "Allow",
        "Action": [
            "iam:CreateVirtualMFADevice",
            "iam:DeleteVirtualMFADevice"
        ],
        "Resource": "arn:aws:iam::*:mfa/$${aws:username}"
    },
    {
        "Sid": "AllowManageOwnUserMFA",
        "Effect": "Allow",
        "Action": [
            "iam:DeactivateMFADevice",
            "iam:EnableMFADevice",
            "iam:ListMFADevices",
            "iam:ResyncMFADevice"
        ],
        "Resource": "arn:aws:iam::*:user/$${aws:username}"
    },
    {
        "Sid": "DenyAllExceptListedIfNoMFA",
        "Effect": "Deny",
        "NotAction": [
            "iam:CreateVirtualMFADevice",
            "iam:EnableMFADevice",
            "iam:GetUser",
            "iam:ListMFADevices",
            "iam:ListVirtualMFADevices",
            "iam:ResyncMFADevice",
            "sts:GetSessionToken"
        ],
        "Resource": "*",
        "Condition": {
            "BoolIfExists": {
                "aws:MultiFactorAuthPresent": "false"
            }
        }
    }
  ]
}
POLICY
}

output "user_password_map" {
  # Outputs a map in the format {"test@example.com": <PGPEncryptedPassword>, "test2@example.com": <PGPEncryptedPassword>}
  value = { for k, v in aws_iam_user_login_profile.test_users_profile : k => v.password }
}

output "user_qr_map" {
  # Outputs a map in the format {"test@example.com": <QRCode>, "test2@example.com": <QRCode>}
  value = { for k, v in aws_iam_virtual_mfa_device.test_mfa : k => v.qr_code_png }
}

AWS 콘솔

AWS 콘솔 액세스 권한이 있는 사용자 계정에 MFA를 사용 설정하려면 AWS 문서의 가상 다중 인증(MFA) 기기(콘솔) 사용 설정을 참조하세요.

AWS CLI

MFA 기기 만들기

aws iam create-virtual-mfa-device \
  --virtual-mfa-device-name "test@example.com" \
  --outfile ./QRCode.png \
  --bootstrap-method QRCodePNG

기존 사용자에 MFA 기기 사용 설정

aws iam enable-mfa-device \
  --user-name "test@example.com" \
  --serial-number "arn:aws:iam::123456976749:mfa/test@example.com" \
  --authentication-code1 123456 \
  --authentication-code2 654321

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Iam User Unused Credentials Check`

API의 카테고리 이름: IAM_USER_UNUSED_CREDENTIALS_CHECK

지난 90일 동안 사용되지 않은 IAM 비밀번호나 활성 액세스 키가 있는지 확인합니다.

90일 이상 사용하지 않은 모든 사용자 인증 정보를 삭제, 비활성화 또는 순환하는 것이 좋습니다. 이렇게 하면 도용되거나 폐기된 계정과 연결된 사용자 인증 정보를 사용할 수 있는 기간이 줄어듭니다.

권장사항: 모든 AWS IAM 사용자에게 maxCredentialUsageAge 일수(기본 90일) 동안 사용되지 않은 비밀번호나 활성 액세스 키가 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

Terraform을 통해 생성된 만료된 액세스 키를 삭제하려면 모듈에서 aws_iam_access_key 리소스를 삭제하고 변경사항을 적용합니다.

IAM 사용자 로그인 비밀번호를 재설정하려면 terraform apply를 실행할 때 -replace을 사용합니다.

다음과 같은 사용자 로그인 프로필을 가정합니다.

resource "aws_iam_user" "example" {
  name          = "test@example.com"
  path          = "/users/"
  force_destroy = true
}

resource "aws_iam_user_login_profile" "example" {
  user    = aws_iam_user.example.name
  pgp_key = "keybase:some_person_that_exists"
}

다음 명령어를 실행하여 사용자의 로그인 프로필 비밀번호를 재설정합니다.

terraform apply -replace="aws_iam_user_login_profile.example"

AWS 콘솔

비활성 계정의 사용자 인증 정보를 사용 중지하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
Users(사용자)를 선택합니다.
90일 이상 경과되거나 마지막으로 사용된 사용자 인증 정보가 있는 사용자의 이름을 선택합니다.
Security credentials(보안 사용자 인증 정보)를 선택합니다.
90일 이상 사용되지 않은 각 로그인 사용자 인증 정보와 액세스 키에 대해 Make inactive(비활성화)를 선택합니다.

다음에 로그인할 때 콘솔 사용자에게 새 비밀번호를 요구하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
Users(사용자)를 선택합니다.
90일 이상 경과되거나 마지막으로 사용된 사용자 인증 정보가 있는 사용자의 이름을 선택합니다.
Security credentials(보안 사용자 인증 정보)를 선택합니다.
로그인 사용자 인증 정보 및 콘솔 비밀번호에서 Manage(관리)를 선택합니다.
새 비밀번호(자동 생성 또는 커스텀)를 설정합니다.
Require password reset(비밀번호 재설정 필요) 체크박스를 선택합니다.
Apply(적용)를 선택합니다.

AWS CLI

액세스 키를 비활성화

aws iam update-access-key \
  --access-key-id <value> \
  --status "Inactive"

액세스 키 삭제

aws iam delete-access-key \
  --access-key-id <value>

사용자 로그인 프로필 비밀번호 재설정

aws iam update-login-profile \
  --user-name "test@example.com" \
  --password <temporary_password> \
  --password-reset-required

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Kms Cmk Not Scheduled For Deletion`

API의 카테고리 이름: KMS_CMK_NOT_SCHEDULED_FOR_DELETION

이 제어는 KMS 키 삭제가 예약되었는지 여부를 확인합니다. KMS 키 삭제가 예약되면 제어가 실패합니다.

KMS 키는 삭제되면 복구될 수 없습니다. 또한 KMS 키가 삭제되면 KMS 키로 암호화된 데이터는 영구적으로 복구 불가합니다. 삭제가 예약된 KMS 키로 의미 있는 데이터가 암호화된 경우 의도적으로 암호화 삭제를 수행하지 않는 한 데이터를 복호화하거나 새 KMS 키로 데이터를 다시 암호화하는 것이 좋습니다.

KMS 키 삭제가 예약되면 잘못 예약된 경우에 삭제를 취소할 수 있도록 필수 대기 기간이 적용됩니다. 기본 대기 기간은 30일이지만 KMS 키 삭제를 예약할 때 최대 7일까지 줄일 수 있습니다. 대기 기간 중에는 예약된 삭제를 취소할 수 있지만 KMS 키는 삭제되지 않습니다.

KMS 키 삭제에 대한 자세한 내용은 AWS Key Management Service 개발자 가이드의 KMS 키 삭제를 참조하세요.

권장사항: 모든 CMK에 삭제가 예약되지 않았는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Lambda Concurrency Check`

API의 카테고리 이름: LAMBDA_CONCURRENCY_CHECK

람다 함수가 함수 수준 동시 실행 제한으로 구성되었는지 확인합니다. Lambda 함수가 함수 수준 동시 실행 제한으로 구성되지 않으면 규칙은 NON_COMPLIANT입니다.

권장사항: 람다 함수가 함수 수준 동시 실행 한도로 구성되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Lambda Dlq Check`

API의 카테고리 이름: LAMBDA_DLQ_CHECK

람다 함수가 데드 레터 큐로 구성되었는지 확인합니다. 람다 함수가 데드 레터 큐로 구성되지 않으면 규칙은 NON_COMPLIANT입니다.

권장사항: 람다 함수가 데드 레터 큐로 구성되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Lambda Function Public Access Prohibited`

API의 카테고리 이름: LAMBDA_FUNCTION_PUBLIC_ACCESS_PROHIBITED

AWS 권장사항에서는 Lambda 함수를 공개적으로 노출하면 안 된다고 권장합니다. 이 정책은 계정 내에서 사용 설정된 모든 리전에 배포된 모든 Lambda 함수를 확인하고 공개 액세스를 허용하도록 구성되어 있으면 실패합니다.

권장사항: 람다 함수에 연결된 정책이 공개 액세스를 금지하는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

다음 예시는 Terraform을 사용하여 Lambda 함수에 대한 액세스를 제한하고 해당 역할을 Lambda 함수에 연결하는 IAM 역할을 프로비저닝하는 예시를 제공합니다.

resource "aws_iam_role" "iam_for_lambda" {
  name = "iam_for_lambda"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

resource "aws_lambda_function" "test_lambda" {
  filename      = "lambda_function_payload.zip"
  function_name = "lambda_function_name"
  role          = aws_iam_role.iam_for_lambda.arn
  handler       = "index.test"

  source_code_hash = filebase64sha256("lambda_function_payload.zip")

  runtime = "nodejs12.x"

}

AWS 콘솔

람다 함수가 이 제어에 실패하면 Lambda 함수의 리소스 기반 정책 문이 공개 액세스를 허용함을 나타냅니다.

이 문제를 해결하려면 정책을 업데이트하여 권한을 삭제하거나 AWS:SourceAccount 조건을 추가해야 합니다. Lambda API에서는 리소스 기반 정책만 업데이트할 수 있습니다.

다음 안내에서는 콘솔을 사용하여 정책을 검토하고 AWS 명령줄 인터페이스를 사용하여 권한을 삭제합니다.

람다 함수의 리소스 기반 정책을 보려면 다음 안내를 따르세요.

https://console.aws.amazon.com/lambda/에서 AWS Lambda 콘솔을 엽니다.
탐색창에서 Functions(함수)를 선택합니다.
함수를 선택합니다.
Permissions(권한)를 선택합니다. 리소스 기반 정책은 다른 계정 또는 AWS 서비스가 함수에 액세스하려고 시도할 때 적용되는 권한을 보여줍니다.
리소스 기반 정책을 검사합니다.
정책을 공개로 설정하는 주 구성원 필드 값이 있는 정책 문을 식별합니다. 예를 들어 "*" 또는 { "AWS": "*" }를 허용합니다.

콘솔에서는 정책을 수정할 수 없습니다. 함수에서 권한을 삭제하려면 AWS CLI에서 remove-permission 명령어를 사용합니다.

삭제하려는 문의 문 ID(Sid) 값을 기록해 둡니다.

AWS CLI

CLI를 사용하여 람다 함수에서 권한을 삭제하려면 다음과 같이 remove-permission 명령어를 실행합니다.

aws lambda remove-permission \
--function-name <value> \
--statement-id <value>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Lambda Inside Vpc`

API의 카테고리 이름: LAMBDA_INSIDE_VPC

람다 함수가 VPC에 있는지 여부를 확인합니다. Lambda@Edge 리소스의 실패한 발견 항목이 표시될 수 있습니다.

공개 연결 가능성을 결정하기 위해 VPC 서브넷 라우팅 구성을 평가하지 않습니다.

권장사항: 람다 함수가 VPC 내에 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

계정에서 가상 프라이빗 클라우드(VPC)의 비공개 서브넷에 연결하도록 함수를 구성하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/lambda/에서 AWS Lambda 콘솔을 엽니다.
Functions(함수)로 이동한 다음 람다 함수를 선택합니다.
네트워크로 스크롤한 후 함수의 연결 요구사항에 따라 VPC를 선택합니다.
고가용성 모드에서 함수를 실행하려면 Security Hub에서 서브넷을 2개 이상 선택하는 것이 좋습니다.
함수의 연결 요구사항이 있는 보안 그룹을 하나 이상 선택합니다.
Save(저장)를 선택합니다.

자세한 내용은 AWS Lambda 개발자 가이드에서 VPC의 리소스에 액세스하도록 람다 함수 구성 섹션을 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Mfa Delete Enabled S3 Buckets`

API의 카테고리 이름: MFA_DELETE_ENABLED_S3_BUCKETS

민감하고 분류된 S3 버킷에 MFA 삭제가 사용 설정되면 사용자에게 두 가지 형태의 인증이 필요합니다.

권장사항: S3 버킷에 MFA 삭제가 사용 설정되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Mfa Enabled Root User Account`

API의 카테고리 이름: MFA_ENABLED_ROOT_USER_ACCOUNT

'루트' 사용자 계정은 AWS 계정에서 가장 많은 권한이 있는 사용자입니다. 다중 인증(MFA)은 사용자 이름과 비밀번호 외에 보안을 강화합니다. MFA를 사용 설정한 경우 사용자가 AWS 웹사이트에 로그인하면 사용자 이름과 비밀번호뿐만 아니라 AWS MFA 기기의 인증 코드를 입력하라는 메시지가 표시됩니다.

참고: '루트' 계정에 가상 MFA를 사용하는 경우 사용되는 기기는 개인 기기가 아닌 개별 개인 기기와 별도로 충전되고 보호되도록 관리되는 전용 모바일 기기(태블릿 또는 휴대전화)인 것이 좋습니다. ('비개인 가상 MFA') 이렇게 하면 기기 손실, 기기 보상 판매로 인해 또는 기기를 소유한 개인이 더 이상 회사에서 근무하지 않는 경우 MFA에 대한 액세스 권한을 상실할 위험이 줄어듭니다.

권장사항: '루트' 사용자 계정에 MFA가 사용 설정되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Multi Factor Authentication Mfa Enabled All Iam Users Console`

API의 카테고리 이름: MULTI_FACTOR_AUTHENTICATION_MFA_ENABLED_ALL_IAM_USERS_CONSOLE

다중 인증(MFA)은 기존 사용자 인증 정보 외에 인증 보증을 강화합니다. MFA를 사용 설정한 경우 사용자가 AWS Console에 로그인하면 사용자 이름과 비밀번호뿐만 아니라 물리적 또는 가상 MFA 토큰의 인증 코드를 입력하라는 메시지가 표시됩니다. 콘솔 비밀번호가 있는 모든 계정에 MFA를 사용 설정하는 것이 좋습니다.

권장사항: 콘솔 비밀번호를 보유한 모든 IAM 사용자에게 다중 인증(MFA)이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 'https://console.aws.amazon.com/iam/'에서 IAM 콘솔을 엽니다.
왼쪽 창에서 Users를 선택합니다.
User Name 목록에서 원하는 MFA 사용자의 이름을 선택합니다.
Security Credentials 탭을 선택한 다음 Manage MFA Device를 선택합니다.
Manage MFA Device wizard에서 Virtual MFA 기기를 선택한 후 Continue를 선택합니다.

IAM은 QR 코드 그래픽을 포함하여 가상 MFA 기기의 구성 정보를 생성하고 표시합니다. 그래픽은 QR 코드를 지원하지 않는 기기에서 직접 입력할 수 있는 '보안 비밀 구성 키'를 나타냅니다.
가상 MFA 애플리케이션을 엽니다. (가상 MFA 기기를 호스팅하는 데 사용할 수 있는 앱 목록은 https://aws.amazon.com/iam/details/mfa/#Virtual_MFA_Applications에서 가상 MFA 애플리케이션을 참조하세요.) 가상 MFA 애플리케이션에서 여러 계정(여러 가상 MFA 기기)을 지원하는 경우 새 계정(새 가상 MFA 기기)을 만드는 옵션을 선택합니다.
MFA 앱이 QR 코드를 지원하는지 확인한 후 다음 중 하나를 수행합니다.
- 앱으로 QR 코드를 스캔합니다. 예를 들어 카메라 아이콘을 선택하거나 코드 스캔과 유사한 옵션을 선택한 다음 기기의 카메라를 사용하여 코드를 스캔할 수 있습니다.
- MFA 기기 관리 마법사에서 Show secret key for manual configuration(수동 구성을 위한 보안 키 표시)를 선택한 다음 MFA 애플리케이션에 보안 비밀 구성 키를 입력합니다.
완료되면 가상 MFA 기기에서 일회용 비밀번호 생성을 시작합니다.
Manage MFA Device wizard의 MFA Code 1 box에서 현재 가상 MFA 기기에 표시된 one-time password를 입력합니다. 기기에서 새로운 일회용 비밀번호를 생성할 때까지 최대 30초 동안 기다립니다. 그런 다음 MFA Code 2 box에 두 번째 one-time password를 입력합니다.
Assign MFA를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`No Network Acls Allow Ingress 0 0 0 0 Remote Server Administration`

API의 카테고리 이름: NO_NETWORK_ACLS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

네트워크 액세스 제어 목록(NACL) 함수에서 AWS 리소스에 대한 인그레스 및 이그레스 네트워크 트래픽의 스테이트리스(Stateless) 필터링을 제공합니다. NACL에서는 TDP(6), UDP(17) 또는 ALL(-1) 프로토콜을 사용한 원격 서버 관리 포트에 대한 무제한 인그레스 액세스(예: SSH를 포트 22로, RDP에서 포트 3389로 연결)를 허용하지 않는 것이 좋습니다.

권장사항: 0.0.0.0/0에서 원격 서버 관리 포트로 인그레스를 허용하는 네트워크 ACL이 없는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

다음을 수행하세요.

https://console.aws.amazon.com/vpc/home에서 AWS Management Console에 로그인합니다.
왼쪽 창에서 Network ACLs을 클릭합니다.
해결할 각 네트워크 ACL에 대해 다음을 수행합니다.
- 네트워크 ACL 선택
- Inbound Rules 탭 클릭
- Edit inbound rules를 클릭합니다.
- A) 소스 필드를 0.0.0.0/0 이외의 범위로 업데이트하거나, B) Delete를 클릭하여 문제가 되는 인바운드 규칙 삭제
- Save를 클릭합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`No Root User Account Access Key Exists`

API의 카테고리 이름: NO_ROOT_USER_ACCOUNT_ACCESS_KEY_EXISTS

'루트' 사용자 계정은 AWS 계정에서 가장 많은 권한이 있는 사용자입니다. AWS 액세스 키는 지정된 AWS 계정에 대한 프로그래매틱 액세스 권한을 제공합니다. '루트' 사용자 계정과 연결된 모든 액세스 키를 삭제하는 것이 좋습니다.

권장사항: '루트' 사용자 계정 액세스 키가 없는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 '루트'로 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 콘솔을 엽니다.
오른쪽 상단의 <root_account>를 클릭하고 드롭다운 목록에서 My Security Credentials를 선택합니다.
팝업 화면에서 Continue to Security Credentials를 클릭합니다.
Access Keys(액세스 키 ID 및 보안 비밀 액세스 키)를 클릭합니다.
Status 열 아래에서(활성 키가 있는 경우)
Delete를 클릭합니다(참고: 삭제된 키는 복구할 수 없음).

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`No Security Groups Allow Ingress 0 0 0 0 Remote Server Administration`

API의 카테고리 이름: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_0_0_0_REMOTE_SERVER_ADMINISTRATION

보안 그룹은 AWS 리소스에 대한 인그레스 및 이그레스 네트워크 트래픽의 스테이트풀(Stateful) 필터링을 제공합니다. 보안 그룹에서는 TDP(6), UDP(17) 또는 ALL(-1) 프로토콜을 사용한 원격 서버 관리 포트에 대한 무제한 인그레스 액세스(예: SSH를 포트 22로, RDP에서 포트 3389로 연결)를 허용하지 않는 것이 좋습니다.

권장사항: 0.0.0.0/0에서 원격 서버 관리 포트로 인그레스를 허용하는 보안 그룹이 없는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`No Security Groups Allow Ingress 0 Remote Server Administration`

API의 카테고리 이름: NO_SECURITY_GROUPS_ALLOW_INGRESS_0_REMOTE_SERVER_ADMINISTRATION

보안 그룹은 AWS 리소스에 대한 인그레스 및 이그레스 네트워크 트래픽의 스테이트풀(Stateful) 필터링을 제공합니다. 보안 그룹에서는 원격 서버 관리 포트에 대한 무제한 인그레스 액세스(예: SSH를 포트 22로, RDP에서 포트 3389로 연결)를 허용하지 않는 것이 좋습니다.

권장사항: ::/0에서 원격 서버 관리 포트로 인그레스를 허용하는 보안 그룹이 없는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`One Active Access Key Available Any Single Iam User`

API의 카테고리 이름: ONE_ACTIVE_ACCESS_KEY_AVAILABLE_ANY_SINGLE_IAM_USER

액세스 키는 IAM 사용자 또는 AWS 계정 '루트' 사용자의 장기 사용자 인증 정보입니다. 액세스 키를 사용하여 AWS CLI 또는 AWS API에 대한 프로그래매틱 요청에 직접 또는 AWS SDK를 사용하여 서명할 수 있습니다.

권장사항: 단일 IAM 사용자가 사용할 수 있는 활성 액세스 키가 1개만 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/iam/에서 IAM 대시보드로 이동합니다.
왼쪽 탐색 패널에서 Users를 선택합니다.
검사할 IAM 사용자 이름을 클릭합니다.
IAM 사용자 구성 페이지에서 Security Credentials 탭을 선택합니다.
Access Keys 섹션에서 90일이 미만의 액세스 키 하나를 선택합니다. 이 IAM 사용자가 AWS 리소스에 프로그래매틱 방식으로 액세스하는 데 사용하는 유일한 활성 키여야 합니다. 애플리케이션을 테스트하여 선택한 액세스 키가 작동하는지 확인합니다.
동일한 Access Keys 섹션에서 사용되지 않는 액세스 키(선택한 키 제외)를 식별하고 Make Inactive 링크를 클릭하여 비활성화합니다.
Change Key Status 확인 상자가 표시되면 Deactivate를 클릭하여 선택한 키를 사용 중지합니다.
AWS 계정의 각 IAM 사용자에 대해 3~7단계를 반복합니다.

AWS CLI

Audit CLI에 제공된 IAM 사용자 및 액세스 키 정보를 사용하여 90일 미만의 액세스 키 하나를 선택합니다. 이 IAM 사용자가 AWS 리소스에 프로그래매틱 방식으로 액세스하는 데 사용하는 유일한 활성 키여야 합니다. 애플리케이션을 테스트하여 선택한 액세스 키가 작동하는지 확인합니다.
IAM 사용자 이름 및 사용되지 않는 액세스 키 ID를 사용해 아래 update-access-key 명령어를 실행하여 불필요한 키를 비활성화합니다. 감사 섹션을 참조하여 선택한 IAM 사용자에게 불필요한 액세스 키 ID를 확인합니다.

참고 - 이 명령어는 결과를 반환하지 않습니다.

aws iam update-access-key --access-key-id <access-key-id> --status Inactive --user-name <user-name>

선택한 액세스 키 쌍이 성공적으로 deactivated 상태가 되었는지 확인하려면 해당 IAM 사용자에 대해 list-access-keys 감사 명령어를 다시 실행합니다.

aws iam list-access-keys --user-name <user-name>

명령어 결과는 IAM 사용자와 연결된 각 액세스 키의 메타데이터를 노출해야 합니다. 사용되지 않은 키 쌍 Status가 Inactive로 설정된 경우 키가 성공적으로 비활성화되었으며 이제 IAM 사용자 액세스 구성이 이 권장사항을 준수합니다.

AWS 계정의 각 IAM 사용자에 대해 1~3단계를 반복합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Public Access Given Rds Instance`

API의 카테고리 이름: PUBLIC_ACCESS_GIVEN_RDS_INSTANCE

보안 위험을 최소화하기 위해 AWS 계정에 프로비저닝된 RDS 데이터베이스 인스턴스가 무단 액세스를 제한하는지 확인합니다. 공개적으로 액세스할 수 있는 RDS 데이터베이스 인스턴스에 대한 액세스를 제한하려면 데이터베이스 공개 액세스 가능 플래그를 중지하고 인스턴스와 연결된 VPC 보안 그룹을 업데이트해야 합니다.

권장사항: RDS 인스턴스에 공개 액세스 권한이 부여되지 않았는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/rds/의 RDS 대시보드로 이동합니다.
탐색 패널의 RDS 대시보드에서 Databases를 클릭합니다.
업데이트할 RDS 인스턴스를 선택합니다.
대시보드 상단 메뉴에서 Modify를 클릭합니다.
DB 인스턴스 수정 패널의 Connectivity 섹션에서 Additional connectivity configuration을 클릭하고 Publicly Accessible의 값을 공개적으로 액세스할 수 없음으로 업데이트하여 공개 액세스를 제한합니다. 서브넷 구성을 업데이트하려면 다음 안내를 따르세요.
Connectivity and security 탭을 선택하고 Networking 섹션 내에서 VPC 속성 값을 클릭합니다.
VPC 대시보드 하단 패널에서 Details 탭을 선택하고 경로 테이블 구성 속성 값을 클릭합니다.
경로 테이블 세부정보 페이지의 대시보드 하단 패널에서 경로 탭을 선택하고 Edit routes를 클릭합니다.
경로 수정 페이지에서 igw-xxxxx로 설정된 대상의 대상 위치를 업데이트하고 Save 경로를 클릭합니다.
DB 인스턴스 수정 패널에서 Continue를 클릭하고 수정 예약 섹션에서 요구사항에 따라 다음 작업 중 하나를 수행합니다.
예약된 다음 유지보수 기간 중에 변경사항을 자동으로 적용하려면 Apply during the next scheduled maintenance window(다음 예약된 유지보수 기간 중에 적용)를 선택합니다.
변경사항을 즉시 적용하려면 Apply immediately(즉시 적용)를 선택합니다. 이 옵션을 사용하면 RDS 데이터베이스 인스턴스의 유지보수 기간 설정에 관계없이 대기 중인 모든 수정사항이 가능한 한 빨리 비동기적으로 적용됩니다. 대기 중인 수정사항 큐에서 사용할 수 있는 모든 변경사항도 적용됩니다. 대기 중인 수정사항에 다운타임이 필요한 경우 이 옵션을 선택하면 애플리케이션에 예상치 못한 다운타임이 발생할 수 있습니다.
현재 리전에서 사용 가능한 각 RDS 인스턴스에 대해 3~6단계를 반복합니다.
탐색 메뉴에서 AWS 리전을 변경하고 다른 리전에 대해 프로세스를 반복합니다.

AWS CLI

describe-db-instances 명령어를 실행하여 선택한 AWS 리전에서 사용 가능한 모든 RDS 데이터베이스 이름 식별자를 나열합니다.

aws rds describe-db-instances --region <region-name> --query 'DBInstances[*].DBInstanceIdentifier'

명령어 결과는 각 데이터베이스 인스턴스 식별자를 반환해야 합니다.
modify-db-instance 명령어를 실행하여 선택한 RDS 인스턴스 구성을 수정합니다. 그런 후 다음 명령어를 사용하여 선택한 RDS 인스턴스의 Publicly Accessible 플래그를 사용 중지합니다. 이 명령어는 apply-immediately 플래그를 사용합니다. to avoid any downtime --no-apply-immediately flag can be used를 원하는 경우:

aws rds modify-db-instance --region <region-name> --db-instance-identifier <db-name> --no-publicly-accessible --apply-immediately

명령어 결과에는 보류 중인 값 아래에 PubliclyAccessible 구성이 표시되고 지정된 시간에 적용되어야 합니다.
AWS CLI를 통한 인터넷 게이트웨이 대상 업데이트는 현재 지원되지 않습니다. 인터넷 게이트웨이에 대한 정보를 업데이트하려면 AWS 콘솔 절차를 사용하세요.
현재 리전에 프로비저닝된 각 RDS 인스턴스에 대해 1~5단계를 반복합니다.
--region 필터를 사용하여 AWS 리전을 변경하고 다른 리전에 대해 프로세스를 반복합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Rds Enhanced Monitoring Enabled`

API의 카테고리 이름: RDS_ENHANCED_MONITORING_ENABLED

고급 모니터링은 인스턴스에 설치된 에이전트를 통해 RDS 인스턴스가 실행되는 운영체제에 대한 실시간 측정항목을 제공합니다.

자세한 내용은 고급 모니터링으로 OS 측정항목 모니터링을 참조하세요.

권장사항: 모든 RDS DB 인스턴스에 고급 모니터링이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

이 제어를 해결하려면 다음과 같이 RDS 인스턴스에 고급 모니터링을 사용 설정합니다.

RDS의 IAM 역할을 만듭니다.

resource "aws_iam_role" "rds_logging" {
  name = "CustomRoleForRDSMonitoring"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Sid    = "CustomRoleForRDSLogging"
        Principal = {
          Service = "monitoring.rds.amazonaws.com"
        }
      },
    ]
  })
}

RDS 고급 모니터링을 위한 AWS 관리 정책을 검색합니다.

data "aws_iam_policy" "rds_logging" {
  name = "AmazonRDSEnhancedMonitoringRole"
}

정책을 역할에 연결합니다.

resource "aws_iam_policy_attachment" "rds_logging" {
  name       = "AttachRdsLogging"
  roles      = [aws_iam_role.rds_logging.name]
  policy_arn = data.aws_iam_policy.rds_logging.arn
}

고급 모니터링을 사용 설정하려면 위반 RDS 인스턴스에 대한 모니터링 간격과 모니터링 역할을 정의합니다.

resource "aws_db_instance" "default" {
  identifier           = "test-rds"
  allocated_storage    = 10
  engine               = "mysql"
  engine_version       = "5.7"
  instance_class       = "db.t3.micro"
  db_name              = "mydb"
  username             = "foo"
  password             = "foobarbaz"
  parameter_group_name = "default.mysql5.7"
  skip_final_snapshot  = true
  monitoring_interval  = 60
  monitoring_role_arn  = aws_iam_role.rds_logging.arn
}

AWS 콘솔

DB 인스턴스, 다중 AZ DB 클러스터 또는 읽기 복제본을 만들거나 DB 인스턴스 또는 다중 AZ DB 클러스터를 수정할 때 고급 모니터링을 사용 설정할 수 있습니다. 고급 모니터링을 사용하기 위해 DB 인스턴스를 수정하는 경우 DB 인스턴스를 재부팅하지 않아도 변경 내용이 적용됩니다.

데이터베이스 페이지에서 다음 작업 중 하나를 수행할 때 RDS 콘솔에서 고급 모니터링을 사용 설정할 수 있습니다.

DB 인스턴스 또는 다중 AZ DB 클러스터 만들기 - Create database(데이터베이스 만들기)를 선택합니다.
읽기 복제본 만들기 - Actions(작업)를 선택한 다음 Create read replica(읽기 복제본 만들기)를 선택합니다.
DB 인스턴스 또는 다중 AZ DB 클러스터 수정 - Modify(수정)를 선택합니다.

RDS 콘솔에서 고급 모니터링을 사용 설정 또는 중지하려면 다음 안내를 따르세요.

추가 구성으로 스크롤합니다.
Monitoring(모니터링)에서 DB 인스턴스 또는 읽기 복제본에 Enable Enhanced Monitoring(고급 모니터링 사용 설정)을 선택합니다. 고급 모니터링을 사용 중지하려면 Disable Enhanced Monitoring(고급 모니터링 사용 중지)을 선택합니다.
모니터링 역할 속성을 생성된 IAM 역할로 설정하여 Amazon RDS가 Amazon CloudWatch Logs와 자동으로 통신할 수 있도록 하거나, RDS가 rds-monitoring-role이라는 역할을 만들도록 기본값을 선택합니다.
세부사항 속성을 DB 인스턴스 또는 읽기 복제본에 대한 측정항목이 수집되는 시점 간격(초)으로 설정합니다. 세부사항 속성 값은 1, 5, 10, 15, 30, 60 중 하나로 설정할 수 있습니다. RDS 콘솔의 가장 빠른 새로 고침 빈도는 5초 간격입니다. RDS 콘솔에서 이 빈도를 1초로 설정한 경우에도 업데이트된 측정항목은 5초마다 표시됩니다. CloudWatch Logs를 사용하여 1초 측정항목 업데이트를 검색할 수 있습니다.

AWS CLI

RDS IAM 역할을 만듭니다.

aws iam create-role \
  --role-name "CustomRoleForRDSMonitoring" \
  --assume-role-policy-document file://rds-assume-role.json

AmazonRDSEnhancedMonitoringRole 정책을 역할에 연결합니다.

aws iam attach-role-policy \
  --role-name "CustomRoleForRDSMonitoring"\
  --policy-arn "arn:aws:iam::aws:policy/service-role/AmazonRDSEnhancedMonitoringRole"

--monitoring-interval 및 --monitoring-role-arn을 설정하여 고급 모니터링을 사용 설정하도록 RDS 인스턴스를 수정합니다.

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --monitoring-interval 30 \
  --monitoring-role-arn "arn:aws:iam::<account_id>:role/CustomRoleForRDSMonitoring"

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Rds Instance Deletion Protection Enabled`

API의 카테고리 이름: RDS_INSTANCE_DELETION_PROTECTION_ENABLED

인스턴스 삭제 방지를 사용 설정하면 실수로 인한 데이터베이스 삭제나 승인되지 않은 항목에 의한 삭제로부터 보호됩니다.

삭제 방지가 사용 설정된 동안에는 RDS DB 인스턴스를 삭제할 수 없습니다. 삭제 요청이 성공하려면 먼저 삭제 방지를 중지해야 합니다.

권장사항: 모든 RDS 인스턴스에 삭제 방지가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

이 제어를 해결하려면 aws_db_instance 리소스에서 deletion_protection을 true로 설정합니다.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  deletion_protection = true
}

AWS 콘솔

RDS DB 인스턴스에 삭제 방지를 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.
탐색창에서 Databases(데이터베이스)를 선택한 후 수정할 DB 인스턴스를 선택합니다.
Modify(수정)를 선택합니다.
Deletion protection(삭제 방지) 아래에서 Enable deletion protection(삭제 방지 사용 설정)을 선택합니다.
Continue(계속)를 선택합니다.
Scheduling of modifications(수정 사항 예약)에서 수정을 적용할 시기를 선택합니다. Apply during the next scheduled maintenance window(다음 예약된 유지보수 기간 중에 적용) 또는 Apply immediately(즉시 적용) 중에서 선택할 수 있습니다.
Modify DB Instance(DB 인스턴스 수정)를 선택합니다.

AWS CLI

AWS CLI에도 동일하게 적용됩니다. 아래와 같이 --deletion-protection을 설정합니다.

aws rds modify-db-instance \
  --db-instance-identifier = "test-rds" \
  --deletion-protection

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Rds In Backup Plan`

API의 카테고리 이름: RDS_IN_BACKUP_PLAN

이 검사는 Amazon RDS DB 인스턴스에 백업 계획이 적용되는지 평가합니다. RDS DB 인스턴스에 백업 계획이 적용되지 않으면 이 제어가 실패합니다.

AWS Backup은 AWS 서비스의 데이터 백업을 중앙화 및 자동화하는 완전 관리형 백업 서비스입니다. AWS Backup을 사용하여 백업 계획이라는 백업 정책을 만들 수 있습니다. 이러한 플랜을 사용하여 데이터 백업 빈도 및 백업 보관 기간과 같은 백업 요구사항을 정의할 수 있습니다. 백업 계획에 RDS DB 인스턴스를 포함하면 의도치 않은 손실이나 삭제로부터 데이터를 보호할 수 있습니다.

권장사항: RDS DB 인스턴스에 백업 계획이 적용되어야 합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

이 제어를 해결하려면 backup_retention_period를 aws_db_instance 리소스에서 7보다 큰 값으로 설정합니다.

resource "aws_db_instance" "example" {
  # ... other Configuration ...
  backup_retention_period = 7
}

AWS 콘솔

자동 백업을 즉시 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.
탐색창에서 Databases(데이터베이스)를 선택한 후 수정할 DB 인스턴스를 선택합니다.
Modify(수정)를 선택하여 Modify DB Instance(DB 인스턴스 수정) 페이지를 엽니다.
Backup Retention Period(백업 보관 기간) 아래에서 0이 아닌 양수(예: 30일)를 선택하고 Continue(계속)를 선택합니다.
Scheduling of modifications(수정사항 예약)에서 수정을 적용할 시기를 선택합니다. Apply during the next scheduled maintenance window(다음 예약된 유지보수 기간 중에 적용) 또는 Apply immediately(즉시 적용) 중에서 선택할 수 있습니다.
그런 다음 확인 페이지에서 Modify DB Instance(DB 인스턴스 수정)를 선택하여 변경 내용을 저장하고 자동 백업을 사용 설정합니다.

AWS CLI

AWS CLI에도 동일하게 적용됩니다. 자동 백업을 사용 설정하려면 backup-retention-period를 0(기본값)보다 큰 값으로 변경합니다.

aws rds modify-db-instance --db-instance-identifier "test-rds" --backup-retention-period 7

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Rds Logging Enabled`

API의 카테고리 이름: RDS_LOGGING_ENABLED

Amazon RDS의 다음 로그가 사용 설정되어 CloudWatch로 전송되는지 여부를 확인합니다.

RDS 데이터베이스에서 관련 로그가 사용 설정되어 있어야 합니다. 데이터베이스 로깅은 RDS에 수행된 요청에 대한 상세 레코드를 제공합니다. 데이터베이스 로그는 보안 및 액세스 감사에 도움이 되며 가용성 문제를 진단하는 데 유용할 수 있습니다.

권장사항: 모든 RDS DB 인스턴스에 내보낸 로그가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

resource "aws_db_instance" "example" {
  # ... other configuration for MySQL ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
}

resource "aws_db_parameter_group" "example" {
  name   = "${aws_db_instance.example.dbInstanceIdentifier}-parameter-group"
  family = "mysql5.7"

  parameter {
    name  = "general_log"
    value = 1
  }

  parameter {
    name  = "slow_query_log"
    value = 1
  }

  parameter {
    name  = "log_output"
    value = "FILE"
  }
}

MariaDB의 경우 커스텀 옵션 그룹을 추가로 만들고 aws_db_instance 리소스에서 option_group_name을 설정합니다.

resource "aws_db_instance" "example" {
  # ... other configuration for MariaDB ...
  enabled_cloudwatch_logs_exports = ["audit", "error", "general", "slowquery"]
  parameter_group_name            = aws_db_parameter_group.example.name
  option_group_name               = aws_db_option_group.example.name
}

resource "aws_db_option_group" "example" {
  name                     = "mariadb-option-group-for-logs"
  option_group_description = "MariaDB Option Group for Logs"
  engine_name              = "mariadb"
  option {
    option_name = "MARIADB_AUDIT_PLUGIN"
    option_settings {
      name  = "SERVER_AUDIT_EVENTS"
      value = "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  }
}

AWS 콘솔

커스텀 DB 매개변수 그룹을 만들려면 다음 안내를 따르세요.

https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.
탐색창에서 Parameter groups(매개변수 그룹)을 선택합니다.
Create parameter group(매개변수 그룹 만들기)을 선택합니다.
Parameter group family(매개변수 그룹 계열) 목록에서 DB 매개변수 그룹 계열을 선택합니다.
Type(유형) 목록에서 DB Parameter Group(DB 매개변수 그룹)을 선택합니다.
Group name(그룹 이름)에 새 DB 매개변수 그룹의 이름을 입력합니다.
Description(설명)에 새 DB 매개변수 그룹의 설명을 입력합니다.
Create(만들기)를 선택합니다.

콘솔을 사용하여 MariaDB 로깅에 새 옵션 그룹을 만들려면 다음 안내를 따르세요.

https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.
탐색창에서 Option groups(옵션 그룹)를 선택합니다.
Create group(그룹 만들기)을 선택합니다.
Create option group(옵션 그룹 만들기) 창에서 다음을 제공합니다.
이름: AWS 계정 내에서 고유해야 합니다. 문자, 숫자, 하이픈만 사용할 수 있습니다.
설명: 표시 목적으로만 사용됩니다.
- 엔진: DB 엔진을 선택합니다.
- 주 엔진 버전: DB 엔진의 주 버전을 선택합니다.
Create(만들기)를 선택합니다.
방금 만든 옵션 그룹의 이름을 선택합니다.
Add option(옵션 추가)을 선택합니다.
Option name(옵션 이름) 목록에서 MARIADB_AUDIT_PLUGIN을 선택합니다.
SERVER_AUDIT_EVENTS를 CONNECT, QUERY, TABLE, QUERY_DDL, QUERY_DML, QUERY_DCL로 설정합니다.
Add option(옵션 추가)을 선택합니다.

AWS Management Console에서 SQL Server DB, Oracle DB 또는 PostgreSQL 로그를 CloudWatch Logs에 게시하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.
탐색창에서 Databases(데이터베이스)를 선택합니다.
수정할 DB 인스턴스를 선택합니다.
Modify(수정)를 선택합니다.
Log exports(로그 내보내기)에서 CloudWatch Logs에 게시하기 시작할 모든 로그 파일을 선택합니다.
로그 내보내기는 CloudWatch Logs에 게시를 지원하는 데이터베이스 엔진 버전에서만 사용할 수 있습니다.
Continue(계속)를 선택합니다. 그런 다음 요약 페이지에서 Modify DB Instance(DB 인스턴스 수정)를 선택합니다.

새 DB 매개변수 그룹 또는 DB 옵션 그룹을 RDS DB 인스턴스에 적용하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.
탐색창에서 Databases(데이터베이스)를 선택합니다.
수정할 DB 인스턴스를 선택합니다.
Modify(수정)를 선택합니다.
Database options(데이터베이스 옵션)에서 필요에 따라 DB 매개변수 그룹과 DB 옵션 그룹을 변경합니다.
변경이 완료되면 Continue(계속)를 선택합니다. 수정 요약을 확인합니다.
Modify DB Instance(DB 인스턴스 수정)를 선택하여 변경사항을 저장합니다.

AWS CLI

엔진 계열을 검색하고 DB 인스턴스 엔진 및 버전과 일치하는 계열을 선택합니다.

aws rds describe-db-engine-versions \
  --query "DBEngineVersions[].DBParameterGroupFamily" \
  --engine "mysql"

엔진 및 버전에 따라 매개변수 그룹을 만듭니다.

aws rds create-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --db-parameter-group-family "mysql5.7" \
  --description "Example parameter group for logs"

DB 엔진에 따라 필요한 매개변수가 포함된 rds-parameters.json 파일을 만듭니다. 이 예시에서는 MySQL5.7을 사용합니다.

[
  {
    "ParameterName": "general_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "slow_query_log",
    "ParameterValue": "1",
    "ApplyMethod": "immediate"
  },
  {
    "ParameterName": "log_output",
    "ParameterValue": "FILE",
    "ApplyMethod": "immediate"
  }
]

DB 엔진에 따라 매개변수를 추가하도록 매개변수 그룹을 수정합니다. 이 예시에서는 MySQL5.7을 사용합니다.

aws rds modify-db-parameter-group \
  --db-parameter-group-name "rds-mysql-parameter-group" \
  --parameters file://rds-parameters.json

DB 인스턴스를 수정하여 매개변수 그룹을 연결합니다.

aws rds modify-db-instance \
  --db-instance-identifier "test-rds" \
  --db-parameter-group-name "rds-mysql-parameter-group"

또한 MariaDB의 경우 다음과 같이 옵션 그룹을 만듭니다.

aws rds create-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --engine-name "mariadb" \
  --major-engine-version "10.6" \
  --option-group-description "Option group for MariaDB logs"

다음과 같이 rds-mariadb-options.json 파일을 만듭니다.

{
  "OptionName": "MARIADB_AUDIT_PLUGIN",
  "OptionSettings": [
    {
      "Name": "SERVER_AUDIT_EVENTS",
      "Value": "CONNECT,QUERY,TABLE,QUERY_DDL,QUERY_DML,QUERY_DCL"
    }
  ]
}

옵션 그룹에 옵션을 추가합니다.

aws rds add-option-to-option-group \
  --option-group-name "rds-mariadb-option-group" \
  --options file://rds-mariadb-options.json

MariaDB 인스턴스를 수정하여 옵션 그룹을 DB 인스턴스에 연결합니다.

aws rds modify-db-instance \
  --db-instance-identifier "rds-test-mariadb" \
  --option-group-name "rds-mariadb-option-group"

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Rds Multi Az Support`

API의 카테고리 이름: RDS_MULTI_AZ_SUPPORT

RDS DB 인스턴스가 여러 가용성 영역(AZ)에 구성되어야 합니다. 이렇게 하면 저장된 데이터의 가용성이 보장됩니다. 다중 AZ 배포는 가용성 영역 가용성에 문제가 있고 정기 RDS 유지보수 중에 발생하는 자동 장애 조치를 허용합니다.

권장사항: 모든 RDS DB 인스턴스에 고가용성이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

이 제어를 해결하려면 aws_db_instance 리소스에서 multi_az를 true로 설정합니다.

resource "aws_db_instance" "example" {
  # ... other configuration ...
  multi_az                = true
}

AWS 콘솔

DB 인스턴스에 여러 가용성 영역을 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/rds/에서 Amazon RDS 콘솔을 엽니다.
탐색창에서 Databases(데이터베이스)를 선택한 후 수정할 DB 인스턴스를 선택합니다.
Modify(수정)를 선택합니다. Modify DB Instance(DB 인스턴스 수정) 페이지가 나타납니다.
Instance Specifications(인스턴스 사양)에서 Multi-AZ deployment(다중 AZ 배포)를 Yes(예)로 설정합니다.
Continue(계속)를 선택한 다음 수정 요약을 확인합니다.
(선택사항) 변경사항을 즉시 적용하려면 Apply immediately(즉시 적용)를 선택합니다. 이 옵션을 선택하면 경우에 따라 서비스 중단이 발생할 수 있습니다. 자세한 내용은 Amazon RDS 사용자 가이드의 즉시 적용 설정 사용을 참조하세요.
확인 페이지에서 변경사항을 검토합니다. 문제가 없으면 Modify DB Instance(DB 인스턴스 수정)을 선택하여 변경사항을 저장합니다.

AWS CLI

AWS CLI에도 동일하게 적용됩니다. --multi-az 옵션을 제공하여 다중 Az 지원을 사용 설정합니다.

modify-db-instance
  --db-instance-identifier "test-rds" \
  --multi-az

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Redshift Cluster Configuration Check`

API의 카테고리 이름: REDSHIFT_CLUSTER_CONFIGURATION_CHECK

Redshift 클러스터의 필수 요소인 저장 데이터 암호화, 로깅, 노드 유형을 확인합니다.

이러한 구성 항목은 안전하고 관측 가능한 Redshift 클러스터 유지보수에 중요합니다.

권장사항: 모든 Redshift 클러스터에 저장 데이터 암호화, 로깅, 노드 유형이 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

resource "aws_kms_key" "redshift_encryption" {
  description         = "Used for Redshift encryption configuration"
  enable_key_rotation = true
}

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  encrypted                           = true
  kms_key_id                          = aws_kms_key.redshift_encryption.id
  logging {
    enable               = true
    log_destination_type = "cloudwatch"
    log_exports          = ["connectionlog", "userlog", "useractivitylog"]
  }
}

AWS 콘솔

클러스터 감사 로깅을 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/redshift/에서 Amazon Redshift 콘솔을 엽니다.
탐색 메뉴에서 Clusters(클러스터)를 선택한 후 수정할 클러스터의 이름을 선택합니다.
Properties(속성)를 선택합니다.
Edit(수정), Edit audit logging(감사 로깅 수정)을 차례로 선택합니다.
Configure audit logging(감사 로깅 구성)을 사용 설정한 다음 Log export(로그 내보내기) 유형을 CloudWatch(권장)로 설정하고 내보낼 로그를 선택합니다.

AWS S3를 사용하여 Redshift 감사 로그를 관리하려면 AWS 문서의 Redshift - 데이터베이스 감사 로깅을 참조하세요.

Save changes(변경사항 저장)를 선택합니다.

클러스터에서 데이터베이스 암호화를 수정하려면 다음 안내를 따르세요.

AWS Management Console에 로그인하고 https://console.aws.amazon.com/redshift/에서 Amazon Redshift 콘솔을 엽니다.
탐색 메뉴에서 Clusters(클러스터)를 선택한 후 암호화를 수정할 클러스터를 선택합니다.
Properties(속성)를 선택합니다.
Edit(수정), Edit encryption(암호화 수정)을 차례로 선택합니다.
사용할 암호화(KMS 또는 HSM)를 선택하고 다음을 제공합니다.
- KMS: 사용할 키
- HSM: 연결 및 클라이언트 인증서

AWS CLI

KMS 키 만들기 및 키 ID 검색

aws kms create-key \
  --description "Key to encrypt Redshift Clusters"

클러스터 수정

aws redshift modify-cluster \
  --cluster-identifiers "test-redshift-cluster" \
  --encrypted \
  --kms-key-id <value>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Redshift Cluster Maintenancesettings Check`

API의 카테고리 이름: REDSHIFT_CLUSTER_MAINTENANCESETTINGS_CHECK

자동 주 버전 업그레이드가 유지보수 기간에 따라 수행됩니다.

권장사항: 모든 Redshift 클러스터에 allowVersionUpgrade가 사용 설정되어 있고 preferredMaintenanceWindow 및 automatedSnapshotRetentionPeriod가 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

이 검사는 Terraform에서 제공하는 모든 기본값을 준수합니다. Redshift 클러스터가 실패하면 요구사항을 검토하고 aws_redshift_cluster 리소스의 다음 속성에 대한 기본 재정의를 삭제합니다.

resource "aws_redshift_cluster" "example" {

  # ...other configuration ...

  # The following values are compliant and set by default if omitted.
  allow_version_upgrade               = true
  preferred_maintenance_window        = "sat:10:00-sat:10:30"
  automated_snapshot_retention_period = 1
}

AWS 콘솔

AWS 콘솔을 통해 Redshift 클러스터를 만들 때 기본값은 이미 이 제어를 준수합니다.

자세한 내용은 콘솔을 사용하여 클러스터 관리를 참조하세요.

AWS CLI

AWS CLI를 사용하여 이 제어를 해결하려면 다음을 수행하세요.

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --allow-version-upgrade

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Redshift Cluster Public Access Check`

API의 카테고리 이름: REDSHIFT_CLUSTER_PUBLIC_ACCESS_CHECK

Amazon Redshift 클러스터 구성의 PubliclyAccessible 속성은 클러스터에 공개적으로 액세스할 수 있는지 여부를 나타냅니다. PubliclyAccessible을 true로 설정한 상태에서 클러스터를 구성하면 클러스터는 공개 IP 주소로 확인되는 공개적으로 확인 가능한 DNS 이름이 있는 인터넷 연결 인스턴스가 됩니다.

클러스터에 공개적으로 액세스할 수 없는 경우, 이는 비공개 IP 주소로 확인되는 DNS 이름이 있는 내부 인스턴스가 됩니다. 클러스터에 공개적으로 액세스할 의도가 없으면 PubliclyAccessible을 true로 설정한 상태에서 클러스터를 구성해서는 안 됩니다.

권장사항: Redshift 클러스터에 공개적으로 액세스할 수 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

이 제어를 해결하려면 Redshift 클러스터 리소스를 수정하고 publicly_accessible을 false로 설정해야 하며 기본값은 true입니다.

resource "aws_redshift_cluster" "example" {
  # ... other configuration ...
  publicly_accessible = false
}

AWS 콘솔

Amazon Redshift 클러스터에 대한 공개 액세스를 사용 중지하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/redshift/에서 Amazon Redshift 콘솔을 엽니다.
탐색 메뉴에서 Clusters(클러스터)를 선택한 후 수정할 보안 그룹이 있는 클러스터의 이름을 선택합니다.
Actions(작업)를 선택한 다음 Modify publicly accessible setting(공개적으로 액세스 가능한 설정 수정)을 선택합니다.
Allow instances and devices outside the VPC to connect to your database through the cluster endpoint(VPC 외부의 인스턴스 및 기기가 클러스터 엔드포인트를 통해 데이터베이스에 연결되도록 허용)에서 No(아니요)를 선택합니다.
Confirm(확인)을 선택합니다.

AWS CLI

modify-cluster 명령어를 사용하여 --no-publicly-accessible을 설정합니다.

aws redshift modify-cluster \
  --cluster-identifier "test-redshift-cluster" \
  --no-publicly-accessible

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Restricted Common Ports`

API의 카테고리 이름: RESTRICTED_COMMON_PORTS

보안 그룹에 제한되지 않은 수신 트래픽이 가장 위험한 지정된 포트에 액세스할 수 있는지 여부를 확인합니다. 보안 그룹의 규칙 중 하나라도 해당 포트의 '0.0.0.0/0' 또는 '::/0'에서 인그레스 트래픽을 허용하면 이 제어가 실패합니다.

무제한 액세스(0.0.0.0/0)로 인해 해킹, DoS 공격, 데이터 손실과 같은 악의적인 활동 가능성이 증가합니다.

보안 그룹은 AWS 리소스에 대한 인그레스 및 이그레스 네트워크 트래픽의 스테이트풀(Stateful) 필터링을 제공합니다. 보안 그룹은 다음 포트에 대한 무제한 인그레스 액세스를 허용하면 안 됩니다.

20, 21(FTP)
22(SSH)
23(텔넷)
25(SMTP)
110(POP3)
135(RPC)
143(IMAP)
445(CIFS)
1433, 1434(MSSQL)
3000(Go, Node.js, Ruby 웹 개발 프레임워크)
3306(mySQL)
3389(RDP)
4333(ahsp)
5000(Python 웹 개발 프레임워크)
5432(postgresql)
5500(fcp-addr-srvr1)
5601(OpenSearch 대시보드)
8080(프록시)
8088(기존 HTTP 포트)
8888(대체 HTTP 포트)
9200 또는 9300(OpenSearch)

권장사항: 보안 그룹은 위험도가 높은 포트에 대한 무제한 액세스를 허용해서는 안 됩니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

보안 그룹 규칙을 삭제하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.
탐색창에서 Security Groups(보안 그룹)를 선택합니다.
업데이트할 보안 그룹을 선택하고 Actions(작업)를 선택한 다음 Edit inbound rules(인바운드 규칙 수정)을 선택하여 인바운드 규칙을 삭제하거나 Edit outbound rules(아웃바운드 규칙 수정)을 선택하여 아웃바운드 규칙을 삭제합니다.
삭제할 규칙의 오른쪽에 있는 Delete(삭제) 버튼을 선택합니다.
Preview changes(변경사항 미리보기), Confirm(확인)을 차례로 선택합니다.

보안 그룹에서 규칙을 삭제하는 방법에 대한 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용자 가이드의 보안 그룹에서 규칙 삭제를 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Restricted Ssh`

API의 카테고리 이름: RESTRICTED_SSH

보안 그룹은 AWS 리소스에 대한 인그레스 및 이그레스 네트워크 트래픽의 스테이트풀(Stateful) 필터링을 제공합니다.

CIS는 보안 그룹에서 포트 22에 대한 무제한 인그레스 액세스를 허용하지 않도록 권장합니다. SSH와 같은 원격 콘솔 서비스에 대한 무제한 연결을 제거하면 서버가 위험에 노출될 가능성이 줄어듭니다.

권장사항: 보안 그룹은 0.0.0.0/0에서 포트 22로의 인그레스를 허용해서는 안 됩니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

VPC와 연결된 각 보안 그룹에 대해 다음 단계를 수행하세요.

https://console.aws.amazon.com/vpc/에서 Amazon VPC 콘솔을 엽니다.

왼쪽 창에서 Security groups(보안 그룹)를 선택합니다.
보안 그룹을 선택합니다.
페이지 하단 섹션에서 Inbound Rules(인바운드 규칙) 탭을 선택합니다.
Edit rules(규칙 수정)을 선택합니다.
포트 22를 통한 액세스를 허용하는 규칙을 파악한 후 X를 선택하여 삭제합니다.
Save rules(규칙 저장)를 선택합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Rotation Customer Created Cmks Enabled`

API의 카테고리 이름: ROTATION_CUSTOMER_CREATED_CMKS_ENABLED

키마다 자동 키 순환이 사용 설정되어 있고 고객이 만든 AWS KMS 키의 키 ID와 일치하는지 확인합니다. 리소스에 대한 AWS Config 레코더 역할에 kms:DescribeKey 권한이 없으면 규칙은 NON_COMPLIANT입니다.

권장사항: 고객이 만든 CMK에 순환이 사용 설정되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Rotation Customer Created Symmetric Cmks Enabled`

API의 카테고리 이름: ROTATION_CUSTOMER_CREATED_SYMMETRIC_CMKS_ENABLED

AWS Key Management Service(KMS)를 사용하면 고객이 만든 고객 마스터 키(CMK)의 키 ID에 연결된 KMS 내에 저장된 키 자료인 예비 키를 순환할 수 있습니다. 암호화 및 복호화와 같은 암호화 작업을 수행하는 데 사용되는 예비 키입니다. 자동 키 순환은 암호화된 데이터 복호화가 투명하게 수행될 수 있도록 현재 모든 이전 예비 키를 보존합니다. 대칭 키에 CMK 키 순환을 사용 설정하는 것이 좋습니다. 비대칭 CMK에는 키 순환을 사용 설정할 수 없습니다.

권장사항: 고객이 만든 대칭 CMK에 순환이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/iam에서 IAM 콘솔을 엽니다.
왼쪽 탐색창에서 Customer managed keys를 선택합니다 .
Key spec = SYMMETRIC_DEFAULT인 고객 관리 CMK를 선택합니다.
General configuration(일반 구성) 패널 아래에서 Key rotation(키 순환) 탭을 엽니다.
'Automatically rotate this KMS key every year(매해 이 KMS 키를 자동 순환) ' 체크박스를 선택합니다.

AWS CLI

다음 명령어를 실행하여 키 순환을 사용 설정합니다.

 aws kms enable-key-rotation --key-id <kms_key_id>

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Routing Tables Vpc Peering Are Least Access`

API의 카테고리 이름: ROUTING_TABLES_VPC_PEERING_ARE_LEAST_ACCESS

VPC 피어링의 경로 테이블이 최소 권한의 주 구성원으로 구성되었는지 확인합니다.

권장사항: VPC 피어링의 라우팅 테이블이 '최소 액세스 권한'인지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`S3 Account Level Public Access Blocks`

API의 카테고리 이름: S3_ACCOUNT_LEVEL_PUBLIC_ACCESS_BLOCKS

Amazon S3 퍼블릭 액세스 차단은 Amazon S3 리소스에 대한 공개 액세스를 관리하는 데 도움이 되는 액세스 포인트, 버킷, 계정에 대한 설정을 제공합니다. 기본적으로 새 버킷, 액세스 포인트, 객체에서는 공개 액세스를 허용하지 않습니다.

권장사항: 필요한 S3 공개 액세스 블록 설정이 계정 수준에서 구성되어 있는지 확인합니다.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

다음 Terraform 리소스는 S3에 대한 계정 수준 액세스를 구성합니다.

resource "aws_s3_account_public_access_block" "s3_control" {
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

AWS 콘솔

AWS 계정의 모든 S3 버킷에 대한 공개 액세스 차단 설정을 수정하려면 다음 안내를 따르세요.

AWS Management Console에 로그인하고 https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.
이 계정에 대해 Block Public Access settings(공개 액세스 설정 차단)을 선택합니다.
AWS 계정의 모든 버킷에 대한 공개 액세스 차단 설정을 변경하려면 Edit(수정)을 선택합니다.
변경할 설정을 선택한 다음 Save changes(변경사항 저장)를 선택합니다.
확인 메시지가 표시되면 확인을 입력합니다. 그런 다음 Confirm(확인)을 선택하여 변경사항을 저장합니다.

AWS CLI

aws s3control put-public-access-block \
--account-id <value> \
--public-access-block-configuration '{"BlockPublicAcls": true, "BlockPublicPolicy": true, "IgnorePublicAcls": true, "RestrictPublicBuckets": true}'

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`S3 Bucket Logging Enabled`

API의 카테고리 이름: S3_BUCKET_LOGGING_ENABLED

AWS S3 서버 액세스 로깅 기능에서 보안 감사에 유용한 스토리지 버킷에 대한 액세스 요청을 기록합니다. 기본적으로 S3 버킷에는 서버 액세스 로깅이 사용 설정되지 않습니다.

권장사항: 모든 S3 버킷에 로깅이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

다음 예시에서는 2개의 버킷을 만드는 방법을 보여줍니다.

로깅 버킷
규정 준수 버킷

variable "bucket_acl_map" {
  type = map(any)
  default = {
    "logging-bucket"   = "log-delivery-write"
    "compliant-bucket" = "private"
  }
}

resource "aws_s3_bucket" "all" {
  for_each            = var.bucket_acl_map
  bucket              = each.key
  object_lock_enabled = true
  tags = {
    "Pwd"    = "s3"
  }
}

resource "aws_s3_bucket_acl" "private" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  acl      = each.value
}

resource "aws_s3_bucket_versioning" "enabled" {
  for_each = var.bucket_acl_map
  bucket   = each.key
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_logging" "enabled" {
  for_each      = var.bucket_acl_map
  bucket        = each.key
  target_bucket = aws_s3_bucket.all["logging-bucket"].id
  target_prefix = "log/"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "example" {
  for_each = var.bucket_acl_map
  bucket   = each.key

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
    }
  }
}

AWS 콘솔

AWS 콘솔을 통해 S3 액세스 로깅을 사용 설정하는 방법은 AWS 문서의 Amazon S3 서버 액세스 로깅 사용 설정을 참조하세요.

AWS CLI

다음 예시에서는 다음 작업을 수행하는 방법을 보여줍니다.

버킷 정책을 만들어 로깅 버킷의 PutObject에 Logging 서비스 주 구성원 권한 부여

policy.json javascript { "Version": "2012-10-17", "Statement": [ { "Sid": "S3ServerAccessLogsPolicy", "Effect": "Allow", "Principal": {"Service": "logging.s3.amazonaws.com"}, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::MyBucket/Logs/*", "Condition": { "ArnLike": {"aws:SourceARN": "arn:aws:s3:::SOURCE-BUCKET-NAME"}, "StringEquals": {"aws:SourceAccount": "SOURCE-AWS-ACCOUNT-ID"} } } ] }

aws s3api put-bucket-policy \
  --bucket my-bucket
  --policy file://policy.json

로깅 버킷에 정책 적용

logging.json javascript { "LoggingEnabled": { "TargetBucket": "MyBucket", "TargetPrefix": "Logs/" } }

aws s3api put-bucket-logging \
  --bucket MyBucket \
  --bucket-logging-status file://logging.json

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`S3 Bucket Policy Set Deny Http Requests`

API의 카테고리 이름: S3_BUCKET_POLICY_SET_DENY_HTTP_REQUESTS

Amazon S3 버킷 수준에서는 HTTPS를 통해서만 객체에 액세스할 수 있게 해주는 버킷 정책을 통해 권한을 구성할 수 있습니다.

권장사항: S3 버킷 정책이 HTTP 요청을 거부하도록 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

AWS Management Console에 로그인하고 https://console.aws.amazon.com/s3/를 사용하여 Amazon S3 콘솔을 엽니다.
Bucket(버킷) 옆의 체크박스를 선택합니다.
Permissions(권한)를 클릭합니다.
Bucket Policy(버킷 정책)를 클릭합니다.
이 정책을 필수 정보가 채워진 기존 정책에 추가합니다. { "Sid": <optional>", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::<bucket_name>/*", "Condition": { "Bool": { "aws:SecureTransport": "false" } } }
저장
민감한 정보가 포함된 AWS 계정의 모든 버킷에 대해 이 작업을 반복합니다.

콘솔에서

AWS Policy Generator를 사용하여 다음을 수행합니다.

위의 1~4단계를 반복합니다.
Bucket Policy Editor(버킷 정책 편집기 하단)에서 Policy Generator를 클릭합니다.
S3 Bucket Policy 정책 유형을 선택합니다.
문을 추가합니다.
Effect = Deny
Principal = *
AWS Service = Amazon S3
Actions = *
Amazon Resource Name =
정책 생성
텍스트를 복사하여 버킷 정책에 추가합니다.

AWS CLI

버킷 정책을 json 파일로 내보냅니다. aws s3api get-bucket-policy --bucket <bucket_name> --query Policy --output text > policy.json
다음 문을 추가하여 policy.json 파일을 수정합니다.

{
 "Sid": <optional>",
 "Effect": "Deny",
 "Principal": "*",
 "Action": "s3:*",
 "Resource": "arn:aws:s3:::<bucket_name>/*",
 "Condition": {
 "Bool": {
 "aws:SecureTransport": "false"
 }
 }
 }

이 수정된 정책을 S3 버킷에 다시 적용합니다.

aws s3api put-bucket-policy --bucket <bucket_name> --policy file://policy.json

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`S3 Bucket Replication Enabled`

API의 카테고리 이름: S3_BUCKET_REPLICATION_ENABLED

이 제어는 Amazon S3 버킷에 리전 간 복제가 사용 설정되었는지 여부를 확인합니다. 버킷에 리전 간 복제가 사용 설정되지 않았거나 동일 리전 복제도 사용 설정된 경우에는 제어가 실패합니다.

복제는 같거나 다른 AWS 리전의 버킷 간에 객체를 비동기적으로 자동 복사하는 것입니다. 복제는 새로 생성된 객체와 객체 업데이트를 소스 버킷에서 대상 버킷으로 복사합니다. AWS 권장사항에서는 같은 AWS 계정에서 소유하는 소스 및 대상 버킷의 복제를 권장합니다. 가용성 외에도 다른 시스템 강화 설정을 고려해야 합니다.

권장사항: S3 버킷에 리전 간 복제가 사용 설정되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`S3 Bucket Server Side Encryption Enabled`

API의 카테고리 이름: S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED

S3 버킷에 Amazon S3 기본 암호화가 사용 설정되었는지 또는 S3 버킷 정책에서 서버 측 암호화를 사용하지 않는 객체 내보내기 요청을 명시적으로 거부하는지 확인합니다.

권장사항: 모든 S3 버킷이 저장 데이터 암호화를 사용하는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

AWS 콘솔

S3 버킷에서 기본 암호화를 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.
왼쪽 탐색창에서 Buckets(버킷)을 선택합니다.
목록에서 S3 버킷을 선택합니다.
Properties(속성)를 선택합니다.
Default encryption(기본 암호화)을 선택합니다.
암호화에 AES-256 또는 AWS-KMS를 선택합니다.
Amazon S3에서 관리되는 키를 기본 암호화에 사용하려면 AES-256를 선택합니다. Amazon S3 서버 측 암호화를 사용하여 데이터를 암호화하는 방법에 대한 자세한 내용은 Amazon Simple Storage Service 사용자 가이드를 참조하세요.
AWS KMS에서 관리되는 키를 기본 암호화에 사용하려면 AWS-KMS를 선택합니다. 그런 다음 생성된 AWS KMS 마스터 키 목록에서 마스터 키를 선택합니다.
사용할 AWS KMS 키의 Amazon 리소스 이름(ARN)을 입력합니다. IAM 콘솔의 Encryption keys(암호화 키) 아래에서 AWS KMS 키의 ARN을 확인할 수 있습니다. 또는 드롭다운 목록에서 키 이름을 선택할 수 있습니다.
중요: 기본 암호화 구성에 AWS KMS 옵션을 사용하면 AWS KMS의 RPS (초당 요청 수) 할당량이 적용됩니다. AWS KMS 할당량 및 할당량 증가를 요청하는 방법에 대한 자세한 내용은 AWS Key Management Service 개발자 가이드를 참조하세요.
Save(저장)를 선택합니다.

AWS KMS 키 만들기에 대한 자세한 내용은 AWS Key Management Service 개발자 가이드를 참조하세요.

Amazon S3에서 AWS KMS를 사용하는 방법에 대한 자세한 내용은 Amazon Simple Storage Service 사용자 가이드를 참조하세요.

기본 암호화를 사용 설정할 때 버킷 정책을 업데이트해야 할 수 있습니다. 버킷 정책에서 기본 암호화로 이동하는 방법에 대한 자세한 내용은 Amazon Simple Storage Service 사용자 가이드를 참조하세요.

AWS CLI

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "AES256"}}]}'

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`S3 Bucket Versioning Enabled`

API의 카테고리 이름: S3_BUCKET_VERSIONING_ENABLED

Amazon S3는 같은 버킷에 객체 변형 여러 개를 보관하는 수단이며 의도치 않은 사용자 작업과 애플리케이션 오류로부터 더 쉽게 복구할 수 있도록 도와줍니다.

권장사항: 모든 S3 버킷에 버전 관리가 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-bucket"

  versioning {
    enabled = true
  }
}

AWS 콘솔

S3 버킷에서 버전 관리를 사용 설정하거나 사용 중지하려면 다음 안내를 따르세요.

AWS Management Console에 로그인하고 https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.
버킷 목록에서 버전 관리를 사용 설정하려는 버킷의 이름을 선택합니다.
Properties(속성)를 선택합니다.
Bucket Versioning(버킷 버전 관리)에서 Edit(수정)을 선택합니다.
Suspend(정지) 또는 Enable(사용 설정)을 선택한 다음 Save changes(변경사항 저장)를 선택합니다.

AWS CLI

aws s3control put-bucket-versioning \
--bucket <bucket_name> \
--versioning-configuration Status=Enabled

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`S3 Default Encryption Kms`

API의 카테고리 이름: S3_DEFAULT_ENCRYPTION_KMS

Amazon S3 버킷이 AWS Key Management Service(AWS KMS)로 암호화되었는지 여부를 확인합니다.

권장사항: 모든 버킷이 KMS로 암호화되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

Terraform

resource "aws_kms_key" "s3_encryption" {
  description         = "Used for S3 Bucket encryption configuration"
  enable_key_rotation = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "enable" {
  bucket   = "my-bucket"

  rule {
    apply_server_side_encryption_by_default {
      kms_master_key_id = aws_kms_key.s3_encryption.arn
      sse_algorithm     = "aws:kms"
    }
  }
}

AWS 콘솔

S3 버킷에서 기본 암호화를 사용 설정하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/s3/에서 Amazon S3 콘솔을 엽니다.
왼쪽 탐색창에서 Buckets(버킷)을 선택합니다.
목록에서 S3 버킷을 선택합니다.
Properties(속성)를 선택합니다.
Default encryption(기본 암호화)을 선택합니다.
암호화에 AWS-KMS를 선택합니다.
AWS KMS에서 관리되는 키를 기본 암호화에 사용하려면 AWS-KMS를 선택합니다. 그런 다음 생성된 AWS KMS 마스터 키 목록에서 마스터 키를 선택합니다. KMS 키를 만드는 방법에 대한 자세한 내용은 AWS 문서 - 키 만들기를 참조하세요.
사용할 AWS KMS 키의 Amazon 리소스 이름(ARN)을 입력합니다. IAM 콘솔의 Encryption keys(암호화 키) 아래에서 AWS KMS 키의 ARN을 확인할 수 있습니다. 또는 드롭다운 목록에서 키 이름을 선택할 수 있습니다.
중요: 이 솔루션에는 AWS KMS의 RPS (초당 요청 수) 할당량이 적용됩니다. AWS KMS 할당량 및 할당량 증가를 요청하는 방법에 대한 자세한 내용은 AWS Key Management Service 개발자 가이드를 참조하세요.
Save(저장)를 선택합니다.

Amazon S3에서 AWS KMS를 사용하는 방법에 대한 자세한 내용은 Amazon Simple Storage Service 사용자 가이드를 참조하세요.

AWS CLI

KMS 키 만들기

aws kms create-key \
  --description "Key to encrypt S3 buckets"

키 순환 사용 설정

aws kms enable-key-rotation \
  --key-id <key_id_from_previous_command>

버킷 업데이트

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"KMSMasterKeyID": "<id_from_key>", "SSEAlgorithm": "AES256"}}]}'

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Sagemaker Notebook Instance Kms Key Configured`

API의 카테고리 이름: SAGEMAKER_NOTEBOOK_INSTANCE_KMS_KEY_CONFIGURED

AWS Key Management Service(AWS KMS) 키가 Amazon SageMaker 노트북 인스턴스에 구성되었는지 확인합니다. 'KmsKeyId'가 SageMaker 노트북 인스턴스에 지정되지 않으면 규칙은 NON_COMPLIANT입니다.

권장사항: 모든 SageMaker 노트북 인스턴스가 KMS를 사용하도록 구성되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Sagemaker Notebook No Direct Internet Access`

API의 카테고리 이름: SAGEMAKER_NOTEBOOK_NO_DIRECT_INTERNET_ACCESS

SageMaker 노트북 인스턴스에 직접 인터넷 액세스가 사용 중지되어 있는지 확인합니다. 이렇게 하려면 노트북 인스턴스에 DirectInternetAccess 필드가 중지되었는지 여부를 확인합니다.

VPC 없이 SageMaker 인스턴스를 구성하면 기본적으로 인스턴스에 직접 인터넷 액세스가 사용 설정됩니다. VPC를 사용하여 인스턴스를 구성하고 기본 설정을 VPC를 통해 인터넷 액세스 중지로 변경해야 합니다.

노트북에서 모델을 학습시키거나 호스팅하려면 인터넷 액세스가 필요합니다. 인터넷 액세스를 사용 설정하려면 VPC에 NAT 게이트웨이가 있고 보안 그룹에서 아웃바운드 연결을 허용하는지 확인합니다. 노트북 인스턴스를 VPC의 리소스에 연결하는 방법에 대한 자세한 내용은 Amazon SageMaker 개발자 가이드의 VPC에 있는 리소스에 노트북 인스턴스 연결을 참조하세요.

또한 SageMaker 구성에 대한 액세스 권한이 승인된 사용자로만 제한되도록 해야 합니다. SageMaker 설정과 리소스를 수정할 수 있는 사용자의 IAM 권한을 제한합니다.

권장사항: 모든 Amazon SageMaker 노트북 인스턴스에 직접 인터넷 액세스가 사용 중지되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

노트북 인스턴스가 생성된 후에는 인터넷 액세스 설정을 변경할 수 없습니다. 중지하고 삭제한 후 다시 만들어야 합니다.

직접 인터넷 액세스를 거부하도록 SageMaker 노트북 인스턴스를 구성하려면 다음 안내를 따르세요.

https://console.aws.amazon.com/sagemaker/에서 SageMaker 콘솔을 엽니다.
노트북 인스턴스로 이동합니다.
직접 인터넷 액세스가 사용 설정된 인스턴스를 삭제합니다. Instance(인스턴스)를 선택하고 Actions(작업)를 선택한 다음 Stop(중지)을 선택합니다.
인스턴스가 중지되면 Actions(작업)를 선택한 후 Delete(삭제)을 선택합니다.
Create notebook instance(노트북 인스턴스 만들기)를 선택합니다. 구성 세부정보를 제공합니다.
네트워크 섹션을 펼친 후 VPC, 서브넷, 보안 그룹을 선택합니다. Direct internet access(직접 인터넷 액세스)에서 Disable—Access the internet through a VPC(사용 중지—VPC를 통한 인터넷에 액세스)를 선택합니다.
Create notebook instance(노트북 인스턴스 만들기)를 선택합니다.

자세한 내용은Amazon SageMaker 개발자 가이드의 VPC에 있는 리소스에 노트북 인스턴스 연결을 참조하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Secretsmanager Rotation Enabled Check`

API의 카테고리 이름: SECRETSMANAGER_ROTATION_ENABLED_CHECK

AWS Secrets Manager에 저장된 보안 비밀이 자동 순환으로 구성되었는지 여부를 확인합니다. 보안 비밀이 자동 순환으로 구성되지 않으면 제어가 실패합니다. maximumAllowedRotationFrequency 매개변수에 커스텀 값을 제공하면 보안 비밀이 지정된 기간 내에 자동으로 순환하는 경우에만 제어가 통과합니다.

Secret Manager는 조직의 보안 상황을 개선하는 데 도움이 됩니다. 보안 비밀에는 데이터베이스 사용자 인증 정보, 비밀번호, 서드 파티 API 키가 포함됩니다. Secret Manager를 사용하여 보안 비밀을 중앙에서 저장하고 보안 비밀을 자동으로 암호화하고 보안 비밀에 대한 액세스를 제어하며 보안 비밀을 안전하게 자동으로 순환할 수 있습니다.

Secret Manager는 보안 비밀을 순환할 수 있습니다. 순환을 사용하여 장기 보안 비밀을 단기 보안 비밀로 바꿀 수 있습니다. 보안 비밀을 순환하면 승인되지 않은 사용자가 보안 침해된 보안 비밀을 사용할 수 있는 시간이 제한됩니다. 따라서 보안 비밀을 자주 순환해야 합니다. 순환에 대한 자세한 내용은 AWS Secrets Manager 사용자 가이드의 AWS Secrets Manager 보안 암호 교체를 참조하세요.

권장사항: 모든 AWS Secrets Manager 보안 비밀에 순환이 사용 설정되어 있는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Sns Encrypted Kms`

API의 카테고리 이름: SNS_ENCRYPTED_KMS

SNS 주제에 AWS KMS를 통해 저장 데이터 암호화가 적용되는지 여부를 확인합니다. SNS 주제에서 서버 측 암호화(SSE)에 KMS 키를 사용하지 않으면 제어가 실패합니다.

저장 데이터를 암호화하면 AWS에 인증되지 않은 사용자가 디스크에 저장된 데이터에 액세스할 위험이 줄어듭니다. 또한 승인되지 않은 사용자의 데이터 액세스를 제한하는 또 다른 액세스 제어 세트가 추가됩니다. 예를 들어 데이터를 읽으려면 먼저 복호화할 수 있는 API 권한이 필요합니다. SNS 주제에는 보안 강화를 위해 저장 데이터 암호화가 적용되어야 합니다.

권장사항: 모든 SNS 주제가 KMS로 암호화되었는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Vpc Default Security Group Closed`

API의 카테고리 이름: VPC_DEFAULT_SECURITY_GROUP_CLOSED

이 제어는 VPC의 기본 보안 그룹에서 인바운드 또는 아웃바운드 트래픽을 허용하는지 여부를 확인합니다. 보안 그룹에서 인바운드 또는 아웃바운드 트래픽을 허용하면 제어가 실패합니다.

기본 보안 그룹 규칙은 같은 보안 그룹에 할당된 네트워크 인터페이스(및 연결된 인스턴스)의 모든 아웃바운드 및 인바운드 트래픽을 허용합니다. 기본 보안 그룹을 사용하지 않는 것이 좋습니다. 기본 보안 그룹을 삭제할 수 없으므로 기본 보안 그룹 규칙 설정을 변경하여 인바운드 및 아웃바운드 트래픽을 제한해야 합니다. 이렇게 하면 EC2 인스턴스와 같은 리소스에 기본 보안 그룹이 실수로 구성된 경우에도 의도하지 않은 트래픽이 방지됩니다.

권장사항: 모든 VPC의 기본 보안 그룹이 전체 트래픽을 제한하는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Vpc Flow Logging Enabled All Vpcs`

API의 카테고리 이름: VPC_FLOW_LOGGING_ENABLED_ALL_VPCS

VPC 흐름 로그는 VPC의 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보를 캡처할 수 있는 기능입니다. 흐름 로그를 만든 후에는 Amazon CloudWatch Logs에서 데이터를 보고 검색할 수 있습니다. VPC의 경우 패킷 '거부'에 VPC 흐름 로그를 사용 설정하는 것이 좋습니다.

권장사항: 모든 VPC에 VPC 흐름 로깅이 사용 설정되어 있는지 확인하세요.

이 발견 항목을 해결하려면 다음 단계를 완료하세요.

AWS 콘솔

Management Console에 로그인합니다.
Services를 선택한 다음 VPC를 선택합니다.
왼쪽 탐색창에서 Your VPCs를 선택합니다.
VPC를 선택합니다.
오른쪽 창에서 Flow Logs 탭을 선택합니다.
흐름 로그가 없으면 Create Flow Log를 클릭합니다.
필터에 Reject를 선택합니다.
Role 및 Destination Log Group을 입력합니다.
Create Log Flow를 클릭합니다.
CloudWatch Logs Group을 클릭합니다.

참고: 필터를 '거부'로 설정하면 이 권장사항의 로깅 데이터 누적이 크게 줄어들고 위반 감지, 조사, 해결에 충분한 정보가 제공됩니다. 하지만 최소 권한 보안 그룹 엔지니어링 기간 중에 이 필터를 '모두'로 설정하면 이미 실행 중인 환경의 올바른 작동에 필요한 기존 트래픽 흐름을 찾는 데 매우 유용할 수 있습니다.

AWS CLI

정책 문서를 만들고 이름을 role_policy_document.json으로 지정한 후 다음 콘텐츠를 붙여넣습니다.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Sid": "test",
 "Effect": "Allow",
 "Principal": {
 "Service": "ec2.amazonaws.com"
 },
 "Action": "sts:AssumeRole"
 }
 ]
}

다른 정책 문서를 만들어 이름을 iam_policy.json으로 지정한 후 다음 콘텐츠를 붙여넣습니다.

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action":[
 "logs:CreateLogGroup",
 "logs:CreateLogStream",
 "logs:DescribeLogGroups",
 "logs:DescribeLogStreams",
 "logs:PutLogEvents",
 "logs:GetLogEvents",
 "logs:FilterLogEvents"
 ],
 "Resource": "*"
 }
 ]
}

아래 명령어를 실행하여 IAM 역할을 만듭니다.

aws iam create-role --role-name <aws_support_iam_role> --assume-role-policy-document file://<file-path>role_policy_document.json

아래 명령어를 실행하여 IAM 정책을 만듭니다.

aws iam create-policy --policy-name <ami-policy-name> --policy-document file://<file-path>iam-policy.json

이전 단계에서 반환된 IAM 정책 ARN을 사용해 attach-group-policy 명령어를 실행하여 IAM 역할에 해당 정책을 연결합니다(명령어가 성공하면 출력이 반환되지 않음).

aws iam attach-group-policy --policy-arn arn:aws:iam::<aws-account-id>:policy/<iam-policy-name> --group-name <group-name>

describe-vpcs를 실행하여 선택한 리전에서 사용 가능한 VpcId를 가져옵니다.

aws ec2 describe-vpcs --region <region>

명령어 결과는 선택된 리전에서 사용 가능한 VPC ID를 반환해야 합니다.
create-flow-logs를 실행하여 VPC의 흐름 로그를 만듭니다.

aws ec2 create-flow-logs --resource-type VPC --resource-ids <vpc-id> --traffic-type REJECT --log-group-name <log-group-name> --deliver-logs-permission-arn <iam-role-arn>

선택한 리전에서 사용 가능한 다른 VPC에 대해 8단계를 반복합니다.
--region을 업데이트하여 리전을 변경하고 다른 VPC에 대한 해결 절차를 반복합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Vpc Sg Open Only To Authorized Ports`

API의 카테고리 이름: VPC_SG_OPEN_ONLY_TO_AUTHORIZED_PORTS

이 제어는 Amazon EC2 보안 그룹이 승인되지 않은 포트에서 제한되지 않은 수신 트래픽을 허용하는지 여부를 확인합니다. 제어 상태는 다음과 같이 결정됩니다.

authorizedTcpPorts의 기본값을 사용하는 경우 보안 그룹에서 포트 80 및 443 이외의 모든 포트에서 제한되지 않은 수신 트래픽을 허용하면 제어가 실패합니다.

authorizedTcpPorts 또는 authorizedUdpPorts의 커스텀 값을 제공하는 경우 보안 그룹이 비공개 포트에서 제한되지 않은 수신 트래픽을 허용하면 제어가 실패합니다.

매개변수를 사용하지 않으면 제한되지 않은 인바운드 트래픽 규칙이 있는 보안 그룹에 대한 제어가 실패합니다.

보안 그룹은 AWS에 대한 인그레스 및 이그레스 네트워크 트래픽의 스테이트풀(Stateful) 필터링을 제공합니다. 보안 그룹 규칙은 최소 액세스 권한의 주 구성원을 따라야 합니다. 무제한 액세스(/0 서픽스가 있는 IP 주소)로 인해 해킹, DoS 공격, 데이터 손실과 같은 악의적인 활동 가능성이 증가합니다. 포트가 특별히 허용되지 않는 한 포트는 제한되지 않은 액세스를 거부해야 합니다.

권장사항: VPC가 0.0.0.0/0인 보안 그룹이 특정 인바운드 TCP/UDP 트래픽만 허용하는지 확인하세요.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.

`Both VPC VPN Tunnels Up`

API의 카테고리 이름: VPC_VPN_2_TUNNELS_UP

VPN 터널은 AWS Site-to-Site VPN 연결 내에서 고객 네트워크에서 또는 AWS에서 데이터가 전달될 수 있는 암호화된 링크입니다. 각 VPN 연결에는 고가용성을 위해 동시에 사용할 수 있는 VPN 터널 2개가 포함됩니다. AWS VPC와 원격 네트워크 간의 안전하고 가용성이 높은 연결을 확인하려면 VPN 연결에 대해 두 VPN 터널 모두 작동하는지 확인해야 합니다.

이 제어는 AWS Site-to-Site VPN에서 제공하는 두 VPN 터널 모두 UP 상태인지 확인합니다. 터널 중 하나가 또는 모두 DOWN 상태이면 제어가 실패합니다.

권장사항: AWS 사이트 간에서 제공되는 두 AWS VPN 터널이 모두 UP(작동) 상태인지 확인합니다.

이 발견 항목 유형의 지원되는 애셋 및 스캔 설정에 대해 알아봅니다.