728x90

Google Cloud SCC Challenge Lab 정리

Security Command Center로 따라가 보는 클라우드 보안 운영의 전체 흐름

이번에 진행한 Mitigate Threats and Vulnerabilities with Security Command Center: Challenge Lab은 단순히 Google Cloud 콘솔의 보안 메뉴를 눌러 보는 실습이 아니었다. 겉으로는 SCC(Security Command Center)의 기능을 사용하는 랩처럼 보이지만, 실제로는 클라우드 보안 운영자가 어떤 순서로 자산을 바라보고, 위험을 판별하고, 노이즈를 걷어내고, 실제 조치를 수행하고, 최종 결과를 보존하는지를 압축해서 경험하게 만드는 실습에 가깝다.

이 랩에서 요구하는 작업은 크게 다섯 단계로 나뉜다. 먼저 SCC Findings 화면에서 시간 범위를 180일로 맞춰 관찰 범위를 확보한다. 이후 특정 finding에 대해 static mute rule을 생성해 운영상 노이즈를 줄인다. 그다음 Open SSH port, Open RDP port 같은 실제 위험한 노출 상태를 수정한다. 이후 Web Security Scanner를 통해 실행 중인 웹 애플리케이션을 검사하고, 마지막으로 Findings를 Google Cloud Storage로 export해서 장기 보존 가능한 보안 이력으로 남긴다.

이 글에서는 단순한 실습 후기보다 조금 더 아래 개념까지 내려가서, SCC가 어떤 보안 개념 위에서 동작하는지, 그리고 왜 실습이 이 순서로 설계되어 있는지를 흐름적으로 정리해보려 한다.

1. SCC를 기능이 아니라 운영 플랫폼으로 보기

SCC를 처음 보면 “Google Cloud의 보안 대시보드” 정도로 이해하기 쉽다. 물론 틀린 말은 아니지만, 이 정도 설명으로는 본질이 잘 잡히지 않는다. SCC는 단순히 결과를 예쁘게 모아 보여주는 UI가 아니라, 원래 보안 업계에 따로 존재하던 여러 개념을 클라우드 리소스 중심으로 통합해 운영하게 해주는 플랫폼에 가깝다.

보안 운영은 대체로 다음 흐름을 가진다.

무엇이 있는지 파악한다 → 위험한 상태를 식별한다 → 불필요한 경고를 정리한다 → 실제 위험을 수정한다 → 애플리케이션도 검사한다 → 결과를 남긴다

이번 챌린지 랩은 정확히 이 흐름을 따른다.
즉 SCC의 핵심은 “보안 메뉴 하나 더 생긴 것”이 아니라, 클라우드 환경에서 발생하는 보안 판정 결과를 운영 가능한 형태로 다루게 하는 것이다.

2. SCC에서 가장 중요한 기본 단위: Finding

SCC를 이해할 때 가장 먼저 잡아야 하는 개념은 Finding이다. Finding은 단순한 로그도 아니고, 리소스 자체도 아니다. 보다 정확히 말하면, 특정 리소스에 대해 보안 시스템이 ‘이 상태는 위험하다’고 판정한 결과다.

예를 들어 VM이 있다고 해서 그 VM 자체가 finding은 아니다. 방화벽 규칙이 있다고 해서 그 규칙 자체가 finding인 것도 아니다. 대신, 그 VM이나 규칙이 보안 정책상 위험한 상태라고 판정될 때 Open SSH port, Audit logging disabled 같은 finding이 생성된다.

이번 실습에서 다루는 대표 finding은 다음과 같은 성격을 가진다.

Flow logs disabled, Audit logging disabled, Admin service account, Open SSH port, Open RDP port

즉 SCC는 자산 목록 화면이 아니라, 자산에 대한 보안 해석 결과를 다루는 화면으로 이해하는 편이 맞다.

3. SCC 아래에 깔린 핵심 보안 개념들

3.1 자산 인벤토리: 무엇이 있는지 알아야 지킬 수 있다

보안의 출발점은 늘 같다.
무엇이 존재하는지 알아야 보호할 수 있다.

어떤 VM이 있는지, 어떤 서비스 계정이 있는지, 어떤 네트워크가 외부에 열려 있는지, 어떤 웹 애플리케이션이 떠 있는지 모르면 보안 조치도 불가능하다. 온프레미스 환경에서도 자산 파악은 중요했지만, 클라우드에서는 리소스 생성과 변경이 API 단위로 매우 빠르게 일어나기 때문에 더욱 중요해진다.

SCC는 바로 이런 클라우드 자산을 기반으로 finding을 연결해 보여준다. 따라서 SCC는 단순 보안 UI라기보다, 클라우드 자산 인벤토리를 보안 관점으로 해석하는 계층이라고 볼 수 있다.

3.2 CSPM: 클라우드 설정 상태를 계속 평가하는 개념

이번 실습의 가장 중심에 있는 개념은 CSPM(Cloud Security Posture Management) 이다. 쉽게 말해, 클라우드 환경의 현재 설정 상태가 보안 원칙에 맞는지 지속적으로 점검하는 것이다.

