一个细粒度的架构，在安全实施上给了我们更多的自由。对于那些处理最敏感信息的，或者暴露最有价值的功能的部分，我们可以采用最严格的安全措施。但对系统的其他部分，我们可以采用宽松一些的安全措施。
让我们考虑下MusicCorp并结合之前的一些概念，看看可以再哪里以及如何使用这些安全技术。我们主要考虑传输中的数据和静态数据的安全问题。我们将分析下图显示的整个系统中的一部分，目前欠缺对安全问题的考虑。一切都是通过普通的HTTP传输。
在这个例子中，我们的客户使用标准的Web浏览器，在MusicCorp网站上购物。我们还引入第三方版税网关的概念：我们已经开始与第三方公司合作，为新的流媒体服务收取版税。它会间断地获取已下载音乐的记录 – 这个信息我们需要小心地保护，以防止被竞争对手获取。最后，我们将产品目录数据暴露给其他第三方。例如，允许在音乐评论网站中，嵌入艺术家或歌曲的相关信息。在我们的网络范围内，有一些协作的服务仅在内部使用。
对于浏览器，我们会为无需安全保护的内容使用标准HTTP，以便其能被缓存。对于有安全需要的、登录后才可访问的页面，所有的内容都通过HTTPS传输，这样，如果我们的客户使用像公共WiFi那样的网络，能够给他们提供额外的保护。
当涉及第三方的版税支付系统时，我们所关注的不仅仅是公开数据的性质，还要确保我们得到的请求是合法的。在这里，我们坚持让第三方使用客户端证书。所有的数据传输都通过一条安全的、加密的通道，这能够提高我们确保请求主体合法性的能力。当然，我们也需要考虑当数据离开控制范围后，会发生什么事情。合作伙伴是否会跟我们一样关心这些数据？
对于产品目录数据的聚合，我们希望尽可能广泛地共享这些信息，让人们很方便地从我们这里购买音乐！然而，我们不希望这个信息被滥用，而且想要知道是谁在使用我们的数据。在这里，使用API密钥是一个绝佳的选择。
在网络范围内部，情况有点微妙。我们有多担心有人威胁我们的内部网络？理想情况下，最低限度也应该使用HTTPS，但是它的管理有点痛苦。我们决定，花费更多精力来夯实网络边界的保护（至少在刚开始时），这包括使用一个正确配置的防火墙，选择适当的硬件或软件安全装置检查恶意流量（例如，端口扫描或拒绝服务攻击）。
也就是说，我们担心的是数据及其存储的地方。我们并不担心产品目录服务；毕竟，我们希望共享这些数据，并为它提供了一个API！但是我们很担心客户的数据。在这里，我们决定加密客户服务中的数据，并需要在读取时解密。如果攻击者真的潜入我们的网络，他们仍然可以发送请求给客户服务API，但当前的实现并不允许批量检索客户数据。如果这个情况真的发生，我们可能需要考虑使用客户端证书来保护这些信息。即使攻击者攻破数据库所在的机器，下载了全部内容，他们也将需要访问用于加密和解密数据的密钥才能使用这些数据。
下图显示了最终的结果。正如你所看到的，基于对被保护信息本质的了解，我们最终选择了这些技术。你自己的架构安全关注点很有可能非常不同，所以最终你可能会有一个看起来不一样的解决方案。
