docs: archive entra materials and simplify deployment docs
This commit is contained in:
defiQUG
@@ -1,354 +0,0 @@
|
||||
# Naming Convention - The Order
|
||||
|
||||
**Last Updated**: 2025-01-27
|
||||
**Status**: Standard naming convention for all Azure resources
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This document defines the standardized naming convention for all Azure resources in The Order project. The convention ensures consistency, clarity, and compliance with Azure naming requirements.
|
||||
|
||||
---
|
||||
|
||||
## Naming Pattern
|
||||
|
||||
### Format Structure
|
||||
|
||||
```
|
||||
{provider}-{region}-{resource}-{env}-{purpose}
|
||||
```
|
||||
|
||||
### Segment Definitions
|
||||
|
||||
| Segment | Description | Format | Examples |
|
||||
|---------|------------|--------|----------|
|
||||
| **provider** | Cloud provider identifier | 2-3 chars, lowercase | `az` (Azure) |
|
||||
| **region** | Azure region abbreviation | 2-3 chars, lowercase | `we` (westeurope), `ne` (northeurope) |
|
||||
| **resource** | Resource type abbreviation | 2-5 chars, lowercase | `rg` (resource group), `sa` (storage account) |
|
||||
| **env** | Environment identifier | 3-5 chars, lowercase | `dev`, `stg`, `prd` |
|
||||
| **purpose** | Resource purpose/name | 3-15 chars, lowercase, alphanumeric | `main`, `data`, `kv` (key vault) |
|
||||
|
||||
---
|
||||
|
||||
## Region Abbreviations
|
||||
|
||||
| Full Name | Abbreviation | Code |
|
||||
|-----------|--------------|------|
|
||||
| westeurope | we | `we` |
|
||||
| northeurope | ne | `ne` |
|
||||
| uksouth | uk | `uk` |
|
||||
| switzerlandnorth | ch | `ch` |
|
||||
| norwayeast | no | `no` |
|
||||
| francecentral | fr | `fr` |
|
||||
| germanywestcentral | de | `de` |
|
||||
|
||||
**Rule**: Use first 2 letters of country code or region identifier.
|
||||
|
||||
---
|
||||
|
||||
## Resource Type Abbreviations
|
||||
|
||||
| Resource Type | Abbreviation | Azure Limit | Example |
|
||||
|---------------|--------------|-------------|---------|
|
||||
| Resource Group | `rg` | 90 chars | `az-we-rg-dev-main` |
|
||||
| Storage Account | `sa` | 24 chars, alphanumeric | `azwesadevdata` |
|
||||
| Key Vault | `kv` | 24 chars, alphanumeric | `az-we-kv-dev-main` |
|
||||
| AKS Cluster | `aks` | 63 chars | `az-we-aks-dev-main` |
|
||||
| Container Registry | `acr` | 50 chars, alphanumeric | `azweacrdev` |
|
||||
| PostgreSQL Server | `psql` | 63 chars | `az-we-psql-dev-main` |
|
||||
| Database | `db` | 63 chars | `az-we-db-dev-main` |
|
||||
| Virtual Network | `vnet` | 64 chars | `az-we-vnet-dev-main` |
|
||||
| Subnet | `snet` | 80 chars | `az-we-snet-dev-main` |
|
||||
| Network Security Group | `nsg` | 80 chars | `az-we-nsg-dev-main` |
|
||||
| Public IP | `pip` | 80 chars | `az-we-pip-dev-main` |
|
||||
| Load Balancer | `lb` | 80 chars | `az-we-lb-dev-main` |
|
||||
| Application Gateway | `agw` | 80 chars | `az-we-agw-dev-main` |
|
||||
| Log Analytics Workspace | `law` | 63 chars | `az-we-law-dev-main` |
|
||||
| Application Insights | `appi` | 255 chars | `az-we-appi-dev-main` |
|
||||
| Managed Identity | `mi` | 128 chars | `az-we-mi-dev-main` |
|
||||
| Service Principal | `sp` | N/A | `az-we-sp-dev-main` |
|
||||
|
||||
---
|
||||
|
||||
## Environment Abbreviations
|
||||
|
||||
| Environment | Abbreviation | Usage |
|
||||
|-------------|--------------|-------|
|
||||
| Development | `dev` | Development environment |
|
||||
| Staging | `stg` | Pre-production testing |
|
||||
| Production | `prd` | Production environment |
|
||||
| Management | `mgmt` | Management/infrastructure |
|
||||
|
||||
---
|
||||
|
||||
## Purpose Identifiers
|
||||
|
||||
| Purpose | Identifier | Usage |
|
||||
|---------|------------|-------|
|
||||
| Main application | `main` | Primary application resources |
|
||||
| Data storage | `data` | Application data storage |
|
||||
| State/Backend | `state` | Terraform state, backend storage |
|
||||
| Secrets | `sec` | Key Vault, secrets management |
|
||||
| Monitoring | `mon` | Monitoring and logging |
|
||||
| Network | `net` | Networking resources |
|
||||
| Compute | `cmp` | Compute resources (VMs, AKS) |
|
||||
| Database | `db` | Database resources |
|
||||
| Container | `cnt` | Container registry |
|
||||
|
||||
---
|
||||
|
||||
## Naming Examples
|
||||
|
||||
### Resource Groups
|
||||
|
||||
```
|
||||
az-we-rg-dev-main # Main development resource group
|
||||
az-we-rg-stg-main # Main staging resource group
|
||||
az-we-rg-prd-main # Main production resource group
|
||||
az-we-rg-mgmt-state # Management resource group for Terraform state
|
||||
```
|
||||
|
||||
### Storage Accounts
|
||||
|
||||
```
|
||||
azwesadevdata # Development data storage (24 chars max)
|
||||
azwesastgdata # Staging data storage
|
||||
azwesaprddata # Production data storage
|
||||
azwesamgmtstate # Terraform state storage
|
||||
```
|
||||
|
||||
### Key Vaults
|
||||
|
||||
```
|
||||
az-we-kv-dev-main # Development Key Vault
|
||||
az-we-kv-stg-main # Staging Key Vault
|
||||
az-we-kv-prd-main # Production Key Vault
|
||||
az-we-kv-mgmt-sec # Management Key Vault
|
||||
```
|
||||
|
||||
### AKS Clusters
|
||||
|
||||
```
|
||||
az-we-aks-dev-main # Development AKS cluster
|
||||
az-we-aks-stg-main # Staging AKS cluster
|
||||
az-we-aks-prd-main # Production AKS cluster
|
||||
```
|
||||
|
||||
### Container Registries
|
||||
|
||||
```
|
||||
azweacrdev # Development ACR (alphanumeric only)
|
||||
azweacrstg # Staging ACR
|
||||
azweacrprd # Production ACR
|
||||
```
|
||||
|
||||
### PostgreSQL Servers
|
||||
|
||||
```
|
||||
az-we-psql-dev-main # Development PostgreSQL server
|
||||
az-we-psql-stg-main # Staging PostgreSQL server
|
||||
az-we-psql-prd-main # Production PostgreSQL server
|
||||
```
|
||||
|
||||
### Databases
|
||||
|
||||
```
|
||||
az-we-db-dev-main # Development database
|
||||
az-we-db-stg-main # Staging database
|
||||
az-we-db-prd-main # Production database
|
||||
```
|
||||
|
||||
### Virtual Networks
|
||||
|
||||
```
|
||||
az-we-vnet-dev-main # Development virtual network
|
||||
az-we-vnet-stg-main # Staging virtual network
|
||||
az-we-vnet-prd-main # Production virtual network
|
||||
```
|
||||
|
||||
### Application Insights
|
||||
|
||||
```
|
||||
az-we-appi-dev-main # Development Application Insights
|
||||
az-we-appi-stg-main # Staging Application Insights
|
||||
az-we-appi-prd-main # Production Application Insights
|
||||
```
|
||||
|
||||
### Log Analytics Workspaces
|
||||
|
||||
```
|
||||
az-we-law-dev-main # Development Log Analytics workspace
|
||||
az-we-law-stg-main # Staging Log Analytics workspace
|
||||
az-we-law-prd-main # Production Log Analytics workspace
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Special Cases
|
||||
|
||||
### Storage Account Naming
|
||||
|
||||
Storage accounts have strict requirements:
|
||||
- **Max length**: 24 characters
|
||||
- **Allowed characters**: Lowercase letters and numbers only
|
||||
- **No hyphens**: Must be alphanumeric only
|
||||
|
||||
**Pattern**: `{provider}{region}{resource}{env}{purpose}`
|
||||
|
||||
Example: `azwesadevdata` (az + we + sa + dev + data)
|
||||
|
||||
### Container Registry Naming
|
||||
|
||||
ACR names have requirements:
|
||||
- **Max length**: 50 characters
|
||||
- **Allowed characters**: Alphanumeric only
|
||||
- **No hyphens**: Must be alphanumeric only
|
||||
|
||||
**Pattern**: `{provider}{region}{resource}{env}`
|
||||
|
||||
Example: `azweacrdev` (az + we + acr + dev)
|
||||
|
||||
### Key Vault Naming
|
||||
|
||||
Key Vault names:
|
||||
- **Max length**: 24 characters
|
||||
- **Allowed characters**: Alphanumeric and hyphens
|
||||
- **Must be globally unique**
|
||||
|
||||
**Pattern**: `{provider}-{region}-{resource}-{env}-{purpose}`
|
||||
|
||||
Example: `az-we-kv-dev-main`
|
||||
|
||||
---
|
||||
|
||||
## Kubernetes Resources
|
||||
|
||||
### Namespaces
|
||||
|
||||
```
|
||||
the-order-dev # Development namespace
|
||||
the-order-stg # Staging namespace
|
||||
the-order-prd # Production namespace
|
||||
```
|
||||
|
||||
### Service Names
|
||||
|
||||
```
|
||||
identity # Identity service
|
||||
intake # Intake service
|
||||
finance # Finance service
|
||||
dataroom # Dataroom service
|
||||
portal-public # Public portal
|
||||
portal-internal # Internal portal
|
||||
```
|
||||
|
||||
### Deployment Names
|
||||
|
||||
```
|
||||
identity # Identity deployment
|
||||
intake # Intake deployment
|
||||
finance # Finance deployment
|
||||
dataroom # Dataroom deployment
|
||||
portal-public # Public portal deployment
|
||||
portal-internal # Internal portal deployment
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Tags
|
||||
|
||||
All resources must include the following tags:
|
||||
|
||||
| Tag Key | Value | Example |
|
||||
|---------|-------|---------|
|
||||
| `Environment` | Environment name | `dev`, `stg`, `prd` |
|
||||
| `Project` | Project identifier | `the-order` |
|
||||
| `Region` | Azure region | `westeurope` |
|
||||
| `ManagedBy` | Management tool | `Terraform`, `Manual` |
|
||||
| `CostCenter` | Cost allocation | `engineering` |
|
||||
| `Owner` | Resource owner | `platform-team` |
|
||||
|
||||
---
|
||||
|
||||
## Naming Validation
|
||||
|
||||
### Terraform Validation
|
||||
|
||||
All resource names should be validated in Terraform:
|
||||
|
||||
```hcl
|
||||
variable "resource_name" {
|
||||
type = string
|
||||
validation {
|
||||
condition = can(regex("^az-[a-z]{2}-[a-z]{2,5}-[a-z]{3,5}-[a-z]{3,15}$", var.resource_name))
|
||||
error_message = "Resource name must follow pattern: az-{region}-{resource}-{env}-{purpose}"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Script Validation
|
||||
|
||||
Deployment scripts should validate names:
|
||||
|
||||
```bash
|
||||
validate_name() {
|
||||
local name=$1
|
||||
local pattern="^az-[a-z]{2}-[a-z]{2,5}-[a-z]{3,5}-[a-z]{3,15}$"
|
||||
if [[ ! $name =~ $pattern ]]; then
|
||||
echo "Invalid name format: $name"
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Migration Guide
|
||||
|
||||
### Current Naming → New Naming
|
||||
|
||||
| Current | New | Notes |
|
||||
|---------|-----|-------|
|
||||
| `the-order-dev-rg` | `az-we-rg-dev-main` | Add provider and region |
|
||||
| `theorderdevdata` | `azwesadevdata` | Storage account (no hyphens) |
|
||||
| `the-order-dev-kv` | `az-we-kv-dev-main` | Add provider and region |
|
||||
| `the-order-dev-aks` | `az-we-aks-dev-main` | Add provider and region |
|
||||
|
||||
---
|
||||
|
||||
## Implementation Checklist
|
||||
|
||||
- [ ] Update Terraform variables to use new naming
|
||||
- [ ] Update deployment scripts (`config.sh`)
|
||||
- [ ] Update all Terraform resource definitions
|
||||
- [ ] Update documentation
|
||||
- [ ] Migrate existing resources (if applicable)
|
||||
- [ ] Validate all names meet Azure requirements
|
||||
- [ ] Update CI/CD pipelines
|
||||
- [ ] Update monitoring and alerting
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Consistency**: Always use the same pattern across all resources
|
||||
2. **Clarity**: Names should be self-documenting
|
||||
3. **Length**: Keep names as short as possible while maintaining clarity
|
||||
4. **Uniqueness**: Ensure names are unique within Azure subscription
|
||||
5. **Validation**: Always validate names before resource creation
|
||||
6. **Documentation**: Document any deviations from the standard
|
||||
7. **Tags**: Use tags for additional metadata, not names
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- [Azure Naming Conventions](https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/naming-and-tagging)
|
||||
- [Azure Resource Naming Rules](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/resource-name-rules)
|
||||
- [Terraform Azure Provider Documentation](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs)
|
||||
|
||||
---
|
||||
|
||||
**Status**: ✅ Standard naming convention defined and ready for implementation
|
||||
|
||||
@@ -1,172 +0,0 @@
|
||||
# Naming Convention Implementation Summary
|
||||
|
||||
**Last Updated**: 2025-01-27
|
||||
**Status**: ✅ Complete
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The standardized naming convention has been fully implemented across The Order project. All Azure resources now follow the pattern:
|
||||
|
||||
```
|
||||
{provider}-{region}-{resource}-{env}-{purpose}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Implementation Status
|
||||
|
||||
### ✅ Completed
|
||||
|
||||
1. **Naming Convention Document** (`docs/governance/NAMING_CONVENTION.md`)
|
||||
- Comprehensive naming rules and patterns
|
||||
- Region abbreviations
|
||||
- Resource type abbreviations
|
||||
- Environment abbreviations
|
||||
- Purpose identifiers
|
||||
- Examples for all resource types
|
||||
|
||||
2. **Terraform Implementation**
|
||||
- ✅ Created `locals.tf` with centralized naming functions
|
||||
- ✅ Updated `resource-groups.tf` to use new naming
|
||||
- ✅ Updated `storage.tf` to use new naming (with special rules)
|
||||
- ✅ Updated `outputs.tf` with naming convention outputs
|
||||
- ✅ Updated `variables.tf` with region validation
|
||||
- ✅ Updated `versions.tf` backend comments
|
||||
|
||||
3. **Deployment Scripts**
|
||||
- ✅ Updated `scripts/deploy/config.sh` with naming functions
|
||||
- ✅ Added region abbreviation mapping
|
||||
- ✅ Added environment abbreviation mapping
|
||||
- ✅ All resource names now use new convention
|
||||
|
||||
4. **Documentation**
|
||||
- ✅ Updated deployment guide with naming convention reference
|
||||
- ✅ Created naming validation document
|
||||
- ✅ All examples updated
|
||||
|
||||
---
|
||||
|
||||
## Naming Examples
|
||||
|
||||
### Resource Groups
|
||||
- **Old**: `the-order-dev-rg`
|
||||
- **New**: `az-we-rg-dev-main`
|
||||
|
||||
### Storage Accounts
|
||||
- **Old**: `theorderdevdata`
|
||||
- **New**: `azwesadevdata` (alphanumeric only, max 24 chars)
|
||||
|
||||
### Key Vaults
|
||||
- **Old**: `the-order-dev-kv`
|
||||
- **New**: `az-we-kv-dev-main` (max 24 chars)
|
||||
|
||||
### AKS Clusters
|
||||
- **Old**: `the-order-dev-aks`
|
||||
- **New**: `az-we-aks-dev-main`
|
||||
|
||||
### Container Registries
|
||||
- **Old**: `theorderacr`
|
||||
- **New**: `azweacrdev` (alphanumeric only, max 50 chars)
|
||||
|
||||
---
|
||||
|
||||
## Key Features
|
||||
|
||||
### Centralized Naming
|
||||
|
||||
All naming logic is centralized in `infra/terraform/locals.tf`:
|
||||
|
||||
```hcl
|
||||
locals {
|
||||
provider = "az"
|
||||
region_short = "we" # westeurope
|
||||
env_short = "dev"
|
||||
|
||||
rg_name = "${local.provider}-${local.region_short}-rg-${local.env_short}-main"
|
||||
sa_data_name = "${local.provider}${local.region_short}sa${local.env_short}data"
|
||||
# ... etc
|
||||
}
|
||||
```
|
||||
|
||||
### Automatic Abbreviations
|
||||
|
||||
Region and environment abbreviations are automatically calculated:
|
||||
|
||||
- `westeurope` → `we`
|
||||
- `northeurope` → `ne`
|
||||
- `uksouth` → `uk`
|
||||
- `dev` → `dev`
|
||||
- `stage` → `stg`
|
||||
- `prod` → `prd`
|
||||
|
||||
### Validation
|
||||
|
||||
Terraform variables include validation:
|
||||
|
||||
```hcl
|
||||
validation {
|
||||
condition = contains([
|
||||
"westeurope", "northeurope", "uksouth", ...
|
||||
], var.azure_region)
|
||||
error_message = "Region must be one of the supported non-US regions."
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Usage
|
||||
|
||||
### In Terraform
|
||||
|
||||
```hcl
|
||||
resource "azurerm_resource_group" "main" {
|
||||
name = local.rg_name # az-we-rg-dev-main
|
||||
location = var.azure_region
|
||||
}
|
||||
```
|
||||
|
||||
### In Deployment Scripts
|
||||
|
||||
```bash
|
||||
# Automatically calculated from environment variables
|
||||
readonly RESOURCE_GROUP_NAME="${NAME_PREFIX}-rg-${ENV_SHORT}-main"
|
||||
# Result: az-we-rg-dev-main
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Benefits
|
||||
|
||||
1. **Consistency**: All resources follow the same pattern
|
||||
2. **Clarity**: Names are self-documenting
|
||||
3. **Compliance**: Meets Azure naming requirements
|
||||
4. **Maintainability**: Centralized naming logic
|
||||
5. **Scalability**: Easy to add new resources
|
||||
6. **Automation**: Scripts automatically generate correct names
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
When adding new resources:
|
||||
|
||||
1. Add naming function to `locals.tf`
|
||||
2. Use the local value in resource definition
|
||||
3. Update documentation if needed
|
||||
4. Test with Terraform plan
|
||||
|
||||
---
|
||||
|
||||
## References
|
||||
|
||||
- [Naming Convention Document](./NAMING_CONVENTION.md)
|
||||
- [Terraform Locals](../infra/terraform/locals.tf)
|
||||
- [Deployment Config](../../scripts/deploy/config.sh)
|
||||
- [Naming Validation](../infra/terraform/NAMING_VALIDATION.md)
|
||||
|
||||
---
|
||||
|
||||
**Status**: ✅ Implementation complete and ready for use
|
||||
|
||||
@@ -43,8 +43,8 @@ This directory contains governance documentation, including contribution guideli
|
||||
## Related Documentation
|
||||
|
||||
- [Architecture Security](../architecture/README.md#security)
|
||||
- [Cloud for Sovereignty](../architecture/CLOUD_FOR_SOVEREIGNTY_LANDING_ZONE.md)
|
||||
- [Deployment Security](../deployment/azure/SOVEREIGNTY_LANDING_ZONE_DEPLOYMENT.md#security-features)
|
||||
- [Architecture Overview](../architecture/README.md)
|
||||
- [Deployment Overview](../deployment/overview.md)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,601 +0,0 @@
|
||||
# Technical Integration Plan
|
||||
## Governance Tasks Integration with The Order Platform
|
||||
|
||||
**Last Updated**: 2024-12-28
|
||||
**Purpose**: Map governance tasks to technical implementation requirements
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
This document maps the governance and legal transition tasks to technical features and implementations required in The Order platform to support the Order of Military Hospitallers, International Criminal Court of Commerce, and DBIS operations.
|
||||
|
||||
---
|
||||
|
||||
## I. Document Management & Registry Systems
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 3.1**: Tribunal Constitution & Charter
|
||||
**Task 3.2**: Articles of Amendment
|
||||
**Task 4.3**: Rules of Procedure
|
||||
**Task 6.2**: Protectorate Mandates
|
||||
**Task 11.1-11.6**: Policy Documents
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Document storage (S3/GCS with WORM mode)
|
||||
- ✅ Document ingestion service
|
||||
- ✅ OCR processing
|
||||
- ✅ Document classification
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 1.1**: Legal Document Registry
|
||||
- **Service**: Dataroom Service (enhanced)
|
||||
- **Features**:
|
||||
- Version control for legal documents
|
||||
- Digital signatures and verification
|
||||
- Document lifecycle management
|
||||
- Access control by role (Registrar, Judicial, etc.)
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 4-6 weeks
|
||||
|
||||
- [ ] **Feature 1.2**: Treaty Register System
|
||||
- **Service**: New service or Dataroom enhancement
|
||||
- **Features**:
|
||||
- Database of 110+ nation relationships
|
||||
- Treaty document storage
|
||||
- Relationship mapping
|
||||
- Search and retrieval
|
||||
- **Priority**: Medium (Task 15.1)
|
||||
- **Estimated Effort**: 8-12 weeks
|
||||
|
||||
- [ ] **Feature 1.3**: Digital Registry of Diplomatic Missions
|
||||
- **Service**: Identity Service (enhanced)
|
||||
- **Features**:
|
||||
- Mission registration
|
||||
- Credential management
|
||||
- Status tracking
|
||||
- Integration with Identity Service
|
||||
- **Priority**: Medium (Task 10.3)
|
||||
- **Estimated Effort**: 4-6 weeks
|
||||
|
||||
---
|
||||
|
||||
## II. Identity & Credential Management
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 4.2**: Appoint key judicial positions
|
||||
**Task 8.1-8.3**: Appoint DBIS leadership
|
||||
**Task 10.2**: Issue Letters of Credence
|
||||
**Task 12.2**: Appoint auditors
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Verifiable Credential issuance (KMS-based)
|
||||
- ✅ Microsoft Entra VerifiedID integration
|
||||
- ✅ eIDAS verification
|
||||
- ✅ DID support
|
||||
- ✅ JWT authentication
|
||||
- ✅ Role-based access control
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 2.1**: Judicial Credential System
|
||||
- **Service**: Identity Service
|
||||
- **Features**:
|
||||
- Specialized VC types for judicial roles
|
||||
- Registrar credentials
|
||||
- Judicial Auditor credentials
|
||||
- Provost Marshal credentials
|
||||
- Credential revocation workflows
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 6-8 weeks
|
||||
|
||||
- [ ] **Feature 2.2**: Diplomatic Credential Management
|
||||
- **Service**: Identity Service
|
||||
- **Features**:
|
||||
- Letters of Credence issuance
|
||||
- Diplomatic status tracking
|
||||
- Credential verification
|
||||
- Integration with Entra VerifiedID
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 4-6 weeks
|
||||
|
||||
- [ ] **Feature 2.3**: Appointment Tracking System
|
||||
- **Service**: New service or Database enhancement
|
||||
- **Features**:
|
||||
- Appointment records
|
||||
- Role assignments
|
||||
- Term tracking
|
||||
- Succession planning
|
||||
- **Priority**: Medium
|
||||
- **Estimated Effort**: 3-4 weeks
|
||||
|
||||
---
|
||||
|
||||
## III. Financial Infrastructure (DBIS)
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 7.1**: Form DBIS as FMI
|
||||
**Task 7.2**: Adopt PFMI standards
|
||||
**Task 7.4**: Payment rails and ISO 20022
|
||||
**Task 7.5**: Cross-border compliance (AML/CFT, GDPR, NIST/DORA)
|
||||
**Task 8.1-8.3**: Appoint financial leadership
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Payment gateway (Stripe)
|
||||
- ✅ Ledger system
|
||||
- ✅ Payment processing
|
||||
- ✅ Basic financial records
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 3.1**: ISO 20022 Payment Message Processing
|
||||
- **Service**: Finance Service (enhanced)
|
||||
- **Features**:
|
||||
- ISO 20022 message parsing
|
||||
- Payment instruction processing
|
||||
- Settlement workflows
|
||||
- Message validation
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
- [ ] **Feature 3.2**: AML/CFT Compliance System
|
||||
- **Service**: New Compliance Service
|
||||
- **Features**:
|
||||
- Transaction monitoring
|
||||
- Suspicious activity detection
|
||||
- KYC/KYB workflows
|
||||
- Sanctions screening
|
||||
- Reporting and alerting
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 16-24 weeks
|
||||
|
||||
- [ ] **Feature 3.3**: PFMI Compliance Framework
|
||||
- **Service**: Finance Service + Monitoring
|
||||
- **Features**:
|
||||
- Risk management metrics
|
||||
- Settlement finality tracking
|
||||
- Operational resilience monitoring
|
||||
- Compliance reporting
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
- [ ] **Feature 3.4**: Digital Asset Custody
|
||||
- **Service**: New Custody Service
|
||||
- **Features**:
|
||||
- Multi-signature wallets
|
||||
- Cold storage integration
|
||||
- Asset tracking
|
||||
- Collateral management
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 16-20 weeks
|
||||
|
||||
- [ ] **Feature 3.5**: Cross-border Payment Rails
|
||||
- **Service**: Finance Service (enhanced)
|
||||
- **Features**:
|
||||
- Multi-currency support
|
||||
- FX conversion
|
||||
- Correspondent banking integration
|
||||
- Real-time gross settlement (RTGS)
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 20-24 weeks
|
||||
|
||||
---
|
||||
|
||||
## IV. Judicial & Tribunal Systems
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 4.1**: Three-tier court governance
|
||||
**Task 4.3**: Rules of Procedure
|
||||
**Task 4.4**: File Rules & Jurisdictional Charter
|
||||
**Task 5.1**: Provost Marshal General Office
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Basic service architecture
|
||||
- ✅ API documentation (Swagger)
|
||||
- ✅ Authentication and authorization
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 4.1**: Case Management System
|
||||
- **Service**: New Tribunal Service
|
||||
- **Features**:
|
||||
- Case filing and registration
|
||||
- Document management per case
|
||||
- Hearing scheduling
|
||||
- Decision tracking
|
||||
- Appeal workflows
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 16-20 weeks
|
||||
|
||||
- [ ] **Feature 4.2**: Rules of Procedure Engine
|
||||
- **Service**: Tribunal Service
|
||||
- **Features**:
|
||||
- Rule-based workflow engine
|
||||
- Procedure automation
|
||||
- Deadline tracking
|
||||
- Notification system
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
- [ ] **Feature 4.3**: Enforcement Order System
|
||||
- **Service**: Tribunal Service + Dataroom
|
||||
- **Features**:
|
||||
- Order issuance
|
||||
- Service of process tracking
|
||||
- Enforcement status
|
||||
- Integration with Provost Marshal
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 8-12 weeks
|
||||
|
||||
- [ ] **Feature 4.4**: Judicial Governance Portal
|
||||
- **Service**: New Portal Application
|
||||
- **Features**:
|
||||
- Judicial Council dashboard
|
||||
- Registrar's Office interface
|
||||
- Ethics Commission tools
|
||||
- Reporting and analytics
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
---
|
||||
|
||||
## V. Compliance & Risk Management
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 11.1**: AML/CFT Policy
|
||||
**Task 11.2**: Cybersecurity Policy
|
||||
**Task 11.3**: Data Protection Policy
|
||||
**Task 12.1**: Three Lines of Defense Model
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Basic monitoring (OpenTelemetry, Prometheus)
|
||||
- ✅ Security middleware (Helmet, CORS, Rate limiting)
|
||||
- ✅ Environment variable validation
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 5.1**: Compliance Management System
|
||||
- **Service**: New Compliance Service
|
||||
- **Features**:
|
||||
- Policy document management
|
||||
- Compliance checklist tracking
|
||||
- Audit trail
|
||||
- Violation tracking
|
||||
- Remediation workflows
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
- [ ] **Feature 5.2**: Risk Management Dashboard
|
||||
- **Service**: Monitoring Service (enhanced)
|
||||
- **Features**:
|
||||
- Risk metrics aggregation
|
||||
- Three Lines of Defense reporting
|
||||
- Risk heat maps
|
||||
- Alerting and notifications
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 8-12 weeks
|
||||
|
||||
- [ ] **Feature 5.3**: Data Protection & Privacy Controls
|
||||
- **Service**: Shared middleware + Database
|
||||
- **Features**:
|
||||
- Data classification
|
||||
- Access logging
|
||||
- Right to erasure workflows
|
||||
- Data retention policies
|
||||
- Consent management
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 10-14 weeks
|
||||
|
||||
- [ ] **Feature 5.4**: Cybersecurity Monitoring & Response
|
||||
- **Service**: Monitoring Service (enhanced)
|
||||
- **Features**:
|
||||
- Threat detection
|
||||
- Incident response workflows
|
||||
- Security event correlation
|
||||
- Vulnerability management
|
||||
- Penetration testing integration
|
||||
- **Priority**: Critical
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
---
|
||||
|
||||
## VI. Diplomatic & Mission Infrastructure
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 10.1**: Chancellery of International Affairs
|
||||
**Task 10.2**: Letters of Credence
|
||||
**Task 5.2**: Diplomatic Security Services
|
||||
**Task 6.1**: Protectorates
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Identity service with VC issuance
|
||||
- ✅ Document storage
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 6.1**: Chancellery Management System
|
||||
- **Service**: New Chancellery Service
|
||||
- **Features**:
|
||||
- Mission registration
|
||||
- Diplomatic status management
|
||||
- Communication workflows
|
||||
- Archive management
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 10-14 weeks
|
||||
|
||||
- [ ] **Feature 6.2**: Protectorate Management System
|
||||
- **Service**: New Protectorate Service
|
||||
- **Features**:
|
||||
- Protectorate registration
|
||||
- Case assignment
|
||||
- Mandate tracking
|
||||
- Reporting and compliance
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
- [ ] **Feature 6.3**: Security Services Portal
|
||||
- **Service**: New Security Service
|
||||
- **Features**:
|
||||
- DSS operations dashboard
|
||||
- Incident reporting
|
||||
- Access control management
|
||||
- Security audit logs
|
||||
- **Priority**: Medium
|
||||
- **Estimated Effort**: 8-12 weeks
|
||||
|
||||
---
|
||||
|
||||
## VII. Workflow & Process Automation
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 4.3**: Rules of Procedure
|
||||
**Task 6.3**: Compliance Warrants procedure
|
||||
**Task 13.3**: Model Arbitration Clause
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Basic workflow definitions (intake, review)
|
||||
- ✅ Azure Logic Apps connector
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 7.1**: Advanced Workflow Engine
|
||||
- **Service**: Workflows package (enhanced)
|
||||
- **Features**:
|
||||
- Complex multi-step workflows
|
||||
- Human-in-the-loop steps
|
||||
- Conditional branching
|
||||
- Integration with Temporal or Step Functions
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 16-20 weeks
|
||||
|
||||
- [ ] **Feature 7.2**: Compliance Warrants System
|
||||
- **Service**: Compliance Service
|
||||
- **Features**:
|
||||
- Warrant issuance
|
||||
- Investigation tracking
|
||||
- Audit workflows
|
||||
- Reporting
|
||||
- **Priority**: Medium
|
||||
- **Estimated Effort**: 8-12 weeks
|
||||
|
||||
- [ ] **Feature 7.3**: Arbitration Clause Generator
|
||||
- **Service**: Tribunal Service
|
||||
- **Features**:
|
||||
- Template management
|
||||
- Clause generation
|
||||
- Customization options
|
||||
- Document export
|
||||
- **Priority**: Medium
|
||||
- **Estimated Effort**: 4-6 weeks
|
||||
|
||||
---
|
||||
|
||||
## VIII. Reporting & Analytics
|
||||
|
||||
### Requirements from Governance Tasks
|
||||
|
||||
**Task 12.1**: Three Lines of Defense reporting
|
||||
**Task 7.3**: Governance committee reporting
|
||||
**Task 11.1-11.6**: Policy compliance reporting
|
||||
|
||||
### Technical Implementation
|
||||
|
||||
#### Current Status
|
||||
- ✅ Basic Prometheus metrics
|
||||
- ✅ OpenTelemetry tracing
|
||||
|
||||
#### Required Enhancements
|
||||
- [ ] **Feature 8.1**: Comprehensive Reporting System
|
||||
- **Service**: New Reporting Service
|
||||
- **Features**:
|
||||
- Custom report builder
|
||||
- Scheduled reports
|
||||
- Dashboard creation
|
||||
- Data export (PDF, Excel, CSV)
|
||||
- **Priority**: High
|
||||
- **Estimated Effort**: 12-16 weeks
|
||||
|
||||
- [ ] **Feature 8.2**: Governance Analytics Dashboard
|
||||
- **Service**: Monitoring Service (enhanced)
|
||||
- **Features**:
|
||||
- Committee metrics
|
||||
- Compliance scores
|
||||
- Risk indicators
|
||||
- Trend analysis
|
||||
- **Priority**: Medium
|
||||
- **Estimated Effort**: 8-12 weeks
|
||||
|
||||
---
|
||||
|
||||
## Implementation Priority Matrix
|
||||
|
||||
### Critical Path (Must Have for Launch)
|
||||
|
||||
1. **Feature 1.1**: Legal Document Registry
|
||||
2. **Feature 2.1**: Judicial Credential System
|
||||
3. **Feature 3.1**: ISO 20022 Payment Processing
|
||||
4. **Feature 3.2**: AML/CFT Compliance System
|
||||
5. **Feature 4.1**: Case Management System
|
||||
6. **Feature 4.2**: Rules of Procedure Engine
|
||||
7. **Feature 5.1**: Compliance Management System
|
||||
8. **Feature 5.3**: Data Protection Controls
|
||||
|
||||
### High Priority (Needed Soon After Launch)
|
||||
|
||||
1. **Feature 1.2**: Treaty Register System
|
||||
2. **Feature 2.2**: Diplomatic Credential Management
|
||||
3. **Feature 3.3**: PFMI Compliance Framework
|
||||
4. **Feature 3.5**: Cross-border Payment Rails
|
||||
5. **Feature 4.3**: Enforcement Order System
|
||||
6. **Feature 4.4**: Judicial Governance Portal
|
||||
7. **Feature 6.1**: Chancellery Management System
|
||||
8. **Feature 6.2**: Protectorate Management System
|
||||
|
||||
### Medium Priority (Enhancement Features)
|
||||
|
||||
1. **Feature 1.3**: Digital Registry of Diplomatic Missions
|
||||
2. **Feature 2.3**: Appointment Tracking System
|
||||
3. **Feature 3.4**: Digital Asset Custody
|
||||
4. **Feature 5.2**: Risk Management Dashboard
|
||||
5. **Feature 5.4**: Cybersecurity Monitoring
|
||||
6. **Feature 6.3**: Security Services Portal
|
||||
7. **Feature 7.1**: Advanced Workflow Engine
|
||||
8. **Feature 7.2**: Compliance Warrants System
|
||||
9. **Feature 8.1**: Comprehensive Reporting System
|
||||
|
||||
### Low Priority (Future Enhancements)
|
||||
|
||||
1. **Feature 7.3**: Arbitration Clause Generator
|
||||
2. **Feature 8.2**: Governance Analytics Dashboard
|
||||
|
||||
---
|
||||
|
||||
## Estimated Total Development Effort
|
||||
|
||||
### Critical Path Features
|
||||
- **Total**: 96-128 weeks (18-24 months)
|
||||
|
||||
### High Priority Features
|
||||
- **Total**: 80-104 weeks (15-20 months)
|
||||
|
||||
### Medium Priority Features
|
||||
- **Total**: 64-88 weeks (12-17 months)
|
||||
|
||||
### **Grand Total**: 240-320 weeks (46-61 months)
|
||||
|
||||
**Note**: Many features can be developed in parallel, reducing overall timeline.
|
||||
|
||||
---
|
||||
|
||||
## Integration with Existing Services
|
||||
|
||||
### Services Requiring Enhancement
|
||||
|
||||
1. **Identity Service**
|
||||
- Add judicial credential types
|
||||
- Add diplomatic credential management
|
||||
- Enhance VC issuance workflows
|
||||
|
||||
2. **Finance Service**
|
||||
- Add ISO 20022 support
|
||||
- Add AML/CFT monitoring
|
||||
- Add PFMI compliance tracking
|
||||
|
||||
3. **Dataroom Service**
|
||||
- Add legal document registry
|
||||
- Add version control
|
||||
- Add treaty register
|
||||
|
||||
4. **Intake Service**
|
||||
- Add case filing workflows
|
||||
- Add document classification for legal documents
|
||||
|
||||
### New Services Required
|
||||
|
||||
1. **Tribunal Service** (New)
|
||||
- Case management
|
||||
- Rules of procedure engine
|
||||
- Enforcement orders
|
||||
|
||||
2. **Compliance Service** (New)
|
||||
- AML/CFT monitoring
|
||||
- Compliance management
|
||||
- Risk tracking
|
||||
|
||||
3. **Chancellery Service** (New)
|
||||
- Diplomatic mission management
|
||||
- Credential issuance
|
||||
- Communication workflows
|
||||
|
||||
4. **Protectorate Service** (New)
|
||||
- Protectorate management
|
||||
- Case assignment
|
||||
- Mandate tracking
|
||||
|
||||
5. **Custody Service** (New)
|
||||
- Digital asset custody
|
||||
- Multi-signature wallets
|
||||
- Collateral management
|
||||
|
||||
---
|
||||
|
||||
## Technology Stack Recommendations
|
||||
|
||||
### For New Services
|
||||
|
||||
- **Case Management**: Consider specialized legal tech platforms or custom build
|
||||
- **Compliance Systems**: Leverage existing compliance frameworks
|
||||
- **Payment Rails**: Integrate with SWIFT, SEPA, or other payment networks
|
||||
- **Workflow Engine**: Temporal or AWS Step Functions for complex workflows
|
||||
- **Reporting**: Grafana, Metabase, or custom reporting service
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
1. **Immediate**:
|
||||
- Review and prioritize features
|
||||
- Create detailed technical specifications
|
||||
- Set up development teams
|
||||
|
||||
2. **Short-term**:
|
||||
- Begin critical path features
|
||||
- Set up development infrastructure
|
||||
- Create API specifications
|
||||
|
||||
3. **Medium-term**:
|
||||
- Parallel development of high-priority features
|
||||
- Integration testing
|
||||
- User acceptance testing
|
||||
|
||||
---
|
||||
|
||||
## Dependencies
|
||||
|
||||
### External Dependencies
|
||||
- Payment network integrations (SWIFT, SEPA, etc.)
|
||||
- Compliance data providers (sanctions lists, etc.)
|
||||
- Legal document templates
|
||||
- Regulatory guidance
|
||||
|
||||
### Internal Dependencies
|
||||
- Database schema updates
|
||||
- Authentication/authorization enhancements
|
||||
- Monitoring and observability improvements
|
||||
- Documentation updates
|
||||
|
||||
@@ -107,7 +107,7 @@ This document provides the privacy and data governance framework for the DSB, in
|
||||
**Providers:**
|
||||
* KYC providers (Veriff)
|
||||
* Sanctions providers (ComplyAdvantage)
|
||||
* Cloud providers (AWS, Azure)
|
||||
* Cloud providers (AWS, GCP, private infrastructure)
|
||||
* Email/SMS providers
|
||||
* Analytics providers
|
||||
|
||||
@@ -277,4 +277,3 @@ This document provides the privacy and data governance framework for the DSB, in
|
||||
**Chancellor:** _________________ Date: _________
|
||||
|
||||
**Founding Council:** _________________ Date: _________
|
||||
|
||||
|
||||
@@ -117,7 +117,7 @@ This document outlines the threat model for The Order monorepo, identifying pote
|
||||
- **Mitigation**:
|
||||
- Hardware Security Modules (HSM)
|
||||
- Key rotation policies
|
||||
- Secure key storage (AWS KMS, Azure Key Vault)
|
||||
- Secure key storage (AWS KMS, GCP KMS, or HSM-backed stores)
|
||||
- Access controls on key operations
|
||||
- Audit logging of key usage
|
||||
|
||||
@@ -273,6 +273,5 @@ This document outlines the threat model for The Order monorepo, identifying pote
|
||||
## References
|
||||
|
||||
- [OWASP Threat Modeling](https://owasp.org/www-community/Threat_Modeling)
|
||||
- [STRIDE Threat Model](https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats)
|
||||
- [STRIDE Threat Model](https://en.wikipedia.org/wiki/STRIDE_(security))
|
||||
- [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework)
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ This document provides a comprehensive security audit checklist for The Order mo
|
||||
## Secrets Management
|
||||
|
||||
- [ ] No hardcoded secrets in code
|
||||
- [ ] Secrets are stored in AWS Secrets Manager or Azure Key Vault
|
||||
- [ ] Secrets are stored in an approved secret manager or HSM-backed store
|
||||
- [ ] Secrets are rotated regularly
|
||||
- [ ] Secret access is logged and audited
|
||||
- [ ] Secrets are encrypted at rest and in transit
|
||||
@@ -197,4 +197,3 @@ This document provides a comprehensive security audit checklist for The Order mo
|
||||
**Audit Date**: _______________
|
||||
**Auditor**: _______________
|
||||
**Next Review Date**: _______________
|
||||
|
||||
|
||||
Reference in New Issue
Block a user