데이터 보안 시스템 기술 개발 기록(3) - '구현 범위 설정'

암호 알고리즘을 선택하고, 이젠 구현 범위와 시스템의 대략적인 설계를 진행해야하는 단계에 왔다.

우리 고객의 요구사항은 외부 업체가 제작한 블록체인 플랫폼에 자사의 데이터 저장될텐데 이때 블록체인 플랫폼을 관리하는 회사가 데이터를 마음대로 이용할 수 없도록 암호화를 걸어서 보관하고, 우리 고객의 고객사 즉, 2차 고객사가 필요한 경우 복호화해서 사용하는 것이다.

 

이 요구사항을 만족하기 위해 구현할 범위는 아래와 같다.

• 암/복호화 모듈
  암호화 표준 알고리즘을 기반으로 한 시스템 구축
• 암호 장비
  키 분배 보안성 문제를 해결하기 위해 비밀 키 알고리즘의 키 값에 대한 2차 암호화가 적용된 복호화 암호 장비 제작(외장하드/플래시 드라이브 등)
• 설계 문서
  추후 오류 및 요지보수 사항 발생 시 빠른 조치를 위해 설계문서 제작

나는 이에 맞춰 2가지 방법을 제시했는데,

첫 번째는 암호화 전용 모듈과, 복호화 전용 모듈을 따로 만들어 놓고 암호장비에는 암/복호화를 위한 비밀키가 들어있어
암호장비 없이 프로그램 작동이 불가능하게 구성하는 방식이다.

해당 방식은 고객에게 재전송하지 않아도되는 효율성이 있지만, 암/복호화 장비 및 모듈 개별 제작이 필요하고
고객이 늘어날 때 마다 암호장비를 제작해야하는 번거로움, 암호장비에 존재하는 키 주기적으로 변경할 때
암호화 키와 복호화 키를 한번에 변경해야하는데 이때 수거해서 한번에 변경해야하는 번거로움이 존재했다.

두 번째는 암/복호화를 한 곳에서 관리하는 모듈로 어느정도의 오버헤드가 있지만 암호장비 한 개를 이용해 키를 편하게 관리할 수 있고, 암호장비를 추가로 제작하지 않아도 되는 장점이 있다.

나는 두 번째 방식으로 제작하는 것으로 이야기 했으나 고객사에서는 첫 번째 방안을 선택했다.
난 1번 방식으로 제작하면 추후 문제가 있을 것으로 확신했고,

팀원들에게 언제든지 2번째 방안으로 바꾸면서 할 수 있도록 추가적인 기능을 제작할 것을 염두해두어야 한다고 당부했다.

 

이제 어떤 방식으로 진행할 지 정했으니, 필요한 정보들이 몇 개 필요했다.

- 암호화 데이터의 종류(타입) 및 크기

- 데이터를 읽어들이는 공간이나, 방법에 대한 협의

- 암/복호화된 데이터를 어떤 방식으로 출력해낼 것인지, 고객사는 어떤 형태로 데이터를 받을 것인지에 대한 정보

 

위와 같은 정보를 요청했으나, 고객사에서는 "아직 딱히 정해진 것이 없으니 다양한 타입과 범용성있는 방안을 준비해줬으면 좋겠다" 라는 답변이 왔고, 일단 범용성이 높은 JSON 데이터, csv 파일을 이용해 입/출력을 구현하는 계획을 세웠다.

 

이번 개발을 하면서 느낀건데 "디테일한 요구사항 vs 추상적인 요구사항"
둘 중 어떤게 편하냐고 물어보면 전자가 더 낫지 않을까 싶다.. ㅋㅋ