如何在 Python 和 Flask 中使用 IP API 查找地理位置?
如何在API中查找和保护敏感数据
数据是现代互联网的主要动力。API需要数据来进行通信,并提供我们在现代互联网中看到的巨大好处。然而,这些数据不仅仅是简单的1和0。它通常代表个人和团体的身份,反映他们的愿望,品质和个人信息。
因此,保护敏感数据既是商业上的当务之急,也是道德上的当务之急。但是,组织如何找到和保护这些敏感数据,特别是在数据如黄金般珍贵的API驱动的环境中?
什么是PII和敏感数据?
当我们讨论查找和保护敏感数据时,这些数据福尔斯分为两大类:个人身份信息(PII)和一般敏感数据。这些术语的实际含义是什么,何时适用?
许多组织和监管机构对PII有不同的定义。在美国,国家标准与技术研究院(NIST)对PII的定义如下:
“个人身份信息:允许通过直接或间接方式合理推断信息适用的个人身份的任何信息表示。(NIST SP 800-79-2)”
在欧洲,根据GDPR,PII可以被广泛定义为“个人数据”:
“个人数据“是指与已识别或可识别的自然人有关的任何信息(“数据主体”);可识别的自然人是可以直接或间接识别的人,特别是通过参考诸如姓名、身份证号、位置数据、在线标识符等标识符或特定于身体、生理、遗传、心理、经济、该自然人的文化或社会身份.”
另一方面,敏感数据的定义不那么明确。虽然GDPR中有一类敏感的个人数据,但API背景下的敏感数据的定义要少得多。从广义上讲,敏感数据可以被视为比PII更广泛的项目,因此,它当然包括这些数据。
“敏感数据是机密信息,必须保持安全,除非他们有权访问,否则所有外人都无法访问。”
因此,将这两个术语视为特定性的平衡可能是最容易的。PII是一组定义明确的数据点,而敏感数据是一个包罗万象的术语,适用于所有应受到外部访问保护的数据(包括PII本身)。从本质上讲,敏感数据是我们想要保持隐私的任何部分。如果API所有者不愿意将数据打印在布告板上并张贴在他们的草坪上,那么它就是敏感数据。
监管考虑
重要的一点是,保护这些数据不仅仅是一件好事-在许多情况下,这是法律。虽然某些数据点显然必须受到保护,例如PCI DSS下的信用卡支付信息,但其他数据,例如某人的性别,身份,位置等,则属于不同的法规,乍一看可能不那么透明。
在欧盟,《通用数据保护条例》(GDPR)是管理这些数据的监管文件。它不仅非常具体地说明了什么是PII和敏感数据,而且还配备了相当严格的执行机制。对于严重违规行为,罚款可高达全球营业额的4%或高达2000万欧元,以较高者为准。对于基本违规行为,罚款最高可达全球营业额的2%或1000万欧元,同样以较高者为准。
美国在隐私法规方面明显落后,但即使是它也有一些覆盖面和措施来执行这些标准。在加州,《加州消费者隐私法》确保了PII数据的部分覆盖范围。在联邦范围内,医疗保健信息等敏感数据受到《健康保险便携性和责任法案》的保护,违反隐私将被处以巨额罚款。
简而言之,个人信息和敏感数据的安全保护不力可能会对监管和财政产生巨大影响。但这并不是组织应该考虑的唯一事情。
品牌信任与安全
即使数据不受法规保护,组织也应该考虑对其品牌和平台安全的影响。收集个人信息边缘数据的API,例如推断的经济状况或身份信息,收集的数据如果泄露,可能会在其公司记录上留下痕迹。
我们以前见过这种情况–公司在数据泄露后倒闭的故事比比皆是。即使他们设法保持业务,他们往往这样做的客户和收入的重大损失。
如果用户不能信任组织来保护他们的数据,他们就不太可能将这些数据提供给组织。这对从事数据销售的公司来说是一个丧钟。它还可能阻碍算法内容、内部广告或用户支持。毕竟,你如何支持一个拒绝给你他们的电子邮件,用户名,位置或任何其他信息的用户,所有这些都是因为他们不信任你来保护它?
在API中查找敏感数据:API是泄漏的
记住这一点,记住API是冗长的是很有帮助的。开发人员设计API来连接系统和交换信息,许多最引人注目的数据泄露事件并非来自完全非法的内部活动,而是来自基本的疏忽或对配置的误解。像错误配置的数据存储解决方案这样简单的事情可能会导致数亿条记录暴露,破坏组织的声誉并暴露全球用户的私人信息。
因此,战斗的一半实际上是首先找到哪些敏感数据被暴露。
自动扫描和发现
随着LLM驱动的AI安全产品的广泛采用,扫描和发现漏洞从未如此容易。诸如作为盐安全的解决方案提供了自动化的解决方案,用于检测暴露的端点和安全状态中的弱点。
值得注意的是,这个过程依赖于开发人员的开放文档和寻找错误的意愿。简单地混淆端点并认为它“安全”是不够的。如果你的数据存在,有一种方法可以访问它,这可能不像你想象的那么清楚。因此,需要进行全面测试,以全面了解安全状况。
错误配置是导致数据暴露的一个重要原因,因此,通过内部自动扫描和发现进行尽职调查将带来巨大而直接的回报。
一旦你完成了内部审查,你应该看看什么数据是外部访问。从这种状态确保适当安全性的最佳方法是深入研究提供的各种端点,枚举所有端点并扫描它们的漏洞。
这些漏洞可能是显而易见的,例如配置错误或缺乏安全性。然而,在某些情况下,它们可能不那么明显,例如简单的破坏访问控制或特权升级。枚举端点并扫描它们以查找常见漏洞可以帮助保护您的状态,但这需要使用受信任的合作伙伴。
数据分类
隐私和安全之战的很大一部分是了解您正在收集的数据并对其进行适当的分类。开发人员应该从第一天起就知道他们正在收集什么数据,如果这个过程被应用于现有的产品,那么对数据收集进行全面的审查和审计是值得的。
然后必须对这些数据进行分类,并考虑如何处理这些数据。有些数据不一定是个人身份。例如,您不能根据时间戳合理地推断出用户的某些信息,除非使用模式表明其区域设置。但是,这些数据可能会与其他数据一起成为PII。因此,所有数据都值得通过合理的便利来保护。除非需要从外部访问数据,否则最好将其视为需要保护的数据。
话虽如此,一些数据(例如金融或医疗保健数据)显然受到更严格的安全执法的保护,应该与其他数据分开并提供更高级别的审查。此外,出于监管目的,它可能需要阐明安全处理的文档。
考虑收集的所有数据,并将其分类为特权访问类别。确保只有公共消费所必需的才真正公开,并适当保护其余部分!
保护数据
实施适当的身份验证和授权
正确的身份验证和授权是确保数据安全的主要因素。从本质上讲,身份验证确保访问系统的人就是他们所说的那个人,而授权确保他们有权访问他们想要的东西。
重要的是要注意,身份验证和授权仅与底层数据方案一样好。如果您没有正确地留出哪些角色可以访问哪些数据,那么强身份验证和授权模式就像一把纸锁–安全性的终极幻觉。
一旦你有一个适当的安全计划和系统来实现它,你必须确保这个计划在实践中得到遵守。通常,管理员帐户或特权漏洞被用来破坏核心安全性。为了避免这种情况,遵守安全计划将需要一致的安全审计,轮换角色,基于安全第一原则的基于角色的访问控制等等。
使用适当的加密
即使您设法保护进入系统的请求的涌入,您仍然必须防止简单的数据泄露。现实情况是,传输中的数据可以在任何时候通过可见的传输线路(例如通过互联网)被看到。更重要的是,理论上,如果任何人物理访问硬盘驱动器或远程访问服务器集群,静态数据都可能被盗。
因此,您需要确保这种情况不会发生。最好的方法是部署加密。加密的最基本形式是一种对数据进行置乱的方法,只有当您有特定的信息(“密钥”)来解扰它时,它才有意义。
组织必须了解两种加密。第一个是传输中的加密。这种加密允许数据的发送者和接收者对数据进行加扰和解扰,这样如果有任何东西在“中间”被捕获,它就无法使用了。这有助于保护传输中的数据,但一旦存储,您还必须在静态时对其进行加密。这确保了,即使数据被泄露,由于破解加密的纯粹经济和资源成本,它对小偷也是无用的(或者至少足够长的时间来循环密码和备用数据)。另请阅读:
选择不收集
保护数据的一个主要策略似乎简单得可笑:首先不要收集它。组织通常会收集大量数据以备将来使用,但这些数据中的大部分不一定有用,结构良好,甚至可能有利可图。
因此,最好的策略是不收集任何东西,除非有必要。减少收集的数据量可以最大限度地减少可能暴露的数据量。它还减少了必须首先完成的处理和加密。
多年来,科技行业一直将数据视为黄金。现实情况是,加密和其他安全措施是有成本的,仅仅因为数据“可能”有价值而保留数据,特别是考虑到有问题的数据属于用户,而不是开发人员,这只是为了可能永远不会实现的潜在优势而付出成本和风险。
保护API中的敏感数据
查找和保护PII和敏感数据是开发API的一个非常重要的部分。通过一些简单的注意事项和流程,任何组织都可以采取更好的安全态势,从而带来更好的用户体验,更高的组织信任度,以及更好的大规模和长期成果。
原文链接:https://nordicapis.com/how-to-find-and-protect-sensitive-data-in-apis/