受限 Windows 环境中如何安全部署 Shiny 应用？
结论
共享文件夹适合存放代码，但不适合作为多人使用的 Shiny 托管环境。可以先请 IT 评估是否能使用一台公司管理的 Windows Server：在服务器上安装和维护 R 及应用依赖，由服务器运行 Shiny 应用，再通过公司认可的 Web 入口供用户用浏览器访问。这样通常不需要用户在自己的电脑上安装 R、Rtools 或 RStudio，也无需让他们接触应用代码。
这类部署需要 IT 设计和维护，不能靠把文件夹映射成网络盘来实现。Windows 上如何管理 Shiny 进程、并发会话、身份验证和更新，需要结合公司的基础设施验证。
可与 IT 讨论的架构
可以向 IT 说明以下需求：应用运行在公司控制的 Windows 服务器上，使用受限的服务账号；数据存放在获批的内部位置；用户通过公司内网或 VPN，经 HTTPS 访问网页入口。如果需要反向代理，可以请 IT 评估 IIS 和相应的代理配置。具体采用哪些组件、如何配置，应由 IT 根据现有标准决定。
典型访问路径如下：
用户浏览器 → 公司 HTTPS 入口/反向代理 → Windows Server 上的 Shiny 应用 → 获批的数据存储
应用监听端口可以只允许代理或指定内网网段访问。端口号、服务器地址和网络规则应由 IT 分配，不要将应用端口直接暴露到互联网。代理还需正确处理 Shiny 使用的 WebSocket 连接；配置不支持时，页面可能可以打开，但交互功能会异常。
部署前需要确认的事项
- 服务器和运行方式：公司是否有获批、可长期运行 R 应用的 Windows Server？应用进程通过什么服务或进程管理方式启动、监控和重启？
- 用户身份与访问范围：是否使用公司现有的登录和授权机制？哪些业务组可以访问？访问是否限于内网或 VPN？
- 数据位置与临时文件：敏感数据、上传文件、下载结果、缓存和临时文件分别存放在哪里？日志是否会记录敏感内容？
- 依赖和更新：由谁安装 R 包和系统依赖？如何固定版本、审批更新和回滚？用户不应有权修改生产代码或服务器包库。
- 并发和资源：预计有多少人同时使用？应用会进行多重计算吗？需要用有代表性的数据验证内存、CPU 和会话数量。
- 网络要求：客户端通过哪个 HTTPS 地址访问？代理与应用服务器之间需要哪些内部连接？是否需要支持 WebSocket？端口和网络规则由 IT 按照网络分区和安全规范确定。
给 IT 的需求说明示例
希望评估在公司管理的 Windows Server 上托管内部 Shiny 应用。用户通过公司 HTTPS 入口和现有身份认证从浏览器访问，无需在终端安装 R，也不直接访问代码目录。应用仅使用获批的内部数据源，服务账号遵循最小权限原则。请协助确认进程托管与监控方式、反向代理及 WebSocket 支持、内网访问规则、日志和临时文件位置、补丁与依赖更新流程，以及并发容量评估。应用端口和访问范围由 IT 按现有安全规范配置。
这段说明提出的是需要评估的能力，没有预设端口号，也没有要求开放公网访问。最终方案应通过公司的安全和运维审批。
对现有方案的判断
- 从共享文件夹启动：每位用户都需要安装并维护 R 环境，代码也会出现在用户操作界面中。这种方式适合小范围开发或演示，不适合作为稳定的多人使用入口。
- shinyapps.io：是否适用取决于数据分类、部署区域和公司的云服务政策。涉及敏感数据的应用，应先按照公司要求确认数据处理和存储条件。
- Shiny Server：常见的 Shiny Server 部署依赖 Linux。如果环境不允许使用 Linux，不应假设它可以直接安装在现有的 Windows 工作站上运行。
- Chrome portable 和 shell 命令：这类启动方式没有解决应用进程托管、访问控制和稳定运行的问题，也可能触发企业终端安全策略，不适合用来绕过 IT 控制。
- 商业托管产品：不要只根据供应商所在地判断数据的实际部署位置。可以请供应商和 IT 核实其部署方式、数据驻留、访问控制和合同条款是否符合公司要求。在确认前，不要放入敏感数据。
如果 IT 暂时没有可用的 Windows 托管方式，可以先选一个不含敏感数据、访问人数有限的应用进行内部概念验证，记录依赖、并发、资源和网络需求，再据此讨论正式运行环境。不要通过未经批准的云服务、便携式程序或脚本启动方式绕过安全限制。
备注：内容仅供参考。