[Cloud & CERT] 근두운 인프라 문제점 분석 (박진혁)

미리 밝혀 두면, 이 글은 우리 팀을 비판하려는 게 아니다. 아직 프로젝트 중반이고 W5 이후 일정에 들어 있는 항목이 많다. 여기서 하려는 건 "계획에 있다"와 "지금 막을 수 있다"는 다르다는 걸 확인하는 것이다. 지금 이 순간 사고가 나면 어떻게 되는지를 기준으로 봤다.

1. 지금 우리 인프라는 어디까지 와 있나

구조도부터 그려 봤다.

정리하면 이렇다. 코드로 관리하는 파이프라인과 계정 수준 기록은 있고, 그 아래 네트워크 분리와 탐지·대응 계층은 비어 있다. 위에서 아래로 쌓은 게 아니라 양 끝에서 시작한 모양이다.

구조도의 붉은 항목 중 VPC 서브넷 분리와 보안그룹 구성은 W4 일정에 잡혀 있지만 실제 적용 상태를 내가 직접 확인하지 못했다. 이 글에서는 "적용됐더라도 계층별 체이닝까지는 아니다"를 전제로 봤다. 사실과 다르면 해당 항목은 빼면 된다.

2. 과제 1 기준: 아직 지나오지 않은 Step

과제 1의 Step에 우리를 대응시켜 보면 이렇다.

Step	내용	근두운
1	계층 분리	아직 대상 워크로드가 본격적으로 올라가지 않아 해당 없음
2	Scale Up/Out	미도달
3	Load Balancing	미도달
4	Stateless / 세션	미도달
5	Health Check, 이중화	미도달
6	Failure Domain	미도달
7	AWS 매핑	일부 (EC2, S3 사용 중)

과제 1 쪽은 대부분 미도달이지만, 여기서 중요한 건 우리 프로젝트에서 그게 문제인가다. 우리는 상용 서비스를 운영하는 게 아니라 침해를 재현하고 탐지하는 게 목적이다. 그래서 Scale Out이나 세션 외부화가 지금 없는 건 문제라고 보지 않았다.

문제가 되는 건 Step 5와 6이다. 이유가 서비스 가용성이 아니라 탐지 가용성 쪽에 있다.

지금 Wazuh는 사실상 단일 지점이다. 이게 죽으면 로그 수집과 탐지가 통째로 멈추는데, Health Check가 없으니 죽은 걸 알아차리는 방법도 없다. 공격 재현 단계에서 SIEM이 조용하면 "탐지 실패"인지 "SIEM이 죽어 있었음"인지 구분이 안 된다. 실제 침해 사고에서도 공격자가 가장 먼저 노리는 게 로그와 탐지 계층이다. 1회차에 CloudTrail 탐지 이벤트로 StopLogging, DeleteTrail을 꼽아 놓고서, 정작 우리 SIEM이 멈추는 건 감시하지 않고 있다.

Step 6도 같은 맥락이다. SIEM 서버와 공격 대상 워크로드가 같은 장애 범위 안에 있으면 공격 재현이 곧 탐지 인프라 장애가 된다. W6에는 의도된 취약점 배치가 예정되어 있다. 취약점을 심어 둔 서버와 그걸 지켜보는 서버가 같은 실패 범위에 있으면 실험 자체가 성립하지 않는다.

3. 과제 2 기준: 내부 이동은 지금 어떻게 되어 있나

과제 2 쪽이 더 직접적이다.

Step	내용	근두운
1	공인 IP 노출 구분	부분 적용
2~5	DMZ, NAT, Bastion	미도달 또는 미확인
6	AWS 매핑	W4 일정, 부분 적용
7	East-West 인식	미도달
8	Security Group Chaining	미도달

가장 크게 걸리는 게 Step 7~8이다. 지금 우리 환경에서 내부 이동을 막는 통제가 뭔지 물으면 답할 게 없다. 서브넷을 나눴더라도 과제 2에서 확인한 대로 local 경로는 기본으로 존재하고, 보안그룹을 "우리 VPC 대역 허용"으로 걸어 뒀다면 Step 8에서 겪은 것과 똑같은 상태다.

그런데 우리 환경에는 일반적인 3-tier보다 조건이 하나 더 나쁘다. k3s 클러스터가 있다. 컨테이너 사이의 통신은 보안그룹 아래 계층에서 일어나기 때문에, 보안그룹을 잘 걸어도 파드 사이의 이동은 그대로 열려 있다. 여기에 W6 의도된 취약점까지 들어가면, 취약점 하나가 클러스터 전체 장악으로 이어질 수 있다. 과제 3 타임라인의 Lateral Movement 칸이 실제로 우리 환경에서 재현 가능하다는 뜻이다.

관리 접근 경로도 같은 문제다. Bastion이나 SSM 중 무엇으로 들어가는지 팀 안에 정해진 규칙이 없다. 지금은 각자 편한 방식으로 접속하고 있을 가능성이 높은데, 그러면 Step 5에서 본 대로 접속 기록이 흩어져서 사후에 누가 무엇을 했는지 재구성할 수 없다.

