디버거 연결이 불가능한 운영 환경을 어떻게 운용할 것인가: Meta가 TEE에 스토리지까지 넣기로 한 판단

운영(本番)에서 장애가 발생했을 때, 디버거를 연결할 수 없습니다. 메모리 덤프도 가져갈 수 없고. 다운되었을 때의 입력 값조차 볼 수 없습니다.

이러한 환경을 직접 구축했다면 어떻게 운용할 것인가. Meta의 엔지니어링 블로그가 AI 글래스(AI glasses)를 위한 기반 구조에 대해 작성했습니다.

주목해야 할 부분은 암호화로 운영자(operator)를 배제하면, 자신의 운용 수단까지 사라진다는 대가의 이야기였습니다. 설계 자체보다도 그 점에 매료되어 다루고 있습니다.

참고로, 아래에서 나오는 메커니즘과 보장은 Meta의 자체 신고이며, 저는 외부 검증 결과를 확인하지 않았습니다. TEE나 remote attestation 자체는 이미 알려진 기술입니다. 기술적으로 흥미로운 부분은 스토리지(storage)를 TEE 안에 넣기로 한 판단과, 그 이유로 제시된 두 가지 지점입니다.

전제: 사용 중인 데이터를 어떻게 보호할 것인가

전통적으로 데이터 암호화는 두 가지 상태를 대상으로 했습니다. 저장 시(디스크 상)와 전송 시(네트워크 상)입니다.

남아있던 것이 세 번째 상태, 사용 중이었습니다. 계산을 하려면 메모리 위에서 복호화해야 하며, 그 상태에서는 호스트 OS, 하이퍼바이저, 인프라 운영자에게 노출되는 상태가 됩니다. Confidential Computing은 이 틈새를 메우는 움직임이라고 기사에서 설명하고 있습니다.

하드웨어적인 메커니즘이 TEE(Trusted Execution Environment)입니다. 특정 CPU와 GPU가 가진 기능으로, CVM(confidential virtual machine)이라 불리는 특별한 가상 머신의 메모리를 칩 위의 전용 보안 하드웨어가 가진 키로 암호화합니다.

이 키는 호스트 OS나 하이퍼바이저를 포함하여, 그 머신을 운용하는 누구에게도 전달되지 않습니다. 외부에서 보이는 CVM의 메모리는 암호문입니다.

기사는 Confidential Computing Consortium의 정의로서, TEE가 하드웨어적으로 강제하는 세 가지 보장을 제시합니다.

• Data Confidentiality: Meta나 호스트 OS를 포함하여, CVM 외부에 있는 누구도 사용 중인 CVM 메모리를 읽을 수 없다 -
• Data Integrity: CVM 외부에서 해당 데이터를 추가, 삭제, 변형할 수 없다 -
• Code Integrity: 일단 로드된 CVM 내부의 코드를 아무도 변형할 수 없다

여기서 보충 설명을 하나 합니다. 신뢰가 사라지는 것이 아니라, 맡기는 곳이 바뀌는 것입니다.

키는 칩 위의 하드웨어가 가지고 있으며, attestation의 검증 또한 벤더가 공개하는 루트 키까지 거쳐 성립합니다. 즉 호스트 운영자를 신뢰할 필요가 없어지는 대신, 칩 벤더의 구현과 사이드 채널 내성(side-channel resistance)을 신뢰하게 됩니다. 게다가 이용자 입장에서는 Meta가 원장(ledger)에 올린 이미지가 설명대로 작동하는 것을 감사한 연구자를 거쳐 신뢰하게 되는 것입니다.

이것은 기사에 쓰여있지 않은, 저의 해석입니다.

클라이언트가 서버를 검증하다

흥미로운 점은 신뢰의 방향성입니다. 보통 이용자가 서버를 신뢰하지만, 여기서는 클라이언트가 서버에 증명을 요구합니다.

디바이스는 remote attestation report를 요청합니다. 이는 그 칩 안에만 존재하는 키로 서명되며, CVM이 로드한 소프트웨어 이미지의 measurement를 포함하고 있습니다. 클라이언트 측은 두 가지를 확인합니다.

• 서명이 칩 벤더가 공개하는 루트 키까지 추적 가능한지
• measurement가 독립적인 제3자가 입회하는 추가 전용 원장에 공개된 값과 일치하는지

둘 중 하나라도 실패하면, 클라이언트는 연결을 거부하고 데이터는 전송되지 않습니다.

기사에서는 이를 RA-TLS(remote attestation and TLS)라고 부릅니다. CPU/GPU 벤더의 인증서 검증이 통과하지 못하거나, 바이너리의 해시가 원장과 일치하지 않으면 핸드셰이크가 실패합니다.

누구로부터의 요청인지, 인증 측에서 알 수 없게 하다

또 하나, 저에게는 철저하게 눈에 띄었던 부분이 여기입니다.

누가 보내는지 알아버리면, 운영자가 그 통신을 조작된 머신 쪽으로 유도할 위험이 있습니다. 그래서 세션 확립 시점에서, 인증 서비스가 요청을 계정(account)에 연결 지을 수 없도록 합니다.

