2007년에 KISA에서 이런저런 일을 하면서 발표했을때 언급을 한 것이지만 앞으로의 방화벽 특히나 WAF기능을 가진 모든 방화벽은 실제 웹 어플리케이션을 분석하지 않으면 안된다.
기존의 네트워크 방화벽이 '방어'를 할 수 있었던 이유는 Protocol이라는 것이 '약속'이기 때문에 open되어 있고 나름 효율 적인 방식으로 구성되어 있고(머신이 처리하기 쉬운 방향으로) 프로토콜 하나당 복잡도가 전혀 크기 않기 때문이었다. 즉 보호해야할 대상을 알고 있다고 볼 수있다.
그런데 웹 어플리케이션 방화벽의 현주소는 어떠한가? 단순히 본인이 모듈형 웹 방화벽을 만들었던 2006년도에 비하여 2009년인 지금에 와서도 오픈소스진영의 모듈형 웹 방화벽이 얼마나 사용되고 있는가?
사실 처참하면 처참하다고 볼 수 있는 상황은 아닐까?
OWASP의 ASVS프로젝트가 2006년도보다는 많이 진전된것 같다. ASVS프로젝트의 핵심은 보안 문제를 방화벽으로 덮는게 아니라 문제를 가지고 있는 코드를 죄다 찾아내서 직접 고치겠다는 한발짝 적극 적인 태도의 프로젝트이다. 그리고 본인의 견지에 비추어 가장 확실한 방법이라고 본다.
아래 그림 한장이 웹 어플리케이션 방화벽이 가야할 길을 정확하게 찝어낸 그림이 아닐까 한다.
Web Application that is the target of verification.
ASVS의 자동화 툴은 웹 어플리케이션을 뜯어서 직접 내부를 본다. 물론 단위 단위로 정확하게 뜯어봐야 한다. 그리고 추출한 데이터들을 토대로 XML을 작성하고 그것을 이용하여 코드를 향상시키고 방화벽의 세부조정을 해야 한다.
본인이 지금 작성하고 있는 논문은 이러한 분석의 단계를 필요 없도록 만든다. 즉 각 레이어에 속한 각 객체들이 완벽에 가까운 Self Description을 해야한다. 가장 큰 이유은 웹 어플리케이션의 능동적인 조합이다. 이것을 통하여 웹 개발의 속도를 최대한으로 이끌어 내는 것이 본인의 목표중의 하나이다.
ASVS나 본인의 논문등의 구현물이 나오게 되면 방화벽은 소스와 연동되어 동작하게 된다.
앞으로 웹 개발은 더욱 더 Engineering될 것이다. 그리고 그것을 기반으로 자동화 될 것이다.
그렇게 될 것이라는 징후와 그래야만 하는 이유들이 계속 해서 나오고 있는 지금 웹 개발을 단순한 것으로 인식하고 있는 사람은 설자리를 잃어야 하는데............ 아마 계속 남아있겠지요...
진심 없이 일을 하는 사람들이 없는 세상이 왔으면 좋겠습니다.
관련글
2008/10/10 - 웹 어플리케이션 방화벽 Libero
2009/06/05 - [웹 개발]Hot한 주제 EUD, End User Development에 대하여
2009/06/09 - Web Engineering
2009/06/05 - [웹 개발]Hot한 주제 EUD, End User Development에 대하여
2009/06/09 - Web Engineering
