보안·거버넌스
OIDC, API key, BYOK, ZDR, WAF, BotID, approval을 결합해 엔터프라이즈 AI 운영 통제를 설계하는 방법을 정리합니다.
핵심 요약
- 엔터프라이즈 AI 보안은 인증·네트워크·데이터 정책·실행 격리·사람 승인으로 계층화하고, side effect와 untrusted execution은 별도 경계로 분리합니다.
- Next.js 보안 기준은 최신 권고·실제 기능·배포 의존성으로 결정하며, 9~10월 이미지 처리·cache 관련 권고를 함께 점검합니다.
- 통제는 WAF/BotID(외부 진입), OIDC(신원), Gateway의 API key scope·BYOK·ZDR(데이터), Sandbox(실행)로 배치합니다.
- 환불 발행·권한 변경처럼 파괴력이 큰 action만 승인 게이트로 묶고, 승인 없이 허용할 범위를 명확히 줄입니다.
- 감사 로그에 request/workflow id, user/operator id, project/api key, model/provider, tenant id를 최소 항목으로 남깁니다.
엔터프라이즈 AI의 보안은 "모델이 안전한가"보다 누가 어떤 권한으로 어떤 데이터를 어떤 런타임에서 처리했는가를 추적할 수 있느냐에 달려 있습니다.
그래서 통제도 단일 기능이 아니라 인증, 네트워크, 데이터 정책, 실행 격리, 사람 승인으로 계층화합니다.
2026-10-23 Next.js 보안 기준
과거의 16.2.3 이상이라는 숫자는 4월 특정 권고의 패치 기록입니다. 이를 현재 전체 보안 기준으로 사용하지 않습니다. 설치된 Next.js·React·이미지 처리 의존성, 실제 사용 기능과 배포 런타임을 최신 공식 보안 권고에 대조합니다.
| 최근 권고 | 영향 조건 | 해당 권고의 수정 버전 |
|---|---|---|
| Image Optimization SVG RCE, 10월 14일 | glibc Linux의 이미지 최적화에 사용되는 upstream library | 15.5.28 / 16.4.1; sharp 0.35.5 이상 여부도 확인 |
use cache typed array RCE, 10월 14일 | 영향을 받는 use cache 함수 경로 | 16.4.1 |
next/og ImageResponse RCE, 9월 22일 | Node.js 구현에서 외부 입력이 SVG 내용·속성·스타일에 전달됨 | 16.3.6 |
이 표는 최근 주요 권고의 요약이며 전체 취약점 목록이 아닙니다. 2026-10-23 공식 문서의 최신판은 16.4.2입니다. 지원하는 릴리스 계열의 최신 patch를 선택하고, lockfile·실제 배포 산출물·회귀 테스트 결과를 함께 기록합니다.
배포 전 확인
- 사용 중인 기능과 각 권고의 affected range·patched version을 대조합니다.
- lockfile과 배포 산출물의 Next.js·React·
sharp버전이 패치 의도와 일치하는지 확인합니다. - 개발 서버는 외부에 노출하지 않고, Server Actions의 인증·권한·origin 검증을 확인합니다.
- 이미지·SVG·동적 OG 입력과 cache 경계를 회귀 테스트합니다. WAF 규칙 적용만으로 패치를 대신했다고 판단하지 않습니다.
통제 계층
| 통제 | 배치 위치 | 담당 리스크 |
|---|---|---|
| OIDC / Auth | 앱, 내부 서비스 | 사용자와 서비스 신원 분리 |
| API key scope | Gateway, worker | 호출 주체 추적 |
| BYOK / Secrets | Gateway | 고객/팀별 자격 증명 분리 |
| ZDR | Gateway 정책 | 데이터 보존 제한 |
| WAF / BotID | 외부 진입점 | 악성 요청, bot abuse |
| Sandbox | tool runtime | 코드 실행, 파일 유출 |
| Human approval | workflow gate | 고위험 비즈니스 action |
보안 경계 구조
인증과 자격 증명 운영
| 항목 | 권장 방식 | 이유 |
|---|---|---|
| 사용자 인증 | OIDC / SSO | 회사 계정과 권한 연결 |
| 서비스 간 호출 | 전용 service identity | 운영자 행위와 분리 |
| Gateway key | app key, workflow key 분리 | 비용/감사 분리 |
| BYOK | 규제 고객에 한정 | 복잡도 통제 |
| secret rotation | 중앙화된 정책 + 주기 점검 | drift 방지 |
승인 게이트를 어디에 둘 것인가
| action | 승인 필요 여부 | 이유 |
|---|---|---|
| CRM 메모 작성 | 보통 불필요 | 낮은 파괴력 |
| 고객 환불 발행 | 필요 | 재무 리스크 |
| 외부 메일 발송 | 상황별 | 브랜드/법무 리스크 |
| 권한 변경 | 필수 | 보안 리스크 |
실무 해석
approval은 UX를 방해하는 요소가 아니라 비즈니스 위험을 갈라놓는 장치입니다. 승인 없는 자동화를 늘리는 것보다, 어떤 action을 승인 없이 허용할지 명확히 줄이는 편이 운영상 더 안전합니다.
감사 추적 최소 항목
| 필드 | 이유 |
|---|---|
| request id / workflow id | 사건 재구성 |
| user id / operator id | 책임 추적 |
| project / api key | 비용/권한 소유자 추적 |
| model / provider | 정책 위반 분석 |
| tool name / approval status | 고위험 action 확인 |
| tenant id | 데이터 경계 감사 |
운영 기준
- auth는 앱 계층에서, 비용과 모델 정책은 Gateway 계층에서 분리합니다.
- 민감 경로는 ZDR 기본값을 우선 고려합니다.
- mutating tool은 approval candidate로 먼저 분류합니다.
- 외부 입력 방어는 WAF/BotID에서, 내부 실행 격리는 Sandbox에서 담당합니다.
ADR 스타일 결론
Decision
보안 통제는 단일 기능으로 해결하지 않고, 인증, API key scope, 데이터 정책, 외부 입력 방어, 실행 격리, 사람 승인으로 계층화합니다. 특히 side effect와 untrusted execution은 별도 경계로 분리합니다.
실무 체크리스트
- app auth와 service auth가 분리돼 있는가
- app key와 workflow key가 분리돼 있는가
- mutating action에 approval 기준이 있는가
- audit log에 request, workflow, operator, tenant가 남는가