Springboot 개인정보 암복호화 저장 (1) A-Z 과정 기록

이직 한 달 차, Springboot 한 달 차. 신규 프로젝트를 인수인계 받았다. springboot, Gradle, JPA로 기본적인 개발이 된 상태였고, 나는 요구사항에 따라 암복호화, 외부 API 연동, DB 모델링 변경, UI 변경을 하게 되었다.

이번 암호화 적용기를 통해 다룬 분들과 미래의 내가 더 정교하고 깔끔하게 진행하기를 바라며 경험을 공유한다.

이번 포스팅은 4-5개로 진행될 예정이고, 다음 포스팅에는 암호화 알고리즘을 어떻게 선택했는 지에 대해 말하겠다.

• 프로젝트 배경 간단 설명

  이번에 맡게 된 디지털 헬스케어 관련 프로젝트는 환자의 건강검진 기록을 외부 병원 API에 송신하여 환자의 기대수명과 건강나이, 질병 발병률을 예측해주는 서비스이다. 환자의 건강검진 기록은 임시로 저장되며, 송수신 시에도 암호화는 필수이다. 건강검진 기록에는 키, 몸무게부터 혈당, 콜레스테롤 수치, 요단백 등의 의료 정보가 포함되어있다.

 

---

이번 포스팅 시리즈를 통해 암복호화 작업을 어떤 순서로 진행하였는지, 무엇을 고려하였는지 공유한다.

목차

1. 암호화 대상과 법률적 근거

   이번 포스팅에서는 암호화 대상 데이터와 그에 대한 법률적 근거를 어디서 얻었는 지 정리해보겠다.

   막상 검진 기록을 암호화를 하려고 하는데, 어떤 데이터가 암호화해야 할 "바이오 정보"인지 정확히 알지 못했기 때문에 내가 도움이 되었던 문서의 일부 내용을 공유한다.

    

2. 암복호화 알고리즘 선정 기준

   내가 데이터 암복호화를 적용하기 위해 알아보기 전 까지는 이렇게 다양한 알고리즘이 있는 지 몰랐다.

   암복호화 알고리즘은 굉장히 다양하고, 데이터의 성격에 따라 알고리즘을 고르는 기준도 다르다. 비밀번호는 일방향 해쉬함수 알고리즘을 채택하라는 가이드가 존재하는 지도 몰랐다.

   나같은 알고리즘맹이 어떻게 암복호화 알고리즘을 선택했는지에 대해서는 다음 포스팅에 이어서 써보겠다.

   • 암호화 알고리즘 유형별 대표 알고리즘
     • 대칭키 알고리즘 (SEED, ARIA, LEA, HIGHT, AES, Blowfish, Camellia 등)
     • 일방향(해쉬함수) 알고리즘 (SHA-2, SHA-3 등)
     • 공개키 알고리즘 (RSA, EIGamal, ECC 등)

   내가 바이오 정보를 암복호화하기 위해 어떤 알고리즘을 어떤 근거로 선택했는지 설명한다.

    

3. DB에 저장하기 (모델링과 인코딩)

   데이터 암복호화 기능 구현까지 성공했다. 이제 데이터베이스에만 저장하면 되는데 🙂...

    

4. 암복호화 주체와 시점 (변화에 대한 유연성)

   좋아. 암호화된 데이터를 DB에 저장하는 것까지 구현했다.

   이제 어떤 시점에 암복호화를 하는 것이 좋을지, 암복호화에 대한 의무를 어떤 주체에게 부여하는 지에 따라 나의 시스템의 "변화에 대한 유연성"은 어떻게 달라질 지 고민해보자.

   각 시점별로 어떤 장단점이 있는 지 간단하게 정리해본다. (다른 방법이 더 있을 것이다.)

   1. JPA AttributeConverter를 활용
   2. filter로 view ↔ controller 시점에 직렬화/역직렬화처럼 구현
   3. util처럼 암복호화 함수로 만들어서 service 단에서 적용

    

5. 비밀키 관리

   소중한 고객 정보를 암호화하여 DB에 저장했는데, 고객 정보를 암복호화할 수 있는 비밀키를 털리면 어떻게 될까? 비밀키를 안전하게 보관하는 방법에 대해 생각해보았다. 암호화 솔루션은 비용이 발생하기 때문에 제외하였다.

   1. 별도 서버에서 비밀키 관리
   2. 동일 서버 내 별도 파일로 분리하여 관리 (git에는 절대 올리지 않음)
   3. 프로퍼티로 관리 (프로퍼티값을 암호화할 수 있음)

    

---

암호화 대상과 법률적 근거

왜 암호화해야하는가?

