一个安全架构师需要做什么?有什么能力要求?

杭州或者北京的安全架构师,可以到p7及以上级别的工作内容包括如下:
1、负责平台数据安全相关核心功能研发,参与产品需求分析、业务讨论、设计工作,评估需求的技术可行性和技术难点; 
2、负责产品的技术框架选型,编写接口规范、编码规范等文档; 
3、负责系统架构设计、搭建、数据库设计、核心功能代码的编写; 
4、为开发人员提供快速有效的开发框架、服务、公用组件; 
5、负责项目开发过程中的技术攻关,和运行中出现的技术问题; 
6、负责对架构进行优化,持续改进性能、可扩展性、稳定性、安全性。 

岗位需要具备要求:
1、具备扎实的Java基础,深入了解http原理、socket通讯,熟悉主流开源框架,精通SpringBoot、SpringCloud、MyBatis、SOA、微服务、消息中间件; 
2、熟悉互联网平台架构、分布式、微服务架构,对大型分布式、高并发、高负载、高可用性系统设计有一定的了解; 
3、负责设定业务边界,业务模块间的交互及API的定义、接口规范;以及核心功能的设计与编码工作; 
4、对面向对象有深刻的理解、熟悉常用设计模式; 
5、精通MySQL、Redis、Mongodb、HBase等数据库设计、性能优化、存储优化; 
6、掌握架构设计方法,独立负责过云平台系统架构设计; 
7、对数据清洗、处理、数仓建设有经验者优先,有 Flink、 Hive、 Spark、 Kafka、 Hbase 等大数据技术经验; 
8、对数据中台建设、数据安全、可信计算等方向有经验。
 

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
网络安全架构:安全架构公理全文共9页,当前为第1页。网络安全架构:安全架构公理全文共9页,当前为第1页。网络安全架构:安全架构公理 网络安全架构:安全架构公理全文共9页,当前为第1页。 网络安全架构:安全架构公理全文共9页,当前为第1页。 导语 20条安全架构公理,是从安全学科的几十年安全架构实践经验中提炼出来的,是对永恒安全主题的升华,是对完美理想主义的陈述。无论数字技术和威胁如何发展演进,它们都是具有广泛适用性的永恒声明。它们也许不是完全可以实现的,但它们就像遥远的灯塔,可以指导业务和安全能力的开发活动的方向。20条公理是有序的,从业务性公理,到技术架构性公理,再到设计性公理。 安全架构公理 公理1:业务风险驱动安全 安全架构应通过最大化收益和最小化损失来支持业务目标。必须牢记的是,组织资产并不是为了被保护而存在,它们的存在是为了创造价值。而利用资产创造价值,通常意味着使该资产面临风险。这正是矛盾之处。为了提供最优架构,安全架构师不仅要从防止负面结果的角度来看待它们对组织的贡献,还要从促成积极结果的角度来看待它们。如果安全架构无法支撑组织利用其资产来完成业务工作,则该安全架构可能被边缘化和显得无用。安全架构应基于业务风险驱动,并且应该是对这些风险进行适当响应。 公理2:场景 不要虚构场景,否则后果自负。专为一种场景而设计安全系统或解决方案,并不总是可以有效地在另一种场景中工作。 网络安全架构:安全架构公理全文共9页,当前为第2页。网络安全架构:安全架构公理全文共9页,当前为第2页。这并不是反对重用,可重用的基于组件的架构有很多好处。但是,如果为了节省时间和精力,将安全系统重用于不同的用例,则需要针对这两个用例之间的差异,进行新的风险分析。 网络安全架构:安全架构公理全文共9页,当前为第2页。 网络安全架构:安全架构公理全文共9页,当前为第2页。 公理3:范围 明确定义安全架构的范围很重要。在这方面,系统收益(SOI)的概念很有用(如ISO/IEC/IEEE 42010:2011中所定义)。 公理4:情报 安全系统应利用情报来主导响应活动。通过威胁情报,既可以了解对手的意图、能力、攻击方式,也可以了解自身的漏洞情况。建议对潜在威胁场景进行建模分析,来实现最佳效果。可参考SABSA《企业安全架构》一书中描述的方法,如下图所示: 图1-SABSA威胁场景建模 公理5:信任 安全架构应该保障系统可以准确建模业务实体关系中存在的信任的性质、类网络安全架构:安全架构公理全文共9页,当前为第3页。网络安全架构:安全架构公理全文共9页,当前为第3页。型、级别、复杂性。信任是人际关系的特征。但我们可能要给非人员对象以信任。当这样时,其实是在说,我们可以信任操作这类对象的人员,或可被操作这类对象的人员所信任。因此,一个可信的系统是指我们信任参与系统生命周期过程的人员。信任从来都不是二进制,而是一个很长的灰度连续体,很少有黑色或白色。"信任"和"被信任"不是镜像关系。即使是最复杂的信任关系,也可以自顶向下分析成一系列简单的单向信任关系。通过严格执行此项分析,可以将任何业务关系分解为简单且独立的单向信任组件。 公理6:整体分析 网络安全架构:安全架构公理全文共9页,当前为第3页。 网络安全架构:安全架构公理全文共9页,当前为第3页。 安全需求应与其它的功能性需求和非功能性需求集成在一起。安全需求通常被描述为非功能需求(NFR),并且不应将其与其他功能需求或非功能需求分离。只有将所有需求都视为SOI(系统收益)整体风险的一部分时,安全架构才能有效工作。架构通常被视为不同视角的一系列观点。这些观点通常被称为架构域。例如:业务架构域、应用架构域、信息架构域、数据架构域、服务管理架构域、技术架构域。就像看一座被群峰环绕的山谷,远近高低的观点各不同。而安全架构域是从另一个视角来看的另一种观点,但与其它视角有很大不同,因为它是一个跨领域的域,必须以整体的方式解决所有其它域的安全和风险管理问题。因为风险无法分为孤立的架构域,所以安全架构师必须同时从所有视角看到山谷,即拥有可以随意旋转的全息视图。 公理7:简洁性 系统和服务应在保证功能性的前提下尽可能简洁。复杂是安全的敌人,必须在保持整体性的同时,将其简化为子结构进行管理。安全架构将会受益于面向服务的架构(SOA)方法,在这种方法中,我们看到了"一切即服务"(EaaS)。 网络安全架构:安全架构公理全文共9页,当前为第4页。网络安全架构:安全架构公理全文共9页,当前为第4页。服务的性能对于实现顶级业务绩效目标至关重要。任何架构类型的主要目标之一就是管理复杂性。必须通过自上而下的分解来分解高度复杂的SOI(系统收益),从最高级别的业务目标开始,并创建逐渐简化的SOI层次,并对其逐层解决。高度复杂的系统,倾向

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值