사용하는 것은 anonymous credentials이며, 무작위 간격으로 획득하는 blind-signed token입니다. 그 위에 장치는 제3자의 OHTTP relay(Fastly 또는 Cloudflare)를 거쳐 게이트웨이에 연결하고, TEE 노드를 선택합니다. 이 선택은 이용자를 특정할 수 없는 지표에 기반한다고 쓰여 있습니다.

이 기사는 이를 non-targetability라고 부르며, 특정 개인의 세션이나 저장 영역만 노리는 것은 시스템 전체를 침해하려고 하는 것 외에는 방법이 없도록 요구사항을 설정하고 있습니다.

하지만 이 특성은 relay와 게이트웨이가 공모하지 않는다는 가정에 의존합니다. OHTTP의 일반적인 특성으로, relay는 내용을 읽을 수 없고, 게이트웨이는 발신지를 알지 못합니다. 각각은 아무것도 모르지만, 둘 다 손을 잡으면 연결할 수 있습니다. 기사는 이 가정을 언급하지 않았기 때문에 저는 보충하여 해석했습니다.

스토리지(Storage)를 TEE 안에 넣은 두 가지 이유

여기서 기술적으로 가장 흥미로운 부분이었습니다.

세션을 넘어 문맥을 기억하는 기능을 만들려면, 어딘가에 상태(state)를 가지고 있어야 합니다. 일반적인 방식이라면, 장치 측에서 암호화하여 일반 클라우드 DB에 저장합니다. 기사는 이 방안을 두 가지 이유로 거부하고 있습니다.

첫 번째는 접근 패턴이 행동을 노출하는 것입니다.

내용물이 강력하게 암호화되어 있어도, 외부 DB는 언제 읽고 썼는지, 어느 정도의 빈도로 문의했는지, 어떤 레코드가 함께 참조되었는지를 관측합니다. 기사는 이렇게 쓰여 있습니다. 그 메타데이터만으로 일상의 행동과 패턴이 지도가 된다고요.

암호화는 페이로드(payload)의 내용물을 보호하지만, 실행의 패턴은 숨기지 못한다.

여기부터는 기사에 없는 보충 설명입니다. 이 논점은 ORAM 등에서 오래전부터 이야기되어 왔습니다. 그리고 TEE 안에 넣어도 메모리 접근 패턴까지 사라지는 것은 아닙니다. 숨길 대상이 외부 DB에서 메모리로 옮겨졌을 뿐이라는 시각도 가능합니다.

두 번째는 암호화된 상태의 조회가 규모를 감당하기 어렵다는 것입니다.

의미 벡터 검색이나 여러 세션 결합과 같은 복잡한 작업을 기존의 암호화 스토리지로 하려고 하면, 거대한 암호문을 DB에서 가져와 네트워크를 통해 TEE로 옮긴 후, 한 번의 조회에 대해 복호화해야 합니다. 이용자의 문맥이 늘어날수록 지연 시간이 급증하고 성능이 무너진다고 기사는 쓰고 있습니다.

그래서 Meta는 스토리지 엔진 자체를 TEE 안에 만들었습니다. 쿼리 엔진이 TEE 경계 내에서 작동하기 때문에, 읽기가 외부 네트워크 경계를 넘지 않습니다.

계산과 상태를 프로세서가 암호화한 메모리 안에 공존시키는 것입니다. 발상은 이해하기 쉽지만, 만드는 수고는 크다고 생각합니다.

키(key) 처리는 자료에 쓰여 있습니다. 이용자가 제공한 키로 암호화하고, 꺼낼 때는 단말기가 키를 전달하여 TEE가 복호화합니다.

쓰여 있지 않은 것은 이미지를 업데이트한 후의 상태 인계입니다. CVM의 이미지가 바뀌면 measurement도 바뀌고, 원장(ledger)에 기록되는 값도 바뀝니다. 키는 이용자가 가지고 있으므로 복호화할 수 없게 되는 것은 아니지만, 그 이전에 기록된 상태나 인덱스를 새로운 이미지의 CVM이 어떻게 인계받는지입니다. multi-regional에서 fault-tolerant라고는 하지만, 그 절차는 나와 있지 않습니다. 운영의 핵심이라고 생각하기 때문에 여기는 신경 쓰였습니다.

대가: 내부를 볼 수 없는 실전 환경

서두에 쓴, 다루게 된 이유의 단락입니다.

암호로 인해 운영자를 배제하는 기반을 만들면, 운영상의 문제가 생긴다고 기사 스스로 쓰고 있습니다. 기사가 언급한 것은 세 가지입니다.

• 엔지니어는 동작 중인 TEE에 디버거를 연결할 수 없다
• 충돌 시 메모리 스택을 덤프하거나, 모델의 입출력을 로그로 남길 수 없다
• 운영상의 결함을 일으킨 특정 페이로드를 조사할 수 없다

