내가 누구인지 말할 수 있는 자는 누구인가

평소 산책을 즐긴다. 온통 프랜차이즈 세상이라 분명 처음 걷는 동네인데도 지나치게 익숙하니 예전 같은 재미는 없지만 그래도 산책은 여전히 즐거운 취미다.

걷다 보면 헉! 놀라곤 한다. 주로 흔히 달동네라 부르는 동네, 자칫 발 잘못 디디면 데굴데굴 굴러 사지 멀쩡한 데가 없을 듯싶은 길. 이런 위험한 곳을 아무런 안전장치 없이 방치하다니, 이거 원 사람들이 용감한 건지 무모한 건지, 아니면 다들 잘들 사는데 내가 너무 겁이 많은 건가? 어쩌면 위험을 두고 보지 못하는 직업병일지도 모르겠다.

위험을 방치해 사고가 발생하면 여기저기서 “이건 이렇게 했어야 했는데 안 했다!” 막 떠들지만 다음에 또 같은 사고가 벌어진다. 그리고 또 “그때 이렇게 했어야 했는데 안 했다!” 떠든다. 아, 괴롭다. 들어 보면 당장 문제를 해결할 수 있는 방법도 아니다. 그 헛된 공회전은 아마도 해당 분야 기술에 대한 이해 부족 때문인 듯싶은데 그리 말하면 더 화내겠지? 꾹 참는다.
ICT 세상의 위험을 보자. 대충, 즉 원론적으로 추상적으로 보지 말고 구체적으로 보자. 위험의 정체를 제대로 파악하고 해법의 가능성을 현실적으로 보는 게 위와 같은 공회전을 막는 유일한 방법이니.

(이 말을 지금껏 몇 번이나 했는지도 모르겠다만,,) 정보보안 사고의 절대다수는 웹 보안 실패다. 그리고 주요 사고지점은,

압도적 1위: SQL 인젝션 등 웹 애플리케이션 허점 노린 범죄
못잖은 2위: 사용자 인증 및 세션 관리 등, 인증보안에 실패한 사례

이 자명한 사실이 왜 그 요란한 ‘소 잃고 외양간 고치기’ 논쟁에 등장하지 않는지 그저 딱할 뿐이다. 아무튼,

웹 애플리케이션 허점은 웹 애플리케이션 방화벽 도입과 적절한 운용으로 해결 가능하다..라고 말하면 피곤한 논쟁이 벌어질 위험이 있지만,, 거듭 강조하는 바, 가능하다. ‘적절한 운용’이란 말이 굉장히 큰 구멍을 숨기고 있긴 하지만, 그게 뭐든 ‘적절하다’는 말 자체가 그러하지 않던가?

보다 큰 문제는, ‘인증보안’. 무지무지 심각한 문제인데 도대체 논의 자체가 되지 않고 “그 정도는 전산실에서 알아서 해 줘야 되는 거 아냐?” 가볍게 다루고 그치기 때문에 더 큰 문제다. 도대체 왜 그럴까?

일단, 아주 간단해 보여서. 패스워드 문제 아닌가? 그렇다. 패스워드 문제다.

발광한 리어 왕이 울부짖는다.

“Who is it that can tell me who I am?”

이 대사를 어떤 소설가가 ‘내가 누구인지 말할 수 있는 자는 누구인가’라고 소설 제목을 땄던 적이 있다. (좋은 번역은 아닌 듯싶다. 너무 딱딱하고, 상황을 보면 “내가 누구인지 말해 줄 사람 거기 누구 없나?” 정도의 뜻이다.) 이 대사는 이후 리어 왕의 ‘그림자’에 대한 온갖 분석의 소재가 되고 어쩌고 저쩌고..는 각설하고,

이는 정보보안적으로도 매우 중요한 질문이다. 내가 누구인지 말할 수 있는 자는 누구인가? 대개는 패스워드를 통해 내가 누구인지를 말한다.

패스워드 따위로..

패스워드 시스템을 보자면, 산책 중에 발견하는 위험한 길이 떠오른다. 용감한 건지 무모한 건지, 이 위험한 시스템을 아무렇지도 않게 막 쓰다니.

아주 당연하게 사고가 끊임없이 벌어졌다. 해커들의 주된 일이 뭐겠나? 주로 패스워드 사냥이다. 패스워드만 알면 내가 아닌 남 행세를 하며 시스템을 막 들락거릴 수 있으니. “열려라 참깨!” 그러면, 열린다.

