AWS IAM 웨비나 정리

Jinny·2020년 11월 11일

IAM aws

AWS IAM을 통한 클라우드 에서의 관리

AWS IAM으로 뭘 할 수 있나?

서비스와 리소스에 대한 액세스를 안전하게 관리
사용자 및 그룹을 만들고 관리
권한을 사용해 리소스에 대한 액세스를 허용 및 거부

IAM Policy

Policy는 AWS 서비스와 리소스에 대한 인가 기능을 제공

Policy를 정의할 때는 어떤 IAM Principal이 어떤 Condition에서 AWS의 어떤 Resource에 대해 어떤 Action을 허용 혹은 차단할 것인지를 지정

aws에서 일어나는 모든 API call은 IAM에 의해서 제어된다.

사용자 vs 그룹

그룹은 동일한 권한을 가지는 사용자에게 권한을 설정하는것을 편리하게 하기 위함이지 그룹에 보안 주체가 될 수는 없다. 사용자는 최대 10개의 그룹에 속할 수 있다.

IAM Policy의 종류와 사용 목적

종류
- Identity 기반 정책 (SCP, Permission Policy, Permission Boundary, Session Policy등은 사용자나 role등의 principal에 할당) - 사용자 관점에서 누가 무엇을 할 수 있는지
- Resource 기반 정책 (Bucket Poclicy, Access Control List등은 서비스에 할당되는 policy) - 서비스 입장에서 나에게 누가 요청할 수 있는지 대상을 지정할 수 있음

IAM Policy의 구조

{
  "Statement":[{
    "Effect":"Allow or Deny",
    "Principal":"principal",
    "Action":"action",
    "Resource":"arn",
    "Condition":{
      "condition":{
        "key":"value"
      }
    }
  }]
}

Effect : 명시된 정책에 대한 허용 혹은 차단

Principal : 특정 서비스에 대해 접근을 허용 혹은 차단하고자 하는 대상(보안 주체. 누가 적용할 건지)

Action : 허용 혹은 차단하고자 하는 접근 타입 (API call. 뭘 할건지)

Resource : 요청의 목적지가 되는 서비스 (API call의 목적지가 되는 서비스. 누구한테 적용할 건지)

Condition : 명시된 조건이 유효하다고 판단될 수 있는 조건

"Condition":{
  "DateGreaterThan": {"aws:CurrentTime" : "2017-01-01T11:00:00z"},
  "DateLessThan" : {"aws:CurrentTime" : "2017-12-31T15:00:00z"},
  "IpAddress": {"aws:SourceIp" : ["192.0.2.0/24", "203.0.113.0/24"]}
}

2017.01.01 11:00 이후 AND 2017.12.13 15:00 이전 AND 요청이 들어온 IP 주소 대역이 192.0.2.0/24 OR 203.0.113.0/24 범위 내에 있음

권한 할당 매커니즘

우선권 순위

API 요청 ➡️ 명시적 Deny ➡️ Permission Boundary ➡️ Permission Policy

하나라도 Deny되면 요청 차단됨

명시적 Deny : 명시적으로 Allow or Deny 하는지 (Effect에 나와있어)
묵시적 Deny : Allow 내용을 쓰지 않으면 일단 다 Deny 되어있어. On-premise에서 방화벽 Default Deny 정책과 유사 (Permission Boundary랑 Permission Policy)

AAA

Authentication(인증)
- 사용자 이름 / 패스워드 (+MFA)
- Access Key (+MFA)
- Federation
Authorization(권한.인가)
- aws IAM Policy (JSON 형식)
  - 유저 기반 정책(이 유저가 무엇을 할 수 있는지)
  - 리소스 기반 정책(이 리소스에 누가 접근할 수 있는지) - 붙였다 뗐다 어려워 (S3, Glacier, SNS, SQS, VPC등..)
Audit : 감사(로그)
- aws cloudTrail : 모든 Log를 모아 한 곳으로
  - 모든 리전의 로그를 하나의 S3 버킷에 통합 저장
  - 계정 단위로 이벤트 기록
  - KMS 통해 로그 파일 암호화 가능
  - 위변조에 대비하기 위해 Log File Integrity 체크 가능

Policy enforcement

평가의 기본값은 Deny
적용 가능한 모든 정책을 검토 및 평가
명시적 Deny 가 존재하는가?
1. YES : 최종 결정 = "Deny" (명시적 Deny)
2. NO : 허용(Allow)이 있는가?
  1. YES : 최종 결정 = "Allow"
  2. NO : 최종 결정 = "Deny" (기본값 Deny)

Policy Generator 를 통해 GUI로 AWS IAM 정책을 만들 수 있어

Policy Simulator 를 통해 만들어둔 정책들을 테스트해 볼 수 있어

IAM Role

작업과 리소스에 대한 액세스를 부여하는 권한 세트
정의된 권하을 다른 사용자나 서비스로 위임
AWS IAM users 또는 AWS services는 role에서 정의된 권한범위 내 AWS API를 사용할 수 있는 temporary security credentials를 얻을 수 있음
사용 예시 :
- EC2 role
- Federations : Cross-Account, SAML2.0, Web Identity Provider
장점
- 보안 자격증명을 공유할 필요가 없음 (보안 향상)
- 언제든지 접근 권한 회수 가능(강력한 권한 제어)
- 각 사용자에게 매번 필요한 권한을 일일이 부여할 필요 없음

AWS IAM 모범 사례

개별 사용자 생성
강력한 암호 정책 설정
보안 자격 증명을 정기적으로 순환 (Credential Report 확인)
권한이 있는 사용자에 대해 MFA 활성화
권한 관리에 그룹 사용
최소한의 권한만 부여 (정기적으로 Access Advisor 확인)
접근제어를 공유하기 위해 AWS IAM Role 사용

Role은 다음의 경우에 사용:
- 계정 간 접근 권한 위임
- 동일 계정 내에 접근권한 위임
- 연동된 사용자(federated users)
Amazon EC2 instances에 AWS IAM Role 사용
API 호출 로그를 얻기 위해 AWS CloudTrail 활성화
Reduce or remove use of root

:smiley:

AWS IAM 은 AWS 계정과 AWS 리소스들에 대해 누가 어떤 것을 할 수 있는지를 제어하고 관리
AWS IAM 자격 증명 연동을 사용하면 AWS IAM 사용자를 생성하지 않고 외부 자격 졍믕여로 AWS 계정의 리소스에 안전하게 액세스할 수 있다.

➕ 내가 추가로 공부한 내용

1️⃣ Policy에서 연결 대상에 따라 자격 증명 기반 정책 과 리소스 기반 정책 으로 나뉨

자격 증명 기반 정책은 이 정책이 적용된 사용자,그룹, 역할 이 보안의 주체로 principal이 없어. IAM policy 메뉴 또는 IAM Role 인라인으로 관리한다.

리소스 기반 정책은 어떤 리소스가 어떤 리소스를 이용(action)할때 정하는 정책으로 principal 존재. 대표적으로 S3나 SQS에서 사용한다. 즉 일부 공유자원 성격을 가진 서비스에서 사용

2️⃣ ARN : AWS의 리소스를 고유하게 식별하는 아이디 같은 거

형식 : arn:aws:(서비스 prefix):(AWS 리전 이름): (AWS 계정):(리소스 한정자)

Jinny

Devops, AWS에 관심있어요.

이전 포스트

codepipeline 구성하기 (deploy + build)

다음 포스트