change nav 1-patterns formatting
This commit is contained in:
parent
ba12637e35
commit
7e4e21d223
54 changed files with 211 additions and 250 deletions
|
|
@ -1,9 +1,7 @@
|
|||
+++
|
||||
title = "1-sensitive-data-encapsulation.md"
|
||||
title = "Sensitive Data Encapsulation"
|
||||
weight = 120
|
||||
+++
|
||||
## Sensitive Data Encapsulation
|
||||
|
||||
_By Bogdana Botez at Microsoft Development Center Copenhagen_
|
||||
|
||||
_
|
||||
|
|
@ -40,7 +38,7 @@ To apply this pattern in Dynamics NAV, a table structure similar to Table 1261 S
|
|||
Figure 1 describes the definition of a table which is already available in Dynamics NAV. This table can be used for storing sensitive data. As a minimum, the table only needs two fields:
|
||||
|
||||
1. The key is of type GUID (Globally Unique Identifier), which is a 128-bit value consisting of multiple groups of hexadecimal digits \[2\]. Each key needs to be unique and will be used for storing and retrieving the protected information.
|
||||
2. The value (the actual data to be encapsulated) is of type BLOB (Binary Large OBject) \[3\], which contains the encrypted or un-encrypted data (for encryption, see the related [**Encryption** ][anchor2]pattern).
|
||||
2. The value (the actual data to be encapsulated) is of type BLOB (Binary Large OBject) \[3\], which contains the encrypted or un-encrypted data (for encryption, see the related [**Encryption**][anchor2] pattern).
|
||||
|
||||
[![Figure 1- Example definition, table used for Data Encapsulation][image1]][anchor3]
|
||||
|
||||
|
|
@ -72,13 +70,13 @@ _Figure 2 - Data access before and after **Sensitive** **Data** **Encapsulation.
|
|||
|
||||
* **Clarity:** when all sensitive data is encapsulated in one place, it is clear which is the information that needs to be protected.
|
||||
* **Simplicity:** easier to protect just a limited number of known resources when they are grouped.
|
||||
* **Homogeneity: **the same protection can be applied to all data, since it is stored in the same place.****
|
||||
* **Separation of concerns: **treat each section of the computer program differently, by separating it and clearly addressing its own requirements and limitations. \[1\]
|
||||
* **Performance**: data protection techniques like **Access Control** and **Encryption **can now be applied only to the sensitive data (not to everything), which improves the performance of the system.
|
||||
* **Homogeneity: **the same protection can be applied to all data, since it is stored in the same place.
|
||||
* **Separation of concerns:** treat each section of the computer program differently, by separating it and clearly addressing its own requirements and limitations. \[1\]
|
||||
* **Performance**: data protection techniques like **Access Control** and **Encryption** can now be applied only to the sensitive data (not to everything), which improves the performance of the system.
|
||||
|
||||
**Drawbacks:**
|
||||
|
||||
* **Single point of failure:** a maliciously intended actor has no longer a need to reverse engineer the places where important data is stored. In the unwanted situation when this actor would have already obtained access to the system, they can more easily locate the sensitive information. This is a step towards information disclosure, but mechanisms like [**Encryption** ][anchor2]and logging can provide further protection.
|
||||
* **Single point of failure:** a maliciously intended actor has no longer a need to reverse engineer the places where important data is stored. In the unwanted situation when this actor would have already obtained access to the system, they can more easily locate the sensitive information. This is a step towards information disclosure, but mechanisms like [**Encryption**][anchor2] and logging can provide further protection.
|
||||
* **Limited Text Length**: there is a limit on how long the encrypted text can be. This limit is imposed by the OS encryption service and it depends on the composition of the text as well as on the system specifics. In NAV, we had implemented the Encrypted Text for text values of max 250 chars, which is enough to cover passwords, person ID numbers, credit card info, but it might turn insufficient in other future scenarios.
|
||||
* **Nomenclature**: the name of the table **Service Password** is too specific, since it started by being used for passwords, but it has the capability and it now contains other sensitive data like API Keys, credit card numbers etc.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue