NIS2 documentation

Document status	35 - Reviewed

NIS2 Documentation - Energy Connect

This document describes how Energy Connect complies with the requirements set forth in the Danish NIS2 Act (NIS2-loven), specifically focusing on the measures outlined in Chapter 2, § 6.

Reference: NIS 2-loven

§ 6, stk. 5 - Sikkerhed i forsyningskæde

Requirement: Security in the supply chain, including handling of relationships between the entity and its direct suppliers or service providers.

Supplier and Service Provider Management

Azure Cloud Services (Microsoft)

Energy Connect is hosted on Microsoft Azure, a cloud platform that maintains comprehensive security certifications including ISO 27001, SOC 2, and EU compliance frameworks
Microsoft provides continuous security updates and patches through Azure platform services
All Azure services used in Energy Connect benefit from Microsoft's security baseline and threat intelligence

Third-party Components

All third-party libraries and dependencies are tracked through the development pipeline
Sonar Cloud integration performs continuous security scanning of dependencies
Regular updates of NuGet packages and Node.js dependencies follow security advisories

Development Partners (Fellowmind)

Fellowmind follows Microsoft's Security Development Lifecycle (SDL)
All developers undergo security training and follow secure coding guidelines
Access to production systems is controlled through Entra ID with PIM (Privileged Identity Management)
Reference: Security and Access Management

Supply Chain Security Controls

Code Quality and Security Scanning
- SonarCloud performs static code analysis on Pull Request before merging to main branch
- Code reviews are mandatory before merging to main branch
Dependency Management
- Regular updates following security bulletins
- Version control ensures reproducible builds
Access Control to Development Pipeline
- Azure DevOps access controlled through Entra ID
- Role-based access control (RBAC) for repository and pipeline access
- Multi-factor authentication (MFA) required for all accounts

§ 6, stk. 8 - Politikker og procedurer til brug af kryptografi

Requirement: Policies and procedures for the use of cryptography and, where relevant, encryption.

Encryption at Rest

Virtual Machine and Disk Encryption

All Virtual Machines use Encryption at Host (Server-Side Encryption - SSE)
Data on temporary disk and OS/data disk caches are encrypted end-to-end
Encryption occurs at the VM host level before data flows to Azure Storage
No performance impact as encryption doesn't use VM CPU resources

Database Encryption

PostgreSQL databases leverage Azure disk encryption through host-level encryption
Database backups are encrypted at rest in Azure Storage

Storage Accounts

All Azure Storage Accounts use Microsoft-managed encryption keys
Data is encrypted automatically before persisting to storage
Encryption is applied to all storage services: Blobs, Files, Tables, and Queues, but the solution primarily uses Blob storage

Azure Key Vault

Secrets, connection strings, and certificates stored in Azure Key Vault
Access to Key Vault is controlled through Managed Identities where possible
Reference: System Landscape

Encryption in Transit

HTTPS/TLS for All Communications

Azure Front Door enforces HTTPS for all client connections
TLS 1.2 or higher is required for all external communications
Internal service-to-service communication within Container Apps uses encrypted channels
Frontend to backend communication is secured through Azure Virtual Network

Database Connections

PostgreSQL connections enforce SSL/TLS encryption
Neo4j graph database connections use encrypted protocols

API Security

All REST APIs exposed through HTTPS only
OpenAPI-generated clients enforce secure connections

Certificate Management

Certificate Storage and Rotation

Azure Front Door manages certificate provisioning and renewal
Automated certificate rotation through Azure Front Door for the custom domains

Application Certificates

Service principals uses federated credentials (passwordless)

Cryptographic Standards

Approved Algorithms and Protocols

TLS 1.2 and TLS 1.3 for transport security
AES-256 for data at rest encryption
SHA-256 or higher for hashing operations
RSA 2048-bit or higher for key exchange

JWT Token Signing

OAuth 2.0 and OpenID Connect for authentication
Microsoft Authentication Library (MSAL) used for token handling
JWT tokens signed using industry-standard algorithms
Token validation enforced in all API endpoints
Reference: Developer Guide

§ 6, stk. 9 - Personalesikkerhed

Requirement: Personnel security, including access management and control of personnel, employees or service providers with access to the entity's operations or services and privileged access rights.

Access Management Framework

Entra ID (Azure Active Directory) as Central Identity Provider

