AWS Aurora MySQL/NestJS TypeORM行级安全实现方案咨询

现有两种方案的可行性 #

1. API侧修改所有查询，关联权限表 #

完全可行，这是最直接的落地方式。核心逻辑是在每个数据查询/操作的SQL中，通过关联Relationships表过滤当前用户有权访问的数据：

• 查询场景：获取data时，通过JOIN Relationships添加条件user = 当前用户ID AND module = 'data' AND access_level IN ('read', 'full')，同时关联data表的company字段。
• 写操作场景：创建/更新数据前，先校验用户对目标公司的对应权限（比如创建需full权限，更新需update或full权限）。

注意点：必须封装权限校验逻辑，比如基于TypeORM自定义Repository或通用查询方法，避免每个接口重复编写权限关联代码，降低维护成本和漏写风险。

2. 基于用户或企业组合创建视图 #

可行但存在局限性：

• 视图适合简化查询逻辑，比如创建user_data_view自动关联data和Relationships表，过滤当前用户有权访问的数据。但视图仅能处理查询场景，创建、更新等写操作仍需在API层单独校验权限。
• 若按企业创建视图，跨企业访问的用户需同时查询多个视图，逻辑复杂度高；若按用户创建视图，用户量较大时会导致视图数量激增，增加数据库维护成本。

其他可考虑的方法 #

1. TypeORM生命周期钩子/拦截器 #

利用TypeORM的生命周期钩子（如beforeFind、beforeInsert、beforeUpdate）或自定义拦截器，统一注入权限过滤逻辑：

• 查询时，在beforeFind钩子中自动为QueryBuilder添加权限关联条件，无需每个查询手动编写。
• 写操作时，在beforeInsert/beforeUpdate钩子中校验用户对目标资源的权限，不符合则抛出异常。

这种方式能实现权限逻辑的统一维护，避免重复代码，与TypeORM集成度高。

2. 权限校验中间件 #

在API服务层或网关层添加权限校验中间件：

• 用户请求接口时，中间件先查询Relationships表，获取用户当前操作对应的权限范围（如可访问的公司列表）。
• 将权限范围传递给业务逻辑，业务逻辑只需根据该范围过滤数据，无需直接关联权限表。

此方式分离了权限校验和业务逻辑，降低耦合度，适合微服务架构。

3. 数据库存储过程 #

将权限校验逻辑封装为存储过程，API通过调用存储过程执行数据操作，存储过程内部完成权限过滤和校验。但存储过程维护成本较高，且与TypeORM的集成灵活性不如ORM原生机制。

TypeORM的RLS相关支持 #

Aurora MySQL原生不支持RLS，TypeORM官方也未提供标准RLS插件，但可通过以下方式实现：

• 社区第三方库：部分社区库（如typeorm-rls）提供了RLS相关封装，但需注意库的维护状态和版本兼容性。
• 自定义实现：基于TypeORM的Repository扩展、生命周期钩子或拦截器，自行封装权限校验逻辑，这种方式更可控，能适配自身业务需求。

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