[AFOS] 5주차 보안 서비스

1. Why Security : aws 상의 보안 - IAM

AWS 사용 방법 3가지 : AWS Web Console, CLI, SDK(+CDK)

• Web console (Console 기반 작업)

1. 쉽게 시작할 수 있다.
2. 반복 작업에 적합하지 않다
3. 시간이 오래 걸린다

---

• CLI (Script 기반)

1. 반복 작업에 적합하다
2. 원하는 항목에 대한 수정이 용이하다.
3. 리소스의 준비 상태 확인이 어렵다.
4. 문제 발생 시 복원이 어렵다.

---

• SDK (프로비저닝 엔진 사용)

1. 자동화 구현에 용이하다.
2. 반복 작업에 적합하다.
3. 에러 발생시 원복이 쉽다.
4. 최초 구현이 복잡하다.

---

• CDK (DOM 기반 - 링크)

1. 코드 기반
2. 원하는 형상에 대한 정의
3. 초기 코딩의 복잡성

---

 

한가지 중요한 공통점 => 결론은 API (Everything API) : API 개념 공부할것

• 클라이언트가 AWS 리소스에 보내는 모든 조회/업데이트/생성/삭제 요청은 모두 API로
• AWS 자원들끼리 주고받는 요청과 응답도 모두 API 형태

---

AWS 에서의 API 인증 방식

• AWS에서의 모든 자격증명은 Access Key ID 및 Secret Access Key(비밀키)의 모습
• Secret Access Key는 노출이 되면 안되므로 Secret Access Key를 가진 사람만 생성할 수 있는 HMAC서명 값 포함
• (+) IAM role과 같이 임시 Credential을 쓰는 경우에는 Session Token 추가

예시

1. 요청이 DynamoDB에 도착하면 AWS는 요청 내용과 비교하여 서명값을 확인
2. 해당 타임스탬프와 같은 것을 확인
3. 이 Credential이 적절한 권한을 가지고 있는지 판단
4. 허용 여부 결정

---

AWS의 shared responsibility model

• 어떤 환경을 사용하더라도 AWS IAM이 필요하고 관리 주체와 책임은 고객
• 애플리케이션의 구조, 기업의 인력 구조에 따라 액세스 권한이 달라지기 때문에 IAM 구성은 고객이 해야함

---

---

2. AWS IAM(Identity and Access Management)

AWS Identify and Access Management : 인증 + 인가

• AWS 전체의 권한 통제 시스템
• 인증 : 누구냐?
• 인가 : 권한있냐?

---

Access Control 개념

UBAC (User-Based Access Control)

• 가장 단순하게 권한을 사용자에게 직접 부여
• 사용자가 많아지면 권한 관리가 지루하고 엉성해짐
• 같은 권한이 있는 사람들끼리 그룹으로 묶어보자

GBAC (Group-Based Access Control)

• 그룹에다 권한을 주고 사용자를 그룹에 넣음
• 권한이 다양해지면 그룹이 복잡해짐
• 같은 권한이 여러 그룹에 포함되면서 권한 검사가 어려워짐
• 역할이라는 개념을 만들어보자

RBAC (Role-Based Access Control)

• 그룹에다가 권한을 바로 주는 대신에 권한의 논리적 집합으로서 역할을 만듬
• 만든 역할을 그룹이나 사용자에게 연결
• 권한 검사를 할 때 Group에 대해서 조건을 거는 것 보다, Role에 대해 규칙을 설정하는 것이 쉬움
• AWS에서는 IAM Group보다 IAM Role 지정이 많다

ABAC (Attribute-Based Access Control)

• PBAC (Policy-Based) 와 혼용되기도함
• 미세한 접근 제어가 필요하다
• 조건문 형식의 권한 부여를 해보자
• 사용자가 가진 속성을 조건으로 정책(Policy)을 만들자
• IAM 의 Policy 와 같은 개념

출처 : https://musma.github.io/2019/11/05/about-aws-iam-policy.html

---

IAM User

• root user
  1. 계정을 생성할 때 사용한 이메일 계정과 동일한 루트 유저
  2. 너무 많은 권한을 가지고 있고 권한제어가 불가능한 슈퍼 유저
  3. 보안상 매우 취약한 계정

• IAM user
  1. Username / Password를 입력하여 콘솔 로그인
  2. 장기(상시) Credential을 사용하여 서비스에 접근하는 보안 주체

---

IAM Role

• 자동으로 로테이션되는 임시 Credential 사용
• 장기 Credential은 Access key 와 Secret key로 이루어진데 반해 임시 Credential은 +일정시간이 지나면 만료되는 Token이 함께 구성되어 발급
• 이 역할을 사용하는 것을 Assume 한다고 표현
• Assume을 하여 임시 Credential을 발급받아 특정 액션 수행 가능
• 활용 예시
  1. EC2 Role - 인스턴스/타 서비스 : AWS 서비스(EC2, Lambda)가 사용자 대신 접근 실행 - 링크
  2. 외부사용자(AWS 외부에 존재하는 사용자를 위해 임시 자격증명 사용, 혹은 다른 Account에 접근 사용할 때) - Federations(연계된 사용자) : Cross-Account(교차 계정 접근 제어), SAML2.0, Web Identity Provider (정확히 뭔지 모름)

---

Policy

