웹의 보안

표(!)로 정리되었으면 좀더 보기 좋았을 듯한 웹 보안쪽 컨설팅에 대한 짧고 좋은 글입니다.
웹 애플리케이션 취약점 진단 방법 비교 - "헐랭이와IT보안"

이번 글은 위의 글을 좀더 퍼트리고자 하는 목적과 더불어 일반적으로 웹의 보안에 대한 인식에 대해 저의 견해를 적어 보고자 함입니다. 많은 회사들이 자사의 데이터 보호에만 신경을 쓰고 있지만 고객의 자산을 보호하려는 것에 대해서 "보안 요구 사항" 자체가 생각해 내기 어려운 면도 있지만 미필적고의에 의해 간과해 버리는 것이 일반적인 상황일 것입니다.

ID-Password 시스템의 한계
보안이라는 것이 편의성과 반하는 경우가 일반적이라 할 수 있습니다. 가령 패스워드의 강도를 요구사항으로 넣게 되는 경우 안그래도 세상에 외울것도 많은데 전혀 이해할 수 없는 문자열을 머리에 넣게 만들고 있습니다. 질문-답 시스템은 심지어 주관식에 약한 사람들에게는 애시당초 외우는 것을 포기하게 만드는 경우도 존재합니다. 가령 좋아하는 색이 뭔가라는 질문에 대해 1년전과 동일한 상황이란 보장이 없기때문입니다. 그렇다고 부모 이름적기는 개인정보유출되면 끝나는 문제이고 초등학교 이름 적으라는 것은 초등학교를 나오지 않는 사람에게는 불가능한 질문이 되기도 합니다. 아무튼 이런 불편성을 고객에게 요구하고도 얻는 전체적인 보안 강도 향상이 얼마나 되는 것일까요? 패스워드 유출사고에서는 당연히 차이가 없고 패스워드 추측에서는 산술적으로야 100년 걸리는 것이 10000년 걸리는 차이가 있습니다만 실제적으론 둘다 10000년입니다. 단순히 ID와 Password를 동일하게 쓰지만 않게 하는것과 큰 효과차이를 가지기 힘듭니다. 제대로 된 강한 암호입력 방식은 랜덤 제너레이트된 16자리 문자열을 봉투에 넣고 봉인한 후 금고에 보관하면서 일주일마다 그것을 변경하는 정도는 되어야 의미성이 생길것입니다. 어설프게 할바엔 할 필요도 없습니다.

그럼 어떤 방법이 있느냐.. 불안한 ID-Password시스템이라면 아예 깨질것이라고 가정하는 편이 좋습니다. IE의 강력한 자동입력기능에 Cache 파일시스템에 이런 것을 제대로 관리하기에는 무지한 사용자가 있는 이상 적당한 확률로 제 3자가 패스워드를 훔쳐낼 수 있다고 보는 편이 좋습니다. 훔치지 않아도 인정많은 사용자들은 자신의 맞고 계정 패스워드를 애인에게 알려줍니다. 이렇게 포기하고 나면 보안성을 점검하는 데 있어서 길이 보일 것이라고 생각합니다. 취약한 보안 시스템인 ID-Password가 뚫리더라도 문제가 크지 않도록 해야 하는 것입니다. 쇼핑몰에서 가장 핵심적인 피해는 소비자에게 금전적인 문제일것입니다. 헌데 이런 부분은 카드사나 금융사에서 기를 쓰고 막고 있습니다. 쇼핑몰에서 따로 카드정보를 기억만 하고 있지 않으면 됩니다.(만약 한다면 알아서 고민해 보시기 바랍니다.) 나머지 정보들만 이제 보호하면 됩니다. 가장 먼저 할 일은 고객의 정보를 단계별로 나누어야 합니다. ID와 패스워드만 알면 모든 정보를 꺼낼 수 있는 0-depth 디자인은 문제가 있다는 것입니다. multi-depth로 나누고 각 단계마다 접근 방법을 제한 시키면 됩니다. 사실 이런 정보는 변경하는 케이스가 매우 드뭅니다. 회사가 비용을 부담하겠다라고 한다면 그순간 엄청난 방법들이 쏟아져 나옵니다.

