On 9/2/07, Jeff Kowalczyk <..hidden..> wrote:
Has anyone thought about ways we might expire, remove and optionally
restore identifiable customer/entity information from LedgerSMB datasets?
In general this is something that needs to be considered on a case by case basis. I think that once we understand enough of the cases, we can look at a general solution though. I have had at least one potential customer ask for such a feature though.
Obviously, preventing penetration of a production system is the intention.
There's always something in the news about breaches like TJMaxx and
monster.com.
First of all, I would point out that if your production *accounting* system is compromised you have plenty of potential problems, not the least of which might be the ability to print checks, create bogus invoices to cover tracks, and the like. In short, this could be used to *steal your money.* This is one reason why security is such of a priority for the LedgerSMB team.
Having said this, there are plenty of reasons why different businesses may want to do this. These may have to do with privacy protection and the like. At the moment though, I don't think it is possible to *safely* remove all such information withough losing other important data for everyone. Hence the case-by-case aspect.
There might be high target-value business which would prefer or be obliged
to no longer store the identifiable information in the production system
after the invoice is closed, as one example.
Agan, I have had one request for a quote for a project which had this sort of component. Because the entity in question was also using SAP, there were questions about how to do this so that one could not correlate from the other system. The big points here are:
1) When this happens businesses usually want to store some demographic information relating to the invoice (what market segment, for example, or what geographical region).
2) There may be other applictions involved which could mitigate these efforts.
Hence it is a very good idea to think this through in a few real-world cases before committing code for this sort of thing.
In my own use case, I think we'd like to use this, and map our own
customer number to an offline archive of the identifiable customer
information. As needed, we would restore individual customer data for a
repeat sale, or temporarily at an auditors' request.
In this case, I would suggest:
1) Create a dummy customer/account
2) Backup the transactions to off-line media.
3) Move the customer numbers on the invoices to that account after the backup is created.
Steps 2-3 could be automated with shell scripts, stored procedures, etc. It isn't a lot of work. Most of the effort is in designing something that meets *your* needs in this area to the best degree possible.
I'm hoping that the revamped entity model in 1.3+ will make something like
this possible.
Honestly, it isn;t any harder in 1.2. If you want high-level guidance for such a solution, that is what this list is for. If I were to be hired to do this, most of my time would be spent on needs analysis.
Destroying information is easy :-) Making sure the *right* information is destroyed... That is the question.
A simple database API to expire and restore customer data would be really
nice. It might let LedgerSMB move into additional business areas.
The only problem is that data-retention policy enforcement issues tend to be *extremely* sensitive to exact needs. I think we need to have more experience with this issue and the math involved before we start including code to do it. Nothing like a false sense of security....
Best Wishes,
Chris Travers