• 모든 AWS 서비스는 접근제어 정책을 기반으로 인가
• AWS 내에서 할 수 있는 액션을 Json 형태로 쭉 기술해 놓은 Permission 문서
• AWS에 요청하는 모든 API 호출은 매번 이 정책을 통해 인가가 수행
• Role, User, AWS 서비스 자체에 연결 가능
• 다양한 액션(어떤건 허용, 어떤건 차단) 자유롭게 기술 가능 : 디폴트가 Deny, 명시적 Allow보다 명시적 Deny 가 우선 순위
• Policy 의  JSON 구조 - IAM JSON 정책 요소 참조

 

 

• ARN(Amazon Resource Name)
  1. AWS 리소스를 고유하게 식별
  2. 모든 AWS 리소스는 고유한 자신의 ARN을 소유 
  3. arn:aws:[서비스 이름]:[AWS 리전 이름]:[AWS 계정]:[리소스]
     
     • Amazon EC2 instance
       arn:aws:ec2:us-east-1:123456789012:instance/i-1a2b3c4d
     • Amazon RDS tag
       arn:aws:rds:eu-west-1:001234567890:db:mysql-db

---

요청의 성공 조건 : 인증 + 인가

• IAM 보안 주체의 서명 값을 보고 요청을 처리할지 결정 (인증)
• and 조건으로 Permission Policy를 보고 권한 확인 (인가)

---

IAM 정책의 종류

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/access_policies.html

 

• 가장 많이 사용되는 Identity-based, Resource-based 정책에 대해 조금 더 알아보자

Resource-based 정책에는 principal 구문이 필수적으로 들어가야함

 

• Identity-based 정책 : 요청하는 주체에게 연결 -> 접근을 하기 위한 정책
• Resourced-based 정책 : 요청을 받는 리소스에게 연결 -> 접근을 받기 위한 정책
  • principal 구문이 필수 (누가 어떤 것을 할 수 있는지 없는지)

 

• 두 정책의 적용 범위는 In-account 인지 Cross-account(교차 계정 접근 제어)인지에 따라 다름
  1. 하나의 요청을 허용 또는 차단하기 위한 정책을 양쪽(Identity, Resourced)에서 기술한다면?
     • In-account : 합집합
     • Cross-account : 교집합

 

---

---

3. AWS IAM Best practice

루트 잠그기

• AWS 계정 root 사용자 액세스 키 잠금(삭제하거나 in-active)
• 권한 있는 사용자에 대해 MFA 활성화

---

IAM 사용자 관리

• 개별 IAM 사용자 만들기
• 그룹을 사용하여 IAM 사용자에게 권한 할당

---

자격 증명을 정기적으로 교체

• 콘솔이나 Credential Report를 통해 교체 주기 지난 IAM사용자의 자격증명을 파악하여 조치

---

최소 권한 부여

• Access Advisor 사용 
• ACcess Analyzer 사용 - 링크
• 일정 기간 또는 한번도 접근 안한 서비스들에 대한 권한은 점차적으로 회수할 것을 권장

---

서비스 간 권한 제어에 역할 사용

• IAM Role을 부여하는 액션 자체에도 제어가 필요함
• 오른쪽 정책은 개발자에게 부여한 정책 - ec2 시작 권한, IAM Role 부여 권한(iam:Passrole)

결과적으로 EC2가 특정 IAM 역할만 부여받을 수 있음

---

Role을 사용하여 권한 위임

• A account 의 EC2가 B account의 DynamoDb에 접근하려함(Cross account 환경)
• Identity-based + Resource-based policy를 사용할 수도 있지만 Cross Account role 사용도 가능

 

1. A account 의 EC2는 다른 account 의 IAM 역할을 Assume할 수 있는 정책을 부여,
2. B account에는 DynamoDB에 접근할 수 있는 권한을 가진 IAM 역할을 만들고
3. 거기에 A account가 Role을 Assume 할 수 있께 신뢰 정책 추가 
   • -> 장기 Credential 사용하는 것 보다 훨씬 안정하게 Cross account 접근 가능

---

보안 강화를 위해 정책 조건 사용 : and, or 조건

• Condition 구분 사용 

  

---

IAM 모범 사례 - https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/best-practices.html

IAM의 보안 모범 사례 - AWS Identity and Access Management

 

---

---

4. AWS IAM advanced

AWS 계정의 활동 모니터링 및 감사

• AWS CloudTrail : API 활동 기록, 감사 활동의 핵심
• AWS IAM Access analyzer : 외부 entity와 공유되는 리소스 식별
• Amazon GuardDuty : 위협탐지 서비스
• AWS Security Hub : 통합 대쉬보드

 

---

속성 기반 접근 제어

• IAM 보안 주체의 요소인 태그를 이용해서 단일 policy로 각기 다른 리소스에 재사용 가능한 접근 제어를 구상
• 동적인 권한 부여 가능

---

인증 범위를 클라우드 외로 확장가능

• Cross account
• 온프레미스 환경과의 연결 가능 - Active Directory와 같은 솔루션으로 SSO를 사용하는 상황에 AWS 편입 가능
• SAML, OpenID Connector를 이용한 소셜인증도 지원

---

 

Key takeaways (중요 포인트, 총정리?같은 개념)

• Everything API, AWS 사용자들에게 IAM은 피할 수 없는 숙명
• IAM의 인증과 인가
• 정책의 구조와 종류
• IAM 운영은 모범 사례에 맞춰서
• Beyond IAM, 워크로드 보안

 

출처 : https://www.youtube.com/watch?v=zIZ6_tYujts&ab_channel=AmazonWebServicesKorea
슬라이드 : https://www.slideshare.net/awskorea/aws-iam-aws-aws-builders-online-series