HTTP를 사용하는 어플리케이션 개발자들에게

인터넷 접속 제어

인터넷을 이용하는 프로그램의 핵심에 웹 브라우져가 있다고 가정하고 만드는 보안 장비들이 있습니다. 그들의 주 타겟은 사용자의 인터넷 접속을 제한하는 것인데, 모든 웹 트래픽을 사용자 인증을 거치도록 리다이렉션 시킨다음 인증되고 나면, 해당 브라우저에 cookie나 혹은 auth header등을 설정하게 만들거나 해당  IP를 등록하여 이후의 인터넷 접속을 허용하는 방식으로 구현이 됩니다.

문제 발생

아, 그런데 여기에서 웹브라우저가 아닌 것들과 문제가 발생합니다. 저희 회사의 제품에서도 80번 포트를 이용한 HTTP로 업데이트를 하고 있습니다만, 이것은 사용자의 인터렉션을 기대하기 어렵습니다. 라이브러리만 HTTP를 이용하는 수준으로 개발되기 때문입니다. HTTP 프로토콜을 사용하는 어플리케이션 개발자들은 대개

• IE Component를 이용하거나
• HTTP+SSL library 를 이용하거나
• tcp로 직접 HTTP를 구현하거나
  

하는 방법을 사용하게 됩니다. 그러나 네트워크 보안제품을 만드는 사람은 어떻게든 불편을 감수하고서라도 관리자에 의해 통제 가능하도록 만듭니다.

보안 제품 개발

이런 보안 제품은 최대한 정상적인 흐름을 건드리지 않고 그 흐름을 제어 하게 됩니다. network fire wall, personal fire wall, qos, switching hub, transparent proxy, load balancer, nat, ips 등등... 일개 어플리케이션 개발자들이 굳이 알지 않아도 그들은 다 회피시켜주는 것을 원칙으로 합니다. 다만, 인터넷 접속 제어만은 인증을 요구하여 최초 한번만 용서를 구하도록 개발되고, 이런 보안 프로그램과 일반 어플리케이션이 충돌하게 되면, 어플리케이션이 접속하는 서버들은 고정되어 있으므로, 그 서버 리스트를 제작자에게 요청하여 예외 항목에 등록하게 됩니다.

예외 관리 및 관리 회피 개발간의 갈등

여기에서 갈등이 생깁니다. 네트워크 관리자는 어플리케이션마다 예외를 추가하는 부담스러운 관리를 해야합니다. 필수 어플리케이션이 아닌 상황에서야 VIP(임원진) 들이 요청하는 것외에는 예외을 둘 수 없는 상황이 생깁니다.

그런데 그런 네트웍 안에 있는 어플리케이션 사용자들은 왜 이 제품이 정상적으로 동작하지 않는지 알 수 있는 방법이 없습니다. 제품 개발사에 문의를 하는 것 밖엔 없지만, 연락을 잘 하지 않습니다.

그렇다고, 어플리케이션 개발자들도 상상하지 않았던 보안제품이 설치된 환경에서 동작할 때의 이상현상이란 직접 보지 않고는 알 수가 없기 때문에 어떤 식으로 대처해야 할지 모릅니다. 대개, 보안 제품과 충돌할 때, 허용리스트를 네트워크 관리자에게 전달해주면 모든게 끝날수 있지만, 그렇게 모든 문제가 생기는 네트워크마다 가이드 해줄 수 있는 것도 아닙니다. 게다가 서버가 증설되거나 변경이 되면 다시 모든 네트워크 관리자에게 전달해주어야합니다.

결국... 개발자가...

이런 갈등은 소비자/생산자, 관리자/개발자 간의 알력이 포함될 수 밖에 없습니다. 여기서 문제는, 보안 제품쪽 개발자가 수 많은 어플리케이션의 요구사항에 맞춰 지능화 시키기란 어렵다는 것입니다. 어플리케이션 개발자가 늘 지는 구도로 갈 수 밖에 없고, 처음 몇번은 회피 목록을 관리자에게 전달하여 우회시키는 것을 해답으로 제시하겠지만, 다시 이런 일로 고객지원을 하지 않게 하려면, 어플리케이션에서 사용하는 HTTP를 마치 인터넷 익스플로러를 사용할 때 나올 법한 오류 메시지로 진화시켜야합니다.

이런 개발자들을 우리는 칭찬해 주어야합니다.