Skip to content

Commit ee70510

Browse files
committed
move diagram
1 parent b134b46 commit ee70510

File tree

1 file changed

+61
-61
lines changed

1 file changed

+61
-61
lines changed

infra/modules/azure_storage_account/README.md

Lines changed: 61 additions & 61 deletions
Original file line numberDiff line numberDiff line change
@@ -4,67 +4,6 @@
44

55
This Terraform module provisions an Azure Storage Account with optional configurations for advanced features, networking, and monitoring.
66

7-
## Features
8-
9-
- **Use Case Profiles**: Simplifies deployment by providing pre-configured profiles (`default`, `audit`, `delegated_access`, `development`, `archive`) tailored for specific needs.
10-
- **Advanced Threat Protection**: Enables advanced threat protection for enhanced security only for public configurations.
11-
- **Advanced Security**: Enforces the use of User Delegation SAS for secure shared access if `delegated_access`.
12-
- **Data Lifecycle Management**: Includes automated policies for tiering data from Hot to Cool/Archive and setting retention periods to optimize costs.
13-
- **Private Networking**: Configures private endpoints and DNS zones for secure access.
14-
- **Blob Features**: Supports versioning, change feed, immutability policies, and more.
15-
- **Static Website Hosting**: Configures static website hosting with custom domains.
16-
- **Monitoring and Alerts**: Includes metric alerts and diagnostic settings for operational visibility.
17-
- **Customer-Managed Keys (CMK)**: Supports encryption with customer-managed keys, mandatory only for `audit` for enhanced encryption control (BYOK).
18-
19-
## Use cases Comparison
20-
21-
| Use case | Description | Alerts | Advanced Threat Protection | Replication Type | Account Tier |
22-
| ------------------ | --------------------------------------------------------------------------------------------------------------------------- | ------ | -------------------------- | ----------------------- | ------------ |
23-
| `development` | Ideal for lightweight workloads, testing, and development. | No | No | LRS | Standard |
24-
| `default` | Suitable for production with moderate to high performance needs. | Yes | No | ZRS | Standard |
25-
| `audit` | For storing audit logs with high security and long-term retention. (Blob items will be deleted after 3 yaers of inactivity) | Yes | No | ZRS + secondary replica | Standard |
26-
| `delegated_access` | For sharing files externally, forcing secure access patterns. | Yes | Yes | ZRS | Standard |
27-
| `archive` | For long-term, low-cost backup and data archiving. | No | No | LRS + secondary replica | Standard |
28-
29-
## Important Considerations for CDN Origin
30-
31-
This storage account module should **not** be used as an origin for an Azure CDN if the variable `force_public_network_access_enabled` is set to `false` (as default). Azure CDN requires the origin to be publicly accessible. For CDN setups, please refer to the dedicated [Azure CDN module](https://registry.terraform.io/modules/pagopa-dx/azure-cdn/azurerm/latest).
32-
33-
## Note about Replication
34-
35-
For use cases with `secondary replica`, the module creates a secondary storage account in the specified `secondary_location` to enable geo-redundant storage. This setup ensures data durability and availability across different geographic regions.
36-
37-
### Archive policy
38-
39-
The archive lifecycle management policy use the value `tier_to_archive_after_days_since_creation_greater_than` to move blobs to the Archive tier, but this feature is available only in some regions and only when Replication Type is `LRS`.
40-
Refer to the [Azure tabele](https://azure.microsoft.com/it-it/explore/global-infrastructure/products-by-region/table) for more details, check `Archive Storage`.
41-
42-
## Security Considerations
43-
44-
### Customer-Managed Key (BYOK) Encryption
45-
46-
For enhanced control over data encryption, this module supports **Bring Your Own Key (BYOK)**. Instead of using Microsoft-managed keys, you can provide a key from your own Azure Key Vault.
47-
48-
- The `audit` use case requires BYOK to be enabled for maximum security.
49-
- For all other use cases, this feature is optional.
50-
- To enable it, simply provide the necessary details in the `customer_managed_key` variable. The module will handle the rest, including the creation of access policies or role assignments on the Key Vault.
51-
52-
### User Delegation SAS for Secure Access
53-
54-
For the `delegated_access` use case, this module enhances security by disabling the main storage account access keys. This action has a critical consequence:
55-
56-
- It becomes impossible to create a standard Service SAS token.
57-
- The only way to generate a **Shared Access Signature (SAS)** is by using User Delegation SAS.
58-
59-
This model forces applications to first authenticate with Azure Active Directory (Azure AD) to obtain a temporary key. This is a significant security improvement because access is tied to an identity and can be centrally managed and revoked via Azure RBAC. To implement this, you must grant the Storage Blob Delegator role to the identities that need to create SAS tokens.
60-
61-
**NOTE**:
62-
Terraform uses Shared Key Authorisation to provision Storage Containers, Blobs and other items - when Shared Key Access is disabled, you will need to enable the `storage_use_azuread` flag in the Provider block to use Azure AD for authentication, however not all Azure Storage services support Active Directory authentication.
63-
64-
## Usage Example
65-
66-
A complete example of how to use this module can be found in the [example/complete](https://github.com/pagopa-dx/terraform-azurerm-azure-storage-account/tree/main/examples/complete) directory.
67-
687
## Diagram
698

709
The following diagram illustrates the architecture and relationships between the main components of this module:
@@ -126,6 +65,67 @@ flowchart LR
12665
defender -.-> sa
12766
```
12867

68+
## Features
69+
70+
- **Use Case Profiles**: Simplifies deployment by providing pre-configured profiles (`default`, `audit`, `delegated_access`, `development`, `archive`) tailored for specific needs.
71+
- **Advanced Threat Protection**: Enables advanced threat protection for enhanced security only for public configurations.
72+
- **Advanced Security**: Enforces the use of User Delegation SAS for secure shared access if `delegated_access`.
73+
- **Data Lifecycle Management**: Includes automated policies for tiering data from Hot to Cool/Archive and setting retention periods to optimize costs.
74+
- **Private Networking**: Configures private endpoints and DNS zones for secure access.
75+
- **Blob Features**: Supports versioning, change feed, immutability policies, and more.
76+
- **Static Website Hosting**: Configures static website hosting with custom domains.
77+
- **Monitoring and Alerts**: Includes metric alerts and diagnostic settings for operational visibility.
78+
- **Customer-Managed Keys (CMK)**: Supports encryption with customer-managed keys, mandatory only for `audit` for enhanced encryption control (BYOK).
79+
80+
## Use cases Comparison
81+
82+
| Use case | Description | Alerts | Advanced Threat Protection | Replication Type | Account Tier |
83+
| ------------------ | --------------------------------------------------------------------------------------------------------------------------- | ------ | -------------------------- | ----------------------- | ------------ |
84+
| `development` | Ideal for lightweight workloads, testing, and development. | No | No | LRS | Standard |
85+
| `default` | Suitable for production with moderate to high performance needs. | Yes | No | ZRS | Standard |
86+
| `audit` | For storing audit logs with high security and long-term retention. (Blob items will be deleted after 3 yaers of inactivity) | Yes | No | ZRS + secondary replica | Standard |
87+
| `delegated_access` | For sharing files externally, forcing secure access patterns. | Yes | Yes | ZRS | Standard |
88+
| `archive` | For long-term, low-cost backup and data archiving. | No | No | LRS + secondary replica | Standard |
89+
90+
## Important Considerations for CDN Origin
91+
92+
This storage account module should **not** be used as an origin for an Azure CDN if the variable `force_public_network_access_enabled` is set to `false` (as default). Azure CDN requires the origin to be publicly accessible. For CDN setups, please refer to the dedicated [Azure CDN module](https://registry.terraform.io/modules/pagopa-dx/azure-cdn/azurerm/latest).
93+
94+
## Note about Replication
95+
96+
For use cases with `secondary replica`, the module creates a secondary storage account in the specified `secondary_location` to enable geo-redundant storage. This setup ensures data durability and availability across different geographic regions.
97+
98+
### Archive policy
99+
100+
The archive lifecycle management policy use the value `tier_to_archive_after_days_since_creation_greater_than` to move blobs to the Archive tier, but this feature is available only in some regions and only when Replication Type is `LRS`.
101+
Refer to the [Azure tabele](https://azure.microsoft.com/it-it/explore/global-infrastructure/products-by-region/table) for more details, check `Archive Storage`.
102+
103+
## Security Considerations
104+
105+
### Customer-Managed Key (BYOK) Encryption
106+
107+
For enhanced control over data encryption, this module supports **Bring Your Own Key (BYOK)**. Instead of using Microsoft-managed keys, you can provide a key from your own Azure Key Vault.
108+
109+
- The `audit` use case requires BYOK to be enabled for maximum security.
110+
- For all other use cases, this feature is optional.
111+
- To enable it, simply provide the necessary details in the `customer_managed_key` variable. The module will handle the rest, including the creation of access policies or role assignments on the Key Vault.
112+
113+
### User Delegation SAS for Secure Access
114+
115+
For the `delegated_access` use case, this module enhances security by disabling the main storage account access keys. This action has a critical consequence:
116+
117+
- It becomes impossible to create a standard Service SAS token.
118+
- The only way to generate a **Shared Access Signature (SAS)** is by using User Delegation SAS.
119+
120+
This model forces applications to first authenticate with Azure Active Directory (Azure AD) to obtain a temporary key. This is a significant security improvement because access is tied to an identity and can be centrally managed and revoked via Azure RBAC. To implement this, you must grant the Storage Blob Delegator role to the identities that need to create SAS tokens.
121+
122+
**NOTE**:
123+
Terraform uses Shared Key Authorisation to provision Storage Containers, Blobs and other items - when Shared Key Access is disabled, you will need to enable the `storage_use_azuread` flag in the Provider block to use Azure AD for authentication, however not all Azure Storage services support Active Directory authentication.
124+
125+
## Usage Example
126+
127+
A complete example of how to use this module can be found in the [example/complete](https://github.com/pagopa-dx/terraform-azurerm-azure-storage-account/tree/main/examples/complete) directory.
128+
129129
<!-- BEGIN_TF_DOCS -->
130130
## Requirements
131131

0 commit comments

Comments
 (0)