单点登陆(Single Sign on)现在已经很普遍了,比如Google,一次登录之后可以直接访问Gmail、Calendar、Docs、Youtube、Keep等所有产品。在互联网公司内网,SSO应该都是必备设施,一次登录后可以访问ERP、Wiki、Ticket、代码、服务器资源等所有系统。如果你们公司没有——我觉得你需要跳槽来培养一些品味。
以上我们都还说的是比较成熟的Web SSO,但是我非常惊奇的是,很多一线大公司竟然都还没有实现命令行下的SSO以及依赖于此的资源访问控制(access control)。在这里你经常会遇到什么事情呢——
有一些Linux服务器,它们的维护方式是SSH上去做操作,用户名、密码是靠少数几个人保管着,严谨的人靠脑子记、靠口口相传,不严谨的人写在便签纸上贴在电脑上、写在wiki里、毫不在意地发在100人的微信群里——随处可见的明文密码。
有一些没有ACL的存储里保存着各种孤本数据,谁都可读可写。有一天猪队友手一抖全给删了,如果不是他自觉承认,其实根本查不出是哪头猪。
聪明的人出现了,他们又做了一套独立于公司体系之外的权限管理系统,强大无比,升职加薪。
但你觉得这套“自主研发”的权限系统其实很蠢,而公司里竟然有很多套类似的系统,你自己就有很多个用户名、密码,用以访问不同的资源。
所以每当有人说要做一个权限管理系统,我都想问:这是用户的需求还是升职的需求?是升职完就废弃或者甩锅给别人、还是承诺维护五年以上?我们工程师圈子始终有一个怪现象,那些善于不停挖坑弃坑的人,只需要0.2的effort就拿走0.8的credit;后面的人再兢兢业业、干到死也就是0.2的credit。我钦佩前者创新和讲故事的能力,但其中只有少数是出自对未来技术走向的洞察,多数是重复造轮子、面向升职编程。
说得有点远了,回到我们的话题。如何设计一个统一的Terminal SSO呢?其实也并不复杂,跟Web SSO是一样的:
第一步是身份验证,获得员工在公司的唯一标识,一般就是邮箱前缀吧。
第二步是访问控制,所有工具链都应该比对身份与权限,得出结论“用户A以身份X执行了操作”,并且写入log。
身份验证有比较成熟的方案,例如RSA。可以参考常见的Git仓库权限管理,用户登录Web SSO,上传一份本机的公钥。
访问控制其实就是简单的树状用户组。例如一个学校的校友会组织形式:
小王属于“三年二班”用户组,“三年二班”属于“三年”用户组,“三年”属于“A校”用户组。
小王以“小王”的身份访问了自己的成绩档案;
小王以“三年二班”的身份访问了三年二班班聚照片;
小王以“三年”的身份访问了三年校友通讯录;
小王收到了A校校友办公室发给“A校”的校庆通知。
我们一般也会在每一层都有一些具有更高管理权限的组别,比如:
小刘属于“三年二班班委”,可以加人、踢人等;
同时小刘作为班长,属于“三年管委会”,可以跟其他班长一起在年级级别发一些公告等;
同时小刘还德高望重,被选为“A校校友会理事”,可以在更高级别做出一些操作。
总之每一个操作,都是“A以B的身份做出操作C”,我们只对A进行身份验证,并鉴定他是否可以具有B的身份。而不是A记住了一堆密码,以B的身份登录进系统去做操作,因为这样我们只能记录到“B做出操作C”,而且B的密码很容易泄漏到更广范围。
行之有年的“公共邮箱”,就是这样一个脆弱的“私密”环境。
行之有年的上百人的“X校校友微信群”,就是这样一个经常混入神秘陌生人但又无法甄别的“可信”朋友圈。
而如果一个代表科技巅峰的无人车大公司内部研发环境也是如此,我很难相信他们的Infra可以支撑起100台车的管理。
领取专属 10元无门槛券
私享最新 技术干货