# 보안 검토를 위한 한 장

> **이 장에서 배우는 것**
> 데이터가 어디에 갇혀 있고, 밖으로 나가는 길이 몇 개이며, 각각을 무엇으로
> 잠그는지. 도입 심사에 그대로 낼 수 있는 형태로 정리합니다.

## 왜 한 장이 필요한가

멤버 역할은 [멤버와 역할](/guide/cn-members)에, 자료 범위는
[드라이브](/guide/cn-drive)에, 도구 권한은 [도구 켜고 끄기](/guide/cn-tool-settings)에
있습니다. 각각은 잘 설명되어 있지만 **보안 검토자는 그걸 한 장으로 보고
싶어 합니다.**

이 장은 그 한 장입니다.

## 경계는 다섯 개입니다

```mermaid
graph TD
  A["1. 계정 — 누가 들어오나"] --> B["2. 워크스페이스 — 데이터 격리 단위"]
  B --> C["3. 대화 — 누가 이 대화를 보나"]
  B --> D["4. 자료 — 무엇을 재료로 쓰나"]
  B --> E["5. 밖으로 나가는 길 — 도구 · 채널 · API · 시스템"]
```

| 경계 | 무엇을 정하나 | 어디서 | 누가 |
|---|---|---|---|
| 계정 | 워크스페이스에 들어올 사람 | 멤버 화면 초대 | owner · admin |
| 워크스페이스 | **데이터가 섞이지 않는 단위** | 워크스페이스 생성 | 누구나(본인 소유) |
| 대화 | 이 스레드를 볼 사람 | 그룹 공개 범위 | owner · admin |
| 자료 | 답변의 재료가 될 파일 | 드라이브 폴더 | 올리는 사람 |
| 나가는 길 | 실행 가능한 도구·경로 | 도구 설정 · 채널 · API 키 · 시스템 | owner · admin (시스템은 owner만) |

## 2. 워크스페이스가 가장 강한 통제입니다

이게 이 장에서 제일 중요한 문장입니다.

> **워크스페이스는 데이터가 섞이지 않는 단위입니다.** 다른 워크스페이스의
> 대화·자료·도구는 서로 보이지 않습니다.

따라서 **민감도가 다른 업무는 워크스페이스를 나누는 것이 가장 확실한
통제**입니다. 같은 워크스페이스 안에서 권한을 잘게 나누는 것보다 훨씬 단순하고
설명하기 쉽습니다.

| 상황 | 권장 |
|---|---|
| 인사·법무 자료를 다룸 | **별도 워크스페이스** |
| 외부 고객 응대(위젯·채널) | **별도 워크스페이스** |
| 운영 시스템에 닿는 도구 | **별도 워크스페이스** |
| 일반 업무 | 하나로 충분 |

두 번째 줄이 특히 그렇습니다. 외부 입력이 들어오는 워크스페이스와 사내 자료가
있는 워크스페이스를 분리하면 [프롬프트 인젝션](/guide/mcp-prompt-injection)의
사고 경로가 구조적으로 끊깁니다.

## 3. 대화가 보이는 범위

| 종류 | 누가 보나 |
|---|---|
| **비공개 대화** | 만든 사람만 |
| 전체 공개 그룹 | 워크스페이스 멤버 전원 |
| 선택된 멤버 그룹 | 지정한 부서 또는 개인만 |

**"비공개"의 범위를 정확히 이해해야 합니다.** 다른 멤버에게 안 보인다는
뜻이지, 워크스페이스 소유자가 데이터베이스 수준에서 접근할 수 없다는 뜻은
아닙니다. 개인 사생활 용도가 아니라 **업무상 정리되기 전의 초안**을 두는
자리로 보세요.

## 4. 자료의 범위

[드라이브](/guide/cn-drive)에 올린 파일은 **그 워크스페이스의 답변 재료**가
됩니다. 검색은 권한을 모릅니다.

