谁拥有安全?[关闭]

让我们面对现实吧,如果安全不是每个人都拥有的,那么它就不会被任何人拥有。(我相信 Ricky Bobby 先这么说)。

top ten security vulnerabilities ,不这样做是不可原谅的。因为一旦你“明白”了就很容易了。

快速示例:

1. 打开SSL/TLS来保护它 这是用户界面的责任 你在问题中提到的层。
2. 在 web服务器和您的业务服务 商业服务层的人。
3. 在 业务服务层和数据 层。数据层的人必须这么做 那。
4. 在数据库中代理或使用密钥。 Here's 这必须由DBA完成。
5. 所有这些都需要

所以你看,它必须在整个团队中完成,因此必须是一个文化主题,而不仅仅是另一个要检查的框。

我必须同意每个人的观点,即安全必须是每个人共同关心的设计/实现问题,而且必须跨越所有层。我在一家非常大的公司工作,从事非常大的内部web应用程序,在那里,每个使用该系统的人都是受信任的人,安全性仍然是首要考虑的问题。

下面是如何从层的角度在我的web应用程序上分解的。当一个请求被发送到web应用程序时,在子域级别上存在公司范围的安全性,只有 only allows SSL (HTTPS) communication 到服务器。还有另一个服务器(network appliance)截取对应用程序的请求并处理 logging people into the application (身份验证)基于用户名和密码以及它们要访问的URL。

determine what actions the user can do in the system . 在业务服务层中,我们实现了业务安全逻辑(使用 AOP )过滤掉某些用户不允许看到的数据(例如他/她自己的信息)。这将允许过滤在一个地方完成,即使它是由来自UI的不同地方调用的。

在数据访问层或SQL中,公司只允许 stored procedures DBA 是唯一有权对数据库模式进行更改的人),而且没有一个开发人员可以偷偷地使用糟糕的SQL。为了访问数据库,我们使用一个特殊的用户ID和一个在配置文件中加密的密码(公司策略和 FedRAMP requirement ).

当数据返回屏幕显示时,我们偶尔添加 custom hash

安全性应该是公司的部分标准和特定于部分应用程序的部分标准。如果你的公司有 architect ,他/她将帮助您定义在不同用例中需要安全性的位置,以及在哪些位置需要重写基础结构/公司提供的默认安全性。当涉及到实际的代码时,开发人员通常会找出如何在特定流中实现安全性,并找到需要由架构师标识的安全性的流。在对应用程序进行编码和设置之后(最好在 staging or integration environment )你需要 someone test 应用程序,以确保它按预期运行,并且没有 security flaws .

如果这能回答你的问题请告诉我。。。

要求 . 只有当您有一个指定的安全需求/策略时,您才能实现和测试它。

是否是 数据库 里面 数据库是可能的,但往往是昂贵的,我的意思是:

• 如果必须加密数据/连接,则会产生间接费用

但是 一个选项(尽管它通常是为最安全的关键应用程序保留的,即使是DBA也不允许读取数据);除此之外。。。安全在很大程度上是一个贯穿各领域的问题。你一定会的 特定于UI层的安全实现(因为它正在处理cookies等),但是大部分工作 倾向于

应用程序的设计需要考虑到安全性,而且需要以安全的方式进行开发。最初的责任是由系统架构师设计规范,然后由开发人员正确地实现规范(由架构师监督),最后web服务器必须由系统管理员和/或基础设施保护。最大的问题是,中间层的开发人员常常假设他们从系统中的其他组件获得的所有信息都经过了验证,但事实并非如此,这可能会导致一些难以追踪的安全漏洞。因此,每一层都必须作为自己的安全沙箱来开发,以防止数据泄漏。