일단 웹 서비스에 접속해 용의자 자신의 신원을 인증 받는다. 그리고 정상적으로 아이핀 증명서 발급을 요청한다. 서버가 정상 및 유효 요청으로 판단하고 데이터베이스에서 해당 증명서 발급을 결정하면, 이때 프락시 툴을 이용해 타인의 증명서 번호를 반복해 요청한다. 하지만 서버는 이 요청이 정상적인지 아닌지 이미 끝낸 상태라 별 생각 없이 해당 증명서를 막 발급해버린다.데자뷔, 좀 허무하다. 작년 초 대형 통신사에서 벌어졌던 개인정보 유출사고와 완전 같은 유형, 그러니 사고 후일담 또한 몇 번째 똑같은 말을 하는 건지,, 그래도 핵심본질을 정리해 보면,
– 웹 애플리케이션 보안의 문제다.
– 범죄가 발각되지 않는 한 설계 원론적으로는 지극히 정상적인 과정이다.
– 따라서 백신 프로그램으로는 막을 수 없다.
문제 해결을 위한 해법 또한 늘 하던 이야기다. 그래도 써 보면,
1) 데이터 접근제어 등 기초적인 보안성 보장하는 시큐어 코딩에 입각해 개발한다.
2) 파라미터의 OTP화 등, 데이터 보안을 통해 공격을 원천적으로 차단한다.
3) 정상적인 웹 브라우저인지, 즉 프락시 툴이 아닌지 판단하는 장치를 사용한다.
4) 파라미터 탬퍼링 공격을 탐지하고 차단하는 웹 방화벽을 적절히 사용한다.
중요도 및 우선순위는 1)에서 4)로 흐르지만 당장 문제를 해결할 수 있는 처방의 즉각성(?)은 4)가 가장 높다. 특히 시큐어 코딩은 정말이지 봄날의 꿈 같은 이야기다. 이에 대해서도 ‘당장 아파 죽겠는데, 그저 건강해지라고?’란 글을 통해 말했던 적이 있다. 역시나, “개발을 잘하라? 물론 잘하고 싶지. 그 말을 ‘개발 환경의 척박함’ 주제와 함께 떠든다는 게 모순일 뿐.”
그간 벌어졌던 각종 정보 보안 사건사고를 종합해 보면 역시나 가장 중요한 정보 보안의 요소는, 근본적으로는 ‘데이터 암호화’, 사고 빈도수에 따른 처방 효과로는 ‘웹 애플리케이션 보안’, 중요도는 높지만 흔히 간과하므로 위험성이 높은 ‘인증 보안’, 이 세 가지라는 추론이 확신 수준으로 굳어진다. 해당 요소들의 중요성에 대해서는 ‘정보보안, 완벽한 방어는 없다’는 주장을 통해 에둘러 이야기했더랬다.
이번 아이핀 사고는 특히 웹 애플리케이션 보안이 중요하다. 그럼 이런 경우 당장 써먹을 수 있는 처방은? 웹 애플리케이션 방화벽을 도입하고 대응 옵션을 적절히 조절하는 일. 이 당연한 일을 왜들 그리 안 하는 건지 난 정말 모르겠다,,
그리고 또 인증 보안. 이번 사건을 통해 우리나라의 개인 신원 확인 절차는 또 어지러워질 것이다. 온갖 성토가 속출하고 대책이 난무할 것이다. 그럼? 절차가 복잡해지는 것이다. 게다가 아이핀 아닌가, 이거 무너지면 이제 뭘로 주민등록번호를 대체하겠다고 나설 작정일지 벌써부터 궁금하다. 그러다 결국 ‘너무 어려워서 인증 받지 못하는 인증’이 되고 만다. 이에 대해 ‘내가 누구인지 말할 수 있는 자는 누구인가’라는 사용자 입장에서의 의문을 던졌던 적도 있다.
자, 보라! 이미 다 했던 이야기들이다! 그러니 사실 상당히 번거로운 일이로구나 싶기도 하다. 그래도 뭐 어쩌랴. 정보 보안 관련해 계몽은 어쩌면 완전히 포기해야만 비로소 이후 대책이 나오는 거 아닐까? 뭐 그런 생각마저 들 지경이라, 오늘 나의 취미는 끝없는 인내요 이 길은 도 닦는 길이로구나, 뭐 그런 생각도 든다.