클라우드 서비스 하나를 위한 네이티브 TLS, SSH 포워드 또는 VPN

질문은 두 클라우드 머신 사이에서 무엇을 암호화할지가 아니라, 어떤 인터페이스를 암호화하고 누가 누구의 신원을 확인하는가입니다. 저는 네트워크 다이어그램이 아니라 이미 무엇이 필요한지 아는 서비스에서 이 대화를 시작합니다. 대부분의 경우는 애플리케이션 자체의 TLS, SSH를 통해 전달되는 단일 TCP 포트, 모든 참여자에게 주소를 주는 라우팅된 오버레이라는 세 가지 경계로 덮입니다. 강도로 순위가 매겨지는 것이 아니라 문제를 얼마나 덮는지로 매겨집니다.

네트워크가 아니라 서비스에서 시작하세요

프로세스에서 바깥으로 나아가세요. 어떤 프로토콜을 쓰는지, 클라이언트가 어떤 이름을 검증할지, 누가 연결을 열 수 있는지. 이 세 답은 어떤 비교표보다 빨리 선택지를 없애고, 서비스 자체의 구성이 보통 몇 분 안에 답을 줍니다.

8443 포트에서 이미 HTTPS를 제공하고 api.internal.example용 인증서를 가진 작은 내부 API를 잡으세요. 호스트의 ss -ltnp은 무엇에 바인딩되는지 보여주고, openssl s_client -connect 127.0.0.1:8443 -verify_hostname api.internal.example는 클라이언트가 실제로 사용할 이름에 인증서가 유효한지 보여줍니다. 둘 다 건강하면 서비스가 자기 스트림을 보호할 수 있고 남는 것은 도달성뿐입니다. 네트워크를 만드는 것보다 훨씬 작은 문제입니다.

1단계: 서비스가 스스로를 보호하는가?

맞을 때 고르는 선택지이며, 팀이 가정하는 것보다 자주 맞습니다. 서비스의 암호화는 클라이언트와 서버 사이의 전체 경로를, 중간의 모든 홉을 포함해 덮으며, 중앙을 우회하는 어떤 터널도 이를 개선하지 못합니다. 클라이언트의 기본 저장소에 우연히 있는 것에 기대지 말고 기대하는 이름과 신뢰를 명시적으로 설정하세요.

암호화와 도달성은 별개의 제어로 남고, 이 둘을 합치는 것이 이 선택지가 잘못되는 지점입니다. 제한 없는 공용 리스너의 TLS 서비스는 여전히 누구로부터든 연결 시도를 받아들이므로, 리스너와 네트워크 규칙은 페이로드가 보호된다는 사실과 독립적으로 정해져야 합니다. TLS 위의 API는 검색 엔드포인트, 관리 포트, 옆의 대량 전송 채널에 대해 아무것도 말하지 않으므로 의존성을 확인하세요. 각각에는 고유한 답이 필요하고, 보호되지 않은 형제 하나면 전체 경계가 허구가 됩니다.

2단계: TCP 포트 하나가 요구 사항 전부인가?

요구 사항이 정말 TCP 포트 하나라면, 포워드가 작동하는 가장 작은 것입니다. SSH 로컬 포워드는 이미 존재하는 인증된 연결을 통해 그 포트를 나릅니다.

형태는 ssh -N -L 8443:127.0.0.1:8443 [email protected]이고, 중요한 세부는 127.0.0.1가 원격 측에서 해석되어 서비스로의 연결이 노트북이 아니라 배스천에서 열린다는 대상 주소입니다. 로컬 리스너를 -L 127.0.0.1:8443:...처럼 좁게 바인딩해 실수로 서비스를 자신의 로컬 네트워크에 게시하지 않도록 하세요. 서버 측에서는 클라이언트의 선행을 믿는 대신 계정이 전달할 수 있는 것을 제한하세요. PermitOpen, AllowTcpForwarding local, 기본 GatewayPorts no이 범용 릴레이를 특정 채널로 바꾸는 세 가지 설정입니다.

계약은 양방향으로 좁습니다. SSH는 자기 채널을 보호하고, 배스천에서 다른 애플리케이션으로의 추가 홉은 자체 보호가 필요합니다. 배스천의 loopback에서만 듣는 서비스는 다른 네트워크를 통해 도달하는 서비스와 노출이 전혀 다르며, 포워드는 이를 바꾸지 않습니다. 터널을 그 대체물로 취급하지 말고 애플리케이션의 인증과 TLS 검사를 유지하세요.

소유자가 하나인 연결 하나에는 잘 작동합니다. 규모가 커지면 로컬 포트 충돌, 감독, 키 회전, 재부팅 후 누가 포워드를 다시 시작하는가라는 문제를 안은 시스템이 됩니다.

3단계: 라우팅이 실제 요구 사항인가?

그 목록은 가장 작은 선택지의 정직한 비용이며, 그래서 팀은 결국 잊힌 몇 개의 백그라운드 명령을 관리되는 무언가로 바꿉니다. 대체물이 자동으로 VPN은 아닙니다. 요구 사항이 여전히 TCP 포트 하나라면, 문서화된 소유자가 있는 감독된 포워드가 오버레이보다 운영 비용이 싸고 눈에 보이는 방식으로 실패합니다. 우아함을 측정하기 전에 운영 소유권을 측정하세요.

라우팅이 요구 사항일 때 라우팅이 올바른 답이 됩니다. 평범한 IP 연결이 필요한 여러 애플리케이션, TCP 포워드가 나를 수 없는 프로토콜, 호스트 사이를 옮겨 다니는 서비스는 모두 같은 방향을 가리킵니다.

오버레이는 참여자에게 주소와 경로를 주고, 그다음 겹치지 않는 범위, 경로 소유권, DNS, 등록, 철회, 피어가 사라질 때 무슨 일이 일어나는가라는 진짜 작업이 시작됩니다. 그중 어느 것도 주소와 함께 오지 않습니다. 오버레이에 받아들여진 피어도 목적지의 모든 작업에 자동으로 권한이 부여되지는 않으므로 서비스 수준 인증은 남습니다.

그 후에 당신이 소유하는 것

남기는 기록에는 두 가지가 속합니다. 첫째는 무언가를 작동시키려고 이름 검사가 완화되면 이 경계가 모두 조용히 나빠지므로 클라이언트가 검증해야 하는 신원입니다. 둘째는 접근이 끝날 때 어떤 키, 어떤 규칙, 어떤 경로가 사라지고 누가 그것을 수행하는가라는 제거 단계입니다.

이 여정은 시작한 곳, 서비스에서 끝납니다. 실제 트래픽을 덮고 의도한 피어를 검증하는 경계를 고르고, 접근이 어떻게 갱신되고 감시되고 제거되는지 적으세요. OpenSSH 참조는 좁은 계약을 약속하기 전에 포워딩 옵션을 확인하는 곳입니다. 제거 단계를 한 문장으로 설명할 수 없다면 경계가 문제보다 큽니다.