IPsec을 Shadowsocks로 바꾸기 전에 사라지는 일을 먼저 적어 두세요

서비스 세 개, 터널 하나: 웹 앱, 데이터베이스, 파일 공유입니다. 누군가 운영이 더 간단하다며 IPsec을 Shadowsocks로 바꾸자고 합니다. 이어지는 암호화 논쟁은 터널이 여러 일을 동시에 하고 있고 그중 하나만 암호에 관한 일이라는 점을 놓칩니다. 제품을 비교하기 전에 그 일들을 적어 두세요. 목록은 짧고, 항목 하나만 빠져도 교체는 성립하지 않습니다.

트래픽이 어떻게 잡히는지부터 시작하세요

프로토콜에는 두 반쪽이 있습니다. 로컬 구성 요소가 연결을 받아 목적지 주소로 시작하는 스트림을 암호화하고 원격 구성 요소로 보냅니다. 원격 쪽은 그 목적지로 연결을 열고 바이트를 중계합니다. UDP도 데이터그램으로 같은 모양을 따릅니다. 이것은 자기가 잡는 흐름에 대한 전달이며, 잡지 않는 흐름에 대해서는 아무 말도 하지 않습니다. 프록시를 명시적으로 말하는 앱은 쉽지만, 나머지는 어댑터나 라우팅 규칙이 있어야 애초에 잡힙니다.

무엇보다 먼저 앱별로 잡는 방식을 문서화하세요. 잡히지 않은 트래픽은 평소 경로로 나가고, 서비스가 사무실 밖에서 다르게 동작할 때까지 아무도 눈치채지 못합니다.

모든 목적지와 프로토콜의 이름을 붙이세요

원격 쪽은 모든 내부 서비스에 도달할 수 있어야 합니다. 그 호스트로 가는 암호화 세션이 잘 돌아가도 그곳에서 데이터베이스로 가는 경로가 생기지는 않고, 클라이언트에서 내부 이름이 해석되지도 않습니다. LAN이 포함된다고 적는 대신 주소, 포트, 프로토콜을 나열하세요.

정돈된 설계를 깨는 사례로 내부 DNS, 프록시 설정을 무시하는 앱, 서버에서 클라이언트 쪽으로 시작해야 하는 흐름을 더하세요. 각각은 가정이 아니라 명시적 합의가 필요합니다.

암호화는 권한 부여가 아닙니다

Shadowsocks의 문서화된 AEAD 방식은 인증된 암호화를 제공하므로, 계열 전체를 안전하지 않다고 몰아내는 것은 틀렸습니다. 그 사실이 접근 질문에 답하게 두는 것도 똑같이 틀렸습니다. 누가 어느 서비스에 도달하는지, 사람이 떠날 때 접근을 어떻게 회수하는지, 비밀을 어디에 두는지, 어느 구성 요소가 경계를 강제하는지를 누군가는 정해야 합니다. 공유 비밀 하나면 보유자 모두가 같은 범위를 갖고, 한 사람의 퇴장이 모두의 교체 작업이 됩니다.

현재 IPsec 구성도 같은 잣대로 재세요. 그 이름이 규칙이 옳다는 것을 증명하지 않고, 한 설계의 매끈한 판과 다른 설계의 흐릿한 판을 비교해서는 아무것도 정해지지 않습니다.

오늘 양쪽에 있는 통제를 나열하고, 어떤 빈틈이라면 감당할 수 있는지 판단하세요.

운영 업무를 세세요

교체에는 클라이언트 패키지, 서버 업데이트, 자격 증명 교체, 장애 처리를 맡을 책임자가 필요합니다. 터널을 쓸 수 없을 때 각 앱이 무엇을 하는지, 실패하는지, 로컬 경로로 다시 시도하는지, 기다리는지 적어 두세요. 그 동작은 배포 방식에서 나오며 프로토콜 이름에서 나오지 않습니다.

웹 앱 하나에는 좁은 프록시로 충분할 수 있습니다. 사람별 권한이 있는 전사 네트워크 접근에는 추가 부품이 대체한 터널보다 비싼 경우가 보통입니다.

결정은 어느 제품이 더 안전하게 들리는가가 아닙니다. 나열한 일을 팀이 실제로 유지할 통제로 끝낼 수 있는 설계가 어느 것인가입니다.