ISMS-P 결함사례 고찰 #2.7. 암호화 적용

2.7.1 암호정책 적용

인증기준: 개인정보 및 주요정보 보호를 위하여 법적 요구사항을 반영한 암호화 대상, 암호 강도, 암호 사용 정책을 수립하고 개인정보 및 주요정보의 저장·전송·전달 시 암호화를 적용하여야 한다.

 

결함사례#1

내부 정책·지침에 암호통제 관련 법적 요구사항을 고려한 암호화 대상, 암호 강도, 저장 및 전송 시 암호화 방법, 암호화 관련 담당자의 역할 및 책임 등에 관한 사항이 적절히 명시되지 않은 경우가 있다. 대상 별로 어떻게 암호화를 해야 하고, 어떤 암호화 알고리즘을 적용해야 하는지도 이미 성문화 되어있고, 그렇기에 역할 및 책임에 대해 명시하는 것은 어려운 일이 아니라고 본다. 개인적으로 '책임'을 명시하는 것을 정말 중요시 여겨야 한다고 생각하는데, 개인적으로는 자리가 사람을 만든다는 말 보다는 책임이 사람을 만든다는 말을 선호하기 때문이기도 하다. 실제로 그렇게 느끼기도 하고 말이다.

 

결함사례#2

암호정책을 수립하면서 해당 기업이 적용받는 법규를 잘못 적용하여 암호화 관련 법적 요구사항을 준수하지 못하고 있는 경우(예를 들어, 이용자의 계좌번호를 저장하면서 암호화 미적용)가 있다. 뭐.. 법규가 원체 다양하기야 하니까 이해를.. 그래도 이해를 하기 힘들다. 망에 따라, 위치에 따라, 구간에 따라 친절하게 성문화가 되어 있기 때문이다. 어느 정보를 다루고 있는지 분명하게 확인을 하는 것이 우선적으로 처리되어야 한다. 그리고 그 정보가 어디에 속하는지, 어느 법적 요구사항을 준수해야 하는지 확인해야 할 것이다. 그리고 처리는 최대한 즉시 해야만 한다.

 

결함사례#3

개인정보취급자 및 정보주체의 비밀번호에 대하여 일방향 암호화를 적용하였으나, 안전하지 않은 MD5 알고리즘을 사용한 경우가 있다. MD5 같은 경우는 대표적으로 '안전하지 않은' 알고리즘이라고 할 수 있다. 거의 대명사 수준이지 않을까 싶다. 그럼에도 MD5를 사용했다는 것은, 어떤 알고리즘을 쓴 시스템인지 관심이 없었다거나, 아니면 법에 무관심했다거나 둘 중 하나이지 않을까 싶다.

 

결함사례#4

개인정보처리자가 관련 법규 및 내부 규정에 따라 인터넷 쇼핑몰에 대하여 보안서버를 적용하였으나, 회원정보 조회 및 변경, 비밀번호 찾기, 비밀번호 변경 등 이용자의 개인정보가 전송되는 일부 구간에 암호화 조치가 누락된 경우가 있다. 암호화 조치는 개인정보가 포함된 구간이라면 모두 적용이 되어야 한다. 절대 누락되는 구간은 없어야 하며, 사실상 누락되는 구간은 공격을 하기 위한 타깃으로 너무도 적절할 것이다.

 

결함사례#5

정보시스템 접속용 비밀번호, 인증키 값 등이 시스템 설정파일 및 소스코드 내에 평문으로 저장되어 있는 경우가 있다. 중요정보는 어느 곳에 위치하건 항상 암호화를 기본값으로 깔고 가야 한다. 단순히 보여지는 화면에서만 처리를 할 것이 아닌, 모든 영역에서 그래야 한다.

 

2.7.2 암호키 관리

인증기준: 암호키의 안전한 생성·이용·보관·배포·파기를 위한 관리 절차를 수립·이행하고, 필요 시 복구방안을 마련하여야 한다.

 

결함사례#1

암호 정책 내에 암호키 관리와 관련된 절차, 방법 등이 명시되어 있지 않아 담당자별로 암호키 관리 수준 및 방법 상이 등 암호키 관리에 취약사항이 존재하는 경우가 있다. 담당자 별로 관리 수준과 방법은 당연히 다를 수밖에 없다. 사람마다 스타일이라는 것이 있기 마련이니 말이다. 따라서 이를 통일시키고, 취약한 수준으로 관리되는 것을 방지하기 위해 이에 대한 정책을 마련해야 한다. 이런 기준점이 있다면 담당자도 더욱 확신을 갖고 업무를 할 수 있을 것이다.

 

결함사례#2

내부 규정에 중요 정보를 암호화 할 경우 관련 책임자 승인 하에 암호화 키를 생성하고 암호키 관리대장을 작성하도록 정하고 있으나, 암호키 관리대장에 일부 암호키가 누락되어 있거나 현행화되어 있지 않은 경우가 있다. 암호키는 언제나 현행화를 진행하며, 누락되는 경우가 없도록 해야 한다. 보통 이런 경우에는 관리대장을 만들 때 그것을 관리하는 방법도 명시해두는 것이 업무에 있어서 도움이 될 것이다.

 

결함사례#3

개발시스템에 적용되어 있는 암호키와 운영시스템에 적용된 암호키가 동일하여, 암호화된 실데이터가 개발시스템을 통해 쉽게 복호화가 가능한 경우가 있다. 암호키가 동일한 것도 문제가 되는데, 쉽게 복호화가 된다면 더욱 문제가 된다. 개발시스템을 공격하면 끝나는 문제가 될테니 말이다. 암호키를 다르게 적용하는 것은 물론이거니와, 언제나 취약점 평가를 통해 문제가 있는 곳을 잡아내야 할 것이다.