- 제1부 SaaS 보안은 설계에서 시작된다

1. 인증을 준비하면서 보안을 시작하면 늦는다

많은 SaaS 기업이 보안을 본격적으로 검토하는 시점은 제품 개발 초기보다 훨씬 뒤다. 공공기관이나 대기업 고객이 보안 인증을 요구하거나, 투자 및 납품을 위한 실사를 앞두고 있을 때 비로소 보안 체계를 점검하기 시작한다. 심지어 개인정보 유출이나 계정 침해 같은 사고를 겪은 뒤에야 문제의 심각성을 인식하는 경우도 있다.

그러나 이 단계에서는 이미 데이터베이스 구조와 사용자 권한 체계, 개발 및 배포 방식이 상당 부분 굳어져 있다. 뒤늦게 보안 요구사항을 반영하려면 일부 기능을 수정하는 수준을 넘어 서비스의 핵심 구조를 다시 설계해야 할 수 있다. 고객별 데이터 분리 방식에 문제가 발견되면 데이터베이스를 재구성해야 하고, 접근 기록이 충분히 남지 않는다면 인증과 권한 관리 체계도 손봐야 한다. 그만큼 개발 기간과 비용이 늘어나고, 서비스 운영 중단이나 데이터 이전에 따른 위험도 커진다.

특히 SaaS는 고객사 내부에 개별 설치되는 구축형 소프트웨어와 보안 환경이 다르다. 하나의 서비스를 여러 고객이 함께 이용하며, 고객의 데이터는 클라우드에 지속적으로 축적된다. 서비스 업데이트도 특정 고객에게만 적용되는 것이 아니라 다수의 고객에게 동시에 영향을 미친다. 하나의 잘못된 배포나 권한 설정 오류가 전체 고객의 보안 문제로 확산될 수 있는 구조다.

최근에는 외부 API와 생성형 AI 서비스의 활용도 늘고 있다. SaaS 내부에서만 처리되던 고객 데이터가 분석, 번역, 요약 등의 목적으로 외부 서비스에 전달될 수 있다는 뜻이다. SaaS 기업이 직접 운영하는 영역만 보호해서는 데이터의 전체 흐름을 관리하기 어려워진 것이다.

따라서 SaaS 보안을 인증 심사에 통과하기 위한 사후 대응으로 이해해서는 안 된다. 어떤 방식으로 고객 데이터를 분리할지, 누가 어떤 정보에 접근할 수 있도록 할지, 이용이 끝난 데이터를 언제 어떻게 삭제할지와 같은 결정은 제품을 설계할 때부터 이루어져야 한다. 인증서는 이러한 보안 체계가 적절하게 운영되고 있음을 확인하는 결과물이지, 보안의 출발점이 아니다.

결국 SaaS 보안은 인증 담당자만의 업무가 아니다. 제품 기획과 데이터 구조, 개발 방식, 클라우드 운영 전반에 걸쳐 함께 설계해야 하는 제품의 핵심 요건이다. 보안을 처음부터 제품에 포함할 것인지, 출시 이후 비용을 들여 덧붙일 것인지가 SaaS의 신뢰도와 성장 가능성을 결정한다.

2. 첫 번째 설계: 테넌트 간 데이터 격리

SaaS에서 ‘테넌트ʼ란 하나의 서비스를 독립적으로 이용하는 고객 조직이나 사용자 집단을 의미한다. 여러 기업이 같은 SaaS를 사용하더라도 각 기업의 사용자, 설정, 업무 기록과 파일은 서로 완전히 분리되어야 한다. 고객의 관점에서는 자신만의 독립된 서비스를 이용하는 것처럼 보여야 한다.

SaaS의 보안 위협이라고 하면 외부 공격자의 해킹을 먼저 떠올리기 쉽다. 하지만 실제로는 정상적으로 로그인한 사용자가 다른 고객의 데이터에 접근하게 되는 상황도 매우 치명적이다. 화면 주소나 요청값을 변경했을 때 다른 기업의 계약서가 표시되거나, 검색 결과에 다른 고객의 문서가 섞여 나오는 사례가 대표적이다. 공격자가 시스템을 침해하지 않더라도 데이터 격리의 작은 허점만으로 대규모 정보 노출이 발생할 수 있다.

테넌트의 데이터를 격리하는 방식은 크게 세 가지로 구분할 수 있다. 첫 번째는 고객별로 데이터베이스를 분리하는 방식이다. 격리 수준이 높고 특정 고객의 데이터 이전이나 복구가 비교적 명확하다는 장점이 있다. 반면 고객이 늘어날수록 데이터베이스의 생성, 업데이트, 모니터링에 필요한 운영 비용도 증가한다.

