R-Shiny部署AWS Fargate的会话安全及多用户数据隔离问题咨询

问题1：直接将RShiny应用部署在AWS Fargate上多用户访问是否存在会话干扰、数据泄露风险？ #

存在明确风险。原生RShiny单实例默认多用户共享同一个R进程，所有访问该实例的用户会共用同一套运行环境、全局变量空间，如果应用没有做显式的会话级变量隔离，很容易出现A用户的操作修改全局数据后，B用户直接读取到修改后内容的情况，甚至用户提交的敏感数据会被同实例的其他访问者获取。该风险是RShiny单实例的原生特性导致的，和底层运行环境是否为Fargate无关。

问题2：可行的会话/数据隔离方案（可达到ShinyProxy同等安全效果） #

• 方案1：单用户单Fargate任务调度模式
  可自行实现轻量调度逻辑替代ShinyProxy功能：在前端接入层新增调度服务，每个新用户访问时单独为其启动一个独立的Fargate任务运行RShiny实例，用户的所有流量仅路由到专属的Fargate任务上，用户会话结束后自动销毁对应任务。该模式本质和ShinyProxy单用户单R会话的逻辑完全一致，隔离性拉满，同时依托Fargate的弹性能力，无需自行维护底层服务器资源，可解决此前专用服务器部署的扩容限制问题。冷启动延迟敏感的场景可预留部分空闲Fargate任务做池化预热。
• 方案2：改造RShiny应用实现会话级变量隔离 + 多用户共享Fargate实例
  如果对成本敏感度较高，不想为每个用户启动独立Fargate任务，可先改造RShiny应用代码：所有用户相关的变量、数据全部存储在session$userData这个Shiny自带的会话级存储空间内，绝对不要使用全局变量存储用户数据，所有数据库操作、文件读写都要加上用户唯一标识做隔离。改造完成后单个Fargate实例可承接多用户流量，该模式隔离性依赖应用代码的正确性，上线前需要做充分的多用户并发测试验证没有变量串用问题。
• 方案3：基于AWS EKS部署ShinyProxy
  无法直接在Fargate上部署ShinyProxy是指不能直接将ShinyProxy作为单个Fargate任务运行就实现自动调度，实际可将ShinyProxy部署在AWS EKS上，底层工作节点用Fargate承载，ShinyProxy本身作为EKS的一个服务运行，它调度的每个RShiny实例都作为独立的EKS Pod跑在Fargate上，该模式可完全复用此前基于ShinyProxy的配置逻辑，迁移成本最低，同时也能享受到Fargate的弹性扩缩容能力。

内容的提问来源于stack exchange，提问作者LePyka