[DEV]개인정보 마스킹 처리 기준..

마스킹 처리를 위한 TLD 파일 이용에 대해서 포스팅을 올렸었다.. 그런데 생각을 해보니 마스킹 기준을 알아야 될거 아닌감.. 이건 현 회사에서 사용하는 기준이기도 하지만, 기본적으로 금감원이라던지 기타 기관에서 개인정보 마스킹 체크를 할 때 항상 내려오는 기준이다.. [내가 보기엔 시간이 흐를수록 그 기준도 변화되는 듯하다.. 내가 처음 감사를 받을 때 마스킹 기준하고 비교하면, 또 틀려졌기 때문이다..]

고로.. 어떤 회사에서건 해당 방식을 기준으로 사용할 것이라고 생각되므로 나중에 내가 어떻게 쓸지 모르니 올려둔다.. 이것도 올리기에 앞서서.. 표나 그런거로 하면 좋을텐데.. 내 상황이 상황인지라 직접 다 타이핑 했다.. 아오;; 그래도 이렇게 올리고 나면 상당히 뿌듯하단 말이지.. 캬캬캬캬캬..

식별정보..

• 성명 : 성명 중 성을 제외한 나머지 Ex. 김**
• 성명 : 성명 중 이름의 첫 번째 글자 이상 Ex. 김*용
• 성명[영문] : 영문 성명 중 앞 4자리 철자 노출 Ex. KIM **********
• 주소[지번주소] : 읍/면/동 미만의 숫자 Ex. 서울시 서초구 서초동 *** 번지
• 주소[도로명주소] : 도로명 이하의 건물번호 및 상세주소의 숫자 Ex. 서울시 종로구 세종대왕로 ***, *** 호(세종로)
• 주소[도로명주소] : 건물번호, 상세주소(동/층/호) Ex. 서울시 영등포구 여의나루로 *, *** 동 **** 호
• 주민번호[외국인 포함] : 뒤에서부터 7자리 Ex. 711231-*******
• 주민번호[외국인 포함] : 성별이 필요한 경우에는 뒤에서부터 6자리 Ex. 711231-1******
• CI : 88자리의 숫자 중 앞 7자리 노출 Ex. cDR34cv***** ~~ ****
• 연락처 : 전화번호 또는 휴대폰 뒤 4자리 Ex. 02-1234-****, 010-1234-****
• 여권번호 : 뒤에서부터 4자리 Ex. 12345****
• 이메일주소 : ID 중 앞 2자리를 제외한 나머지 Ex. at******@gmail.com

고급정보..