여기에 계정 쪽 문제가 하나 더 겹친다. 1회차 보고서 기준으로 IAM 그룹 3개에 AWS 관리형 FullAccess가 붙어 있고 최소권한은 아직 미적용이다. 즉 지금은 네트워크 이동을 막아도 자격증명 하나만 유출되면 API로 전부 접근된다. 과제 2가 다룬 게 네트워크 평면의 이동이라면, 클라우드에는 그것과 별개로 API 평면의 이동이 있다. 우리 쪽은 이 두 번째 평면이 훨씬 넓게 열려 있다.

4. 과제 3 기준: 지금 사고가 나면 타임라인을 쓸 수 있나

결론부터 쓰면 쓸 수 없다. Mission 5의 타임라인 표를 우리 환경에 그대로 놓고, 각 줄의 근거를 지금 확보할 수 있는지 따져 봤다.

사건	필요한 근거	지금 우리가 가진 것
초기 침투	Web/WAF 로그	없음
프로세스 실행	EDR 프로세스 이벤트	Wazuh 에이전트 배포 범위 불명, 취약점 탐지 모듈 위주
외부 통신	VPC Flow Logs, 네트워크 이벤트	VPC Flow Logs 미수집
파일 생성	파일 무결성 감시	설정 여부 불명
내부 이동	대상 서버 인증 로그, 상관 룰	개별 서버에는 남지만 중앙 수집·상관분석 없음
봉쇄 조치	자동화 실행 기록, CloudTrail	CloudTrail은 있음, 자동화는 없음

여기서 한 가지를 분명히 하고 싶다. CloudTrail이 있으니 "기록은 있다"고 말할 수 있지만, CloudTrail이 답해 주는 건 "누가 어떤 AWS API를 호출했는가"뿐이다. 서버 안에서 어떤 프로세스가 무슨 파일을 만들었는지는 한 줄도 안 나온다. 과제 3 Mission 1의 네 가지 질문 중 CloudTrail로 답할 수 있는 건 사실상 없다.

Mission별로 보면 이렇다.

Mission 1 — Wazuh는 있지만 현재 쓰고 있는 건 취약점 탐지 쪽이다. 침해 조사에 필요한 프로세스 실행 계보, 파일 변경, 아웃바운드 연결이 실제로 수집되고 있는지는 별개 문제다.

Mission 2 — 가장 크게 비어 있다. 로그 소스가 CloudTrail 하나뿐이고, 정규화와 시간 동기화 기준이 없고, 탐지 룰이 없다. 1회차에 CloudTrail 탐지 대상 이벤트를 AssumeRole, CreateAccessKey, StopLogging 등으로 정리해 뒀는데, 그건 조사 문서일 뿐 지금 그 이벤트가 발생해도 아무도 모른다. 조사와 적용 사이가 이 프로젝트의 가장 큰 간극이다.

Mission 3, 4 — 착수 전이다. W7 일정이니 지금 없는 게 이상하진 않다.

Mission 5 — 케이스 관리 도구가 없다. 지금 사고가 나면 노션 문서에 손으로 쓰게 될 텐데, 문제는 근거로 붙일 원본 로그가 애초에 없다는 쪽이다.

그리고 과제 3과 별개로, 우리 프로젝트에만 있는 위험이 하나 더 있다. 레포 공개와 의도된 취약점 배치가 겹치는 구간이다. 앞서 레포 공개 위험을 조사하면서, ARN 노출보다 fork PR로 들어오는 워크플로 동작이 실제 위험이라는 걸 확인했다. 여기에 취약점이 심어진 인프라 코드가 공개로 올라가면, 우리가 재현 대상으로 삼은 공격을 외부인이 먼저 할 수 있다. 탐지가 없는 상태에서 이게 겹치는 게 지금 가장 큰 구멍이다.

5. 문제점 목록

