2 채널인증과 2 팩터 인증의 차이점과 네트워크 기반 서버접근제어 2 팩터 인증의 취약점

Posted by taeho Tae-Ho
2014.03.15 11:45 서버보안

KT의 개인 정보 유출과 여러 신용 카드 사의 개인 정보 유출 등 끊임없이 발생하는 보안 사고는 기존의 보안 솔루션들이 보안 솔루션 답지 않게 보안 취약성을 제대로 제거해주지 못한다는 것을 의미한다.

특히 인터넷을 통한 서버로의 직접 침투는 많이 줄었지만 (사실 그리 줄지도 않았지만..발견되지 않거나 은폐될 뿐..) 정보가 저장되어 있는 서버에 접근 권한을 가진 내부 관리자 및 개발자 그리고 외주 인력에 의한 보안 사고는 오히려 더 늘고 있다. (신용카드 3사의 개인정보 대량 유출이 가장 대표적인 사례다.)


공공 기관과 기업의 전산실에서는 오래전부터 내부자의 서버 접근을 통제하기 위해 여러 방안들이 적용하고 있긴 하다. 하지만 그 내부 접근 통제의 개념과 적용 범위를 제대로 결정하지 못하고 있고 적용하고 있는 보호 대책들도 관리자 권한에서 우회나 변조가 가능하기도 하며 다수의 서버를 통합 관리하기가 쉽지 않기 때문에 보안 취약성 제거 효과를 보지는 못하고 있는 것이 현실이다.


이 포스트에서는 최근 내부 접근 권한을 가진 관리자나 개발자, 외부 엔지니어에 대한 접근 통제 및 감사 솔루션으로 각광 받기 시작한 2 Factor 인증 및 2 Channel 인증 기법에 대해 살펴보고자 한다.


2 Factor 인증과 2 Channel 인증의 차이



2 Factor 인증은 기존의 "지식기반 인증"인 ID/Password 인증에 다른 요소 즉 소유기반 인증 및 생체인증 요소를 추가한 인증 기법을 말한다.


2 Factor 인증기법을 인증 과정에 추가하면 ID/패스워드를 알고 접속하려는 사용자에게 OTP 인증 번호나 지문 등의 추가 인증을 요구함으로써 스니핑과 같은 ID/패스워드 유출에 의한 공격을 방어할 수 있다. 하지만 최근에는 APT 공격 등에 의해 단순한 2 Factor인증(이차 인증) 기법이 무력화 되는 경우가 발생하기도 한다.


특히 웹 서비스나 스마트폰 기반의 서비스는 이러한 단순한 이차인증(2 Factor 인증)만으로는 해킹을 방어하지 못하는 사례가 발생하기도 한다. 그 이유는 바로 메모리 해킹 때문이다. PC나 스마트폰에 설치된 악성코드가 사용자가 입력한 이차 인증 정보 혹은 인증 후 실 거래 발생 시 거래정보를 암호화하여 네트워크로 전송하기 직전에 거래 정보를 가로채 변조하는 고도의 프로그래밍 기술을 적용한 악성코드를 사용하기 때문이다.


그래서 등장한 개념이 바로 2 Channel 인증이다.



2 Channel 인증은 2 Factor 인증을 포함한다고 보는 것이 일반적이며 인증과 서비스를 수행하는 통신선로를 서비스 채널과 인증채널로 물리적으로 분리하는 것이 특징이다.


즉 서비스를 사용하는 PC/스마트폰의 통신 채널을 인증과 서비스에 모두 사용하는 것이 아니라 PC가 서비스 채널인 경우 ARS(전화) 혹은 스마트폰 앱 등을 통해 서비스를 사용하는 PC와는 물리적으로 다른 채널을 형성하여 2차 인증을 수행하는 것이다. 이렇게 서비스 채널과 인증 채널을 물리적으로 분리함으로써 해커에 의해 PC 혹은 스마트폰이 장악 되더라도 해커가 서비스에 접속을 할 수 없게 된다.


