一位非技术、安全偏执的工作人员坚持认为,确保我们网站安全的有效方法是将应用程序分为三个部分:前端、API和后台管理区域,供员工使用。
API和管理系统都在域名上,这些域名只是一组随机字符。
应用程序保存敏感数据,但是,所有应用程序都位于同一台服务器上。
我面临的问题是,在应用程序处于这种状态时,调试或添加特性会使工作非常困难,因为不清楚应用程序的哪一部分做什么。(这里没有文档,之前的开发人员已经离开了公司。)
他坚持认为,未来的项目应该遵循相同的套件,有自己独立的API和管理区域,我认为对于一个相对简单的应用程序来说,这是不必要的。
第二个问题是,我知道通过默默无闻的安全性并不一定是安全的,而且我也不认为使用一个复杂的域来主持某个部分,或者整个网站都是安全的。
所以我的问题是:
1)使用这样的API是否会带来安全方面的好处?是否有其他方法可以确保应用程序和它的数据是安全的,这样它就不会影响开发速度。
( 2)是否需要使用模糊域来确保应用程序的安全?再一次,是否有其他的方法可以同样有效,而对未来的开发人员来说就不那么奇怪了?
3)管理系统使用用户名和密码进行安全保护。让管理系统在website.com/admin上安全,而不是在randomcharacters.com上安全吗?
发布于 2017-06-13 09:28:04
API应该由身份验证机制(如OAuth访问令牌(AuthN) )来保护。然后,谁能在该API上做什么,应该由访问令牌(AuthZ)中的声明来确定。应该在这些术语中考虑身份验证和授权。
‘我是这位校长,我可以证明这一点,因为我有你发给我的记号,你可以核实只有你才能发,我有一些信息,你可以用它来决定我可以做什么’
不,使用晦涩的域名不能提供任何级别的安全性。它们只是由DNS条目转换成IP地址的字母--为了使用My-WebAddress.com或hdsfiuycxzuyecgfr.com,您必须将其传递给某个人,并且在这一点上他们同样安全!
要问的问题是,谁是系统不同部分的用户,谁应该访问什么?前端应用程序是否在互联网上公开可见,并可供各种客户端使用?管理系统是否属于同一类别,还是更多地属于内部工具?标识组件的用例,并考虑是否通过应用程序逻辑(如OAuth令牌)或基础设施限制(例如,只有位于特定IP地址范围/子网内的计算机才能访问管理工具)来保护它们。它通常是应用程序和基础设施安全的结合,提供了最好的保护级别。
将前端应用程序和管理工具作为不同的应用程序托管可能允许您在它们周围应用不同的安全边界,这可能很有用。
然而,这是一个确定谁是你的威胁演员和设计相应的问题。
发布于 2017-06-13 08:23:52
一个不知名的域名只需要在某个地方泄露一次;一旦攻击者得知该域名,它就不再是晦涩难懂的,也不会带来任何好处。如果你有一个公共网站对“模糊”后端进行API调用,那么这个域名已经被很好的宣传了。
不,为了安全起见,使用一个模糊的名称几乎是没有意义的。如果您的API不安全并且允许未经授权的访问,这是您的安全弱点,而不是域名可能被知道的事实。
https://stackoverflow.com/questions/44515935
复制相似问题