IAM Users & Groups

  • A group can NOT be assigned to another group

MFA

  • Can be enabled not only Root user account, but also ALL IAM user accounts.

[SAA + SAP] 01. IAM[SAA + SAP] 01. IAM

 

IAM Security Tools

  • IAM Credentials Reports (account-level): report all your account's users and the status of their various credentials
  • IAM Access Advisor (user-level)
    • Show the service permissions granted to a user and when those services were last accessed. (4 hours)
    • You can use this information to revise your policies.

[SAA + SAP] 01. IAM

 

 

 

[SAA + SAP] 01. IAM 

  • AWS Managed Microsoft AD: Enabled MFA, auth both directions
  • AD Connector: Proxy, auth On-perm
  • Simple AD: no on-perm AD

[SAA + SAP] 01. IAM

 

Service Control Policies (SCP)

  • Whitelist or blacklist IAM actions
  • Applied at the OU or Account level
  • Does not apply to the Master Account
  • SCP is applied to all the Users and Roles of the Account, including Root.
  • The SCP does not affect service-linked roles
    • Service-linked roles enable other AWS services to integrate with AWS Organizations and cannot be restricted by SCPs.
  • SCP must have an explicit Allow (does not allow anything by default)
  • Use cases:
    • Restrict access to certain services (for example: cannot use EMR)
    • Enforce PCI compliance by explicityly disabling services

[SAA + SAP] 01. IAM

  • Always account looks up OUs SCP.
    • Account A, has Root OU and Prod OU
    • From Root OU, Account A can access anything
    • From Prod OU, Account A cannot access Redshift
    • Even though, Account A has AuthorizeRedshift SCP, but OU deny, OU Wins over Account.
  • To summarize, we've inherited stuff from the root OU and the SCP applied to the Master account, To Deny anthing does not apply.
    • OU allows, Account deny, always OU wins

[SAA + SAP] 01. IAM

 

Policy Evaluation Logic

  • User can access one service or not, can based on multi factors
    • OU's SCP
    • Permission boundaries
    • Resouce-based policy
    • Identity-based policy

[SAA + SAP] 01. IAM

[SAA + SAP] 01. IAM

 

AWS Resource Access Manager (RAM)

  • Share AWS resources that you own with other AWS accounts
  • Share with any account or within your Organization
  • Avoid resource duplication
  • VPC Subnets:
    • Allow to have all the resources launched in the same subnets, but must be from the same AWS Organizations
    • Cannot share security groups and default VPC
    • Can only manage their own resource
    • Can NOT view, modify, delete resouces that belong to other paticipants or the owner
  • AWS Transit Gateway
  • Route53 Resolver Rules
  • Liencse Manager Configuations

[SAA + SAP] 01. IAM

  • A shared VPC subnet, each account can have his own resouces. 
  • Resouces in different account can communicate with private IP
  • Can ref SG in other account

SSO

[SAA + SAP] 01. IAM

 [SAA + SAP] 01. IAM

[SAA + SAP] 01. IAM

  • Sign in to multi accounts with SSO

 

SAP

IAM policies

  • Best practice: use least privilege for maximum security
    • Access Advisor: Granted and when last accessed
    • Access Analyzer: Analyze resources that shared with external entity

NotAction

  • In case you don't want to deny all the action in one service, you can use "NotAction"

[SAA + SAP] 01. IAM

By default, NotAction doesn't allow any action on "iam:*", "organizations:*" and "account:*", then "Alllow" Action enables "createServiceLinkedRole"....

 

[SAA + SAP] 01. IAM

 

[SAA + SAP] 01. IAM

 

IAM Roles vs Resource Based Policies

There are two ways to access S3 in Account B for Account A; 1: assume role, 2: resource-based

