[DB] AWS basic & IAM ROLE, POLICY

20190829 - AWS

첵 ‘모두의 네트워크’를 보자

AWS를 쓰는 가장 큰 이유

탄력성
- IDC 서버는 탄력성이 없다
가격(잘 쓸 경우에…)

AWS 핵심 서비스 : basic

Route53 : DNS 서비스

aws에서 제공해주는 DNS 서버
가동률 100%, 분산 시스템이라 절대로 장애가 날 일이 없다
DNS를 IP로 바꿔준다

VPC : 네트워크망

가상 사설망
VPC 앞에는 인터넷 게이트 웨이가 있어 외부 인터넷과 연결이 가능하다
서브넷으로 쪼개짐

EC2 : 서버

실제 서버
보통 EC2와 EBS를 붙여서 쓴다

RDS : DB

aws가 DB 관리를 대신해줌

S3 : object storage

용량이 큰 동영상, 파일 저장

IAM : management

계정 관리

cloud watch : resource monitoring

모니터링
aws 리소스 모니터링

cloud trail

계정 관리자를 management 및 모니터링

Queue

비동기처리
pub, sub

SQS

SNS

알림 서비스

AWS CLI 실습

S3 버킷 생성
파일 업로드
CLI 설치
CLI로 파일 업로드 확인
Node.js SDK로 확인

IAM

aws의 서비스 API를 이용할 수 있는 권한을 식별하기 위해 인증, 권한 부여해주는 것
IAM 권한은 최소한으로.
authentification
- 콘솔에서는 ID / PASSWORD
- CLI나 sdk에서는 access id, secret key
authorization
- 정책으로 결정
- 정책을 사용하여 IAM 또는 AWS 리소스에 대한 제어 가능
정책 허용 단계
- 암묵적 금지, 허용, 명시적 금지
뭔가가 삭제가 안되거나, 서비스에 접근이 안될 때 정책 상 ‘명시적인 금지’가 걸려있을 경우가 많다

정책의 종류

AWS Management Policy

aws가 만든 관리형 정책
삭제 불가능

User Management Policy

유저 커스텀 관리 정책

Inline

특정 사용자에게만 특정 권한을 주고 싶을 때 설정

IAM ROLE

사람, 또는 EC2 instance, service도 쓸 수 있다
- 예를 들어 람다 서버가 S3 서버 접근 권한을 요청할 수도 있음
aws는 여러 서비스가 다른 서비스에 접근하는 경우가 굉장히 많기 때문에 중요

IAM ROLE 실습

아까 만든 S3 저장소의 파일 하나를 EC2에서 받아보자

bad case

aws configure에 직접 access id, serect code를 써서 권한을 획득한다
키와 패스워드가 노출, 가장 좋지 않음

good case

키페어 노출 대신 IAM ROLE을 부여한다
‘역할 전환’으로 임시 권한을 부여한 후 작업을 진행하게 한다

APP에서 sdk로 api를 호출할 때는?

보통 권한이 있는 유저의 키페어가 하드코딩되어 있는데, 정보 노출의 위험성이 있다
안전한 방법으로는
- 아무 권한도 없는 빈 계정을 만들고
- Assume Role 하나만 허용해주고
- role을 우선 획득하게 한 후 api를 호출
별 차이 없는 것 같아도 이게 aws에서 권장하는 best practice

Date: August 29, 2019

Tags: DB