파이프라인 보안: 이벤트 레이어의 제로 트러스트

SchemaBridge Team · 2026-01-03 · Security, Zero Trust

장시간 실행 워크플로를 보호하는 법. 참조 전용 시크릿, 적시(Just-in-Time) 주입, 제로 트러스트 아이덴티티.

보이지 않는 경계: 전통적인 보안이 이벤트 레이어에서 실패하는 이유

모놀리식 애플리케이션의 세계에서 보안은 단순했습니다. 서버 주위에 방화벽이라는 "요새"를 쌓았습니다. 네트워크, 하드웨어, 소프트웨어를 직접 통제했습니다. 입구에 아이덴티티 공급자(IdP)를 두었고, 일단 안으로 들어온 요청은 "신뢰된" 것으로 간주했습니다. 이것이 Castle-and-Moat(성과 해자) 보안 모델입니다.

하지만 분산되고 장시간 실행되는 비즈니스 라이프사이클 — 우리가 이벤트 레이어라고 부르는 것 — 의 시대로 넘어오면서 성벽은 무너졌습니다. 애플리케이션은 더 이상 한곳에 존재하지 않습니다. 마이크로서비스, 서드파티 SaaS API, 외부 웹훅으로 트리거되는 헤드리스 워커들의 무리입니다. 경계는 없습니다. 데이터는 끊임없이 이동하며, 직접 작성하지 않은 코드에 의해 변환되고, 완전히 통제할 수 없는 데이터베이스에 저장됩니다.

이처럼 파편화된 환경에서 옛 해자는 쓸모가 없습니다. 엔진 자체의 명령어 집합(Instruction Set)에 내장된 새로운 보안 패러다임이 필요합니다. 우리는 이를 트랜잭션 제로 트러스트라고 부릅니다.

보안의 악몽: 자격 증명 유출

아키텍트로서 여러분은 이벤트 레이어에서 근본적이고 존폐가 걸린 위협에 직면합니다. 그중 가장 치명적인 것 중 하나가 자격 증명 유출입니다.

연동에는 API 키가 필요합니다. Stripe 키, Salesforce 토큰, 내부 DB 비밀번호가 있습니다. "글루 코드" 스크립트에서는 이런 시크릿이 흔히 환경 변수에 저장되거나 JSON 페이로드에 실려 이리저리 전달됩니다. 개발자가 디버깅을 위해 실수로 console.log(payload)를 추가하거나 로깅 시스템이 침해되면, 핵심 프로덕션 시크릿이 외부에 그대로 노출됩니다. 유출되거나 부실하게 관리된 자격 증명은 클라우드 침해의 주요 원인 중 하나입니다.

SchemaBridge 보안 스택: 인프라 수준의 격리

SchemaBridge는 "좋은 코딩 관행"에만 의존하지 않고 인프라 제약으로 이러한 위협에 대응하도록 보안 모델을 설계했습니다. 예를 들어 테넌트 스크립트는 자격 증명이 없고 네트워크 egress도 없는 격리된 스크립트 러너에서 GraalVM으로 실행되므로, 스크립트가 시도하더라도 여러분의 시크릿이나 플랫폼 데이터베이스에 도달할 수 없습니다.

제로 트러스트 아이덴티티: API 키를 넘어서

분산된 여정에서 아이덴티티는 동적이고 범위가 제한되어야 합니다. 모든 워커에 단일 "루트" API 키를 사용하는 것은 재앙적인 위험입니다.

SchemaBridge는 자격 증명에 참조 전용 모델을 사용합니다.

1. 암호화된 시크릿 저장소: 프로덕션 API 키는 워크플로 설정이나 상태에 절대 저장되지 않습니다. 키는 암호화된 시크릿 저장소(EntitySecretRepository)에 보관되며, 저장 시 AES-256-GCM으로 암호화되고 키 로테이션을 지원합니다.

2. 참조만 노출: 비주얼 그래프 안에서는 이름으로 된 시크릿 참조(예: {{ secrets.STRIPE_KEY }})만 보입니다. 이름은 의도적으로 정적입니다. 표현식은 지원하지 않는데, 계산된 이름을 허용하면 페이로드가 어떤 자격 증명을 읽을지 선택할 수 있게 되기 때문입니다.

3. 적시(Just-in-Time) 주입: Gateway Vertex가 HTTP 요청을 보낼 때에만 엔진이 참조를 해석하고, 토큰을 복호화하여 나가는 헤더나 본문에 치환해 넣습니다. 시크릿은 설정 표현식이나 스크립트에서 읽을 수 없으며, 이름이 지정된 시크릿이 vertex 설정이나 워크플로 상태로 복사되는 일은 없습니다.

{
  "type": "GATEWAY",
  "config": {
    "url": "https://api.stripe.com/v1/refunds",
    "method": "POST",
    "headers": {
      "Authorization": "Bearer {{ secrets.STRIPE_KEY }}"
    }
  }
}

몇 가지 추가 가드레일도 적용됩니다. 플랫폼 밖으로 나갈 수 있는 시크릿은 bearer, API 키, 헤더 맵 유형뿐이며(HMAC 서명 키는 절대 나가지 않습니다), 플랫폼이 관리하는 시크릿은 워크플로 작성자가 주입할 수 없습니다.

