Today I will continue to discuss the AWS Security mechanism. We were discussing Server Side Encryption.An S3 object can be passed to the server with a per-object key over SSL and encrypted on the server side before being put into the S3 bucket. The client side encryption is also possible so long as the client maintains its keys and encryption of objects without sending or sharing the keys.
Even data maintained on file systems or database can be encrypted. Both databases and file systems can provide transparent encryption. Whole disk or file level encryption is possible. With AWS, volumes can be encrypted too. Snapshots of encrypted volumes can also be taken. Optionally S3 bucket access can be taken and access logs to S3 can be taken. Hardware Security modules in the virtual private cloud enable to manage the AWS provisioned HSM. Customers can be single tenants in these VPC. If we are deploying a service, we can isolate our service, simplify security groups and forensics. We can also connect two VPCs in the same region bridged by routing table. Services that have APIs can also use logging. Logging can be enabled with CloudTrail. CloudTrail can monitor who made the API Call, when was the call made, what was the API call, and what were the resources that were acted upon etc. CloudTrail event collection can be configured in JSON just like a policy. CloudTrail partners with some of the major log reading, parsing and indexing vendors. To summarize the security recommendations, we should turn on Multi factor authentication for our root account, create IAM users, groups and policies, and never use the root account API keys and we should scope limit our policies. In addition if there are any geographical requirements such the whitepapers on Auditing, Logging, Risk, Compliance, and Security for say Australia, then those should be followed as well. Lastly, the IAM groups and security is one thing and user managing their resources is another. The tools available for the user are to chain their resources in a way that different accounts can have access or to enable signed provisioning of their resources for granting access to specific people outside the users and groups. In the latter case, the user is not really sharing the access keys and at the same time not granting public access to the read or write. This method is also favored in cases where the s3 resource needs to be downloadable via the http. In addition, signed access can also be time constrained so that the access can be revoked on the expiration of the duration specified. This is convenient for revokes. And provides ability to not have to do bookkeeping of the recipients.
Even data maintained on file systems or database can be encrypted. Both databases and file systems can provide transparent encryption. Whole disk or file level encryption is possible. With AWS, volumes can be encrypted too. Snapshots of encrypted volumes can also be taken. Optionally S3 bucket access can be taken and access logs to S3 can be taken. Hardware Security modules in the virtual private cloud enable to manage the AWS provisioned HSM. Customers can be single tenants in these VPC. If we are deploying a service, we can isolate our service, simplify security groups and forensics. We can also connect two VPCs in the same region bridged by routing table. Services that have APIs can also use logging. Logging can be enabled with CloudTrail. CloudTrail can monitor who made the API Call, when was the call made, what was the API call, and what were the resources that were acted upon etc. CloudTrail event collection can be configured in JSON just like a policy. CloudTrail partners with some of the major log reading, parsing and indexing vendors. To summarize the security recommendations, we should turn on Multi factor authentication for our root account, create IAM users, groups and policies, and never use the root account API keys and we should scope limit our policies. In addition if there are any geographical requirements such the whitepapers on Auditing, Logging, Risk, Compliance, and Security for say Australia, then those should be followed as well. Lastly, the IAM groups and security is one thing and user managing their resources is another. The tools available for the user are to chain their resources in a way that different accounts can have access or to enable signed provisioning of their resources for granting access to specific people outside the users and groups. In the latter case, the user is not really sharing the access keys and at the same time not granting public access to the read or write. This method is also favored in cases where the s3 resource needs to be downloadable via the http. In addition, signed access can also be time constrained so that the access can be revoked on the expiration of the duration specified. This is convenient for revokes. And provides ability to not have to do bookkeeping of the recipients.
No comments:
Post a Comment