?BSG Partners / 한형주 이사
클라우드 밴더사가 제공하는 데이터베이스 서비스를 PaaS로 사용하는 경우
기관이나 기업의 관리자가 클라우드 벤더사가 제공하는 PaaS 형태의 데이터베이스를 구독하여 사용한다면, 이때는 OS레벨로 접근하여 해당 자원을 관리할 수 없다.
[그림8. 밴더사가 제공하는 PaaS형 데이터베이스를 사용하는 경우]
벤더사가 제공하는 PaaS형태의 데이터베이스를 사용하는 경우, 벤더사는 해당자원의 OS관리와 데이터베이스 관리에 모든 의무가 있고, 기관이나 기업의 관리자는 오로지 데이터베이스를 사용하는 사용자에 대한 권한관리와 데이터의 백업관리만 신경을 쓰면 된다. 매우 편리한 서비스를 받을 수 있지만, 구독한 관리자의 보안관리의 시선으로 바라볼 때, 개인정보가 데이터베이스에 저장이 된다면 선택할 수 있는 보안조치는 제한적이다.
물론 PaaS형 데이터베이스를 생성할 때 OS 커널 레벨의 암호화와 동일한 TDE(Transparent Data Encryption)를 설정할 수 있다.
[그림9. PaaS상의 MS SQL TDE 옵션 예제 (Amazon Web Service: RDS)]
[그림10. PaaS상의 MySQL 암호화 옵션 예제(MS Azure)]
하지만 이때는 보안키가 해당 벤더의 보안서비스를 사용해야 관리가 가능하게 된다. AWS는 KMS를 사용해야 하고, MS Azure는 Key Vault를 사용해야 한다.
[그림11.?Amazon Web Service의 PaaS 데이터베이스 암호화 키]
MS Azure는 Active Directory로 접근통제를 위한 권한 관리를 하고, 보안담당자가 Azure Key Vault에서 생성된 암호화키를 생성하고 해당키를 데이터베이스에 적용시킨다. 이후 암호화키의 사용로그는 Azure Monitor로부터 감사를 받을 수 있도록 저장이 된다.
[그림12. MS Azure의 키 관리 시스템]
Amazon Web Service의 경우에는 AWS KMS(Key Management Service)를 이용하여 암호화키를 관리작업을 하고 이는 IAM(Identity & Access Management)서비스를 활용하여 권한관리와 접근제어를 구현하여 프로세스간 발생된 로그는 CloudTrail에 저장되는 보안구성을 할 수 있다. 이미 많은 성공사례가 있는 입증된 보안운영 방식이다.
[그림 13.?Amazon Web Service의 PaaS 형 데이터베이스의 접근제어 구성]
하지만, 현재 온프리미스와 동시에 암호화를 운영하는 상태라면 보안관리의 포인트가 늘어나게 된다. 이때 기존에 사용하던 3rd 파티의 암호화Agent를 설치하여 OS Kernel 암호화를 제공하는 방식은 지원되지 않는다. OS 레벨로 로그인을 해야Agent를 설치할 수 있지만 PaaS 서비스의 특성상 OS 레벨로 접근할 수 없기 때문이다.
PaaS 형 데이터베이스를 사용하는 경우에는 Plug-in의 스위치 방식을 적용하려면, 해당 데이터베이스가 gateway를 별도로 설정이 가능한지 확인해야 하며, 데이터베이스에 설치작업을 해야 한다면 구현할 수가 없다. 반드시, plug-in방식을 제공하는 3rd 파티사와 사용대상의 클라우드 벤더와 호환이 되는지 확인을 해야 한다.
PaaS형 데이터베이스에서는 API 호출 방식의 암/복호화는 온프리미스의 방식과 차이가 없으며, PaaS 형 데이터베이스에서 가장 추천하는 방식이다. 암/복호화 ?명령어는 어플리케이션 서버에서 코딩되기 때문에 PaaS 형 데이터베이스의 OS 레벨 접근 또는 게이트웨이를 별도 디자인 하지 않아도 구현할 수 있다. 하지만 언제나 고려해야 할 부분이 암호화를 지원하는 보안서버의 위치를 클라우드에 둘지 아니면 기존의 네트웍 자원에서 운영할지는 암호화 빈도를 보고 판단을 해야 한다. 예를 들어, 클라우드에 저장된 정보가 온프리미스에 저장된 자원보다 사용빈도가 높고 저장된 데이터량이 많다고 가정한다면, 기존의 암호화 보안서버를 클라우드 상으로 이전하는 것이 효과적이고, 그렇지 않다면 기존 온프리미스 보안서버를 활용하는 것이 좋다. 물리적으로 떨어진 온프리미스 자원의 데이터센터와 클라우드데이터 센터 간의 네트웍 상태 또는 트랜젝션의 부하에 따라 암/복호화 성능이 좌우되는 리스크를 사전에 처리하기 위해서다.
또한, 3rd 파티 암호화가 아닌 클라우드 벤더에서 제공하는 암호화서버와 암호화 API를 사용할 수도 있다. 다시한번 집고 가자면, 보안통합관리를 위해서는 API 암호화 서버를 한가지 방식으로 통일하여 클라우드에서 지원하는 보안서버 또는 3rd 파티에서 지원하는 보안서버, 둘 중 하나의 방식으로 통합 운영하는 방법을 추천한다. 구현이 불가능하지 않는 한, 관리포인트는 무조건 늘리지 않거나 줄여가는 방안으로 장/단기 계획을 잡는 것이 언제나 옳다.
글을 마치며
클라우드 환경에서 보안 그것도 개인정보보호법을 충족시키는 것은 쉬운 일이 아니다. 각 업무 또는 시스템 담당자들에게 이해를 시켜야 하고, 시스템환경과 현재 환경에 가장 최적화 된 방식으로 선택하여 보안운영에도 부담을 주지 않도록 디자인하고 설계를 해야 하기 때문이다.?데이터베이스 암호화 위주로 작성된 본 글이 익숙한 온프라미스 환경에서 클라우드로 전환을 생각하고 있는 예비 클라우드 이용자들에게 도움이 되었으면 한다. 또한 클라우드 서비스의 특징을 이해하고 기존에 해 왔던 클라우드 또는 보안업무에 대해 조금이라도 중압감을 덜어내어 클라우드를 용이하게 사용하기를 바란다.
저작권정책
K-ICT 클라우드혁신센터의 저작물인 『퍼블릭 클라우드와 개인정보보호법 준수를 위한 데이터베이스 암호화』는 K-ICT 클라우드혁신센터에서 BSG Partners 한형주 이사에게 집필 자문을 받아 발행한 전문정보 브리프로, K-ICT 클라우드혁신센터의 저작권정책에 따라 이용할 수 있습니다.
다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.