대규모 가시성: Figma가 민감한 데이터 노출을 탐지하는 방법

프로그래밍 방식으로 민감한 데이터 노출을 방지하는 것은 보안 엔지니어링에서 가장 복잡한 과제 중 하나입니다. 현대적인 분산 시스템의 특성상 데이터는 복잡하고 때로는 예측할 수 없는 경로를 통해 이동합니다. 여러 서비스를 거치고, 직렬화 레이어를 통과하며, 데이터의 존재가 항상 명확하지는 않은 컨텍스트로 주입될 수도 있습니다. 이러한 문제는 미묘한 방식으로 나타날 수 있습니다. 엔드포인트가 의도한 것보다 더 많은 데이터를 반환하거나, 레거시 코드 경로가 권한 확인을 건너뛰거나, 누락된 검증으로 인해 사용자가 봐서는 안 될 리소스를 보게 되는 식입니다. 보안 용어로, 이는 종종 권한 부여 결함이나 부주의한 데이터 과다 노출의 형태를 띱니다. 작은 실수지만 대규모로 발생할 경우 프라이버시와 신뢰에 막대한 영향을 미칠 수 있습니다.

Figma에서 이 과제에 정면으로 대응하기 위해 우리는 안전망이자 조기 경보 시스템 역할을 하는 모니터링 시스템을 구축해야 했습니다. 스테이징 단계에서 노출을 잡아내어 프로덕션에 도달하지 못하게 하고, 배포된 후에도 예상치 못한 회귀를 지속적으로 감시하는 능력을 갖추어야 했습니다. 즉, 신뢰할 수 있을 만큼 정밀하면서도 제품의 여러 부분에 걸쳐 가치를 제공할 만큼 광범위한 시스템을 구축해야 한다는 뜻이었습니다.

잠재적인 민감 데이터 유출을 실시간으로 탐지하도록 설계된 시스템인 '응답 샘플링(Response Sampling)' 구축 경험을 공유하게 되어 기쁜 마음입니다. 응답 샘플링(Response Sampling) 기능은 서비스에서 나가는 데이터에 대한 지속적인 가시성을 제공하므로 팀은 문제를 신속하게 조사하고 해결할 기가 있으며, 노출 위험을 줄이고 데이터 처리 방식에 대한 신뢰를 높여줍니다.

우리는 이 문제에 플랫폼 보안 사고방식으로 접근했습니다. 애플리케이션 표면을 인프라처럼 취급하고 그 위에 지속적인 모니터링 및 탐지 제어를 계층화했습니다. 일반적으로 하위 수준 시스템을 위해 사용되는 기술을 애플리케이션 레이어에 적용함으로써, 개발 속도를 늦추지 않으면서도 데이터가 제품을 통해 어떻게 이동하는지에 대한 지속적인 가시성을 확보할 수 있었습니다.

문제 식별: 숨겨진 노출에 대한 가시성

Figma는 권한과 인증을 매우 중요하게 생각합니다. 수년 동안 우리는 세분화된 인증 프레임워크인 PermissionsV2와 같은 강력한 예방 통제 기능에 투자해 왔습니다. 또한 부정 단위 테스트, 스테이징 및 프로덕션에서의 엔드투엔드 테스트, 지속적인 보안 검토 프로그램(버그 바운티 프로그램 및 정기 모의 해킹 포함)을 통한 지속적인 테스트에도 투자했습니다. 이러한 시스템 덕분에 액세스 경계를 강하게 신뢰할 수 있으며, 민감한 데이터 노출을 방지하는 방식의 토대를 형성할 수 있습니다.

PermissionsV2 구축 방법에 대해 자세히 알아보세요.

하지만 예방 조치와 테스트만으로 모든 Edge 케이스를 잡아낼 수 있는 건 아닙니다. 제품과 인프라가 복잡해짐에 따라 미묘한 간과나 예상치 못한 데이터 흐름의 위험도 자연스럽게 증가했습니다. 잘 설계된 시스템이라도 서비스가 새로운 방식으로 상호작용하거나 기존 경로가 예상과 다르게 동작할 때 놀라운 결과를 낳을 수 있습니다.

