You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: learn-pr/wwl-sci/design-solutions-secure-organization-data/includes/2-design-solution-data-discovery-classification-microsoft-purview.md
+48-21Lines changed: 48 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,21 +16,60 @@ A comprehensive discovery solution must provide visibility across this entire es
16
16
17
17
### Classification taxonomy design
18
18
19
+
Classification taxonomy is a hierarchical depiction of data categorization. There isn't a universal standard for classification—it's driven by your organization's motivation for protecting data. Taxonomy might capture compliance requirements, promised features for workload users, or other criteria driven by business needs.
20
+
21
+
As a workload owner, rely on your organization to provide a well-defined taxonomy. All workload roles must have a shared understanding of the structure, nomenclature, and definition of the sensitivity levels. Don't define your own classification system that conflicts with organizational standards.
22
+
19
23
Your classification scheme should:
20
24
21
25
-**Align with business requirements**: Classifications should reflect how your organization thinks about data sensitivity
22
26
-**Support regulatory compliance**: Include classifications that map to GDPR, HIPAA, PCI-DSS, and other relevant regulations
23
27
-**Enable automation**: Design classifications that can be applied automatically based on content patterns
24
28
-**Scale across the organization**: Use consistent classifications that work for all business units
25
29
26
-
The WAF Security pillar recommends defining data classifications that enable risk-based controls. Common classification levels include:
30
+
The WAF Security pillar recommends defining data classifications that enable risk-based controls. Example classification labels cover sensitivity levels, information types, and compliance scope:
31
+
32
+
| Category | Example labels |
33
+
|----------|----------------|
34
+
|**Sensitivity levels**| Public, General, Confidential, Highly Confidential, Secret |
35
+
|**Information types**| Financial, Credit Card, Credentials, Health fields, Intellectual Property, Personal data |
36
+
|**Compliance scope**| HIPAA, PCI, CCPA, SOX |
37
+
38
+
### Defining classification scope
39
+
40
+
Be granular and explicit when defining what's in scope for classification. The WAF Security pillar emphasizes that classification should extend beyond primary data stores to related components:
41
+
42
+
-**Data store granularity**: Classify at the table level or even column level for tabular systems
43
+
-**Backup systems**: Has your highly sensitive data store's backup been classified?
44
+
-**Caching layers**: If you're caching user-sensitive data, is the cache in scope?
45
+
-**Analytical data stores**: How is aggregated or derived data classified?
46
+
-**Preproduction environments**: Do you need to classify data in development and test systems?
47
+
48
+
Start with these questions to define your scope:
49
+
50
+
1. What's the origin of data and information type?
51
+
2. What's the expected restriction based on access (public, regulatory, internal use)?
52
+
3. What's the data footprint—where is it stored and how long should it be retained?
53
+
4. Which architecture components interact with the data?
54
+
5. How does data move through the system?
55
+
6. What information is expected in audit reports?
56
+
57
+
### Designing architecture based on classification labels
58
+
59
+
Classification should influence your architectural decisions. The WAF Security pillar identifies key areas where classification drives design:
27
60
28
-
| Classification | Description | Example controls |
|**Public**| Information intended for public disclosure | No restrictions |
31
-
|**Internal**| Information for internal business use | Basic access controls |
32
-
|**Confidential**| Sensitive business information | Encryption, restricted access |
33
-
|**Highly Confidential**| Most sensitive data | Strong encryption, audit logging, DLP |
61
+
**Segmentation strategy**: Classification labels influence traffic isolation boundaries. Critical flows might require end-to-end TLS, while other traffic can use different encryption standards.
- Highly sensitive data might require double encryption
65
+
- Different secrets might require varied levels of protection (HSM vs. standard secret stores)
66
+
- Compliance labels dictate protection standards (for example, PCI-DSS mandates FIPS 140-2 Level 3, requiring HSMs)
67
+
68
+
**Data in use protection**: For the most sensitive classifications, consider confidential computing to protect data during processing.
69
+
70
+
**Classification persistence**: Classification information should move with the data as it transitions through the system. Data labeled as confidential should be treated as confidential by all components that interact with it—including removing or obfuscating personal data from application logs.
71
+
72
+
**Reporting and masking**: Classification impacts how data is exposed in reports. Based on information type labels, you might need to apply data masking algorithms for obfuscation. Define which roles should have visibility into raw data versus masked data.
34
73
35
74
### Sensitive information type detection
36
75
@@ -110,18 +149,6 @@ For Azure workloads, [Microsoft Defender for Cloud](/azure/defender-for-cloud/de
110
149
-**Built-in recommendations**: Suggested classifications based on column names and data patterns
111
150
-**Microsoft Purview integration**: Sync classifications with your enterprise labeling strategy
112
151
113
-
## Design recommendations
114
-
115
-
When designing your data discovery and classification solution:
116
-
117
-
1.**Start with data governance goals**: Define what you're trying to protect and why before selecting tools
118
-
119
-
2.**Implement a unified classification taxonomy**: Use consistent classifications across all data sources and tools
120
-
121
-
3.**Prioritize automated discovery**: Manual processes don't scale—invest in automated scanning
122
-
123
-
4.**Integrate with protection mechanisms**: Classification provides value when it triggers protection actions
124
-
125
-
5.**Plan for multi-cloud and hybrid**: Ensure your solution covers all locations where data resides
152
+
## Bringing it together
126
153
127
-
6.**Enable monitoring and reporting**: Track classification coverage and identify gaps in your data estate
154
+
Effective data discovery and classification requires a unified organizational taxonomy applied consistently across your data estate. Start by defining what you need to protect and why, then be explicit about scope—extending classification to backups, caches, and analytical stores. Prioritize automated discovery with tools like Microsoft Purview, but validate results through manual verification. Classification provides value when it triggers protection actions, so design your architecture so that labels influence encryption choices, access controls, and segmentation. Build classification maintenance into operations, because stale metadata leads to compliance issues and erroneous risk assessments.
Copy file name to clipboardExpand all lines: learn-pr/wwl-sci/design-solutions-secure-organization-data/includes/3-design-solution-data-protection.md
+2-12Lines changed: 2 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -142,16 +142,6 @@ Labels applied through classification can trigger protection:
142
142
-**Watermarking**: Apply visual markings to indicate sensitivity
143
143
-**Expiration**: Set time limits on document access
144
144
145
-
## Design recommendations
145
+
## Bringing it together
146
146
147
-
1.**Encrypt by default**: Enable encryption for all data stores even if not explicitly required
148
-
149
-
2.**Standardize on TLS 1.2+**: Disable all legacy protocols across your environment
150
-
151
-
3.**Centralize key management**: Use Azure Key Vault for all cryptographic operations
152
-
153
-
4.**Implement key rotation**: Establish policies for regular key rotation based on compliance requirements
154
-
155
-
5.**Enable HSM protection**: Use Key Vault HSM for keys protecting the most sensitive data
156
-
157
-
6.**Document key recovery procedures**: Ensure you can recover from key loss scenarios
147
+
Effective data protection requires a defense-in-depth approach that combines encryption, access controls, network isolation, and monitoring. Encrypt all data by default—both at rest and in transit—using TLS 1.2 or higher and AES-256 encryption. Centralize key management in Azure Key Vault, using HSM protection for the most sensitive workloads and implementing key rotation policies based on compliance requirements. Classification labels should trigger protection actions through DLP policies and Azure Information Protection, ensuring that sensitivity levels drive the appropriate encryption choices and access restrictions throughout your environment.
Copy file name to clipboardExpand all lines: learn-pr/wwl-sci/design-solutions-secure-organization-data/includes/5-design-security-azure-storage.md
+2-28Lines changed: 2 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -163,32 +163,6 @@ Use immutable storage for:
163
163
- Healthcare records under HIPAA retention rules
164
164
- Legal documents subject to litigation hold
165
165
166
-
## Design recommendations for Azure Storage security
166
+
## Bringing it together
167
167
168
-
### Network security
169
-
170
-
1.**Use private endpoints** for all storage accounts containing sensitive data
171
-
2.**Disable public blob access** at the account level
172
-
3.**Configure minimum TLS 1.2** for all accounts
173
-
4.**Implement Azure Private DNS** for name resolution
174
-
175
-
### Encryption
176
-
177
-
1.**Enable infrastructure encryption** for regulated workloads
178
-
2.**Use customer-managed keys** when key control is required
179
-
3.**Configure automatic key rotation** in Key Vault
180
-
4.**Require secure transfer** (HTTPS only)
181
-
182
-
### Access control
183
-
184
-
1.**Use Microsoft Entra authentication** with RBAC
185
-
2.**Prefer user delegation SAS** over service or account SAS
186
-
3.**Disable shared key access** when not needed
187
-
4.**Implement just-in-time access** for administrative tasks
188
-
189
-
### Monitoring
190
-
191
-
1.**Enable Microsoft Defender for Storage** on all accounts
192
-
2.**Configure diagnostic logging** to Log Analytics
193
-
3.**Set up alerts** for anomalous activity
194
-
4.**Implement malware scanning** for uploaded content
168
+
Securing Azure Storage requires a layered approach across network, identity, encryption, and monitoring. Use private endpoints and disable public blob access for accounts containing sensitive data. Implement Microsoft Entra authentication with RBAC, preferring user delegation SAS over shared keys. Enable infrastructure encryption with customer-managed keys for regulated workloads, and require secure transfer (HTTPS only) with TLS 1.2 minimum. Enable Microsoft Defender for Storage with malware scanning for accounts accepting uploads, and configure diagnostic logging to detect anomalous activity.
Copy file name to clipboardExpand all lines: learn-pr/wwl-sci/design-solutions-secure-organization-data/includes/6-design-security-defender-sql-storage.md
+5-39Lines changed: 5 additions & 39 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@ Microsoft Defender for Cloud provides workload protection plans specifically des
2
2
3
3
## Microsoft Defender for Storage
4
4
5
-
[Microsoft Defender for Storage](/azure/defender-for-cloud/defender-for-storage-introduction) provides a comprehensive security layer for Azure Storage accounts, detecting unusual and potentially harmful attempts to access or exploit storage resources.
5
+
[Microsoft Defender for Storage](/azure/defender-for-cloud/defender-for-storage-introduction) provides a comprehensive security layer for Azure Storage accounts, detecting unusual and potentially harmful attempts to access or exploit storage resources. This capability supports MCSB control LT-1 (Enable threat detection capabilities).
6
6
7
7
### Capabilities overview
8
8
@@ -16,7 +16,7 @@ Microsoft Defender for Storage includes three core capabilities:
16
16
17
17
### Activity monitoring
18
18
19
-
Activity monitoring analyzes storage account operations to detect:
19
+
Activity monitoring supports MCSB control DP-2 (Monitor anomalies and threats to sensitive data) by analyzing storage account operations to detect:
20
20
21
21
-**Anomalous access patterns**: Unusual geographic locations or access times
22
22
-**Permission-related anomalies**: Suspicious changes to access configurations
@@ -147,7 +147,7 @@ The MCSB recommends enabling workload protection for all production resources co
147
147
148
148
### Alert management
149
149
150
-
Plan for alert handling:
150
+
Alert management supports MCSB control IR-4 (Detection and analysis). Plan for alert handling:
151
151
152
152
1.**Define alert routing**: Configure email notifications and webhook integrations
153
153
2.**Establish response procedures**: Document investigation and remediation steps
By implementing Defender for Storage and Databases, you establish comprehensive threat detection aligned with Microsoft security best practices and industry frameworks.
176
+
Microsoft Defender for Storage and Defender for Databases provide the threat detection layer for your data security strategy. Enable subscription-wide protection for production resources, configure malware scanning for uploads, and run regular vulnerability assessments. Integrate with Microsoft Sentinel for alert correlation and automated response, establishing consistent procedures for common threats like SQL injection and access anomalies.
0 commit comments