SK shieldus Rookies 16기 (클라우드 보안 기술 #02)

만두다섯개·2023년 12월 4일

클라우드 클라우드보안

SK 루키즈 16기

목록 보기

24/52

주요 정보

교육 과정명 : 클라우드기반 스마트융합보안 과정 16기
교육 회차 정보 : '23. 12. 01. 클라우드 보안 기술 #02

무엇을 깨달았나

AWS 기초 및 IAM(권한, 역할, 등..), 버킷, EC2 기초 사용방법

강의 자료 정보

박창렴 강사님 작성https://docs.google.com/document/d/1Y7wtAHji99RyS7h77oyr2W28Z2t7I9Uu_c7N7YPjRls/edit

IAM – 사용자 생성 및 권한부여

사용자는 크게 권한과 정책으로 권한을 부여한다. (권한 : 특정 사용자와 관련된 권한의 모음, 정책 : 권한만 모아놓은 것)
IAM의 구성 3요소 : 대상, Source, Action
– IAM에서 사용자 생성 시, 권한 설정 방법은 세 가지 존재한다.

사용자 그룹에 생성하는 사용자를 추가한다. (그룹에 사용자 추가)

여기서 사용자 그룹이란? 특정 권한을 묶어놓고, 사용자들에게 할당할 수 있는 단위.

권한 복사
직접 정책에 연결

권한 경계 설정이란? 사용자에 대한 최대권한 설정. 여기에서 지정한 권한 이상으로 사용 불가능하다.

IAM 보안 모범 사례

사용자는 ID 공급자와의 페더레이션(안전한 계정사용을 위한 기술의 조합) 사용 요구
AWS 접근 시, 워크로드 IAM 역할이 있는 임시 자격 증명을 사용하도록 요구한다.
다중 인증 MFA 사용
장기 보안 인증이 필요한 사용 사례에 필요한 경우 액세스 키 업데이트
최소 권한 적용(필요한 만큼만 정의)
IAM 엑세스 분석기를 이용해, 사용하는 엑세스 활동을 기반으로 최소 권한 정책 생성
권한 경계를 사용
루트 사용자 모범 사례 (https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/best-practices.html)

루트 사용자 모범 사례

루트 사용자 보안 인증을 보호하여 무단 사용 방지 (관리자만 소유, 필요 시 사용자 계정을 만들어 전달 등.)

AWS 서비스를 이용하는 방법

Management Console : 사람(사용자) 로그인 후 사용
AWS CSI : 사람 또는 프로그램이 Access Key를 이용해서 사용
각 개발 언어별 SDK : 응용 프로그램을 이용해 사용

사용자 접근 보안

터미널 등, 웹 브라우저가 아닌 곳에서 AWS 접근 시, CLI 로 액세스 키를 사용해 접근 가능하다
사용자 계정에 대한 엑세스 키 발급 : 로그인 - IAM – 엑세스 관리(사용자) - 엑세스 키 만들기(요약) - CLI를 위한 키 발급하기

AWS CLI 사용하는 이유?

탐지 룰을 생성할 수 있다.
스크래핑 기술을 사용한다면 AWS 콘솔 페이지에 접근해야 한다. 접근이 어렵다.
만약 CLI 기술을 사용한다면 AWS을 쉽게 점검할 수 있게 된다.
AWS 클라우드를 사용하는 서비스의 취약점 점검 시, CLI를 사용해 스캐닝. (AWS 페이지를 하나씩 눌러 살펴보는 것보다 CLI를 사용하면 더 효율젂이다.)

VPC

Virtual Private Cloud
AWS 사용자 계정 가상 네트워크
AWS 클라우드에서 논리적 가상 네트워크를 생성한다.
한 AWS 리전 안에서만 존재 가능, 한 리전에 만든 VPC는 다른 리전에서는 보이지 않는다.
VPC Peering이란? 프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워킹 연결
생성 시, RFC 1918에 지정된 프라이빗 주소 체계 사용을 권고한다.
10.0.0.0/8- 10.255.255.255 (10/8 prefix)
172.16/12 - 172.31.255.255 (172.16/12 prefix)
192.168/16 - 192.168.255.255 (192.168/16 prefix)
인터넷에 VPC 연결 시 인터넷 게이트웨이를 사용한다.
인터넷 게이트웨이에서 라우팅이 진행
논 타이틀리적으로 VPC를 재사용 가능

기본 VPC 구성 요소

IPv4 CIDR 블록의 크기가 /16인 VPC를 만듭니다 (172.31.0.0/16). 최대 65,536개의 프라이빗 IPv4 주소를 제공
각 가용 영역에 크기 /20의 기본 서브넷을 생성합니다. 이렇게 하면 서브넷당 최대 4,096개의 주소가 제공되며, 그중 몇 개는 내부용으로 예약되어 있습니다.
인터넷 게이트웨이를 만들어 기본 VPC에 연결합니다.
기본 라우팅 테이블에 모든 트래픽(0.0.0.0/0)이 인터넷 게이트웨이로 전달되는 경로를 추가합니다.
기본 보안 그룹을 만들어 기본 VPC와 연결합니다. (기본 VPC 보안그룹은 IN/OUT 바운드 트래픽을 허용한다.)
네트워크 ACL(액세스 제어 목록)을 생성하여 기본 VPC와 연결합니다.
AWS 계정에서 설정된 기본 DHCP 옵션을 기본 VPC와 연결합니다.

서브넷

VPC 내 논리적인 구분
EC2 인스턴스를 배치하는 장소 == 인스턴스는 서브넷 안에 위치한다

한번 서브넷 인스턴스를 생성하면 다른 서브넷으로 옮길 수 있다.
인스턴스를 종료하고 다른 서브넷에 새 인스턴스를 만들 수 있다.

인스턴스를 서로 격리하고, 인스턴스 간의 트래픽 흐름을 제어하고, 인스턴스를 기능별로 묶을 수 있는 기능을 제공한다.
서브넷은 하나의 가용 영역 내에서 존재
서브넷의 CDIR 블록
1. VPC의 일부, VPC 내에서는 유니크 해야 한다
2. 모든 서브넷에서 처음 4개, 마지막 1개의 IP는 예약되어 인스턴스에 할당 불가.
3. 예시) 서브넷 CIDR이 172.16.100.0/24 인 경우,
172.16.100.0 ~ 172.16.100.255 범위이다.
172.16.100.0 => 네트워크 주소
172.16.100.1 => AWS에서 VPC 라우팅용 예약
172.16.100.2 => DNS 서버 주소
172.16.100.3 => AWS 나중에 사용하려고 예약
172.16.100.255 => 브로드캐스트 주소
172.16.100.4 ~ 172.16.100.254 => 인스턴스 할당 가능
퍼블릭 서브넷 : 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 있는 라우팅 테이블과 연결된 경우
프라이빗 서브넷 : 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 없는 라우팅 테이블과 연결된 경우