데이터 보호가 Figma에 얼마나 중요한지를 고려하여, 우리는 탐지와 관찰 가능성에 초점을 맞춘 또 다른 방어 레이어를 추가하고자 했습니다. 우리는 예방 통제가 의도한 대로 작동하는지 지속적으로 검증하고, 프로덕션에 영향을 미치기 전에 이상 징후를 조기에 발견하도록 돕는 시스템을 구축하는 것을 목표로 삼았습니다.

이를 실현하기 위해, 다음과 같은 기능을 갖춘 시스템이 필요했습니다.

• 제품 내 어디에서 발생하든 잠재적인 노출을 지속적으로 모니터링합니다.
• 이상적으로는 프로덕션에 도달하기 전에 문제를 조기에 수정할 수 있는 실행 가능한 인사이트를 제공합니다.
• 실시간으로 회귀를 탐지하기 위한 추가 방어 레이어로서 프로덕션에서도 활성 상태를 유지합니다.

이러한 목표는 우리 접근 방식의 토대를 형성했고, 탐지 범위, 성능 영향, 운영 유지보수성 사이의 균형을 맞추는 지침이 되었습니다.

1단계: 파일 식별자를 위한 응답 샘플링 구축

민감한 데이터 노출을 프로그래밍 방식으로 탐지하기 전에 먼저 무엇을 '민감한' 것으로 간주할지 결정해야 했습니다. API 응답의 모든 필드가 위험을 초래하는 것은 아니므로, 민감도와 액세스 규칙이 이미 명확한 하나의 잘 정의된 유형인 '파일 식별자'부터 시작했습니다. Figma의 파일 식별자는 각 파일의 URL에 임베드된 고유 토큰이며, 특정 액세스 제어와 연결됩니다. 파일 식별자는 알려진 문자 집합과 일정한 길이를 가진 고엔트로피 기능 토큰이기 때문에 텍스트 스트림에서 쉽게 탐지할 수 있습니다. 따라서 인증 버그를 탐지하고, 나중에 민감한 데이터에 대한 체계적인 정의가 가능해졌을 때 더 광범위한 응답 샘플링을 지원할 인프라를 구축하기 위한 실용적인 출발점이 되었습니다.

초기 구현은 이 데이터 유형과 관련된 권한 확인에 집중했습니다. 아이디어는 단순하지만 강력했습니다. 주요 서비스의 응답 중 일부를 샘플링하고, 파일과 연결된 식별자를 스캔한 다음, 요청한 사용자가 각 값에 액세스할 권한이 있는지 확인하는 것입니다. 샘플링은 요청 경로 전반에 걸쳐 설정 가능한 비율로 무작위 균등하게 수행되므로, 커버리지를 제어하고 오버헤드를 제한하면서도 대표성 있는 결과를 도출할 수 있습니다.

우리는 인증된 사용자 개체, 전체 API 응답 본문, 내부 권한 시스템인 PermissionsV2에 직접 액세스할 수 있는 Ruby 애플리케이션 서버의 미들웨어로 시스템을 구축했습니다. 덕분에 한곳에서 더욱 수월하게 응답 데이터를 검사하고 권한을 평가할 수 있게 되었습니다. Envoy와 같은 프록시 레이어에서 유사한 검사를 구현할 수도 있었지만, 이렇게 했다면 아키텍처에 필요한 사용자 컨텍스트 인식 권한 평가를 수행하기가 훨씬 더 어려워졌을 것입니다.

