2. IPv4 CIDR은 보통 VPC는 /16 prefix, public subnet 같은 경우 /20, private subnet 같은 경우 /22 로 나뉘며 그 이유는 앞단인 public subnet 영역 에서 훨씬 많은 외부접근이 발생할 수 있기 때문에 auto scailing을 통해 ip대역을 원할히 할당하기 위해 prefix를 좀더 널럴하게 잡는다고 한다.
3. DR(Disaster Recovery) 를 위해 2AZ 안에 2 Tier의 Subnet 영역을 두고자 하며 각각의
4. VPC > Subnets > Create Subnet을 통해 Subnet 생성을 하며 필자는 2 tier 로 구성하기에
4개의 서브넷 영역을 생성했다.(2pub/2pri)
5. pub1, pub2 subnet 영역을 하나의 라우팅 테이블에 묶고 pri1, pri2 subnet 영역을 하나의 라우팅 테이블에 묶는다.
최초 VPC 생성시 Default Routing Table이 생성되고 이를 필자는 pub1, pub2 를 묶는데 썼으며 추가로 pri1, pri2 서브넷 영역을 묶기위해 Route Table을 별도로 생성하였다.
6. private subnet 과 public subnet에 각각 ec2 인스턴스를 셋팅한다. public subnet 영역에는 ec2 ami로 amzn-ami-vpc-nat-2018.03.0.20220705.1-x86_64-ebs(이미지 이걸로 안할시에 -> ec2 인스턴스를 nat용으로 사용못함) 를 사용하여 ec2 인스턴스를 nat용으로도 사용하고자 한다. private subnet 영역에는 ami로 amazon default image를 사용하여 t2 medium으로 올렸다.
7. bastion host란 private subnet에 올린 ec2에 접근 할 수 있는 방법이 오직 bastion host 로만 관리하는 것이며 이경우 보안과 통신 로그를 일괄적으로 관리할 수 있는 편리함이 보장된다. public subnet에 올린 ec2 인스턴스를 bastion으로 사용하기 위해 기존 private subnet을 묶은 {Service Name}-{Profile}-private-rt 에 Edit routes 로 모든 나가는 목적지를 아래와 같이 public 영역에 위치한 ec2 인스턴스의 아이디를 입력한다.
8. public subnet을 묶은 {Service Name}-{Profile}-public-rt 은 외부로 통신해야하기 때문에 Internet Gateway를 우선적으로 생성한다.
9. 생성한 Internet gateway를 앞서 생성한 {Service}-vpc에 Attach to VPC 메뉴를 통해 붙인다.(안붙이게 되면 routing table에서 이용할 수 없다)
10. 앞서 8번에서 언급한 {Service Name}-{Profile}-public-rt 에 앞서 만든 Internet gateway를 연결한다.
11. public 영역에 위치한 ec2 인스턴스와 private 영역에 위치한 ec2 인스턴스에 접근하기 위해선 각각의 Security Group의 Inbound rule 과 outbound rule 에 설정을 해야 하는데 우선 private 영역에 위치한 보안그룹의 inbound와 outbound의 설정 정보는 routing table에 등록되어있는 정보를 토대로 외부로 나아가기때문에 outbound를 모두 all로 표기했으며 inbound는 아래와 같이 ssh만 설정하였다.
12. public 영역에 위치한 ec2 인스턴스의 Security Group 은 아웃바운드는 모든 트래픽 허용으로 했으며 inbound 의 source 타겟을 Security Group 도 target으로 할 수 있어 private 영역에 위치한 ec2인스턴스의 security group을 소스로 설정했다. 아래는 그 설정 정보이다.
13. 또한 public subnet 영역에 위치한 ec2인스턴스를 nat 용도로 사용해야하기 때문에 원본/대상 확인 비활성화 작업을 해야하며 아래와 같이 진행하면 된다.
14. 정상적으로 nat용도로 활용되는지를 확인하려면 우선 가까운 영역부터 즉 private ec2 에서 public ec2 인스턴스로 핑을 날려보고
아래와 같이 명령어로 정상적으로 작동 되는지 확인한다.
$ sudo yum update -y
* perm key의 권한은 600으로 안해줄시에 SSH 커넥션시에 에러가 발생한다.
15. 핑은 VPC 내의 Subnet을 묶는 Default Routing table을 통해 다른 서브넷에 있는 ec2 인스턴스끼리 서로 통신할 수 있지만 IGW를 통해 외부 연결을 하려면 반드시! private subnet을 묶은 routing table에 public subnet에 올린 ec2인스턴스를 등록을 꼭 해줘야한다.
$ aws configure
AWS Acess Key Id: { aws_access_key_id }
AWS Secret Access Key: { aws_secret_access_key }
Default region name: ap-northeast-2
# AWS 자원에 대한 응답의 기본 포맷으로 text, table, yml 등이 있다.
Default output format: json
# 특정 profile 별 액세스 키 설정
$ aws configure --profile dev
# 아래 명령어로 현재 설정된 프로그램 액세스 키가 어느 계정에 소속된 것인지 조회할 수 있다
$ aws --region ap-northeast-2 iam get-user
# 프로파일 별 계정 정보 조회
$ aws --profile dev --region ap-northeast-2 iam get-user
IAM 사용자의 집합으로서, 사용자 그룹을 활용하면 다수의 사용자들에 대한 권한을 지정함으로써 해당 사용자들에 대한 권한을 더 쉽게 관리할 수 있다. 사용자 그룹의 모든 사용자가 정책의 권한을 받도록 Identity기반 정책을 사용자 그룹에 연결할 수 있다. 그룹은 인증이 아니라 권한과 관련이 있고 보안 주체는 인증된 IAM 엔티티이기 때문에 정책에서 사용자 그룹을 Principal로 식별할 수 없다.
다음은 사용자 그룹이 갖는 몇 가지 중요한 특징이다.
Root accout 는 기본생성 되어지며 사용하거나 공유해서는 안된다.
조직내의 사용자들은 그룹화(사용자 그룹) 할 수 있습니다.
그룹에는 사용자만 포함할 수 있으며 다른 사용자 그룹은 포함할 수 없습니다.
사용자는 사용자 그룹에 속할 필요가 없으며 사용자는 여러 그룹에 속할 수 있습니다.
User & Group
IAM 역할
IAM 역할 은 계정에 생성할 수 있는, 특정 권한을 지닌 IAM 자격 증명이다. IAM역할은 AWS에서 자격 증명이 할 수 있는 것과 없는 것을 결정하는 권한 정책을 갖춘 AWS 자격 증명이라는 점에서 IAM 사용자와 유사하다. 그러나 역할은 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없다. 때문에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공된다. 이와 관련된 것이
AWS STS와 Assume Role인데
AWS STS(Security Token Service)는 AWS에서 보안 토큰을 생성하는 서비스이며, Assume Role은 AWS IAM에서 지원하는 기능 중 하나로써 AWS IAM에서 Assume Role을 사용하면 IAM 사용자 또는 AWS 외부 자격 증명으로 다른 AWS 계정 또는 리로스에 엑세스 할 수 있다.
IAM Permissions
사용자와 그룹은 JsonType document로 Policies(정책)를(을) 할당 받을 수 있으며 이러한 Policies는 사용자의 권한을 정의합니다.
최소한의 권한 정책을(least privilege principle)을 적용해야 하며 사용자가 필요로 하는 것보다 더한 권한을 주워서는 안된다.
IAM Policies inheritance (정책 상속)
정책 상속
IAM Policies Structure
구성 정보
Version: 정책 언어 버전(항상 2012-10-17일로 고정)
Id: 정책 식별자(선택 사항)
Statement: 하나 또는 그 이상의 개별 명령문(Statement)(필수)
Statement 구성 정보
Sid: 명령문의 식별자(선택사항)
Effect: 명령문이 액세스를 허용하는지 또는 거부 하는지 여부(Allow or Deny)
Principal: 이 정책이 적용될 사용자, 계정, 역할(Account, User, Role)
Action: 허용하거나 거부된 정책 목록
Resource : Action 이 적용된 리소스 목록
Condition: 이 정책이 적용되는 조건(선택사항)
IAM Password Policy
복잡한 암호는 계정의 보안을 강화시키기에, AWS는 비밀번호 정책을 다음과 같이 설정할 수 있다.
