[AWS] Identity and Access Management 사용자 관리 (AWS IAM)

본 포스팅은 아마존 웹 서비스 IAM 실습 세션입니다.

---

AWS에서는 권한 관리를 위한 AWS Identity and Access Management(이하 IAM) 서비스를 제공하고 있습니다.

AWS에서 계정을 생성하면 루트 계정이 만들어집니다. 기존에 카드번호 입력하면서 최초 프리티어로 가입한 계정이 루트 계정입니다. 저의 경우 nara0617 바로 하단의 이미지 계정이 루트 계정입니다. 루트 계정은 계정에 속한 모든 리소스에 대한 접근 권한을 가지고 있다보니 루트 계정을 직접 사용하는 대신 이에 속한 다수의 사용자를 생성하고, 각 사용자들에게 서로 다른 권한을 부여하는 것을 권고합니다.

또한 AWS IAM에서는 각 사용자에게 API 호출을 위한 액세스 키를 발급할 수 있습니다. 각 사용자는 웹 콘솔을 사용하지 않더라도 자신에게 부여된 권한에 따라서 AWS 커맨드 라인 인터페이스나 SDK를 사용해 API를 호출할 수 있습니다.

AWS 사용자 생성

지금부터는 AWS의 사용자를 추가하는 방법에 대해 알아보겠습니다.

---

---

먼저 우측 상단의 계정 정보(nara0617) -> 내 보안 자격 증명을 선택합니다.

---

 

---

사용자 -> 사용자 추가 버튼을 클릭합니다.

---

사용자 이름과 엑세스 유형을 프로그래밍 방식 엑세스로 선택하고 권한 설정 버튼을 클릭합니다.

---

권한 설정은 기존 정책 직접 연결을 선택하여 AdministratorAccess를 선택하고 태그 설정 버튼을 클릭합니다.

---

위와 같이 전체 설정을 확인하고 사용자 만들기 버튼을 클릭합니다.

---

---

마지막으로 엑세스에 사용할 Key File을 확인하고 .csv를 다운로드 받아 키파일을 관리합니다.

보안 자격 증명 추가

사용자를 생성할 때, 프로그래밍 방식 액세스 타입이나 AWS 매니지먼트 콘솔 액세스 타입 중에서 하나를 선택해야만 했습니다. 하지만 AWS 매니지먼트 콘솔 액세스 타입을 선택하더라도 앞서 살펴본 대로 액세스 키를 추가해주면 프로그래밍 방식 액세스 타입 사용자가 됩니다. 반대로 프로그래밍 방식 액세스 타입을 선택하더라도 비밀번호를 설정해주면 웹 콘솔에서 로그인 가능한 사용자가 됩니다.

---

---

사용자의 상세 뷰의 보안 자격 탭에서 변경합니다.

① 패스워드 추가

프로그래밍 방식 액세스 타입으로 만든 계정은 처음에 콘솔 패스워드가 비활성화 되어있습니다. 패스워드 관리하기를 클릭하면 패스워드를 지정하는 팝업이 나옵니다.

사용자 -> '추가한 사용자 명 : nrson' -> 보안 자격 증명을 선택합니다.

---

최초 보안 자격 증명의 콘솔 비밀번호는 비활성 상태로 생성됩니다.

비활성 옆 관리 버튼을 클릭합니다.

---

비활성화 -> 활성화를 선택합니다.

---

---

활성화 상태에서 비밀번호 설정을 수행한 후 적용 버튼을 클릭합니다.

---

위와 같이 콘솔 비밀번호가 활성화 상태로 변경된 것을 볼 수 있습니다.

② 엑세스 키 추가

엑세스 키는 앞서 살펴본 것 처럼 AWS 매니지먼트 콘솔 액세스 타입을 선택하더라도 앞서 살펴본 대로 액세스 키를 추가해주면 프로그래밍 방식 액세스 타입 사용자가 됩니다. 

추가 방식은 간단합니다.

---

---

사용자 -> 보안 자격 증명에서 엑세스 키 만들기를 클릭합니다.

---

이렇게 한번의 클릭으로 엑세스 키를 만들 수 있습니다. 각 사용자 별 최대 2개의 엑세스 키를 사용할 수 있습니다.

모듈 9: 자동화
수동 프로세스의 위험성
- 확장 불가, 버전 제어 없음, 감사 내역 부족, 일관성 없는 데이터 관리

인프라 자동화
AWS CloudFormation
- AWS 인프라를 설명하는 공통 언어를 제공
- 설명된 리소스를 자동화된 방식으로 생성하고 구축
- 생성할 리소스를 설명하는 JSON/YAML 형식 파일
- 소스코드로 취급되어 리포지토리에 저장 관리 가능
- 스택의 변경
=> 원래 스택 -> Transit Set 생성 -> Transit Set -> Transit Set 보기 -> Transit 검사 -> Transit Set 실행 -> 적용 (AWS CloudFormation)
- 각 포메이션을 구분화 해서 관리해라 (프론트엔드, 백엔드, 공유, 기본 네트워크, 자격 증명 등으로 구분)

AWS Quickstart
- Google => AWS Quickstart 검색 (빠르게 테스트 해 볼 수 있음)

배포 자동화
AWS Systems Manager
- 자동화된 구성 및 대규모 시스템의 지속적 관리가 가능한 기능의 집합
- EC2 기반 또는 온프렘 기반에서 사용 가능
- 명령 실행, 유지 관리 기간, 패치 관리, 상태 관리자 등의 역할

AWS OpsWorks
- 인프라 및 배포 자동화
- AWS OpsWorkd Stacks
- CHEF & PUPPET을 사용하여 자동화
- 아직 Ansible 서비스로 지원되지 않음
- AWS CloudFormation은 인프라 / OpsWorks는 인프라 + 배포 자동화
- 수명 주기
=> Setup(기동이 완료 된 후 실행해야 할 명령어), Configure, Deploy, Undeploy, Shutdown

