.jpg)
움직이는 데이터뿐 아니라 멈춰 있는 데이터에도 암호화 필요
전문지식 없는 어설픈 암호화는 오히려 나쁜 결과 낳아
.jpg)
[보안뉴스 문가용] 암호화의 본질은 공격자들의 행동을 지연시키고 시간을 끄는 것이다. 그리고 굉장히 효과적이기도 하다. 그러나 이 시간지연의 역할을 간과한 것인지 기업들 대부분은 암호화를 반영하지 않고 있다. 최근 해킹 당한 토크토크(TalkTalk) 통신사가 대표적인 예이다.
물론 암호화가 처음부터 이런 목적으로 탄생한 건 아니다. 데이터를 전송 중에 있을 때 누군가 가로채지 못하도록 ‘보호’하는 것이 암호화의 기본 목적이었던 것이다. 그렇기 때문에 ‘전송 중’에 있는, 즉 움직이고 있는 정보의 보호에 암호화를 적용하는 것에 대해서는 일반 기업들도 잘 이해하고 있다. 하지만 저장되어 있는, 즉 멈춰 있는 정보에도 암호화를 적용하는 것에 대해서는 아직 잘 인지하지 못하고 있다. 개념이 낯설어서일 수도 있고, 네트워크 안에 일단 안착한 정보에 대해서는 안심하기 때문이기도 하다. 그러나 최근 몇 년 동안 일어난 사고 대부분이 ‘멈춘 상태로 있는’ 정보에서 발생한 사고라는 걸 생각해보면, 이제 생각을 바꿔야 할 때임이 자명하다.
암호화를 적용하려 할 때 기업들이 겪는 어려움은 크게 두 가지다. 1) 암호화를 실제로 어떻게 적용해야 하는가? 2) 암호화 키는 어떻게 보호해야 하는가? 가 바로 그것이다. 암호화는 매우 좋은 기술임이 분명하지만 비전문가가 잘못 사용하는 경우가 많아 의외로 안 좋은 인식이 많이 퍼져 있다. 암호화는 적용 당시에는 ‘품질 관리’를 할 수가 없기 때문에 비전문가가 얼마든지 자신감을 가지고 손 대볼 수 있으며, 낮은 암호화 품질에 대한 결과가 구체적으로 나타났을 때는 이미 늦은 경우가 많다.
게다가 인터넷은 정보의 바다다. 암호화에 대한 어설픈 정보들이 여기 저기 널려 있다. 심지어 코드 정보도 손쉽게 구하기 쉽다. 비전문가 양성소가 되기 십상이다. 그러나 이 또한 마땅한 해결책이 없다. 전문지식을 찾아 구하고 실제 전문가가 되는 것만이 유일한 방법이다. 하지만 딱히 현실적이진 않다. 그렇다면 암호화를 포기할 수밖에 없는 것 아니냐, 고 물을 수 있다. 현재 상황에서 할 수 있는 최선책을 준비해 보았다.
Tip 1 : 표준 알고리즘만 사용하고, 절대 스스로 제작하거나 고안하지 말 것. 대칭 암호화의 표준은 AES이며 비대칭 암호화의 표준은 RSA이다.
Tip 2 : 표준을 적용할 때 그 표준의 출처가 어디인지 확인하라. NIST 등 국가가 인정한 기관이나 산업이 공통적으로 인정한 곳이어야 한다. AES-128과 RSA-2048이 하한선이다.
Tip 3 : AES를 위한 인증된 암호화 모드(AES-GCM이나 AES-CCM)나 PCKS#11 v2.1을 디폴트로 사용하라. 해시 기능이 필요하다면 SHA256을 디폴트로 정하라.
Tip 4 : 알고리즘, 키의 크기, 암호화 모드를 쉽게 대체할 수 있도록 유연하게 코딩을 짜라. 암호화의 가장 기본은 코딩을 꾸준히 업데이트 하는 것이다.
Tip 5 : 위 네 개 실천사항을 실천하기가 너무 어렵다면 하이레벨 API(OpenSSL에 있는 EVP 라이브러리)를 활용해 암호화 하라고 권하고 싶다. 더 간단히 해결하고 싶으면 솔루션을 정식으로 구입하라.
암호화 키는 어디에?
애플리케이션 층위의 데이터베이스 암호화의 경우, 암호화시킨 데이터와 암호화 키를 함께 보관하는 것도 괜찮다. 그리고 사실 많이들 이렇게 하고 있다. 하지만 누군가 정보를 훔쳐갈 때 한 번에 키까지 가져갈 수 있게 된다는 건 감안해야 한다. 그리고 그 사실을 알고 키를 추출하는 데 성공하면 모든 암호화를 위한 노력이 한 순간에 무용지물이 된다.
또 다른 방법으로는 키를 애플리케이션 서버에 저장하는 것이다. 하지만 이렇게 하려면 키 싱크로 문제가 발생한다. 한 개의 데이터베이스를 여러 애플리케이션 서버가 공유하기 때문에 같은 키를 필요로 하기 때문이다. 그런데 문제는 애플리케이션 서버가 보통 네트워크에서 가장 취약한 곳이라는 거다. 그렇기 때문에 한 군데에만 침투를 성공하면 키를 훔쳐 다른 서버에도 간단히 들어갈 수가 있다. “Select *”만 실행시키면 된다. 애플리케이션 서버의 난독화나 다계층 보호를 활용해 키를 숨기는 방법도 있다. 그러나 이 역시 고급 기술을 가진 해커들 앞에선 별 효과가 없다.
결국 가장 좋은 방법은 키의 저장을 위해서 따로 서버를 마련하고, 보안을 단단하게 구축하는 것이다. 그리고 복호화가 필요한 작업을 할 경우 이 서버에 접속하게 하되 키를 직접 넘기지 않는 방식으로 처리할 수 있도록 해야 한다. 환경설정만 올바로 하면 이는 이상적으로 안전한 방법이다. 서버 자체의 보안이 완벽하고, 접근 방식 및 세팅만 제대로 갖추어지면 말이다.
요약하자면, 요즘 시대에 암호화는 어떤 경우에나 필수 요소다. 이를 부정할 수는 없다. 유출 사고 때문에 발생하는 피해액보다 암호화에 투자하는 금액이 훨씬 낮다. 그러려면 암호화 전문가가 내부 인력이든 외부 조력자든 반드시 필요한데, 이 부분은 현실적으로 충당하는 게 어려울 수 있다. 그런 경우 신뢰할 수 있는 조직이나 단체가 제정한 표준을 참고하고 철저하게 따르는 것으로 어느 정도 보완할 수 있다. 그것조차 어렵다면, 보안 암호화 솔루션을 구입하는 게 그냥 방치하는 것보다 백번 낫다. 암호화 키는 전문가나 전문기업의 상담을 받는 것을 권장한다.
글 : 예후다 린델(Yehuda Lindell)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
전문지식 없는 어설픈 암호화는 오히려 나쁜 결과 낳아
물론 암호화가 처음부터 이런 목적으로 탄생한 건 아니다. 데이터를 전송 중에 있을 때 누군가 가로채지 못하도록 ‘보호’하는 것이 암호화의 기본 목적이었던 것이다. 그렇기 때문에 ‘전송 중’에 있는, 즉 움직이고 있는 정보의 보호에 암호화를 적용하는 것에 대해서는 일반 기업들도 잘 이해하고 있다. 하지만 저장되어 있는, 즉 멈춰 있는 정보에도 암호화를 적용하는 것에 대해서는 아직 잘 인지하지 못하고 있다. 개념이 낯설어서일 수도 있고, 네트워크 안에 일단 안착한 정보에 대해서는 안심하기 때문이기도 하다. 그러나 최근 몇 년 동안 일어난 사고 대부분이 ‘멈춘 상태로 있는’ 정보에서 발생한 사고라는 걸 생각해보면, 이제 생각을 바꿔야 할 때임이 자명하다.
암호화를 적용하려 할 때 기업들이 겪는 어려움은 크게 두 가지다. 1) 암호화를 실제로 어떻게 적용해야 하는가? 2) 암호화 키는 어떻게 보호해야 하는가? 가 바로 그것이다. 암호화는 매우 좋은 기술임이 분명하지만 비전문가가 잘못 사용하는 경우가 많아 의외로 안 좋은 인식이 많이 퍼져 있다. 암호화는 적용 당시에는 ‘품질 관리’를 할 수가 없기 때문에 비전문가가 얼마든지 자신감을 가지고 손 대볼 수 있으며, 낮은 암호화 품질에 대한 결과가 구체적으로 나타났을 때는 이미 늦은 경우가 많다.
게다가 인터넷은 정보의 바다다. 암호화에 대한 어설픈 정보들이 여기 저기 널려 있다. 심지어 코드 정보도 손쉽게 구하기 쉽다. 비전문가 양성소가 되기 십상이다. 그러나 이 또한 마땅한 해결책이 없다. 전문지식을 찾아 구하고 실제 전문가가 되는 것만이 유일한 방법이다. 하지만 딱히 현실적이진 않다. 그렇다면 암호화를 포기할 수밖에 없는 것 아니냐, 고 물을 수 있다. 현재 상황에서 할 수 있는 최선책을 준비해 보았다.
Tip 1 : 표준 알고리즘만 사용하고, 절대 스스로 제작하거나 고안하지 말 것. 대칭 암호화의 표준은 AES이며 비대칭 암호화의 표준은 RSA이다.
Tip 2 : 표준을 적용할 때 그 표준의 출처가 어디인지 확인하라. NIST 등 국가가 인정한 기관이나 산업이 공통적으로 인정한 곳이어야 한다. AES-128과 RSA-2048이 하한선이다.
Tip 3 : AES를 위한 인증된 암호화 모드(AES-GCM이나 AES-CCM)나 PCKS#11 v2.1을 디폴트로 사용하라. 해시 기능이 필요하다면 SHA256을 디폴트로 정하라.
Tip 4 : 알고리즘, 키의 크기, 암호화 모드를 쉽게 대체할 수 있도록 유연하게 코딩을 짜라. 암호화의 가장 기본은 코딩을 꾸준히 업데이트 하는 것이다.
Tip 5 : 위 네 개 실천사항을 실천하기가 너무 어렵다면 하이레벨 API(OpenSSL에 있는 EVP 라이브러리)를 활용해 암호화 하라고 권하고 싶다. 더 간단히 해결하고 싶으면 솔루션을 정식으로 구입하라.
암호화 키는 어디에?
애플리케이션 층위의 데이터베이스 암호화의 경우, 암호화시킨 데이터와 암호화 키를 함께 보관하는 것도 괜찮다. 그리고 사실 많이들 이렇게 하고 있다. 하지만 누군가 정보를 훔쳐갈 때 한 번에 키까지 가져갈 수 있게 된다는 건 감안해야 한다. 그리고 그 사실을 알고 키를 추출하는 데 성공하면 모든 암호화를 위한 노력이 한 순간에 무용지물이 된다.
또 다른 방법으로는 키를 애플리케이션 서버에 저장하는 것이다. 하지만 이렇게 하려면 키 싱크로 문제가 발생한다. 한 개의 데이터베이스를 여러 애플리케이션 서버가 공유하기 때문에 같은 키를 필요로 하기 때문이다. 그런데 문제는 애플리케이션 서버가 보통 네트워크에서 가장 취약한 곳이라는 거다. 그렇기 때문에 한 군데에만 침투를 성공하면 키를 훔쳐 다른 서버에도 간단히 들어갈 수가 있다. “Select *”만 실행시키면 된다. 애플리케이션 서버의 난독화나 다계층 보호를 활용해 키를 숨기는 방법도 있다. 그러나 이 역시 고급 기술을 가진 해커들 앞에선 별 효과가 없다.
결국 가장 좋은 방법은 키의 저장을 위해서 따로 서버를 마련하고, 보안을 단단하게 구축하는 것이다. 그리고 복호화가 필요한 작업을 할 경우 이 서버에 접속하게 하되 키를 직접 넘기지 않는 방식으로 처리할 수 있도록 해야 한다. 환경설정만 올바로 하면 이는 이상적으로 안전한 방법이다. 서버 자체의 보안이 완벽하고, 접근 방식 및 세팅만 제대로 갖추어지면 말이다.
요약하자면, 요즘 시대에 암호화는 어떤 경우에나 필수 요소다. 이를 부정할 수는 없다. 유출 사고 때문에 발생하는 피해액보다 암호화에 투자하는 금액이 훨씬 낮다. 그러려면 암호화 전문가가 내부 인력이든 외부 조력자든 반드시 필요한데, 이 부분은 현실적으로 충당하는 게 어려울 수 있다. 그런 경우 신뢰할 수 있는 조직이나 단체가 제정한 표준을 참고하고 철저하게 따르는 것으로 어느 정도 보완할 수 있다. 그것조차 어렵다면, 보안 암호화 솔루션을 구입하는 게 그냥 방치하는 것보다 백번 낫다. 암호화 키는 전문가나 전문기업의 상담을 받는 것을 권장한다.
글 : 예후다 린델(Yehuda Lindell)
Copyrighted 2015. UBM-Tech. 117153:0515BC
[국제부 문가용 기자(globoan@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
문가용기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