두 번째는 하나의 데이터베이스 안에서 고객별로 스키마를 분리하는 방식이다. 데이터베이스 자체는 공유하면서 논리적인 저장 공간을 구분하기 때문에 격리 수준과 운영 효율 사이에서 균형을 찾을 수 있다. 다만 고객 수가 많아지면 스키마 변경과 버전 관리가 복잡해질 수 있다.

세 번째는 모든 고객의 데이터를 같은 테이블에 저장하고 테넌트 식별자로 구분하는 방식이다. 운영과 확장이 상대적으로 간편하고 자원을 효율적으로 사용할 수 있지만, 데이터 조회 과정에서 테넌트 조건이 한 번이라도 누락되면 다른 고객의 데이터가 노출될 가능성이 있다. 따라서 비용이 적게 든다는 이유만으로 선택하기보다 고객의 데이터 민감도, 예상 고객 수, 운영 역량과 규제 요건을 함께 고려해야 한다.

특히 데이터 격리를 개발자의 주의력과 애플리케이션 코드에만 의존해서는 안 된다. 개발자가 조회 조건에 테넌트 식별자를 빠뜨리거나, 새로 추가한 기능에 기존 권한 검사를 적용하지 않는 실수가 발생할 수 있기 때문이다. 공통 데이터 접근 계층이나 데이터베이스의 접근 제어 기능을 이용해 모든 요청에 테넌트 조건이 자동으로 적용되도록 하는 것이 안전하다.

격리 원칙은 데이터베이스에만 적용되는 것도 아니다. 고객이 업로드한 파일과 백업 데이터, 캐시, 검색 인덱스, 분석 데이터에도 같은 기준이 적용되어야 한다. 예를 들어 원본 문서는 분리되어 있더라도 검색 인덱스가 함께 구성되어 있다면 다른 고객의 문서 제목이나 일부 내용이 검색 결과에 노출될 수 있다. 생성형 AI를 위한 벡터 데이터베이스에서도 권한과 테넌트 범위를 확인하지 않으면 다른 고객의 정보를 근거로 답변하는 문제가 발생할 수 있다.

운영자와 고객지원 담당자가 사용하는 관리자 기능도 중요한 점검 대상이다. 관리자 화면은 일반 사용자보다 넓은 범위의 데이터에 접근하기 때문에, 작은 권한 설정 오류가 더 큰 사고로 이어질 수 있다. 접근 사유와 기록을 남기고, 업무에 필요한 최소한의 범위에서만 고객 데이터를 조회하도록 제한해야 한다.

마지막으로 테넌트 격리는 설계 문서만으로 보장되지 않는다. 한 고객의 계정과 식별자를 이용해 다른 고객의 데이터에 접근할 수 없는지 자동화된 테스트를 통해 반복적으로 검증해야 한다. 새로운 기능을 배포할 때마다 데이터베이스, API, 파일, 검색 결과 등 여러 경로에서 교차 접근 가능성을 점검하는 절차도 필요하다.

멀티테넌시는 인프라와 운영 비용을 줄여 SaaS의 확장성을 높여준다. 그러나 동시에 한 번의 실수가 여러 고객에게 확산될 수 있는 구조이기도 하다. 따라서 테넌트 간 데이터 격리는 SaaS 개발이 완료된 후 확인하는 보안 항목이 아니라, 데이터 구조를 결정하는 첫 단계부터 반영해야할 핵심 설계 원칙이다.

3. 두 번째 설계: 권한 관리와 감사 로그

사용자가 로그인에 성공했다는 사실이 서비스의 모든 기능과 데이터에 접근할 수 있다는 의미는 아니다. SaaS 보안에서는 사용자의 신원을 확인하는 것과, 확인된 사용자에게 허용할 작업을 결정하는 것을 명확하게 구분해야 한다.

인증은 아이디와 비밀번호, 일회용 인증번호, 생체정보 등을 통해 사용자가 누구인지 확인하는 과정이다. 반면 권한은 인증된 사용자가 어떤 데이터를 조회하고, 무엇을 생성·변경·삭제할 수 있는지 결정하는 기준이다. 인증이 서비스의 출입문을 통과하는 절차라면, 권한은 건물 안에서 출입할 수 있는 공간과 수행할 수 있는 업무를 제한하는 장치라고 할 수 있다.

권한을 제대로 설계하지 않으면 정상적인 계정을 통한 정보 유출이 발생할 수 있다. 예를 들어 일반 직원이 인사평가 자료를 열람하거나, 퇴사 예정자가 고객 데이터를 대량으로 내려받거나,부서 관리자가 다른 부서의 기밀 문서에 접근하는 상황이다. 이러한 문제는 외부 공격이 없어도 발생할 수 있으므로 로그인 보안만 강화해서는 예방하기 어렵다.

