Security: protecting data in your NoSQL systems - Making Sense of NoSQL - page 244

application level as well as the database level; NoSQL databases aren't required to
have built-in libraries to perform these functions. Yet for some applications, knowing
the database hasn't been modified by unauthorized users can be critical for regulatory
compliance.
Encryption processes use tools similar to the hash functions we described in chap-
ter 2. The difference is that private and public keys are used in combination with cer-
tificates to encrypt and decrypt documents. Your job as architects is to determine
whether encryption should be done at the application or database layer.
By adding these functions in the database layer, you have centralized control over
the methods that store and access the data. Adding the functions at the application
layer requires each application to control the quality of the cryptographic library. The
key issue with any encryption tool isn't the algorithm itself, but the process of ensur-
ing the cryptographic algorithm hasn't been tampered with by an unauthorized party.
Some NoSQL databases, especially those used in high-stakes security projects, are
required to have their cryptographic algorithms certified by an independent auditor.
The US National Institute of Standards and Technology ( NIST ) has published Federal
Information Processing Standard ( FIPS ) Publication 140-2 that specifies multiple levels of
certification for cryptographic libraries. If your database holds data that must be
securely encrypted before it's transmitted, then these standards might be required in
your database.
XML S IGNATURES
The World Wide Web consortium has defined a standard method of digitally signing
any part of an XML file using an XML Signature. XML Signatures allow you to verify
the authenticity of any XML document, any part of an XML document, or any resource
represented in a URI with a cryptographic hash function. An XML Signature allows
you to specify exactly what part of a large XML document should be signed and how
that digital signature is included in the XML document.
One of the most challenging problems in digitally signing an entire XML docu-
ment is that there are multiple ways a document might be represented in a single
string. In order for digital signatures to be verified, both the sender and receiver must
agree on a consistent way to represent XML . For example, you might agree that ele-
ments shouldn't be on separate lines or have indented spaces, attributes should be in
alphabetical order, and characters should be represented using UTF-8 encoding. Digi-
tal signatures can avoid these problems by only signing the data within XML elements,
not the element and attribute names that contain the values.
As an example, US federal law requires that all transmissions of a doctor's prescrip-
tions of controlled substances be digitally signed before they're transmitted between
computer systems. But the entire prescription doesn't need to be verified. Only the
critical elements such as the doctor prescribing the drug, the drug name, and the
drug quantity need to be digitally signed and verified. An example of this is shown in
listing 11.1, which shows how the rules of extracting part of the text within a docu-
ment are specified before they're signed. In the example, the prescriber (Drug