trusted-execution-environment

2 개의 포스트

meta

종단 간 암호화와 검증 가능성을 보장하는 WhatsApp용 사기 경보 시스템 구축 방법 (새 탭에서 열림)

WhatsApp의 Scam Alert는 종단간 암호화를 유지하면서 사기 가능성이 있는 메시지를 기기에서만 분석하는 선택형 기능이다. 메시지 내용은 서버로 전송되거나 자동 신고되지 않으며, 사용자가 경고를 본 뒤 차단·신고·대화 지속 여부를 직접 결정한다. WhatsApp은 온디바이스 처리, 사용자 통제, 공개 검증 가능성을 통해 개인정보 보호와 사기 탐지의 균형을 이루려 한다. ## 온디바이스 사기 탐지 - 사용자가 기능을 켜면 사기 탐지용 머신러닝 모델이 기기에 다운로드된다. - 모델은 연락처에 등록되지 않은 사람이 보낸 메시지를 대상으로 다음 신호를 분석한다. - 대화의 구조 - 문장 및 언어적 특징 - 기존 사기 대화에서 관찰된 패턴 - 분류는 확률 기반으로 수행되며, 메시지 내용은 분류를 위해 WhatsApp·Meta·제3자 서버로 전송되지 않는다. - 모델이 사기 가능성이 높다고 판단하면 해당 사용자에게만 채팅 경고가 표시된다. 상대방에게는 경고가 보이지 않는다. ## 사용자가 결정하는 대응 방식 - 경고를 본 사용자는 다음 중 하나를 선택할 수 있다. - 대화 차단 - 신고 - 계속 대화 - 오탐이라고 판단하면 채팅을 신뢰 대상으로 표시할 수 있다. - 신뢰 처리된 채팅은 경고가 제거되고, Scam Alert가 해당 채팅을 다시 경고하지 않는다. - 사용자가 원할 경우 정확도 개선을 위해 최근 수신 메시지 5개를 WhatsApp에 공유할 수 있다. - 메시지 내용이나 사기 탐지 사실이 서버에 전달되는 유일한 경로는 사용자가 명시적으로 신고하거나 공유하는 경우다. ## 설계 원칙 - **기기 내 처리**: 머신러닝 모델과 분석 대상 메시지는 모두 사용자 기기에 남는다. - **자동 신고 금지**: WhatsApp은 사용자의 행동 없이 메시지나 탐지 결과를 서버로 보낼 수 없다. - **사용자 통제**: 기능을 언제든 켜거나 끌 수 있고, 경고에 대한 최종 판단도 사용자가 내린다. - 최근 온디바이스 머신러닝 기술 발전으로 모바일 기기에서도 성능·배터리·모델 크기의 부담을 줄이면서 텍스트 분류가 가능해졌다는 점을 활용한다. ## 개인정보 보호형 분석 WhatsApp은 기능이 실제 사기를 잘 탐지하는지, 모델 업데이트 후 성능이 악화되지 않았는지를 확인하기 위해 제한적인 통계만 수집한다. - 수집 대상은 메시지 원문이 아닌 다음 두 종류의 집계 신호다. - **경고 횟수**: 기기 내 모델이 사기 경고를 표시한 횟수 - **사용자 행동 횟수**: 경고 이후 사용자가 신뢰 처리, 차단, 신고 등을 선택한 횟수 - 이 통계는 모델의 경고 발생률과 오탐률을 평가하는 데 사용된다. - 개인별 행동이나 특정 메시지를 식별할 수 있도록 설계하지 않는다. - 차등 개인정보보호(differential privacy)를 적용해 통계에 조정된 노이즈를 추가한다. - 이에 따라 특정 개인의 데이터가 포함되거나 제외되더라도 전체 통계에 미치는 영향이 매우 작아진다. ## 기밀 연합 분석 파이프라인 집계 통계를 보호하기 위해 WhatsApp은 기밀 컴퓨팅 기반의 연합 분석 구조를 사용한다. - **로컬 집계** - 원시 이벤트는 기기를 떠나지 않는다. - 기기는 데이터를 자체적으로 횟수로 합산한 뒤 집계값만 전송한다. - 전송 시점은 무작위화되고, 기기 식별자는 포함되지 않는다. - 시간 정보도 정확한 시각이 아닌 넓은 구간으로 제한된다. - **기밀 처리** - 집계값은 CPU 기반 기밀 가상머신(CVM)과 신뢰 실행 환경(TEE)에서 처리된다. - 클라이언트는 하드웨어 기반 증명을 확인하고, 허용된 소프트웨어 바이너리인지 제3자 로그와 대조한다. - 데이터는 기기와 TEE 사이에서 암호화된다. - WhatsApp이나 Meta를 포함한 중간 전달자도 처리 중인 데이터를 볼 수 없도록 설계됐다. - **안전한 집계** - 개별 기기의 통계가 직접 노출되지 않도록 여러 기기의 데이터를 결합한다. - 최종적으로 WhatsApp과 Meta에 제공되는 것은 익명화·차등 개인정보보호가 적용된 집계 결과다. ## 모델 배포와 독립 검증 - Meta와 WhatsApp은 특정 사용자에게 특정 모델을 선택적으로 배포할 수 없도록 설계했다. - 실험 모델을 포함한 모든 모델 버전은 배포 전에 공개 투명성 원장에 기록된다. - 모델 가중치도 공개해 보안 연구자들이 모델이 사기 탐지 목적에 맞게 제작됐는지 확인할 수 있도록 한다. - 버그 바운티 프로그램을 확대해 외부 연구자들이 구현을 검증하고 취약점을 찾을 수 있게 했다. - 사용자 역시 앱 내 로그를 통해 기능의 동작을 확인할 수 있도록 했다. ## 실용적인 결론 Scam Alert는 서버에서 메시지를 검사하는 방식이 아니라, 선택형 온디바이스 모델과 사용자 주도 신고를 결합한 접근이다. 개인정보 보호가 중요한 사용자는 기능을 직접 활성화해 사기 경고를 보조 수단으로 활용할 수 있지만, 머신러닝 경고는 확률적 판단이므로 최종적으로는 송금 요구, 긴급성 유도, 신원 사칭 같은 전형적인 사기 신호를 사용자가 함께 확인해야 한다.