우리는 after 블록과 비동기 작업을 사용하여 응답 샘플링을 구현했습니다. after 필터는 각 요청이 완료된 후 자동으로 실행되는 내장 훅으로, 응답이 클라이언트로 전송되기 전에 일관되게 검사할 수 있는 지점을 제공합니다. 필터는 설정된 샘플링 비율에 따라 적격 응답을 검사하고 JSON 본문을 파싱하여 파일 식별자를 추출합니다. 관련 식별자가 발견되면 시스템은 비동기 작업을 대기열에 추가하여 권한을 확인합니다. 오탐을 줄이기 위해 검증 로직은 알려진 안전한 사례를 고려하는 규칙을 적용하여 예상치 못한 결과만 검토 대상으로 드러나도록 합니다. 이 모든 과정은 논블로킹 방식입니다. 샘플링이나 검증이 실패하더라도 요청은 정상적으로 완료되며 오류는 모니터링을 위해 로그로 기록됩니다.

내부 엔드포인트를 통해 협업 경험을 동기화 상태로 유지하는 실시간 데이터 페칭 서비스인 LiveGraph와 같은 다른 서비스들도 자체 샘플링 데이터를 제출하고 처리 파이프라인을 재사용할 수 있습니다. 응답을 생성한 후 LiveGraph는 이 엔드포인트에 가벼운 API 호출을 하여 실시간 데이터 흐름에 오버헤드를 추가하지 않고도 응답 샘플링의 이점을 누릴 수 있습니다. 예측 가능한 성능을 유지하기 위해 LiveGraph의 샘플링은 구성 및 속도 제한에 의해 제어됩니다. 발견된 내용은 다른 서비스와 동일한 스키마 및 로깅 경로를 공유하므로 결과가 분석 웨어하우스와 분류 대시보드에 통합되어, 온콜 엔지니어가 소스에 관계없이 알림을 쉽게 해석할 수 있습니다.

LiveGraph 구축 방법에 대해 자세히 알아보세요.

우리는 이 로직을 API 인프라에 직접 임베드하여 스테이징 및 프로덕션 트래픽 모두에서 실행되게 했습니다. 샘플링 비율은 눈에 띄는 지연을 유발하지 않으면서 의미 있는 결과를 얻을 수 있도록 충분한 커버리지를 확보하게 조정되었으며, 요청-응답 주기가 느려지는 것을 방지하기 위해 모든 검사는 비동기적으로 수행되었습니다. 또한 처리 파이프라인의 과부하를 방지하고 과도한 리소스 소모를 막기 위해 속도 제한을 적용했습니다.

이 접근 방식은 즉시 귀중한 인사이트를 도출하기 시작했습니다. 배포 며칠 만에 응답 샘플링은 특정 응답에서 파일 관련 식별자가 불필요하게 반환되는 미묘한 사례를 드러냈고, 이는 더 나은 데이터 필터링을 촉진했습니다. 또한 특정 파일이 권한 확인을 완전히 우회하는 경로를 노출시켜, 그 허점을 메우고 전반적인 액세스 제어를 강화할 수 있게 해주었습니다.

1단계는 개념을 증명했지만 범위가 제한적이었습니다. 파일 식별자는 중요하지만 우리가 보호해야 할 민감한 정보의 한 범주에 불과합니다.

2단계: 확장된 응답 샘플링으로 가시성 증대

기반을 마련했으므로, 이제 시스템의 도달 범위를 넓히기 시작했습니다. 초기 구현은 응답 샘플링이 실제 인증 문제를 효율적으로 탐지할 수 있음을 증명했지만, 단일 데이터 유형에 국한되어 있었습니다. 다음 과제는 동일한 접근 방식을 모든 민감한 필드로 확장하는 것, 즉 본질적으로 시스템에게 우리 제품 전반에서 "민감함"이 무엇을 의미하는지 인식하도록 가르치는 것이었습니다.

내부에서는 "고급진 응답 샘플링(fancy Response Sampling)"이라 부르는 확장된 응답 샘플링 기능은 내부 데이터 분류 도구인 FigTag와 통합하여 모든 민감 데이터에 동일한 샘플링 원칙을 확장 적용했습니다.