All user identities managed through Microsoft Entra ID
Single Sign-On (SSO) across all Energy Connect services
Conditional Access policies enforce security requirements
Reference: Entra ID Groups Infrastructure and Application groups

Multi-Factor Authentication (MFA)

MFA required for all administrative access
MFA required for Privileged Identity Management (PIM) activation
Azure Conditional Access enforces MFA policies
Users cannot access privileged resources without MFA

Role-Based Access Control (RBAC)

Infrastructure Access (Azure RBAC)

Energy Connect implements a standardized Entra ID group structure per environment and customer:

Naming Convention: ec-{env}-{customer}-{scope}-{role}

Role	Azure RBAC	Description	Access Method
`infra-reader`	Reader	Read-only access to Azure resources	Direct assignment
`infra-contributor`	Contributor	Full management of resources (except access)	PIM with MFA
`infra-owner`	Owner	Full control including access management	PIM with MFA
`infra-vm-admin`	VM Administrator Login	SSH/RDP access to Virtual Machines	PIM with MFA

Privileged Identity Management (PIM)

All privileged roles (except Reader) require PIM activation
Access granted for limited duration (maximum 8 hours)
All activations logged and auditable
Reference: Entra ID Groups Infrastructure and Application groups

Application Access (API Roles)

Application-level access managed through Entra ID groups with app role assignments:

Naming Convention: ec-{env}-{customer}-app-{role}

Role	Description	Access Level
`app-cpmp-reader`	Read access to CMPP data	Read-only API endpoints
`app-cpmp-handler`	Process CMPP requests	Write access to CMPP APIs
`app-system-reader`	System monitoring and read access	Read-only system data
`app-administrator`	Full application administration	Full application control

API access enforced through JWT token validation
Tokens contain user roles from Entra ID group membership
Authorization checked on every API request
Unauthorized access attempts logged and monitored

Access Control Procedures

Onboarding Process

User identity created in Entra ID (or customer's tenant)
User assigned to appropriate Entra ID groups based on role
For infrastructure access: PIM eligibility configured by administrators
For application access: Group membership grants API roles
User receives onboarding documentation and security training
Initial access logged in audit trail

Offboarding Process

User account disabled in Entra ID
All group memberships removed
PIM eligibility revoked
Active sessions terminated
Access keys/tokens invalidated
Offboarding logged and verified
Access review confirms all access removed

Privileged Access Management

Separation of Duties

Development, test, and production environments have separate access groups
No direct access to production databases (access through Bastion only)
Infrastructure changes require approval and are tracked in Git
Principle of least privilege enforced across all systems

Azure Bastion for Secure VM Access

Bastion provides browser-based SSH/RDP access
No public IP addresses on Virtual Machines, only private IP is available
All Bastion sessions logged

Service Principal and Managed Identity Access

Automated processes use Managed Identities (passwordless) where possible
Service Principals use federated credentials (passwordless), not secrets
Service Principal access regularly reviewed and rotated
Reference: Operation & Maintenance Manual

Audit and Logging

Authentication and Authorization Logging

All authentication attempts logged in Entra ID
Authorization decisions logged in Application Insights
PIM activations logged with justification
Logs retained according to compliance requirements
Reference: Developer Guide Access Audit Trail
Azure Activity Log records all infrastructure changes
Application logs record API access and operations
Database access logged in PostgreSQL audit logs
Log Analytics aggregates logs for analysis

Security Monitoring

Application Insights monitors application security events
Failed sign-in authentication attempts monitored
Security incidents escalated according to procedures
Reference: Operation & Maintenance Manual

Backup and Disaster Recovery (Supporting § 6)

Backup Strategy

Database Backup (Barman)

Automated backup through Barman tool on Agent VM
Weekly full backups combined with continuous WAL (Write-Ahead Log) streaming
Point-in-Time Restore (PITR) capability with minimal data loss
Backups encrypted at rest in Azure Storage
Export capability to tar archive for long-term strategic backup
Reference: Operation & Maintenance Manual Infrastructure-as-Code Backup
All infrastructure defined in Bicep templates
Infrastructure code versioned in Azure DevOps Git
Ability to recreate entire environment from code

Recovery Procedures

Recovery procedures documented in Operation & Maintenance Manual
Regular testing of backup restoration
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) defined per environment
Disaster recovery procedures include failover scenarios