QueryPie Protocol 개발기 1편 (부제: 안전한 데이터 암호화, AWS KMS & AES)
--
“하루에 5억 규모의 쇼핑몰을 운영하는 회사가 있다고 해보죠. 사용자가 지속해서 늘어나면서 서비스 규모도 커지고, 회사 조직도 점점 더 커지고 있습니다.
그러던 어느 날, 새로운 개발자가 입사했습니다.
개발자 찾는 게 어디 쉬운 일이 아니다보니, 아쉬운 대로 신입개발자를 채용하게 됐는데, CTO는 걱정이 이만저만이 아닙니다.
웹 서비스를 구성하는 데이터베이스에는 테이블이 수백 개가 넘고, 하루에 수천만 건의 데이터가 쌓이는데, 이 데이터베이스 정보를 신입이 개발자에게 알려주려고 하니 혹시라도 실수라도 할까 봐 말이죠.
데이터베이스 툴을 사용하다가 Truncate를 잘못 하면 어떻게 할까, 혹시라도 UPDATE, DELETE 쿼리를 실행하면 어쩌나…
게다가 최근 개발자 뿐만 아니라 기획/마케팅 조직에서도 광고/프로모션을 위한 사용자 데이터를 매일 요청하고 있는데, 제시간에 맞춰 주기가 여간 힘든 게 아닙니다.
데이터베이스에서 직접 SQL을 실행할 수 있도록 권한을 열어주고 싶은데, 패스워드가 노출되는 것도 걱정되고 신입개발자처럼 데이터베이스를 잘못 조작할까 봐 걱정됩니다.”
이런 이야기, 어디서 많이 들어보셨다면 바로 여러분의 회사일 수 있습니다.
최근에는 어떤 산업이든 불문하고 IT 기술 융합 없이는 성공하기 어려운 게 사실입니다. 결국, 데이터를 저장하기 위한 저장소로 데이터베이스를 사용하게 되고, 그중에서도 RDBMS(관계형 데이터베이스 시스템)을 가장 많이 사용하는 것이 업계 표준으로 자리 잡고 있습니다. (아직 우리 회사에 데이터베이스가 있는지 없는지 모르신다면 IT 조직에 물어보세요! 1개, 혹은 수십개를 사용하고 있을수도 있습니다)
하지만 빠르게 발전하는 데이터베이스와는 달리, 데이터베이스를 좀 더 쉽고, 빠르고, 안전하게 다룰 수 있는 관련 소프트웨어들은 발전 속도가 뒤떨어지고, 그나마 있는 솔루션들도 너무 고가라 88%나 되는 스타트업, 중소기업이 사용하기에는 너무나 부담이 큰 것이 사실입니다.
이에 체커는 기업 내 모든 구성원이 데이터베이스를 ‘안전'하면서도 ‘쉽고’, ‘빠르게’ 다룰 수 있도록 하는 데이터베이스 협업/보안 기능들을 개발하고 있습니다.
그 중, 오늘 이야기할 주제는 QueryPie Protocol의 첫 번째 과제로 진행 중인 “데이터베이스 접속정보 관리 및 접근 제어” 입니다.
앞서 예를 들었던 상황은 수많은 회사가 겪고있는 고질적인 문제이며 데이터베이스를 보수적으로 운영하고 있는 가장 큰 이유중 하나라 생각됩니다. 하지만 관리자가 데이터베이스 정보를 한 곳에만 등록하고, 사용자 별로 읽기전용/DML/DDL 권한 및 접근 가능 테이블 등을 설정할 수 있다면 떨까요?
QueryPie Protocol 를 통해 관리자만 데이터베이스 접속 정보를 관리할 수 있게 되니 안전하게 보관함과 동시에 조직 구성원 모두가 허용된 권한 내에서 안전하게 데이터베이스에 접근할 수 있습니다.
하지만 QueryPie Protocol을 만드는 체커 입장에서는 수많은 회사의 데이터베이스 접속 정보가 저장되기 때문에, 각 회사의 데이터베이스 접속 정보를 안전하게 보관하고, 조회할 수 있도록 완벽한 수준의 암호화가 필수적입니다.
여러 암호화 알고리즘과 옵션들을 고민하다, 결국 UI/UX를 고려하여 서비스 운영에 가장 적합한 대칭 키 암호화로 선택지를 좁혔습니다.
하지만 대칭 키 암호화를 가장 큰 단점은, 암호화/복호화에 사용하는 키가 같기 때문에, 키가 유출되면 누구나 같은 키로 암호화한 데이터를 복호화할 수 있다는 문제가 있습니다. 결국, 암호화 키를 다음 조건으로 관리할 수 있어야 합니다.
- 데이터를 암호화한 키가 노출되지 않도록 해야 합니다.
=> 데이터를 암호화한 키는 데이터베이스에 저장하지 말아야 합니다.
=> 하지만 암호화키가 없이는 복호화가 불가능하니, 암호화키를 다시 찾을 수 있는 또 다른 키를 어딘가에 보관해야 합니다. 이를 Recovery Key라고 부르기로 했습니다. - 최악의 경우 설령 암호화키를 복구할 수 있는 Recovery Key키가 노출되더라도, 암호화키를 복구할 수 없도록 원천 봉쇄할 방법이 필요합니다.
100% 보안은 존재할 수 없으니, 항상 최악의 상황을 가정하고 대응할 수 있는 시스템과 매뉴얼이 있다면 가능한 일이라 생각하고, 첫 번째와 두 번째를 만족하게 할 수 있는 키 관리 시스템을 구현해야 했습니다.
먼저, 키 관리는 체커가 아닌 제3자에 의해 안전하게 관리되도록 하고, 유출되더라도 두 번째 조건을 만족할 수 있도록 하는 키 관리 솔루션이 필요했습니다.
여러 옵션 중 AWS에서 제공하는 KMS(Key Management System) 가 제가 생각했던 두 가지 조건을 모두 만족하고 있었고 연동해보니 사용법 또한 매우 간단했습니다.
AWS KMS를 사용하면 다음 프로세스로 데이터를 암호화할 수 있습니다.
- KMS에 암호화를 위한 키를 요청합니다.
- KMS에서는 암호화를 위한 키와, 암호화를 위한 키를 한 번 더 암호화한 키를 줍니다. (앞서 Recovery Key라고 부르기로 한 키)
- KMS에서 받은 암호화 키로 데이터를 암호화합니다.
- 암호화 키는 폐기하고 (어떤 곳에도 저장하지 않고, 사용한 변수는 즉시 null로 할당합니다), Recovery Key는 안전한 곳에 숨겨둡니다. ( 데이터베이스든, 파일이든, S3 든, 암호화 데이터를 저장하는 위치와는 다른 또 다른 제 3의 위치에 보관합니다 )
암호화가 끝나면, 암호화에 사용한 키는 이미 폐기되었고, Recovery Key만 남아있는 상태입니다. 이제 다음과 같이 복호화가 가능합니다.
- KMS에 Recovery Key로 암호화 키를 복호화하는 요청을 보냅니다.
- KMS는 Recovery Key를 통해 당시 암호화했던 키를 알려줍니다.
- KMS에서 받은 암호화키로 암호화된 데이터를 복호화합니다.
- 복호화 후에는 암호화 때와 같이 암호화키를 폐기합니다.
- KMS에서 받은 Recovery Key를 암호화 때와 같이 제 3의 위치에 보관합니다.
이렇게 KMS 암/복호화 API 요청에는 Master Key라는게 필요한데요, 이 키는 AWS IAM에서 발급하는 키로 언제든 생성/폐기가 가능합니다. 따라서 최악의 경우 Recovery Key가 노출되더라도 마스터키를 AWS IAM에서 폐기하면, 해커는 암호화한 키를 영영 얻을 수 없습니다.
AWS KMS 기반의 AES 암호화로 구현된 시스템을 해커가 공격한다면 다음 절차가 진행될 텐데요.
- 해커는 가장 먼저 QueryPie Protocol웹서버와 데이터베이스를 해킹해야 한다.
- 해킹 후에는 AWS 계정을 해킹한 후 AWS Master Key를 알아낸 다음, KMS API에 Recovery Key를 보내서 암호화키를 알아낸다.
- 알아낸 암호화키로 모든 데이터를 복호화한다.
체커는 이를 방어하기 위해 다음과 같이 시스템을 구축하고, 운영 매뉴얼을 만들고 있습니다.
- 체커는 QueryPie Protocol 웹서버와 데이터베이스를 모두 AWS VPC Private Network 환경에서 운영한다. Load Balancer를 통해서만 웹 80/443 요청을 받는다.
- AWS계정에 2FA 인증을 활성화 하고, 소스코드에 있는 Master Key는 노출되지 않도록 C 소스코드에 포함시켜 빌드한 후, JNI로 연결하여 Java에서 사용한다.
- 서버 모니터링과 침입탐지 시스템을 통해 최악의 경우 웹 서버와 데이터베이스가 해킹되었다는 사실을 감지하면, 즉시 Master Key를 폐기한다.
쉽고, 편하면서도 “안전” 한 서비스를 만든다는 건 무척 어려운 일입니다. 하지만 사용자의 데이터를 안전하게 저장하고, 보관하고, 유출되지 않도록 하는것은 서비스 제공자가 가져야 할 가장 중요한 원칙 중 하나라고 생각합니다.
체커는, 오늘도 더 쉽고, 편하면서도 “안전”한 데이터베이스 업무 환경을 만들기 위해 고민합니다!
체커에서는 업계 최고의 인력들과 함께 QueryPie Protocol을 개발할 동료를 상시 모집하고 있습니다. 현재 블록체인 스토리지 및 Java 애플리케이션 개발 포지션이 열려있습니다. 회사에 대한 자세한 내용과 채용공고는 Workable에 있습니다.