AWS CloudFormation으로 인프라를 구축하고, AWS OpsWorkd로 RDS + APP + 로드 밸런싱 계층 + 경보 + 로그 등을 구성하여 함께 사용하는 것을 권장 함

AWS Elastic Beanstalk
- PaaS 임
- 인프라를 프로비저닝 및 운영하고 사용자를 위해 애플리케이션 스택을 관리
- 자동 스케일 인 아웃 환경 관리
- 사용자는 애플리케이션 코드만 Define 해주면 HTTP 서버, WAS, 인프라 등이 모두 자동으로 구성되는 형태

상위 수준 서비스 : AWS Elastic Beanstalk, AWS OpsWorks (간편한 관리)
DIY 서비스 : AWS CloudFormation, Amazon EC2 (제어의 어려움)

모듈 10: 캐싱 - 사용자 딜레이를 줄이는 캐싱 서비스, 계층 별
동일한 요청으로 인프라 용량이 지속적으로 과부화가 발생될 경우 비효율적으로 비요 및 지연 시간이 발생할 수 있음
무엇을 캐시 대상으로 삼아야 할까?
- 수집하려면 느리고 비싼 쿼리가 필요한 데이터
- 비교적 정적이고 자주 액세스하는 데이터
- 공개 거래되는 주식 가격 처럼, 일정 기간 동안 변화가 없을 수 있는 정보

캐싱의 효과
- 어플리케이션의 속도 향상
- 시간이 많이 걸리는 DB 쿼리의 부담 완화
- 응답 지연 시간 감소

캐싱의 유형
- 클라이언트 측 캐싱 (브라우저 캐싱 / 하드 디스크 / 메모리 캐싱)
- 서버 측 캐싱 (웹 서버 / 역방향 프록시 캐시)

AWS의 캐싱
- 사용자는 인터넷/엣지 로케이션을 통해 웹/앱/데이터베이스에 접근할 경우를 예를 들어보자. (전형적인 3tier)
- 엣지 캐싱 : 엣지 로케이션에 캐싱을 두어 CDN(콘텐츠 전송 네트워크)를 지원

Amazon CloudFront (엣지 로케이션 캐싱)
- Amazon의 글로벌 CDN 서비스
- 다중 계층 캐시와 광범위한 유연성으로 모든 전송 사례에 최적화
- 아키텍처에 추가적인 보안 계층 제공
- WebSocket 프로토콜 지원
- CloudFront 작동 방식
=> 요청이 최적의 엣지 로케이션으로 라우팅됨
=> 캐시되지 않은 데이터가 오리진으로부터 검색 됨
=> 오리진 콘텐츠가 캐싱을 위해 CloudFront로 복제 됨
=> 데이터가 사용자에게 전송 됨
=> 이후는 S3까지 가지 않고 바로 CloudFront로부터 호출 됨
- 콘텐츠 만료 방식
=> Time To Live (TTL) : 기간 고정(만료 기간) - 0으로 설정할 경우 즉각 새로 반영, 고객이 직접 설정, CloudFront에서 오리진으로의 GET 요청에 IF-Modified-Since 헤더를 사용
=> 객체 이름 변경 : Header-v1.jpg를 Header-v2.jpg로 변경
=> 객체 무효화 : 명시적으로 Invalidation 하는 메뉴를 통해 만료. 시간이 오래 걸리고 비용도 들어가고 비효율적.
- 동적 콘텐츠를 접근할 경우에도 매번 서버로 접근하게 되지만 인터넷 HOPS를 사용하지 않고 AWS 전용 망을 사용하여 빠르고, 보안 정책으로 인해 이점을 가져 갈 수 있음
- DDoS 완화 : Amazon WAF를 통해 1차 완화, Amazon CloudFront를 통해 2차 완화, ELB의 동적 관리, SG를 통해 3차 완화

ELB (웹 계층 캐싱)
- 사용자 세션을 관리하는 특정 서버로 요청을 라우팅 (전에 요청한 세션 기반 기존 웹 또는 와스 서버 쪽으로 라우팅하는 스티키 기능 제공)
- 클라이언트 측 쿠키, 비용 효율적, 세션 검색 속도 증가

DynamoDB (웹 계층 캐싱)
- DynamoDB에 세션을 저장하는 방식
- 상태 정보를 외부에 두는 방식
- 더 빠른 세션 검색
- 10ms 수준의 속도

데이터베이스 캐싱 (앱 / 데이터베이스 계층 캐싱)
- 고객에 대한 응답 시간이 우려되는 경우
- 부하가 큰 대용량 요청으로 데이터베이스가 넘치는 것을 알게 되는 경우
- 데이터베이스 비용을 줄이고 싶을 때 (IOPS)
- AWS DynamoDB Accelerator : 마이크로초 단위의 응답 시간

Amazon ElastiCache
- 인 메모리 캐시
- 완전 관리형 서비스
- Redis 및 Memcached 형태로 배포 가능
- Memcache vs Redis 비교
DB 부하 오프로드 예 예
쓰기/저장을 위해 수평 확장 예 아니오
다중 쓰레드 기능 예 아니오
고급 데이터 유형 아니오 예
데이터 세트 정렬/순위 지정 아니오 예
Pub/Sub 아니오 예
자동 장애 조치 아니오 예
지속성 아니오 예
- 연속쓰기 : Amazon ElastiCache에 먼저 쓰고 DB에 업데이트 하는 방식
- 레이지 로딩 & TTL 추가 방식 지원

참고자료

- AWS 공식 사이트 : IAM 사용자의 액세스 키 관리

https://online.vitalsource.com/#/user/signin