네트워크 보안

Alpacon의 네트워크 아키텍처는 보안을 최우선으로 설계되어, 서버 포트를 노출할 필요 없이 안전하고 신뢰할 수 있는 연결을 유지합니다.

아키텍처 개요

에이전트 기반 연결 모델

포트 22를 노출해야 하는 기존 SSH 접근과 달리, Alpacon은 에이전트 기반 아키텍처를 사용합니다:

기존 SSH:
인터넷 → 방화벽(포트 22) → 서버 (보안 위험) 🚨

Alpacon 아키텍처:
서버 (안전) → Alpamon 에이전트 (아웃바운드만) → 방화벽 → 인터넷 ✅

주요 이점:

• 인바운드 포트 없음: 서버가 들어오는 연결을 절대 수락하지 않음
• 아웃바운드만: Alpamon 에이전트가 모든 연결 시작
• 방화벽 친화적: 제한적인 방화벽 정책과 호환
• 제로 트러스트: 네트워크 위치가 접근 권한을 부여하지 않음

연결 흐름

1. 에이전트 초기화:

   • Alpamon 에이전트가 서버에서 시작
   • Alpacon 플랫폼으로 아웃바운드 WebSocket(WSS) 연결 설정
   • 워크스페이스 전용 토큰을 사용하여 인증
   • 하트비트로 지속적인 연결 유지

2. 사용자 연결:

   • 사용자가 Alpacon 플랫폼에 인증(웹 또는 CLI를 통해)
   • 서버 접근 요청(IAM 권한 확인)
   • 플랫폼이 기존 에이전트 채널을 통해 연결 라우팅
   • 종단간 암호화된 세션 설정

3. 데이터 전송:

   • 모든 데이터가 암호화된 WebSocket을 통해 흐름
   • 사용자와 서버 간 직접 연결 없음
   • 플랫폼이 안전한 릴레이 역할
   • 양쪽 끝에서 세션이 종료되면 연결 닫힘

네트워크 구성 요소

Alpamon 에이전트

서버에서 실행되는 에이전트:

기능:

• 경량: < 20MB 메모리 사용량
• 복원력: 지수 백오프로 자동 재연결
• 안전: 모든 데이터에 대한 종단간 암호화
• 최소 권한: 필요한 최소 권한으로 실행

네트워크 요구사항:

• <workspace>.<region>.alpacon.io로 아웃바운드 HTTPS(443)
• 지속적인 연결을 위한 아웃바운드 WSS(443)
• 선택사항: WebFTP 기능을 위해 S3로 아웃바운드 HTTPS(443)

프록시 지원:

# HTTP 프록시 구성
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
 
# 에이전트 재시작
sudo systemctl restart alpamon

암호화 및 프로토콜

전송 계층 보안(TLS)

모든 네트워크 통신은 TLS 1.2 이상을 사용합니다:

구성:

• 최소 버전: TLS 1.2
• 선호 버전: TLS 1.3
• 암호화 모음: 강력한 암호만 사용(AES-256-GCM, ChaCha20-Poly1305)
• Perfect Forward Secrecy: ECDHE 키 교환
• HSTS: Strict-Transport-Security 헤더 시행

Websh 프로토콜

터미널 세션은 WSS를 통해 Alpacon의 자체 개발 Websh 프로토콜을 사용합니다:

캡슐화:

터미널 데이터 (Websh)
  ↓
WebSocket 프레임 (WSS)
  ↓
TLS 1.3 암호화
  ↓
TCP/IP

아키텍처 이점:

• 게이트웨이 가시성: Alpacon Gateway가 컴플라이언스를 위해 모든 명령을 검사, 로깅 및 감사할 수 있음
• 실시간 모니터링: 보안 팀이 의심스러운 활동에 대해 활성 세션을 모니터링할 수 있음
• 정책 시행: 게이트웨이가 보안 정책을 시행(명령 차단, 승인 워크플로)
• 세션 기록: 컴플라이언스를 위한 선택적 기록(SOC 2, HIPAA, PCI-DSS)
• 암호화된 전송: 전송 중 TLS 1.3을 사용하여 데이터 암호화

종단간 암호화를 사용하지 않는 이유

기존의 종단간 암호화(직접 SSH와 같은)는 플랫폼이 트래픽을 검사하는 것을 방지하여 중요한 보안 및 컴플라이언스 기능을 제거합니다:

• ❌ 실제 실행된 명령의 감사 추적 없음
• ❌ 실시간 위협 탐지 없음
• ❌ 컴플라이언스를 위한 세션 기록 없음
• ❌ 위험한 명령을 차단할 수 없음
• ❌ SOC 2, HIPAA, PCI-DSS 요구사항 충족 어려움

