Security

RADNAC strides to be a tool to aid you meeting your compliance requirements so a summary of how it secures your data is provided below.

  • The user interface provides informative and actionable warnings based on best current practices sourced from the standards working groups helping you navigate the most appropriate path for your deployment

  • All local secrets (user passwords and device secrets) are encrypted at rest by the Azure Key Vault, decryption is done on demand

    Backups contain the plaintext decrypted secrets, so make sure the Storage Account to send them to has limited access to only those authorized to view them

  • The Network Security Group (NSG) used by the service automatically manages the security rules for you utilizing both Application Security Groups (ASG) and ‘Deny by Default’ for both ingress (incoming) and egress (outgoing) traffic

  • EAP-TTLS/PAP credential caching uses S(alted)SHA512 (hash unique per entry, pool of 96 characters and of length 32 characters) and stores the result only in RAM

  • Remote network access to the instances is limited to the serial port only

    • The serial port is disabled

      • Can only be re-enabled by coreMem Limited, and then only when a co-administrator plan is used and with your permission, if access the instance is needed for diagnostics

    • The SSH service is disabled (systemctl mask ssh.socket ssh.service)

      • Only allows public key authentication

      • ‘root’ is blocked from using SSH

    • The only local user account is ‘root’ and the password is unique to each deployment which only exists and is stored in the Azure Key Vault created during the deployment

    • Only the root user is allowed to log in over the serial port

    • The ‘azureuser’ account is deleted during the install

      • It only briefly exists as Azure does not allow you to create (generalized) VMs without providing credentials

      • The SSH public key used is unique to each release, the private key is never recorded making it unusable to anyone, including coreMem Limited; it is deleted with the azureuser account during the deployment

    • No security rules on the Network Security Group (NSG) allow for SSH access to the instance

  • All resources used by the service utilize managed identities meaning there is no password or secret to leak

    • One exception to this is accessing the Storage Account created by the deployment due to a limitation of Azure that is being actively addressed by Microsoft

  • Use of Microsoft Entra ID and Microsoft Graph API is made through the use of certificate credentials

    • The private key of the certificate is non-exportable and stored in an Azure Key Vault

    • The certificate is regularly and automatically rotated

      • Configurable by you during deployment and settable between one (1) and thirty-six (36) months whilst defaulting to twenty-four (24) months

  • All network traffic is secured using TLS version 1.3

    • One exception is Azure Custom Resource Providers support only TLS 1.2 which communicates with the Azure Function; this is mitigating by forcing at least the cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 or stronger to be used

    • Azure Instance Metadata Service (IMDS) traffic also uses only HTTP (not HTTPS) as this is how all cloud provide IMDS services function

  • Access to the Azure Function is protected by:

    • Restricting access to Azure’s IP ranges only

    • Authenticated using mTLS - allowing only Azure Resource Manager (by way of the Custom Resource Provider) to communicate with it

    • Authorized using a function access key that is unique to each deployment - preventing access from other deployments to your deployment