[2/25] AWSKRUG Security 소모임 후기

개요

[ Opening ]

KRUG Security Meetup Icebreaking

[ Session 1 ]

제목 : AWS VPC 접근의 새로운 패러다임
발표자 : 씬커님
내용 : VPN 없이 Cloudflare One으로 Private Network & Egress 제어하기, 맨땅에 헤딩하며 얻은 실전 노하우

[ Session 2 ]

제목 : SG 검토 대시보드 개발 및 활용기
발표자 : Security Meetup Organizer - 지훈님
내용 : 반복적이고 비효율적인 업무를 claude code로 개발 및 개선한 사례 소개

[ Session 1 ] AWS VPC 접근의 새로운 패러다임

최근 AWS VPC 내 프라이빗 자산(EC2, DB 등)에 접근하기 위해 전통적으로 사용하던 방식들(VPN, Bastion Host)의 한계를 느끼고, 이를 Cloudflare One을 활용한 "제로 네트워크(Zero Network) 아키텍처'로 해결한 실전 노하우를 공유합니다.

1. AWS Client VPN 기존 방식의 문제점

우리가 흔히 사용하는 방식들은 운영 효율성이나 비용, 보안 측면에서 여러 단점이 있습니다.

① AWS Client VPN

Client VPN은 서브넷 단위로 과금이 이루어집니다.
즉, 여러 환경을 나누어 구성하면 고정 비용이 꽤 발생합니다.
스타트업이나 50인 이하 조직에서는 부담이 될 수 있는 구조입니다.

비용 부담: 연결된 서브넷당 고정비 발생하며, 한 달에 약 100달러 이상의 비용이 발생할 수 있어 비싼편이다
제어의 한계: 특정 도메인별로 VPN을 경유하는 설정하는 것이 불가능하며, 유저 단위의 세밀한 IP 접근 제어가 어렵다즉, VPN을 통해 접속하면 사용자에게는 내부 IP가 하나 부여된다. 하지만 이 IP는 개인 고유 IP가 아니라 세션 기반 임시 IP이다. 그러므로 보안 그룹에서 "이 사람만 접근 허용해줘" 같은 제어를 하기가 어렵다

Bastion Host
- 관리 리소스: SSH 키 페어를 지속적으로 관리해야 하며, 유저별 접속 이력(Auditing)을 남기기 위해 인스턴스를 늘리거나 유저를 일일이 생성해야 하는 번거로움이 있습니다.
- 가용성: 베스트 호스트 장애 시 모든 접속이 차단되는 단일 장애점(SPOF) 문제가 있습니다.
Public ALB + WAF
- 보안 취약: 사무실 IP 기반 화이트리스트 방식은 동일 IP를 사용하는 사내 모든 인원(재무팀, 개발팀 등)에게 동일한 접근 권한을 부여하게 되는 보안상 허점이 있습니다.

2. 대안: Cloudflare One 기반 제로트러스트

발표자(씬커님)는 기술적 중심축을 Cloudflare에 두고, 기존의 복잡한 접근 방식을 단순화했습니다.

AWS VPC 프라이빗 서브넷에
cloudflared 데몬을 설치한 인스턴스 하나만 배포
그리고 모든 접근은 Cloudflare Edge를 통해 인증 기반으로 처리.

핵심 개념: 단순한 'Zero Trust'를 넘어 네트워크 경계 자체를 최소화하는 'Zero Network' 관점에서 접근했습니다.
사용자 경험: 개발팀이나 협업 인원들이 온보딩할 때 별도의 복잡한 인증 과정 없이, 클라이언트 설치와 로그인 한 번으로 불편함 없이 사용 가능한 환경을 구축했습니다.
안정성: 세션 끊김이나 충돌 현상 없이 매끄러운 접속 환경을 제공하여 개발 생산성을 높였습니다.

3. 아키텍처

[흐름] 개발자가 EC2에 SSH 접속하려고 할 때

사용자가 ssh ssh-dev.company.com 입력
요청이 Cloudflare Edge로 감
로그인 요구
IDP(Okta, Google Workspace) 인증 완료
Edge가 정책 확인
- 이 사람 developers 그룹인가?
- SSH 접근 허용 대상인가?
허용이면
→ Edge가 이미 열려있는 터널(cloudflared)로 트래픽 전달
EC2 22번 포트로 연결

궁금한점

1. Cloudflare은 어떤 기준으로 접근제어를 할까?

"네트워크 레벨의 접근 경로"를 기준으로 한다

도메인 (ec2-dev.company.com)
포트(22, 3306)
프로토콜(SSH, HTTP, TCP)
터널 이름
내부 IP + 포트 조합

cloudflare은 ARN을 모른다

2. 그럼 애플리케이션 단위 제어라는게 무슨 뜻이지?

AWS 리소스 단위가 아니라 "사용자가 접근하려는 네트워크 대상 하나"를 의미함

ssh-dev.company.com → EC2:22
db.company.com → RDS:3306
admin.company.com → 내부 웹서버:443

3. 이런 설정은 어떻게 하는걸까?

① 먼저 EC2에서 하는 설정 (cloudflared 쪽)

EC2 안에 cloudflared를 설치한다

cloudflared tunnel create ec2-ssh

설정 파일을 작성한다

vi /etc/cloudflared/config.yml

tunnel: ec2-ssh
credentials-file: /root/.cloudflared/ec2-ssh.json

ingress:
  - hostname: ssh-dev.company.com
    service: ssh://localhost:22
  - service: http_status:404

ssh-dev.company.com 으로 들어오면
EC2의 22번 포트로 연결하라

그다음에 실행한다

cloudflared tunnel run ec2-ssh

② Cloudflare 쪽에서 하는 설정 (Access 정책)

Cloudflare Zero Trust 대시보드로 이동

Zero Trust → Access → Applications → Add application

Application type 선택:

Self-hosted
SSH

Hostname 입력: ssh-dev.company.com

Policy 설정:

Allow:
   Group = developers

4. 장점

인바운드 설정이 필요 없다
- cloudflared가 Edge와 아웃바운드 세션으로 연결된다
- cloudflared가 설치된 EC2의 인바운드 SG 오픈을 할 필요가 없다
  - 이유: cloudflared가 Edge와는 이미 HTTPS 세션을 먼저 맺어둔걸 계속 유지함
  - 🤔 아웃바운드와 인바운드의 차이 & 왜 아웃바운드 통신만 된다는거지?

더보기
TCP 3-way handshake를 먼저 시작하면 아웃바운드이다
외부에서 나한테 SYN을 보내면 인바운드

cloudflared가 먼저 Edge한테 3-way handshake를 요청함
443포트로 HTTPS가 연결되어있음
이 상태를 계속 유지(persistent connection)이므로 계속 아웃바운드 통신만 하는 것이다!

- NAT 비용이 부담된다면 Public Subnet에 배치하고, 인바운드를 열지 않고 구성가능하다 → 비용 절약 가능
IDP와 연동 가능하다
- Okta, Google Workspace, Azure AD등
- 인증 기반 접근제어가 가능하다
세밀한 접근 제어 가능
- 사용자/그룹 기반
- 특정 리소스/대역 접근 허용
- 애플리케이션별 정책 설정
- 세션 타임아웃 개별 설정 가능
50인 이하는 무료
- 스타트업에게 매우 강력한 옵션
모바일 앱 지원
- Client VPN은 모바일 대응 어려움
- Cloudflare WARP는 모바일 지원
직관적인 관리
- 설정보다 요구사항 정의가 더 어려웠다.
- 실제 구축시간: 2주

5. 실제 적용 사례

사례 1) 웹 접근 제어

기존

IP 기반 제어
사무실 VPN 장비 운영

변경 후

도메인 접근 시 → Cloudflare Access 리디렉션
Okta 인증 후 접속
TLS 암호화 통신

재택이든 사무실이든 동일한 보안 정책 적용

사례 2) Vercel 접근 제어

🤔 Vercel 접근제어란?

Vercel: 프론트엔드 웹사이트를 “배포해주는 플랫폼”

코드만 올리면 자동으로 빌드하고, 전 세계에 배포해주고, HTTPS까지 다 해주는 서비스

vercel 접근제어가 필요한 이유

