1. 개요
최근 한 기업에서 개인정보 탈취 사건이 발생하였는데, 찾아보니까 신용카드 정보를 DB에 저장하여 카드 정보 유출 발생, 카드분실신고 등 사용자들의 피해가 클 것이라는 소식까지 보게 되었다.
최근 XSS 관련 조치를 하면서 보안에 대한 중요성을 염두에 두고 있었는데, 이번 뉴스를 보게되면서 암호화에 대해 이론적으로, 실무적으로 어떠한 방안이 있을지 알아보았다.
분명 암호화를 하긴 할텐데 여기서 더 나아간 방법이 있을지 궁금하였다.
2-1. XSS
일단 조치하였던 XSS에 대해 잠깐 알아보았다.
지금까지 단순히 보안적인 조치로 인해 특수문자를 막는다, DB에는 비밀번호 등 민감한 개인정보는 반드시 암호화하여 저장한다, 라는 포괄적으로 이해하고 있었는데 이번 뉴스를 접하면서 암호화는 법률과 관계된 매우 중요한 요소라는 것을 느끼게 되었다.
XSS도 마찬가지로, 단순한 스크립트를 통해 민감한 정보를 탈취할 수 있으므로 전산처리가 아닌 입력 자체, 조회를 포함한 모든 입력값에 대해 공격 경로를 막는 것이 중요하다는 것을 배울 수 있었다.
현재 개발한 프로그램에 대해서는 Reflected Xss 조치를 취하였는데(HDIV, Http Direct Input Validation), 아예 접근을 차단하거나 페이지를 막아버리는 방법도 있다고 한다.
프로그램의 사용처나 내부망 등의 환경적인 요소가 아무리 폐쇄적이어도 보안조치는 법률과 관련한 문제이므로 반드시 짚고 넘어가야 한다.
클린 코딩과 더불어 시큐어 코딩의 개념을 머릿속에 기억하게 된 계기이다.
2-2. 카드정보 등 민감성 개인정보를 DB에 저장하는 방안
암호화는 당연한 전제이고 문제는 어떻게 암호화하느냐이다.
전체적으로 찾아봤을때는..크게 세가지 방안이 있는것 같았다.
1) 카드번호를 PG사에서 대외API를 통해 받아온다면, 그 자체로 암호화되어있으므로 그대로 저장한다.
2) 국가보안기술연구소 및 전 세계적으로 통용하는 표준 암호화 알고리즘(LEA/AES 등)을 사용한다.
3) PG사에서 제공하는 암호화된 결제키와 카드번호를 혼합하는 등 특정 숫자를 조합한다 -> 하지만 이 방법은 PG사에서 암호화된 결제키가 아닌 번호(카드번호)에서 특정 규칙, 보안 취약성을 보일 수 있을 것 같아서 더 개선된 방법이 있지 않을까 생각해보았다.
결국 암호화된 결제키나 번호를 받아서 사용한다는 것인데, 내부적으로 한번 더 암호화한다면 더 강력한 조치가 이루어지지 않을까 생각해보았다.
법률과 관련된 부분이 많으므로 한번은 정리를 해야할 것 같다.
3. 참고자료
XSS/시큐어코딩 - https://kevinthegrey.tistory.com/m/36
XSS 종류 - https://www.skshieldus.com/blog-security/security-trend-idx-06
민감성 개인정보 저장 방안 - https://okky.kr/questions/1129024
보안 법률 - https://m.blog.naver.com/n_privacy/222863803209