[SAA + SAP] 01. IAM

  • When you assume a role, you give up your original permissions and take the permissions assigned to the role.
  • When using a resource based policy, the principla doesn't have to give up any permissions.
  • Example: User in a Account A needs to scan a DynamoDB table in Account and dump it in an S3 bucket in Account B. 
    • In this case, because user assume role in Account B, therefore has to give up the original role
    • Therefore he cannot access to DynamoDB in Account A anymore.
    • Therefore, it make senses to use Resource based policy in this case.

 

STS

Use cases:

  • Provide access to an IAM user in Your or Another AWS account That you OWN
  • Provide access to IAM users in AWS accounts owned by third parties
  • Provide access for services offered by AWS to AWS resources
  • Provides access for extrnally authenticated users (identity federation)
  • Ability to revoke active sessions and credentials for a role (Uing time statement - AWSRevokeOlderSessions)

 [SAA + SAP] 01. IAM

Example: You need to assume a Role to Terminate EC2 instance, in your own account. Adding an extra security, MFA.

 

[SAA + SAP] 01. IAM

 

[SAA + SAP] 01. IAM

If you give third party assume role access to your account, you MUST use External ID, to provide extra secruity to prevent "Confused deputy" attack.

[SAA + SAP] 01. IAM

 

[SAA + SAP] 01. IAM

 

Identity Federation & Cognito

  • Federation lets users outside of AWS to assume temporary role for accessing AWS resources
  • There user assume identity provided access role
  • Using federation, you don't need to create IAM users
  • Federations can have many flavors:
    • SAML 2.0 (being replaced by SSO)
    • Custom Identity Broker
    • Web identity Federation with Amazon Cognito
    • Web Idenetity Federation without Amazon Cognito
    • Single Sign On (replacing SAML 2.0)
    • Non-SAML with AWS Microsoft AD

[SAA + SAP] 01. IAM

[SAA + SAP] 01. IAM

 

[SAA + SAP] 01. IAM

Using Identity Broker if your backend is NOT compatible with SAML 2.0.

 

[SAA + SAP] 01. IAM

Perfer Cognito.

 

[SAA + SAP] 01. IAM

IAM policy variable for WIF.

 

Microsoft Active Directory (AD)

  • Windows server with AD Domain services
  • Database of objects: User Accounts, Computers, Printers, File Shares, Security Groups
  • Centralized security management, create account, assign permissions.
  • Objects are organized in tree
  • A group of trees is a forest.

[SAA + SAP] 01. IAM

 

[SAA + SAP] 01. IAM

 

[SAA + SAP] 01. IAM

Two ways Forest trust is not replaiction. Users on On-Premise and AWS AD are independent. On-premise users can access AWS AD successfully becasue of the Trust.

 

[SAA + SAP] 01. IAM

To reduce the latency or in case DX / VPN goes down, we can set up replication on AWS EC2 and establish Trust between AWS AD and EC2.

 

Organizations

  • Consolidated billing features
    • Consolidated Billing across all accounts -  single payment method
    • Pricing benefits from aggregated usage (volume discountn for EC2, S3..)
  • All Features (Default):
    • Includes consolidated billing features
    • You can use SCP
    • Invited accounts must approve enabling all features.

Reserved Instances

  • Reverved instnances can be shared with all the account in Organization
  • You can disabled it
  • To have cost saving

 

SSO

[SAA + SAP] 01. IAM

Users can be managed directly inside SSO. Or users can be managed in On-Premise AD. 

3 options for integrations with AD.

 

[SAA + SAP] 01. IAM

We can need to directly communicate with STS by using SSO.

 

相关文章:

  • 2022-02-09
  • 2021-06-12
  • 2021-08-05
  • 2021-10-26
  • 2021-09-15
  • 2021-11-27
  • 2021-11-20
  • 2021-10-28
猜你喜欢
  • 2021-08-29
  • 2021-08-15
  • 2021-05-17
  • 2022-03-10
  • 2021-08-09
  • 2021-09-05
  • 2021-06-22
相关资源
相似解决方案