Security at Cirrova

1. Infrastructure & Hosting

Cirrova runs entirely on Microsoft Azure infrastructure. All infrastructure components are accessed using Managed Identity — the application never stores cloud credentials directly.

• Hosting: Azure App Service with managed runtime patching
• Database: Azure SQL with Entra ID–only authentication (SQL logins disabled); databases are not publicly accessible and access is restricted via role-based controls to permitted managed identities only
• Cost metric data: Azure Data Explorer — stores collected cost and resource metrics with long-term retention
• Secrets management: Azure Key Vault — no secrets are stored in application configuration or source code
• Credential resolution: Application credentials are resolved at startup via Key Vault; secrets are never logged or exposed via API responses
• Monitoring & logging: Application and audit logs are written to Azure Data Explorer
• Internal access controls: Cirrova team access to infrastructure components is protected by enforced Entra MFA

2. Data in Transit & at Rest

In transit

• All traffic is served over HTTPS/TLS — unencrypted connections are redirected automatically
• Database connections use Encrypt=True; TrustServerCertificate=False — TLS is enforced and certificate authenticity is verified

At rest

• Azure SQL data benefits from transparent data encryption (TDE), enabled by default on all Azure SQL databases
• Azure credentials you provide (service principal client secrets) are encrypted using the .NET Data Protection API before storage; they are decrypted in memory only when a collection run requires them
• User passwords are hashed using BCrypt with per-user salts — plaintext passwords are never stored
• MFA secrets (TOTP) are encrypted at rest using the Data Protection API
• Password reset and invitation tokens are stored as SHA-256 hashes with expiry timestamps — tokens cannot be reconstructed from stored values

3. Authentication

User authentication

• Email + password: Passwords must be a minimum of 12 characters. Credentials are validated against a BCrypt hash — the application never holds plaintext passwords
• Single Sign-On (SSO): Cirrova supports SSO via Microsoft Entra ID (Azure AD) using OpenID Connect. Users authenticate directly with your identity provider — Cirrova never sees your SSO credentials
• Multi-factor authentication (MFA): Organisation owners can enforce TOTP-based MFA for all non-SSO users. MFA secrets are encrypted at rest

API key authentication

• Keys are stored as SHA-256 hashes — the plaintext key is shown once at creation and is never stored or recoverable
• Each key has a 12-character prefix retained for audit trail identification
• Keys can be assigned an optional expiry date and revoked at any time
• Every API key use is logged with the key prefix, organisation, user, endpoint accessed, and timestamp

Token lifecycle

• Session tokens (JWT) are signed with HMAC-SHA256 using a secret stored exclusively in Key Vault
• Tokens are short-lived (60 minutes by default) and are not persisted server-side
• SSO sessions use separate short-lived cookies (HttpOnly, SameSite=Lax, 10-minute expiry)

4. Authorisation & Access Control

Role-based access control (RBAC)

Cirrova uses a layered RBAC model with five roles:

Tenant isolation

• Each organisation's data is logically isolated. Queries are always scoped to the authenticated user's organisation ID — cross-organisation data access is not possible at the application layer
• Within an organisation, users only see the Azure tenants they have been explicitly granted access to
• API keys inherit the permissions of the user they are issued to — they cannot exceed the user's own access scope

5. Your Azure Credentials

Cirrova needs read access to your Azure environment to collect cost and resource data. Here is exactly how credentials are handled:

• Service principal credentials (client ID + secret) or Managed Identity can be used to grant Cirrova access to your subscriptions
• Client secrets are encrypted immediately on receipt using the .NET Data Protection API and stored in encrypted form. They are decrypted in application memory only during scheduled collection runs
• Cirrova requests the minimum required Azure RBAC permissions: Cost Management Reader, Reader, and Monitoring Reader roles at the subscription scope
• Credentials are never logged, included in error messages, or returned via API responses
• You can rotate or revoke credentials at any time from within Cirrova or directly in your Azure portal — collection runs will fail gracefully if credentials are invalid

6. Audit Logging

Every significant action in Cirrova generates an audit log entry. Logged events include:

• User logins (successful and failed) and logouts
• API key creation, use, and revocation
• User and organisation management changes
• Tenant credential additions and updates
• Collection runs (start, completion, failures)
• Cost anomaly detection events
• Report generation and delivery
• Licence and subscription changes
• Support ticket creation

Each log entry captures: user ID, organisation ID, event type, IP address, user agent, and timestamp. Logs are retained in Azure Data Explorer according to your organisation's plan retention period.

7. Data Retention & Deletion

• Retention periods are applied per organisation based on your subscription plan
• A daily background process purges cost records, anomaly data, and collection snapshots that fall outside your retention window
• Enterprise plan customers can configure custom retention periods
• On cancellation, your data can be exported before deletion — contact us to arrange this

8. Multi-Organisation Architecture

Cirrova is a multi-organisation SaaS platform. Organisation isolation is enforced at every layer:

• Database queries always include an organisation ID filter — the application does not rely solely on application-layer checks
• API responses are validated against the authenticated user's organisation before any data is returned

Each organisation can connect to multiple Azure tenants, with per-tenant role assignments inside the organisation. Combined with multi-organisation hosting on a partner licence, this is designed for MSPs and enterprise teams managing multiple customer or business-unit environments.

9. Vulnerability & Patch Management

• Cirrova utilises PaaS components exclusively within the Azure stack — there are no self-managed virtual machines or operating systems. All underlying infrastructure, runtimes, and platform components are patched and maintained by Microsoft as part of the managed service
• Application dependencies are monitored for known vulnerabilities
• Security issues can be reported to: security@cirrova.io

10. Compliance