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, oftenstruggle 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 forrenewing, 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 freeto give feedback and we can answer any queries !! Appreciate everyone time :)
NBU console access for non-admins
this is not easy to come across so i'm sharing my settings for /usr/openv/java/auth.conf [root@master java]# cat auth.conf root ADMIN=ALL JBP=ALL nbu ADMIN=AM+BPM+DM the above settings will allow non-admins (unix username here is nbu) to run NBU Java console with limited rights. for explanation of the rights, https://www.veritas.com/support/en_US/article.000112209 https://www.veritas.com/support/en_US/article.v41641740_NBU_773 https://www.veritas.com/support/en_US/article.v41641767_NBU_773 HTH.
