AWS Security Hub 리소스 중요도 설정: 핵심 서버 보안 위험 우선순위

리소스 중요도란? 심각도와 다른 이유

리소스 중요도는 자원이 업무에서 얼마나 중요한지를 나타냅니다. 결제 서버, 고객 데이터 저장소, 내부 테스트 서버는 같은 종류의 보안 문제가 있어도 중단·침해 시 업무 영향이 다를 수 있습니다. 반대로 중요도가 낮은 테스트 서버라도 관리자 권한이나 운영 데이터에 접근할 수 있다면 위험을 낮게 보면 안 됩니다.

Security Hub는 exposure finding에서 심각도·영향·리소스 중요도·공격 가능성 등을 이용해 위험을 우선순위화한다고 설명합니다. 근거: Exposure findings 개요 중요도를 높게 지정했다고 모든 발견이 자동으로 CRITICAL이 되거나 특정 순위가 보장된다고 해석하지 마세요.

새 기능의 설정 방식·확인 화면·비용

근거: 10월 14일 출시 발표. “추가 비용 없음”은 중요도 기능을 설명하며 Security Hub 전체가 무료라는 의미는 아닙니다. 사용할 계정·리전에서 Security Hub 지원과 이용 상태를 확인하세요.

설정 전 핵심 서버를 분류하는 기준

이는 편집부 분류 예시입니다. prod라는 이름만으로 모든 자원을 같은 중요도로 묶기보다 서비스 책임자와 역할을 대조하세요. 반대로 dev라는 이름이 남아 있는 운영 서버는 추론과 업무 실상이 다를 수 있습니다.

자동화 규칙으로 핵심 계정의 컴퓨팅 리소스 지정하기

AWS 발표는 특정 계정의 모든 컴퓨팅 리소스를 Very High로 표시하는 예를 듭니다. 실제 적용에서는 먼저 Resources에서 해당 계정·리소스 범위를 확인한 뒤, 리소스 중요도를 갱신하는 자동화 규칙을 구성하세요. 근거: 규칙 예시

1. 대상 확인: 계정·리전·리소스 유형과 업무 역할을 기록합니다.
2. 규칙 설계: 어떤 조건을 어떤 중요도로 지정할지, 제외할 자원은 무엇인지 정합니다.
3. 설정 검토: 리소스용 규칙과 발견 항목용 규칙을 구분하고 실제 UI의 지원 조건·동작을 확인합니다.
4. 제한된 적용: 작은 범위에서 중요도와 결정 출처를 확인합니다.
5. 기존·신규 확인: 기존 리소스와 새로 발견되는 리소스를 각각 점검합니다.
6. 운영 연결: 담당자·대응 기한·예외 검토 주기를 정합니다.

현재 확인한 출시 발표는 상세 API 요청 형식과 규칙 충돌 시 우선순위를 명시하지 않았습니다. 기존 CSPM 규칙의 순서나 숫자형 Criticality 갱신 예제를 그대로 새 리소스 규칙에 복사하지 마세요. 구체적인 필드·충돌 처리는 사용 중인 콘솔과 최신 문서에서 확인해야 합니다.

설명용 규칙 설계표 — API 요청 형식이 아님
목적: 결제 서비스 핵심 컴퓨팅 자원 우선 조사
대상 계정: [운영 계정 ID]
대상 리소스: [확인한 컴퓨팅 유형과 범위]
설정할 중요도: Very High
검토할 제외 대상: [공유·테스트 자원 등]
검증: 기존 자원 / 새로 발견한 자원 / 결정 출처
담당자 / 재검토 날짜 / 되돌리기 계획:

태그·이름 추론을 확인하고 오분류 줄이기

중요도 값만 보지 말고 무엇이 값을 결정했는지 출처를 확인하세요. 규칙의 적용 의도와 결과가 다르면 조건 일치, 다른 규칙, 현재 태그·이름, 인벤토리 갱신 상태를 조사합니다. 특정 태그 키에 특정 값을 넣으면 언제나 원하는 중요도가 나온다는 공식 매핑은 이번 발표만으로 확인할 수 없습니다.

