Prove to my customers that their data in AWS is encrypted - amazon-web-services

I am about to launch a webapp based on subscription. FYI, the web application manages health care data, and my customers are concerned about the security of data in the cloud.
Is there any certificate, or any official information I can give to my customers on the behalf of AWS proving that the data in any storage used by my application will be encrypted?
THANK YOU

From What is AWS Artifact?:
AWS Artifact provides on-demand downloads of AWS security and compliance documents, such as AWS ISO certifications, Payment Card Industry (PCI), and Service Organization Control (SOC) reports. You can submit the security and compliance documents (also known as audit artifacts) to your auditors or regulators to demonstrate the security and compliance of the AWS infrastructure and services that you use. You can also use these documents as guidelines to evaluate your own cloud architecture and assess the effectiveness of your company's internal controls. AWS Artifact provides documents about AWS only. AWS customers are responsible for developing or obtaining documents that demonstrate the security and compliance of their companies.
It explains what AWS does. However, you would also need to prove that you are using the cloud correctly, such as verifying user's identities and not making buckets public.

NO, there is no such a document, you need to apply and obtain this certificate.
AWS is complaint, for there part Security of the cloud, and you are responsible for the Security in the cloud. AWS Artifact is a repository.
AWS Config is the tool you will use to monitor the configuration of
your stack, can repair configurations also.
AWS Cloudwach will monitor the performance, brings you alerts and evoke Lambda
AWS Cloud Trail will monitor the API calls.
AWS Macy to check your buckets for Personal Identifiable information.
Then you are the one who enable encryption and choose the Key management and rotation, AWS KMS.
Just to mention few services to be aware of. Best regards.

Related

How to audit changes to the AWS account

I wanted to know if there was a way to track alerts or audit anything that happens with the AWS account like who changed what and why. I did find this https://docs.aws.amazon.com/opensearch-service/latest/developerguide/audit-logs.html where they use a comand line for enabling audit logs on an existing domain: aws opensearch update-domain-config --domain-name my-domain --log-publishing-options "AUDIT_LOGS={CloudWatchLogsLogGroupArn=arn:aws:logs:us-east-1:123456789012:log-group:my-log-group,Enabled=true}" but this is in regard to Amazon OpenSearch Service which I believe is only free for 12 months if you haven't used already. AWS Audit Manager. I am aware there are services that can do this but require a fee and I wanted to know if there were any free options
From the AWS documentation:
With AWS CloudTrail, you can monitor your AWS deployments in the cloud by getting a history of AWS API calls for your account, including API calls made by using the AWS Management Console, the AWS SDKs, the command line tools, and higher-level AWS services. You can also identify which users and accounts called AWS APIs for services that support CloudTrail, the source IP address from which the calls were made, and when the calls occurred. You can integrate CloudTrail into applications using the API, automate trail creation for your organization, check the status of your trails, and control how administrators turn CloudTrail logging on and off.
AWS Config provides a detailed view of the resources associated with your AWS account, including how they are configured, how they are related to one another, and how the configurations and their relationships have changed over time.
Basically, AWS CloudTrail keeps a log of API calls (requests to AWS to do/change stuff), while AWS Config tracks how individual configurations have changed over time (for a limited range of resources, such as Security Group rule being changed).

What are the differences between AWS Cloud HSM and KMS?

I am trying to understand the key management services in AWS (Amazon Web Services) and I can see that Amazon recommends more AWS Key Management Service (KMS) over Cloud Hardware Security Module (Cloud HSM). But I am having a hard time finding the key differences between the two, KMS vs Cloud-HSM.
Can someone please list a few key differences or a comparison of the two technologies?
Feature
AWS Cloud HSM
AWS KMS
Tenancy
Single-Tenant
Multi-Tenant
High Availability: How to achieve?
Create multiple HSMs (manually) over different AZs
Managed (automatically) by AWS
Scaling/Performance Responsibility
Your responsibility
AWS
Key access: Who controls it?
You
You+AWS
Keys: How to use?
Customer code + Safenet APIs
AWS Management Console
Keys: Where to use?
AWS & Your Network (VPN)
AWS
AWS Services Integration
A small set of services (Redshift, Oracle RDS etc.)
Most services fully integrated
Access & Authentication Policy
Quorom based K of N
AWS IAM Policy
Price
$$
$
FIPS 140-2 Compliance
Level 3
Level 2 overall (Level 3 in some areas)
Source: AWS official documentation + multiple courses I took for the AWS exams + practical experience.
Developers describe AWS CloudHSM as "Dedicated Hardware Security Module (HSM) appliances within the AWS cloud". The AWS CloudHSM service allows you to protect your encryption keys within HSMs designed and validated to government standards for secure key management. You can securely generate, store, and manage the cryptographic keys used for data encryption such that they are accessible only by you. AWS CloudHSM helps you comply with strict key management requirements without sacrificing application performance.
On the other hand, AWS Key Management Service is detailed as "Easily create and control the encryption keys used to encrypt your data".
AWS Key Management Service (KMS) is a managed service that makes it easy for you to create and control the encryption keys used to encrypt your data, and uses Hardware Security Modules (HSMs) to protect the security of your keys. AWS Key Management Service is integrated with other AWS services including Amazon EBS, Amazon S3, and Amazon Redshift. AWS Key Management Service is also integrated with AWS CloudTrail to provide you with logs of all key usage to help meet your regulatory and compliance needs.
AWS CloudHSM and AWS Key Management Service can be categorized as "Data Security Services" tools.
Some of the features offered by AWS CloudHSM are:
1]Protect and store your cryptographic keys with industry standard, tamper-resistant HSM appliances. No one but you has access to your keys (including Amazon administrators who manage and maintain the appliance).
2]Use your most sensitive and regulated data on Amazon EC2 without giving applications direct access to your data's encryption keys.
3]Store and access data reliably from your applications that demand highly available and durable key storage and cryptographic operations.
On the other hand, AWS Key Management Service provides the following key features:
1]Centralized Key Management
2]Integrated with AWS services
3]Encryption for all your applications
The AWS KMS custom key store feature combines the controls provided by AWS CloudHSM with the integration and ease of use of AWS KMS
Q: Why would I need to use a custom key store?
Since you control your AWS CloudHSM cluster, you have the option to manage the lifecycle of your CMKs independently of AWS KMS
From official documentation, it seems that KMS is a basic feature, and you can get a senior feature by expanding with CloudHSM.