여기서 posture는 자세가 아니라 보안 태세, 즉 현재의 보안 상태를 뜻한다. 예를 들어 로그가 꺼져 있지 않은지, 감사 로그가 비활성화되어 있지 않은지, 관리자 권한 서비스 계정이 과도하게 사용되고 있지 않은지, SSH나 RDP 포트가 공개 인터넷에 그대로 열려 있지 않은지 같은 것들이 모두 CSPM의 검사 대상이다.

실습에 등장하는 Flow logs disabled, Audit logging disabled, Admin service account, Open SSH port, Open RDP port는 모두 이런 위험한 구성 상태를 가리키는 finding이다. 공격이 실제로 발생했는지를 보는 것이 아니라, 지금 설정 자체가 위험한가를 본다는 점에서 전형적인 CSPM 성격을 가진다.

3.3 네트워크 하드닝: 노출면을 줄이는 가장 전통적인 보안 조치

실습 중 Open SSH port, Open RDP port를 수정하는 단계는 네트워크 하드닝(Network Hardening) 의 대표적인 사례다. 네트워크 하드닝은 이름이 거창해 보이지만, 본질은 단순하다.

불필요하게 열려 있는 통신 경로를 줄이고, 접근 가능한 대상을 최소화해서 공격 표면을 줄이는 것

예를 들어 0.0.0.0/0처럼 전 세계 누구나 접근 가능한 허용 범위를 유지하는 것은 위험하다. 반대로 관리용 IP 대역만 허용하도록 소스 범위를 제한하면, 공격 가능한 경로가 크게 줄어든다.

이번 실습에서는 public internet을 향한 SSH와 RDP 노출을 제거하고, 필요 시 35.235.240.0/20 대역을 사용하도록 안내한다. 이 부분은 SCC가 finding으로 위험을 식별하고, 사용자가 방화벽 규칙을 수정해 실제 보안 상태를 바꾸는 remediation 흐름을 보여준다.

3.4 RDP: 윈도우 원격 접속 통로가 왜 위험이 되는가

여기서 함께 등장하는 RDP(Remote Desktop Protocol) 는 윈도우 시스템에 원격으로 접속하기 위한 대표적인 프로토콜이다. 리눅스 원격 접속에서 SSH를 떠올리면 이해하기 쉽다.

문제는 RDP가 공개 인터넷에 열려 있을 때다. 이 경우 외부에서 누구나 해당 포트로 접속을 시도할 수 있고, 그 자체로 공격 표면이 커진다. 따라서 Open RDP port finding은 단순히 “윈도우 포트 하나 열려 있음” 수준이 아니라, 외부 원격 접속 통로가 과하게 खुल려 있는 상태로 이해해야 한다.

3.5 DAST: 실행 중인 웹 애플리케이션을 외부 시점에서 검사하는 방식

실습 후반의 Web Security Scan 단계는 앞의 인프라 구성 점검과 결이 다르다. 여기서 등장하는 핵심 개념은 DAST(Dynamic Application Security Testing) 다.

DAST는 실행 중인 애플리케이션에 실제 요청을 보내 보면서 취약점 징후를 찾는 방식이다. 즉 코드만 보는 것도 아니고, 설정만 보는 것도 아니다. 이미 떠 있는 서비스에 대해 외부에서 접근해서, 동작 과정에서 드러나는 보안 문제를 확인한다.

이번 실습에서는 cls-vm의 외부 IP를 static IP로 바꾸고, http://<YOUR_EXTERNAL_IP>:8080 URL에 대해 Web Security Scanner를 실행한다. 여기서 static IP를 먼저 붙이는 이유는 스캔 대상이 계속 바뀌면 안 되기 때문이다. 즉 대상 식별을 안정화한 뒤, 실행 중인 웹앱을 검사하는 구조다. 이것이 바로 DAST 성격의 AppSec 작업이다.

3.6 버킷과 아카이빙: 결과를 남겨야 보안 운영이 완성된다

마지막 export 단계에서 등장하는 버킷(bucket) 은 Google Cloud Storage의 기본 저장 단위다. 가장 쉽게 말하면, 파일을 저장하는 클라우드 저장소 컨테이너다. 다만 일반적인 폴더보다는 객체를 담는 그릇에 가깝다.

이번 실습에서 Findings를 GCS 버킷으로 export하는 이유는 단순하다. 콘솔 화면에서 잠깐 보는 것으로 끝나지 않고, 나중에 다시 확인하고, 감사에 대응하고, 사고 발생 시 과거 상태를 추적하기 위해서다.

실습에서는 scc-export-bucket-____ 형태의 버킷에 findings.jsonl 파일로 결과를 export하게 한다. 이 단계는 기능적으로는 export지만, 개념적으로는 보안 이력의 장기 보관, 즉 아카이빙에 해당한다.

4. Mute Rule은 단순 숨김이 아니라 운영상의 예외 처리 규칙이다