```
올리기 전 확인:
  □ 이 워크스페이스의 모든 멤버가 봐도 되는 파일인가
  □ 개인정보가 포함되어 있나 — 있다면 보관 근거와 기간이 있나
  □ 계약상 반출 제한이 있나
```

**"봐도 되는 사람"과 "물어보면 답에 딸려 나올 사람"은 같습니다.** 이 한 줄이
드라이브 정책의 전부입니다.

## 5. 밖으로 나가는 길

여기가 검토자가 가장 오래 보는 부분입니다. 길은 네 종류입니다.

### 도구

[도구 켜고 끄기](/guide/cn-tool-settings)에서 워크스페이스별로 켭니다.
판단 기준은 [도구는 권한이다](/guide/mcp-security)와 같습니다.

```
읽기 도구        →  대체로 안전 (읽는 대상이 민감하지 않다면)
되돌릴 수 있는 쓰기 →  기록만 남기면 됨
되돌릴 수 없음     →  메일 발송 · 결제 · 삭제 · 대외 게시 → 사람 승인
```

### 밖에서 안으로 — 채널 · 위젯 · 이메일

| 경로 | 누가 보낼 수 있나 |
|---|---|
| [채널](/guide/cn-channels) | 연결한 외부 서비스의 사용자 |
| [채팅 위젯](/guide/cn-chat-widget) | **웹사이트 방문자 누구나** |
| [이메일 에이전트](/guide/cn-email-agents) | **그 주소를 아는 누구나** |

**아래 두 줄이 통제의 초점입니다.** 신원 확인 없는 입력이 에이전트에 직접
닿습니다. 이 워크스페이스에 사내 자료와 쓰기 도구를 함께 두지 마세요. 그리고
[AI 기본법](/guide/ax-compliance)의 사전 고지·표시 의무가 여기서 발생합니다.

### API 키

[API 키로 외부에서 부르기](/guide/cn-api)의 키는 **그 워크스페이스의 권한을
그대로** 가집니다.

```
□ 용도마다 별도 키 (하나를 여러 곳에 쓰면 회수할 때 전부 멈춤)
□ 키는 환경변수·비밀 관리 시스템에. 코드·프롬프트에 두지 않음
□ 사용량 화면에서 키별 소비를 주기적으로 확인
□ 담당자가 바뀌면 회수 절차
```

### 시스템

[시스템](/guide/cn-systems)은 **회사 컴퓨터 한 대가 워크스페이스에 붙는
것**입니다. 그래서 등록·정책 변경은 **owner만** 할 수 있습니다. 가장 무거운
권한이므로 admin에게도 열려 있지 않습니다.

## 도입 심사 체크리스트

그대로 복사해서 쓰세요.

```
[격리]
  □ 민감 업무를 별도 워크스페이스로 분리했는가
  □ 외부 입력(위젯·채널·메일)이 사내 자료와 같은 워크스페이스에 있지 않은가

[접근]
  □ owner 1명 + admin 1~2명 구성인가 (owner 단독은 위험)
  □ 퇴사·이동 시 멤버 제거 절차가 있는가
  □ 대화 그룹 공개 범위가 부서 기준으로 설정되어 있는가

[자료]
  □ 드라이브에 올린 파일의 반출 가능 여부를 확인했는가
  □ 개인정보 포함 파일의 보관 근거와 기간이 정해져 있는가
  □ 대화·파일이 모델 학습에 쓰이는지 확인했는가 (개인 계정 병행 사용 포함)

[실행]
  □ 되돌릴 수 없는 도구에 사람 승인이 걸려 있는가
  □ 켜져 있는 도구 중 실제로 안 쓰는 것을 껐는가
  □ MCP 서버 자격증명이 최소 권한으로 발급되었는가

[외부 노출]
  □ API 키가 용도별로 분리되어 있는가
  □ 위젯·이메일 사용 시 AI 고지 문구가 노출되는가

[기록]
  □ 승인 이력이 남고 있는가 (→ 감사 기록)
  □ 사용량을 주기적으로 확인하는 사람이 있는가
```