FigTag는 모든 데이터베이스 컬럼에 민감도와 의도된 사용법을 설명하는 카테고리를 주석으로 답니다. 이러한 주석은 중앙 스키마에 저장되고 데이터 웨어하우스로 전파되어 쿼리 시점에 컬럼의 민감도를 쉽게 확인할 수 있습니다. 이 카테고리 중 하나인 banned_from_clients는 민감도 신호로 작용하여, 정상적인 상황에서는 API 응답으로 반환되어서는 안 되는 필드(예: 보안 관련 식별자, 청구 세부 정보, 기타 개인정보(PII))를 표시합니다.

FigTag와 통합함으로써 우리는 모든 애플리케이션 서버 API 엔드포인트에 걸쳐 무엇이든 민감한 필드가 포함된 응답의 일부를 샘플링할 수 있게 되었습니다. banned_from_clients로 태그 지정된 컬럼이 있는 데이터베이스 레코드가 애플리케이션에 로드되면(우리 경우 Ruby 애플리케이션에서 사용하는 개체 관계 매핑 레이어인 ActiveRecord 모델을 통해), 콜백이 해당 값을 요청 로컬 저장소(request-local storage)에 기록합니다. 샘플링된 요청의 경우, 요청 중에 실제로 액세스된 값만 추적되도록 하여 불필요한 오버헤드를 방지합니다.

응답이 생성되면, after 필터가 직렬화된 JSON을 검사하고 기록된 민감한 값과 비교합니다. 응답에 민감한 값이 나타나면 발견 사항이 로그에 기록됩니다. 이전과 마찬가지로 결과는 통합 분석 웨어하우스 및 대시보드로 전송됩니다.

또한 유연한 허용 목록 프로세스를 도입하여, 의도적이고 안전한 노출이 있는 엔드포인트는 정말로 예상치 못한 데이터의 탐지를 희생하지 않고도 응답 샘플링에서 제외할 수 있도록 지원했습니다. 예를 들어, OAuth 클라이언트 시크릿은 승인된 사용자를 위한 전용 자격 증명 관리 엔드포인트에서는 의도적으로 반환될 수 있지만, 관련 없는 API 응답에 포함된다면 심각한 문제가 될 것입니다.

조기 탐지 실행

확장된 응답 샘플링 시스템은 코드 리뷰나 수동 QA만으로는 잡아내기 매우 어려웠을 미묘한 문제를 드러내는 강력한 탐지 레이어가 되었습니다. 덕분에 스테이징 단계에서 위험을 사전에 발견하고 프로덕션 회귀에 신속하게 대응할 수 있게 되었습니다. 다음은 몇 가지 예시입니다.

• 오랫동안 사용되지 않은 데이터 필드가 특정 응답에 예기치 않게 포함되는 문제를 잡아냈습니다. 팀은 발견 사항을 확인하고 분류한 뒤, 신속하게 수정 사항을 배포했습니다.
• 시스템은 관련 리소스의 데이터가 명확한 필요 없이 응답에 포함되는 사례를 드러냈고, 이는 목표 지향적인 정리 작업으로 이어졌습니다.
• 응답 샘플링은 각 항목에 대한 액세스 권한을 개별적으로 확인하지 않고 리소스 목록을 반환하는 시나리오를 강조하여 권한 확인 기능을 강화하도록 유도했습니다.

정밀도와 성능의 균형을 맞추며 얻은 교훈

Figma의 여러 팀은 이러한 시스템을 구축하기 위해 협업하면서 최선을 다합니다. 보안 엔지니어들은 제품 및 플랫폼 팀과 함께 코드를 배포하며, 사용자 대면 기능에 쏟는 것과 동일한 창의성과 엄격함을 탐지 시스템에도 적용합니다.

몇 달 동안 응답 샘플링을 구축하고 운영하면서, 프로그래밍 방식의 탐지 시스템을 구축하는 데 무엇이 필요한지 다음과 같이 많은 것을 배웠습니다.