Amazon의 사용자 기억 기능이 나름대로 유용할 수 있습니다. 아무런 입력 없이도 페이지 상단에 자신의 이름이 나옵니다. 자신이 주로 가는 카테고리나 본 상품에 의해 추천 상품들이 나옵니다. 반대로 그 상황에서 정보가 유출되어 봐야 Adult Video 상품들을 자주 찾아본다가 전부일 것입니다. 이후 로그인을 해야만 접근할 수 있는 부분과 더불어 최종 결제는 카드사의 인증방식을 사용합니다. 덕분에 결제가 뜨는데만 상당한 시간이 소요되기도 합니다만 이런 식의 다단계 정보 분류는 사용자의 편의성도 좋게 만들면서 적절한 보안성을 노리고 있습니다. (물론 저 시스템의 장점만 이야기 한 것이고 문제점이 없는 것은 아닙니다.)

보안도 투자가 필요하다
조금 위에서도 이야기 했습니다만 회사가 고객을 보호하겠다라고 투자를 시작하면 많은 보안적인 방법들이 생겨납니다. 즉 보안강도는 직/간접적인 비용과 연관이 생길 수 밖에 없습니다. 이런 부분은 의외의 곳에서도 존재하는데 가령 페이지와 컨텐트 접근에 있어 모든 데이터에 대해 사용자 인증을 걸게 되면 보안성은 향상되지만 액션당 컴퓨팅파워 소모량의 증가로 동일 동시사용자를 버티기 위한 서버대수가 증가할 수 밖에 없습니다. 비용 절감을 위해(개발자는 아마 효율적으로 프로그램을 짠거라고 주장하겠지만) 일부의 데이터는 사용자 인증을 거치지 않습니다. 페이지 자체는 이런 경우가 드물지만 컨텐트 즉 멀티미디어 데이터에 대해서는 소흘히 하는 경우가 많습니다. 스와핑을 한 부부가 그때의 사진을 상대방에게 보낼때 게시판을 통하면서 비밀글 설정을 했는데 3자가 위의 방식으로 접근해서 보고는 자신의 XXX 사이트에서 건당 10원에 팔수 있다는 것입니다. 회사에서는 서버 100대의 가격과 유지비를 아끼면서 고객은 평생의 쪽팔림을 얻게 되었습니다.

애시당초 보안컨설팅을 받는 것도 비용이겠습니다만 최초에 디자인단계에서 부터 보안전문분석가를 투입하고(참고글) 개발 단계에서도 지속적으로 코드를 보안적인 리뷰하는 것들이 모두 코스트가 되겠습니다. 최근 N회사에서 패스워드 유출 사고가 터졌을때 강제로 패스워드 변경하라고 시킨것은 좋은데 급하게 사건을 수습하는데만 신경쓰다 기존의 보안강도를 무시한채 임의로 사용자들에게 패스워드를 변경할 수 있게 하거나 일주일 후에 그래도 바꾸지 않은 사람들은 걍 그대로 써라라고 한 처사는 돈을 최대한 아끼면서 보안을 하려다 보니 강도를 급격하게 떨어뜨려 버린 상황이라 할 수 있습니다. (개다가 그 난리를 치고는 고작 1일 이용권이라닛!)

돈없으면 개발도 하지 마란 예기냐라고 하신다면 저도 약간은 가슴아프지만 그렇다라고 할 수 있습니다. 사실 그보다는 돈 많은 회사도 이런 부분에 정말 인색하다라는 점을 지적하고 싶은 것입니다. 만개중 하나의 압력 밥솥이 폭발한다면 전량 리콜을 하듯 소프트웨어나 웹도 마찬가지일 것입니다. 애시당초 폭발가능성을 고려하라는 것이구요. 그렇다고 바닥에 "폭발할 수 있으니 작동시 근처에 있지 말것"이란 스티커를 붙이진 말길 바랍니다. --;