最近的工作中，技术的成长上极为有限，在流程上却大开眼界。第一次见识到了如何通过流程去弥补技术上的不确定性。也算是从纸上谈兵见到实际操作（架构设计中技术方案也需要通过流程确保后续运营，只是没有见过完全依赖流程的情况）。虽然这些极为臃肿的流程实现了对技术上的保障，但却耗费了更多的人力，时间成本，尽管这个成本可能比技术方案更为廉价（100w的工具vs100w的人力成本在2-3年内的持续投入），但在日常运营过程中，其流程几乎完全无法自动化，也无法实现快速修正错误。所以并不值得学习（仁者见仁，智者见智吧）。这种情况的出现个人理解主要因为金融行业的技术落后性，以及传统企业的工作氛围和利益关系所致。在这种缺乏技术支撑业务的工作过程中，我一度对技术，以及对自己产生了怀疑（常常听到：又不是不能用！过去也好好的！以现有流程为准！为什么要接XXX！你有台账吗？不要拿互联网那一套来金融行业），如今从这种情绪阴霾中走出来，用老板的话说就是：“学吧，学无止境！”
在意识到孰之过也，非吾之过后。我开始思考金融行业到底能不能迁移应用互联网行业的技术，安全架构设计的原则及边界到底在何处，嘴里口口声声说的为业务服务如何避免成为业务方的借口。与此同时恰因一个项目，在对接机构（包含发卡方和收单）的过程也见识到了各大机构的傲慢与官僚。虽然是管中窥豹，也值得总结一下。文中所指仅为传统金融行业（TradFi)的机构，非所谓的FinTech。
记得《图解CIO指南》里有一句描述CIO工作之一就是确保业务发展与技术相适应。考虑到金融行业的业务变化似乎经久未变，以及诸多原因。似乎并不会有人考虑以下的技术问题，但仍列于此（我自己答案已经删除，有是有否，也需要考虑适应性）：
接入的机构数量有限（总体数目也有限）时，是否不再需要DNS了？ 使用专线接入是不是就可以使用HTTP了，而无需使用HTTPS？ 什么时候需要进行硬件隔离？专线接入是机构运营的必要成本吗？ 专线接入就可以只用Firewall，不再使用WAF了吗？ 金融机构通过专线接入是不是就可以将IP硬编码在代码中？ 金融机构是否有必要建设私有云？ 金融机构是否能够使用公有云？对于金融行业公有云是不是一个不可逾越的鸿沟？ 金融机构通常使用form表单传递数据，是否有必要使用json或xml类进行数据传输？ 金融机构是否需要使系统具备API，有无必要使用REST API？ 针对Tokenization，有的使用随机数递增+1的机制（据说），有的使用对称加密，如何选择？ 金融机构开发主流为java，是否有必要尝试使用golang，nodejs，rust等？ 金融机构是否需要使用现代化的数据库（Mysql, Pg, NoSQL etc, but not DB2)？ 金融机构系统通常采用用户名密码及证书实现认证，使用cookie作为后续凭证，互联网多用JWT实现，是否有必要使用JWT作为凭证？ 金融机构系统/应用间的调用是否需要鉴权？ 金融机构存在大量以sftp文件传输是否可以通过https协议文件传输？ 机构密钥是否需要rotation？ 金融机构是否需要建设实时数仓？ 实时风控系统生效后，是否还需要准实时风控系统？ 金融机构大多是单体应用，是否需要微服务架构？ 金融机构是否需要CI/CD？ 金融机构是否需要使用容器化，以及K8S等技术？ 金融机构是否需要支持流量灰度的功能？
至此，我更加理解HW期间，机构系统是尽量要关闭的了。同时也产生了新的疑问：完善的流程真的能填补技术的缺陷吗？流程真的完善吗？臃肿复杂的流程对比技术实现哪个更好一些？大量的审批节点有人认真看了吗？实际上流程的制定者往往不是具备过实际执行经验的;机构负责对接的接口人往往也不是专业的,而且流程往往需要经过多层审批，甚至需要纸质用印。而技术侧运营多以厂商支持的模式进行，乃至常常出现的小故障都不具备自己运营的能力。
安全架构设计中的原则有很多，纵深防御、默认安全、零信任等等。但架构设计过程中的安全原则呢？作为安全架构师，需要学会如何组合安全原则也要及坚持设计原则。我读了几遍Security Principles for Architecture(C246)，感觉更像是给企业架构师（非安全架构师）写的，这样也比较符合TOGAF定位。但仍试着从笔记上总结一下，记录于此。（此处对原文进行了拆分，并重新组织了C246的内容。建议先阅读C246原文。）
目标(Vision)：通过安全设计使企业实现安全敏捷性 方法（Method）：设计时平衡生产力和安全防护 策略(Strategy)：合规驱动，风险管理，三方（3rd-Party)管理 过程（Approach)：验证安全元素、建立安全框架、深度设计、面向失败设计、验证安全设计，妥协设计， 简约设计，流程活动的自动化设计。
通过设计时对Production和Protection的平衡，以实现企业的安全敏捷，在这个过程中，整理了C246中一些比较值得关注的点：
架构必须周期性评估并适应最新的安全变化 安全设计及实施应该周期性的Review以识别是否违反了预期目的（最简单的，例如定期review防火墙策略，老洞新用） 安全设计应该评估是否出现了不必要的复杂设计 技术债必须明确识别并被纳入企业内现有风险管理流程（永远不要忘记技术债！） 系统和资产必须要有Owner，并且必须要认识到自己所Own系统的风险及技术债 系统必须要默认配置安全（这就是默认安全的体现） 系统必须明确保护，而不是简单伪装（例如，伪装22到2222） 系统应该被设计为安全，而非期望之后增加/实现安全 系统必须能够在不损害安全控制的情况下处理内部故障和其他系统间的故障 必须制定补救计划并去解决控制缺陷 在安全和生产力之间出现冲突时，选择业务优先 IT发展和安全必须相适应（这个同业务和IT相适应道理相同） 仅靠技术无法解决的人员和流程问题必须在设计之初识别出来 组织必须拥有足够的安全资源来支持开发团队，包括对他们进行培训，并协助架构、设计和测试 组织在有条件应引入第三方去提供额外的验证和测试 组织必须计划和准备预算以便在事故发生之前应对 组织必须考虑系统潜在的失败并记录下来 组织必须在可能的时候考虑自动化 开发团队和测试团队必须具备安全专业知识 测试用例必须包含安全测试用例 Compliance和Privacy的专业知识及需求必须要传递到开发团队 运营流程必须明确指出如何处理敏感数据 所有团队必须共享安全性、生产力等目标（the accountability structure must ensure that all team members share security , producitivity, and other goals， 好像微软也提了这个） 所有第三方解决方案（包含不限于IaaS, PaaS,SaaS)必须强制实施(Imposed)了安全控制 所有网络应被认为不可信，所有设备必须具备在不可信网络下维护安全策略的能力 采用以资产为中心(Asset-Centric, Asset Level)的安全防护而非仅依赖网络安全(Network-Based)措施 内部系统必须具备访问控制策略以验证访问请求 所谓隔离网络几乎是从未完全隔离，几乎不可能通过完全切断外部网络来阻止威胁 必须收拢攻击面以实现对资产的保护和控制 应该使用IPDRR去确保整个安全生命周期 所有的安全元素（产品，工具，流程，例如备份恢复流程等等）都必须经过验证测试，确保正常工作 结合行业框架及时更新企业内部的安全控制框架
这是重新组织过后的图
在这个过程中，我们依旧需要问自己：
如何避免过度设计？ 什么样算是平衡技术和成本？ 面对技术债务是否妥协？
架构设计需要安全原则，但是金融机构往往不需要原则中的安全，或者说唯一的安全原则就是符合监管，遵循流程。
使用专线，但同时使用HTTP协议进行通讯；以及在内网使用HTTP协议 使用SSO，但在URL里传递Ticket 使用证书进行验证，但不验证证书的有效期 使用证书进行加密，但是某证书仅具备验签功能标识 使用密钥，为保障密钥的安全性，必须要专人生成。但不避免单人持有所有密钥分量，并放在TXT文件里 约定对密钥的rotation，出于“稳定”考虑，销毁前都不会Rotation 约定对单个密钥销毁，加密机的密钥处于“稳定考虑”，不用也不会Destroy 使用商密算法进行HTTPS通讯，但是无法自动区分使用SM2或RSA的CipherSuite的流量 使用验证码保护文件下载，但是直接可以通过文件路径进行下载 使用Token进行鉴权，但是Token不刷新，新建Token后旧Token依旧生效 使用用户名密码进行验证身份，但是明文传输密码，并不是通过验证哈希实现 使用IP访问控制登录，登录后Session生效，但系统不再受IP访问白名单限制 使用XXX系统，但是XXX系统中生效策略为0
再次回答标题，金融行业需要安全架构设计的存在吗？主观的来说，迫切的需要。客观的来说，则似乎又远不可能。或许出于监管的需要，一定会有类似的职位存在，但是实际上的效果如何不置可否，而能做几分，只有心里知道了。如果安全是甲方里的乙方，那攻击队还有大放异彩的机会，运营如果能溯源取证，应急响应，也不会默默无闻。唯独架构，似乎可有可无。仿佛应了那句，做的好要你何用？做的不好要你何用？
最后的最后，以柏拉图的一首诗结尾，照照镜子。
如果尖锐的批评完全消失， 温和的批评将会变得刺耳。如果温和的批评也不被允许， 沉默将被认为居心叵测。如果沉默也不再允许， 赞扬不够卖力将是一种罪行。如果只允许一种声音存在， 那么， 唯一存在的那个声音就是谎言。——柏拉图
如有侵权请联系:admin#unsafe.sh