AWS and Security – A view from outside
Shared Responsibility Model:
– static code analysis run as a part of build process
– threat modeling
– Google authenticator/RSA
MFA for AWS service API
– terminating EC2 instance
– sensitive data in S3 bucket
Security of Access Keys
– must be secured
– use IAM roles for EC2 management
Run Trusted Advisor
– encrypted file systems
– disabling password-only access to your guests,
– utilizing some form of multi-factor authentication to gain access to instances (or at a minimum certificate-based SSH Version 2 access).
– privilege escalation mechanism with logging on a per-user basis.
– utilize certificatebased SSHv2 to access the virtual instance,
– disable remote root login,
– use command-line logging,
– use ‘sudo’ for privilege escalation.
– generate your own key pairs in order
– ports which are required
– certain CIDR blocks
– think about IPTables
– encrypt volume
– use DoD methods to wipe volume before deleting
– any particular cipher to use? for PCI/SOX compliance?
– use Server Order preference
– use of Perfect Forward Secrecy
– VPC security group
– IP range, Internet gateway, virtual private gateway
– Need Secret Access Key of the account
– To consider subnet and route tables
– To consider firewall/security groups
– Network ACLs: inbound/outbound from a subnet within VPC
– ENI: Elastic Network Interface for management network / security appliance on network
– By default, you can deliver content to viewers over HTTPS by using https://dxxxxx.cloudfront.net/image.jpg. If you want to deliver your content over HTTPS using your own domain name and your own SSL certificate, you can use SNI Custom SSL or Dedicated IP Custom SSL.
– With Server Name Identification (SNI) Custom SSL, CloudFront relies on the SNI extension of the TLS protocol,
– With Dedicated IP Custom SSL, CloudFront dedicates IP addresses to your SSL certificate at each CloudFront edge location so that CloudFront can associate the incoming requests with the proper SSL certificate.
– Use IAM policies
– Use of ACL to grant read/write access to other AWS account users
– Bucket policies: add/deny permission within single object in a bucket
– Restrict access to specific resource using POLICY KEYS: Based on request time (date condition), whether request was send using SSL (Boolean condition), Requestor IP address (IP condition) or requestor’s client (string condition)
– Use SSL endpoint for S3 via internet or via EC2
– Use client encryption library
– Use server side encryption (SSE)- S3 managed encryption
– S3 metadata not encrypted
– S3 data to Glacier archival at regular frequency
– s3 delete control via mfa
– CORS: cross-origin resource sharing – allows S3 objects to be referenced in HTML pages else they are considered cross-site scripting
– DynamoDB resources and API permissions via IAM
– Database level permission that allow/deny at item(row) and attribute(column)
– Fine-grained access control allow you to specify via policy under what circumstances user/application can access DynamoDB table.
– IAM policy can restrict access individual items in the tables, attributes in these items or both.
– Allow Web Identity Federation instead of using IAM users via AWS STS (Secure Token Services)
– Each request must contain HMAC-SHA256 signature in header when sending request to DynamoDB
– Access Control: Master User Account and Password, Create additional user accounts, DB Security Group – similar to EC2 security group, which defaults to “deny all”. Access can be granted by adding database port in firewall via network IP range or EC2 security group.
– Using IAM further granular access can be granted.
– Network Isolation in muti-az deployment using DB Subnet groups
– RDS instance in VPC can be access via EC2 instances outside of VPC using SSH Bastion host and Internet Gateway.
– Encryption at RDS is available as means of transport encryption. SSL certificate installed on MySQL and SQL server – so app to DB connection is secure.
– Encryption at rest is supported via TDE (Transparent Data Encryption) for SQL and Oracle Enterprise Edition.
– Encryption at rest is not supported for MySQL natively and application must send encrypted data if they want data-at-rest encrypted.
– Point-in-time recovery via automated backup with db log and tran log stored for user-specified retention period.
– Restore upto last 5 minutes.. store the backup for 35 days by-default.
– During backup storage I/O is suspended but with multi-az deployment, backup is done at standby, so no performance impact.
– Cluster is closed to everyone by-default.
– Utilize security groups for network access to cluster.
– Database user permission is per cluster basis instead of per table basis. Though user can see the data in table rows generated by his activities; rows generated by other is not visible to the user.
– User who create an object is owner and only owner/superuser can query, grant or modify permission on the object.
– Redshift data is spread across multiple compute nodes in a cluster. Snapshot backups are uploaded to S3 of user-defined period.
– Four-tier Key Based architecture:
- Data Encryption Keys: Encrypts Data Blocks in Cluster
- Database Key: Encrypts Data Encryption Keys in Cluster
- Cluster Key: Encrypts Database Keys in Cluster. Use AWS or HSM to store the cluster key.
- Master Key: Encrypts Cluster Key, if stored in AWS. Encrypts the Cluster-Key-Encrypted-Database-Key if Cluster key is in HSM.
– RedShift uses Hardware-Accelerated SSL
– Offers strong cipher suites that uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) protocol allows PFS (Perfect Forward Secrecy).
– Cache Security group like firewall
– By default, network access is turned off
– Use authorize Cache Security Group ingress API/CLI to authorize EC2 Security Group (in turn allows EC2 instances)
– Backup/Snapshot of ElastiCache Redis cluster point-in-time backup or scheduled backup.
– Access to search domain’s endpoint is restricted by IP address so that only authorized hosts can submit documents and send search requests.
– IP address authorization is used only to control access to the document and search endpoints.
– Access is based on AWS acct/IAM user and once authenticated, user has full access to all user operations.
– Default access to individual queue is restricted to the AWS account that created it.
– Data stored in SQS is not encrypted by AWS but can be encrypted/decrypted by means of application.
– Amazon SNS delivers notifications to clients using a “push” mechanism that eliminates the need to periodically check or “poll” for new information and updates. Amazon SNS can be leveraged to build highly reliable, event-driven workflows and messaging applications without the need for complex middleware and application management. The potential uses for Amazon SNS include monitoring applications, workflow systems, time-sensitive information updates, mobile applications, and many others.
– SNS provided access control mechanism so topics and message are secured against unauthorized access.
– Topic owners can set policies on who can publish/subscribe to a topic.
– Access is granted based on an AWS account/IAM user.
– Actors that participate in the execution of a workflow – deciders, activity workers, workflow administrators – must be IAM users under the AWS account that owns the AWS SWF resources. Other AWS account can’t be granted access to AWS SWF workflows.
– AWS SES requires users to verify their email address or domain in order to confirm that they own it and to prevent others from using it. To verify a domain, Amazon SES requires the sender to publish a DNS record that Amazon SES supplies as proof of control over the domain.
– SES uses content-filtering technologies to help detect and block messages containing viruses or malware before they can be sent.
– SES maintain complaint feedback loops with major ISPs.
– SES supports authentication mechanisms such as Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM). When you authenticate an email, you provide evidence to ISPs that you own the domain.
– For SES over SMTP, it requires to encrypt the connection using TLS – supported mechanisms: STARTTLS and TLSWrapper.
– For SES over HTTP, communication will be protected by TLS through AWS SES’s HTTPS endpoint.
– Logical access to Kinesis is via AWS IAM, controlling which Kinesis operations users have permission to perform.
– By associating EC2 instance with IAM role, credentials available as a part of role is available to the applications on that EC2 instances. Thus it avoid using long-term AWS security credentials.
– Allows to create multiple users and manage permission for each users within AWS account.
– User permissions must be granted explicitly.
– IAM is integrated with AWS Marketplace to control software subscription, usage and cost.
– Role uses temporary security credentials to delegate access to user/service that normally don’t have access to AWS resources.
– Temporary security credentials is in short life-span (default 12 hours) and it can’t be reused after expiry.
– Temporary security credential are: Security Token, an Access Key ID, a Secret Access Key
– Useful in situations such as:
- Federated (non-AWS) User access:
- Identity federation between AWS and non-AWS users in corporate identity and authorization system.
- Using SAML, AWS as Service Provider and provide users with federated Single-Sign-On (SSO) to the AWS management Console or get federated access to call AWS APIs.
- Cross-Account Access: For organization who uses multiple AWS accounts to manage their resources, a role can provider users who have permission in one account to access resources in another account.
- Applications running on EC2 instance that need to access AWS resources: If EC2 need to make calls to S3 or DynamoDB resources, it can utilize role allowing management of large fleet of instances/autoscaling.
– Dedicated Hardware Security Module (HSM) appliance to provide secure cryptographic key storage and operations within an intrusion-resistant, temper-evident device.
– Variety of use cases such as database encryption, Digital Rights Management (DRM), Public Key Infrastructure (PKI), authentication and authorization, document signing, and transaction processing.
– Support some of the strongest cryptographic algorithm available – AES, RSA, ECC etc.
– Connection to CloudHSM available with EC2 and VPC via SSL/TLS using two-way digital certificate authentication
– Cryptographic partition is a logical and physical security boundary that restricts access to keys, so only owner of keys can control the keys and perform operations on HSM.
– CloudHSM’s temper detection erase the cryptographic key material and generate event logs if tempering (physical or logical) detected. After 3 unsuccessful attempt to access HSM partition with Admin credentials, HSM appliance erase its HSM partition.
– Enable CloudTrail will send event to S3 bucket in 5 minutes. Data captured: Info about every API calls, location of that call, either console, CLI, SDK; captures console sign-in events, create log record every time AWS account owner, federated users, IAM user sign-in.
– CloudTrail access can be limited to only certain users via IAM.