AWS Security Best Practices Part Five

Continuing on from the first, second, third and fourth blog posts about Incident Response and Logging & Monitoring and Infrastrucutre Security available here Part Onehere Part Twohere Part Three and here for Part Four. This blog post moves into the important area of Identity & Access Management best practices and gotchas to avoid.

As with the other blog posts peppered in them are some photos from the Astronomy Photographer of the year awards at the Greenwich Maritime Museum. Why? Cos they are cool and interesting.

Feeling small in the Universe yet?

Identity & Access Management

  • In AWS, all the policy decisions start with the “DEFAULT DENY” rule.
  • IAM will then evaluate all the policies that are attached to the principal who is performing the activity (user/group/role).
  • If there is an EXPLICIT DENY (user-defined deny policy) mentioned in the IAM policies associated with the access is immediately denied.
  • If no explicit deny is mentioned in the policies, the next step is to check if there are any allow policy is present, then you will be allowed to operate.
  • If no explicit allow policy is present, then the final decision would be denied.
  • EXPLICIT DENY policy ALWAYS TAKES HIGHER precedence over EXPLICITLY ALLOW POLICIES.
  • IAM Policies
    • JSON Based objects define the permissions of the entity they are being attached to.
    • Two policy types
      • Identity-based policies
        • Policies that can be attached to a principal (or identity), such as an IAM group, user, or a role.
        • These policies define the actions that can be performed and on which resources.
        • The principle is the IAM user to which the policy is attached to or the user who gets the policy is attached to or the user who gets the policy from the group. Thus, it is not required to be mentioned explicitly for identity based policies.
        • Can be further categorised.
          • Managed policies
            • Standard identity-based policies that can be attached to multiple users, roles and groups.
            • The can be further classified into AWS managed policies & customer managed policies.
          • Inline policies
            • These are custom policies embedded directly into a single user, group or role.
    • Resource-based policies
      • JSON Documents that can be attached to the AWS resources, such as an S3 bucket.
      • Have to define which started who is allowed to access the resource.
    • Overview of JSON Policies
      • Easily create policies with the help of the new visual editor that AWS provides.
    • Understanding JSON policies
      • When assigning a permission to an IAM user, role or group, you have to attach a JSON based policy, which is also referred to as an IAM policy that defines the permission.
Ever got the feeling that something is watching over you?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close