最近在给项目上的FICO顾问开HANA查询账号，又顺手把新建账号和授权设置完整走了一遍。SAP HANA里的账号创建看着就是一条CREATE USER的事，实际上坑全在授权这一层，很多人建完账号能连上，一执行查询就报insufficient privilege，然后开始怀疑人生。这篇文章我就把自己日常在HANA里新建账号、做授权设置的一套流程整理出来，分享给刚接触HANA的BASIS顾问、DBA，以及那些需要跟HANA数据库打交道又不想被权限折腾的FICO/ABAP开发同事。
这活儿本身不复杂，但涉及的东西很碎：账号类型、系统权限、对象权限、分析权限、角色封装，每一层都有讲究。尤其在S4 HANA项目里，FICO模块的底层表全在HANA库里，业务顾问要导数、做校验，开发要调存储过程，应用要连库读写，各类场景对授权的要求完全不一样。最简单的做法是直接甩一个ALL PRIVILEGES给所有人，但那等于在数据库层裸奔，等审计找你谈话的时候，肠子都能悔青。
1. 动手前必须先弄清楚的权限模型和账号类型
1.1 HANA用户账号到底有哪几种
HANA的账号体系和我最早接触的传统Oracle、MySQL不太一样。你打开HANA Studio的Security节点，能看到用户列表里有SYSTEM、技术用户、业务账号，偶尔还有一堆_ SYS开头的神秘用户。先说结论：_ SYS_REPO、_SYS_STATISTICS这类系统内部账号，是HANA自身运行和仓库管理用的，千万不能动，也别试图改成密码或删掉，否则整个系统都可能出问题。
真正需要我们操心的，是两类账号：普通用户（Standard User）和受限用户（Restricted User）。普通用户有完整的登录能力，可以访问目录（Catalog）、执行查询、创建自己的对象，是日常使用最多的类型。受限用户是后来版本里为了物联网、边缘计算这类轻量场景加的，它只能通过HTTP/SQL端点访问，而且不能拥有对象，不能创建会话，基本就是个“专用通道型”账号。咱们做企业应用，百分之九十九的情况选普通用户就行。
还有一点必须分清：HANA数据库用户，和SAP应用层（ECC、S4 HANA）里的用户，是两个完全不同的概念。S4 HANA的业务登录账号存在应用服务器里，数据库账号只是应用服务器连接HANA时用的底层身份。所以你经常看到SAP顾问说“权限在SU01里配”，那是应用层的权限；而HANA数据库账号的权限，是在数据库层单独配的。项目里如果分不清这两层，后面做FICO全套角色导入时，特别容易绕晕。
1.2 权限体系速览：系统权限、对象权限、分析权限、包权限
HANA数据库的授权体系可以用一个表先概括清楚：
| 权限类型 | 控制范围 | 典型操作 | 对应SQL关键字 |
|---|---|---|---|
| 系统权限 | 数据库级管理动作 | 创建用户、创建角色、备份恢复、查目录 | GRANT USER ADMIN, CATALOG READ |
| 对象权限 | Schema、表、视图、存储过程等对象 | 查表、读写数据、执行存储过程 | GRANT SELECT, INSERT, EXECUTE |
| 分析权限 | 分析视图、计算视图里的数据行级可见性 | 控制用户能看到哪些公司代码/成本中心的数据 | GRANT ANALYTIC PRIVILEGE |
| 包权限 | HANA repository里的开发包（Package） | 读取/写入/导出开发对象 | GRANT REPO.READ, REPO.EDIT |
这四个层级理解起来可以类比一栋大楼的门禁：系统权限是物业总钥匙，能开门、能管监控、能进设备间；对象权限是各房间门锁，财务室的门卡开不了机房；分析权限是房间里文件柜的抽屉权限，同一个财务室，有人能看全公司账，有人只能看自己公司代码；包权限则决定了你能不能往这栋楼的图纸上改结构。
很多刚接触HANA的人会犯一个错：以为给了某个Schema的SELECT，用户就能看这个Schema下所有视图了。实际上，如果视图引用了别的Schema的表，你还需要同时授权底层表的访问权限。这个在传统数据库里也有，但HANA的计算视图因为跨Schema建模很普遍，踩坑概率直线上升。
1.3 前置条件：用什么账号登录才能创建账号
创建用户和授权，本身就需要权限。通常我们用SYSTEM账号登录HANA Studio或hdbsql来操作，因为SYSTEM默认拥有USER ADMIN、ROLE ADMIN等关键系统权限。有些企业会禁掉SYSTEM，那至少需要一个拥有USER ADMIN和ROLE ADMIN系统权限的账号，才能执行CREATE USER和GRANT语句。
拿到登录账号后，建议先查一下自己有没有权限，免得写一堆SQL全是报错。在SQL控制台执行：
SELECT * FROM SYS.USER_SYSTEM_PRIVILEGES WHERE USER_NAME = CURRENT_USER;看到USER ADMIN、ROLE ADMIN、CATALOG READ这些字段为TRUE，就说明你有资格建账号和分配权限。另外提醒一句：HANA 2.0之后，密码策略默认要求大写字母、小写字母、数字、特殊字符都要有，至少8位，长度上限和复杂度可以通过密码策略配置调整。创建用户之前，先把密码准备好，不要等到CREATE USER报“password does not meet policy”再回来改。
1.4 明确授权需求：建这个账号是给谁用的
这是整个授权设置里最容易被忽略、却最关键的一步。我见过太多人上来就CREATE USER，然后随口问一句“你要啥权限”，对方说“给我全部吧”，就把ALL PRIVILEGES扔过去了。真要这么干，审计检查时直接就红了。
动手前先把场景理清楚：
- 应用连接账号：S4 HANA应用服务器连数据库用的，通常只需要连接权限、执行特定Schema过程的权限，不需要开发权限，更不能有USER ADMIN。
- FICO/开发顾问账号：顾问要查会计凭证表（BSEG、BKPF、ACDOCA）做数据核对，要给对应Schema的SELECT，偶尔需要EXECUTE存储过程，但没必要给INSERT/UPDATE/DELETE。
- 报表分析账号：给业务用户跑报表的，如果报表基于HANA分析视图，需要配分析权限，按公司代码、成本中心做行级过滤。
- 运维/开发账号：需要写代码、建表、传传输请求的，这类账号才考虑给SCHEMA的DDL权限、包权限。
想清楚这层，后面所有授权步骤就都围绕“够用就好”的原则展开，这也是我在S4项目里给FICO全套相关顾问开账号时坚持的标准做法。
2. 一步步新建HANA账号：三种常用方式实测
2.1 方式一：HANA Studio图形界面创建
HANA Studio虽然官方推广力度不如HANA Database Explorer，但老项目里依然大量使用。打开HANA Studio，切换到Administration透视图，依次展开Security -> Users，右键选择New User。
在General选项卡里，User Name填账号名，Authentication选Password，下面输入密码和确认密码。这里有个关键下拉框：Force password change，如果你希望用户第一次登录后必须改密码，就选YES；如果是给应用用的技术账号，选NO，不然应用连不上还得你手动去改。
接下来是其他选项卡：
- System Privileges：勾选这个用户需要的系统权限，比如CATALOG READ。
- Object Privileges：点绿色加号，选择Schema或具体的表/视图，再勾选SELECT/INSERT/UPDATE/DELETE/EXECUTE等。
- Analytic Privileges：添加已有的分析权限对象。
- Package Privileges：选择Repository里的包，分配开发权限。
- 下方的Validity：可以设置账号有效期，比如只开3个月的临时账号，过期自动失效，这个对项目上短期借调的外部顾问特别实用。
全部设置完后点Deploy，用户就建好了。这个方式肉眼所见即所得，适合不想记SQL的人。但要批量创建或者要写自动化脚本时，图形界面效率就太低了。
2.2 方式二：HANA Database Explorer（HDB）快速操作
现在很多新项目直接走HANA Database Explorer，也就是网页版的SQL开发工具。在HDB里，左侧SQL Console连接目标数据库，然后在SQL命令窗口里写SQL创建用户，或者通过Security菜单创建用户。HDB比传统Studio更轻量，我用下来最舒服的一点是它自带了权限检查视图，可以直接查当前用户有没有某权限，不用记一堆系统视图名。
如果你是刚接触HANA的新手，建议直接用HDB。打开HANA实例后，用SYSTEM账号登录，在SQL控制台执行创建命令，右侧结果区可以直接看到执行成功与否，比Studio的Deploy机制直观。后面文章里的SQL示例，我都默认在HDB里跑。
2.3 方式三：HDBSQL命令行创建
DBA或运维同事通常离不开命令行，特别是要批量处理几十个账号时，写个shell脚本比手动点半天快得多。HDBSQL连接命令的通用写法：
hdbsql -n 10.10.1.20:30015 -u SYSTEM -p '你的密码' -d SYSTEMDB连接进去之后，创建用户的SQL很直观：
CREATE USER FICO_READER PASSWORD "Init_2025!" NO FORCE_FIRST_PASSWORD_CHANGE;这条语句创建了一个名为FICO_READER的普通用户，密码是Init_2025!，不强制首次登录修改密码（应用账号必须这么设）。如果你希望用户第一次登录就改密码，把NO FORCE_FIRST_PASSWORD_CHANGE换成FORCE_FIRST_PASSWORD_CHANGE。
建好之后先验证一下：
SELECT USER_NAME, CREATE_TIME FROM SYS.USERS WHERE USER_NAME = 'FICO_READER';能看到记录说明创建成功。此时你尝试用这个账号登录，会发现能建立连接，但查不了任何业务表，因为还没有任何授权。这就到了下一节的重点：授权设置才是重头戏。
2.4 删除、锁定与解锁账号的日常操作
账号建得多，自然有清理的一天。临时项目结束、外包顾问离场、应用下线，都涉及账号回收。删除用户用DROP USER，但建议先停用观察一段时间，防止有后台任务还在依赖这个账号。
锁定账号：
ALTER USER FICO_READER DEACTIVATE USER NOW;解锁恢复：
ALTER USER FICO_READER ACTIVATE USER NOW;真正确认不需要了再删除：
DROP USER FICO_READER;这个顺序是我踩过坑之后的习惯操作。我之前直接DROP了一个还在被后台调度任务使用的账号，导致当晚批量作业大面积失败，半夜被电话叫醒。所以现在一律先DEACTIVATE，观察至少一个完整业务周期，确认没有报错和告警，再DROP。另外，删除账号之前，最好先查一下它拥有的对象（表、视图、存储过程），如果账号名下创建了对象，DROP USER会连带处理，产生的影响可能比你想象的大。
3. 授权设置的完整实操：从零到能查表
3.1 最小可用授权：建一个能连接、能查Schema表的账号
还是拿FICO_READER这个账号举例。目标是让它能连接数据库，并且只查SAPFICO这个Schema下的会计凭证相关表。假设应用层的角色已经配好了，但数据库层必须先给它打开通道。
首先，默认情况下任何新建的普通用户会自动获得PUBLIC角色，这是HANA内建的公共角色，只包含最基础的连接权限，相当于“允许进门”。所以这时候FICO_READER已经能连上数据库，但看不到任何业务数据。
接下来要补两类授权：一是系统层面的CATALOG READ，允许这个账号查看目录信息；二是对象层面的Schema查询权限。SQL如下：
GRANT CATALOG READ TO FICO_READER; GRANT SELECT ON SCHEMA SAPFICO TO FICO_READER;执行完这两条，用FICO_READER登录，执行：
SELECT TOP 100 * FROM SAPFICO.BSEG;这里BSEG是会计凭证行项目表，FICO顾问最常查的表之一。能出数据，说明最小链路已经通了。这个组合我用在最常见的顾问取数场景上，既满足查数需求，又不至于给太多权限。
3.2 常用系统权限明细与授权写法
系统权限是控制数据库级操作能力的，给的时候务必克制。我把平时最常用的几个列出来：
| 系统权限 | 作用 | 说明 |
|---|---|---|
| CATALOG READ | 读取目录对象 | 查询表结构、视图定义，顾问查数常用 |
| USER ADMIN | 创建和管理用户 | 只有DBA或权限管理员才该有 |
| ROLE ADMIN | 创建和管理角色 | 和USER ADMIN配套出现 |
| DATA ADMIN | 管理数据 | 带这个权限基本等于数据层“半个管理员” |
| BACKUP ADMIN | 管理备份 | 一般仅DBA |
| MONITORING | 查看监控信息 | 运维同事用的 |
| EXECUTE | 执行存储过程 | 但实际上过程执行权限也可以走对象授权 |
授权的标准写法：
GRANT CATALOG READ TO FICO_READER; GRANT MONITORING TO DBA_MONITOR_USER;回收系统权限：
REVOKE CATALOG READ FROM FICO_READER;每次执行完GRANT之后，如果用户已经连接，通常不需要重启数据库，但已建立的会话可能不会立刻感知到新权限。遇到权限改了但行为没变的情况，让用户重新登录一下会话就好。
3.3 对象权限：从Schema级到表、视图、存储过程
对象权限的粒度可以粗也可以细。最粗的是Schema级别授权，一条命令管整个Schema的所有表；最细的是单表单视图级别。
如果FICO_READER只需要读SAPFICO下的部分表，更严谨的做法是逐个授权：
GRANT SELECT ON SAPFICO.BSEG TO FICO_READER; GRANT SELECT ON SAPFICO.BKPF TO FICO_READER; GRANT SELECT ON SAPFICO.ACDOCA TO FICO_READER;如果场景允许顾问看整个Schema的表结构，再考虑Schema级授权。这里有个重要细节：Schema-Specific权限中，如果给用户SELECT ON SCHEMA SAPFICO，用户能看到该Schema下所有表，但只能查自己有权限的表。换句话说，Schema级SELECT授权意味着新增表后，用户自动获得新表的查询权。这在项目初期很方便，但也意味着风险，业务顾问可能无意间查到敏感字段，比如薪资。所以我的原则是：能明细到表就不偷懒用Schema一把梭。
存储过程的执行权限单独授：
GRANT EXECUTE ON SAPFICO.Z_GET_OPEN_ITEM TO FICO_READER;写入权限同理：
GRANT INSERT, UPDATE, DELETE ON SAPFICO.TMP_DATA TO FICO_READER;这类写权限，给临时表、接口表还好，给核心日志表就要谨慎评估了。数据的最终一致性是生命线，别因为权限给了写，导致业务数据乱套。
3.4 HANA特有：分析权限到底怎么配
分析权限（Analytic Privileges）是HANA里比较独特的设计，它解决的是行级数据可见性问题。比如FICO顾问说“我要查ACDOCA表”，但公司规定：上海的财务顾问只能看“1000公司代码”的数据，其他公司代码的数据一概不能看。如果只靠表级SELECT授权，做不到这种过滤；分析权限就是专门干这个的。
创建分析权限的路径：在HANA Studio/HDB的Content区，找到你想要放置权限的包（Package），右键New -> Analytic Privilege。给权限起个名字，比如AP_FICO_1000，然后在Business Object里选择一个分析视图或计算视图，在Where Used标签页配置过滤条件。
比如ACDOCA视图里有一个关键字段RCOMP（公司代码），在分析权限里配置：
RCOMP = '1000'保存、激活这个分析权限，再把它授予用户：
GRANT ANALYTIC PRIVILEGE AP_FICO_1000 TO FICO_READER;分析权限是HANA的“行级安全门禁”，报表跑出来的数据，只显示你权限内的公司代码。我后来在S4 HANA FICO项目里给十几个财务顾问开报表账号，就是靠分析权限实现了“不同公司代码各看各的数”，避免了给每个人单独建视图的麻烦。这也是搜索热词里那个“intouch授权路径设置步骤”思路的一个数据库层落地参考：先梳理清楚数据权限路径，再在HANA里通过分析权限对象去落地。
3.5 包权限：开发人员传Repository对象时用到
如果账号是给HANA开发人员用的，他们需要直接创建或修改Repository包里的计算视图、存储过程等开发对象。这个时候就需要包权限。
比如给开发账号授权某个包下所有操作权限：
GRANT REPO.READ, REPO.EDIT, REPO.ACTIVATE ON PACKAGE "FICO_REPORTS" TO HANA_DEV;包权限和前面的对象权限互相独立，别以为给了SELECT ON SCHEMA就自动能改Repository里的视图。HANA的Repository是独立于Catalog的一套对象体系，很多从传统数据库转过来的开发会在这里卡住：明明表都能看到，但计算视图就是打不开，因为没配包权限。
4. 更规范的做法：把授权做进角色（Role）里
4.1 为什么不建议直接给用户授权
环境里如果只有三五个用户，直接对用户授权问题不大。但企业环境里用户数量动辄几十上百，今天给这个授权，明天给那个回收，信息全在管理员脑子里，时间一长完全失控。
角色的逻辑思维上特别像“岗位说明书”。你先定义好“FICO报表查询顾问”这个岗位需要哪些权限，把它做进一个角色；然后谁担任这个岗位，就把角色赋予谁。员工离职了，把角色收回换给新人就行。权限定义只改一处，所有使用该角色的用户同步更新，这才是可持续的管理方式。
另外，SAP HANA的权限有一个特性：用户的有效权限 = 直接授予的权限 + 所有角色带来的权限。如果你通过角色管理权限，审计时可以按角色梳理授权路径；如果直接授权，审计时只能一个用户一个用户查，工作量成倍增加。
4.2 创建角色并授权的标准SQL
创建角色：
CREATE ROLE FICO_REPORT_ROLE;给角色授权：
GRANT SELECT ON SCHEMA SAPFICO TO FICO_REPORT_ROLE; GRANT ANALYTIC PRIVILEGE AP_FICO_1000 TO FICO_REPORT_ROLE; GRANT CATALOG READ TO FICO_REPORT_ROLE;角色创建和授权，需要当前用户有ROLE ADMIN权限。
然后把这个角色赋予FICO_READER用户：
GRANT FICO_REPORT_ROLE TO FICO_READER;用户在角色里的权限变更会自动生效（精确说，用户下一次会话刷新后生效），不需要每个用户单独维护。如果某天你想让这个角色下的所有人都不能再查ACDOCA表，只需要：
REVOKE SELECT ON SAPFICO.ACDOCA FROM FICO_REPORT_ROLE;一次性搞定，这就是角色的意义。
4.3 结合S4 HANA FICO的权限应用案例
说一个我实际做过几次的场景。S4 HANA项目刚上线，FICO模块顾问陆续进场，他们需要核对差异，频繁查表。几个人在群里喊：“帮我开个账号，我要能查BSEG、BKPF、ACDOCA，还要能执行几个标准函数。”如果按最简单的做法，直接给每个人授权，后面肯定乱。
我是这么处理的：
第一步，先梳理出FICO顾问需要访问的全部对象清单。以S4 HANA 2025环境为例，通常包括：
- SAPFICO.Schema下的BKPF（凭证抬头）、BSEG（凭证行项目）、ACDOCA（通用日记账）
- 一些自定义函数Z_*
- 标准视图V_GL_ACCOUNT等
第二步，建一个角色FICO_QUERY_ALL：
CREATE ROLE FICO_QUERY_ALL; GRANT SELECT ON SAPFICO.BKPF TO FICO_QUERY_ALL; GRANT SELECT ON SAPFICO.BSEG TO FICO_QUERY_ALL; GRANT SELECT ON SAPFICO.ACDOCA TO FICO_QUERY_ALL; GRANT EXECUTE ON SCHEMA SAPFICO TO FICO_QUERY_ALL;第三步，再建一个受限查询角色，只给部分公司代码分析权限：
CREATE ROLE FICO_QUERY_1000; GRANT SELECT ON SAPFICO.BKPF TO FICO_QUERY_1000; GRANT SELECT ON SAPFICO.BSEG TO FICO_QUERY_1000; GRANT ANALYTIC PRIVILEGE AP_FICO_1000 TO FICO_QUERY_1000;然后给不同顾问授予不同角色：
GRANT FICO_QUERY_ALL TO FIN_AUDITOR; GRANT FICO_QUERY_1000 TO FIN_CONSULTANT_01;这样整个授权路径就非常清晰：用户 -> 角色 -> 权限对象。后面谁要加表，改角色；谁离职，收用户上的角色。这套方法放在大项目里尤其管用，也方便交接给下一位管理员。
4.4 授权变更后为什么经常“不生效”
这是一个高频问题。明明REVOKE了某个权限，用户也确认重新登录了，结果还能查到数据。先别急着怀疑HANA出bug，大概率是下面几个原因：
一是连接池缓存。应用服务器连接HANA通常用连接池，账号权限变更后，连接池里的旧连接还在用旧权限上下文。让应用侧重启连接池，或者干脆重启应用实例，才能强制刷新。
二是有角色叠加。用户可能同时有几个角色，一个角色里收回了权限，另一个角色里还保留着。查用户有效权限时，要把所有角色加上直接授权综合看：
SELECT * FROM SYS.EFFECTIVE_PRIVILEGES WHERE USER_NAME = 'FIN_CONSULTANT_01';这条SQL列出的是用户真正拥有的全部有效权限，排查问题先跑它。
三是分析权限缓存。计算视图和分析权限之间有缓存机制，激活新的分析权限后，旧会话可能还停留在旧数据权限里，需要让用户重新建立会话。
5. 运维中常见的坑与排查技巧
5.1 常见报错速查表
| 报错信息 | 含义 | 处理方式 |
|---|---|---|
| insufficient privilege: Not authorized | 缺少对象或系统权限 | 查EFFECTIVE_PRIVILEGES，定位缺失授权 |
| could not open connection: invalid user or password | 用户或密码不对 | 核对账号名、密码策略，确认账号未被锁定 |
| user is deactivated | 账号被停用 | ALTER USER ... ACTIVATE USER NOW |
| no SELECT privilege on view | 视图底层表权限不足 | 给底层Schema或表补SELECT |
| analytic privilege not found | 分析权限不存在 | 确认分析权限对象已激活 |
| password does not meet policy | 密码不符合复杂度策略 | 改成大写+小写+数字+特殊字符组合 |
这些报错里，“insufficient privilege”出现频率最高。遇到就先跑：
SELECT * FROM SYS.EFFECTIVE_PRIVILEGES WHERE USER_NAME = '登录账号';看一下这个账号到底缺了什么。别凭感觉瞎猜，数据说话。
5.2 我踩过的几个坑
第一个坑是用SYSTEM账号建完用户，随手就把USER ADMIN授给了业务账号，想着以后让业务自己管账号。后来发现这个账号能创建用户，还能给用户授权，等于把整栋楼的钥匙给了租户。审计发现问题后，处理起来非常麻烦。现在我的原则是：USER ADMIN、ROLE ADMIN这类系统权限，只给DBA和权限管理员，业务账号一个都不给。
第二个坑是分析权限激活了，结果用户始终看不到数据。折腾了半天，发现计算视图本身还有一层“数据权限检查”机制，需要在视图属性里选择“分析权限”作为数据过滤方式，光建分析权限、授权，视图没启用权限检查，等于白干。创建计算视图时，在View Properties里有一个Analytic Privilege设置项，需要选择Enabled，并绑定对应的权限对象。
第三个坑是PUBLIC角色动不得。有次为了省事，想直接往PUBLIC角色里加一个查询权限，让所有人都能查某张基础表。日志一查，PUBLIC角色被改，等于所有用户权限都被变了，影响面不可控。幸好发现得早，及时REVOKE了。PUBLIC角色里任何权限变更，都是全局性的，动之前一定三思。
第四个坑是账号密码有效期。给外部顾问开账号时设了有效期3个月，到期后账号自动失效，顾问正干着活突然连不上，来问怎么回事。后来我养成了习惯：建临时账号时在备注里写清楚到期时间，到期前一周提醒业务方续期或者清理。
5.3 权限审计与日常检查
企业上线后，数据库权限审计是常态。我一般每季度做一次权限盘点，核心就几条SQL：
列出所有用户：
SELECT USER_NAME, CREATE_TIME FROM SYS.USERS WHERE USER_NAME NOT LIKE '_SYS%' AND USER_NAME != 'SYSTEM';列出每个用户的系统权限：
SELECT GRANTEE, PRIVILEGE FROM SYS.GRANTED_PRIVILEGES WHERE GRANTEE = 'FIN_CONSULTANT_01' AND IS_GRANTABLE = 'FALSE';列出某个角色下所有权限：
SELECT * FROM SYS.ROLE_PRIVILEGES WHERE ROLE_NAME = 'FICO_QUERY_ALL';我还会导出一份完整清单，检查是否有账号超过180天未登录：
SELECT USER_NAME, LAST_SUCCESSFUL_CONNECT FROM SYS.USERS WHERE LAST_SUCCESSFUL_CONNECT < ADD_DAYS(CURRENT_DATE, -180);长期不用的账号，要么锁定，要么删除。项目上每半年至少能清出一批过期账号，都是当初各种原因建的，后来人走了账号留下。清理的时候记得走工单流程，留好记录，这也是审计时最有力的凭证。
最后再分享一点我自己的习惯
权限管理这件事，工具和SQL都只是手段，真正考验人的是“路径思维”。我在每一次开账号之前，都会先画一遍授权路径：这个账号是谁在用，它需要访问哪些对象，这些对象在哪个Schema，涉及哪些视图和底层表，有没有行级过滤需求，应该做成角色还是直接授权。这个过程可能只花十分钟，但能在后面避免无数个“为什么查不到数据”的求助电话。
有一次在S4项目里配置FICO全套功能时，几十个顾问各要各的权限，我靠的就是先把通用权限整理成几个标准角色，再按需求做微调，整个配置工作在一个下午就完成了，后续几乎没有权限类的工单。这比我早期一个个用户单独授权的效率高了一个量级。
另外，每个新账号创建之后，我都会在HANA的扩展备注里写清楚这个账号的用途、负责人、创建日期、有效期。这些信息在审计和交接时价值巨大，尤其项目干到后期，人员流动性大，没有备注的僵尸账号最让人头疼。权限设置从来不是建完就完事，它是一个持续维护的过程，把基础打扎实了，后面才能少折腾。
