Namespace를 둘로 나누고 TLS를 켜면 서로 다른 문서 처리 서비스가 안전하게 분리될까? 이름과 암호화 설정만으로는 이 질문에 답할 수 없다. 누구의 연결을 받아들이는지, 그 사람이 어떤 API를 호출할 수 있는지, 공유 자원을 얼마나 쓰는지가 서로 다른 문제이기 때문이다. 이번 초안에서는 허용량 예약부터 결과 저장과 예약 확정까지 이어지는 가상 실행을 두고 접근 통제를 구분한다.
아래 실험은 외부에 노출되지 않는 시험 환경을 전제로 한 제안이다. 실제 보안 구성을 완료했다는 보고가 아니며, 사용한 Server 릴리스의 설정과 인증 방식을 확인한 뒤 실행해야 한다.
Namespace는 실행을 구분하는 단위다
Namespace는 Workflow와 관련 자원을 구분하는 단위다. 서로 다른 환경이나 애플리케이션의 실행을 나누고, 종료 이력을 얼마 동안 보존할지 같은 설정을 관리할 수 있다. Client와 Worker도 자신이 접근할 Namespace를 지정한다.
그러나 이름을 아는 누구나 다른 Namespace를 요청할 수 있다면 이름만 나눈 것으로 접근을 막았다고 할 수 없다. 공식 문서는 self-hosted Service에서 Authorizer를 구성하지 않으면 기본적으로 API 요청을 허용한다고 설명한다. Namespace를 만들었다는 사실과 그 Namespace에 접근할 권한을 제한했다는 사실을 별도로 확인해야 하는 이유다.
물리적 용량 격리도 자동으로 완성되지 않는다. 같은 Service와 DB를 쓰는 Namespace들은 기반 자원을 공유할 수 있다. 한쪽의 과도한 요청이 다른 쪽에 주는 영향을 막으려면 제한 설정, 부하 시험, 필요할 때 별도 배치까지 검토해야 한다. Namespace를 보안과 성능을 모두 해결하는 만능 경계로 설명하지 말자.
TLS, mTLS, 인가는 서로 다른 질문에 답한다
TLS는 통신 내용을 보호하고 상대 서버를 확인하는 데 사용한다. mTLS는 서버도 클라이언트 인증서를 확인하도록 한다. 따라서 신뢰하는 인증서로 연결했는지 확인하는 단계와 “이 연결이 예약 확정 Workflow를 시작해도 되는가”를 결정하는 단계는 다르다.
Temporal의 ClaimMapper는 전달된 인증 정보에서 권한 판단에 필요한 정보를 만든다. Authorizer는 요청한 API와 대상, 그 권한 정보를 바탕으로 허용 여부를 결정한다. 어떤 인증 수단을 사용할지와 어떤 역할을 부여할지는 선택한 배포 구성에서 구체화해야 한다. 모든 환경에 동일한 인증서 역할 매핑을 적용할 수 있다고 가정하지 않는다.
예를 들어 문서 처리 Worker에는 필요한 작업을 받아 결과를 보고할 권한이 필요하다. 운영자가 실행을 조회하는 권한과 Namespace를 관리하는 권한은 그와 다르다. 하나의 강한 자격증명을 모든 프로세스에 넣으면 설치는 간단해져도 어떤 기능이 실제로 필요한지 검증하기 어렵다.
UI 로그인과 API 접근도 따로 시험한다
웹 화면에 로그인 페이지가 보이면 보호가 끝난 것처럼 느끼기 쉽다. 하지만 Client와 Worker는 UI를 거치지 않고 Service API에 접근한다. UI의 SSO만 설정하고 API 쪽 인가를 확인하지 않으면 화면 밖에서 가능한 작업을 놓칠 수 있다.
실험에는 적어도 조회용 주체, Worker용 주체, 관리용 주체를 개념적으로 구분한다. 여기서 주체는 요청을 보내는 사용자나 프로그램을 뜻한다. 각 주체가 사용할 수 있어야 하는 동작을 먼저 적고, 설정 결과를 그 표와 대조한다. 권한 이름을 외우는 것보다 의도한 허용과 거절을 재현하는 것이 중요하다.
| 시험 요청 | 기대하는 판단의 예 |
|---|---|
| 조회 주체가 실행 상태를 읽음 | 담당 범위이면 허용 |
| 조회 주체가 실행을 종료함 | 별도 권한이 없으면 거절 |
| Worker가 담당 작업을 처리함 | 필요한 범위에서 허용 |
| 같은 Worker가 다른 Namespace를 관리함 | 업무상 필요 없으면 거절 |
이 표는 권한 정책 예제다. 그대로 제공되는 역할 이름이나 기본 동작을 뜻하지 않으며 실제 API와 선택 Authorizer 구현에 맞춰 작성해야 한다.
인증은 통과했는데 권한이 과도한 실패
대표 실패는 신뢰하는 클라이언트 인증서 하나로 접속한 뒤 모든 API가 허용되는 상황이다. 연결 암호화와 인증서 확인은 성공했으므로 로그만 보면 잘 구성됐다고 오해할 수 있다. 하지만 조회만 해야 하는 주체가 실행 종료나 Namespace 변경까지 할 수 있다면 요구한 접근 통제에 실패한 것이다.
이를 확인하는 순서는 다음과 같다.
- 가상 문서 실행을 만들고 담당 Namespace를 명확히 적는다.
- 정상 자격으로 필요한 읽기와 실행 요청을 확인한다.
- 동일 자격으로 허용하지 않은 API를 호출해 거절되는지 확인한다.
- 신뢰하지 않는 자격으로 연결 자체가 거절되는지 확인한다.
- 다른 Namespace를 대상으로 같은 요청을 보내 범위 제한을 확인한다.
예상 결과는 인증 실패와 인가 실패가 구분되어 나타나는 것이다. 실패가 모두 단순 연결 오류로만 보인다면 어떤 단계까지 진행했는지 확인할 로그와 시험 방법을 보완해야 한다. 실험 결과에는 토큰이나 개인키를 넣지 않고 요청 종류, 대상 범위, 결과만 남긴다.
실행 데이터의 노출은 한 번 더 생각한다
API 접근을 통제해도 접근이 허용된 운영자가 무엇을 보는지는 별도 문제다. payload를 암호화했다면 내용 일부는 가려질 수 있지만 Workflow ID나 Search Attributes 같은 메타데이터에 민감한 내용을 넣으면 다른 경로로 드러날 수 있다. 예제에서는 실제 문서 제목이나 개인정보 대신 생성한 업무 ID를 사용한다.
인증서 교체도 단순 파일 교체로 끝났다고 가정하지 않는다. 이미 유지 중인 연결, 새 연결, 실패 재연결에서 어떤 인증서가 사용되는지 확인해야 한다. 교체 시험은 실행 중인 가상 Workflow를 두고 진행하며, 일시적인 연결 실패가 업무 실패로 이어지는지 별도 관찰한다.
검증 질문은 “유효한 인증서로 연결에 성공한 사용자가 모든 API를 호출할 수 있다면 무엇이 빠졌는가?”다. 또 “두 Namespace의 데이터 접근을 막았다는 증거가 두 Namespace의 처리 용량까지 격리됐다는 증거가 될까?”를 생각해 보자. 이 두 질문을 구분해야 운영에서 보안 설정의 범위를 과장하지 않을 수 있다.