그럼 무엇을 보고 있는가. 기사에 따르면, 관측은 완전히 대역 외(out-of-band)에서 수행하는 것 외에는 없고, 집계된 건전성 신호에 의존하도록 설계했다고 합니다. 구체적으로는 CPU 사용률, 메모리 할당, 네트워크 지연, 하드웨어 장애율의 집계값입니다. 이를 통해 이용자의 데이터를 1바이트도 노출시키지 않으면서 서비스의 건전성과 가동률을 유지한다고 쓰여 있습니다.

이곳은 솔직한 기술 설명입니다. 기밀성을 높이는 판단이, 장애 시 무엇을 볼 수 있는지를 미리 결정해 버린 것입니다.

기밀성을 높이면, 관측의 정밀도가 낮아집니다. 장애 재현에 입력이 필요한 설계인 한, 그 입력을 볼 누군가가 필요하게 됩니다.

다만 기사는 이 체제에서 실제로 어떤 장애를 맞았고 어떻게 분리했는지는 적혀있지 않습니다. '집계값으로 충분한가' 아니면 '충분하지 않지만 받아들이고 있는가'는 여기부터는 알 수 없습니다. 저는 그것을 알고 싶었습니다.

기사에 답이 없으므로, 제가 한다면 어떻게 할지 써보겠습니다. 내부를 볼 수 없다는 전제하에 시도할 수 있는 방법은 대략 다음과 같을 것입니다.

입력을 포함하지 않는 오류 유형을 먼저 설계한다. 어떤 경로의 어느 단계에서 실패했는지만 알 수 있는 식별자를 페이로드와 분리하여 가진다 -
합성 요청(synthetic request)을 상시로 흘린다. 실제 사용자 데이터를 볼 수 없다면, 내용이 알려진 요청을 직접 넣어보고 나오는 결과와 대조한다 -
평문(plain text)에 닿지 않는 검사만 경계 바깥으로 빼낸다. 이 구성에서는 통신이 TEE에서 종단되므로, 스키마 검증과 같이 평문을 요하는 처리는 밖에 둘 수 없습니다. 외부에서 할 수 있는 것은 크기나 라우팅의 타당성 정도입니다. 그래도, 떨어뜨릴 수 있는 것을 미리 떨어뜨려 내부로 가져갈 불명점을 줄일 수 있습니다.

세 가지 모두 시도해 보지 않았으므로, 효과가 있을지는 알 수 없습니다. 설계 방향으로는 이런 식이라는 정도의 이야기입니다.

검증을 외부에 개방하기 (Opening Verification Externally)

주장이 제공자를 신뢰하는 것에 의존한다면 의미가 없다는 입장에서, 기사는 세 가지를 제시합니다.

• 실제 서비스에 배포할 CVM 이미지는 모두 추가 전용으로 제3자가 참관하는 투명성 원장(transparency ledger)에 등록한다. 공개된 것과 다른 코드를 내놓으면 클라이언트나 외부 감시자가 불일치에 알아챌 수 있다.
• NCC Group 같은 독립적인 보안 기업이나 연구자와 협력하여 설계, attestation 로직, 격리 모델의 경계를 감사받는다.
• 버그 바운티 대상을 AI 글래스의 Private Processing까지 확대하고, 연구자들에게 툴·CVM 바이너리·문서를 제공할 예정이라고 적혀있다(제공 조건은 이 절 끝에 적겠습니다).

원장에 대해 기사는 **변조가 감지될 수 있는 상태(tamper-evidence)**가 확립된다고 적습니다. 막을 수 있는 것이 아니라, 보이게 된다는 주장입니다. 기록이 자신들의 관리 하에 있지 않은 원장에 남기 때문에, 대체하면 보인다는 설명입니다.

참고로 원장과 measurement는 공개되어 있지만, 해당 바이너리는 보안 프로그램에 참여하는 연구자에게 합의하에 제공된다고 적혀 있습니다(available to researchers in our security program under agreement). 완전한 공개는 아닙니다.

즉 일반 사용자 입장에서는, 원장의 일치는 스스로 확인할 수 있어도, 그 이미지가 기사 설명대로 작동하는지는 감사한 연구자를 믿을 수밖에 없다는 의미가 됩니다.

가져온 것 (Takeaways)

이 구성을 그대로 따라 할 수 있는 현장은 많지 않습니다. TEE 대응 하드웨어가 필요하고, 클라이언트 측에 검증 구현도 필요합니다.

그럼에도 두 가지는 가져올 수 있었습니다.

하나는 관측의 수단을 설계 단계에서 결정해 버린다는 점입니다. TEE를 사용하지 않아도, 로그에 무엇을 내보내지 않기로 결정하는 순간, 장애 시 무엇이 보이는지가 결정됩니다.

다른 하나는, 기밀성과 가시성(observability)이 같은 자원을 두고 경쟁한다는 것입니다. 기사는 엔지니어가 내부를 볼 수 없는 상태에서 어떻게 고가용성을 유지할 수 있을지에 대한 질문을 스스로 던지고, 집계값이라는 답을 적었습니다.

답이 집계값만으로는 마음이 불안합니다. 그럼에도 만들기 전에 이 질문을 던졌다는 것은 알 수 있습니다.

참고 (Reference)

• Bringing Private Processing to Meta AI Glasses (Engineering at Meta, 2026-09-23)

Discussion