2026-06-27
고객의 드라이브에 데이터를 둔다: 최소 데이터 보관이라는 설계 사상
업무용 SaaS의 정보 유출 리스크를 어떻게 낮출 것인가. 데이터의 실체를 고객 측에 두고, 서버 보관을 최소화하는 설계의 사고방식을 해설합니다.
쌓아 둘수록 리스크는 커진다
서비스 제공자의 서버에 고객 데이터를 쌓아 둘수록 공격을 받았을 때의 피해는 커집니다. 반대로 서버에 남기는 데이터를 줄이면 만일의 경우의 영향 범위를 구조적으로 작게 만들 수 있습니다. 지켜야 할 대상이 적을수록 방어 방식도 단순해지고 점검 누락도 생기기 어렵습니다. 설계 처음에 ‘정말로 서버에 남길 필요가 있는가’를 묻는 것이 출발점입니다.
실체는 고객의 드라이브에
일일 보고의 최종 저장처를 고객 자신의 Google 드라이브 안 스프레드시트로 하면 데이터의 관리 주체가 고객 쪽으로 돌아갑니다. 제공자는 중계만 하고 장기 보관은 하지 않습니다. 고객은 자사의 액세스 권한 설정으로 누가 볼 수 있는지를 스스로 정할 수 있고, 계약을 끝내는 경우에도 데이터의 실체는 손안에 남습니다. 데이터를 인질로 삼지 않는 설계는 도입 시의 안심으로도 이어집니다.
서버 보관은 시간을 구분한다
전송부터 승인까지의 임시 데이터만 서버에서 맡고, 승인 시에 삭제하며, 미승인이어도 최대 24시간에 자동 삭제합니다. ‘최대 24시간만 남는다’고 명시할 수 있으면 도입 측의 심사도 통과하기 쉬워집니다. 여기서 중요한 것은 삭제가 사람의 조작에 의존하지 않고 자동으로 동작한다는 점과, 보관의 상한을 말로 설명할 수 있다는 점입니다. 모호한 ‘가능한 한 빨리 지운다’로는 심사하는 쪽이 판단할 수 없습니다.
삭제만으로는 충분하지 않다
최소 보관은 강력하지만 그것만으로 안전해지는 것은 아닙니다. 통신 암호화, 쓰기 권한 분리, 조작 기록 같은 기본을 함께 갖추어야 비로소 안심하고 쓸 수 있는 상태가 됩니다. 예를 들어 맡고 있는 동안 제삼자에게 읽히지 않을 것, 쓰기 대상을 필요한 범위로 한정할 것, 나중에 무슨 일이 있었는지 추적할 수 있을 것, 이 세 가지를 한 세트로 생각하면 누락이 줄어듭니다.
도입 전에 확인하고 싶은 질문의 예
도입을 검토하는 쪽은 다음 질문을 제공자에게 던져 보는 것이 요령입니다. ‘데이터의 실체는 어디에 있습니까’, ‘서버에 남는 기간의 상한은 언제까지입니까’, ‘삭제는 자동입니까, 수동입니까’, ‘권한을 해제하고 싶을 때 어떤 절차가 됩니까’. 답이 구체적이고 구조로서 설명될수록 설계가 잘 정리되어 있다고 판단하기 쉽습니다. 반대로 답이 운영 담당자의 주의 깊음에 의존한다면 그곳이 약점이 되기 쉬운 부분입니다. 마지막으로 설계 설명이 문서로 남아 있는지도 확인해 두면 사내 결재나 재검토 때 도움이 됩니다.