Resource policies (for example, for DynamoDB, Amazon S3, and AWS Key Management Service [AWS KMS])

Can you describe what an IAM policy is, and how it differs from a resource-based policy like those used in DynamoDB or S3?

An IAM policy is an entity that, when attached to identities (users, groups, or roles), defines their permissions. It specifies what actions are allowed or denied on which AWS resources. IAM policies are centralized and focus on who (the identity) can do what (actions) to which resources. Resource-based policies, like those for DynamoDB or S3, are attached directly to the resources and specify which principals (accounts, users, roles, or federated users) are allowed to perform which actions on the resource. Resource-based policies offer a decentralized way of managing permissions and can grant cross-account access without using roles.

How would you secure sensitive data in an S3 bucket using policies?

To secure sensitive data in an S3 bucket using policies, I would implement the following measures:

• Implement bucket policies to define which principals can access the S3 bucket and what actions they can perform.
• Use S3 Block Public Access to prevent unintentional public exposure.
• Employ S3 encryption (SSE-S3, SSE-KMS, or SSE-C) to protect data at rest.
• Optionally, utilize S3 Object Lock for WORM (Write Once Read Many) protection if the data must not be altered after creation.
• Enable access logging to monitor access requests to the S3 bucket.

What is the purpose of a condition in an IAM or resource-based policy?

A condition in an IAM or resource-based policy adds fine-grained control to the permissions defined in a policy. It allows you to specify circumstances under which the policy grants or denies permission. Conditions can include items like the IP address of the requester, the date/time of the request, whether MFA (Multi-Factor Authentication) is used, or the SSL/TLS requirements for the request. They are used to restrict permissions and enhance security.

Can you explain the key differences between an S3 bucket policy and an S3 ACL (Access Control List)?

An S3 bucket policy is a type of resource-based policy that allows you to manage permissions for a bucket and define what actions are allowed or denied across the bucket, including objects within it. It supports granting permissions to AWS accounts, IAM users and roles, and even anonymous users. Policy statements can include a variety of conditions for more granular control.

On the other hand, an S3 ACL is a legacy access control mechanism that allows you to manage permissions on a per-object or bucket level, providing read and write access to both buckets and objects. ACLs offer basic permissions and are less flexible than bucket policies.

What steps are involved in properly securing data access in DynamoDB using policies?

Properly securing data access in DynamoDB involves:

• Defining IAM policies that grant the least privilege needed to perform tasks, applied to IAM users or roles.
• Using DynamoDB fine-grained access control to control access to individual items or attributes within a table.
• Employing condition expressions in policies for more granular access based on attributes such as IP range, date/time, and other key factors.
• Enabling encryption at rest using DynamoDB encryption with AWS KMS to secure data.

How does AWS KMS integrate with resource policies, and what are the benefits?

AWS KMS integrates with resource policies (key policies) to control access to KMS keys. These policies define which principals can use the KMS key to encrypt and decrypt data. They can include conditions for added security. The benefits of using KMS with resource policies include central management of encryption keys, the ability to enforce cryptographic best practices easily, and detailed control over who can use keys, including the ability to grant cross-account access without the use of roles.

Describe a scenario where you would use a bucket policy over an IAM policy for S3?

A scenario where I would use a bucket policy over an IAM policy is when I need to enable cross-account access to the S3 bucket. Bucket policies allow for specifying permissions for users in other AWS accounts directly, whereas IAM policies are strictly tied to the identities in a single AWS account. This feature of bucket policies is particularly useful for operations like sharing data with business partners or allowing access to a logging bucket for multiple accounts.

What considerations should be taken when setting resource policies for AWS KMS?

When setting resource policies (key policies) for AWS KMS, one should consider the following:

• Ensure the key policy grants appropriate permissions only to necessary principals to maintain the least privilege.
• Use policy conditions to restrict access based on factors like source IP, encryption context, or date/time.
• Review and restrict the use of “kms:Grant*” permissions, which allow principals to delegate their permissions to others.
• Regularly rotate KMS keys if necessary, according to the organization’s security requirements.

Discuss how the principle of least privilege is applied when configuring resource policies for DynamoDB.

The principle of least privilege is applied in DynamoDB by ensuring that IAM policies and DynamoDB access control mechanisms grant only the permissions required for an entity to perform its defined tasks and no more. This involves using IAM policies to restrict access to certain actions, table-level access control for controlling which items and attributes a user can access, and using conditions in policies to impose further restrictions such as time-based access or IP restrictions. Fine-grained access control in DynamoDB further helps in adhering to the least privilege principle at the items and attributes level.

Is it possible to use a combination of IAM and resource-based policies to control access to an S3 bucket, and if so, how do they work together?

Yes, it is possible to use a combination of IAM and resource-based policies to control access to an S3 bucket. IAM policies are used to manage permissions for IAM users and roles within the same AWS account. These can specify which S3 actions a user or role can perform. Resource-based policies, such as S3 bucket policies, are used to grant permissions to a broader set of principals, including IAM users and roles from other AWS accounts.

When both types of policies are used, access to S3 buckets is granted only if both the IAM policy attached to the user or role and the bucket policy attached to the S3 bucket allow the action. If either policy denies access, the request will be denied. This allows for flexible cross-account sharing scenarios while still maintaining a layered approach to security.

What is the purpose of the “aws:SourceArn” condition key in resource policies, and can you provide an example of its use in an S3 bucket policy?

The “aws:SourceArn” condition key in resource policies is used to match the ARN (Amazon Resource Name) of the resource that is making the request. This condition key helps ensure that the policy is granting permissions to the correct resource. For example, in an S3 bucket policy, you can use “aws:SourceArn” to allow an SNS topic to trigger a Lambda function only if the notifications come from a specific S3 bucket. The policy snippet would look something like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"Service": "lambda.amazonaws.com"},
      "Action": "lambda:InvokeFunction",
      "Resource": "arn:aws:lambda:region:account-id:function:my-function",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:::my-source-bucket"
        }
      }
    }
  ]
}

How would you prevent accidental deletion of an S3 object or DynamoDB table using resource policies?

To prevent accidental deletion of S3 objects, you can use a combination of S3 Versioning and MFA (Multi-Factor Authentication) Delete feature. By enabling these, you can ensure that object versions are kept even after deletions, and that deletions require MFA confirmation. For DynamoDB, you cannot use resource policies to prevent deletions directly; however, you can set a very restrictive resource-based policy that explicitly denies “dynamodb:DeleteTable” action unless certain conditions are met (like MFA authentication or requests from certain IP addresses).