Does Amazon Web Services (AWS) support GDPR?

Which AWS services are GDPR ready? Can I build and run GDPR compliant applications on AWS?
All AWS Services can be used in compliance with GDPR
Many requirements under the GDPR focus on ensuring effective control and protection of personal data. AWS services give you the capability to implement your own security measures in the ways you need in order to enable your compliance with the GDPR, including specific measures such as:
Encryption of personal data
Ability to ensure the ongoing confidentiality, integrity, availability, and resilience of processing systems and services
Ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident
Processes for regularly testing, assessing, and evaluating the effectiveness of technical and organizational measures for ensuring the security of processing
This is an advanced set of security and compliance services that are designed specifically to handle the requirements of the GDPR. There are numerous AWS services that have particular significance for customers focusing on GDPR compliancea and AWS has 500+ features and services focused on security and compliance.
For more information, have a look at the AWS GDPR Center.
The AWS Shared Responsibility Model and GDPR
AWS has a shared responsibility model with the customer and this doesn't change under GDPR. AWS is responsible for securing the underlying infrastructure that supports the cloud and the services provided; while customers, acting either as data controllers or data processors, are responsible for any personal data they put in the cloud.
You can find more information about the shared responsibility under GDPR in the AWS Security Blog.

AWS assume iam roles vs gcp's json files with private keys

One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.
Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?
I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.
AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.
In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.
Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.
The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.
Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.
As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.
From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.
Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.
Links:
[1] https://cloud.google.com/docs/authentication/getting-started
[2] https://cloud.google.com/docs/authentication/

AWS RDS - HIPAA compliant?

I'm planning to have Oracle on AWS.
Is Oracle RDS HIPAA compliant? How can I make it HIPAA compliant?
The answer just recently changed. RDS is now HIPAA compliant, per their documentation/FAQ:
What Services Can I Use in My AWS Account if I Have a BAA with AWS?
Customers may use any AWS service in an account designated as a HIPAA account, but they should only process, store and transmit PHI in the HIPAA-eligible services defined in the BAA. There are nine HIPAA-eligible services today, including Amazon DynamoDB, Amazon EBS, Amazon EC2, Amazon Elastic MapReduce (EMR), Amazon Elastic Load Balancer (ELB), Amazon Glacier, Amazon Relational Database Service (RDS) [MySQL and Oracle engines], Amazon Redshift, and Amazon S3.
Source
#Dang
There is no AWS offical documentation that says RDS can be made HIPAA compliant. Instead EC2, S3 and EBS are known services. The way to get HIPAA compliant for your AWS services follow this:
Customers must identify to AWS each account to be covered by the BAA
as a 'HIPAA Account'.
Customers may process, store or transmit PHI only on EC2, S3 and EBS.
Customers must use Dedicated instances for PHI data -
http://aws.amazon.com/dedicated-instances/
Customers must use VPC
Customers must encrypt all PHI in accordance with certain minimum
encryption standards
Customers may use any AWS service in their 'HIPAA Account' for data
that is not PHI
So, to get a BAA agreement from AWS you'll need dedicated instances running in a VPC, not the "classic" EC2. (Pricing for dedicated instances has come down a lot since the very beginning.)
I cannot comment about RDS for sure. What I know RDS can be made quite secure, using SSL over port 443.
What I suggest that If you are an authorized AWS customer, speak to AWS customer care executive as they are the best to validate my answer.
Thanks
Quoting the whitepaper released by Amazon Web Services on December 2015 (link mentioned below )
Amazon RDS for Oracle and Amazon RDS for Mysql are available for use under HIPAA standards once you sign an Business associate agreement and your account is designated as an "HIPAA account"
Link to the white paper - https://d0.awsstatic.com/whitepapers/compliance/AWS_HIPAA_Compliance_Whitepaper.pdf
Amazon RDS is an AWS HIPAA-Eligible Service meaning that it can be used with
In order to be HIPAA compliant in AWS, your team must do the following:
Sign a Business Associates Agreement (BAA) with AWS. This agreement outlines the HIPAA security responsibilities shared between the cloud provider and the cloud customer
Adopt appropriate administrative policies and procedures
Implement all necessary security configuration for individual cloud services, such as RDS, EC2, and S3. Security standards include configuring safeguards around encryption, backup and disaster recovery, and access control.
You can take a look at this guide to utilizing Amazon RDS in a HIPAA compliant manner.