• 카드번호 : 카드번호 중 7~12 번째 숫자 또는 9~12 번째 숫자 Ex. 9430-20**-****-2399, 9430-2000-****-2399
• 카드번호 : Amex 15자리 카드번호체계 동일하게 적용 Ex. 9430-20**-****-239, 9430-2000-****-239
• 카드번호 : 국제카드업계 표준(PCI-DSS) 준용 Ex. 9430-****-****-239*
• 카드유효기간 : 연/월을 모두 마스킹 Ex. **/**
• 온라인 회원 ID : ID 중 앞 2자리를 제외한 나머지 Ex. at********
• 계좌번호 : 뒤에서부터 5자리 변환(단, 회원사에 오너쉽이 있는 경우 해당 회원사의 요청 기준에 준함) Ex. 430-20-1*****, 484220-01-1*****, 103-910096-*****
• I-PIN : 뒤에서부터 5자리 변환 Ex. 123*****
• 고객의 IP 주소 : 앞에서부터 3자리 변환 Ex. ***.1.1.12

이상이다.. 내가 가지고 있는 정보 및 기준을 잡고 있는 것은 위와 같다.. 서두에도 얘기 했지만, 각 회사에 따라서 기준이 또 틀릴 수도 있다.. 그런 경우에는 당연히 해당 케이스에 준해서 작업을 하면 된다.. 조금 더 여건이 괜찮아서 표로 정리한다던지 하면 더 좋을텐데 그게 좀 아쉽다.. 포스팅을 하다보면 나도 모르게 욕심이 생기는 것 같다.. ㅎㅎ..

[DEV]Tag Library Descriptor.. TLD 파일을 이용한 마스킹 처리..

지금 금감원 감사로 인해서 상당히 바쁘게 보내고 있다.. 그 중 가장 큰 문제가 되는 것이 사용자 정보에 대한 부분인데 이름, 연락처, 주소, 이메일 주소 등을 특정 기준에 맞춰서 다 마스킹[*] 처리를 해야 된다.. 개인정보 보호 때문에..

과거 이런 마스킹 문제가 생기면, JSP 에서 JSTL 태그를 쓰기 때문에 난 당연히 JAVA 에서 마스킹 처리를 해서 해당 값을 JSP 로 보내곤 했다.. 머 별다른 생각도 안했고, 그렇게 해왔기 때문에 습관처럼 그렇게 작업을 한 것이다..

하지만, 여기서 가장 큰 문제는 작업량이 많아진다는 것이다.. 왜냐면 JAVA 에서 JSP 로 보내는 부분을 수정하면, JAVA 만 수정하는 것이 아니라 JSP 에서도 수정을 해야 되는 경우가 생기기 때문이다.. hidden 처리 및 파라미터 전달 등으로 인해서 userNm 이라고하면, userNm 은 놔두고 또 userNmMask 이런식으로 추가가 되어야 하기 때문에 그만큼 수정 공수가 많이 들어간다..

그런데 왠열.. 역시 아는만큼 보인다고 해야되나.. 무식하면 손이 고생한다더니.. 딱 그말이 맞다.. ㅜㅠ.. TLD[Tag Library Descriptor] 라는 것이 있더라.. JSTL 태그를 노상 쓰면서도 내가 TLD 파일에 정의를 해서 사용자 스스로 사용할 수 있는 taglib 를 만들 생각은 전혀 못했던 것이다.. 몰랐으니 생각도 못한게 당연하긴 하다..

그래도 그나마 다행이라고 해야되나.. 많이 늦기는 했지만, 그래도 만들어서 테스트 해보고 적용을 했다.. 소스 수정본이 거의 절반으로 줄었다.. 과거에 했던 것을 다 수정할 수는 없는 노릇이고, 추가사항으로 나온 것에 대해서만 적용했다.. 앞으로는 해당 태그를 사용해서 하면, 훨씬 편하게 작업을 할 수 있을 듯하다..

그럼 얘기는 이쯤하고, 파일을 어떻게 만들어야 되는지 보자..
우선 파일은 기본적으로 WEB-INF 안에 있어야 된다..

나 같은 경우는 WEB-INF/tlds/MaskingUtil.tld 로 만들었다.. 기존에 tld 파일이 존재하면, 복사해와서 내용을 바꿔도 되고, eclipse 에서 만들어도 된다.. 모른다면 인터넷을 검색해보라.. 진짜 많이 나온다.. 그정도의 검색은 해봐야지..??.. ㅎㅎ

아래가 MaskingUtil.tld 내용이다.. 내가 캡쳐나 복사 그런게 안되는 관계로 내 소스보고 직접 다 코딩했다 ㅡㅡ.. 단, 전체는 아니고 윗 부분만 가져왔다.. 그 이후는 반복이기 때문에..

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

<?xml version="1.0" encoding="UTF-8" ?> <taglib xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee web-jsptaglibrary_2_0.xsd" version="2.0"> <description>JSTL 1.1 functions library</description> <display-name>JSTL XML</display-name> <tlib-version>1.1</tlib-version> <short-name>mask</short-name> <function> <description>이름 마스킹</description> <name>getNameMasking</name> <function-class>com.test.utils.MaskingUtil</function-class> <function-signature>java.lang.String getNameMasking(java.lang.String)</function-signature> <example>${mask:getNameMasking(String name)}</example> </function> </taglib>

위의 MaskingUtil.tld 가 기본이 되는 내용들인데.. 9라인 까지는 기본적인 선언부이기 때문에 크게 문제가 없다.. 그러므로 그 다음부터 설명을 하겠다..

10라인 <short-name> 은 JSP 에서 실제 태그 앞에 간단히 쓸 함수 명이라고 보면 된다.. MaskingUtil.tld 을 불러들이기 위한 간단한 약어정도..?? <c:if test=""> 에서 c 의 의미라고 생각하면 된다..

12~18라인이 가장 중요하면서 하나의 묶음이라고 보면 된다.. 다른 함수를 더 추가하려면 12~18라인이 하나 더 생겨야 된다..

13라인 <description> 은 말 그대로 설명이다..
14라인 <name> 함수를 호출할때 사용되는 태그명이다..
15라인 <function-class> 는 java 소스의 경로다.. 근데 실제 경로는 저게 아니지만, BCCard 내부 소스이므로 형태만 보여지도록 코딩했다..
16라인 <function-signature> 는 실행할 메소드를 명시하는데 타입까지 지정해준다..
17라인 <example> 은 말 그대로 예제를 보여준다..

이것이 소스에 대한 설명이고, 그럼 JSP 에서 써봐야 될것 아닌가.. 우선 본인이 쓰려고 하는 JSP 로 간다.. JSP 상단에 아래와 같이 선언을 해준다..

<%@ taglib prefix="mask" uri="/WEB-INF/tlds/MaskingUtil.tld" %>

여기서 prefix 이 부분이 tld 파일에 정의한 <short-name> 이다.. 이제 확 이해가 가지..??.. 위에 저렇게 선언을 하고 나면, 본인이 마스킹 처리 할 곳에 쓰기만 하면 된다.. 아래처럼 말이지.. 엄청 간단하다..

${mask:getNameMasking(unserNm)}

위처럼 감싸주면, 기존 똥장군 에서 똥*군 이런식으로 마스킹이 되어서 개인정보 보안 규칙에 부합되는 것이다..

조금 더 빨리 알았다면, 정말 손쉽게 작업을 했을 텐데.. 뼈저리게 아프다.. ㅎㅎ.. 비록 늦었지만, 알고 지나가니 그나마 다행이라고 위안을 삼는다.. 역시..

아는 것이 힘!!!

[EP]Open ID를 더욱 응원하고 싶어졌다..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

Open ID라는 녀석에 대해서 처음 들었을때 "오~ 괜찮다"라는 생각을 했었는데 최근에 더욱 응원을 하고 싶어졌다. OpenID는 대략적으로 얘기하자면 회원인증에 대한 표준 같은 거라고 할 수 있다. (그냥 사용만 해봤기 때무네 아주 개념적인 부분밖에 모른다.) 내 회원정보등은 Open ID를 제공하는 곳에서 가지고 있고 난 이 Open ID를 지원하는 사이트에 별도의 가입등을 할 필요없이 Open ID를 이용해서 로그인을 할 수 있다는 거다.

인터넷에서 회원가입이라는 것은 필수적이면서도 상당히 불편하다. 특히 우리나라에서는 무분별한 개인정보요구로 인하여 짜증이 좀 나기도 한다. 온라인은 아니지만 심지어 동네 PC방에 회원가입할 때도 주민번호를 적으라고 한다. (우기면 넘어가기도 하지만...난 왜 PC방이 개인정보를 요구하는지 아직도 모르겠다.)

어쨌든 이런면에서 Open ID라는 것은 상당히 매력적이고 닷넷패스포트나 싱글사인온처럼 특정 사이트혹은 업체의 종속적이지 않고 표준기술이라는 점에서 그 매력은 더 크다. 내가 웹상에 가입해 있는 사이트는 대충생각해도 100여개는 될것이다. 그 정보를 한 곳에서 관리한다면 그 편리성은 이루말하지 못할 것이다.

Open ID 자체는 이걸하려는 기술의 표준기술의 이름이고 이걸 이용해서 국내에서 서비스를 하고 있는 것이 오픈마루의 myid.net이다. 웹2.0을 지향하는 서비스들에서 많이 채택하고 있고 최근에는 대형포털에도 도입되고 있는 상황이다. 국내에도 OpenID커뮤니티가 존재하고 있다.


최근에 오랫동안 사용하던 비밀번호 변경시도를 하였다. 귀찮아서 계속 미루고 있었는데 최근 옥션개인정보누출사건도 있었고 너무 오랫동안 상당히 쉬운 비번을 사용하고 있었기 때문에 비밀번호는 좀더 보안높은 암호로 올리는 작업을 시도했는데 이게 만만치 않은 일이었다.

일단 사이트마다 비밀번호를 입력받는 정책이 제각각이다.

보안성을 확 높이고자 특수기호를 포함한 암호를 하기로 했었는데 곧 특수기호를 암호에 입력하도록 허용하는 사이트는 그리 많지 않다는 것을 깨달았다. 그래서 특수기호가 없이 갈라고 했는데 영문+숫자 혼합필수 정도가 대부분의 사이트의 기본적이긴 하지만 어떤 사이트는 동일한 글자를 3번이상 연속입력하는 것을 거부하고 어떤 사이트는 암호를 8자나 10자정도까지만 허용하고...

맨날 보안강화하라고 하는거 무시했는데 막상 현실을 보니까 암호의 보완성강화를 하기가 무척이나 어렵다. 사이트별로 리스트업을 하기도 참 그렇고... 여태 이런 시도를 안했던 나의 문제라고 할 수도 있지만 이런 제각각의 비밀번호 정책은 상당히 짜증을 유발했다. 보안성 높은 암호로 통일시키려 했지만 결과적으로는 이것저것의 암호가 뒤섞이고 말았다.

이런 점에서 OpenID의 장점을 몸소 체험했다. myid.net에 가서 비밀번호를 바꿔주는 것 만으로 7-8개의 사이트의 비번을 한꺼번에 바꾸었다. 이게 1-200개의 사이트였다면 하는 생각이 간절했다.

My Comment..
나도 OpenID 라는 개념은 Goolge Blog 쓰면서 보게 되었다..
당췌 이게 머지 했는데.. 조금씩 알아가고 쓰다보니.. "아하.. 이런거구나.." 하게 되었다..
살면서 아니.. 개발자로써 아주 필수는 아니지만, 알아두면..
어디가서 "아!.. 그거..??" 정도는 할 수 있을듯해서 가져왔다..
읽다 보면 글이 약간 개인 얘기 같기도 하지만.. 기본적인 개념은 드러나 있어서..
도움은 될거라고 생각한다.. [나도 그랬으니까.. ㅋㅋㅋㅋ..]