[Cloudflare 완전 정복: 입문부터 2026 AI 에이전트까지] 6/16화: Cloudflare Zero Trust Access 설정: 재택근무 보안 완전 가이드

Cloudflare Access 핵심 개념 3가지

실습에 들어가기 전에 꼭 알아야 할 세 가지 개념을 정리합니다.

1. 애플리케이션(Application)

보호할 대상입니다. NAS 관리자 페이지, Grafana 대시보드, 내부 위키 등 URL 단위로 하나의 애플리케이션을 정의합니다. nas.example.com이면 하나, grafana.example.com이면 또 하나입니다.

2. 정책(Policy)

누가 들어올 수 있는지를 규칙으로 정의합니다. “Gmail이 @example.com인 사람만 허용”, “GitHub 조직 멤버만 허용”, “특정 국가에서만 허용” 같은 조건을 조합할 수 있습니다.

3. 인증 수단(Identity Provider, IdP)

사용자가 자신을 증명하는 방법입니다. Cloudflare Access는 자체 비밀번호 DB를 갖지 않습니다. 대신 Google, GitHub, Microsoft, Okta 같은 외부 인증 제공자에 인증을 위임합니다. 가장 간편한 것은 이메일 OTP — 이메일 주소를 입력하면 일회용 코드가 날아오고, 그걸 입력하면 끝입니다.

사전 준비: 5화의 터널이 살아 있어야 합니다

이번 실습은 5화에서 만든 Cloudflare Tunnel 위에 Access 정책을 얹는 구조입니다. 아직 터널을 설정하지 않았다면 5화를 먼저 따라해 주세요. 최소 요건은 다음과 같습니다.

• Cloudflare에 등록된 도메인 1개 (예: example.com)
• cloudflared 데몬이 Synology NAS 또는 Mac Studio에서 실행 중
• 터널을 통해 하나 이상의 서비스가 외부에 공개된 상태 (예: nas.example.com → NAS DSM 5000번 포트)

Step 1: Zero Trust 대시보드 진입

Cloudflare 대시보드에서 일반 DNS/캐시 설정과 Zero Trust 설정은 입구가 다릅니다. 처음 방문하면 헷갈리기 쉬우니 정확한 경로를 안내합니다.

1. one.dash.cloudflare.com에 접속합니다.
2. 왼쪽 메뉴에서 Access → Applications를 클릭합니다.
3. 처음이라면 팀 이름(예: myhomelabteam)을 설정하라는 안내가 나옵니다. 이 이름은 로그인 URL에 포함됩니다: myhomelabteam.cloudflareaccess.com

팀 이름은 나중에 바꿀 수 있지만, 짧고 기억하기 쉬운 것으로 정하세요. 이 URL을 북마크해두면 모든 보호된 서비스의 로그인 상태를 한 곳에서 관리할 수 있습니다.

Step 2: 인증 수단(IdP) 설정 — Google·GitHub·OTP

Access 정책을 만들기 전에 “사용자가 어떤 방법으로 로그인할 것인가”를 먼저 정해야 합니다. Zero Trust 대시보드 → Settings → Authentication에서 설정합니다.

방법 A: 이메일 OTP (가장 간편, 기본 제공)

별도 설정이 필요 없습니다. Cloudflare가 기본으로 One-time PIN을 제공합니다. 사용자가 이메일을 입력하면 6자리 코드가 발송되고, 이를 입력하면 인증 완료. 외부 IdP 연동이 번거로운 개인 사용자에게 가장 추천하는 방법입니다.

방법 B: Google 계정 연동

Google OAuth를 사용하면 “Google로 로그인” 버튼이 Access 로그인 화면에 나타납니다. 설정 절차:

1. Google Cloud Console → APIs & Services → Credentials로 이동
2. OAuth 2.0 Client ID를 생성합니다. 애플리케이션 유형은 Web application.
3. 승인된 리디렉션 URI에 다음을 추가합니다:

https://myhomelabteam.cloudflareaccess.com/cdn-cgi/access/callback

myhomelabteam 부분을 본인의 팀 이름으로 바꾸세요.

4. 생성된 Client ID와 Client Secret을 복사합니다.
5. Cloudflare Zero Trust 대시보드 → Settings → Authentication → Add new → Google 선택 후 Client ID와 Secret을 붙여넣습니다.
6. Test 버튼으로 연동을 확인합니다.

