从应用数据角度看网站存在的逻辑漏洞

从应用的角度来看，在应用生命周期内，鉴定权和解密是重要的项目。全链接TLS不仅需要从client到application，还需要之间加密传输。如何设计CA，如何使用证书，需要明确哪个policy，传输过程需要支持相应的TLSCiphoerSuite、Versure、Algorommanhoms等。有必要明确启用国密算法。除了业务应用程序之外，应该如何保存APM、标志数据等基础服务(为应用程序提供基础服务的Service)，是否实现了同一安全等级的要求？不同Zone之间的ACL战略可以遵循最小化的原则吗？加密服务有权限控制吗？如果回到SDLC，是否存在越权(或其他)的漏洞，在应用程序中解密相应的加密数据，源代码是否泄漏到公开的管理站点？扫描服务器的白名单上是否有陷阱。回到线上，有多少恶意流量被清洗，无论是四层还是七层。当然，这些似乎脱离了数据安全，但实际上并非如此。正如前文所说，都是相互依赖的。流量清洗时能补充相关的控制数据吗？更新的feed来源有可能被污染吗？那样的东西不计其数。

因此，在关注应用程序时，还需要关注应用程序的基础设施和网络流量的清洗，与应用程序本身的代码有关。不是说装了多少设备，买了多少服务就能解决问题。从数据的角度来看。结束了应用视角和业务视角。终于回到了数据本身。从数据角度来看，最基本、最直接的方法是为不同类型的数据提供安全存储(加密)，同时可以在可审计的授权下确保数据转移过程的一致性。当然，你可以跳过这句话来看DSMM等等。之所以在这个时候提到DSMM，是因为DSMM模型本身缺乏业务和应用的框架制约。当然，更深入的应该是读书和实践。简而言之，在数据安全工作中，涉及的用户数据不仅出现在流量中，还出现在日志和数据库中。

在不同的位置，数据什么时候明确，什么时候加密？在任何场合取得任何数据都需要根据相应的战略和制约进行。此外，在考虑数据等级和数据类别的同时，还需要考虑这个数据是否可以在这里获得/打开，是否可以存储。例如，有必要考虑持卡人的数据是否可以保存在当地，是否可以出国等。对于静态数据的加密、动态数据的分类扫描和相应的权限管理等安全控制，另一个必要措施是审计所有行为。所有审计日志无论是数据库审计、DAL层还是不同设备的常见操作日志。应该推进集中的日志集群。冷热分离，计算分析。同样，在这个过程中，哪些场景需要对敏感数据的脱敏？从数据的角度来看，有必要回到数据本身，丰富数据的属性，关注数据的流动和相应的流程制度。在谈到数据安全的基础设施后，我们可以看到如何在基础设施上进行相应的运营管理。