예를 들어 결제 API 서버의 이름에 test가 남아 있다면 이름만 보고 판단하지 말고 실제 트래픽·소유자·데이터 접근 권한을 대조하세요. 태그 표준을 변경할 때에는 다른 자동화가 그 태그를 사용하는지도 확인해야 합니다. 이 사례는 진단 설명이며 실제 AWS 계정 관측 결과가 아닙니다.

Resources와 Impact assessment로 대응 순서 정하기

Resources에서 중요도가 높은 자원을 모아 업무 담당자와 확인한 뒤, 연결된 exposure finding의 영향과 공격 경로를 검토하세요. 공식 심각도 문서는 likelihood와 impact를 조합해 severity를 결정한다고 설명합니다. 근거: 노출 심각도 평가

이 표는 고정된 AWS 위험 계산식이나 공식 대응 기한이 아닙니다. 팀의 사고 대응 기준에 맞춰 실제 악용 징후와 영향을 우선 고려하세요. 중요도 분류를 완료했다는 사실만으로 취약점이나 노출이 해결되지는 않습니다.

기존 ASFF Criticality와 혼동하지 않기

Security Hub CSPM의 ASFF에는 발견과 연결된 리소스의 중요도를 담는 0~100 정수 Criticality 필드가 있습니다. 근거: ASFF 필드 정의 이 기존 필드와 새 Resources 중요도 표시·노출 우선순위 기능을 동일 스키마라고 가정하지 마세요.

연동 프로그램을 수정한다면 API 종류, 반환 필드, 대상이 finding인지 resource인지 먼저 확인해야 합니다. Very High를 임의로 100으로 변환하거나 기존 BatchUpdateFindings 호출만으로 새 기능을 설정했다고 판단하면 실제 결과와 어긋날 수 있습니다.

적용 결과를 기록하는 점검표

계정·리전 / 리소스 ID / 서비스 소유자:
업무 역할 / 데이터 접근 / 의존 관계:
기대 중요도 / 실제 표시 중요도 / 결정 출처:
규칙 이름·조건 / 적용 확인 시각:
기존·신규 리소스 검증 결과:
연결된 exposure finding / 영향 / 공격 가능성:
조치 담당자 / 기한 / 예외·재검토 날짜:

변경 전후 자원 수와 제외 대상을 비교하세요. 핵심 자원 대부분이 같은 등급으로 묶이면 분류가 너무 넓은지 확인하고, 빠진 업무 자원이 있으면 조건과 인벤토리 범위를 점검합니다. 위험 처리 성과는 설정 건수보다 실제 수정·검증 결과로 따로 추적하는 것이 좋습니다.

오분류 검토 예시: 결제 API와 운영 데이터에 접근하는 테스트 서버

다음은 가상 자산을 이용한 업무 분류 예시입니다. AWS가 자동으로 부여하는 등급표나 위험 계산식이 아닙니다.

핵심 계정 전체를 한 등급으로 묶는 규칙을 도입할 때에는 포함·제외 표본을 모두 확인하세요. 기존 자원 하나가 맞게 표시되는 것만으로 새로 발견한 자원이나 다른 유형도 같은 의도로 처리된다고 결론 내릴 수 없습니다.

잘못 지정한 경우를 대비해 규칙 변경 전 조건·표시값·결정 출처를 기록합니다. 규칙 비활성화나 수정 후 값이 언제 어떻게 재계산되는지는 실제 환경에서 확인해야 하며, 즉시 원래 값으로 복원된다고 가정하지 마세요.

자주 묻는 질문

리소스 중요도를 별도로 활성화해야 하나요?

10월 14일 발표는 Essentials에 포함되고 별도 활성화가 필요 없다고 안내합니다. Security Hub 이용·지원 리전 조건은 별도로 확인하세요.

Very High면 모든 위험이 CRITICAL인가요?

업무 중요도와 노출 심각도는 다른 기준입니다. 실제 finding의 영향·공격 가능성과 함께 해석해야 합니다.

태그 하나로 원하는 등급을 확정할 수 있나요?

발표는 이름·태그 추론을 설명하지만 고정 태그 매핑을 제시하지 않습니다. 실제 결정 출처를 확인하고 명시적 규칙이 필요한지 판단하세요.

관련 보안 운영 안내

• GitHub AI Scan 지표 해석과 대응 결과 점검
• Copilot 텔레메트리 수집 범위 확인