AWS 사용하는 3가지 방법
1.관리 콘솔로 리소스 만들기
쉽게 시작 가능
반복 작업에 적합 X
시간이 오래 걸림
2.코드 형태의 명령형 인프라 : CLI(Command Line Interface)
반복 작업에 적합
원하는 항목에 대한 수정이 용이
리소스의 준비 상태 확인이 어려움
문제 발생 시 복원이 어려움
3.코드로서의 선언적 인프라 : AWS CloudFormation template, HashiCorp Configuation Language(HCL)
자동화 구현에 용이
반복 작업에 적합
에러 발생 시 원상 복구가 쉬움
최초 구현이 복잡함
4.AWS CDK(DOM 모델 기반, Cloud Development Kit)
친숙한 개발 언어로 작성
단일 생성자를 기반으로 많은 AWS 리소스를 생성
생성자는 간단한 클래스로 각각의 스택을 구성
여전히 선언적이지만, 생성과 업데이트를 처리할 필요가 없음
결국 API : 모든 방식은 결국 AWS 리소스를 사용 시 혹은 AWS 리소스들간 최종적으로는 API(Application Programming Interface)를 사용
AWS의 shared responsibility model
어떤 환경을 사용하더라도 AWS IAM 필요로 하고, 관리 주체와 책은 고객이다.
AWS IAM(Identify and Access Management)
AWS 전체의 권한 통제 시스템 => 인증*+ 인가**
인증 : 누구시죠? 정체를 밝혀라 ! (Identity)
인가 : 권한 있으세요 ? (Access Management)
IAM User(사용자) vs IAM Group(그룹)
IAM Group 은 동일한 권한을 가져야 하는 IAM User 에게 권한을 설정하는 것을 편리하게 하기 위함이며, IAM Group 이 보안 주체가 될 수 없음
IAM User는 최대 10개의 Group에 속할 수 있음
AWS IAM 정책(Policy)의 JSON 구조
IAM Policy 는 AWS 서비스와 리소스에 대한 인가 기능을 제공
IAM 은 여러분이 정의한 Policy 를 기반으로 AWS 요청을 검사/ 평가 하게 되며 최종적으로 허용 혹은 차단을 결정
IAM advanced
AWS 계정의 활동 모니터링 및 감사
AWS CloudTrail - API 로깅, 감사 활동의 핵심
AWS IAM Access analyzer - 외부 엔터티와 공유되는 리소스 식별
Amazon GuardDuty - 위협탐지 서비스
AWS Security Hub - 통합 대쉬보드속성 기반 접근 제어
Before : 기존의 RBAC 방식 - 메번 개별적인 권한 관리 운영이 필요함
ABCA : Attribute Based Access Control
IAM 보안 주체의 요소(attribute, 태그)를 이용해서 단일 policy 로 각기 다른 리소스에서 재사용가능한 접근 제어
After : 보안 주체가 가진 태그와 리소스가 가진 태그의 일치를 확인으로 권한 부여 가능 -> 동적인 권한 부여 기능
Key take away
Everything API, AWS 사용자들에게 IAM은 피할 수 없는 숙명
IAM의 인증과 인가
정책의 구조와 종류
IAM 운영은 모범 사례에 맞춰서
Beyond IAM, 워크로드 보안
참고 자료 : AFOS[2기] 노션 내용
