엔터프라이즈 고객사와 계약을 진행하면서 "고객 데이터의 저장(Encryption at Rest) 및 전송(Encryption in Transit) 구간 암호화 적용 여부"와 함께, 

 "우리 회사가 직접 관리하는 암호화 키(BYOK)를 적용할 수 있는지"에 대한 요구사항을 전달받았습니다. 

모든 테넌트 데이터가 하나의 DB에 섞여 있는 멀티테넌트 SaaS 구조에서 테넌트별로 암호화 키를 다르게 적용하고 안전하게 관리할 수 있는 실무적인 접근 방식이 궁금합니다.

답변:

안녕하세요. SaaS 전환지원센터입니다.

멀티테넌트 SaaS 환경에서도 고객사별로 암호화 키를 구분해 데이터를 보호하는 구조를 설계할 수 있습니다. 다만 저장 및 전송 구간의 암호화와 고객사가 직접 암호화 키를 관리하는 BYOK는 서로 다른 요구사항이므로 구분해서 검토할 필요가 있습니다.

먼저 저장 구간 암호화는 DB나 스토리지에 저장된 데이터를 암호화하는 방식이며, 전송 구간 암호화는 고객과 서비스 간 또는 서비스 내부 시스템 간 데이터가 이동할 때 TLS 등을 적용해 보호하는 방식입니다. AWS를 사용하고 있다면 Amazon RDS와 같은 데이터베이스 서비스의 암호화 기능, AWS KMS 등을 활용한 키 관리 체계를 검토할 수 있습니다. 다만 저장 구간 암호화만으로는 DB에 접근할 수 있는 권한을 가진 사용자의 데이터 조회까지 차단되는 것은 아니므로, 고객사별 접근제어와 권한 관리도 함께 적용해야 합니다.

고객사별로 서로 다른 암호화 키를 적용하려면 각 테넌트에 대응하는 키를 구분해 관리하는 방식을 고려할 수 있습니다. 예를 들어 AWS KMS를 활용해 고객사별 키를 분리하거나, 데이터 암호화에 사용하는 별도의 키를 고객사별로 생성하고 이를 안전하게 관리하는 구조를 설계할 수 있습니다. 다만 DB 전체를 암호화하는 방식과 애플리케이션에서 고객사별 데이터를 개별적으로 암호화하는 방식은 보호 범위와 운영 복잡성이 다르므로, 어떤 데이터까지 고객사별 키로 보호해야 하는지 먼저 정하는 것이 중요합니다.

특히 BYOK는 단순히 고객사별로 키를 나누는 것과는 차이가 있습니다. 고객사가 직접 생성하거나 보유한 키를 서비스의 암호화 과정에 활용하고, 키의 사용 권한이나 폐기 등을 고객사가 통제할 수 있도록 하는 요구사항이 포함될 수 있습니다. 따라서 고객사가 키를 직접 보유하는지, 외부 키 관리 시스템과 연동해야 하는지, 키 사용 중지 시 서비스 데이터에 어떤 영향이 발생하는지 등을 계약 단계에서 명확히 확인해야 합니다.

실무적으로는 우선 기본 암호화 및 키 관리 기능을 활용하고, 엔터프라이즈 고객의 요구 수준에 따라 테넌트별 키 분리와 BYOK 지원을 단계적으로 검토하는 것을 권장합니다. 고객사별 키를 적용할 경우에는 키 접근 권한, 교체 주기, 폐기 절차, 장애 시 복구 방안까지 함께 설계해야 하며, 키를 분실하거나 사용이 중지되면 데이터 복호화가 불가능해질 수 있다는 점도 고려해야 합니다.

현재 사용 중인 데이터베이스 종류와 고객사가 요구하는 BYOK의 구체적인 조건에 따라 적합한 구현 방식이 달라질 수 있습니다. 추가로 궁금하신 사항이나 현재 인프라 구성에 맞춰 확인하고 싶은 부분이 있으시면 추가 질문을 남겨주시기 바랍니다.

감사합니다.