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 :)6 Steps for installing NetBackup in the AWS Cloud
In the following example, NetBackup 9.1 Primary, Media and CloudPoint servers are deployed with the result being able to log into the NetBackup Primary webui and viewing the Media and CloudPoint servers attached. Let’s Begin To begin, log into your AWS portal, search for Veritas NetBackup in the AWS navigation bar and select “Veritas NetBackup (BYOL)”. You will be taken to the latest Veritas NetBackup (BYOL) in the AWS Marketplace. Click on Continue to Subscribe. Once you’ve subscribed to the software, Click on Continue to Configuration. The first step to configuring the software is choosing the Delivery Method. For this blog we’re going to deploy a NetBackup Primary, Media and CloudPoint servers. After Delivery Method has been chosen, select the Software Version and the Region you’d like to deploy NetBackup in. Click on Continue to Launch. Prepare for Launch! Check to make sure you the selections you’ve chosen are correct. Click Launch. Check the prerequisites and click Next. Primary Server Give the Stack a name that will identify it. Next, we’ll enter the configurations for the NetBackup Primary Server. Give your NetBackup Primary server a name. Choose the Server Instance Type. Select the NetBackup Primary Server installation volume size. Media Server Here we enter information for the Media Server: Give the NetBackup Media server a name. Choose the Server Instance Type. Select the NetBackup Media Server installation volume size. CloudPoint - Configurations Next, we’ll enter information for the NetBackup CloudPoint Instance. Select the OS type you’d like for the CloudPoint server. Select the Instance Type. Enter in the size of the CloudPoint Volume. Enter an Elastic IP if you need one. Enter the HTTP Proxy if one is use. Enter the HTTPS Proxy if one will be used. Enter a NO Proxy if one will be needed. Common Configurations Now enter the Common Instance Configuration Parameters. Select an SSH Key Pair so you can SSH to the new environment. This step needs to be completed prior to this point. Choose if you will be using an existing Virtual Private Cloud (VPC) or if you’d like the template to create one for you. VPC, Subnet and Domain Next, we’ll enter the information of our existing VPC and Subnet. If you’d like the stack to create a new VPC and Subnet and Domain, ignore this step and go to the next step. Enter the VPC ID you’d like to deploy the NetBackup stack in. Enter the Subnet ID for the new stack. Note: The VPC CIDR block and the subnet block cannot be the same size. If the same range is given an error will occur during CloudPoint server creation. Select the Availability Zone the stack will be installed in. Choose the VPC CIDR block the stack will use. Choose whether or not the stack should create a new DHCP Option Set for the VPC. If you already have one associated with your Route 53 Domain, choose false. Enter the name of the Domain you wish to use. This domain must be associated with the Route 53 you plan to use with this stack. Select if there is a Route 53 Hosted Zone associated with the domain in step 6. If you’ve chosen to have the stack create your VPC, CIDR Blocks and Domain, enter the information here. NetBackup Installation Parameters Next enter the NetBackup Installation Parameters. Enter a username for the NetBackup service. This user will NOT be used to login to the instances, it will only be used to start and stop NetBackup processes. Enter your NetBackup License Key. Paste the contents of your NetBackup Usage Insights Customer Registration Key here. CloudPoint – Installation Parameters From here we’ll enter in the NetBackup CloudPoint Parameter. Enter the username for CloudPoint. Give the user a password. Enter any additional names you’d like to be added to the TLS certificate. The default CloudPoint port is 443, customize if desired. Give the name of the Cloudpoint Instance IAM. If you don’t enter one, the stack will create one for you. Note: This role is required for NetBackup to properly work with AWS. For more information, see the Veritas NetBackup Cloud Administrator’s Guide. https://www.veritas.com/content/support/en_US/doc/58500769-150013608-0/v125433652-150013608 Enter the NetBackup Cloud SNS Topic ARN. This is only required if you wish to receive notifications. Enter the NetBackup CloudPoint CMK ID. This is only necessary if you are using a Key Management Service (KMS). Enter the NetBackup CloudPoint CMK Region. This is only necessary if you are using a KMS. Click Next when the above information is correct for your environment. Final Inputs This page covers any Tags, Permissions or Advanced options you’d like to use with the Stack. When you are complete or if no changes are necessary, click Next. Review Time It’s time to review the Stack and if everything looks good, go to Capabilities at the bottom of the screen. Acknowledge the two Capabilities and click on Create stack. Your Deployment is Complete You will be taken to CloudFormation where the new NetBackup infrastructure will be created. When the stack has been successfully created, a similar message will appear. Create WebUI User and Login to WebUI If you choose not to use the root user to log into the WebUI, a user must be created and given privileges to login to the new webui. Log into the Primary server using the ec2-user and create a new user on the Primary server to log into the new NetBackup infrastructure. sudo useradd -m newusername sudo passwd newusername sudo /usr/openv/netbackup/bin/admincmd/bpnbaz -AddRBACPrincipal -user typeofpassword:FullyQualifiedDomainName:username Example: sudo useradd -m netbkadmin sudo passwd netbkadmin sudo /usr/openv/netbackup/bin/admincmd/bpnbaz -AddRBACPrincipal -user unixpwd:ng-nbu-primary1.vrts.tme.io:netbkadmin Next open a web browser and type this into the URL bar: https://FQDN/webui Example: https://ng-nbu-primary1.vrts.tme.io/webui Enter the username and password created in step 1. On successful login you will be greeted with the following banner. For this blog, we’ll jump into the GUI to see the other created NetBackup components. Located under Security > Hosts in the NetBackup webui we can see the three newly created resources ready to be used.
