1433 포트 포워딩을 피해야 하는 이유
사무실에 SQL Server가 있습니다. 그 네트워크 밖의 누군가 — 원격 분석가, 클라우드 리포팅 도구, 팀이 만들고 싶은 앱 — 가 그 데이터를 읽어야 합니다. 누구나 먼저 제안하는 빠른 방법은 라우터에서 TCP 1433 포트를 DB 서버로 포워딩하고 방화벽에서 허용하는 것입니다.
작동하고, 빠릅니다. 그리고 거의 모든 보안 담당자가 하지 말라고 하는 방법이기도 합니다.
- 로그인 화면이 공개됩니다. 인터넷의 무엇이든 SQL Server에 닿아 인증을 시도할 수 있습니다. 자동 스캐너는 하루 종일 열린 1433 포트를 찾고,
sa같은 계정에 비밀번호 목록을 대입합니다. - 데이터베이스가 곧 경계가 됩니다. 미뤄 둔 패치와 약한 SQL 로그인이 모두 외부에서 닿는 곳에 놓입니다.
- IP 제한은 도움이 되지만 취약합니다. 1433을 벤더 IP로만 제한하면 노출은 줄지만, IP는 바뀌고 누군가는 목록을 계속 관리해야 합니다.
정말 원하는 건 인바운드 포트 없이 외부에서 그 DB를 읽게 하는 것입니다. 방법은 네 가지입니다.
방법 1: VPN
VPN은 외부의 상대를 네트워크 '안'으로 들입니다. 클라이언트 VPN은 개인 노트북을 연결하고, 사이트 간 VPN은 두 네트워크를 상시 연결합니다.
사람에게 적합. SQL Server Management Studio가 필요한 원격 회계 담당자가 바로 VPN이 상정한 경우입니다.
SaaS 도구에는 부적합. 대부분의 클라우드 서비스는 우리 VPN에 들어올 수 없습니다. 또 VPN 게이트웨이 자체가 보통 인바운드 포트에서 대기하므로, 노출된 DB를 (훨씬 잘 방어된) 노출된 VPN 엔드포인트로 바꾸는 셈입니다.
방법 2: 배스천 호스트를 통한 SSH 터널
많은 클라우드 도구가 'SSH 터널로 연결'을 지원합니다. 도구가 SSH로 접속할 작은 리눅스 머신(배스천)을 두고, SQL Server로 가는 트래픽을 그 세션으로 흘려보냅니다.
지원하는 도구가 많고, 키 기반 SSH는 잘 알려지고 검증된 프로토콜입니다.
걸리는 점: 여전히 인바운드 포트(보통 22)를 인터넷이나 벤더 IP에 열어야 하고, 그 머신의 패치와 모니터링도 맡아야 합니다. 공인 주소가 없는 사무실에는 잘 맞지 않습니다. 배스천이 외부에서 접근 가능해야 하기 때문입니다.
방법 3: 아웃바운드 터널 (Cloudflare Tunnel, ngrok, Tailscale)
아웃바운드 터널은 방향을 뒤집습니다. 네트워크 안쪽의 작은 프로세스가 바깥으로 연결하고, 트래픽은 그 아웃바운드 연결을 타고 돌아옵니다.
- Cloudflare Tunnel은 내부에서
cloudflared를 실행해 Cloudflare로 나가는 연결만 맺고, 접근은 액세스 정책으로 제어합니다. - ngrok은 아웃바운드 연결을 열고 로컬 서비스로 전달하는 공개 엔드포인트를 줍니다. 테스트에는 편하지만, 접근 제어를 붙이지 않으면 그 엔드포인트는 인터넷에서 닿습니다.
- Tailscale은 등록한 기기끼리 WireGuard 사설망을 만듭니다. 네트워크 멤버만 SQL Server에 닿습니다.
인바운드 규칙도 공인 IP도 필요 없음. 둘 다 없는 사무실에서도 작동합니다.
다만 DB가 아니라 네트워크 접근입니다. 터널에 닿은 것은 그 로그인의 권한으로 SQL Server와 대화합니다. 정책, 로그인, 모니터링은 여전히 우리 몫입니다. 그리고 반대편 SaaS 도구가 터널을 쓸 수 있어야 하는데, 못 쓰는 도구가 많습니다.
방법 4: 바깥으로 연결하는 벤더 에이전트
이 용도로 자체 에이전트를 제공하는 제품도 있습니다. DB가 보이는 머신에 설치하면 벤더 클라우드로 아웃바운드 연결을 맺고, 제품은 그 연결로 쿼리를 보냅니다.
- Microsoft 온프레미스 데이터 게이트웨이가 가장 유명합니다. Windows에서 실행되고 Azure로 아웃바운드 연결을 맺으며 Power BI, Power Apps, Power Automate, Logic Apps를 지원합니다. 팀이 Microsoft 생태계에 있다면 기본 선택입니다. (자세한 비교는 온프레미스 데이터 게이트웨이 대안 가이드에 있습니다.)
- AgentUI 커넥터는 AgentUI 앱과 대시보드를 위해 같은 일을 하며, 일부러 범위를 좁혔습니다.
깔끔한 이유: 인바운드 포트도 공인 주소도 필요 없고, 에이전트는 해당 벤더의 제품만 지원하므로 신경 쓸 범용 네트워크 경로가 없습니다.
대가: 각 에이전트는 자기 벤더의 제품만 지원하고, 벤더의 에이전트를 신뢰해야 합니다. 설치 전에 무엇을 할 수 있고 없는지 확인하세요.
한눈에 비교
| 방법 | 인바운드 포트 개방? | 공인 IP 없이 작동? | DB에 닿는 주체 | 적합한 용도 |
|---|---|---|---|---|
| 1433 포워딩 | 예 (1433) | 아니요 | 포트에 닿는 누구나 | 장기적으로는 없음 |
| VPN | 보통 게이트웨이에서 | 구성에 따라 | VPN 안의 누구나 | 전체 네트워크 접근이 필요한 사람 |
| 배스천 경유 SSH 터널 | 예 (배스천의 22) | 아니요 | 배스천 키를 가진 사람 | SSH 터널을 지원하는 클라우드 도구 |
| 아웃바운드 터널 (Cloudflare Tunnel, Tailscale) | 아니요 | 예 | 정책이 허용한 대상 | 접근 정책을 관리할 수 있는 팀 |
| 벤더 에이전트 (게이트웨이, AgentUI 커넥터) | 아니요 | 예 | 해당 벤더의 제품만 | 한 벤더의 도구로 데이터 활용 |
목적이 그 데이터로 만드는 앱과 대시보드라면
실제로 원하는 것이 사무실 DB 위의 내부 도구, 보고서, 대시보드라면 터널보다 커넥터가 더 중요합니다. 그래서 만든 것이 AgentUI 온프레미스 SQL Server 커넥터입니다.
- 아웃바운드만. 포트 443의 HTTPS로 바깥에 연결합니다. 인바운드 규칙, 방화벽 변경, 공인 주소 모두 필요 없습니다.
- 읽기 전용.
SELECT와WITH쿼리만 실행되고, 모든 쿼리는 실행 후 롤백됩니다. - 비밀번호는 제자리에. 해당 서버에만 저장됩니다(Windows에서는 암호화). AgentUI는 커넥터 키의 지문만 보관합니다.
- 해제 가능. 두 번 클릭으로 해제되며, 키는 25초 안에 작동을 멈춥니다.
- 한계. Microsoft SQL Server만 지원합니다. 쿼리는 필요할 때 실행되며 한 번에 최대 1,000행, 30초. DB를 복사하거나 동기화하지 않습니다.
Windows, macOS, Linux에 서비스로 설치됩니다. 전형적인 경우는 Windows 서버의 SAP Business One입니다. 이 관점에서 앱 빌더를 비교하고 있다면 Retool이 온프레미스 SQL Server에 연결하는 방식도 정리해 두었습니다.
무엇을 골라야 할까?
- 사람이 집에서 전체 접근이 필요하다: VPN.
- 클라우드 도구가 SSH 터널만 지원한다: 벤더 IP로 제한한 배스천. 관리할 서버가 하나 늘어난다고 생각하세요.
- 팀이 접근 정책을 잘 관리하고 범용 경로를 원한다: Cloudflare Tunnel이나 Tailscale 같은 아웃바운드 터널.
- 한 제품만 데이터를 읽게 하고 싶다: 그 제품의 아웃바운드 에이전트 — Power Platform이라면 Microsoft 게이트웨이, AgentUI 앱이라면 AgentUI 커넥터.
마지막 경우에 해당한다면 AgentUI 커넥터로 SQL Server를 연결하세요. 읽기 전용이고, 두 번 클릭으로 해제할 수 있습니다.