기본적으로 프로젝트를 배포하면 도메인이 생성됨(ex. https://myapp.vercel.app)

하지만 URL을 아는 사람은 모두 접근 가능하고, 별도 인증 설정을 안하면 공개 상태이고, 팀 내부용 서비스도 외부로 노출이 된다

문제:

Vercel 보안 기능은 Enterprise 플랜 필요 (비쌈)

해결:

Cloudflare 도메인 등록
Vercel 도메인을 Cloudflare 경유
vercel.app → 강제 리디렉션 → 인증 후 접근

엔터프라이즈 비용 없이 Zero Trust 구성

사례 3) SageMaker AI Notebook

문제:

IAM 계정 발급 필요
AWS 계정 제공 부담

해결:

Notebook 터미널 접속
cloudflared 설치
Named Tunnel 생성
Localhost 포트를 도메인 매핑

인바운드 트래픽 없이 Notebook 접근 가능

사례 4) Source NAT VPN 대체

Cloudflare WARP 사용

특정 도메인/대역은 Cloudflare Tunnel 경유
IP 기반 접근 제어가 필요한 외부 서비스 대응

예:

고객사 시스템이 특정 IP만 허용
재택 환경에서 접근 필요

→ Cloudflare Connector Instance 경유

🤔 무슨뜻이지?

만약 다음과 같이 설정이 되어있다면,

" 우리 시스템은 특정 IP에서 오는 것만 허용합니다"

근데 우리는 재택근무 중이라서 집 IP, 회사 IP 다 고정적이지 않아서 접근이 불가능해

=> 이때 필요한게 SNAT야

"내 요청이 항상 특정한 고정 IP로 나가는것처럼 보이고 싶을때" 사용한다

재택 PC
   ↓
회사 VPN 접속
   ↓
회사 네트워크
   ↓
회사 고정 IP로 나감
   ↓
고객사 시스템 접속 성공

Cloudflare WARP를 사용한다면,

cloudflare connector Instance가 AWS 안에 있기때문에 그 인스턴스는 고정 Public IP를 가질 수 있다

그러므로, 기존에는 회사 VPN, NAT 장비로 SNAT를 설정해줘야했지만,

Cloudflare Tunnel, AWS Connector Instance로 추가 설정 없이 고정 IP가 할당된다

재택 PC
   ↓
WARP
   ↓
Cloudflare 네트워크
   ↓
Cloudflare Connector Instance (AWS 안에 있음)
   ↓
고객사 시스템

“Source NAT VPN 대체”란

고객사가 특정 IP만 허용할 때,
Cloudflare 터널을 이용해 요청이 항상 고정 IP에서 나가는 것처럼 만드는 구조

특정 도메인만 Cloudflare 경유한다는것?

WARP는 이런게 가능하다

example.com → Cloudflare 터널을 경유하고, 나머지는 일반 인터넷으로 통신하도록

즉, 필요한 도메인만 SNAT 처리가 가능하

6. 실전 도입 결과 및 추천 이유

온보딩 간소화: "이것만 설치하고 로그인하세요" 한 마디면 모든 설정이 끝날 정도로 간편합니다.
운영 효율성: 인바운드 포트를 열어두거나 복잡한 SG(Security Group) 관리를 유저 단위로 할 필요가 없어 운영 리소스가 획기적으로 줄어듭니다.
성능 및 안정성: 실제 운영 환경에서 에러나 충돌 사례가 거의 없을 정도로 안정적인 아키텍처임을 확인했습니다.

7. 단점 및 트레이드오프

1) Logging 부족

하루치 로그만 제공
상세 레벨 낮음
CloudTrail 수준 아님

해결:

Lambda로 로그 수집 별도 저장
엔터프라이즈 플랜 필요하면 해결 가능

2) Route53 사용 어려움

네임서버를 Cloudflare로 변경해야 함
무료 플랜은 제약 있음

3) CDN 캐싱 이슈

기본적으로 캐싱 활성화
어디서 캐싱되는지 추적 어려움

해결:

Development Mode 활성화
캐싱 정책 별도 정리

4) Latency 증가

기존:

Client → Public Internet → Server​

Cloudflare:

Client → Cloudflare Edge → Okta Auth → Server

실측 결과:

약 100ms 증가

체감은 거의 없음
하지만 초저지연 서비스에는 고려 필요

5) SPOF

Cloudflare 장애 시 → 접근 불가

단, 서비스 자체는 정상 동작

8. 질의응답