여기서 한걸음 더 나아간다면 금융거래나 구매 거래 시 관련 데이터를 2 채널 인증에 의해 확립된 2개의 채널로 분리하여 전송한 뒤 결제 시스템에서 조합하여 거래를 완성시키는 2 채널 서비스 구성도 검토해 볼 수 있겠다. 


SAC 솔루션의 2 Factor/Channel 인증 취약성


많은 보안 솔루션들 특히 서버 접근제어 솔루션(SAC)들이 2 팩터/2 채널 인증을 제공하고 있다. 하지만 네트워크 수준에서 2 Factor/Channel 인증을 수행할 경우 제대로 된 2 팩터/2 채널 인증을 수행할 수 없다.



위의 개념도에서 알 수 있듯 네트워크 수준에서 수행하는 서버 접근제어의 2차 인증은 사용자와 서버 접근 제어 장비까지의 구간만 2차 인증이 수행되고 실제 서버에 접근하는 접속 세션에서는 여전히 ID와 패스워드에 기반한 단순한 인증만이 수행된다.


게다가 비밀번호의 관리 편의성을 높이고 사용자가 서버의 계정에 대한 패스워드를 알지 못하게 하기 위해 서버접근제어 서버에 "복호화가 가능한" 형태로 모든 서버의 계정에 대한 비밀번호를 저장한다. 이는 "비밀번호는 복호화가 불가능한 형태로 암호화"해야 한다는 가장 기본적인 보안 규정을 어기는 중대한 보안 취약성이다. 개인정보보호법에는 사용자의 비밀번호는 복호화가 불가능한 단방향 암호화를 하도록 명시되어 있음을 유의해야 한다.


서버에 대한 2 factor 인증 및 2 channel 인증은 서버 운영체제의 자체 인증 과정에 추가하여 적용되어야만 우회 접속 및 여러 인증 취약성 공격 기법에서 자유로울 수 있다. 관리의 편의성 만을 생각한다면 모를까 제대로 된 서버 접근 통제를 하기 위해서는 필수적으로 운영체제에 추가적인 인증 모듈을 적용하여야 한다.


Unix/Linux의 경우 운영체제에서 PAM (plugable authentication module)이라는 2 factor/2 channel 인증을 적용할 수 있는 모듈을 제공하며 Windows의 경우도 GINA/CP라는 추가 인증을 적용할 수 있는 기능을 제공하고 있다. 그럼에도 불구하고 개발의 편의성, 관리의 편의성만을 쫓아 적용이 손쉬운 네트워크 기반의 2 factor/2 channel 인증기법을 적용하게 되면 관리 편의성은 증대될지 모르나 실질적인 보안 강화 효과는 그다지 기대하기 어렵다고 볼 수 있다.


또한 수 많은 서버와 네트워크 장비를 운용하며 패스워드 관리에 골치를 앓고 있는 기관과 기업의 어려움을 파고들어 제대로 된 보안 강화 솔루션이 아닌 보안 강화 효과도 별로 없는 솔루션을 공급하는 것은 상도덕에도 어긋난다고 할 수 있다.


사실 특정 보안 솔루션만으로 모든 보안 취약성을 커버할 수는 없는 것이 사실이다. 해킹은 지속적이고 지능적으로 변화하고 있으며 네트워크 기반의 보안 만으로는 더 이상 서버에 저장된 정보를 보호할 수 없다. 


개인정보를 비롯한 기관과 기업의 중요 데이터는 "서버"에 저장되어 있다. 서버의 보안을 강화하지 않고 길목인 네트워크에서 어떻게든 보안을 강화해보려는 구태의연한 보안은 이제 더 이상의 효과를 볼 수 없는 현실을 직시해야 한다. 아울러 외부로부터의 해킹이 아닌 내부 관리자/운영자/개발자들에 대한 통제를 빠르고 안정적인 "서비스 개발과 운영"을 핑계로 계속 미룰 경우 지금과 같은 해킹 대란은 계속 발생하고 보안 예산의 낭비는 계속될 수 밖에 없다.


신고
이 댓글을 비밀 댓글로