When it comes to SECRETS, how secure is your application?
Introduction Enterprises running various heterogeneous workloads ranging from on prem applications to applications spread across various cloud service providers, often struggle to manage credentials securely. We’ve seen a lot of technical debates about how to find a perfect balance between security and flexibility, but there’s no de facto standard hack which fits in for all. We’ve seen (sometimes radically) different opinions on “the right way” to manage secrets: “You should always use vault”, “You should encrypt creds” and the list is never ending! To cope up with these challenges, Veritas introduces Alta Recovery Vault short lived token-based authentication. For us, your data’s security is paramount to us. Prior to short lived tokens, Veritas provided ability to connect to Alta Recovery Vault with Standard Credentials (access and secret keys) as shown below : Diagram1: Creating a Credential with the Storage Account and Traditional Credentials (Access key and secret) given by Veritas Disadvantages of using Standard Credentials in Recovery Vault These standard credentials are long lived in nature. If compromised, they give attackers ample time to exploit the application. If they are stolen it would be a nightmare to discern which operations are legitimate. Thus, the only fail-safe choice is to cumbersomely rotate the keys and redistribute to customers. This is often overlooked action and adds extra pain for the DevOps.( p.s: It's not happier as it seems to be in the adajcent picture) Solution To help alleviate some of the above risks, Veritas has leveraged the ability to enhance security by introducingshort lived token-based authentication. Beginning with NetBackup 10.2 for Azure and NetBackup 10.4 for AWS (...GCP work in progress), users will have cloud storage accounts and a short-lived refresh token to connect securely to the Alta Recovery Vault storage. These new secrets are added as Credentials in the NetBackup Credential Management (as shown in diagram 2a and 2b) Once the initial connection is established, Veritas credential Management API is solely responsible for renewing, refreshing, accessing and sharing access signature. Isn’t it amazing just no pain to rotate the keys and redistribute! ( I see the cyber security team seems happier and overjoyed ) Diagram 2a: Creating a Credential with the Storage Account and Refresh Token given by Veritas for Azure Diagram 2b: Creating a Credential with the Refresh Token given by Veritas for AWS Solution Benefits Enhanced Security : Short-lived tokens have a limited lifespan, reducing the exposure window for potential attacks. If a token is compromised, its validity period is short, minimizing the risk of unauthorized access. Regular token expiration forces users to re-authenticate, ensuring better security. Mitigating Token Abuse : Tokens are often used to authorize access to resources. By making tokens short lived, we limit the time an attacker can use to abuse a stolen token. Thus, minimizing the risk window significantly. Better Management of Permissions : When permissions change (e.g., user roles or access levels), short-lived tokens automatically reflect the updates upon renewal. Long-lived tokens may retain outdated permissions, leading to security risks. Conclusion Introduction to Alta Recovery Vault short lived token authentication adds another layer for ransomware protection thus making applications more secure than ever before. At Veritas, your data’s security is paramount to us and this blog serves just as one simple example of the challenges Veritas short lived tokens can help solve. Further, Veritas is always looking and working for better ways to secure your data. Here are some additional helpful links : Veritas Alta Recovery Vault Technical White Paper Veritas Alta Recovery Vault Security Guide Veritas Alta Recovery Vault Azure ExpressRoute Overview Guide Veritas Alta™ Recovery Vault AWS Direct Connect Overview Guide Please feel free to give feedback and we can answer any queries !! Appreciate everyone time :)
What information and logs to include when creating an Exchange case with support ( non-grt)
Providing the following information when creating an exchange case will not only help the TSE narrow down the issue, but will help resolving your case faster and more efficient. The following information will help the TSE outline an action plan before the first call back and WebEx.What information and logs to include when creating a GRT Exchange 2007/2010 case with support.
Providing the following information when creating a GRT Exchange case will not only help the TSE narrow down the issue, but will help resolve your case faster and more efficient. This information will help the TSE outline an action plan before the first call back and WebEx.
