[SAA + SAP] 01. IAM

SAA

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.

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.
    • You can use this information to revise your policies.

 

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

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

  • 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

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

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

  • 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

 

  • 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"

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

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

  • 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)

 

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

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.

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

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

Perfer Cognito.

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.

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.

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

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

3 options for integrations with AD.

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

原文地址:https://www.cnblogs.com/Answer1215/p/14956445.html