Alpacon의 게이트웨이 기반 접근 방식은 전송 중 암호화를 유지하면서 포괄적인 감사 로깅을 가능하게 하여 보안과 컴플라이언스를 모두 제공합니다.

방화벽 구성

필수 아웃바운드 규칙(서버 측)

Alpamon 에이전트를 실행하는 서버의 경우:

필수 아웃바운드 규칙(클라이언트 측)

Alpacon에 접근하는 사용자(웹 브라우저 또는 CLI)의 경우:

IP 허용 목록

🚧 출시 예정 - 이 기능은 Essentials 플랜 이상에서 사용 가능할 예정입니다

IP 허용 목록을 통해 보안 강화를 위해 소스 IP 주소를 기반으로 접근을 제한할 수 있습니다:

계획된 기능

워크스페이스 수준 허용 목록:

• 특정 IP 범위(사무실 네트워크, VPN 게이트웨이 등)로 워크스페이스 접근 제한
• IPv4 및 IPv6 주소 모두 지원
• 유연한 IP 범위 구성을 위한 CIDR 표기법

서버 수준 허용 목록:

• 개별 서버에 IP 제한 적용
• 추가 보호가 필요한 프로덕션 데이터베이스 서버에 적합
• 서버별 워크스페이스 수준 설정 재정의

사용 사례:

• 워크스페이스에 대한 사무실 전용 접근
• 프로덕션 서버에 VPN 필수 접근
• 컴플라이언스를 위한 지리적 제한
• 파트너/벤더 접근 관리
• 애플리케이션 서버로만 프로덕션 데이터베이스 접근 제한

동적 IP 지원:

• 동적 IP 주소를 위한 CIDR 범위
• 단일 진입점으로서의 VPN 게이트웨이
• 긴급 접근을 위한 관리자 승인 비상 우회

일정: IP 허용 목록은 현재 개발 중입니다. 조직에서 이 기능이 필요한 경우 support@alpacax.com으로 문의하세요.

VPN 대체 전략

Alpacon은 기존 VPN의 필요성을 제거합니다:

VPN의 문제점

• 광범위한 접근: VPN은 모든 것에 대한 네트워크 수준 접근 권한 부여
• 성능: VPN은 지연 시간 및 처리량 오버헤드 추가
• 복잡성: 설정 및 유지 관리가 어려움
• 가시성: 제한된 감사 추적 및 모니터링
• 사용자 경험: 번거로운 연결 프로세스

Alpacon의 장점

• 제로 트러스트: 서버별, 사용자별 기준으로 접근 권한 부여
• 더 나은 성능: 직접 에이전트 연결, VPN 오버헤드 없음
• 더 간단한 설정: VPN 클라이언트 설치 불필요
• 완전한 가시성: 모든 접근에 대한 완전한 감사 추적
• 원활한 UX: 별도의 연결 없이 모든 브라우저에서 접근

보안 모범 사례

네트워크 관리자용

1. 공격 표면 최소화: 필수 서비스를 제외한 모든 인바운드 포트 차단
2. 네트워크 세분화: 서버를 별도의 네트워크 세그먼트로 격리
3. 트래픽 모니터링: 네트워크 모니터링 도구를 사용하여 이상 징후 감지
4. 정기 업데이트: Alpamon 에이전트를 최신 버전으로 유지
5. 방화벽 로그: 모든 방화벽 규칙에 대한 로깅 활성화

서버 관리자용

1. SSH 비활성화: Alpacon 배포 후 포트 22 차단
2. 에이전트 모니터링: 에이전트 상태 및 연결 모니터링
3. 프록시 구성: 필요 시 기업 프록시 사용
4. 로그 수집: 에이전트 로그를 중앙 로깅 시스템으로 전달

문제 해결

에이전트 연결 문제

증상: 에이전트가 “오프라인”으로 표시됨

가능한 원인:

• 아웃바운드 HTTPS/WSS를 차단하는 방화벽
• 잘못된 프록시 구성
• 네트워크 연결 문제
• 잘못된 에이전트 토큰

해결책:

# 에이전트 상태 확인
sudo systemctl status alpamon
 
# 연결 테스트
curl -v https://<workspace>.<region>.alpacon.io/health
 
# 에이전트 로그 확인
sudo journalctl -u alpamon -f

관련 문서

• 보안 개요 - 전반적인 보안 접근 방식
• 데이터 보안 - 데이터 보호 조치
• 인프라 설정 - 방화벽 구성
• 문제 해결 - 연결 문제 해결

문의

네트워크 보안 문의:

• 이메일: security@alpacax.com
• 네트워크 문제: support@alpacax.com

최종 업데이트: 2025년 11월