이번 실습에서 가장 오해하기 쉬우면서도 중요한 개념이 Mute Rule이다. 처음 보면 “그냥 경고 숨기기 기능인가?” 정도로 느껴질 수 있다. 반은 맞고 반은 틀리다.

Mute rule은 단순한 숨김 기능이 아니라, 보안 신호를 운영 가능한 수준으로 정제하는 규칙이다.

보안 도구는 원래 많은 finding을 만든다. 그런데 모든 finding을 똑같은 무게로 다루면, 실제로 시급한 문제가 노이즈 속에 묻혀 버린다. 그래서 보안 운영에서는 늘 다음과 같은 판단이 필요하다.

어떤 경고는 지금 당장 조치해야 하고, 어떤 경고는 이미 인지된 예외일 수 있으며, 어떤 경고는 현재 조직의 운영 정책상 우선순위가 낮을 수도 있다.

Mute rule은 바로 이런 상황에서 쓰인다.
즉 특정 조건에 맞는 finding을 muted 상태로 처리해서, 운영상 우선 대응 대상에서 제외하는 것이다.

여기서 중요한 점은 분명하다.

Mute는 finding을 삭제하지 않는다.
Mute는 실제 취약점을 고치지 않는다.
Mute는 단지 그 finding을 지금 운영 화면에서 주된 대응 신호로 보지 않겠다고 결정하는 것이다.

예를 들어 Flow logs disabled finding을 mute했다고 해서 flow log가 켜지는 것은 아니다. 다만 운영자가 그 finding을 현재는 예외로 취급하는 것이다. 반면 Open SSH port를 firewall rule 수정으로 막았다면, 그건 실제 remediation이다.

즉 둘의 차이는 명확하다.

remediation은 보안 상태 자체를 바꾸는 것
mute는 보안 결과를 다루는 방식을 바꾸는 것

이번 실습에서 생성하는 static mute rule은 다음 세 가지다.

muting-flow-log-findings
muting-audit-logging-findings
muting-admin-sa-findings

여기서 static이라는 말은 일회성으로 잠깐 숨기는 것이 아니라, 정해진 query 조건에 맞는 finding을 지속적으로 muted 상태로 처리하는 규칙에 가깝다. 그래서 실습 문서에서도 finding details를 보고 query에 넣을 값을 찾아 rule을 만들라고 안내한다.

실무적으로 보면 mute rule은 탐지 튜닝, 예외 처리, 노이즈 제거, 운영 우선순위 정리와 같은 개념에 가깝다.
즉 단순한 “숨김”이 아니라, 무엇을 진짜 경고로 운영할 것인가를 정의하는 행위다.

5. 왜 실습은 이 순서로 구성되어 있을까

이제 위 개념들을 알고 다시 실습 흐름을 보면, 순서가 매우 자연스럽다.

5.1 먼저 관찰 범위를 확보한다

실습은 SCC Findings 화면에서 시간 범위를 Last 180 days로 맞추는 것부터 시작한다. 이건 단순 UI 설정이 아니라 가시성 확보다. 보안 운영은 무엇을 볼지부터 결정해야 한다. 필요한 finding이 안 보이면, 이후의 예외 처리나 remediation도 성립하지 않는다.

5.2 그다음 노이즈를 정리한다

이후 static mute rule 세 개를 만든다. 이 단계는 위험을 고치는 단계가 아니라, 보안 결과를 운영 가능한 수준으로 정제하는 단계다. 즉 실습은 처음부터 “모든 finding을 다 같은 무게로 보지 말라”는 메시지를 준다.

5.3 이제 실제 위험을 수정한다

그 다음 Open SSH port, Open RDP port를 public internet에 노출되지 않도록 수정한다. 이 단계는 앞의 mute와 달리, 실제로 보안 상태를 바꾸는 구간이다. 즉 CSPM finding을 네트워크 하드닝으로 해결하는 remediation 단계다.

5.4 인프라 보안에서 애플리케이션 보안으로 확장한다

이후 cls-vm의 외부 IP를 static IP로 바꾸고, 8080 포트의 샘플 웹 애플리케이션에 대해 Web Security Scan을 수행한다. 이는 “인프라만 안전하면 끝”이 아니라, 실제로 서비스 중인 애플리케이션도 별도의 보안 검사가 필요하다는 점을 보여준다.

5.5 마지막에는 결과를 남긴다

마지막으로 Findings를 GCS 버킷에 findings.jsonl로 export한다. 즉 보안은 찾고 고치는 것으로 끝나는 것이 아니라, 무엇이 있었는지 기록으로 남겨야 완성된다는 뜻이다.

6. 이 실습을 한 문장으로 요약하면

이번 SCC 챌린지 랩은 단순한 콘솔 기능 실습이 아니라, 클라우드 자산을 보안 관점에서 관찰하고, 위험한 상태를 finding으로 식별하고, 노이즈는 mute rule로 정리하고, 실제 노출은 하드닝으로 줄이고, 웹 애플리케이션은 DAST로 검사하고, 최종 결과는 버킷에 아카이빙하는 전체 보안 운영 흐름을 압축해서 보여주는 실습이었다.

7. 획득 (실습 후기)