13.3. Security and Privacy

 <  Day Day Up  >  

Security and privacy are complicated issues. You need to deal with both administrative and development facets to make a secure system. Before implementing invoices and discounts , Tim and I consider the security and privacy issues.

13.3.1. Security

With the addition of CreditCard to Customer , CustomerCollection contains some sensitive data. We need to protect that data from prying eyes ("If You Forget Security, You're Not Secure"). Since we used CustomerCollection as the interface to the data, we can assign responsibility for protection of that data to that class and to classes with which it collaborates. We could apply a number of techniques to provide this protection. For example, we could encrypt all information in the collection in whatever persistence mechanism was used to store the collection. That way, the data would be relatively safe even if the file were copied . Only when a Customer is retrieved would the data be decrypted.

Security is not just a matter of encryption, but includes examination of all interfaces into a system. For example, CustomerCollection has a mechanism to search for customers by name . Sam needs to decide where to draw the line between ease of use and security. If the search allows the matching string to be a single character long, an errant user can find all names of customers with only 26 or fewer searches. If the search allows the empty string as a match criterion, a single search could produce a list of all Customer s.

13.3.2. Privacy

Sam called me up. "A few customers have called me with concerns. They know about the federal law that doesn't allow rental stores to keep track of what videos a customer has rented. They want to know whether we keep track of the CDs they have rented."

"Sounds like a legitimate concern to me. Both Invoices and Rentals are related to Customers. We were thinking of tying Invoices back to Rentals. To alleviate that concern, we'll put the rental detail in InvoiceDetail and eliminate any other association between Invoices and Rentals. We will be sure to eliminate any paid Invoices. We'll keep unpaid ones, so we have all the information necessary to present to a collection agency, if it comes to that," I stated. "So we only have to worry about the Rentals. We can delete a Rental once it has been invoiced, but then we wouldn't have a record of the rentals for a particular CDDisc. Let's alter the Rental to relate to an anonymous Customer, once it's been invoiced."

"That sounds good to me," Sam replied hesitatingly.

I recognized I might have gone into too much detail. "In short, we'll be sure that any record of a customer renting a CDDisc is destroyed , once the rental is paid for," I explained.

"That's what I like to hear," Sam responded quickly.

Security and privacy concerns influence system design. For Sam's system, adding privacy is relatively simple. For larger systems, if security and privacy concerns are not addressed in the beginning, they can create a larger disruption when they finally must be addressed.

CONSIDER PRIVACY

Systems need to be designed with privacy in mind .


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net