어떤 회사의 시스템을 떠올려 보자. 사용자 인증보안 문제는 간단한 듯 은근히 복잡하다.

네트워크/시스템/어플리케이션 등 ICT시스템 전 영역에 걸쳐 적용되어야 하고, 인증서버 / DB서버 / 정책서버 / 관리도구 등 여러 요소로 복잡하게 구성되어야만 제대로 된 인증보안이 가능하고, 전 요소가 철저하게 암호화되어야 한다. 모든 영역에 대해 세션 인증을 수행하여 일관성 있는 세션 인증 로직을 표준화해야 하고, 현장에서 사용하는 여러 운영체제와 브라우저 등 어떠한 환경에서도 문제 없이 작동되어야 한다. 어디 그뿐이랴, 외부 협업 및 사생활 등을 위해 NPKI, GPKI, 사설인증 등 다양한 인증서를 지원해야 한다.

듣기만 해도, 이거 쉬운 일이 아니다. 그럼에도, 했다 치자. 그런데 이 모든 복잡한 과정이 그 간단하고 허술한 ‘패스워드’를 통해 일어나고 있는 것이다. 막말로 개고생을 해 구축한 시스템이 누구든 “열려라 참깨!” 그러면 그냥 열리는 것.

그러니 인증보안, 개발만 어려운 것이 아니다. 회사 시스템은 전산 전문가들만 사용하는 게 아니다. 개발은 전문가들이 한다. 하지만 사용은 비전문가들이 단순히 이용할 뿐이다.

세상엔 이룰 수 없는 꿈들이란 게 많다. 그중 하나가 바로 ‘패스워드 계몽’. 어쩌면 절대 불가능한 일일지도 모르겠다. 가장 많은 패스워드 세계 1위는 ‘123456’인데 계몽은 무슨,,

따라서 ‘우리 회사 모든 임직원은 아래와 같이 행동하라’ 정책을 강제한다. 1)패스워드 복잡도, 2)패스워드 유효주기, 3)시스템별 패스워드 등. 즉, 문자 숫자 기호 섞어 충분히 복잡한 패스워드를 시스템별로 다르게 만들고 때마다 바꿔야 한다는 뜻이다. 그 결과,
자기 패스워드를 모른다!

사이트마다 다른 패스워드를 누가 다 암기하나! 그리고 그마저도 매번 재입력해야 한다. 이 회사는 왜 이리 뭐가 복잡해? 투덜댄다. 그런 불만은 별일 아닌 사소한 것처럼 보이지만 모아서 보면 매우 큰 스트레스 요인이다.

사용자만 힘들까, 전산 관리자도 힘들다. 맨날맨날 패스워드 불평불만에 답해야 하고, 관리해야 할 테이블 규모도 점점 커진다. 어느 정도 규모의 회사는 계정 정보는 모두 암호화해야만 한다. 그러니 “당신 패스워드는 뭐뭐뭐”라고 말해 줄 수도 없는데, 맨날 묻는다. 분산형 업무 시스템이라면 중앙집중형 계정 관리는 사실상 불가능해진다. 그래서..

참고 읽어 줄 만한 길이를 이미 넘어선 듯하니, 간단히 결론만 말하고 다음 기회에 다시 풀어서 이야기하는 게 낫겠다 싶으니, 결론은,

그 어렵고 복잡한 개발을 직접 하는 건 불가능하다. 아마 회사도 그런 개발에 시간과 자원을 쓰고 싶지 않을 것이다. (대개의 경우 결국 제대로 되지도 않는다,,) 그러니, 단 하나의 패스워드를 통해, 그리고 OTP 등 여러 보조 인증 방법을 통해 사용자의 신원을 증명하고 여러 자원을 편리하게 이용할 수 있는 SSO(Single Sign-On) 솔루션의 도입을 고민해 보시라. 쓸데없이 낭비되는 시간을 대폭 줄일 수 있다. 단, 사용자나 전산 관리자 모두 편리해지긴 하지만 아쉽게도 인증보안이라 할 만한 보안성은 충족하지 않는다. 따라서 보다 인증보안 원론에 충실한..

그럼 SSO가 무엇이고 또 무엇이어야 하는지,
다음 이 시간에 계속.