이를 방지하려면 사용자의 역할에 따라 권한을 부여하는 역할 기반 접근통제가 필요하다. 일반 사용자는 자신에게 허용된 업무 기능만 사용할 수 있어야 하고, 조직 관리자는 소속 조직의 사용자와 설정을 관리할 수 있어야 한다. 서비스 운영자는 시스템 상태와 장애 대응에 필요한 기능을 사용하되, 고객 데이터에 대한 접근은 제한할 필요가 있다. 개발자와 고객지원 담당자도 업무상 필요하다는 이유로 전체 고객 데이터에 상시 접근하도록 허용해서는 안 된다.

여기서 중요한 원칙은 업무 수행에 필요한 최소한의 권한만 부여하는 것이다. 고객 문의를 처리하기 위해 계정 상태를 확인하는 권한과 고객이 작성한 문서 내용을 열람하는 권한은 구분할 수 있다. 개발자가 장애 원인을 조사할 때도 운영 데이터 전체에 직접 접근하게 하기보다, 민감정보가 제거된 로그나 제한된 진단 도구를 제공하는 편이 안전하다.

데이터 내보내기, 사용자 일괄 삭제, 권한 변경, 결제정보 수정과 같이 영향이 큰 작업에는 추가적인 보호 절차가 필요하다. 재인증이나 다중인증을 요구하거나, 다른 관리자의 승인을 받은 뒤 실행하는 방식을 적용할 수 있다. 특히 관리자 권한 부여와 대량 데이터 반출은 한 사람의 판단만으로 완료되지 않도록 설계하는 것이 좋다. 장기간 사용하지 않은 관리자 권한과 퇴사자 계정도 정기적으로 확인하고 즉시 회수해야 한다.

권한 관리와 함께 반드시 설계해야 하는 것이 감사 로그다. 감사 로그에는 누가, 언제, 어떤 데이터에 접근해 무슨 작업을 수행했으며 그 결과가 성공했는지 실패했는지가 남아야 한다. 로그인과 로그아웃뿐만 아니라 데이터 조회·수정·삭제, 파일 다운로드, 권한 변경, 관리자 접근, 설정 변경과 같은 주요 활동도 기록해야 한다.

다만 모든 내용을 무조건 기록하는 것이 정답은 아니다. 비밀번호나 인증 토큰, 개인정보의 원문과 같은 민감정보가 로그에 포함되면 로그 자체가 새로운 정보 유출 경로가 될 수 있다. 따라서 사건을 조사하는 데 필요한 정보는 남기되, 민감한 값은 마스킹하거나 기록 대상에서 제외해야 한다.

감사 로그가 존재하더라도 운영자가 임의로 수정하거나 삭제할 수 있다면 신뢰하기 어렵다. 로그에 대한 접근 권한을 제한하고, 별도의 저장 영역으로 전송하거나 위변조 여부를 확인할 수 있는 구조를 마련해야 한다. 서비스의 위험 수준과 관련 요건을 고려해 보관 기간을 정하고, 기간이 지난 로그를 안전하게 파기하는 절차도 필요하다. 시스템 시간의 오차로 사건 순서를 잘못 판단하지 않도록 시간 동기화 역시 관리해야 한다.

감사 로그는 SaaS 운영사만을 위한 자료에 머물지 않아도 된다. 고객 조직의 관리자가 구성원의 로그인, 파일 다운로드, 권한 변경 등 주요 활동을 직접 확인할 수 있도록 제공하면 고객도 이상 징후를 빠르게 발견할 수 있다. 필요하다면 검색과 필터링, 보고서 다운로드, 외부 보안관제 시스템과의 연동 기능도 고려할 수 있다. 이러한 기능은 보안을 강화하는 동시에 기업 고객이 SaaS를 신뢰할 수 있는 근거가 된다.

보안 사고가 발생했을 때 가장 먼저 필요한 것은 사고의 범위와 원인을 파악하는 일이다. 그러나 권한이 지나치게 넓게 부여되어 있거나 활동 기록이 남아 있지 않으면 어떤 계정이 어떤 정보에 접근했는지 확인하기 어렵다. 피해 범위를 특정하지 못하면 고객에게 정확히 설명할 수도 없고, 같은 사고의 재발을 막기도 어렵다.

결국 권한 관리는 사고의 가능성과 피해 범위를 줄이는 장치이며, 감사 로그는 사고가 발생했을 때 사실관계를 재구성하는 근거다. 보안 사고가 발생했을 때 “누가 무엇을 했는지 알 수 없다”는 것은 사고 자체만큼 심각한 문제다.

—

저작권 정책

SaaS 전환지원센터의 저작물인 『SaaS 보안은 설계에서 시작된다』은 SaaS 전환지원센터에서 『파프리카데이터랩 김유빈 대표』에게 집필 자문을 받아 발행한 전문정보 브리프로, SaaS 전환지원센터의 저작권정책에 따라 이용할 수 있습니다. 다만 사진, 이미지, 인용자료 등 제3자에게 저작권이 있는 경우 원저작권자가 정한 바에 따릅니다.