방법 C: GitHub 계정 연동

개발자라면 GitHub이 더 자연스러울 수 있습니다. 특히 GitHub Organization 멤버십으로 접근 제어를 하고 싶다면 이 방법이 유리합니다.

1. GitHub → Settings → Developer settings → OAuth Apps로 이동
2. New OAuth App을 클릭합니다.
3. 필드를 채웁니다:

• Application name: Cloudflare Access (자유)
• Homepage URL: https://myhomelabteam.cloudflareaccess.com
• Authorization callback URL: https://myhomelabteam.cloudflareaccess.com/cdn-cgi/access/callback

4. 생성된 Client ID와 Client Secret을 Cloudflare Zero Trust 대시보드에 입력합니다.

팁: 여러 IdP를 동시에 활성화할 수 있습니다. 로그인 화면에 “Google로 로그인”, “GitHub으로 로그인”, “이메일 OTP” 버튼이 모두 표시됩니다. 가족이나 팀원에 따라 편한 방법을 선택하게 해주면 됩니다.

Step 3: 첫 번째 Access 애플리케이션 — NAS DSM 보호하기

이제 본격적으로 Synology NAS 관리자 페이지(DSM)에 Access 보호를 씌워 보겠습니다. 5화에서 nas.example.com으로 DSM을 터널로 공개한 상태라고 가정합니다.

대시보드에서 설정하기

1. Zero Trust 대시보드 → Access → Applications → Add an application
2. 유형은 Self-hosted를 선택합니다.
3. 기본 정보를 입력합니다:

• Application name: Synology NAS
• Session Duration: 24 hours (하루에 한 번만 로그인)
• Application domain: nas.example.com

4. Next를 눌러 정책 설정으로 넘어갑니다.
5. 정책 이름: Allow family
6. Action: Allow
7. Include 규칙에 조건 추가:

• Selector: Emails
• Value: 허용할 이메일 주소를 입력 (예: [email protected], [email protected])

8. Save를 누르면 즉시 적용됩니다.

이제 nas.example.com에 접속하면 Cloudflare 로그인 화면이 먼저 나타납니다. 등록한 이메일로 인증해야만 NAS DSM에 도달할 수 있습니다.

cloudflared CLI로 설정하기 (Synology NAS SSH 접속)

대시보드 UI 대신 터미널에서 설정하는 것을 선호한다면 cloudflared 터널 설정 파일에 access 정책을 연결할 수도 있습니다. 다만 Access 애플리케이션과 정책 자체는 API 또는 Terraform으로 관리하는 것이 일반적입니다. 실습에서는 대시보드 설정을 권장하되, 자동화가 필요한 분을 위해 API 호출 예시를 남깁니다.

Synology NAS에 SSH로 접속한 뒤 다음을 실행하세요:

# Cloudflare API 토큰이 필요합니다 (Zero Trust 편집 권한 포함)
export CF_API_TOKEN="your-api-token-here"
export CF_ACCOUNT_ID="your-account-id"

# Access 애플리케이션 목록 조회
curl -s -H "Authorization: Bearer $CF_API_TOKEN" \
  "https://api.cloudflare.com/client/v4/accounts/$CF_ACCOUNT_ID/access/apps" \
  | python3 -m json.tool

API를 통한 전체 CRUD는 Cloudflare 공식 문서의 Access API 섹션을 참조하세요. 대부분의 홈랩 사용자에게는 대시보드 설정으로 충분합니다.

Step 4: 정책을 정교하게 — 다양한 규칙 조합

이메일 허용만으로는 단순합니다. 실무에서는 여러 조건을 조합해 더 정밀한 접근 제어를 구성합니다.

이메일 도메인으로 팀 전체 허용

회사 도메인이 @mycompany.com이라면:

• Selector: Emails ending in
• Value: @mycompany.com

이 한 줄이면 @mycompany.com 메일을 가진 모든 직원이 접속할 수 있습니다. 퇴사자의 Google Workspace 계정이 비활성화되면 자동으로 접근도 차단됩니다.

GitHub 조직 멤버만 허용

• Selector: GitHub Organizations
• Value: my-org-name