gitlab

GitLab 셀프 호스팅을 위한 기밀 AI (새 탭에서 열림)

GitLab Self-Hosted 환경에서도 소스 코드를 외부에 노출하지 않고 AI 코딩 에이전트를 사용할 수 있다는 것이 글의 핵심 주장입니다. GitLab Duo의 AI Gateway를 Privatemode AI에 연결하면, 프롬프트와 코드가 하드웨어 기반 기밀 컴퓨팅 영역 안에서만 복호화·처리됩니다. 따라서 규제 산업은 자체 GPU·LLM 인프라를 운영하지 않고도 최신 AI 기능과 데이터 보안성을 함께 확보할 수 있습니다. ## 규제 조직이 AI 코딩 도입에 어려움을 겪는 이유 - GitLab Duo Agent Platform은 단순 자동완성을 넘어 다음과 같은 작업을 수행합니다. - 머지 리퀘스트 리뷰 - 여러 파일에 걸친 리팩터링 - 테스트 코드 생성 및 실행 - CI 작업으로 실행되는 에이전트형 워크플로 - 그러나 이러한 기능을 사용하려면 프롬프트, 소스 코드, 실행 컨텍스트가 모델 제공업체로 전송됩니다. - 금융, 의료·제약, 방위산업, 공공기관, 핵심 인프라 기업에서는 소스 코드가 지적 재산이자 규제 대상이므로 외부 AI 서비스 전송 자체가 문제가 될 수 있습니다. ## 데이터 주권과 규제 요구사항 - 소스 코드 처리 위치는 단순한 편의가 아니라 계약, 산업 규정, 데이터 보호법의 적용 대상입니다. - 관련 요구사항에는 다음이 포함됩니다. - NIS2와 DORA의 운영 복원력 및 제3자 위험 관리 - GDPR에 따른 코드와 로그 내 개인정보 처리 - 독일 금융권의 BaFin 감독 - 조달 기준으로 활용되는 BSI C5 - 의료 데이터 관련 규정 - 유럽 조직이 중시하는 데이터 주권 - GitLab Self-Hosted는 원래 코드를 신뢰할 수 있는 조직 내부 경계에 유지하기 위한 방식이므로, AI 기능 도입으로 이 경계를 무너뜨려서는 안 됩니다. ## 기존 AI 운영 방식의 한계 - **공개 AI SaaS** - 소스 코드가 외부 서비스로 이동하므로 규제 조직에서 사용하기 어렵습니다. - **VPC 또는 프라이빗 클라우드** - 네트워크 격리는 강화되지만 클라우드 운영자나 서비스 제공자가 평문 데이터를 처리할 가능성이 남습니다. - 계약상 비공개 약정은 보안에 대한 법적 약속일 뿐, 기술적으로 읽을 수 없게 만드는 보장은 아닙니다. - **자체 모델 및 GPU 운영** - 코드 프라이버시는 확보할 수 있지만 GPU 구매, 인프라 운영, 모델 업데이트, 전문 인력 확보 비용이 큽니다. - 최신 프론티어 모델과 성능 격차가 발생할 수 있습니다. - 결과적으로 많은 규제 조직은 AI를 제한적으로 도입하거나 아예 도입하지 못합니다. ## 하드웨어 기반 기밀 컴퓨팅 - 기밀 컴퓨팅은 데이터가 처리되는 동안에도 메모리 안의 데이터를 암호화합니다. - 하드웨어 기반 TEE(Trusted Execution Environment)가 CPU 또는 GPU 내부에 격리된 실행 영역을 제공합니다. - 사용되는 기술은 다음과 같습니다. - CPU 측: AMD SEV 또는 Intel TDX - GPU 측: NVIDIA Confidential Computing - 전송 및 저장 암호화: AES-256 - 운영체제, 하이퍼바이저, 서버 관리자, 클라우드 제공자도 TEE 내부 데이터를 직접 읽을 수 없습니다. ## 원격 검증과 암호화된 데이터 흐름 - 핵심 보안 장치는 **원격 검증(remote attestation)**입니다. - 클라이언트는 데이터를 보내기 전에 TEE에 다음을 증명하도록 요청합니다. - 어떤 하드웨어에서 실행 중인지 - 어떤 코드와 설정이 실행 중인지 - TEE는 서명된 암호학적 증거를 반환하고, 클라이언트는 이를 사전에 등록된 정상 값과 비교합니다. - 검증이 성공한 뒤에만 암호화 채널을 만들고 요청을 전송합니다. - 데이터는 다음과 같은 흐름으로 처리됩니다. - 클라이언트에서 프롬프트와 코드 암호화 - 암호문 상태로 네트워크 전송 - 원격 TEE 내부에서만 복호화 및 추론 - 서비스 운영자와 클라우드 제공자는 프롬프트·완성 결과·컨텍스트를 확인할 수 없음 - 이는 “보지 않겠다”는 계약이 아니라 하드웨어가 “볼 수 없게” 강제하는 보안 모델입니다. ## Privatemode AI의 역할 - Privatemode AI는 독일의 기밀 컴퓨팅 전문 기업 Edgeless Systems가 개발했습니다. - OpenAI 호환 API를 제공하므로 표준 `/v1` API를 사용하는 도구와 SDK를 그대로 연결할 수 있습니다. - 클라이언트 측 프록시가 다음 작업을 자동으로 처리합니다. - 원격 TEE 검증 - 요청 암호화 - Privatemode 서비스로의 전송 - 글에서 소개한 주요 코딩 모델은 다음과 같습니다. - Kimi K2.6 - 256K 컨텍스트 - 향후 Kimi K3, GLM 등 지원 예정 - Capgemini, 독일 연방고용청, 금융·보험·방위 조직 등에서 규제 환경의 기밀 코딩 용도로 사용되고 있다고 설명합니다. - 암호화는 포스트퀀텀 보안을 지원해, 현재 암호문을 수집한 뒤 미래의 기술로 복호화하려는 “지금 수집하고 나중에 복호화” 공격에도 대응합니다. ## GitLab Duo Self-Hosted 통합 방식 - GitLab Duo Self-Hosted는 GitLab이 관리하는 게이트웨이 대신 조직이 제어하는 AI Gateway를 사용할 수 있습니다. - 구성 흐름은 다음과 같습니다. - 개발자 및 GitLab Duo Agent Platform - 자체 호스팅 GitLab AI Gateway - Privatemode 프록시 - CPU·GPU 기반 원격 TEE - Privatemode 프록시는 OpenAI 호환 `/v1` 엔드포인트로 동작합니다. - 요청이 들어오면 프록시가: - 네트워크를 벗어나기 전에 요청을 암호화하고 - 원격 TEE를 검증한 뒤 - 검증된 환경으로 요청을 전달합니다. - 복호화와 모델 추론은 기밀 컴퓨팅 영역 내부에서만 수행됩니다. - 개발자는 Code Suggestions, Chat, Code Review, 에이전트형 작업 등 기존 GitLab Duo 기능을 동일한 방식으로 사용할 수 있습니다. ## 실용적인 결론 규제 대상 소스 코드를 다루면서 AI 코딩 기능을 도입해야 한다면, GitLab Duo Self-Hosted와 Privatemode AI의 조합은 자체 GPU 클러스터 없이도 검토할 만한 선택지입니다. 다만 실제 도입 전에는 TEE 지원 하드웨어, 원격 검증 절차, 키 관리, 로그 및 메타데이터 처리, 관련 규정에 대한 감사 증적을 별도로 검증해야 합니다.