简单介绍一下背景。我们是一家小公司（13 名员工，其中 6 名是 IT/开发人员）。每个人都远程工作，没有中央办公室。我们的数据中心仅用于开发和生产环境。我们不将其用于任何内部公司功能（例如，目前只有 IT 部门可以通过 VPN 访问它，我们使用 Office365/OneDrive 之类的东西，而不是我们网络上的文件服务器）我们开发、托管和销售 SaaS 解决方案。我们处理一些医疗数据（例如 HIPAA 和 PHI），因此我们已经完成了获得 HIPAA 和 NIST 认证的过程，这对我们的客户非常重要。
现有基础设施
我们在数据中心有一个半机架，其中有集群 Hyper-V 环境（3 个物理服务器连接到 Nimble SAN）。我们的环境包括：
- pfSense 周边防火墙（配置了 OpenVPN 以及用于 IDS/IPS 的 Snort）
- 使用带有 SSL 终止的 keepalived 实现冗余 HAProxy
- 两个运行 IIS 的 Windows 2008R2 VM 用于我们的主要应用程序（注意：当前使用具有 WAF 的 Cloudflare Business）
- 主动/被动故障转移群集中两个运行 SQL 2014 的 Windows 2012R2 VM。
- 我们还有一个单独的 Dev VM、2 个 AD VM 和一个 DPM VM 用于备份，但我并不关心这篇文章中提到的这些内容 - 只是想提一下它们的存在
我们已经使用 Azure 存储来存储客户文档以及异地备份。我们还在 Azure 中配置了一个冷灾难恢复站点，该站点由三台虚拟机（AD、Web 和 DB）组成，虽然规模很小，但可以让我们在几个小时内启动 Azure 上的主要基础设施。
未来计划
我们的目标（理想情况下是在 2019 年底）是将数据中心迁移到 Azure。我们当前的硬件正在老化，虽然没有出现故障迹象（希望如此），但我们希望摆脱数据中心领域，因为微软（或亚马逊/谷歌等）等公司更有能力做到这一点，而数据中心领域则不必担心物理设备。我对如何实现这一目标有一个不错的想法，并且在过去一个月里一直在使用 Azure 来熟悉各种选项。
从高层次的角度来看，我正在研究像这种部署一样简单的事情（https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/basic-web-app) 来为我们的应用程序。我们考虑过直接在 Azure 中重新创建现有虚拟机的直接迁移方法，但从维护的角度来看，迁移到 PaaS 更具吸引力。主要区别在于我们将使用 SQL 托管实例作为数据库，而不是 SQL 数据库。此架构仅适用于我们的生产环境。对于我们的开发/QA 环境，我们很可能会在单独的资源组和 vNet 中部署相同或类似的架构。
我最大的疑问在于防火墙是否适合这里。我们收到 IT 问卷，并且必须对大多数客户进行全面的 IT 安全审计。以下是我们收到的一些问题示例：
- 所有内部连接都使用防火墙吗？
- 所有外部连接都使用防火墙吗？
- 防火墙是否用于分割内部网络？
- 该组织是否采用入侵检测 (IDS) 或入侵防御 (IPS) 系统？
基本上，到目前为止，我发现的所有示例中，推荐的 Azure 部署都不包含任何与防火墙或 IDS/IPS 相关的内容。这很标准吗？我知道 Azure 防火墙是存在的，但每月 900 美元的价格并不值得，因为它在 NSG 之上提供的保护有限。我已经开始考虑 NVA 选项（特别是 Netgate pfSense，因为我对 pfSense 非常熟悉），但我不知道这是否会过度？
因此，如果您在读完这个冗长的计划后仍然在读下去，我想我要问的是：
- 至少看起来我的前进道路是正确的吗？还是我完全错了？
- 如果我们继续进行上述部署，您将如何处理客户有关防火墙和 IDS/IPS 的问题？
答案1
受保护的个人身份信息 (PII) 的安全性和合规性要求与监管较少的行业不同。（尤其是与安全设计最低的初学者教程相比。）除了违反非常私人的信息而背叛患者的信任之外，一些司法管辖区还会施加处罚。在美国，人们倾向于引用 1996 年《健康保险流通与责任法案》（HIPAA）及其关于受保护健康信息 (PHI) 的规定。处罚可以根据受影响的记录进行评估，如果因疏忽而导致处罚，处罚会更严厉。
防火墙问题可以引发有关安全控制的讨论。但它们并不是一个完整的安全程序。
当然，应该有第 4 层防火墙来控制 IP（Azure 应用程序安全组) 和端口。还应考虑对网络进行分段。应仅授权访问包含 PHI 的数据库，并将测试与生产隔离。零信任的概念可能有助于启发。有办法证明防火墙规则实现了您的意图。
您还需要一些方法来预防和检测违规行为。假设您有一个不受限制且未经审计的 API。当数据从端口 443 中抽出时，网络级防火墙无济于事，因为端口 443 的设计是开放的，供授权使用。
您可以对此进行的控制包括应用程序中的强大审核功能，以及可能用于检查不良行为的 IDS/IPS。问题不仅在于 Azure 防火墙是否适合您，还在于您能多快显示未经授权访问的证据、有多少数据被泄露以及是谁干的。如果您的应用程序和 Azure 都没有这些功能，请考虑第三方产品。
哦，还有电子邮件。你打算如何阻止用户通过电子邮件发送患者 ID？
数据中心的物理安全由 Azure 负责。但您是否对员工笔记本电脑实施了磁盘加密？这些笔记本电脑上可能会因 PHI 而丢失。
所有这些以及更多要求安全计划具有全面的风险管理计划、不会忘记基本原则的强大流程以及领导参与。作为这种纵深防御方法的一个例子，请看SecurityMetric 的 HIPAA 合规指南。
诚实地对待您的客户和审计员。承认任何漏洞并提供替代控制措施比声称自己能做到一切更令人信服。