将安全问题推迟到应用程序开发周期的末尾是一种好方法吗?

本文关键字:一种 方法 推迟 问题 安全 迟到 应用程序 开发周期 | 更新日期: 2023-09-27 18:04:25

由于我们要为其他应用程序开发一些公共API以与之集成,有人建议我们应该延迟安全性工作,直到API的方法完成,这样第三方应用程序就可以使用了!这是解决问题的好方法吗?或者我们应该把安全性放在适当的位置,然后再开发API本身?

编辑:

这里的问题是成本。假设您一开始就拥有了它,我认为您不必因为安全问题而重新访问api来进行更改,特别是对于由另一个团队维护的第三方应用程序。如果我们把它推迟到所有的事情都完成并集成,那么其他团队也必须修改和更改代码。

那么根据你的经验,什么成本更低?

将安全问题推迟到应用程序开发周期的末尾是一种好方法吗?

您应该从一开始就完成设计,包括安全性。稍后更改设计将花费更多。实现一开始可能会延迟或不完整。

如果你不知道访问权限的粒度,你将不得不做大量的重新设计,当你后来发现它必须超越表访问或超越SIDU,实际上工作在行级别。

放入虚拟函数并计算出如何在之后实现真正的东西的细节或多或少是免费的,但要做到这一点,您首先需要知道客户需要什么并为此进行计划!

这取决于…

  • 与API的安全性相关的总体风险。你说的是银行、生死还是猫的照片?风险越大,我就越想提前解决这个问题。
  • 团队的总体技能和经验水平。经验丰富的人不太可能把自己逼到墙角。
  • 具有保护API的相关经验。如果这是每个人第一次尝试,我至少会提前做详细的计划。
在可能的情况下,我完全赞成在安全、安全身份验证、acl等问题上进行讨论。但不要只是说,"让我们以后再做吧",而没有很好地处理这个决定可能带来的风险。如果您必须比计划更快地开始实施安全问题,那么这些讨论很可能会产生一个可行的前进路径。

安全性是一个横切关注点,这意味着它渗透(并且应该)到体系结构的每个级别。为什么不使用Basic Auth并与第三方应用程序开发人员共享密钥呢?

安全性必须始终受到关注。如果您的api是完美无缺的,您的安全系统是有缺陷的,那么这将无助于延迟。