오픈소스 프로젝트의 내부 도구를 팀원에게만 공개할 때 유용합니다.

국가 제한 추가 (Require 규칙)

정책에는 Include(OR 조건), Require(AND 조건), Exclude(차단) 세 가지 규칙 그룹이 있습니다.

• Include: 이 중 하나라도 만족하면 통과 후보 (OR)
• Require: 반드시 모두 만족해야 함 (AND)
• Exclude: 하나라도 해당되면 무조건 차단

예를 들어 “한국에서만 접속 가능한 가족 전용 NAS”를 만들려면:

• Include: Emails = [email protected], [email protected]
• Require: Country = South Korea

이렇게 하면 등록된 이메일로 인증하더라도 한국 밖에서는 접속이 차단됩니다. 해외 여행 중 접속이 필요하면 정책에서 국가 조건을 일시적으로 해제하면 됩니다.

Bypass 정책 — 특정 경로 열어두기

헬스체크나 API 콜백처럼 인증 없이 접근해야 하는 경로가 있을 수 있습니다. 이때 Bypass 정책을 별도로 만듭니다:

• Action: Bypass
• Include: Everyone
• 추가 설정: Path에 /api/health 지정

정책 평가는 위에서 아래 순서로 이루어집니다. Bypass 정책을 맨 위에 두면 해당 경로는 인증을 건너뛰고, 나머지 경로는 Allow 정책을 통해 인증을 거칩니다.

Step 5: 여러 서비스를 한번에 보호하기

홈랩에 NAS만 있는 건 아닙니다. Grafana, Home Assistant, Jellyfin, Portainer, VS Code Server… 서비스마다 서브도메인을 하나씩 할당했다면 각각에 Access 애플리케이션을 만들 수도 있지만, 와일드카드를 활용하면 훨씬 간편합니다.

와일드카드 애플리케이션

Application domain에 *.example.com을 입력하면 모든 서브도메인에 동일한 Access 정책이 적용됩니다.

• nas.example.com → 보호됨
• grafana.example.com → 보호됨
• jellyfin.example.com → 보호됨

주의: 와일드카드 애플리케이션과 개별 서브도메인 애플리케이션이 동시에 존재하면, 더 구체적인 규칙이 우선합니다. 예를 들어 Jellyfin은 가족 전체에게 열어두고 싶다면:

1. *.example.com → 본인 이메일만 Allow (엄격)
2. jellyfin.example.com → 가족 이메일 전체 Allow (느슨)

이렇게 하면 Jellyfin만 별도 정책을 적용받고, 나머지는 와일드카드 정책을 따릅니다.

Access Group으로 정책 재사용하기

여러 애플리케이션에 같은 사용자 그룹을 반복 지정하는 건 번거롭습니다. Access Group을 만들면 한 번 정의한 그룹을 여러 정책에서 참조할 수 있습니다.

1. Zero Trust 대시보드 → Access → Access Groups → Create a group
2. 그룹 이름: Family
3. Include: Emails = [email protected], [email protected], [email protected]
4. 저장 후, 각 애플리케이션 정책에서 Selector를 Access Groups로 바꾸고 Family를 선택

가족 구성원이 바뀌면 그룹만 수정하면 모든 애플리케이션에 일괄 반영됩니다.

Step 6: Service Token — 사람이 아닌 시스템의 접근

모든 접근이 사람이 하는 건 아닙니다. 모니터링 봇이 NAS 상태를 체크하거나, CI/CD 파이프라인이 내부 API를 호출할 수도 있습니다. 이런 기계 대 기계(M2M) 통신에는 Service Token을 사용합니다.

Service Token 만들기

1. Zero Trust 대시보드 → Access → Service Auth → Create Service Token
2. 토큰 이름: monitoring-bot
3. 기간: 1 year (또는 Non-expiring — 보안상 유한 기간 권장)
4. Generate token을 클릭하면 Client ID와 Client Secret이 표시됩니다.

중요: Client Secret은 이 순간에만 볼 수 있습니다. 반드시 안전한 곳에 저장하세요.

Service Token으로 접근하기

HTTP 요청에 두 개의 헤더를 추가하면 Access 인증을 통과할 수 있습니다:

# Service Token을 이용한 API 호출 예시
curl -H "CF-Access-Client-Id: your-client-id.access" \
     -H "CF-Access-Client-Secret: your-client-secret" \
     https://nas.example.com/api/health

정책에 Service Token 규칙 추가

해당 애플리케이션의 정책에 Service Token 허용 규칙을 추가해야 합니다:

• 새 정책 생성: 이름 Allow monitoring bot
• Action: Service Auth
• Include: Selector = Service Token, Value = monitoring-bot

이 정책은 해당 Service Token을 가진 요청만 통과시킵니다. 사람 사용자의 정책과 분리되므로, 봇의 접근 범위를 독립적으로 관리할 수 있습니다.

Step 7: 브라우저에서 SSH·VNC 접속하기

Cloudflare Access의 숨은 강점 중 하나가 Browser Rendering입니다. SSH나 VNC 클라이언트를 설치할 필요 없이, 웹 브라우저에서 바로 터미널을 열거나 원격 데스크톱에 접속할 수 있습니다.

SSH 브라우저 렌더링 설정

1. 5화에서 만든 터널에 SSH 서비스를 추가합니다. 터널 설정(대시보드 또는 config 파일)에서:

# config.yml 예시 (cloudflared 터널 설정)
ingress:
  - hostname: ssh.example.com
    service: ssh://localhost:22
  - hostname: nas.example.com
    service: http://localhost:5000
  - service: http_status:404

2. Access 애플리케이션을 만들 때 Application domain에 ssh.example.com을 지정합니다.
3. 설정 하단의 Additional settings에서 Browser rendering을 SSH로 선택합니다.
4. 정책을 설정하고 저장합니다.

이제 ssh.example.com에 브라우저로 접속하면, Access 로그인을 거친 후 웹 기반 터미널이 열립니다. PuTTY나 터미널 앱 없이도 NAS에 SSH 접속이 가능합니다. 카페에서 아이패드로 서버 점검해야 할 때 특히 유용합니다.

VNC 브라우저 렌더링 설정

VNC도 동일한 패턴입니다:

# config.yml에 VNC 서비스 추가
ingress:
  - hostname: vnc.example.com
    service: tcp://localhost:5900
  - hostname: ssh.example.com
    service: ssh://localhost:22
  - hostname: nas.example.com
    service: http://localhost:5000
  - service: http_status:404

Access 애플리케이션에서 Browser rendering을 VNC로 설정하면 브라우저에서 원격 데스크톱이 열립니다.

Synology NAS 실전 — 전체 설정 재현

여기까지의 내용을 Synology NAS DS+925에서 처음부터 끝까지 재현해 보겠습니다. 5화에서 cloudflared Docker 컨테이너가 이미 돌고 있다고 가정합니다.

1단계: 터널에 서비스 매핑 확인

Synology NAS에 SSH로 접속합니다:

# SSH 접속 (Synology DSM → 제어판 → 터미널 및 SNMP에서 SSH 활성화)
ssh [email protected]

# cloudflared 컨테이너 상태 확인
sudo docker ps | grep cloudflared

# 터널 상태 확인
sudo docker exec cloudflared cloudflared tunnel info

2단계: Zero Trust 대시보드에서 Access 설정

대시보드 조작은 웹 UI에서 진행합니다. 위의 Step 1~5를 순서대로 따릅니다:

1. one.dash.cloudflare.com 접속
2. 팀 이름 설정 (최초 1회)
3. IdP 추가 (OTP는 기본 제공, Google/GitHub은 선택)
4. 애플리케이션 추가: nas.example.com → Self-hosted
5. 정책 추가: Allow, Emails = 허용할 주소

3단계: 접속 테스트

# 터미널에서 테스트 (Access 로그인 화면이 나오는지 확인)
curl -I https://nas.example.com

# 예상 응답: HTTP/1.1 302 Found
# Location: https://myhomelabteam.cloudflareaccess.com/cdn-cgi/access/login/nas.example.com?...

302 리다이렉트가 Cloudflare 로그인 페이지로 향하면 정상입니다. 브라우저에서 접속하면 로그인 화면이 표시되고, 인증 후 NAS DSM에 도달합니다.

4단계: Mac Studio에서 cloudflared로 터널 인증 없이 접속

