Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Managed Redis provides a fully managed in-memory data store based on Redis Enterprise software. When you deploy Azure Managed Redis, follow security best practices to protect your cached data, configurations, and infrastructure.
This article provides security recommendations to help protect your Azure Managed Redis deployment.
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.
Service-specific security
Azure Managed Redis has unique security considerations based on its in-memory architecture.
Azure Managed Redis architecture
- Select the appropriate tier for security requirements: Different Azure Managed Redis tiers offer different capabilities. All tiers support private endpoints, TLS encryption, and Microsoft Entra authentication. The Flash Optimized tier stores some data on NVMe disks encrypted with Microsoft-managed keys. When you enable high availability (HA) mode—recommended for all production workloads and required for coverage under the SLA—Azure Managed Redis deploys primary and replica shards across at least two nodes, and the instance is zone redundant in regions with multiple availability zones. An instance created without HA has no replication, so enable HA for any workload where availability matters. For more information, see Feature comparison and Running without high availability mode enabled.
Appropriate use of Azure Managed Redis
Do not store sensitive data without proper encryption: While Azure Managed Redis encrypts data at rest on persistence disks, the service doesn't encrypt data in memory. Implement application-level encryption for highly sensitive data before writing it to the cache, or use the service only for non-sensitive cached data. For more information, see Disk encryption coverage in Azure Managed Redis.
Do not expose access keys in application code: Store access keys in Azure Key Vault, or use Microsoft Entra authentication instead of embedding access keys in application code or configuration files. Exposed access keys can lead to unauthorized cache access. For more information, see Use Microsoft Entra ID for cache authentication.
Do not use Azure Managed Redis as a primary data store: Azure Managed Redis serves as a cache and temporary data store, not a persistent primary database. Always maintain authoritative data in a persistent data store like Azure SQL Database or Azure Cosmos DB. For more information, see Key scenarios.
Network security
Isolate your Azure Managed Redis instance from the public internet and control network access.
Use private endpoints: Deploy Azure Private Link to connect to your Azure Managed Redis instance through a private IP address in your virtual network. Private endpoints eliminate exposure to the public internet and keep traffic on the Microsoft backbone network. Private endpoints are the recommended solution for securing your Azure Managed Redis resource at the networking layer. For more information, see Azure Managed Redis with Azure Private Link.
Disable public network access: When using private endpoints, disable public network access by using the
publicNetworkAccessproperty to ensure all traffic flows through your virtual network. This configuration prevents unauthorized access from the internet. For more information, see Enabling public network access.
Identity and access management
Properly configure authentication and authorization to control access to your Azure Managed Redis instance.
Use Microsoft Entra ID authentication: Configure Microsoft Entra ID for password-free authentication instead of access keys. Microsoft Entra authentication provides enhanced security, centralized identity management, and automatic token refresh. Azure Managed Redis enables managed identity by default when you create a new cache. Microsoft Entra groups aren't supported, so add individual users or service principals to the Redis users list. For more information, see Use Microsoft Entra ID for cache authentication with Azure Managed Redis.
Disable access key authentication: After configuring Microsoft Entra ID authentication, disable access key authentication to eliminate the risk of credential exposure. Access keys are static credentials that attackers can compromise if leaked. Changing this setting terminates all existing client connections regardless of authentication method, so implement proper retry mechanisms for reconnecting. For more information, see Disable access key authentication on your cache.
Add authorized users or service principals: Configure which Microsoft Entra users or service principals can access your cache by adding them to the Redis users list in the Azure portal. Follow the principle of least privilege by granting access only to identities that require it. For more information, see Add users or service principals to your cache.
Apply least privilege access with RBAC: Use Azure role-based access control (RBAC) to manage who can administer your Azure Managed Redis resources in the Azure portal and through APIs. Assign roles at the appropriate scope to limit permissions to only what's necessary. For more information, see Access control (IAM).
Use managed identities for Azure resource access: When your Azure Managed Redis instance needs to access other Azure resources such as Azure Key Vault for customer-managed keys, use managed identities. Managed identities eliminate the need to manage credentials. For more information, see Prerequisites and limitations.
Regenerate access keys regularly: If you must use access keys, regenerate them regularly to limit the impact of potential key exposure. Azure Managed Redis supports two access keys so you can rotate keys without downtime. For more information, see Authentication.
Data protection
Protecting data at rest and in transit is crucial for maintaining the confidentiality and integrity of your cache.
Keep non-TLS access disabled: Azure Managed Redis requires TLS 1.2 or 1.3 for all connections by default, which encrypts data in transit. Keep non-TLS access disabled to prevent unencrypted communication. If you enable non-TLS access for legacy applications, plan to migrate those applications to TLS-enabled clients. For more information, see TLS configuration for Azure Managed Redis.
Use customer-managed keys for disk encryption: Azure Managed Redis encrypts persistence data and OS disks by using Microsoft-managed keys (MMK) by default. For more control, configure customer-managed keys (CMK) to wrap the encryption keys by using Azure Key Vault. CMK requires a user-assigned managed identity and an Azure Key Vault instance with purge protection and soft delete enabled. For more information, see Configure disk encryption for Azure Managed Redis instances using customer managed keys.
Logging and monitoring
Implement comprehensive logging and monitoring to detect security threats and troubleshoot issues.
Enable connection logs: Configure Azure diagnostic settings to log client connections to your cache. Connection logs record who is connecting and the timestamp of those connections, enabling you to identify the scope of security breaches and perform security auditing. For more information, see Azure Monitor diagnostic settings.
Monitor the Activity log: Review the Azure Activity log to track management operations performed on your Azure Managed Redis resources. Activity logs help you determine what operations were performed, who initiated them, and when they occurred for security auditing purposes. For more information, see Activity log.
Create security alerts: Set up Azure Monitor alerts to notify you of abnormal usage patterns, connection anomalies, or potential security breaches affecting your cache. Configure alerts based on connection count spikes, authentication failures, or unusual data transfer patterns. For more information, see Alerts.
Integrate with Azure Monitor: Configure Azure Monitor to collect and analyze logs and metrics from your Azure Managed Redis instance. Use Log Analytics workspaces to run queries on connection logs and identify security patterns. For more information, see Monitoring.
Compliance and governance
Implement governance controls to ensure your Azure Managed Redis deployments meet organizational and regulatory requirements.
Enforce organizational standards with Azure Policy: Deploy Azure Policy to enforce organizational standards and assess compliance at scale. Use policy definitions to audit and enforce security configurations across your cache resources. For more information, see Azure Policy overview.
Enable resource locks: Apply resource locks to prevent accidental deletion or modification of critical Azure Managed Redis resources. Use CanNotDelete locks to prevent deletion while allowing modifications, or ReadOnly locks for complete protection. For more information, see Locks.
Use tags for resource organization: Apply tags to your Azure Managed Redis resources to support security governance, cost tracking, and compliance reporting. Tags help you organize resources by security classification, environment, or compliance requirements. For more information, see Tags.
Backup and recovery
Implement backup and recovery mechanisms to ensure business continuity and data protection.
Configure data persistence: Enable RDB or AOF persistence to automatically recover data after unexpected failures. RDB persistence saves periodic snapshots with minimal performance impact and is suitable for most scenarios. AOF persistence logs every write operation for minimal data loss but can affect throughput. Persistence isn't a backup or point-in-time recovery (PITR) feature—if corrupted data is written to the cache, that corrupted data is persisted as well. For true backups, use the export feature. For more information, see Configure data persistence for an Azure Managed Redis instance.
Use active geo-replication for disaster recovery: For critical workloads, enable active geo-replication to replicate data across multiple Azure regions. Geo-replication provides business continuity if an entire region becomes unavailable. Active geo-replication isn't compatible with data persistence, so choose geo-replication for cross-region resiliency or persistence for single-region durability. For more information, see Set up active geo-replication.
Use export for data backups: Create periodic backups of your Redis data by using the export feature to Azure Storage accounts. Export provides point-in-time data copies that you can import to new cache instances for disaster recovery. For more information, see Import and export data in Azure Managed Redis.
