환경 간 데이터 격리

KeenAuth의 모든 환경(프로젝트마다 있는 development, staging, production)은 각각 별도의 테넌트입니다. 한 환경의 사용자, 조직, 애플리케이션, 세션, 키, 로그와 이벤트는 다른 환경에서 보이지 않으며, 같은 계정 안의 다른 환경에서도 마찬가지입니다. 이 페이지에서는 이 경계가 어떻게 적용되는지 설명합니다.

독립적인 두 가지 방어선

환경들은 데이터베이스 스키마를 공유하며, 환경에 속한 모든 행에는 해당 환경의 식별자가 포함됩니다. 격리는 두 번 적용되며, 데이터가 경계를 넘으려면 두 검사가 모두 실패해야 합니다.

애플리케이션의 타입화된 환경 범위. 모든 요청은 데이터를 읽기 전에 호스트 이름이나 자격 증명을 통해 정확히 하나의 환경으로 확인됩니다. 환경 데이터를 읽거나 쓰는 코드는 이 범위 없이 데이터베이스 트랜잭션을 열 수 없으며, 범위 없이 호출하면 쿼리가 실행되기 전에 거부됩니다.
PostgreSQL 행 수준 보안. 환경 데이터를 담는 모든 테이블에는 행 수준 보안이 활성화되고 강제 적용되어 있으므로, 이 정책은 테이블 소유자에게도 적용됩니다. 각 트랜잭션은 현재 환경을 설정하며, 행은 해당 환경이 일치할 때만 보입니다. 환경을 설정하지 않은 트랜잭션은 어떤 행도 볼 수 없습니다. 애플리케이션이나 유지 관리 역할 중 어느 것도 행 수준 보안을 우회할 수 없습니다.

환경 범위가 적용되는 모든 테이블은 기본 키와 인덱스의 시작 부분에 환경 식별자를 두므로, 격리 조건이 쿼리에 별도의 조회를 추가하지 않습니다.

토큰이나 키로 조회하기

일부 요청은 인가 코드, 새로 고침 토큰, API 키처럼 비밀 값만 전달합니다. KeenAuth는 이러한 값을 다이제스트 전용 조회로 찾은 다음, 저장된 레코드의 환경과 요청의 환경을 비교합니다. 두 환경이 다르면 해당 값은 유효하지 않은 것으로 처리됩니다.

경계를 넘을 때 보이는 응답

시도	응답
다른 환경에 속한 리소스 읽기	`404 Not Found`; 응답은 해당 리소스의 존재 여부를 드러내지 않습니다
다른 환경에서 발급된 액세스 토큰 사용	`401 Unauthorized`; 각 환경은 고유한 발급자와 고유한 서명 키(JWKS)를 가집니다
다른 환경에 등록된 클라이언트로 인증	`invalid_client`

데이터베이스 밖의 영역

같은 경계가 환경 데이터가 저장되는 다른 모든 위치에도 적용됩니다.

캐시: 모든 캐시 키는 환경 식별자로 시작합니다.
이벤트와 작업: 모든 내부 이벤트는 자신의 환경 정보를 포함하며, 소비자는 이를 바탕으로 데이터베이스 범위를 설정합니다. 큐에 저장된 모든 작업은 자신이 속한 환경 정보를 포함합니다.
키: 암호화 키와 서명 키는 환경마다 별도로 관리됩니다.
로그: 로그 줄에는 환경이 필드로 포함되며, 환경 로그 API는 호출한 환경의 항목만 반환합니다.
백그라운드 작업: 유지 관리 작업(보존 정리, 삭제)은 환경별로 실행되며, 각각 자체 범위가 지정된 트랜잭션에서 수행됩니다.

한 환경의 설정을 다른 환경으로 옮기는 작업(설정 승격)은 설정만 복사합니다. 비밀 값과 최종 사용자 또는 조직 데이터는 승격 번들에 포함되지 않습니다.

격리 테스트 방법

테넌트 간 격리 테스트 모음은 KeenAuth의 지속적 통합에서 실행되며, 실패하면 변경 사항을 차단합니다. 이 테스트 모음은 다음을 확인합니다.

환경 데이터를 담는 모든 테이블에 행 수준 보안이 활성화되고 강제 적용되어 있는지;
각 API 표면이 다른 환경의 리소스, 토큰, 클라이언트에 대해 404 또는 401을 반환하는지;
백그라운드 작업과 로그 및 이벤트 파이프라인이 입력에 지정된 환경만 처리하는지.

또한 스키마 검사는 환경 식별자 열이 없는 새 환경 데이터 테이블을 거부합니다.