모든 플랫폼이 보안을 진지하게 다룬다고 말합니다. 하지만 침해 사후 보고서에서도 그렇게 말하는 곳은 없습니다 — 그때가 되어서야 형용사 대신 아키텍처를 설명하니까요. 그러니 바로 아키텍처로 넘어가겠습니다. 테넌트 격리를 설명하는 가장 쉬운 방법은 팀들이 흔히 저지르는 세 가지 실수와 그로 인해 무엇이 무너지는지 살펴보는 것입니다.
실수 하나: 애플리케이션 코드에서 테넌트 ID로 필터링하기
이것이 기본값이 되는 이유는 가장 당연해 보이는 방법이기 때문입니다: 모든 쿼리에 WHERE user_id = ? 절을 붙이고, 모든 개발자가 이를 기억하는 한 모든 요청은 각자의 경계 안에 머무릅니다. 문제는 나중에, 코드베이스에 엔드포인트가 4개가 아니라 400개가 되었을 때 드러납니다. 누군가 두 테이블을 조인하는 리포팅 쿼리를 추가하면서 두 번째 테이블의 필터를 빠뜨립니다. 다른 누군가는 "내부용으로만" 쓸 관리 도구를 만들면서 테넌트 범위 지정을 아예 하지 않습니다, 당시엔 안전하다고 느꼈기 때문이죠. 두 실수 모두 테스트에 걸리지 않습니다. 쿼리는 여전히 유효한 행을 반환하니까요 — 다만 엉뚱한 테넌트의 유효한 행일 뿐입니다.
모든 쿼리가 알아서 정중하게 물어보길 바라며 의존하지 않습니다. 행 수준 보안이 데이터베이스 계층에서 강제되므로, 호출하는 코드가 무엇을 요청했든 데이터베이스 자체가 다른 테넌트의 행을 반환하기를 거부합니다. 요청 경로 어딘가에 특권 우회 경로가 숨어 있지도 않습니다 — 정책은 우리가 신뢰할 수 있다고 착각하기 쉬운 경로를 포함해 항상 적용됩니다.
실수 둘: 샌드박스를 경계가 아닌 최적화로 취급하기
여기서 에이전트는 실제 코드를 실행합니다 — 그것이 이 제품의 핵심이니까요 — 그리고 흔한 유혹은 그 코드를 편리한 곳에서 실행하고 "나중에 여유 생기면" 잠그는 것입니다. 이 방식이 낳는 참사는 빌드 중 끌어온 손상된 의존성이 오픈 인터넷으로 접속을 시도하거나, 한 테넌트의 에이전트 실행이 절대 봐서는 안 될 워크스페이스의 파일을 읽는 형태로 나타납니다. 파일 시스템이 기본적으로 공유되고 예외적으로만 제한되었기 때문입니다.
대신 에이전트 워크로드는 격리된 환경에서 실행됩니다:
- 잠긴 파일 시스템.
- 열린 문이 아니라 허용 목록 방식의 네트워크 외부 접속.
당신의 빌드를 작업하는 에이전트는 오직 당신의 워크스페이스만 봅니다, 그게 전부입니다. 신뢰할 수 없는 코드 — 당신 자신의 앱 빌드를 포함해서 — 는 격리가 설정이 아니라 구조적으로 보장되는 컨테이너 내부에서 컴파일됩니다.
실수 셋: 에이전트에게 자격 증명을 넘기기
이것이 가장 미묘한 실수이고, 가장 많은 팀을 허를 찌를 것이라고 짐작합니다. 에이전트가 당신의 호스트에 배포하거나 스토어에 게시해야 한다면, 가장 빠른 방법은 OAuth 토큰이나 SSH 키를 컨텍스트에 넣고 에이전트가 쓰게 하는 것입니다. 그것은 동시에 재앙으로 가는 가장 빠른 길이기도 합니다 — 프롬프트 인젝션으로 조작된 지시, 환각으로 만들어진 행동, 있어서는 안 될 어딘가의 트랜스크립트 로그에 남게 되는 자격 증명. 이런 일이 벌어지는 데 에이전트가 악의적일 필요는 없습니다 — 실제 키를 손에 쥔 채 단 한 번만 잘못하면 됩니다.
그래서 에이전트는 절대 키를 직접 갖지 않습니다. 연결된 자격 증명은 당신의 테넌트 범위로 저장되며, 연결한 그 작업에만 사용됩니다:
- 스토어 계정
- 소셜 OAuth 토큰
- 배포 키
- Google 서비스 계정
에이전트가 배포하거나 업로드해야 할 때는 플랫폼에 실행을 요청합니다. 플랫폼이 자격 증명을 보유하고 해당 작업을 수행합니다. 에이전트는 자신이 사용을 요청한 비밀 값을 절대 보지 못합니다. 그리고 애널리틱스 쪽에서는, Google 속성이 여러 사이트에 걸쳐 공유되는 경우가 있으므로 모든 GA4 조회에 호스트명 필터를 적용합니다. 그래서 기반이 되는 속성이 여러 도메인의 데이터를 수집하더라도 당신의 대시보드에 실수로 다른 사람의 수치가 표시되는 일이 없습니다.
무엇이든 배포되기 전에 실제로 확인되는 것
이 플랫폼 전반에 적용되는 두 가지 규칙이 있으며, 바로 이 지점에서 가장 중요합니다:
- 에이전트는 당신의 돈을 쓸 수 없습니다.
- 에이전트는 당신인 척 게시할 수 없습니다.
둘 다 당신의 클릭을 필요로 합니다. 즉, 자동화된 구성 요소가 아무리 최악의 날을 맞아도 당신의 지갑이나 평판에는 손을 대지 못한다는 뜻입니다 — 피해 범위는 에이전트의 판단력이 아니라 설계 자체로 제한되어 있습니다. 보존 및 삭제에 관한 자세한 내용은 개인정보 처리방침에서 확인하실 수 있으며, 삭제 요청은 30일 이내에 처리됩니다.
