金融科技行业软件开发的安全类最佳实践

21-10-05 banq

自世纪之交以来,金融科技行业呈指数级增长,支付欺诈的威胁同样与之相匹配。随着在线信用卡交易和无线支付在世界范围内越来越受欢迎和需求,新的金融科技企业出现了。然而,在这个竞争激烈的市场中,那些缺乏严格安全标准的企业会吸引恶意行为者。

金融科技开发商不断面临为客户提供价值的压力,但他们也需要遵守数据隐私、安全和法规遵从性的要求标准。有时,这些优先事项相互冲突,在不牺牲另一项的情况下实现其中一项可能具有挑战性。

安全性应该是任何应用程序开发过程的核心,而不仅仅是金融科技中使用的那些。任何应用程序在设计上都应该是安全的,这意味着在整个软件开发生命周期中应该始终存在一些最佳实践和严格措施。

确保每个阶段的安全性将降低应用程序的整体开发和维护成本。例如,需要对设计进行重大更改的生产应用程序中的关键漏洞可能会导致时间、金钱和资源方面的大量成本。在设计、开发甚至测试阶段解决这些问题会减少它们的负面影响。

幸运的是,今天的组织正在将 DevOps 和 SecOps 结合在一起,确保开发团队不仅对基础设施负责,而且对安全负责。

让我们简要介绍其中一些安全的设计开发最佳实践。 

 

端到端加密 

金融科技行业及其隐私标准对数据托管人的信息保护有着严格的要求。其中一项要求是使用加密来确保数据免受窃听、数据泄露和数据篡改。 

TLS v1.2这样的加密标准,具有强大的密码(例如 AES-GCM),将为传输中的数据提供强大的保护机制——不仅在外部网络(例如在客户端通信期间)而且在您的公司网络中. 这需要伴随着强大的公钥基础设施 (PKI)来生成可信赖的证书和密钥,这些证书和密钥可由发起连接的客户端进行验证和信任。市场上有许多 PKI 提供商,包括Let's EncryptGoDaddyAWS。 

与传输中的加密类似,使用AES-256等标准进行静态数据加密将确保任何应用程序或用户无法访问存储的数据,除非他们提供解密密钥。

  

机密管理

在信息保护方面,不仅应该加密数据。组织还应采取措施进行机密管理。机密管理处理应用程序中使用的私钥、身份验证令牌、密码或其他元数据,保护这些存储的机密免受未经授权的访问。这可以通过加密和验证的保管库来完成。此类保险库的示例包括:

  • HashiCorp 金库
  • AWS 秘密管理器
  • Azure 密钥保管库
  • Docker 的秘密

 

身份验证、授权和计费

身份验证、授权和记账 (AAA) 应该是任何应用程序安全的核心,无论是对人还是第三方应用程序。身份验证确保只有已知的注册用户和系统才能使用该应用程序。执行身份验证的最简单方法是通过单因素机制,例如用户名和密码。但是,其他安全方法包括多因素身份验证、PKI 或签名令牌。实施将根据业务需求和特定用例而有所不同。

 

安全的云或 SaaS 提供商

除了应用程序控制之外,金融科技应用程序供应商还应确保基础设施级别的安全性。底层基础设施可以在本地或在云中。如果您使用公共云提供商,则需要确保他们拥有必要的行业安全控制和认证。例如,三大云提供商都获得了 PCI-DSS 认证:

除 PCI-DSS 外,您的企业可能需要实施进一步的控制和政策以符合行业法规和标准,例如:

选择具有现有安全认证和标准的云供应商可以让您外包一些安全和合规性任务,帮助您更快地将产品推向市场。

值得注意的是,公共云服务提供商通常有一个责任共担模型,供应商负责其数据中心、网络、基础设施、软件平台和存储的物理安全;同时,客户对其应用和数据安全负责。AWS提供了一种这样的责任共担模型。

 

专用生产环境

金融科技行业与医疗保健行业一样,在将数据发送给托管服务提供商时,对数据安全性——尤其是数据泄露的威胁——极为敏感。

自然,金融机构希望确保其客户和其他敏感数据不被竞争对手或任何未经授权的用户看到。这就是组织经常对多租户 SaaS 解决方案犹豫不决的原因,其中多个客户的数据和应用程序共享同一物理服务器甚至同一网络。使用此类共享环境时意外数据泄露场景的一些示例包括将未初始化的分离卷分配给其他租户或使用公共子网来托管多个客户服务器。

作为开发人员,您当然希望将生产环境与其他客户环境分开。但是,除此之外,您还应该确保无法从任何较低的环境(例如开发、测试或暂存)访问生产数据集。有必要保护您的环境以消除意外或恶意数据泄露的可能性。

 

符合 PCI 标准的小部件

 如果您的组织计划接收或处理卡付款,则法律要求遵守PCI DSS 标准。认证涉及极其严格的过程,这意味着在实施您的安全策略方面需要额外的工作。除非您的企业在获得此认证方面已经在顺利进行,否则这项工作的资源消耗可能会成为一个问题。

PCI 兼容小部件可以提供卡管理解决方案所期望的所有功能。这些功能包括卡激活、PIN 更新、敏感信息显示、传输加密和身份验证。您在内部构建的金融 Web 应用程序可以在 iFrame 中显示这些小部件,从而确保合规性并限制您在卡欺诈时的责任。

 

3D 安全高级欺诈保护

3D Secure (3DS) 是一种协议,旨在在处理无卡交易时提供额外的防欺诈层。现在,任何发卡机构都广泛需要该协议,以防止在线交易中的卡欺诈。

3DS 涉及支付应用程序首先检查用户输入的卡详细信息是否正确,然后该卡是否启用了 3DS。如果启用,则用户将被重定向到应用程序的另一部分(可能是嵌入的 iFrame 或其他页面),在那里他们需要证明自己的身份。这可能涉及回答特定的安全问题或输入已通过电子邮件或短信发送给持卡人的验证码。

 

代币化

支付卡信息(例如卡号、有效期和 CVV)高度敏感,不应以明文形式存储在同一数据库或设备中。一个好的安全实践是在存储时对此类信息进行哈希处理,使未经授权或恶意的用户无法读取这些信息。此过程称为代币化,可降低身份盗窃和信用卡欺诈的风险。

这可确保敏感的卡信息安全地存储在数据库中,而您的应用程序数据库仅存储持卡人的私人信息,如姓名、地址等。这种分离不仅使恶意用户难以从一个地方获取有关卡及其用户的完整详细信息,而且还将整个令牌化过程卸载到受信任的第三方。

 

猜你喜欢