1. 법률 조항 근거

   아래 근거에 따라 바이오 정보는 송수신 및 DB 저장 시 암호화를 해야한다.

   • 개인정보 보호법 - 암호화 관련 근거

     • 「개인정보 보호법」제24조(고유식별정보의 처리제한) 및 동법 시행령 제21조(고유식별정보의 안전성 확보 조치) • 「개인정보 보호법」제24조의2(주민등록번호 처리의 제한) 및 동법 시행령 제21조의2(주민등록번호 암호화 적용 대상 등) • 「개인정보 보호법」제29조(안전조치의무) 및 동법 시행령 제30조(개인정보의 안전성 확보조치) • 「개인정보의 안전성 확보조치 기준」(행정자치부 고시 제2016-35호)

   • 개인정보의 안전성 확보조치 기준 (행정자치부 고시, 제2016-35호)

     제7조(개인정보의 암호화)

     1 개인정보처리자는 고유식별정보, 비밀번호, 바이오정보를 정보통신망을 통하여 송신하거나 보조저장매체 등을 통하여 전달하는 경우에는 이를 암호화하여야 한다.

     2 개인정보처리자는 비밀번호 및 바이오정보는 암호화하여 저장하여야 한다. 다만, 비밀번호를 저장하는 경우에는 복호화되지 아니하도록 일방향 암호화하여 저장하여야 한다.

     3 개인정보처리자는 인터넷 구간 및 인터넷 구간과 내부망의 중간 지점(DMZ : Demilitarized Zone)에 고유식별정보를 저장하는 경우에는 이를 암호화하여야 한다.

     4 개인정보처리자가 내부망에 고유식별정보를 저장하는 경우에는 다음 각 호의 기준에 따라 암호화의 적용여부 및 적용범위를 정하여 시행할 수 있다.

     1. 법 제33조에 따른 개인정보 영향평가의 대상이 되는 공공기관의 경우에는 해당 개인정보 영향평가의 결과 2. 암호화 미적용시 위험도 분석에 따른 결과

     5 개인정보처리자는 제1항, 제2항, 제3항, 또는 제4항에 따라 개인정보를 암호화하는 경우 안전한 암호알고리즘으로 암호화하여 저장하여야 한다.

     6 개인정보처리자는 암호화된 개인정보를 안전하게 보관하기 위하여 안전한 암호 키 생성, 이용, 보관, 배포 및 파기 등에 관한 절차를 수립·시행하여야 한다.

     7 개인정보처리자는 업무용 컴퓨터 또는 모바일 기기에 고유식별정보를 저장하여 관리하는 경우 상용 암호화 소프트웨어 또는 안전한 암호화 알고리즘을 사용하여 암호화한 후 저장하여야 한다.

     8 [별표]의 유형1 및 유형2에 해당하는 개인정보처리자는 제6항을 아니할 수 있다.

      

     부칙<제2016-35호, 2016. 9. 1.>

     제2조(적용례) 영 제21조의2제2항에 따른 주민등록번호의 암호화 적용시기 이후에는 고유식별정보 중 주민등록 번호는 제7조제4항을 적용하지 아니한다.

   도움이 되었던 문서는 KISA 한국인터넷진흥원에서 제공한 [개인정보의 암호화 조치 안내서(개정).pdf]이다.

   2017년도에 개정된 문서이고, 암호화에 대한 법률적 근거와 안전하게 개인 정보를 보호하는 것에 대해 안내하고 있다.

   💡

   개인정보의 암호화 조채 안내서(개정) ⇒ https://www.kisa.or.kr/public/laws/laws3_View.jsp?mode=view&p_No=259&b_No=259&d_No=78&ST=total&SV=

2. 서비스 고객을 위해

   법률 조항이 아니더라도 자사 서비스의 고객 정보를 안전하게 지키기 위해서는 어떤 조치가 필요하다고 생각한다.

3. 회사에서 시켰..

 

암호화 대상은 무엇인가?

💡

「개인정보 보호법」에 따라 암호화하여야 하는 개인정보인 고유식별정보(주민등록번호, 여권번호, 운전면허번호, 외국인등록번호), 비밀번호, 바이오정보를 저장·전송하는 개인정보처리자를 대상으로 한다.

사실 이런 안내를 보아도 여전히 헷갈린다. 확실하게 알고 싶으면 전문가에 물어보라는 것이다.

법률에 근거한 개인정보 보호 방법은 해당 법률을 잘 아는 정부 기관에서 배포한 안내서가 제일 정확할 것이다. 정부의 공식 문서를 읽고, 이해가 가지 않는 부분은 정부 기관에게 질문하라.

 

암호화 대상을 정교하게 구분하는 것은 도메인 로직 처리와도 밀접한 관련이 있다. 보수적으로 웬만한 데이터를 암호화하는 것도 좋으나, 내가 어떤 데이터를 제공해야하는 지에 따라 고민거리가 생긴다.

예를 들어, 검진 기록 데이터는 고객ID + 검진일 + 검진 결과(키, 몸무게, 혈당 등)으로 구성되어 있다.

한 명의 고객에게는 N건의 검진 기록이 있을 수 있다. 이 목록을 표시하기 위해 최근 일자로 내림차순 하거나, 제일 최근 일자의 검진 기록만 표시해야 한다고 했을 때, "검진일"이 DB 내에서 암호화되어 있으면 어떻게 해야할까?

"검진일"이 암호화 대상이라면 어쩔 수 없이 해당 결과를 제공하기 위한 방법을 다시 알아봐야 한다.

하지만 굳이 암호화할 필요가 없다면, 조금 더 편하게 개발할 수 있지 않을까?

사실 "검진일"이 암호화 대상이 아니기를 바라는 마음에 현재 정부기관에 문의한 상태이다^^...

 

---

p.s

저는 암호화 적용이 처음입니다.

이 포스팅을 보고 "나도 이렇게 적용해야겠군." 보다는 "나는 최소한 이 사람보다 이런 것들을 더 고려해야겠군."으로 봐주시면 좋겠습니다.

보시고 부족한 점은 댓글로 도움 주시면 감사하겠습니다.