무엇을 허용해야 하나

시험 환경에서 밖으로 나가는 요청을 필요한 곳만 열고 나머지는 막아야 했다. 기존 설정을 보니 프록시를 거쳐 나가고 있어서 그 프록시 주소를 허용 목록에 넣으려고 했다.

Open Table of contents

프록시를 허용하면 열리는 범위

프록시 주소를 허용하면 그 프록시를 거치는 모든 요청이 통과하게 된다. 프록시는 어디로든 보낼 수 있으므로 그 허용은 사실상 아무것도 막지 않는 설정이 된다.

허용해야 하는 것은 프록시가 아니라 그 너머의 목적지였다. 통제하려는 대상이 경유 지점인지 종착점인지를 먼저 정해야 목록의 내용이 정해진다.

목적지 목록이 필요한데 문서에는 그런 것이 없었고 실제 호출 대상은 클라이언트 코드 안에 흩어져 있었다. 두 저장소의 클라이언트 코드에서 호출 주소를 뽑아 중복을 없애니 스무 개 남짓이 나왔고 시험용 변형까지 합쳐 스물 몇 개가 됐다.

문서가 아니라 코드가 정본인 종류의 정보였고 그것을 뽑는 데 명령 하나면 충분했다. 이런 목록은 사람이 기억으로 채우면 반드시 빠지는 것이 생긴다.

뽑은 목록을 파일로 두고 프록시가 그 파일을 읽게 했으며 새 연동이 생기면 코드와 이 파일을 함께 갱신하도록 절차에 넣었다. 갱신한 뒤에 재기동 없이 설정만 다시 읽게 할 수 있는지도 함께 확인했다.

재기동이 필요하면 사람이 갱신을 미루게 되고 그러면 목록이 낡은 채로 남는다. 반영 비용이 낮아야 그 관리가 실제로 유지된다는 것이 이 설계의 전제였다.

목록을 만들다 보니 설정이 주석 처리돼 프록시를 안 거치고 직접 나가는 대상이 있었다. 그런 대상은 허용 목록에 넣어도 아무 효과가 없는데 애초에 그 경로를 지나지 않기 때문이다.

목록에 들어 있다는 것과 그 통제 지점을 실제로 지난다는 것은 별개의 사실이고 앞의 것만 보면 통제되고 있다고 착각한다. 실제로 경유시키려면 설정을 되살려야 하므로 그것을 별도 작업으로 적었다.

차단이 제대로 되는지 시험하다가 이름을 해석해 주지 않아도 주소로 직접 가면 통한다는 것을 확인했다. 장비가 대역 사이를 라우팅하므로 이름 해석을 막는 것만으로는 경계가 만들어지지 않았다.

실제 경계는 프록시의 접근 제어였고 그것만이 주소로 오든 이름으로 오든 동일하게 막는다. 그래서 차단 시험에서 거부 여부만 보지 않고 어떤 오류로 거부되는지까지 봤는데 이름 해석 실패로 거부되면 그것은 프록시가 막은 것이 아니기 때문이다.