Organizations of all sizes continue to adopt and accelerate their move to the cloud. Amazon Web Services (AWS) is widely recognized as the leading provider of cloud services, and it’s no surprise that AWS continues to rapidly add new capabilities and services across its portfolio to facilitate organizations’ journeys to the cloud. 

But, it is not just about making the journey easier; it is also about securing the cloud workloads running on AWS. To that point, CyberArk is working closely with AWS and our customers so they can take full advantage of CyberArk’s privileged account security capabilities for their AWS resident workloads.

Yet, even with all of the cloud-related breaches, such as misconfigurations of S3 buckets, which make private data public, and stolen access keys used for crypto-mining, there is still a lack of awareness within too many enterprises of the shared responsibility model among organizations, their cloud providers, and their security teams.  In CyberArk’s 2018 Threat Landscape report, only 49 percent of respondents had a privileged account security strategy in place for cloud.

Earlier today, AWS announced AWS Secrets Manager at the AWS San Francisco Summit. Now, while it is most likely that AWS Secrets Manager will first get adopted by developers at organizations primarily focused on native AWS environments, it is a significant announcement because it highlights the importance of removing secrets from code and storing them securely to protect the organization’s cloud workloads. This is something for which we have advocated, providing solutions to organizations of all types from AWS native, multi-cloud, hybrid, and on-premises for many years.

Secrets management is important, but it is just one element of the Privileged Account Security Solution. At CyberArk, security is our DNA, that’s what we do. We’re widely recognized for offering the industry’s most comprehensive solution for securing privileged accounts, credentials and secrets across on-premises environments, cloud and hybrid and throughout the DevOps pipeline.

What do we specifically offer for AWS?  We’ve been investing in AWS integrations that provide holistic security solutions for enterprises with hybrid and multi-cloud environments, including:

• The CyberArk AMIs (Amazon Machine Image) and CFTs (Cloud Formation Template) build a complete CyberArk Privileged Account Security environment in AWS in minutes – with primary and DR vaults, as well as session monitoring. It uses a secure and robust architecture developed with AWS that, for example, takes advantage of secure communications sub-nets and utilizes separate AWS Availability Zones for the primary and DR vaults. The flexible architecture also simplifies deployment across hybrid and multi-cloud environments. For more details, see our whitepaper, Securing Hybrid Cloud Environments and Workloads on AWS.
• CyberArk Conjur is focused on securing dynamic DevOps environments running on Docker and other container environments. It supports a broad range of environments, including native AWS, multi-cloud and hybrid environments with support for leading DevOps tools and platforms, including Ansible, CloudBees, Docker and Pivotal Cloud Foundry (PCF). Conjur Enterprise integrates with the CyberArk Enterprise Password Vault, enabling policies to be holistically applied across the enterprise. We offer both open source and enterprise versions. If you are a PCF customer, please join us for a webinar detailing how Conjur works with PCF on May 1, 2018.
• CyberArk’s automated provisioning function for AWS automatically on-boards and secures credentials for newly created EC2 instances in AWS environments, by leveraging CloudWatch and Lambda functions. It was designed to improve the native AWS functionality by simply replacing the generic SSH key assigned in a given AWS Auto Scaling Group with a unique key, thereby meeting a security best practice.

To learn more about how to leverage CyberArk to secure your native AWS, hybrid, multi-cloud and DevOps environments today, visit CyberArk.com/aws.

You can read the original article, here.