Google Workspace를 위한 SOC 2 준수: 알아야 할 사항

조직이 SOC 2를 추진하고 있다면 — 그리고 대부분의 B2B 소프트웨어 기업은 고객이 요구하기 때문에 결국 이를 추진하게 됩니다 — Google Workspace는 그 범위에 포함될 것입니다. Google Workspace는 감사인이 검토하는 기준에 직접적으로 대응하는 ID, 문서, 접근 통제를 보유하고 있습니다. 이 글에서는 Workspace가 SOC 2 프로그램에 어떻게 부합하는지, 그리고 마지막 순간에 허둥대지 않고 Workspace 측면을 준비하는 방법을 설명합니다.

먼저 용어에 대해 짚어두겠습니다: SOC 2는 독립적인 CPA 법인이 수행하는 *인증(attestation)*이며, 스스로 부여하는 배지가 아닙니다. 그 결과물은 감사인이 작성한 보고서이며, 스스로 선언하는 라벨이 아닙니다. 내부적으로 할 수 있는 일은 통제를 구축하고 이를 입증하며 증거를 수집하여 인증 절차가 원활하게 진행되도록 하는 것입니다. 이 글이 다루는 내용이 바로 그것입니다.

SOC 2에 대한 간단한 안내

SOC 2는 서비스 조직의 통제를 신뢰 서비스 기준(Trust Services Criteria, TSC)에 따라 평가합니다: 보안(항상 포함되며 흔히 공통 기준이라고 불림), 그리고 선택적으로 가용성, 처리 무결성, 기밀성, 개인정보 보호가 있습니다. 보안 기준 — CC 시리즈 — 이 바로 Google Workspace가 가장 많이 등장하는 부분입니다.

Type I 보고서는 특정 시점에 통제가 적절하게 *설계*되었는지를 평가합니다. Type II 보고서는 일정 기간(일반적으로 3~12개월) 동안 통제가 *효과적으로 운영*되었는지를 평가합니다. 고객들이 일반적으로 원하는 것은 Type II이며, 여기에는 중요한 함의가 있습니다: 감사 당일뿐만 아니라 해당 기간 전체에 걸쳐 작동하는 통제와, 그것이 작동했음을 보여주는 증거가 필요합니다.

Google Workspace가 기준에 부합하는 지점

여러 공통 기준은 이미 다루고 있는 Workspace 통제와 명확하게 대응합니다:

• CC6.1 — 논리적 접근 통제. 누가 보호된 정보에 접근할 수 있는지, 그리고 접근이 승인된 사용자로 어떻게 제한되는지입니다. Workspace 관점에서는: 계정 프로비저닝, MFA 시행, 공유 통제, 그리고 외부 및 서비스 계정을 포함한 모든 ID가 보유한 접근 권한입니다.
• CC6.2 — 등록 및 승인. 신규 사용자는 접근 권한이 부여되기 전에 등록 및 승인되어야 하며, 더 이상 필요하지 않을 때는 접근 권한이 제거되어야 합니다. 입사/이동/퇴사에 따른 관리가 여기에 속합니다.
• CC6.3 — 최소 권한 및 직무 분리. 접근 권한은 역할에 기반하며 필요한 최소 수준으로 유지되어야 합니다. 과도한 권한 부여와 관리자 권한 확산은 이 기준에 대한 지적 사항이 됩니다.
• CC6.6 — 외부 위협으로부터의 보호. 외부에서 접근 가능한 표면: 공개 링크, 외부 공유, 조직 외부 ID에 부여된 접근 권한입니다.
• CC7.x — 모니터링 및 사고 대응. 이상 징후를 탐지하고 보안 이벤트에 대응하는 것입니다. 공유나 접근 권한 변경 시점을 파악하고 이를 조사할 수 있는 능력이 이를 지원합니다.

번호를 외울 필요는 없습니다. 중요한 점은 MFA 시행, 공유 통제, 오래된 접근 권한 제거, 서드파티 앱 관리와 같은 일상적인 Workspace 작업이 곧 감사인이 확인하고자 하는 통제 증거라는 것입니다.

감사인이 실제로 요구하는 것

감사인은 확언을 원하지 않습니다. 그들은 증거를 원합니다. Workspace 관련 통제에 대해서는 다음과 같은 요청을 예상해야 합니다:

• MFA가 시행되고 있다는 증거(단순히 "켜두었습니다"가 아니라 정책과 그 적용 사례).
• 관리자 목록과 각 특권 역할에 대한 근거.
• 접근 검토의 증거 — 민감한 데이터에 접근할 수 있는 대상을 주기적으로 확인하고 그 결과에 대해 조치를 취했다는 것.
• 직원 퇴사 시 권한 회수 기록.
• 공유 설정과 외부 공유가 어떻게 통제되는지.
• 보안 발견 사항이 해결까지 어떻게 추적되었는지에 대한 기록.

반복되는 주제는 문서화되고 반복 가능한 프로세스와 감사 추적입니다. 존재하지만 흔적을 남기지 않는 통제는 입증하기 어렵습니다. 지속적으로 운영되며 발견한 사항을 기록하는 통제는 입증하기 쉽습니다.

Workspace 측면 준비 방법