Q1. 새로운 아키텍처(Cloudflare One)를 도입했을 때, 실제 내부 구성원들의 반응이나 결과는 어땠나요? 권장할 만한 수준인가요?

가장 큰 성과는 '사용자 편의성'이었습니다.

개발팀 등 내부 사용자들이 새로운 환경에 온보딩할 때 "클라이언트 앱 설치하고 로그인만 하세요"라는 가이드 하나로 끝날 만큼 간편해졌습니다
이전처럼 복잡한 인증을 여러 번 거치거나 접속 장애로 스트레스를 받는 일이 없었고, 사용자들이 네트워크 연결 여부를 의식하지 못할 정도로 매끄럽게 운영되었습니다
기술적으로도 세션 끊김이나 충돌 현상이 거의 발생하지 않아 매우 안정적이었습니다

Q2. 도입 후 체감 효과

“있는지도 모르게 잘 쓰고 있다.”

개발팀 온보딩 간단
인증 불편 없음
세션 문제 없음
장애 이슈 없음

보안은 강화됐지만
사용자 경험은 나빠지지 않았다.

Q3. 금융권에서는 가능할까?

현실적으로 어렵다.

SaaS 사용 제약
규제/보안 심사 대응 부담

엔터프라이즈 + ISMS 대응 환경이라면 신중 검토 필요

9. 결론

50인 이하 조직이라면 강력 추천

비용 0원
VPN 대체 가능
인증 기반 접근 구조
모바일 지원

엔터프라이즈라면 고려 필요

Logging
규제 대응
SaaS 정책
SLA 요구사항

10. 인사이트

1️⃣ IP 기반 보안은 한계가 있다 → 사람을 구분하지 못하므로 인증 기반(Zero Trust)으로 전환하려는 흐름이 있다.

2️⃣ 실무자는 보안과 비용을 동시에 고민한다 → 엔터프라이즈 솔루션 대신 무료/저비용 SaaS를 활용해 현실적인 대안을 찾는다.

3️⃣ 완벽한 보안보다 ‘운영 가능한 보안’을 택한다 → 로그 부족, 제약 사항이 있어도 운영 부담이 낮으면 채택한다.

4️⃣ 목표는 보안 강화 + 사용자 경험 유지 → 개발자가 불편하지 않고, 온보딩이 쉬운 구조가 중요하다.

[ Session 2 ] SG 검토 대시보드 개발 및 활용기

― 반복 업무를 자동화하며 ISMS-P 대응까지 해결한 이야기

1. 왜 Security Group 검토는 항상 어렵게 느껴질까?

ISMS-P 심사에서 빠지지 않고 등장하는 질문이 있습니다.

“보안 시스템에 설정된 정책의 타당성을 주기적으로 검토하고 있습니까?”

대부분의 회사가 이 항목에서 한 번씩 지적을 받습니다.
이유는 단순합니다.

Security Group은 보기 쉬운 만큼, 지적하기도 쉽기 때문입니다.

하지만 실제 운영 환경에서 SG 검토는 생각보다 훨씬 어렵습니다.

2. 우리가 실제로 겪는 문제들

운영하면서 마주친 현실적인 어려움은 다음과 같습니다.

어떤 SG가 어떤 리소스에 attach 되어 있는지 한눈에 보기 어렵다
미사용 SG를 찾기가 매우 어렵다
SG Chain 참조 구조가 복잡하다 (2~3차 참조는 수작업으로 파악하기 힘들다)
0.0.0.0/0, 광범위 포트 범위를 일괄 조회하기 번거롭다
순환 참조가 발생했는지 확인하기 어렵다
AWS 계정이 수십 개라면? 사실상 관리 불가능

결론은 하나였습니다.

“SG를 쉽고, 편하고, 정확하게 관리하고 싶다.”

그래서 직접 만들기로 했습니다.
SG 검토 전용 대시보드.

3. 기술 선택

1️⃣ Steampipe

AWS API를 SQL처럼 조회 가능
SDK 직접 호출 불필요
멀티 계정 지원
운영자가 다루기 매우 편함

SQL을 실행하면 → 내부적으로 AWS API 호출 → 결과 반환

2️⃣ Powerpipe

Steampipe 데이터를 대시보드로 시각화
하지만 커스터마이징 제약이 존재

데이터는 Steampipe로 수집하고,
시각화는 직접 구현하자.

