# 内部 app 平台网络模型：公网 + SSO 闸门 vs 内网 + VPN

> **日期**: 2026-05-13
> **模块**: internal-app-platform
> **类型**: 架构决策权衡

## 背景

internal-app-platform PRD 第一版草稿默认"仅内网 + VPN 必装"。直属领导审 PRD 时改为"公网 + SSO 闸门"——员工居家不再连 VPN，直接 SSO 登录即可访问。

## 关键洞察

**SSO 闸门 + 公网 ≈ 仅内网 + VPN，从攻击面上**：
- 未登录访问者只能看到 Entra ID 登录页（公网 vs 内网无差别）
- 已登录员工拿到内容（公网+SSO vs 内网都需要先认证）
- 区别仅在"登录前"的攻击面：公网暴露了 SSO/Caddy 自身的漏洞面

**取舍核心**：
- VPN 是基础设施摩擦税（每个居家员工每天都要付）
- 公网暴露面是低概率/高成本风险（SSO 失败告警 + Caddy rate-limit + 巡检可压缩）
- AI-first 工具的目标用户是非技术员工，VPN 学习成本 > 公网攻击风险

## 决策模式

**适用于**："员工自助"类内部工具平台。AI-first 时代，给非技术员工降低任何"专业 IT 操作"门槛（VPN / 终端 / 配置文件）都是值得的，安全防护应该往后退一档而不是堆在用户面前。

**不适用于**：核心业务系统（FFOA approval-engine 等）——这些有真实业务数据，攻击面值钱，公网暴露 ROI 反过来。

## 文档对齐成本

一次"网络模型反转"导致：
- PRD §访问网络模型 整段重写
- PRD §风险 删 VPN 摩擦 + 新增公网暴露面
- PRD §不做内容扫描 理由要重写（不能再说"内网隔离"）
- 05 UI spec 3 处 VPN 文案（i18n keys + tooltip + 错误文案）
- 09 test scenarios 3 处 VPN 场景
- §术语 placeholder 6 处 `<APPS_DOMAIN>` 替换为实际域名

**教训**：网络模型这种基础约束应该在 PRD 第一稿就**强制审批人确认**而不是 AI 默认拍板。今后写"访问网络模型"段时，**先在 PRD 顶部做单题确认**：仅内网 / 公网+SSO / 公网无鉴权，三选一。

## 验证状态

- ✅ 直属领导口头批准
- ⏳ Phase 0 PoC 公网 MCP 可达性实测待跑
- ⏳ Caddy rate-limit + SSO 失败告警实装待做