네트워크 보안
Alpacon은 아웃바운드 연결만 사용하는 에이전트를 통해 서버를 플랫폼에 연결합니다. Alpacon이 서버로 들어오는 연결을 만들지 않으므로, Alpacon 접근을 위해 열어야 하는 인바운드 포트는 없습니다. 서버가 자체 서비스에 쓰는 포트는 그대로 유지하면 됩니다. 이 문서에서는 연결이 동작하는 방식과 네트워크, 방화벽, 프록시를 구성하는 방법을 설명합니다.
전송 구간 암호화, 인증서 관리, 플랫폼 측 보호에 대해서는 플랫폼 보안 및 가용성을 참고하세요.
연결 모델
아웃바운드 전용 에이전트
기존 SSH 접근은 포트 22를 들어오는 연결에 노출해야 합니다. Alpacon은 그 반대로 동작합니다. 각 서버의 Alpamon 에이전트가 플랫폼으로 아웃바운드 연결을 열고, 모든 접근이 그 채널을 통해 되돌아옵니다.
기존 SSH:
인터넷 → 방화벽(인바운드 포트 22) → 서버
Alpacon:
서버 → Alpamon 에이전트(아웃바운드 전용) → 방화벽 → 플랫폼이렇게 얻는 이점:
- Alpacon용 인바운드 포트 불필요: 에이전트가 밖으로만 연결하며, Alpacon이 서버로 접속해 들어오지 않습니다.
- 아웃바운드 전용: Alpamon 에이전트가 모든 연결을 시작합니다.
- 방화벽 친화적: 제한적인 방화벽 정책이나 네트워크 주소 변환(NAT) 환경에서도 인바운드 허용 없이 동작합니다.
- 위치와 무관한 접근: 네트워크 위치만으로는 접근 권한이 생기지 않으며, 모든 세션이 인증과 권한 확인을 거칩니다.
연결이 설정되는 과정
- 에이전트 시작: Alpamon 에이전트가 서버에서 시작되어 워크스페이스 엔드포인트로 아웃바운드 연결을 열고, 서버 토큰으로 인증한 뒤 하트비트로 연결을 유지합니다.
- 사용자 연결: 웹 콘솔이나 CLI로 Alpacon에 로그인합니다. 서버를 열면 플랫폼이 권한을 확인한 뒤 에이전트의 기존 아웃바운드 채널을 통해 세션을 연결합니다.
- 세션 실행: 사용자와 서버 사이에 직접 연결은 없습니다. 플랫폼이 세션을 중계하며, 세션은 전송 구간에서 암호화됩니다. 어느 한쪽을 닫으면 세션이 종료됩니다.
에이전트 네트워크 요구사항
Alpamon 에이전트는 워크스페이스 엔드포인트로 아웃바운드 HTTPS와 WebSocket(WSS) 접근이 필요합니다. 호스트에서 수신 대기 포트를 열지 않습니다.
엔드포인트:
<workspace>.<region>.alpacon.io로 아웃바운드 HTTPS(443)- 지속 채널을 위한
<workspace>.<region>.alpacon.io로 아웃바운드 WSS(443)
리소스 사용량: 에이전트는 경량이며 보통 메모리 약 128MB, 디스크 약 150MB를 사용합니다. 네트워크가 끊기면 지수 백오프로 자동 재연결하고, 자신이 실행했던 세션에 다시 연결합니다.
프록시 지원:
# HTTP 프록시 구성
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
# SOCKS 프록시 구성
export ALL_PROXY=socks5://proxy.company.com:1080
# 적용을 위해 에이전트 재시작
sudo systemctl restart alpamon방화벽 구성
필수 아웃바운드 규칙(서버 측)
Alpamon 에이전트를 실행하는 서버의 경우:
| 프로토콜 | 포트 | 대상 | 목적 |
|---|---|---|---|
| HTTPS | 443 | <workspace>.<region>.alpacon.io | 에이전트 연결 |
| WSS | 443 | <workspace>.<region>.alpacon.io | 지속 채널 |
| HTTPS | 443 | api.github.com | 에이전트 버전 확인 |
| HTTPS | 443 | github.com, release-assets.githubusercontent.com | 에이전트 설치 및 자동 업데이트 |
| HTTPS | 443 | *.amazonaws.com (S3) | WebFTP 파일 전송(선택) |
일부 선택 기능은 추가 엔드포인트에 접근합니다. 브라우저 내장 코드 편집기는 처음 사용할 때 code-server.dev와 open-vsx.org에서 내려받고, Linux 패키지 설치는 packagecloud.io를 사용합니다. 해당 기능을 쓰는 경우에만 허용하세요.
iptables 예시:
# 워크스페이스로 아웃바운드 HTTPS 허용
iptables -A OUTPUT -p tcp --dport 443 -d <workspace-ip> -j ACCEPT
# 설정된 연결의 응답 허용
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# 그 외 모든 인바운드 차단
iptables -A INPUT -j DROP필수 아웃바운드 규칙(클라이언트 측)
웹 브라우저나 CLI로 Alpacon에 접근하는 사용자의 경우:
| 프로토콜 | 포트 | 대상 | 목적 |
|---|---|---|---|
| HTTPS | 443 | alpacon.io | 메인 애플리케이션 |
| HTTPS | 443 | <workspace>.<region>.alpacon.io | 워크스페이스 접근 |
| HTTPS | 443 | auth.alpacon.io | 인증 |
| WSS | 443 | <workspace>.<region>.alpacon.io | 터미널 세션 |
기업 방화벽과 프록시
Alpacon은 기업 프록시 뒤에서도 동작합니다.
지원하는 구성:
- HTTP/HTTPS 프록시: CONNECT 메서드를 사용하는 표준 프록시
- SOCKS 프록시: SOCKS4 및 SOCKS5
- 인증 프록시: 사용자 이름과 비밀번호 인증
- 프록시 자동 구성(PAC): 자동 프록시 구성
프록시 우회:
# 로컬 네트워크는 프록시 우회
export NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,192.168.0.0/16IP 허용 목록
🚧 출시 예정 - Essentials 플랜 이상을 대상으로 준비 중입니다.
IP 허용 목록을 사용하면 출발지 IP 주소를 기준으로 접근을 제한해 통제를 강화할 수 있습니다.
워크스페이스 수준 허용 목록:
- 사무실 네트워크나 VPN 게이트웨이 같은 특정 IP 범위로 워크스페이스 접근 제한
- IPv4 및 IPv6 주소 지원
- 유연한 범위 설정을 위한 CIDR 표기법
서버 수준 허용 목록:
- 개별 서버에 IP 제한 적용
- 추가 보호가 필요한 프로덕션 데이터베이스에 유용
- 서버별로 워크스페이스 수준 설정 재정의
사용 사례:
- 워크스페이스에 대한 사무실 전용 접근
- 프로덕션 서버에 대한 VPN 게이트웨이 전용 접근
- 컴플라이언스를 위한 지리적 제한
- 파트너 및 벤더 접근 관리
- 프로덕션 데이터베이스를 애플리케이션 서버로만 제한
지금 이 기능이 필요하신가요? support@alpacax.com으로 요구사항을 알려주세요.
프로그래밍 방식 접근은 토큰 단위로 이미 제한할 수 있습니다. 서비스 토큰은 IP 허용 목록과 요청 속도 제한을 지원합니다. 서비스 토큰을 참고하세요.
VPN에서 이전하기
접근 권한이 네트워크 수준이 아니라 사용자별, 서버별로 부여되기 때문에, 서버 접근만을 위해 두었던 VPN을 정리하는 팀이 많습니다. 단계적으로 전환하면 확신이 설 때까지 대체 수단을 유지할 수 있습니다.
- 병행 운영: 기존 VPN을 비상 접근용으로 유지하면서 서버에 Alpacon을 배포하고, 팀이 익숙해지도록 합니다.
- 점진적 이전: 중요도가 낮은 서버부터 옮기고, 이어서 팀을 하나씩 이전하면서 사용 현황과 피드백을 확인합니다.
- VPN 정리: 워크스테이션에서 VPN 클라이언트를 제거하고 방화벽 규칙을 닫습니다. 일정 기간 동안은 인프라를 대체 수단으로 남겨 둡니다.
- 전환 완료: VPN 인프라를 폐기하고 네트워크 문서를 갱신합니다.
모범 사례
네트워크 관리자용
- 공격 표면 최소화: 필수 서비스를 제외한 모든 인바운드 포트를 차단합니다.
- 네트워크 분리: 서버를 별도의 네트워크 세그먼트로 격리합니다.
- 트래픽 모니터링: 네트워크 모니터링으로 이상 징후를 감지합니다.
- 에이전트 최신 유지: Alpamon을 최신 버전으로 유지합니다.
- 방화벽 로그: 방화벽 규칙에 로깅을 활성화합니다.
서버 관리자용
- SSH 차단: Alpacon 배포 후 포트 22를 차단합니다.
- 에이전트 모니터링: 에이전트 상태와 연결을 확인합니다.
- 프록시 사용: 필요한 경우 기업 프록시를 구성합니다.
- 로그 집중화: 에이전트 로그를 중앙 로깅 시스템으로 전달합니다.
문제 해결
에이전트가 오프라인으로 표시됩니다
가능한 원인:
- 아웃바운드 HTTPS 또는 WSS를 차단하는 방화벽
- 잘못된 프록시 구성
- 네트워크 연결 문제
- 잘못된 에이전트 토큰
확인 방법:
# 에이전트 상태
sudo systemctl status alpamon
# 워크스페이스 연결 확인
curl -v https://<workspace>.<region>.alpacon.io/health
# 에이전트 로그
sudo journalctl -u alpamon -f
# 프록시를 통한 테스트
export HTTPS_PROXY=http://proxy:8080
curl -v https://<workspace>.<region>.alpacon.io/health터미널 응답이 느립니다
가능한 원인:
- 워크스페이스 리전과의 지리적 거리
- 네트워크 혼잡
- 프록시 성능
시도해 볼 것:
- 워크스페이스를 만들 때 가장 가까운 리전을 선택합니다.
- 가능하면 Alpacon 엔드포인트에 대해 프록시를 우회합니다.
traceroute로 네트워크 경로를 확인합니다.- 서버 자체의 리소스 사용량을 점검합니다.
관련 문서
- 플랫폼 보안 및 가용성 - 전송 구간 암호화, 인증서, 플랫폼 보호
- 보안 개요 - 전반적인 보안 접근 방식
- 데이터 보안 - 데이터 보호 조치
- 연결 문제 해결 - 연결 끊김·세션 실패 진단
문의
네트워크 구성 관련 도움: