[웹 애플리케이션 보안 프레임워크] ① 어떤 게 있나

인터넷은 매우 방대한 공간이다. 게다가 웹사이트 하나를 게재하기만 하면 누구든지 브라우저를 통해 볼 수 있게 된다. 바로 이런 점이 인터넷의 장점이 아닐까.웹사이트에 어떤 특정한 조치를 취하지 않는 한 누구든지 계속 들락날락거릴 수 있다. 그러나 이런 외부인의 접속을 막고 싶으면 어떻게 해야 할까?웹 애플리케이션 보안 프레임워크는 웹사이트에 대한 접속을 제한하는 방법을 제공한다. 보안 사항을 설정하는 방법은 매우 많지만 가장 흔히 사용되는 3가지는 데이터베이스 색인, OS 수준의 인증, 그리고 디지털 인증이다.웹사이트에 보안을 적용해야 하는 이유는 수없이 많다. 그러나 가장 결정적인 이유는 바로 특정 콘텐츠는 특정 사람들만 봐야 한다는 점이다. 사실 이 부분은 오히려 인터넷보다도 더 오래된 딜레마이지만 다행히도 몇몇 영민한 사람들이 온라인에서 이 목적을 달성할 수 있는 방법을 개발해냈다.1. 데이터베이스 색인보안 사항을 실행하는 가장 손쉬운 방법은 데이터베이스 색인을 활용하는 것이다. 여기서 말하는 데이터베이스는 MS SQL 서버나 오라클과 같은 RDBMS만을 지칭하는 것은 아니다. 더 포괄적인, ‘관련 정보에 관한 조직화된 구성체’ 정도의 의미다.정보 구성체가 다양한 역할과 회원제도를 운영하기 위해 사용자당 75개 항목을 둔 복잡한 형태이든, 아니면 사용자당 2개 필드로만 간단히 구성돼 있든 데이터는 모두 검증하기 위해 존재하는 것이다.검색 작업을 수행하는 데에는 많은 방법이 있다. 이 중 어떤 방법을 사용하느냐는 바로 저장 수단에 상당 부분 좌우된다. LDAP를 사용하고 있다면 LDAP 요청을 활용할 것이며 RDBMS를 활용하고 있다면 아마도 ODBC와 같은 커넥터를 활용하게 될 것이다. 만약 애플리케이션에 데이터를 일일이 직접 코드화한다면 그 가치를 활용하지 못하고 단지 검토만 하게 될 것이다.거의 대부분의 웹 애플리케이션이 사용자 인증에 있어 각 방법론을 최적화된 형태로 운영하고 있다고 봐도 무방하다. 이를 알려주는 지표는 바로 사용자명/로그인, 패스워드 등 2개 필드와 확인 버튼으로 구성된, 매우 일반화된 형식이다.이 형식은 2개 필드를 서버로 보내고, 서버는 데이터베이스에서 필드값을 확인한다. 검색 작업이 실패로 돌아가면 해당 사용자는 차단돼 작업을 진행할 수 없게 되며 검색 작업이 성공하면 사용자는 인증받았을 때만 볼 수 있는 콘텐츠에 접속할 수 있다.이 방법론은 여기서 언급하는 3가지 방법론 중에서 가장 쉽게 실행할 수 있는 것이다. 반면 실행의 용이함 때문에 가장 보안에 취약하기도 하다.예를 들면 단지 지속적으로 다른 사용자명과 패스워드 조합을 시도하는 것을 들 수 있다. 요즘처럼 프로세서가 막강한 위력을 지니게 된 때, 스크립트를 사용해 승인되는 조합을 발견하는 것은 몇 초, 아니면 몇 분 내에 성공할 수 있다.그러나 대부분의 경우 보안 프레임워크 뒤에 자리한 정보가 이른바 생사를 좌우할 정도로 중요하진 않는 경우가 많다. 따라서 이 방법론은 그런대로 잘 실행되고 있다고 볼 수 있다.2. OS 수준의 인증다음 보안 유형은 OS 수준의 인증이다. 아마 이와 같은 질문이 제기될지도 모른다. “이게 무슨 뜻인가? 사용하는 운영체제 유형을 체크한 다음, 이에 기반해 사용자의 접속을 허용할지 말지를 결정한다는 것인가?”라고 말이다. 물론 전혀 그렇지 않다.원래부터 운영체제는 보안 요소를 내부에 내장하고 있다. 각 시스템에 대한 로그인/패스워드 방식이든 접속 네트워크에 대한 로그인/패스워드 방식이든, 사용자들이 일정한 ‘허락’을 받아내려면 자신을 식별시켜야 하기 때문이다.이 보안 방법론을 웹 애플리케이션에 활용하는 것에 대한 근거는 다음과 같다. 이미 로그인과 패스워드에 대한 데이터베이스를 갖고 있는 마당에 왜 또 다른 요소를 만들어야 하냐는 것이다.이런 유형의 보안 방법론은 사용자가 웹사이트를 방문하기 이전에 관리자에 의해 식별되고 설정돼야만 작동된다. 그러나 잘 조직된 기업이나 전문 기관 등 결합도가 높은 집단에서는 효과를 발휘할 수도 있지만 대용량의 웹사이트에서는 전혀 실효성이 없다.그러니까 아마존이 자사 고객은 물론 모든 접속자들을 중앙에서 관리해야만 한다면 어떻게 될 지 상상할 수 있겠는가? 이 방법론은 실효를 거두지 못할 것이다.하지만 기업의 보안 담당자들은 이미 개별 사용자 계정을 설정하고 있으며, 따라서 이런 정보를 재활용할 여지는 있는 셈이다. 이런 유형의 보안 방법론으로 이득을 취할 수 있는 웹 애플리케이션들은 주로 인트라넷에 기반을 둔 것들일 것이다.3. 디지털 인증잠시 과거로 돌아가 넷스케이프가 인터넷 열풍을 몰아왔던 시기를 회상해보자. 당시 사람들은 커뮤니케이션의 보안을 지킬 수 있는 방법이 앞으로 필요하게 되리란 점을 깨닫고 있었다.원하기만 하면 누구라도 내부 내용을 감청하고 정보를 훔쳐갈 수 있는 상황에서 민감한 정보를 편안하게 주고받을 수 있는 사람은 아무도 없다. 바로 여기서 디지털 인증작업이 탄생하게 됐다.디지털 인증은 데이터를 암호화하고 해독하는 방법론을 제공한다. 만약 ‘SSL’이란 용어를 들어봤거나 ‘http://’에서 ‘https://’로 넘어가는 URL 변경을 본 적이 있다면 디지털 인증 솔루션을 경험해 본 것이다.대부분의 경우 디지털 인증은 웹상의 의사 교환 중 한 쪽에만 설치된다. 그러니까 방문자 자신이 밝힌 신원 정보가 무엇을 뜻하는지 확인하기 위해 인증 솔루션을 설치하는 곳은 바로 웹사이트, 즉 웹서버다.그렇지 않다면 어떤 웹사이트든지 아마존을 그대로 베낀 다음 의심하지 않는 인터넷 사용자로부터 신용카드 정보를 수집할 수 있게 될 것이다. 인터넷 클라이언트, 그러니까 웹 브라우저에는 인증 솔루션이 설치되지 않는다. 대신 아마존은 사용자명과 패스워드를 제공함으로써 방문자들이 스스로 말하는 신원 정보가 맞는지 확인한다.만약 절대적인 수준의 보안을 원한다면 인터넷 클라이언트는 자신의 시스템에도 디지털 인증 솔루션을 설치할 수 있다. 설치한다면, 방문자는 스스로 말하는 신원 정보가 절대적으로 맞다고 확인할 수 있게 될 것이다.그럼 왜 이런 솔루션이 사용되지 않는가? 여기에는 몇 가지 이유가 있다. 가장 중요한 이유는 바로 비용이다.디지털 인증은 개당 가격이 수백 달러 수준인 솔루션으로 결코 보편적인 인터넷 사용자가 기꺼이 지불하려 하는 정도의 금액은 아니다. 다음은 휴대성이 부족하다는 것이다. 인증 솔루션은 시스템 수준에서만 설치돼야 한다. 쇼핑에 사용하는 시스템 모두에 인증 솔루션을 설치하길 원하는 사용자가 있을까?마지막 요인은 바로 참을성과 관련이 있다. 이 문제를 세밀히 살펴보자. 인터넷 사용자들은 사실 매우 참을성이 없는 편이다. 만약 작업 시간이 오래 걸린다면 이들은 아마 그냥 가버릴 것이다.그럼에도 불구하고 절대적인 수준의 보안을 원한다면, 아마 이와 같은 방법론이 정답일 것이다.다음에 살펴볼 것들이처럼 웹 애플리케이션 보안 프레임워크(WASF)는 몇가지 선택사항들로 구성돼 있다. 이번 글은 3가지 주요 유형에 대한 개요 수준이며 앞으로 게재될 글에서는 각 유형들을 세부적으로 알아볼 것이다.다음 글은 데이터베이스 검색 유형을 살펴볼 것이며, 그 다음에는 OS 수준의 인증에 대해 알아보고 마지막은 디지털 인증을 다룰 될 것이다. 각 글들은 이것들이 과연 무엇이며, 어떻게 운영되고, 어떻게 실행되는지 3가지 문제에 대한 세부적인 답변을 제시하는 방향으로 진행될 것이다. @