[AWS] IAM(Identity and Access Management)

 

 

 

 

AWS IAM (출처 : aws.amazon.com) - 핵심은 누가/무엇을/어떻게 할지에 대한 인증과 인가를 제어

* IAM (Identity and Access Management)

• AWS 리소스 보안을 목적으로 일반 사용자를 대상으로 한 인증(로그인) 및 권한 부여 대상을 제어하는 서비스
• 쉽게 말해 AWS 서비스 중 누가(Who), 어떤 서비스(What)를 어떻게(How) 권한을 통제 받아 사용 할 지 정하는 것

 

 

 

 

 

* IAM 관리 리소스

IAM 관리 리소스 요약도

• 사용자 (Users)
  • 인증을 위한 각각의 대상
  • AWS 개별 계정이 아닌, 하나의 AWS 계정에서 만든 IAM 사용자 계정(또는 계정들)
  • 각 사용자는 고유의 AWS Management Console Access Password를 가질 수 있음(개별 액세스 키 생성도 가능)
  • AWS 외부(온프레미스 등)에서 기존 자격 증명과 IAM을 연동하여 추가 IAM User 생성 없이 사용 할 수 있음
    (단, 연동 사용자는 영구적 ID가 부여되는 것이 아닌, 임시 권한이 부여됨)

---

• 역할 (Roles)
  • IAM User나 특정 AWS 서비스에 역할을 기반으로 한 권한 설정이 가능 (RBAC - Role Based Access Control)
  • 역할을 할당 받은 유저나 서비스가 요청의 주체가 됨
  • 귀속 없이, 요청에 따라 할당하는 방식으로 임시 보안 자격 증명을 STS(Security Token Services)를 통해 요청 가능
  • 요청한 자격 증명은 세션이 유효한 시간 동안 이용 할 수 있음
  • RBAC의 경우 직무에 필요한 최소 권한 부여 방식이 권장
    (ABAC - Attribute Based Access Control이라는 방식도 존재)

---

• 정책 (Policy)
  • 권한을 부여하는 리소스로 높은 빈도에서 낮은 빈도의 정책 유형을 나열할 시 아래와 같음
    • 자격 증명 기반 정책
    • 리소스 기반 정책
    • 사용 권한 경계(Permission Boundary)
    • Organizations SCP
    • ACL (Access Control List)
    • Session Policy

---

• 그룹 (Groups)
  • 동일한 권한을 가진 여러 IAM 사용자들을 그룹으로 구성하여 권한을 효율적으로 배포하기 위한 틀 (그룹핑)

 

 

 

 

 

* IAM 사용 권장 사항

• AWS 계정 루트 사용자 액세스 키 잠금
  • 액세스 키를 기반으로 프로그래밍 식으로 AWS에 요청이 가능
  • 단, 루트 사용자 계정의 경우 액세스 키 사용을 권장하지 않음
  • 루트 사용자는 AWS 결제 정보, 전체 리소스의 액세스 권한을 보유함을 이유로 함
  • 루트 사용자 액세스 키는 삭제 (유지가 필요하다면 주기적 교체) 
  • AWS 루트 계정의 경우 강력한 암호 및 MFA(멀티 팩터 인증)을 반드시 활성화하길 권장 
    • 즉, 특별한 경우를 제외, 루트 계정을 사용하지 않고서 보안 강화를 적용 후, IAM 관리 계정을 따로 생성하길 권장

---

• RBAC을 통한 권한 위임
  • IAM 사용자의 경우 특정 Task(작업별) 별도 역할을 구성하여 역할 별 권한을 받도록 지정
    • STS(Security Token Service - 임시 보안 자격 증명) 또는 AWS Management Console을 사용해 역할 기반 접근 제어를 수행하도록 적용
  • 외부 사용자의 경우 IAM 사용자 계정을 따로 생성하지 않고, SSO(Single Sign-On)을 통해 SAML(Security Assertion Markup Language) 2.0을 연동하여 사용하는 등 세션과 권한을 제한적으로 제공
    • 즉, IAM 사용자의 경우 작업별 역할 구성 / 외부 사용자의 경우 임시 권한 할당을 통해 제한적 접근

---

• 최소 권한 부여
  • IAM 정책 생성 시, 특정 작업 만 수행하도록 최소한의 권한만 부여하며, 필요에 따라 추가 권한을 부여함
    
    • AWS 공식 홈페이지의 내용을 요약하자면 결국 세부적으로 컨트롤 해라... 라고 요약할 수 있음