ENI

Elastic Network Interface : 탄력적 네트워크 인터페이스
물리 서버의 NIC와 같은 기능을 수행
VPC에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소

인터넷 게이트웨이(IGW)

퍼블릭 IP 주소를 갖는 인스턴스가 인터넷에 연결될 수 있는 기능을 제공한다
처음 VPC 생성 시, IGW 연결되어 있지 않으므로, 직접 IGW 생성 및 VPC와 연결해야 한다.
하나의 VPC는 하나의 IGW에만 연결할 수 있다

라우팅

VPC의 네트워크 트래픽을 전달할 위치를 결정하는데 사용되는 규칙
트래픽 전송 전달 IP 주소 범위(대상 주소)와 트래픽 전송 게이트웨이, 네트워크 인터페이스 또는 연결(대상)을 지정한다.
VPC 는 소프트웨어 함수로 IP라우팅을 구현 => 사용자는 라우팅 테이블만 관리하면 된다.
라우팅 테이블 => 라우팅 집합으로 서브넷과 연결 가능
기본 라우팅 테이블 : VPC와 함께 자동으로 제공되는 라우팅 테이블
1. 기본 VPC 테이블인 경우, local 및 IGW로의 라우팅 포함
2. 기본 VPC 테이블이 아닌 경우, local 라우팅만 포함
예시)
-------------------- --------------------
대상 주소 대상
-------------------- --------------------
172.31.0.0/16 local => local 안에서 찾는다.
0.0.0.0/0 IGW-XXXXX
~ ~
인터넷 상 모든 호스트 IP 인터넷 게이트웨이
-------------------- --------------------
172.31.10.10 주소로 트래픽을 전송하는 경우, 172.31.0.0/16 주소 범위에 속하므로 VPC 내부에서 대상 인스턴스를 찾는다.
192.100.10.10 주소로 트래픽을 전송하는 경우, 172.31.0.0/16 주소 범위에 속하지 않고, 0.0.0.0/0 주소 범위에는 속하므로 1GW로 해당 트래픽을 전달
=> 라우팅 위치와 가장 근접하게 일치하는 항목을 기반으로 라우팅을 처리한다.
=> 라우팅 테이블의 항목들간의 순서는 중요하지 않다.

