审计跟踪和实施 SOX/HIPAA/等，敏感数据的最佳实践 [英] Audit trails and implementing SOX/HIPAA/etc, best practices for sensitive data

问题描述

我认为自己在应用程序设计方面相对精通，但我从未处理过敏感数据.我一直想知道审计跟踪的最佳实践是什么以及应该如何实施它们.我现在不必这样做，但如果他们要求我为他们做一些工作，能够自信地与他们交谈会很好.

I consider myself to be relatively proficient in terms of application design, but I've never had to work with sensitive data. I've been wondering about what the best practices were for audit trails and how exactly one should implement them. I don't have to do it right now, but it'd be nice to be able to confidently talk with a medical company if they ask me to do some work for them.

假设我们有一个学校"数据库，其中 'teachers'、'classes'、'students' 都在一个多对多的成绩"表中标准化.你会记录什么?成绩表"上的每次插入/更新?只有更新(比如，一个孩子闯入并想要改变成绩，这应该会发出危险信号)?这是否完全根据一个人想要的偏执程度而有所不同?有最佳做法吗?

Let's say we have a "school" database, with 'teachers', 'classes', 'students' all normalized in a many-to-many 'grades' table. What would you log? Every insert/update on the 'grades table'? Only updates (say, a kid breaks in and wants to change grades, this should send up redflags)? Does this vary entirely based on how paranoid one wants to be? Is there a best practice?

这是应该在数据库中完成的事情吗?(每个敏感 SELECT 的触发器都会向记录每个查询的审计"表中插入一行?)应该记录什么?是否有自动内置到 Oracle/DB2 中的功能可以为您执行此操作?这应该是应用端逻辑吗?

Is this something that should be done in the database? (A trigger on each sensitive SELECT which inserts a row to an 'audit' table logging each query?) What should be logged? Is there functionality automatically built into Oracle/DB2 that do it for you? Should this be application side logic?

如果有人有任何关于如何处理敏感数据的正式文档/书籍(不是 DoD可信计算"规范，而是类似的内容:P)，我将不胜感激.如果这个问题非常含糊，我很抱歉.我意识到这因应用程序而异.我只想听听您在处理敏感数据方面的详细经验.

If anyone has any formal documentation/books on how to deal with sensitive data (not quite DoD "Trusted Computing" spec, but something along the lines of that :P), I'd appreciate it. I'm sorry if this question is terribly vague. I realize that this varies from application to application. I just want to hear your detailed experiences with dealing with sensitive data.

推荐答案

首先要了解的是所选 DBMS 的本机审计功能.这些在细节上有所不同，但通常提供了一种方法来配置审核哪些操作，并为它们生成的审核记录提供安全存储.

The first thing to understand is the native auditing capabilities of your chosen DBMS. These vary in detail, but generally provide a way to configure which operations are audited, and provide secure storage for the audit records that they generate.

接下来要了解的是您要审核的内容.例如，在 HIPAA 和 SOX 的情况下，您可能正在查看 PII - 个人识别信息.还记得人们对访问奥巴马的电话记录或各种名人医疗记录的大惊小怪，或者......因为系统审计了谁阅读了这些记录，审计分析官(AAO)发现名人记录被人们访问而被抓获谁没有特别授权这样做.因此，这些系统必须记录谁访问了每条记录，并发现这样做的用户何时没有真正的商业理由这样做.在这些情况下，用户似乎具有读取记录的权限，因此如果他们的日常职责要求他们查看记录，他们可以这样做.但是，如果他们没有被要求这样做，那么他们就是在滥用权力并受到适当的制裁(甚至因此失去工作).

The next thing to understand is what you want to audit. In the case of HIPAA and SOX, for example, you are probably looking at PII - Personal Identifying Information. Remember the fuss made about people accessing Obama's phone records, or various celebrities medical records, or ... Those were caught because the system audited who read those records, and the audit analysis officer (AAO) spotted that the celebrity records were accessed by people who were not specifically authorized to do so. So, those systems must be logging who accesses each record, and spotting when the user who does so does not have an authentic business reason to do so. In these cases, it appears that the users had read authority for the records, so if their ordinary duties required them to look at the records, they could do so. But, when they were not required to do so, then they were abusing their power and appropriately sanctioned (up to and including losing jobs over it).

这意味着您可能不想跟踪谁访问了记录州代码和全名(以及有关州的其他信息)的州表.该列表没有任何机密性 - 谁阅读它并不重要.当然，几乎没有人应该写信给它.状态列表不会经常更改 - 但这可能可以通过撤销每个人对该表的更新和删除权限来处理.

What this means is that you probably don't want to track who accesses the table of States which records the state code and full name (and assorted other bits of information about the state). There is nothing confidential about that list - it doesn't matter who reads it. Of course, almost no-one should write to it; the list of states does not change very often - but that can probably be handled by revoking update and delete permission on the table from everyone.

OTOH，您可能确实想记录谁访问了病史 (HIPAA) 中的记录，或者谁修改了会计系统 (SOX) 中的数据.您可能需要也可能不需要担心谁读取了会计数据；很多可以通过基本权限处理(会计人员有权限；IT 人员没有).但是，审计始终是一道额外的防线.

OTOH, you probably do want to record who accesses the records in medical histories (HIPAA), or who modifies the data in the accounting systems (SOX). You might or might not need to worry about who reads the accounting data; a lot of that can be dealt with by basic permissions (accounting staff have permission; IT staff do not). However, auditing is always an extra line of defense.

请记住，如果从不查看审核记录，则没有任何帮助.一般来说，审计会减慢系统的速度(仅仅是因为它在写入审计记录时做了更多的工作)；在决定实施您的审计策略之前，了解它减慢了多少是很重要的.但是，有些事情比申请速度更重要，其中之一就是让您和其他工作人员远离监狱.审计可能是必要的，以确保发生这种情况.

Bear in mind that audit records are no help whatsoever if they are never looked at. In general, auditing slows a system down (simply because it is doing more work when it writes audit records); it is important to understand how much it slows down before deciding to implement your auditing strategy. However, there are some things that are more important than application speeed, and one of those is keeping yourself and other staff members out of jail. Auditing can be necessary to ensure that happens.

这篇关于审计跟踪和实施 SOX/HIPAA/等，敏感数据的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！