사내 데이터 보안을 위해
데이터 보안은 숨기는 것이 아니라 보호하는 것입니다
보안과 데이터
데이터는 회사의 가치 창출을 위한 직접적인 자산입니다. 많은 회사에서 가치를 만들어내기 위해 데이터를 수집하고 회사의 방향 및 의사결정에 데이터를 이용합니다.
데이터의 중요성을 다들 인지하고 있지만, 아래와 같은 상황에서는 데이터 수집에 대한 의견이 갈리곤 합니다.
유저의 동의를 받아 얻은 급여 데이터를 바탕으로 유저에게 적절한 회사를 추천하거나, 본인의 직군 또는 직무가 미래에 얼마나 유망한지 등을 알려주는 서비스를 개발합니다.
유저의 동의를 받았다는 것은 급여 데이터가 매우 수집하기 어려운 데이터임을 의미합니다. 데이터팀 및 사업부서에서는 이 데이터를 암호화하여 안전하게 취급하길 원합니다.
하지만 개발하는 입장에서는 당장 필요하지 않은 데이터다보니, 유출 위험을 감수하고 데이터를 저장하는 것이 부담스럽게 느껴질 수 있죠.
또한 급여 데이터의 경우 개발 및 테스트하는 과정에서 서로의 급여 데이터를 볼 수 있다는 점 때문에 개발팀에서 수집을 거부하는 경우도 있습니다.
이렇게 민감한 데이터를 다룰 때 '데이터는 회사의 가치 창출을 위한 직접적인 자산' 이라는 생각을 중심에 두기가 쉽지 않습니다. 결국 데이터의 중요성과 유출 위험성을 트레이드오프로 다루며 데이터를 수집하는 입장에서는 아직 수집되지 않은 데이터를 두고 이 데이터가 왜 필요한지 설명해야 하는 아이러니한 상황을 맞게 됩니다.
개발팀과의 커뮤니케이션
데이터팀과 개발팀은 이렇게 데이터의 가치에 대해 미묘하게 다른 생각을 갖기 쉽습니다.
데이터팀 입장에서는 데이터가 앞으로 갖게 될 가치에 대해서 생각하는 반면에 개발팀 입장에서는 당장 필요하지 않은 데이터를 안전하게 취급하는 것이 시간 낭비라고 여겨질 수 있죠.
이런 이유로, 설계 단계에서 데이터를 수집하지 않으면 결국 일이 더 복잡해진다는 사실을 개발팀에 설득력 있게 전달하는 과정이 필요합니다.
데이터를 나중에 필요할 때 수집하면 안 되나요?
개발자와 커뮤니케이션하면서 흔히 겪는 이슈는 '데이터를 어디까지 수집해야 하나?' 입니다.
데이터는 필요할 때 수집하는 것이 맞습니다. 하지만 개발팀과 데이터팀은 이 '필요할 때' 라는 개념을 다르게 정의하는 경우가 많습니다.
가장 대표적인 상황이 히스토리 데이터를 다룰 때 나타납니다.
유저가 서로 매칭되는 데이팅 애플리케이션을 개발한다고 가정해 봅시다. 유저에게 다양한 상대를 보여주고 매칭을 원하는지 원하지 않는지 선택하게 합니다. 처음에는 매칭에만 집중하느라 어떤 유저가 매칭되었는지에 대한 이력을 저장하지 않았습니다.
하지만 시간이 흘러 프로덕트 오너는 유저가 매칭을 거부한 사람이 계속 추천된다는 문제를 인식하고, 하고 거부된 사람을 더 이상 추천하지 싶지 않도록 히스토리 테이블 개발을 요청합니다. 이전에 거부를 표시했던 유저는 데이터 이동이 필요하지만 데이터가 없어 할 수 없습니다.
이렇게 생각하면 이력을 저장하는 것은 당연해 보입니다. 마찬가지로 급여 데이터를 저장하지 않으면 그동안 힘들게 유저의 약관 동의를 얻어 가며 얻은 데이터는 버려집니다.
서비스 특징상 런칭하고 광고를 진행할 때 유저가 가장 많이 모입니다.
나중에 유지보수를 한다고 그만큼 데이터가 모일까요?
그리고 유지보수는 언제 진행될까요? 다음 스프린트 때 진행될까요?
프로젝트가 구체화가 되지 않은 상태에서는 우선순위가 계속 떨어질 것입니다. 그리고 계속 데이터는 버려질 것입니다.
퍼널을 저해하지 않는 선에서는 필요하다고 판단되는 데이터를 최대한 수집하는 것이 좋습니다.
데이터를 식별 불가능하도록 가공해서 드리면 안 되나요?
일반적으로 데이터는 서로 다른 정보를 연결해주는 고유한 기본키인 Primary Key로 연결된다는 사실 역시 당연하죠.
하지만 이 역시 상황에 따라 트레이드오프로 인해 간과됩니다.
만일 정보보호를 위해 유저를 암호화하는 게 아니라 아예 식별을 못하도록 데이터를 가공해 저장 한다면 나중에 그 데이터는 어떻게 연결될까요?
예를 들어 통계 데이터로만 저장한다고 해봅시다.
Raw 데이터가 없는 만큼 통계를 형성하는 과정에서 잘못된 로직이 발견될 경우 되돌릴 수도 없으며 서로 다른 출처를 연결해야 할 경우 Key가 없기에 데이터의 가치가 없어져 새로 수집해야 합니다.
Raw 데이터가 어딘가에 저장되어 있다면 이전에 수집했던 데이터도 재 가공하면서 새로 바꿀 수 있습니다.
데이터가 유출되면 어쩌시려고요?
데이터 보안은 무단 액세스 및 데이터 손상으로부터 데이터를 보호하는 프로세스를 의미합니다.
보안 프로세스가 모호하다면 오히려 외부의 무단 액세스로부터 보안이 더욱 취약해질 것입니다.
물론 내부자 액세스 및 유출이 보안 문제로 이어지는 경우도 많습니다. 그럴수록 액세스 하는 내부자의 권한 세분화 및 감사 로그를 통한 투명한 액세스 관리가 필요합니다.
우리는 개발 과정에서 데이터가 기술적으로 안전한지 보장하는 과정을 공유해야 합니다.
유출되었을 때의 책임을 개발 당사자가 오롯이 지지 않도록 말이죠.
아무도 모르는 저장 장소를 취급하거나 혼자 개발 히스토리를 이해하여 개발한 것이 보안이 아닙니다. 추후에 데이터가 필요해지거나 인수인계 등을 통해 여기에 접근하는 구성원이 늘어날수록 오히려 회사 내외로 보안이 더욱 취약해지는 결과가 발생할 거예요.
그럼 어떻게 설계해야 할까요?
AWS 서비스를 바탕으로 Raw 데이터를 어떻게 안전하게 취급했는지 소개합니다.
AWS 데이터 보안 설계여기에는 총 4가지 종류의 유저가 등장합니다.
- 클라이언트
- 정보보호 관리자
- 읽기 액세스 권한이 필요한 사람
- 개발자
클라이언트가 약관에 동의하여 얻은 데이터를 서버가 취급하게 되는데, 개발자가 개발하는 과정에서 데이터 수집을 서버리스 서비스인 Lambda로 분리합니다. Lambda 함수는 KMS 암호화 버킷에 쓰기 역할만 부여합니다. 해당하는 서버리스에는 따로 서버 접속을 하는 개념이 없기도 하고 개발자가 이 권한을 가졌다고 해서 저장소 데이터에 접근할 수는 없습니다.
정보보호 관리자는 KMS의 키를 관리하는 유저이며 Lambda에 쓰기 역할을 부여할 수 있고 권한이 필요한 유저에게 읽기 권한을 위임할 수 있는 권한을 가진 유저입니다. 읽기 권한을 가지고 있는 유저가 퇴사할 경우, KMS 키를 교체하여 보안을 강화합니다.
또한 읽기 권한을 가지고 있는 유저에게서 NDA (Non-Disclosure Agreement)를 취급하여 추가로 비밀 유지 계약을 체결하는 방향이 올바를 것입니다.
읽기 액세스 권한이 필요한 사람은 모든 행위가 CloudTrail에 감사 로그로 기록됩니다. 이 기록된 로그로 정보보호 관리자가 감사를 진행할 수 있습니다.
읽기 권한을 얻지 않는다면 개발자라고 하더라도 명시적으로 Deny 버킷 정책을 적용한 S3에 접근할 수 없습니다.
이제 허용된 권한을 가진 데이터 관리자는 아래와 같이 행 기반 / 열 기반 액세스 정책을 데이터가 한 군데로 모인 웨어하우스에 취함으로써 구성원들이 좀 더 제한된 데이터를 다룰 수 있게 합니다.
빅쿼리를 활용해서 자기 자신의 데이터만 조회 가능한 급여 데이터 테이블 사용 사례위의 예시와 같이 jim에게 이 테이블에서 본인 말고는 쿼리를 통해 다른 유저의 데이터를 볼 수 없게 하는 정책을 적용하여 급여 테이블을 관리할 수 있습니다. 통계 쿼리를 통해 다른 유저와 연봉의 총합이 40만이라는 것을 알 수 있지만, 그것이 누구인지는 알지 못합니다.
마무리
복잡한 정책과 개인정보 데이터 등과 같은 데이터는 점점 수집, 취급하기 어려워지고 있습니다. 약관 동의를 통해 어렵게 수집한 데이터를 효율적으로 잘 활용하려면 설계 단계에서부터 데이터 연결을 고려하여야 하고, 보안 프로세스를 투명하게 하여 취약하거나 결함이 있는 부분을 함께 강화해 나가야 합니다.
보안 프로세스가 모호하다면 앞서 설명했듯이 결국 누군가 접근하는 경우가 생기기 때문에 위임을 할 수 없거나 내부 데이터 유출 위험이 커지는 구조가 발생합니다.
또한 집단 지성이 무시되기 때문에 외부적으로도 오히려 보안에 취약할 수밖에 없는 시스템이 되어 버립니다.
이제는 마이데이터 시대입니다. 유저의 동의를 통해 데이터가 어떻게 관리되는지 투명하게 공유하고 회사는 그 범위 안에서 자유롭게 데이터를 취급합니다. 이를 위해 데이터를 안전하게 수집하고, 통합하고, 관리하는 것이 중요해 졌습니다.
이 내용을 통해 데이터 분야 구성원과 개발 분야 구성원의 커뮤니케이션이 좀 더 나아질 수 있기를 바라며 나아가 올바른 문화 정착으로 이어질 수 있기를 바랍니다.