#	어디가	왜 문제인가	어떤 사고로 이어지나	개선 방향
P1	IAM 그룹에 FullAccess	최소권한 미적용, 자격증명 하나가 계정 전체 권한	키 유출 시 로그 삭제, 리소스 파괴까지 한 번에	태그 기반 최소권한 정책으로 리팩터링, MFA 강제, 장기 키 대신 STS
P2	탐지 룰 없음	로그는 쌓이지만 아무것도 알려 주지 않음	침해가 일어나도 인지 자체가 안 됨	1회차에 정리한 CloudTrail 이벤트부터 Sigma 룰로 작성해 Wazuh에 적용
P3	로그 소스가 CloudTrail 하나	서버 내부 행위와 네트워크 흐름이 안 남음	사고 조사 시 타임라인 작성 불가	VPC Flow Logs 활성화, Wazuh 에이전트로 프로세스·파일·인증 로그 수집
P4	내부 이동 통제 없음	서브넷을 나눠도 local 경로와 파드 간 통신은 열림	취약점 하나가 클러스터·DB 전체 장악으로 확대	SG를 SG ID 기반 체이닝으로 전환, k3s NetworkPolicy 적용
P5	SIEM이 단일 지점이고 감시 대상이 아님	탐지 계층이 죽어도 알 수 없음	탐지 실패와 SIEM 장애를 구분 못 해 실험 결과가 무효	Wazuh 자체 헬스 체크와 경보, 수집 중단 감지 룰 추가
P6	SIEM과 공격 대상이 같은 장애 범위	공격 재현이 탐지 인프라를 같이 흔듦	W8 시나리오 재현 시 근거 소실	SIEM을 별도 서브넷·별도 인스턴스로 분리, 로그 사본을 S3에 고정
P7	관리 접근 경로 미통일	접속 기록이 흩어지고 경로가 여럿	사후에 "누가 들어왔나"를 재구성 불가	SSM Session Manager로 단일화, SSH 인바운드 전면 차단
P8	레포 공개와 의도된 취약점 시점 중첩	취약한 인프라 코드가 공개 상태로 노출	외부인의 선제 공격, fork PR을 통한 CI 악용	취약점 배치 구간에는 비공개 유지, OIDC `sub` 조건과 Plan 역할 읽기 전용 검증
P9	케이스 기록 체계 없음	조사 과정과 근거가 남지 않음	최종 보고서의 탐지 커버리지·MTTD를 근거 없이 쓰게 됨	사고 기록 양식을 먼저 정하고, 재현 실험부터 그 양식으로 기록

6. 개선 우선순위

순서를 정하는 기준은 두 가지로 잡았다. 없으면 다음 단계가 아예 성립하지 않는 것을 먼저, 그리고 지금 당장 사고로 이어질 수 있는 것을 먼저다.

1순위 — 지금 사고가 나도 조사가 되게 만든다 (P3, P2, P1)

로그 소스부터 늘려야 한다. VPC Flow Logs를 켜고, Wazuh 에이전트가 프로세스·파일·인증 로그를 실제로 보내는지 확인한다. 그다음 1회차에 정리해 둔 CloudTrail 이벤트를 탐지 룰로 옮긴다. 조사 문서를 룰로 바꾸는 이 작업이 가장 값싸고 효과가 크다. IAM 최소권한도 이 묶음에 넣었다. P1이 열려 있으면 다른 통제를 아무리 세워도 API 한 번으로 우회된다.

2순위 — 실험이 성립하게 만든다 (P6, P5, P8)

W6의 취약점 배치와 W8의 시나리오 재현 전에 끝나야 하는 것들이다. SIEM을 공격 대상과 다른 장애 범위로 빼고, SIEM 자체를 감시 대상에 넣고, 레포 공개 시점을 취약점 배치 구간과 어긋나게 조정한다. 이건 보안 강화라기보다 실험 설계의 전제 조건이다.

3순위 — 피해 확산을 막는다 (P4, P7)

보안그룹을 SG 체이닝으로 바꾸고 k3s NetworkPolicy를 적용한다. 관리 접근은 SSM으로 단일화한다. 1순위보다 뒤에 둔 이유는, 지금은 막는 것보다 보이게 만드는 게 먼저라고 봤기 때문이다. 탐지가 없는 상태에서 차단만 늘리면 무엇을 막았는지도 모른다.

4순위 — 결과를 남긴다 (P9)

사고 기록 양식을 정하고 재현 실험부터 그 양식으로 쓴다. 최종 산출물에 들어갈 탐지 커버리지와 MTTD는 결국 이 기록에서 나온다.

7. 정리하며

네 편을 쓰면서 계속 반복된 문장이 있다. "이름이 붙어 있다고 그 기능이 동작하는 건 아니다."

과제 2에서 Private Subnet이라는 이름만 보고 안전하다고 생각했고, 과제 3에서 로그를 모았으니 탐지가 된다고 생각했다. 그리고 우리 인프라를 보면서 같은 착각을 하고 있었다는 걸 알았다. "Wazuh 배포 완료", "CloudTrail 활성화"라고 적어 두면 그 칸이 채워진 것 같지만, 지금 사고가 나면 Mission 5의 타임라인 여섯 줄 중 근거를 댈 수 있는 줄이 거의 없다.

가장 크게 반성한 건 P2다. 1회차에 CloudTrail에서 탐지해야 할 이벤트를 정리해 뒀는데, 그게 조사 문서에만 있고 룰로는 존재하지 않는다. 조사와 적용 사이의 간극이 곧 우리 인프라의 탐지 공백이었다. 앞으로는 조사 결과를 정리할 때 "이걸 어디에 적용해서 언제 동작을 확인할 것인가"를 같이 적어야겠다고 생각했다.

반대로 잘한 점도 적어 둔다. Terraform으로 IAM을 코드화해 둔 덕분에 P1의 최소권한 리팩터링은 콘솔을 뒤지지 않고 코드 리뷰로 할 수 있다. 레포 공개 위험도 ARN 노출이라는 표면이 아니라 OIDC 신뢰 정책이라는 실제 통제 지점까지 내려가서 확인했다. 통제의 위치를 정확히 짚는 습관은 이번 네 편에서 계속 쓰인 방식이었고, 앞으로 개선 작업에서도 그대로 쓰면 된다.