---

• AWS 관리형 정책으로 권한 사용
  • AWS에서 직접 생성 및 관리하는 독립적인 정책(사용자가 IAM처럼 생성 하는것이 아니므로 할당은 가능하나, 변경은 불가능) 
  • 최소 권한 부여의 대안으로 AWS 관리형 정책(ARN - Amazon Resource Number를 보유한 정책)을 통해 특정 서비스별(e.g. DynamoDBFullAccess, IAMReadOnlyAccess etc)로 전체 액세스 권한을 부여 하여 세부적으로 컨트롤 하는 방법

---

• 정책 검증
  • IAM 정책을 생성(JSON 구문 사용) 후 구문 오류를 식별
    • IAM Access Analyzer를 통해 100개 이상의 정책 확인 항목과 실행 가능한 권장 사항을 제공 받을 수 있음

---

• 인라인 정책 / 고객 관리형 정책 사용
  • 유형
    • 고객 관리형 정책 : 각자의 AWS 계정에서 해당 관리형 정책을 추가, 관리 하는 방식
    • 인라인 정책 : IAM 자격 증명을 기반으로 User, Group, Role에 직접 관리형 정책 권한을 추가하는 방식
  • 사용자는 권한 제어 시, 인라인 정책으로 할지 관리형 정책으로 할지 결정 한 후 사용해야함

---

• 액세스 수준을 이용한 IAM 권한 검토
  • 주기적 IAM 정책 검토
    • 정책은 3가지 테이블 (정책 / 서비스 / 작업)의 3가지로 요약
      • 정책 요약 : 사용자 페이지에서 사용자에게 연결된 정책 요약 (Deny or Allow)
      • 서비스 요약 : 정책 요약에 있는 각 서비스에 대한 요약 (List, Read, Write, Permission management)
      • 작업 요약 : 각 작업(Task)에 대해 부여한 권한을 요약

---

• 사용자 암호 기준 강화
  • 사용자 지정 암호 정책을 통해 주기적으로 강력한 암호를 생성, 교체 하도록 요구
  • 암호 정책

---

• MFA 활성화
  • 소속된 모든 사용자에게 멀티 팩터 인증(MFA)를 요구 (일종의 OTP)

---

• EC2에서 실행되는 애플리케이션에 역할 사용
  • EC2의 경우 실행 시, 파라미터로 인스턴스에 대한 역할을 지정하여, 임시 자격 증명을 제공
  • EC2에서 실행되는 애플리케이션은 다른 AWS 리소스에 액세스 할 시, 위 역할 기반의 임시 자격증명을 사용

---

• 액세스 키 공유 금지
  • AWS 루트 사용자 또는 IAM 사용자의 장기 자격 증명으로 AWS CLI 또는 API에 대한 프로그래밍 요청 자격 증명으로 사용 됨
  • 액세스 키를 암호화 되지 않은 코드에 삽입하거나, 오픈 된 공간에 공개 하는 등의 공유성 행위 금지
  • 실수로 공유해서 해킹 당해 요금 폭탄을 맞았다 어쩌구... 라는 사례가 빈번(특히 Github 같은곳)

---

• 자격 증명을 정기적으로 교체
  • 암호화 액세스 키 정기적 교체
  • 사용자 지정 암호 정책을 통해 주기적으로 암호 교체를 요구

---

• 불필요한 자격 증명 삭제
  • 자격 증명 보고서를 다운로드하여 미사용 암호나 액세스 키를 확인, 기준에서 벗어날 시 삭제 처리 할 수 있음

---

• 보안 강화를 위한 정책 조건 사용
  • 액세스 가능 IP 주소 범위 지정
  • SSL 또는 MFA 사용 강제 등
    • IAM JSON 정책 중 Condition 요소 사용

---

• AWS 계정 활동 모니터링
  • AWS 로깅 기능을 통해 사용자의 수행 내역(작업, 사용 리소스 등) 확인
    • 로그 파일 : 작업 시간 및 날짜, 작업의 Source IP, 권한 부족으로 인한 실패 작업 내역 등
  • 로깅 기능 제공 AWS 서비스
    • CloudFront
    • CloudTrail
    • CloudWatch
    • AWS Config
    • S3