AWS Region
: 데이터 센터의 집합
전 세계에 걸쳐서 존재한다. 리전에는 이름이 있다.(ex. us-east-1, eu-west-3, …)
대부분의 서비스들은 특정 리전에 연결되어서 국한된다.
한 리전에서 어떤 서비스를 사용하다가 다른 리전에서 그 서비스를 사용하려고 하면 서비스를 처음 사용하는 것이 된다.
✅ Q. 새로운 애플리케이션을 출시하려는 경우, 어떤 리전을 선택하면 좋을까요?
A. ‘상황에 따라 다르다’
AWS region 선택에 영향을 미칠 수 있는 요인
- 법률 준수
어떤 정부는 애플리케이션을 배포할 때 대상 국가 내에 데이터가 보관되기를 원한다. 그러면 리전은 그 나라로 선택해야 한다.
- 지연 시간
대부분의 사용자가 미국에 있는 경우, 애플리케이션 역시 사용자와 가까이 출시하는 것이 바람직하다. 그래야 지연 시간이 줄어들기 때문이다.
- 서비스의 사용 가능성
일부 리전에는 애플리케이션에 필요한 서비스가 없을 수 있다.
- 요금
리전마다 요금이 달라진다.
AWS Availability Zone(AZ)
가용 영역은 리전 내에 존재한다.
각각의 리전은 많은 가용 영역을 가지고 있다. 대부분은 세개이다.
각각의 가용 영역은 여분의 전원 네트워킹, 통신 기능을 갖춘 개별적인 데이터 센터로 이루어져 있다.
재난을 대비해서 서로 영향을 미치지 않도록 설계되어 있다.
IAM(Identity and Access Management)
사용자를 생성하고 그룹에 배치하기 때문에 글로벌 서비스에 해당된다.
Root account
우리는 모르는 사이에 이미 IAM을 사용했다. 계정을 생성할 때 루트 계정을 만들었는데, 이는 기본으로 생성되는 것이다. 이 계정은 오직 계정을 생성할 떄만 사용되어야 한다.
User
하나의 사용자는 조직 내의 한 사람에 해당이 된다. 필요 하다면 사용자들을 그룹으로 묶을 수 있다.
Groups
그룹에는 사용자만 배치할 수 있다. 다른 그룹을 포함시킬 수 없다.
Fred처럼 그룹에 포함되지 않는 사용자도 존재할 수 있다.
또, 한 사용자가 다수의 그룹에 속할 수 있다.
사용자와 그룹을 생성하는 이유
사용자와 그룹이 AWS 계정을 사용할 수 있도록 허용하기 위해서이다.
허용을 위해서는 이들에게 권한을 부여해야 한다.
이를 위해 사용자 또는 그룹에게 정책, 또는 IAM 정책이라고 불리는 JSON 문서를 지정한다.
➡️ 이 정책들을 사용해 사용자들의 권한을 정의할 수 있게 된다.
AWS에서는 모든 사용자에게 모든 것을 허용하지 않는다. 새로운 사용자가 너무 많은 서비스를 실행하여 큰 비용이 발생하거나, 보안 문제를 야기할 수 있기 때문이다.
따라서 AWS에서는 최소 권한의 원칙을 적용한다.
IAM 정책 상속
Developers 그룹에 정책을 연결한다. 이렇게 하면 정책이 그룹의 모든 구성원에게 적용된다.
Alice, Bob과 Charles 모두 권한을 얻으며 정책의 상속이 가능하다.
두 번째는 Operations 그룹으로 다른 정책을 적용한다. David와 Edward는 Developers 그룹과 다른 정책을 적용 받는다.
Fred라는 사용자가 있다고 하면 그룹에 속하지 않을 수도 있다. 이런 경우에는 사용자에게만 연결이 가능한 인라인 정책이라는 걸 생성할 수도 있다.
그리고 만약 Charles와 David가 감사팀에 속한다고 하면 감사팀에도 정책을 연결할 수 있다.
Charles와 David는 감사팀의 정책도 상속하게 된다.
정책 구조
- Version : 정책 언어의 버전
- Id : 정책을 식별하기 위한 ID (선택사항)
- Statement : 하나 혹은 여러개의 문장 (필수사항)
- Sid(시드) : statement 식별자
- Effect(효과) : statement가 특정 API에 접근하는 걸 허용할지 거부할지에 대한 내용(Allow, Deny)
- Principal(원칙) : 특정 정책이 적용될 사용자, 계정 혹은 역할
- Action(조치) : Effect에 기반해, 허용 및 거부되는 API 호출의 목록
- Resource(리소스) : 적용될 Action의 리소스 목록
- Condition(조건) : Statement가 언제 적용될지 결정
그룹과 사용자들의 정보가 침해당하지 않도록 보호해야 한다.
이를 위한 두 가지 방어 메커니즘이 있다.
IAM - Password Policy
첫 번째 방법은 비밀번호 정책의 정의이다. 비밀번호가 강력할수록 계정의 보안이 철저해지기 때문이다.
- 비밀번호의 최소 길이 설정
- 특정 유형의 글자 사용 요구(대문자, 소문자, 숫자, 물음표, 특수문자, …)
- IAM 사용자들의 비밀번호 변경을 허용하거나 금지
- 일정 시간이 지나면 비밀번호를 만료시켜, 새 비밀번호 설정을 요구
- 이전에 사용했던 비밀번호 사용 불가
IAM - MFA(Multi Factor Authentication)
AWS에서는 이 메커니즘을 필수적으로 사용하도록 권장한다.
MFA = password you know + security device you own
- MFA의 장점
해킹을 당해 비밀번호가 누출된 상황이라고 해도 해커에게는 로그인을 위해 휴대전화 등 계정 주인 소유의 물리적 장치가 추가로 필요해질 테니계정이 침해당하지 않는다.
지금까지는 관리 콘솔을 통해서 AWS에 access 했다.
하지만 AWS에 액세스하는 방법은 세 가지가 있다.
AWS Management Console
사용자 이름 및 비밀번호와 MFA로 보호된다.
AWS Command Line Interface(CLI)
액세스 키에 의해 보호된다.
액세스 키란 자격 증명으로 터미널에서의 AWS 액세스를 가능하도록 해준다.
AWS Software Developer Kit(SDK)
애플리케이션 코드 내에서 AWS의 API를 호출하고자 할 때 사용되는 방식이다.
CLI와 SDK 방식 모두 액세스 키로 보호가 된다.
- 액세스 키는 어떻게 생성할까?
관리 콘솔을 사용해서 생성할 수 있다.
그리고 사용자들이 자신들의 액세스 키를 직접 관리한다. 사용자의 측면에서 액세스 키는 비밀번호와 마찬가지로 암호와 같다. 따라서 액세스 키를공유해서는 안된다.
AWS CLI
CLI를 사용하면 AWS 서비스의 공용 API로 직접 액세스가 가능하다.
윈도우용 CLI 설정
Installing or updating the latest version of the AWS CLI - AWS Command Line Interface
AWS SDK
SDK는 소프트웨어 개발 키트이다. 특정 언어로 된 라이브러리의 집합이다.
따라서 프로그래밍 언어에 따라 개별 SDK가 존재한다.
SDK는 터미널 내에서는 사용하는 것이 아니라 코딩을 통해 애플리케이션 내에 심어 둔다. 애플리케이션 내에 자체적으로 AWS SDK가 있는 것이다.
다양한 프로그래밍 언어를 지원한다. (JavaScript Python, PHP, .NET, Ruby, Java, Go Node.js, C++)
IAM Roles for Services
AWS 서비스 몇 가지는 우리의 계정에서 실행해야 한다.
이를 위해서는 사용자와 마찬가지로 AWS 서비스에 권한을 부여해야 한다.
➡️ IAM Role
IAM Role은 사용자와 같지만 실제 사람이 사용하도록 만들어진 것이 아니고 AWS 서비스에 의해 사용되도록 만들어졌다.
예를 들어, EC2 인스턴스를 만들려고 한다. EC2 인스턴스는 AWS에서 어떤 작업을 수행하려고 한다. 그러기 위해서는 EC2 인스턴스에 권한을 부여해야 한다.
IAM Role을 만들어 이들을 하나의 개체로 만든다.
EC2 인스턴스가 AWS에 있는 어떤 정보에 접근하려고 하면, IAM Role을 사용한다. 올바른 권한을 부여한 경우, 접근할 수 있게 된다.
IAM Security Tools
-
IAM 자격 증명 보고서 (계정 수준)
계정에 있는 사용자와 다양한 자격 증명의 상태를 포함한다. -
IAM 액세스 관리자 (사용자 수준)
사용자에게 부여된 서비스의 권한과 해당 서비스에 마지막으로 액세스한 시간이 보인다.
