Secure your Azure Managed Instance for Apache Cassandra deployment

Azure Managed Instance for Apache Cassandra provides automated deployment, scaling, and management for open-source Apache Cassandra datacenters that run in your own virtual network. When you deploy the service, follow security best practices to protect your data, credentials, and cluster infrastructure.

This article provides security recommendations to help protect your Azure Managed Instance for Apache Cassandra deployment. For a conceptual overview of the service's security model, see Security in Azure Managed Instance for Apache Cassandra.

The security recommendations in this article implement Zero Trust principles: "Verify explicitly", "Use least privilege access", and "Assume breach". For comprehensive Zero Trust guidance, see the Zero Trust Guidance Center.

Network security

Azure Managed Instance for Apache Cassandra injects resources directly into your virtual network with private IP addresses and doesn't expose public endpoints. Control the surrounding network to keep traffic private.

  • Deploy the cluster into a dedicated virtual network subnet: Place each datacenter in a subnet that you size and delegate for the service, so cluster nodes stay reachable only over private IP addresses within your virtual network. For more information, see Create a cluster by using the Azure CLI.
  • Restrict outbound traffic to required destinations: Allow only the outbound network rules the service needs. If you use Azure Firewall or network security groups, apply the required virtual network service tags; if you use a non-Microsoft firewall, configure user-defined routes for the required Microsoft address prefixes. For more information, see Required outbound network rules.
  • Isolate the management operator with a VPN connection: Deploy the cluster with the VPN connection method so the management operator runs in a separate virtual network and reaches the cluster through a private endpoint, with service endpoint policies and network security groups that block operator access to the internet. For more information, see Use a VPN with Azure Managed Instance for Apache Cassandra.
  • Grant the deployment identity permission to join your subnet: Assign the Azure Cosmos DB service principal a role such as Network Contributor, or a custom role that allows Microsoft.Network/virtualNetworks/subnets/join/action, scoped to the target virtual network. Every virtual network-injected cluster and datacenter deployment requires this permission, whether or not you use customer-managed keys. For more information, see Use the Azure portal to add the Azure Cosmos DB service principal.

Identity and access management

The service uses Apache Cassandra native authentication and authorization, which you manage through Cassandra roles, and it supports directory-based authentication and client certificate authentication for stronger identity assurance.

  • Evaluate LDAP authentication for directory-based sign-ins: If public preview features meet your workload requirements, authenticate cluster users against your own directory instead of relying only on local Cassandra credentials, so account lifecycle and password policy stay centralized. For more information, see Enable LDAP authentication in Azure Managed Instance for Apache Cassandra.
  • Require client certificate authentication: Configure client-to-node certificate authentication (mutual TLS) so the cluster verifies each connecting client against certificates in its trust store. For more information, see Configure client certificates.
  • Protect the initial Cassandra administrator credentials: Replace the sample initialCassandraAdminPassword value with a strong password at cluster creation, and restrict use of that administrator account to cluster administration. For more information, see Create a cluster by using the Azure CLI.
  • Restrict control-plane access with custom Azure roles: When built-in roles are broader than needed, create a custom role that grants only the specific actions your operators need on the Microsoft.DocumentDB/cassandraClusters and Microsoft.DocumentDB/cassandraClusters/dataCenters resource types, such as the read, write, and delete actions required to create, modify, scale, deallocate, repair, or delete the cluster and datacenter resources. For more information, see Azure permissions for Databases.

Data protection

By default, the service encrypts data at rest with service-managed keys and enforces server and node-to-node TLS in transit. To control the encryption key lifecycle yourself, configure customer-managed keys.

Logging and monitoring

Azure Managed Instance for Apache Cassandra integrates with Azure Monitor and emits Cassandra server and audit logs that you can route to your own log store for detection and investigation.

  • Enable diagnostic settings for Cassandra logs and audit logs: Route the CassandraLogs and CassandraAudit categories to a Log Analytics workspace, storage account, or event hub to record server operations and Cassandra Query Language activity. For more information, see Diagnostic settings.
  • Filter audit logging with an allow list: Audit logging records every sign-in attempt and CQL query by default, which can generate excessive records and overhead. Define an allow list to selectively include or exclude keyspaces, categories, and users so your audit trail captures security-relevant activity without overwhelming your log store. For more information, see Audit log allow list.

Compliance and governance

Govern the lifecycle of your clusters so they stay patched and protected against accidental deletion.

  • Protect clusters and datacenters with resource locks: Apply a delete lock to the Cassandra cluster and its datacenter resources so accidental deletion can't remove them, which matters because automated backups are retained for only a short window. For more information, see Lock your resources to protect your infrastructure.
  • Keep clusters patched by avoiding prolonged deallocation: Return deallocated nonproduction clusters to service within seven days, because a cluster left deallocated longer might miss security patches and should be recreated. For more information, see Deallocate a cluster.

Backup and recovery

The service takes automated snapshot backups that you can tune, but backups aren't geo-redundant. Combine backup configuration with a multi-region topology for resiliency.

  • Configure the backup interval and retention period: Adjust the automated snapshot schedule and retention (up to two days) to match your recovery point objective. For more information, see Backup and restore.
  • Deploy multiple regions for disaster recovery: Because backups aren't geo-redundant, run datacenters in more than one region so a regional outage doesn't leave data unavailable. A second region alone doesn't guarantee against data loss: update each keyspace to use NetworkTopologyStrategy with an appropriate replication factor across the datacenters, and choose a write consistency level that meets your durability requirements. When you add a region, apply the keyspace replication changes and stop clients from writing to the new datacenter before you run nodetool rebuild to copy existing data; writing too early prevents the rebuild from completing. For more information, see Create a multi-region cluster.

Related content

  • Last updated on