## 심사에서 반드시 나오는 세 가지

위 목록으로 대부분 답이 되지만, 대기업 심사에서는 거의 항상 이 셋을 따로
묻습니다. 각각 전용 화면이 있습니다.

| 질문 | 어디서 답하나 |
|---|---|
| **"개인정보가 모델로 나갑니까?"** | [데이터 마스킹](/guide/cn-masking) — 나가기 전에 토큰으로 바꿉니다 |
| **"누가 무엇을 조회했는지 남습니까?"** | [감사 로그](/guide/cn-audit) — 질의와 근거 문서가 남습니다 |
| **"사내 계정 체계로 로그인됩니까?"** | [SSO와 부서 동기화](/guide/cn-sso) — IdP 그룹이 부서가 됩니다 |

**세 번째에서 막히면 나머지는 검토조차 안 됩니다.** 별도 비밀번호를 만들어야
한다는 것 자체가 통과 조건에 걸리는 회사가 많습니다.

그리고 실행 권한을 사람 승인으로 좁히는 장치가
[승인 대기와 작업자 권한](/guide/cn-approvals)입니다 — "되돌릴 수 없는 도구에 사람
승인"의 실제 구현입니다.

## 정기 점검 — 분기 1회

```
□ 멤버 목록 (퇴사자 남아 있나)
□ 켜져 있는 도구 (3개월간 한 번도 안 쓴 것)
□ API 키 (쓰는 곳이 사라진 키)
□ 드라이브 (오래된 민감 파일)
□ 시스템 (연결이 끊긴 채 남아 있는 자리)
```

## 자주 하는 오해

### "권한을 잘게 나누면 안전해지지 않나요?"

**어느 선을 넘으면 반대가 됩니다.** 개인마다 예외를 만들기 시작하면 반년 뒤에
아무도 현재 상태를 설명하지 못합니다. **워크스페이스로 크게 나누고, 그 안은
부서 단위로** 하는 편이 검토하기도 유지하기도 낫습니다.

### "비공개 대화면 아무도 못 보는 것 아닌가요?"

**다른 멤버에게 안 보인다는 뜻입니다.** 데이터베이스 수준의 접근이나 법적
요구에 의한 제출까지 막아주지는 않습니다. 개인 사생활 정보는 애초에 넣지
마세요.

---

## 확인

**1. 민감도가 다른 업무를 다룰 때 가장 확실한 통제는?**

<details>
<summary>답</summary>

**워크스페이스를 나누는 것**입니다. 워크스페이스는 데이터가 섞이지 않는
단위라, 같은 워크스페이스 안에서 권한을 잘게 나누는 것보다 단순하고 설명하기
쉽습니다.
</details>

**2. 채팅 위젯과 이메일 에이전트를 쓸 때 왜 워크스페이스를 분리합니까?**

<details>
<summary>답</summary>

**신원 확인 없는 외부 입력이 에이전트에 직접 닿기 때문**입니다. 사내 자료와
쓰기 도구가 같은 워크스페이스에 있으면 프롬프트 인젝션의 사고 경로가 완성됩니다.
분리하면 그 경로가 구조적으로 끊깁니다.
</details>

**3. 시스템 등록이 admin에게도 열려 있지 않은 이유는?**

<details>
<summary>답</summary>

**회사 컴퓨터 한 대를 워크스페이스에 붙이는, 가장 무거운 권한이기 때문**입니다.
그 컴퓨터에서 할 수 있는 일 전체가 워크스페이스로 들어오므로 owner만 등록·정책
변경을 할 수 있습니다.
</details>

---

마지막으로 잘 안 될 때 무엇부터 보는지 정리합니다 →
[문제 해결](/guide/cn-troubleshooting)