집 안의 Mac Studio에서 Access를 거치지 않고 직접 NAS에 접속하고 싶다면, cloudflared access 명령으로 로컬 프록시를 띄울 수 있습니다:

# Mac Studio 터미널에서 실행
cloudflared access tcp --hostname ssh.example.com --url localhost:2222

# 다른 터미널에서 SSH 접속
ssh -p 2222 admin@localhost

이 방법은 cloudflared가 Access 인증을 브라우저 팝업으로 처리한 뒤 로컬 포트로 트래픽을 중계합니다. 한 번 인증하면 세션이 유지되므로 반복 로그인이 필요 없습니다.

실전 시나리오: 재택근무 보안 포털 구성

가정이 아닌 실무에서 Zero Trust Access를 어떻게 활용하는지 시나리오를 하나 그려 보겠습니다.

시나리오: 5인 스타트업의 내부 도구 보호

사무실 NAS에 다음 서비스가 돌고 있습니다:

• wiki.company.com — 사내 위키 (Outline)
• git.company.com — Gitea 코드 저장소
• monitor.company.com — Grafana 모니터링
• admin.company.com — NAS 관리자 (DSM)

Access 설정 전략

이 구성의 장점:

• VPN 없이 재택근무: 직원은 집에서 wiki.company.com을 열고 Google 계정으로 로그인하면 끝.
• 퇴사 즉시 차단: Google Workspace에서 계정을 비활성화하면 Access 인증도 실패.
• 역할 기반 접근: Grafana는 DevOps 그룹에게만, NAS 관리자는 CTO에게만.
• 감사 로그: 누가 언제 어떤 서비스에 접속했는지 Zero Trust 대시보드에서 확인 가능.

App Launcher — 나만의 사설 포털 만들기

Access로 보호된 서비스가 여러 개면 URL을 일일이 기억하기 번거롭습니다. Cloudflare는 App Launcher라는 간이 포털 페이지를 제공합니다.

App Launcher 활성화

1. Zero Trust 대시보드 → Settings → Authentication
2. App Launcher 섹션에서 Manage 클릭
3. 정책 추가: 포털에 접근할 수 있는 사용자를 정의 (예: @company.com)
4. 저장하면 myhomelabteam.cloudflareaccess.com에 접속했을 때 보호된 앱 목록이 타일 형태로 표시됩니다.

각 Access 애플리케이션 설정에서 App Launcher visibility를 켜면 해당 앱이 포털에 나타납니다. 로고와 이름을 커스터마이즈할 수도 있습니다.

이것이 바로 “비밀번호 없는 사설 포털”의 완성입니다. 별도의 SSO 솔루션을 구축하거나 비밀번호 DB를 관리할 필요 없이, Google/GitHub 같은 기존 계정으로 모든 내부 서비스에 접근하는 통합 입구가 만들어졌습니다.

보안 강화: 디바이스 포스처 확인

Zero Trust의 “Trust”에는 사용자뿐 아니라 디바이스도 포함됩니다. Cloudflare WARP 클라이언트를 설치한 디바이스인지, 디스크 암호화가 켜져 있는지, OS 버전이 최신인지 등을 Device Posture 정책으로 확인할 수 있습니다.

Device Posture 규칙 예시

• WARP 클라이언트 설치 여부: WARP가 설치된 디바이스만 접근 허용
• 디스크 암호화: FileVault(macOS) 또는 BitLocker(Windows) 활성화 확인
• OS 최소 버전: macOS 15 이상, Windows 11 이상만 허용
• 방화벽 활성화: OS 방화벽이 켜져 있는지 확인

이 기능을 활용하면 “올바른 사람이 올바른 디바이스에서 접속”하는 것까지 보장할 수 있습니다. 다만 무료 플랜에서는 기본적인 WARP 확인만 가능하고, 디스크 암호화·OS 버전 같은 고급 체크는 유료 플랜(Teams Standard 이상)에서 지원합니다.

트러블슈팅 — 자주 발생하는 문제와 해결

문제 1: Access 로그인 후 “403 Forbidden”이 뜬다

원인: 정책의 Include 조건에 내 이메일이 빠져 있거나, Require 조건(예: 국가 제한)에 걸린 경우.

해결: Zero Trust 대시보드 → Access → Logs에서 차단된 요청의 상세 사유를 확인합니다. “Policy decision: Deny” 옆에 어떤 규칙이 매치되지 않았는지 표시됩니다.