1. 구성 기준선을 수립하십시오. 공유, 2단계 인증, Marketplace 제한, 이메일 인증 등 관리자 설정의 의도된 상태를 문서화하고, 일정에 따라 실제 상태와 대조하십시오. 드리프트는 깨끗한 감사의 적입니다.
2. 증거로 남길 수 있는 접근 검토를 수행하십시오. 외부 및 비인간(non-human) ID를 포함하여 누가 민감한 데이터에 접근할 수 있는지 주기적으로 검토하고 그 결과물을 보관하십시오. "분기마다 접근 권한을 검토했고, 여기 그 기록이 있습니다"가 바로 CC6.3이 요구하는 것입니다.
3. 공유를 강화하고 문서화하십시오. 공개 및 외부 공유를 통제하고 현재 상태를 보여줄 수 있도록 함으로써 CC6.1 및 CC6.6에 대응하십시오.
4. 발견 사항을 해결까지 추적하십시오. 노출을 발견하면 이를 기록하고, 수정하고, 그 추적 기록을 보관하십시오. 이는 모니터링 및 개선 조치 기준을 지원합니다.
5. 감사 로그를 유지하십시오. 보안 관련 조치에 대한 타임스탬프 기록이 있으면 "누가 언제 무엇을 했는가"라는 질문에 쉽게 답할 수 있습니다.

이 중 많은 부분은 일반적으로 좋은 Google Workspace 보안과 겹칩니다 — 이것이 바로 핵심입니다. SOC 2는 별도로 덧붙여진 프로젝트가 아니라, 여러분의 보안 관행을 가시화하고 증거화한 것입니다.

지속적인 증거가 감사 허둥대기를 이깁니다

전형적인 실패 방식은 준수를 하나의 이벤트로 취급하는 것입니다: 감사 전 한 달 동안 스크린샷과 스프레드시트로 정신없이 매달리고, 이를 매년 반복하는 것입니다. 이는 스트레스가 크고 오류가 발생하기 쉬우며, Type II 감사인이 당연히 의문을 제기할 만한 특정 시점의 증거를 만들어냅니다.

대안은 지속성입니다: 일 년 내내 보안 상태를 통제하고, 그 부산물로 증거를 생성하며, 이미 정리된 추적 기록을 가지고 감사에 임하는 것입니다. 발견 사항을 SOC 2 기준에 매핑하고 감사인이 바로 사용할 수 있는 증거를 생성하는 보안 상태 관리 도구는 허둥대기를 단순한 내보내기(export) 작업으로 바꿔줍니다.

감사에서 Workspace 부분의 흔한 함정

반복적으로 나타나는 몇 가지 실수는 미리 대비할 가치가 있습니다:

• "설정됨"과 "시행됨"을 혼동하는 것. 2단계 인증 정책을 켜는 것은 모든 계정에 실제로 적용되는 것과 같지 않습니다. 감사인은 후자를 검사합니다. 시행이 조직 전체에 걸쳐 유지되는지 확인하십시오 — Google Workspace 전체에서 MFA 시행하기 가이드를 참고하십시오.
• 접근 검토를 단순한 체크박스로 취급하는 것. 기록, 범위, 후속 조치 없이 "우리는 접근을 검토합니다"라고 말하는 것은 증거가 되지 않습니다. 결과물을 보관하고 발견 사항에 대해 조치가 이루어졌음을 보여주십시오.
• 비인간 ID를 잊는 것. 서비스 계정과 AI 에이전트도 접근 권한을 보유하며, 최소 권한(CC6.3)을 검증하는 감사인은 "사람만 검토했습니다"라는 답변을 받아들이지 않습니다. 이들을 관리하십시오 — 위험한 AI 에이전트 탐지하기를 참고하십시오.
• 감사 사이에 구성 드리프트를 방치하는 것. 1월에는 깨끗했던 기준선이 6월에는 드리프트되어 있다면 Type II 지적 사항으로 이어집니다. 연간 스냅샷이 아닌 지속적인 점검이 이를 방지합니다.

준수는 우수한 보안의 부산물입니다

SOC 2의 Workspace 측면에서 가장 유용한 관점 전환은, *감사를 위해* 통제를 구축하는 것이 아니라 견실한 보안 프로그램을 운영하고 감사가 그것을 관찰하도록 하는 것입니다. 접근 통제 기준 하에서 감사인이 확인하고자 하는 모든 것은 어차피 여러분이 원할 만한 것들입니다: 시행되는 ID 관리, 통제되는 공유, 관리되는 서드파티 접근, 그리고 유지되는 구성 기준선. 감사는 단지 이를 가시화하고 증거화하도록 요구할 뿐입니다.

이를 내면화한 팀은 연간 주기를 더 이상 두려워하지 않게 됩니다. 통제는 일 년 내내 운영되고, 증거는 그 부산물로 축적되며, 감사는 별도의 프로젝트가 아니라 이미 완료된 작업에 대한 검토가 됩니다. 실무적으로 이는 허둥대는 것과 준비되어 있는 것의 차이이기도 합니다.

8200.dev는 여러분의 Google Workspace 보안 상태를 SOC 2, ISO 27001, GDPR 통제 체계에 매핑하고 감사인에게 전달할 수 있는 증거 패키지를 생성합니다 — 저희가 실제로 관찰한 것에 한정된 정직한 결과이며, 근거 없는 준수 주장은 하지 않습니다. 작동 방식 또는 저희의 보안 관행에 대해 더 알아보십시오.

감사를 준비하고 계십니까? 무료 보안 감사를 시작하십시오 그리고 여러분의 Google Workspace 보안 상태가 감사인이 검토하는 접근 통제 기준에 어떻게 부합하는지 확인해 보십시오.