보안 그룹 (SG, Security Group)

방화벽과 같은 기능을 제공한다.
인스턴스의 ENI에서 송수신하는 트래픽 제어한다
모든 ENI는 최소 1개 이상의 보안 그룹과 연결되어 있다.
보안그룹은 여러 ENI와 연결할 수 있다.
보안 그룹 생성 시 그룹 이름, 설명, 포함될 VPC를 지정하고, 생성 후에 인바운드, 아웃바운드 규칙을 지정해 트래픽을 허용한다.
상태 저장 방화벽 역할
상태 저장 방화벽이란? 외부로부터 온 트래픽의 IP를 저장하고, 서버가 다시 해당 IP로 트래픽을 전송 시, 특별한 검증 없이 전송하게 해주는 방화벽
상태 저장 방화벽 역할 => 보안 그룹이 트래픽을 한 방향으로 전달하도록 허용 시, 반대 방향의 응답 트래픽을 지능적으로 허용 (예: 웹 클라이언트에서 HTTPS로 요청을 허용했다면 요청에 대한 응답도 허용)

NACL

Network Access Control List
보안 그룹과 유사

원본 또는 대상 주소 CIDER, 프로토콜을 기반으로 트래픽을 제어(인바운드, 아웃바운드 규칙 사용. 이는 방화벽과 같은 역할을 한다.
VPC는 삭제 불가능한 기본 NACL이 존재한다.

NACL은 서브넷에 연결되어 해당 서브넷과 송수신되는 트래픽을 제어한다.
상태 비저장

NACL을 통과한 연결상태를 추적하지 않는다.
모든 인바운드와 아웃바운드 트래픽의 허용 규칙을 별도로 작성해야 한다.

규칙을 적용 시 규칙 번호의 오름차순으로 처리한다.

EC2

Elastic Compute Cloud
안전하고 크기 조정이 가능한 컴퓨팅 파워를 클라우드에서 제공하는 서비스

AMI

Amazon Machine Image
인스턴스를 시작하는 데 필요한 정보를 제공하는 AWS에서 지원되고 관리되는 가상머신 이미지
인스턴스의 명명규칙 ; https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/instance-types.html
인스턴스 유형 : https://aws.amazon.com/ko/ec2/instance-types/

EBS

Elastic Block Store
EC2를 저장하기 위한 물리적인 공간

EIP

Elastic IP
정적 IPv4 주소로, AWS 계정에 할당되며 릴리스할 때까지 할당된 상태를 유지
EC2 인스턴스를 중지하고 다시 시작하면 퍼블릭 IP 주소가 변경되나, EC2 인스턴스에 EIP 주소를 연결하면 EC2 인스턴스를 다시 시작해도 동일한 IP로 접속 가능
EIP 주소 요금

인스턴스가 실행 중인 동안에는 이와 연결된 EIP 주소 하나에 대해서만 요금이 부과되지 않지만, 해당 인스턴스와 연결된 추가 EIP 주소에 대해서는 요금이 부과
연결되어 있지 않거나 중지된 인스턴스 또는 연결되지 않은 네트워크와 연결 시, 시간당 요금이 부과 (EC2와 연결 X, 또는 연결되었지만 EC2가 중지, 네트워크가 EC2와 연결되어있지 않고, 네트워크 카드만 존재하는 것)
2024년 2월 1일부터, 실행 중인 인스턴스와 연결된 주소를 포함하여 모든 탄력적 IP주소에 요금이 부과

웹 서비스 환경 구성 실습

사용자가 EC2 IP를 선택해서 접근할 수 없도록 해야 한다. 왜 그럴까? 특정 선호하는 접근이 다량으로 발생되면, 오류 발생시 서비스 이용 불가능해진다.
L/B : 로드 밸런스는 각 EC2에 골고루 부하를 분배한다.

VPC 생성

VPC 이름 설정(TestVPC-015)
IPv4 CIDER 지정 : 10.0.0.0/16

서브넷 생성

생성된 VPC 좌측 화면에서 서브넷 으로 진입한다
서브넷 2개 생성한다.
- 1번째 서브넷 이름 : TestVPC-015
- 가용 영역이 (서울 리전 기준) : ap-northeast-2a
- IPv4 VPC CIDER block : 10.0.0.0/16
- IPv4 subnet CIDER block : 10.0.10.0/24
- 2번째 서브넷 이름 : TestVPC-015_2
- 가용 영역이 (서울 리전 기준) : ap-northeast-2c
- IPv4 VPC CIDER block : 10.0.0.0/16
- IPv4 subnet CIDER block : 10.0.30.0/24

인터넷 게이트웨이 생성

생성 후 VPC에 연결
인터넷 게이트웨이 이름 지정 필수 아님

라우팅 테이블 생성

서브넷 생성 시, 기본 라우팅 테이블에 local에 연결되어 있다.
라우팅 테이블 생성 : 라우팅 테이블 – 이름(선택) - VPC(TestVPC-015)=> 해당 VPC 내부에서 사용한다는 의미
생성한 라우팅 테이블 클릭 – 라우팅 - 라우팅 편집 – 라우팅 추가 – 대상{ 외부(0.0.0.0/0) 트래픽 } 대상{ IGW } 로 넘겨라 – 변경 사항 저장
서브넷(public-subnet-a)의 라우팅 테이블 등록 확인.

여기까지 구축한 것이다

서브넷에 배치할 인스턴스로, HTTP(90), SSH(443)포트로의 접근을 허용하도록 설정
VPC 좌측 메뉴 리스트에 존재
아웃바운드는 EC2 외부에서 추가로 처리되어 트래픽이 나가므로 아웃바운드는 설정하지 않는다.

웹 서버 인스턴스 생성

EC2 이름 : WebServer-015
AMI : 아마존 리눅스로 생성, HVM – Kernel 5.10 사용.
인스턴스 t2.micro
키 페어 – 기존 생성 키 사용 (MyKeyPair-015)
네트워크 설정 : VPC(TestVPC-015), 서브넷(public-subnet-a-015), 퍼블릭 IP 자동 할당(활성화), 방화벽(WebServerSG-015)
세부 정보에 소스코드 입력
EC2 인스턴스 실행 후 HTTP 와 퍼블릭 IP를 사용해 URL 접속 확인해보자.
잠깐, 윈도우 CMD에서 AWS CLI를 설치해보자! (참고 : https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/getting-started-install.html)

인스턴스에 SSH 접속 후 웹 서버를 설치

윈도우 CMD 창에서 ssh 입력 시, usage: 라고 나온다면, ssh 설치된 것.
Downloads 로 가면 전에 생성한 key 파일이 존재

키 파일을 가지고 사용자 계정, EC2 퍼블릭 IPv4주소로 AWS 접속(키 파일이 있는 위치에서 접속)
ssh –i MyKeyPair-015.pem ec2-user@43.201.97.214
사용하는 키 파일을 저장할거냐고 물어본다. yes =? 사용 키 파일 계속 저장

여기서 웹 서버를 올릴 수 있다. (실습 시, 설치하려는 웹 서버가 작동하지 않음)

기존 인스턴스를 종료하고 동일한 방식으로 인스턴스를 새로 추가.

SSH 로 접속해 웹 서버를 올리는 것이 아니라 EC2 인스턴스 생성 시, 사용자 데이터를 추가한다.
EC2 이름 : WebServer-015
AMI : 아마존 리눅스로 생성, HVM – Kernel 5.10 사용.
인스턴스 t2.micro
키 페어 – 기존 생성 키 사용 (MyKeyPair-015)
네트워크 설정 : VPC, 서브넷, 퍼블릭 IP 자동 할당(활성화), 방화벽(SG – 생성했던 SG 사용)
고급 세부 정보에 소스코드 입력
EC2 인스턴스 실행 후 HTTP 와 퍼블릭 IP를 사용해 URL 접속 확인

아래 내용은 EC2 인스턴스 생성 시, 고급 세부 정보에 소스코드를 입력한다.

#!/bin/sh

amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
yum -y install httpd php-mbstring

# Start the web server
chkconfig httpd on
systemctl start httpd

# Install the web pages for our lab
if [ ! -f /var/www/html/immersion-day-app-php7.tar.gz ]; then
cd /var/www/html
wget https://aws-joozero.s3.ap-northeast-2.amazonaws.com/immersion-day-app-php7.tar.gz  
tar xvfz immersion-day-app-php7.tar.gz
fi

# 
cat <<EOF > /var/www/html/get-index-meta-data.php
<?php
  \$hostname = gethostname();
  \$results = explode(".", \$hostname);
  echo "<table style='width:100%'>";
  echo "<tr><th style='width:30%'>Meta-Data</th><th style='width:70%'>Value</th></tr>";
  echo "<tr><td>Private IP DNS Name</td><td>".\$hostname."</td></tr>";
  echo "<tr><td>Private IP</td><td>".getHostByName(\$hostname)."</td></tr>";
  echo "<tr><td>Region</td><td>".\$results[1]."</td></tr>";
  echo "</table>";
?>
EOF

# Install the AWS SDK for PHP
if [ ! -f /var/www/html/aws.zip ]; then
cd /var/www/html
mkdir vendor
cd vendor
wget https://docs.aws.amazon.com/aws-sdk-php/v3/download/aws.zip
unzip aws.zip
fi

# Update existing packages
yum -y update

웹 서버 설정이 끝난 후, AMI를 생성한다.

생성한 EC2로부터 AMI를 사용해 2번째 부하 분산용 EC2를 생성한다.
생성한 EC2 체크 – 우측 상단 작업 – 이미지 및 템플릿 – 이미지 생성
사진에서는 041로 만들었지만, 015 로 만들어야 한다.
AMI 생성 후, 생성 과정 확인은 EC2 좌측 이미지 – AMI에서 확인 가능하다.

생성한 AMI 이미지를 이용해 웹 서버 인스턴스를 public-subnet-c 서브넷에 생성

EC2 생성 시 세부 데이터 항목에 입력했던 내용을 그대로 가지고 생성된다.
EC2 좌측 이미지 – AMI – 우측 상단에 AMI로 인스턴스 시작

첫 번째 웹 페이지의 Private IP는 10 대역 => 첫 번째 EC2
두 번재 웹 페이지으 Private IP는 30 대역 => 첫 번째 EC2 AMI 이미지로 생성한 두 번째 EC2

로드밸런서 구성

동일한 내용의 서비스를 제공하는 인스턴스 두 개가 실행 중인 환경
개별 인스턴스 주소로 접속하는 경우, 이용의 불편과 부하 집중의 문제가 발생할 수 있음
부하분산기를 이용해 서비스될 수있도록 수정
부하분산과 서비스 편의를 위해 제공
대상 그룹(Target Group)이란? 부하분산기가 동작하는 대상 범위
EC2 메뉴 좌측에서 로드 밸런서 선택
로드 밸런서 유형 : Application Load Balancer 선택
이름 : weblb-015
체계(schema) : 인터넷 경계 선택 -> 인터넷 경계 밸런서는 인터넷을 통해 클라이언트의 요청을 대상으로 라우팅한다. 퍼블릭 서브넷이 필요하다.
네트워크 매핑 : VPC 선택 – 어느 서브넷에 대해 연결할것인가

서브넷 2개와 매핑한다.
로드밸런스용 SG 생성한다 (Webserver sg 사용하지 않는다)

보안 그룹 이름 : lBS_SG_015
VPC : TestVPC-015
인바운드 HTTP/80, Anywhere-IPv4 0.0.0.0/0 으로 설정해 보안 그룹을 생성한다.
아웃바운드 규칙이 없어야 한다. 사진은 반대이다.
2시간동안 아웃바운드 규칙이 없어 EC2가 unhealthy 상태로, 로드밸런스 DNS 주소로 접근 시 503 오류(웹 페이지 불러올 수 없음)발생한다.
따라서, 아웃바운드 규칙은 아래와 같이 all all 로 지정해야 한다. 그래야 EC2에서 다시 외부로 결과를 전송 가능해진다.

리스너 및 라우팅은 HTTP/80
기본 작업 : 대상 그룹 생성
대상 유형은 인스턴스, 대상 그룹 이름 : webserver-TG-015, 프로토콜 HTTP,/80

다음 페이지에서는 대상을 등록한다.
위에서는 사용 가능한 인스턴스 목록이 나온다. 두 항목을 체크해 아래에 보류 중인것으로 포함 을 누르면 아래에서 대기 중 인 인스턴스를 확인하고 대상 그룹을 생성한다.

대상 그룹을 생성 후, 다시 로드 밸런서 생성 페이지로 돌아오면, 기본 작업의 새로고침을 누른 후, 생성한 대상 그룹을 선택하고 로드 밸런서를 생성한다.
로드밸런서가 생성되었다.
로드밸런서 - 세부정보 - 로드밸런서 DNS 이름을 가지고 URL에 입력 시, 아래와 같이 화면이 나온다. 새로고침하면 로드밸런스가 부하분산 목적으로 두 번째 접근에는 다른 EC2을 접근시켜주는 것을 확인 가능하다.
보안 그룹에서 WebServer-SG-015 인바운드 규칙을 확인한다.
생성된 로드 밸런서의 DNS 주소로 접근하면, 2개의 EC2를 차례대로 로드밸런싱해 보여준다.

-기존에서는 보안그룹의 인바운드 규칙으로 인해 HTTP/80 으로 접근하는 모든 소스(0.0.0.0/0)가 접근 가능했다. 인바운드 규칙 편집을 눌러 해당 규칙을 삭제하고 새로운 규칙을 추가한다.

만두다섯개

磨斧爲針

이전 포스트

SK shieldus Rookies 16기 (클라우드 보안 기술 #01)

다음 포스트

SK shieldus Rookies 16기 (클라우드 보안 기술 #02)

SK 루키즈 16기

주요 정보

무엇을 깨달았나

강의 자료 정보

IAM – 사용자 생성 및 권한부여

IAM 보안 모범 사례

루트 사용자 모범 사례

AWS 서비스를 이용하는 방법

사용자 접근 보안

AWS CLI 사용하는 이유?

VPC

기본 VPC 구성 요소

서브넷

ENI

인터넷 게이트웨이(IGW)

라우팅

보안 그룹 (SG, Security Group)

NACL

EC2

AMI

EBS

EIP

웹 서비스 환경 구성 실습

SK shieldus Rookies 16기 (클라우드 보안 기술 #01)

SK shieldus Rookies 16기 (클라우드 보안 기술 #03)

0개의 댓글