문제 2: Access 로그인 화면이 안 뜨고 바로 서비스에 접속된다

원인: DNS 레코드가 Cloudflare 프록시를 거치지 않는 상태(회색 구름 아이콘). Access는 Cloudflare 프록시를 경유해야만 동작합니다.

해결: Cloudflare DNS 대시보드에서 해당 레코드의 프록시 상태를 주황색 구름(Proxied)으로 전환합니다.

문제 3: OTP 이메일이 도착하지 않는다

원인: 스팸 폴더에 들어갔거나, 이메일 제공자가 Cloudflare 발신을 차단한 경우.

해결: 스팸 폴더를 확인하세요. Gmail 사용자라면 거의 문제없지만, 회사 메일 서버를 쓰는 경우 [email protected]을 허용 목록에 추가하세요.

문제 4: 세션이 너무 빨리 만료된다

원인: 기본 Session Duration이 짧게 설정된 경우.

해결: 애플리케이션 설정에서 Session Duration을 24시간이나 1주일로 늘립니다. 홈랩 용도라면 1 month도 합리적입니다.

문제 5: 특정 서브 경로만 보호하고 싶다

원인: nas.example.com 전체가 아닌 nas.example.com/admin만 보호하고 싶은 경우.

해결: 애플리케이션 설정에서 Path 필드에 /admin을 지정합니다. 루트 경로는 인증 없이 접근 가능하고, /admin 이하만 Access 로그인을 요구합니다.

Access 감사 로그 활용하기

보안은 차단만으로 끝나지 않습니다. “누가 언제 어디에 접속했는지”를 사후에 확인할 수 있어야 합니다.

Zero Trust 대시보드 → Logs → Access에서 다음 정보를 확인할 수 있습니다:

• 사용자 이메일: 누가 접속했는지
• 접속 시각: 언제 접속했는지
• 애플리케이션: 어떤 서비스에 접속했는지
• 판정 결과: Allow / Deny
• IP 주소: 어디에서 접속했는지
• 국가: 접속 국가
• 인증 수단: Google / GitHub / OTP 중 무엇으로 인증했는지

무료 플랜에서도 최근 24시간의 로그를 확인할 수 있습니다. 이상 접근이 감지되면 해당 사용자를 Access → Active Sessions에서 즉시 세션 해지(Revoke)할 수도 있습니다.

월 비용 명세표

핵심: 50명 이하의 홈랩·소규모 팀이라면 완전 무료입니다. Tunnel도 무료, Access도 무료, App Launcher도 무료. 별도 VPN 서버를 구축하거나 유지보수하는 비용을 생각하면 상당한 절약입니다.

정리: 5화 터널 + 6화 Access = 완전한 홈랩 보안

5화의 Cloudflare Tunnel과 6화의 Zero Trust Access를 조합하면 다음과 같은 아키텍처가 완성됩니다:

• 인바운드 포트 제로: 공유기 포트포워딩 없음. 외부에서 집 IP를 직접 때릴 수 없음.
• 인증 관문: 모든 접속은 Cloudflare의 글로벌 네트워크에서 신원 확인을 거침.
• 암호화: 클라이언트 → Cloudflare (TLS) → Tunnel (자체 암호화) → 로컬 서비스. 전 구간 암호화.
• 감사 추적: 누가 언제 어디에 접속했는지 로그로 확인 가능.
• 비용: 0원.

전통적인 VPN을 구축하면 서버 유지비, 인증서 관리, 클라이언트 배포, 접속 장애 대응… 끝없는 운영 부담이 따라옵니다. Zero Trust Access는 이 모든 것을 Cloudflare에 위임합니다. 특히 가족이나 비기술 팀원에게 “Google로 로그인하세요”라고 안내하면 끝이라는 점이, VPN 클라이언트 설치를 요구하는 것과는 차원이 다른 사용자 경험입니다.

다음 7화에서는 클라이언트 측 보안의 완성편인 1.1.1.1과 WARP VPN을 다룹니다. DNS 수준에서 광고·악성 사이트를 차단하고, 공용 Wi-Fi에서도 안전하게 인터넷을 쓰는 방법을 알아보겠습니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.