我一直在使用以下方法开发多层应用程序：
安全性是建筑师，开发人员或基础设施的责任吗？
更具体地说，从层到层的安全性。
我想答案就是以上所有。
然而，我只是想知道人们的经历是什么 - 尤其是在非敏捷环境中工作？是否应该在技术设计文档中预先设计好一切并确定安全性（我不知道）？
答案 0 :(得分：3)
我必须同意每个人的观点，即安全性必须是每个人共享的设计/实现问题，并且必须跨越所有层。我在一家非常大的公司工作，从事大型内部Web应用程序，每个使用该系统的人都是值得信赖的人，安全性仍然是最受关注的问题。
以下是从图层角度分析我的网络应用程序的方式。当请求发送到Web应用程序时，子域级别的公司范围内的安全性只有only allows SSL (HTTPS) communication到服务器。还有另一个服务器（网络设备）拦截对应用程序的请求，并将根据用户名和密码以及它们要访问的URL处理logging people into the application（身份验证）。
当请求到达UI层时，它会运行另一次安全检查，以验证用户登录时发送的用户凭据和组（授权）。这是determine what actions the user can do in the system。 在业务服务层，我们实现业务安全逻辑（使用AOP）来过滤掉用户不允许看到的某些数据（例如关于他/她自己的信息）。这将允许在一个地方完成过滤，即使它是从UI的不同位置调用的。
在数据访问层或SQL上，公司只允许stored procedures。这可以确保DBA知道对数据库的所有调用（DBA是唯一有权对数据库模式进行更改的人）并且没有任何开发人员可以潜入错误的SQL。要访问数据库，我们使用特殊的用户ID和在配置文件中加密的密码（公司政策和FedRAMP requirement）。
当数据返回到屏幕显示时，我们偶尔会为我们不希望用户篡改的某些数据添加custom hash。
安全性应该是公司和部分应用程序特定的标准。如果您的公司有architect，他/她将帮助您在不同的用例中定义您需要安全的位置，以及您需要覆盖基础架构/公司提供的默认安全性的位置。当谈到实际代码时，开发人员通常会弄清楚如何在特定流程中实现安全性，并找到需要架构师确定的安全性的流程。在对应用程序进行编码和设置之后（最好在staging or integration environment中），您需要从应用程序安全团队someone到test应用程序，以确保它按预期运行且没有{ {3}}
如果这回答了你的问题，请告诉我......
答案 1 :(得分：3)
让我们面对现实，如果安全不属于每个人，那么它将归NO ONE所有。 （我相信Ricky Bobby首先说。）
问题是文化问题。大多数组织都对安全性提供了很好的口碑，但实施它的工作很差，仅仅是因为他们不了解它。当你考虑处理top ten security vulnerabilities是多么简单时，不可能不可原谅。因为一旦你得到它真的很容易。
快速举例：
您的敏感应用需要受到针对像Fiddler这样的数据包嗅探器的保护。你必须
所以你看，它必须在整个小组中完成，因此必须是一个文化主题，而不仅仅是另一个要检查的方框。
嘿，我觉得你很难完成这件事。为了提高标准而向您道具！答案 2 :(得分：2)
我认为这主要是要求的责任。只有当您有明确的安全要求/政策时，才能实施和测试它。
是否是数据库层取决于几个因素;安全里面数据库是可能的，但往往是昂贵的 - 我的意思是：
但它是一个选项（尽管它通常是为大多数安全关键应用程序保留的，即使DBA也不允许读取数据）;除此之外......安全在很大程度上是一个贯穿各领域的问题。您肯定需要特定于UI层的安全实现（因为它正在处理cookie等），但大多数工作趋向成为业务逻辑的一部分。
答案 3 :(得分：1)
应用程序需要在设计时考虑到安全性，而且需要以安全的方式开发。最初的责任落在系统架构师的设计规范上，然后由开发人员正确实施（由架构师监督），最后必须保护Web服务器不受系统管理员和/或基础设施的影响。最大的问题是，中间层的开发人员通常认为从系统中的其他组件给出的所有内容都将得到验证，通常情况并非如此，并且可能导致一些难以追踪的安全漏洞。因此，每个层都必须作为自己的安全沙箱进行开发，以防止数据泄漏。
