[AWS] IAM

해당 포스트는 AWS IAM과 친해지기 - Amazon web services Korea의 조이정님 강의를 시청하고 작성되었습니다.

IAM이란? Identity and Access Management

→ AWS 리소스를 사용하기 위한 모든 요청은 IAM을 통해 이루어진다. 따라서 IAM은 워크로드를 지키기 위한 시작

AWS 상에서의 인증과 인가 그리고 감사 알아보기

✔ Why security?

1. 콘솔 기반 (쉬움/단순함 but 반복이나 대량 작업을 하기엔 적합하지 x)
2. script 기반 (반복작업에 적합하고 원하는 항목에 대해 수정이 용이 but 리소스의 준비 상태 확인이 어렵고 문제 발생시에 복원이 어려움)
3. 프로비저닝 엔진 사용 (자동화 구현에 용이, 반복작업에 적합, 에러 발생시 원상복구 쉬움 but 첫 구현이 복잡함) "infra as a code!"
4. DOM 기반 (내가 원하는 코드로 형상 관리 가능 but 초기 코딩에 대한 복잡성이 따라옴)

👉🏽 4가지 방법 중 어떤 방식을 사용하든 결국은 API로 프로젝션이 된다는 사실! 즉, 클라이언트가 AWS 리소스에 보내는 모든 CRUD 요청은 모두 API로 이루어진다는 말. 뿐만아니라, AWS 안에 있는 리소스들끼리 주고받는 요청과 응답도 모두 API 형태로 띈다는 점.

✔ How to authorize AWS on API?

본론부터 말하자면, AWS의 authorization은 AccessKey와 SecretKey 모습을 띄고 있음 (추가적으로 Credential 을 쓰는 경우에는 Session Token도 추가됨)

✔ AWS의 Shared Responsibility Model

: AWS에서 보안이 AWS와 고객이 함께 만들어나가야 함 → AWS가 제공하는 클라우드의 보안은 AWS가 책임을 지고, 그 위에 올라가는 데이터나 어플리케이션 즉, 클라우드 위의 보안은 고객이 챙겨야한다는 내용

• infrastructure services : 네트워킹/방화벽, OS, Application, AWS IAM, 고객 IAM, 데이터
• contrainer services : 방화벽 설정, AWS IAM, 고객 IAM, 데이터
• abstract services : AWS IAM, 데이터

👉🏽 이 부분은 회사의 규모나 프로젝트 규모에 따라 고객이 선택하여야 하는 것이기 때문에 그에 따른 보안도 고객이 사항에 따라 보안을 처리해주어야 함

✔ 본격적으로 AWS IAM

: 이러한 AWS 전체의 권한 통제 시스템

• Identity : WHO YOU ARE (클라이언트가 자신이 주장하는 사용자와 같은 사용자인지를 확인하는 과정 : 인증)
  • 실 사용자가 IAM 사용자인지 AWS에 들어오자마자 root user인지 확인하는 과정
  • 하지만 이 root user는 너무 많은 권한을 갖고 있는 superuser이기 때문에, 자유롭게 사용하기에는 취약한 계정임 → 이에 따른 AWS에서 직접 만들 수 있는 보안 주체가 있는데, 이게 바로 User/Role 과 같은 것들임.
  • 모든 보안 주체들은 AWS에 API를 요청할 때, accesskey와 secretkey로 구성된 credential을 포함해 인증을 받게 되는데, 이 때 IAM 사용자는 장기 credential을 이용해 서비스에 접근하는 보안 주체이다. 내가 명시적으로 credential을 로테이션 하지 않는 이상 이 자격증명은 영구적으로 유지됨!!!! 고로 코드안에서 이 자격증명을 사용하거나, 서버에 하드코딩을 하는건 보안에 굉장히 취약한 점임
  • 영구적인 credential을 보안하기 위한 대체제 → IAM ROLE : 정의된 권한 범위 내 AWS API를 사용할 수 있는 임시 자격 증명, 이걸 사용하면 사용자 권한을 공유하거나 매번 필요한 권한부여 할 필요가 없음
  • EX) EC2 Role, Federations - Cross-Account, SAML2.0, Web Identity Provider
• Access Management : WHAT YOU CAN DO (클라이언트가 하고자 하는 작업이 해당 클라이언트에게 허가된 작업인지를 확인하는 권한 부여와 관련이 있는 과정 : 인가)
  • 접근제어 정책을 기반으로 이루어짐 > 이러한 정책은 고객이 작성 가능
  • 매번 API 호출시에 적용된 정책을 통해 인가를 수행하고, 이 정책은 IAM 역할/사용자/그룹, AWS 리소스, 임시 자격증명 세션, OSU 등에 적용할 수 있음
  • AWS Root 어카운트는 기본적으로 AWS 리소스에 대한 모든 권한을 갖는다
  • AWS 정책은 디폴트값이 deny이고, 명시적 Deny가 명시적 Allow보다 우선순위에 있다.
• AM is Access Management → 요청 성공 조건
  1. IAM 보안 주체의 적법한 서명값이 포함되어 있고(인증),
     • 이 서명값을 보고 요청을 처리할지 말지를 결정하고
  2. 정책(policy)에 의해 해당 요청이 정확하게 인가 되어야 한다.
     • AND 조건으로 권한 정책을 보고 권한을 확인하게 되는 것.

✔ AWS 정책의 JSON 구조

Statement안에 내용은,

• Effect : 허용 또는 차단을 결정하는 곳
• Action : 어떤 행위를?
• Resource : 어떤 객체(자원)들에 대해서?
• Condition : 어떤 조건에서? (optional)

✔ IAM 정책에 대해 더 알아보기

• Identity-based 정책 : IAM 보안 주체(IAM 사용자, IAM 그룹의 사용자 집합, IAM 역할)에 할당되어 해당 주체의 권한을 규정하는 정책 → 접근을 하기 위한 정책
  • 요청을 하는 주체에게 연결이 되는 정책
• Resource-based 정책 : 정책이 할당될 리소스를 기준을 어떤 보안 주체가 할 수 있거나 없는 작업을 규정하는 정책 → 접근을 받기 위한 정책
  • 요청을 받는 리소스에 연결이 되는 정책
  • Principal이라는 구문이 하나 더 들어간다는 점 → 이 구문에는 해당 리소스에 요청을 전달할 수 있는 보안 주체를 기술하고 있음

💥 하나의 요청을 허용 또는 차단하기 위한 정책을 양쪽에서 기술한다고 가정했을 때, In Account의 경우 내용이 겹쳐 합집합의 형태 요청권한 검사가 이루어지고, Cross-Account의 경우 공집합의 형태로 이루어짐 → 즉, 동일 Account의 경우에는 요청이 허용되고 cross account의 경우 요청이 거부됨 게다가, 이 두개의 정책이 모두 있을 경우, deny 정책이 우선시 된다는 원칙에 따라 모두 요청이 거절될 것이다.

• IAM Permission Boundary 정책 : IAM 보안 주체 별로 획득할 수 있는 권한의 최대치를 규정
• Organization SCP : Organization의 OU 또는 개별 어카운트 별로 권한의 최대치를 규정 주로 Root 어카운트의 권한을 제한 시킬때 사용됨
• Session 정책 : 임시 자격증명의 기존 퍼미션을 해당 세션에 대해서만 제한할 때 사용됨
• ACL 정책 : 리소스 기준으로 정의하며, 주로 Cross-Account간의 리소스 공유시, 보안 주체에 대한 접근을 규정함
• Endpoint 정책 : VPC G/W endpoint에 적용되는 접근제어 정책 → 일종의 resouce-based 정책임