• 항상 성능에 미치는 영향 고려하기: 주의 깊게 설계하지 않으면 적은 양의 모니터링이라도 지연 시간을 유발할 수 있음을 발견했습니다. 샘플링 비율을 조정하고 검사를 비동기적으로 실행함으로써, 트래픽에 대한 의미 있는 가시성을 확보하면서도 사용자 체감 성능을 유지했습니다.
• 오탐 관리하기(그러지 않으면 우리가 오탐에 휘둘리게 됩니다!): 높은 오탐률은 팀을 압도하고 알림에 대한 신뢰를 떨어뜨릴 수 있습니다. 이를 해결하기 위해 동적 허용 목록과 엄격한 분류 업무 흐름을 구현했습니다. 이에 따라 안전한 것으로 알려진 사례를 빠르게 필터링하여 엔지니어가 진짜 위험한 발견 사항에 집중할 수 있게 되었습니다.
• 맥락의 중요성: 모든 민감한 데이터 노출이 똑같이 문제가 되는 것은 아닙니다. 동적 구성을 사용하여 서비스를 재배포하지 않고도 탐지 규칙을 빠르게 조정할 수 있었습니다. 이를 통해 합법적인 사용 사례를 섬세하게 처리하면서도 비정상적이거나 예상치 못한 시나리오는 여전히 플래그를 지정할 수 있었습니다.
• 계층화된 방어 체계 구축: 스테이징과 프로덕션 모두에서 시스템을 실행함으로써 두 개의 방어선을 확보했습니다. 릴리스 전 조기 탐지와 회귀를 포착하기 위한 지속적인 모니터링입니다. 샘플링된 요청의 경우, 요청 중에 실제로 액세스된 값만 추적되도록 하여 불필요한 오버헤드를 방지합니다.

앞으로의 방향

응답 샘플링을 통해 우리는 플랫폼 보안 접근 방식을 제품 보안에 적용했습니다. 애플리케이션 표면 위에 지속적인 모니터링 및 탐지 기능을 계층화하여 개발 속도를 늦추지 않고 문제를 조기에 포착했습니다.

우리는 모든 주요 인터랙션 채널에서 잠재적인 노출을 식별할 수 있도록 이 프레임워크를 더 많은 서비스와 다른 사용자 접점으로 확장하고 있습니다. 또한 광범위한 개인정보(PII) 및 규제 데이터 등 추가적인 민감 데이터 카테고리로 범위를 확장하여, 진화하는 규정 준수 요구에 맞춰 탐지 역량을 확장할 계획입니다.

시스템이 성장함에 따라 응답 샘플링의 효과를 유지하기 위해 더 적응력 있고 인사이트 있는 시스템으로 만드는 방법을 모색하고 있습니다. 예를 들어, 리소스 사용과 가시성의 균형을 맞추기 위한 더 세밀한 샘플링 제어, 조사를 가속화하기 위한 자동 분류, 시간 경과에 따른 추세를 보여주는 더 풍부한 리포팅 등을 검토하고 있습니다. 이 프레임워크를 확장하더라도 우리의 목표는 동일합니다. 사용자 데이터를 보호하고 모든 Figma 경험이 빠르고, 안정적이며, 안전하게 유지되도록 지원하는 겁니다.

애플리케이션 보안(AppSec) 팀이 인프라 보안 접근 방식을 차용하는 경우는 드물지만, 응답 샘플링 구축은 이를 애플리케이션 계층에 적용했을 때 얼마나 효과적일 수 있는지를 입증했었습니다. 지속적인 탐지를 애플리케이션 계층에 더 가깝게 가져옴으로써 문제를 더 빨리 발견하고 더 신속하게 대응할 수 있었습니다. 이는 다른 팀들도 채택하면 유익할 접근 방식이라고 생각합니다.

현재 엔지니어를 채용 중입니다! Figma에서의 생활에 대해 더 알아보고 채용 중인 직무를 확인해 보세요.