사례: 시크릿 유출을 줄인 결제 애그리게이터

대규모 가맹점의 송금을 처리하며 몇몇 결제 제공업체와 연동하는 가상의 결제 애그리게이터를 생각해 봅시다.

과제

Kubernetes Secrets 기반으로 구축된 기존 시스템을 떠올려 보세요. 각 제공업체 키가 환경 변수로 Node.js 워커에 로드되어 있습니다. 어느 날 한 개발자가 디버깅 로그를 추가했는데, 실패한 요청에 대해 실수로 process.env 객체를 출력합니다. 이런 구성에서는 제공업체 키가 엔지니어링 팀 전체가 접근할 수 있는 ELK 스택으로 유출될 수 있습니다. 이는 대규모 키 로테이션 작업과 규제 기관에 대한 공식 보고가 필요한 심각한 보안 침해입니다.

SchemaBridge 방식

이제 같은 팀이 결제 흐름을 SchemaBridge로 이전한다고 상상해 보세요.

1. 시크릿 저장소로 이전: 제공업체 키를 SchemaBridge 시크릿 저장소로 옮기고, 자격 증명마다 이름이 지정된 시크릿을 하나씩 만듭니다.

2. 이름으로 참조: 각 Gateway vertex는 자격 증명을 값이 아닌 이름({{ secrets.stripe-key }})으로 참조합니다.

3. 더 깔끔한 로그: Gateway가 egress 시점에만 값을 치환하므로 로그에는 시크릿 참조만 남습니다. 개발자가 한 단계의 페이로드 전체를 로깅하더라도, 그곳에는 애초에 시크릿 값이 들어간 적이 없습니다.

예상되는 결과

보안 태세: 시크릿을 워크플로 설정과 상태에서 분리해 두면 로그와 페이로드를 통한 자격 증명 유출 가능성이 훨씬 낮아집니다. 불가능해지는 것은 아닙니다. 요청 헤더를 그대로 되돌려 주는 대상이라면 시크릿이 해당 단계의 기록된 출력에 남게 되며, 워크스페이스 관리자는 의도적으로 시크릿을 열람할 수 있습니다.
운영 속도: 새 제공업체 자격 증명 추가가 Kubernetes 시크릿 롤아웃이 아닌 설정 작업이 됩니다.
마음의 평화: 일상적인 디버깅에서 더 이상 원본 자격 증명을 다룰 필요가 없습니다.

미래: 표준이 되는 제로 트러스트 오케스트레이션

향후 10년 안에 "Castle-and-Moat" 모델은 완전히 사라질 것으로 예상합니다. 분산 시스템의 개별 vertex 하나하나가 각자의 마이크로 경계로 취급될 것입니다. 보안은 "레이어"에서 명령어 자체의 속성으로 옮겨 갈 것입니다.

우리는 그 방향으로 SchemaBridge를 만들어 가고 있습니다. 신뢰할 수 없는 코드의 격리(테넌트 스크립트는 자격 증명도 egress도 없는 격리된 러너에서 실행됨)와 참조 전용 시크릿 주입을 결합해, 자격 증명을 다루는 모든 컴포넌트에 원본 자격 증명을 넘기지 않고도 복잡한 연동을 구축할 수 있도록 하는 것이 목표입니다.

안전한 오케스트레이션을 위한 전문가 체크리스트

"실전에서 단련된" 이벤트 레이어를 구축하려면 다음 세 가지 타협할 수 없는 규칙을 따르세요.

1. 시크릿을 뒤집어라: 시크릿은 코드나 워크플로 페이로드에 절대 있어서는 안 됩니다. 가능한 한 마지막 순간에 해석하고, 로그로 남는 모든 것에서 시크릿을 떼어 놓으세요.

2. 최소 권한 접근: 배송 라벨을 처리하는 워커가 결제 게이트웨이의 API 키를 가져서는 안 됩니다. 플랫폼이 허용하는 한 자격 증명의 범위를 최대한 좁히세요. (SchemaBridge에서 시크릿의 범위는 워크스페이스 단위이므로, 자격 증명을 공유해서는 안 되는 업무는 별도의 워크스페이스로 분리하세요.)

3. 모든 접근을 감사하라: 일반적인 관행으로서 누가 어떤 시크릿에, 왜 접근했는지 기록하세요. 변경 불가능한 감사 추적은 포렌식 조사에서 최고의 방어 수단입니다. SchemaBridge는 현재 시크릿 접근마다 감사 이벤트를 발행하지 않으므로, 그것이 필요하다면 자체 통제 수단과 함께 사용하세요.

결론: 신뢰는 의도가 아니라 인프라 위에 세워진다

"교육"만으로 안전한 시스템에 도달할 수는 없습니다. 인적 오류는 피할 수 없습니다. 진정한 보안은 실수로 잘못된 일을 하기 어렵게 만드는 구조적 제약 위에 세워집니다. SchemaBridge는 그러한 제약 중 여러 가지를 제공하므로, 자격 증명이 새어 나갈 경로를 줄인 채 기능 개발에 집중할 수 있습니다.

함께 보기: 내구성 있는 지연 — 몇 주, 몇 달에 걸친 시간 기반 비즈니스 라이프사이클 관리하기.