보안·거버넌스
OIDC, API key, BYOK, ZDR, WAF, BotID, approval을 결합해 엔터프라이즈 AI 운영 통제를 설계하는 방법을 정리합니다.
핵심 요약
- 엔터프라이즈 AI 보안은 인증·네트워크·데이터 정책·실행 격리·사람 승인으로 계층화하고, side effect와 untrusted execution은 별도 경계로 분리합니다.
- 2026-04 Next.js 보안 권고에 따라 CVE-2026-23869 등 5건을 점검하고 16 계열은 16.2.3 이상을 기준선으로 둡니다.
- 통제는 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-04 보안 기준선
2026년 3~4월 Next.js 보안 권고는 App Router, Server Actions, 이미지 최적화, 개발 서버 경계를 함께 점검하라고 짚습니다. 특히 2026년 4월 공개된 CVE-2026-23869는 React Server Components 기반 Server Function endpoint에서 과도한 CPU 사용을 유발하므로, Next.js 16 계열은 16.2.3 이상을 기준선으로 둡니다.
| CVE | 영역 | 위험 | 패치 기준 |
|---|---|---|---|
| CVE-2026-23869 | React Server Components / Server Functions | crafted request로 CPU DoS 가능 | Next.js 15.5.15 또는 16.2.3 |
| CVE-2026-27977 | next dev internal endpoints | Origin: null 처리로 dev 보호 우회 가능 | Next.js 16.1.7 |
| CVE-2026-27978 | Server Actions CSRF | sandboxed context에서 Origin: null 우회 가능 | Next.js 16.1.7 |
| CVE-2026-27979 | PPR resume buffering | oversized next-resume payload로 DoS 가능 | 보안 권고의 패치 버전 확인 |
| CVE-2026-27980 | next/image disk cache | unbounded cache growth로 저장소 고갈 가능 | Next.js 15.5.14 또는 16.1.7 |
즉시 조치 필요
AI 에이전트 UI가 Server Actions, App Router, 이미지 업로드/최적화를 함께 쓴다면 Next.js 보안 권고를 단순 framework 업데이트가 아니라 agent ingress 보안 이슈로 취급하세요. 개발 서버는 외부 네트워크에 노출하지 말고 production은 16.2.3 이상을 우선 기준으로 둡니다.
보안 점검 체크리스트 (2026-05)
- Next.js 버전이 16.2.3 이상인지 확인
- dev 환경이 외부 네트워크에 노출되지 않았는지 확인
- Server Action에 CSRF/origin 검증과 민감 action별 추가 검증이 있는지 확인
- PPR/Server Function endpoint에 request size와 WAF 정책이 있는지 확인
- 이미지 최적화 캐시 크기와 remote/local pattern을 검토
통제 계층
| 통제 | 배치 위치 | 담당 리스크 |
|---|---|---|
| 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가 남는가