4. 전체 아키텍처 구성

① Steampipe 데이터 수집 모듈

멀티 어카운트 인증 처리
사전 정의 SQL 쿼리 실행
Aggregator 활용 병렬 처리
병목 해결

② 데이터 가공

SG 중심 노드 구성
리소스 ↔ SG 관계 맵핑
SG 체이닝 구조 표현
취약 포트 기준 정의 (22, 3389 등)

③ 커스텀 HTML 대시보드

SG 중심 시각화
리소스 타입별 색상/도형 구분
계정 필터링
VPC 필터링
상세 패널 제공
Excel 리포트 다운로드

5. 이 대시보드로 해결한 것

1️⃣ 미사용 SG 즉시 탐지

“Show Unused SG” 토글
계정별 미사용 SG 즉시 확인
삭제 대상 리포트 자동 생성

이전에는 찾기 어려웠던 미사용 SG를
몇 초 만에 파악할 수 있게 되었습니다.

2️⃣ 과도한 정책 자동 추출

0.0.0.0/0 개방
위험 포트 개방
광범위 포트 범위

계정별 위험 SG 수치를 바로 확인 가능

3️⃣ SG 체이닝 검토

서로 참조만 하고 attach 안 된 SG 탐지
2차 참조까지 시각화
순환 참조 구조 확인

4️⃣ ISMS-P 대응력 강화

“Security Group 검토 어떻게 하십니까?”

대시보드 실행 → 계정 필터링 → 분기별 검토 내역 확인 → 조치 이력 설명

그 이후 추가 질문 거의 없음.

이전에는
“연 1회 수행”이라고 문서에만 적혀 있었지만

이제는
분기별 실제 수행 체계가 정착되었습니다.

6. 추가 자동화 사례

1) Git Repo Secret 자동 탐지

TruffleHog 기반
PR 시 자동 탐지
Slack 알림
Daily 전체 스캔
Org 멤버 Public Repo 생성도 주기 점검

AI 사용 증가로 비엔지니어 실수 가능성 증가
→ 자동화 필수

2) 퇴사자 계정 자동 삭제

매일 저녁 6시 자동 실행

Google Workspace
Slack
Notion
VPN (Teleport)
기타 SaaS 7~8개

Okta 없이 자체 자동화 구성

3) PC 보안 점검 미이행 자동 차단

DLP API 연동
점검 미완료 → CAA 차단
Slack 봇으로 복구 요청

보안 점검을 “권고”가 아닌 “강제 실행 구조”로 변경

4) Google Spreadsheet 퍼블릭 권한 자동 통제

문제:

수십만 개 스프레드시트
30~40%가 퍼블릭

해결:

GWS API 활용
전체 Drive 스캔
퍼블릭 권한 자동 탐지
일정 기간 후 내부 권한으로 전환

결과:

퍼블릭 비율 40% → 10% 이하 감소
공격 표면 관리(ASM) 측면에서 큰 효과.

5) 피싱 메일 전사 자동 삭제

기존 방식:

“이 메일 열지 마세요” 공지

현재 방식:

신고 접수
제목/발신자 기준 전사 스캔
해당 메일 일괄 삭제

피해 발생 가능성을 구조적으로 제거.

6) Cloud Custodian 기반 CSPM

S3 퍼블릭 탐지
정책 위반 실시간 알림
필요 시 자동 Remediation

별도 상용 CSPM 없이 운영 중.

7. 인사이트

이 프로젝트를 통해 느낀 점은 하나입니다.

보안은 사람이 다 할 수 없다.
자동화해야한다

SG 대시보드는
단순한 시각화 도구가 아닙니다.

운영 효율 개선
심사 대응력 향상
보안 신뢰도 강화
보안 문화 정착

자동화는 선택이 아니라
보안을 지속 가능하게 만드는 방법이었습니다.

'커뮤니티 및 교육 > AWSKRUG' 카테고리의 다른 글

[3/26] ARIA-gv 워크플로 세션 후기 (1)	2026.04.01
[3/26] No Edits, No Fiction: Security First, Security Last 세션 후기 (1)	2026.04.01
[2/12] Kiro 한국 사용자 모임 (0)	2026.02.15
[2/11] #container - re:Invent reCap: 컨테이너 서비스 후기 (0)	2026.02.12

개요