[SK 쉴더스] 클라우드 보안 4일차

1. RDS 실습

- RDS : Database 서버를 클라우드에서 동작시키고, 이용자는 Database를 사용하기만 함 → PaaS

- 장점 : DB 서버 관리를 하지 않아도 됨(DB 대용량으로 교체, 백업, 관리등을 AWS에서 제공) 

- DB는 로드밸런서를 사용하기 어려움 : Master DB에서 쓰기를 수행(데이터 일관성) → 대용량을 사용

                                                             - Slave DB는 Master DB에서 정보를 받고 사용자들이 읽기 요청할 때 처리

- Database에 대한 root 권한이 없음(권한이 높은 사용자 권한만 주어짐)

- Database가 설치된 서버에 대한 통제권이 없음(OS에 대한 권한 없음)

* 주의사항

- EC2와 연결해서 사용하도록 설정(퍼블릭 IP를 받을 수 없음)

- Local Workbench를 사용할 수 없음

- RDS에 주소를 부여하기 위해 VPC의 호스트 이름 사용 활성화

 

* 서버, 가상머신(EC2), 컨테이너(ECS), Lambda 등이 부족하면?

- Auto Scaling 을 통해 자동으로 확장 가능

- 로드밸런서(부하 분산장치) 사용 

 

* 컴퓨팅 설비 운영 방식

- On-Premise : 사용자들이 직접 자신의 회사 내에 서버, 네트워크 등을 구성해서 운영 ex) 국내 은행

- Hybrid : On-Premise와 Cloud를 섞어서 사용하는 방식

- All in Cloud : 모든 서버와 네트워크를 클라우드에 구성해서 운영 ex) Netflix

- Multi-Cloud : 여러 회사의 클라우드를 사용하는 것, AWS와 Azure, GCP, NCP 등을 사용하는 것

 

2. Hybrid Server 구축

2.1 실습준비

- 백업해둔 Ubuntu 22.04 LTS.zip 파일 이름변경 후 압축풀기

- VMware를 실행해서 압축 푼 폴더에서 vmx 찾아서 열기 > VM 이름변경(Ubuntu Web Server only)

 

2.2  RDS 생성

- 데이터베이스 생성 방식 : 표준생성

- 엔진 옵션 : MySQL

- 템플릿 : 프리 티어

- DB 인스턴스 식별자 : db-server

- 마스터 사용자 : admin / admin1234

- 인스턴스 구성 : 버스터블 클래스 - t2.micro 선택

- 연결(컴퓨팅 리소스) : EC2 연결 x

- 연결(퍼블릭 액세스) : 예

- vpc 보안 그룹 : 새로생성(DB_server)

- 데이터베이스 인증 : 암호 인증

 

2.3 Ubuntu Web Server only : Apache2, PHP 등 9개, vim, Gnuboard 설치 

- DB는 RDS 사용, DB에 대한 설정은 Workbench를 활용

$ sudo apt install vim

$ sudo apt install apache2    // 웹 서버 설치

- 웹 서버에서 사용할 언어 설치

$ sudo apt install php php-mysql php-common php-gd php-fpm php-xml php-json php-curl git

- 그누보드 다운

$ cd /var/www/html

$ sudo git clone https://github.com/gnuboard/gnuboard5    // github의 gnuboard를 통째로 복제

$ cd gnuboard5

$ sudo mkdir data

$ sudo chmod 707 data

$ sudo apt install net-tools

$ sudo service apache2 restart

 

2.4 Workbench 생성

- 생성한 RDS와 연결한 Workbench 생성

- Workbench에서 데이터베이스, 계정 생성 및 권한 부여

2.5 gnuboard 접속 및 설치

- ubuntu Web Server only의 ip주소/gnuboard5

- host : 생성한 RDS의 엔드포인트:3306

- User/Password : RDS 생성 시 작성한 마스터사용자 계정정보

- DB명 gnuboard, 웹사이트 관리자 admin/admin1234

 

* 게시물 업로드 테스트

→ 업로드 성공

 

*RDS에 접속이 안되는 경우 

- VPC를 직접 생성한 VPC로 설정(EC2와 연결하는 vpc를 선택한 경우

- 보안 그룹 설정시, db_server로 선택(3306 포트를 오픈하도록 설정한 보안그룹)

- 퍼블릭 IP 활성화

 

→ RDS 삭제(최종 스냅샷 체크 해제)

 

* IAM 

- Identification(식별) : 다른 사용자와 구분되는 사용자의 정체성 ex)ID, 사번, 학번, 주민등록번호 등

- Authentication(인증) : 지식기반, 소유기간, 생체기반, 위치기반 → 본인임을 인증하는 방식

- Authorization(인가 = 권한부여) : 읽기, 쓰기, 수정, 복사, 삭제, 출력 권한을 업무에 맞게 부여

 

3. 인증(Authentication)

- 올바른 사용자임을 증명하는 것(본인 인증)

1) 지식기반 : 알고있는 것으로 증명하는 것(What you Know)

- 방법 : 패스워드(=암호), 패스프레이즈(패스워드보다 긴 문구), 암구어, 야구 사인 등

2) 소유기반 : 가지고있는 것으로 증명하는 것(What you Have)

- 방법 : 열쇠(key), 신분증(주민증, 여권, 사원증, 학생증 등), 카드(신용, 체크, 현금), OTP, 공인인증서, 휴대폰 인증 등

3) 생체기반 : 생체적 특징으로 증명하는ㄴ 것(Who you Are)
- 방법 : 지문, 홍채(iris), 망막, 손바닥(융기선과 골짜기), 손모양, 손등(정맥), 얼굴, 목소리 등

4) 위치기반 : 자신이 있는 위치로 증명하는 것(Where you Are)

- 방법 : GPS, Wi-Fi(IP 주소), 통신사 기지국 삼각측량 등

 

* 인증에서 중요한 것 : Multi-Factor 인증 사용
→ 4가지 방식 중에 최소한 2가지 이상을 사용

- AWS에서는 Multi-Factor 인증 권장 : 비밀번호 + 구글 OTP, Root 계정의 경우 Email 인증(소유기반)

 

* Root 계정을 개인 메일로 등록한 사람이 퇴사하면?

→ 구글 OTP를 사용해서 Multi-Factor 인증 사용(퇴사자는 구글 OTP 접근x)

* Root 계정 관리 방법

- AWS 가입할 때 root 계정을 회사의 AWS용 계정을 별도로 만들어서 등록(AWS 담당자가 메일관리)

* 프로젝트 진행시, root 계정 제공x → 사용자를 생성하고 권한을 부여해야 함

- 권한은 최소한의 권한(Least Privileges)만 부여

- 권한을 너무 많이주면 → 부정행위, 불법행위의 가능성 높아짐

- 정보는 꼭 필요한만큼만 알려줌(Need to Know) → 업무 수행에 필요한 만큼만 제공

 

4. 접근(Access)

- Subject(주체) : 접근을 하는 쪽  ex) User, Program, Process, Cloud Service 등

- Object(객체) : 접근을 받는 쪽  ex) Data, File, Directory, Database 등

- 접근 권한을 부여 : Subject가 Object에 접근하는 것을 통제(Control)

- ex) EC2가 로그를 S3에 저장하려면 → 접근 권한을 모아서 Role을 EC2에 부여

 

* 클라우드의 종류

- 클라우드 업체가 책임을 지는 범위 : SaaS > PaaS > IaaS

- SECaaS : Security As a Service(클라우드에서 보안 서비스를 제공하는 것)  ex) 건물 출입-얼굴정보가 cloud에 저장

cf. RaaS :  Ransomware as a Service (클라우드에서 랜섬웨어를 제공)

 

4.1 계정의 종류

- 사용자(User) : 1인당 1개씩 부여(여러사람이 하나의 ID를 공유 : 사고 발생시 책임소재를 찾을 수 없음)

- 사용자 그룹(User Group) : 사용자가 많을 때, 권한을 일괄적으로 부여 또는 제거

- 정책(Policy) : 세부적인 권한을 모아서 정책으로 만듦

- 역할(Role) : 정책을 모아서 역할을 만듦 → 다른 클라우드 서비스에 부여(CloudFormation등 자동화도구), 사용자에 부여x  → 중요!

 

* 정책

- Root 계정은 업무에 사용하지 않음

- AdministratorAccess : 모든 서비스에 대한 모든 권한 → 최소한의 인력에게만 부여

- 꼭 필요한 만큼만 제공

ex) 프로젝트에 참여하지 않는 인원이 프로젝트를 보려고 하는 경우, AmazonEC2ReadonlyAccess 권한 부여

 

4.2 Access Key

- Command Line만 사용해야하는 상태에서 로그인 대신 사용할 수 있는 Access Key(ID)와 Secret Key(Passwd)를 부여

- Amazion의 EC2, S3 등을 Command Line으로 확인, 생성, 관리할 수 있는 방식

- 인터넷에 절대 공개해서는 안됨

→ 공개할 경우 채굴기가 Cloud에 연결될 수 있음(엄청난 비용 청구)

 

4.3. 실습 - AWS CLI 설정 → 위험이 있어서 실습 x

1) Ubuntu Web Server only 

$ sudo apt update

$ sudo apt install python-setuptools python3-pip -y    // 파이썬 설치

$ sudo apt install vim

$ sudo apt install net-tools

$ sudo pip install aswcli    // 아마존에서 CLI 설치 완료

2) AWS S3 - 버킷 생성

- 이름 : 유일해야 함(rookiesmjbucket)

- 객체소유권 : ACL 활성화(접근제한), 버킷 소유자 선호

- 퍼블릭 액세스 차단 해제

- 버킷 버전 관리, 암호화 : 비활성화

→ 생성한 버킷에 이미지 업로드, ACL을 이용해 퍼블릭 설정

 

5. Load Balancing

5.1 Hot-Standby

- Hot : 클라이언트가 요청시 응답하는 서버(활성화) - 모든 요청을 처리

- Standby : 클라이언트의 요청에 응답하지 않음(비활성화) - 꺼져있는 서버는 아님

- Hot 인 서버에 문제 발생시 Standby 서버가 Hot이 되고, 휴식상태(켜져있기만 함)의 서버가 Standby가 됨

 

5.2 로드밸런싱

- 가용성(Availability) : 항상 사용 가능한 상태를 유지하는 것

- 서버들의 부하를 분산해주기 때문에 더 많은 클라이언트들이 접속할 수 있음

- 혹시 서버가 고장나더라도 다른 서버들이 응답하므로 문제 해결

- 서버의 문제 발생 확인 가능(Health Check)

 

5.3 로드밸런서의 종류

1) ALB(Application Load Balancer) : 7계층 로드밸런서 → URL등을 보고 부하를 분산

2) NLB(Network Load Balancer) : 4계층 로드밸런서 → Port 번호를 보고 부하를 분산

 

5.4 실습 - 두 대의 EC2 생성

- 정상적으로 동작하는 EC2 한대 필요(Apache2만 설치, index.html을 vim으로 복사 (이름은 이니셜_red)

- 템플릿을 만듦 → 템플릿을 이용해서 이니셜_blue 추가

1) EC2 생성 (mj_red)

2) EC2 접속 - apache2 설치

$ sudo apt update

$ sudo apt install vim

$ sudo apt install apache2

3) index.html 복사

$ cd /var/www/html

$ sudo mv index.html index.old

4) 템플릿 생성

- 인스턴스 ID 우클릭 > 이미지 및 템플릿 < 인스턴스에서 템플릿 생성

- 이름 작성 > 시작 템플릿 생성(이전에 만든 인스턴스와 동일한 템플릿을 만드는 것 이므로 설정 변경할 필요 x)

5) 템플릿으로 인스턴스 시작

- 생성한 템플릿 선택 > 인스턴스 시작

- 이름을 mj_blue로 저장

* 템플릿으로 만들면 설정까지 복사되지는 않음

→ 설정까지 모두 복사되려면 이미지로 복제해야함

 

6) 생성한 인스턴스 접속

- 윈도우 cmd에서 인스턴스의 ssh 클라이언트 명령어 입력

- mj_red와 같은 방법으로 apache2 설치

$ sudo vi index.html

5.5 로드밸런서 접속

- EC2 > 로드밸런서 > 로드밸런서 생성

- Application Load Balancer create

- 이름 : web-alb

- Intenet-facing : 외부용 (선택) / Internal : 내부용

- IP address type : IPv4 선택

- Network mapping : VPC, Subnet(2개) 생성한 걸로 지정 - 서브넷은 둘다 vpc에 명시적으로 연결되어있어야 함

- Security Groups : 생성해놓은 web-server 선택

- Listener : 80

* create target group

  - Instances

  - name : tg-web

  - 생성한 VPC 선택

  - health checks : http

  - next 클릭

 

  - target group에 등록 : 두 서버 체크 후 Include as pending below 클릭

- default actino에 생성한 타겟그룹 선택(tg-web)

→ create load balancer 클릭

생성된 로드밸런서

 

- DNS 이름 복사 - 접속 : red와 blue가 번갈아가면서 출력되는것 확인

 

* Load Balancer 생성시 주의사항

1) Subnet이 2개 이상이어야 함

- public, private 상관없이 2개면 됨

- 가용영역(AZ)을 2개 지정(EC2가 한쪽에 있어도 됨)

- 모든 Subnet이 라우팅테이블에 명시적으로 등록되어있어야 함

2) Target Group을 생성

- 인스턴스를 target group에 추가 → Instance Pending Below

3) EC2의 개수와 Subnet을 LoadBalancer에 등록하는 것은 상관없음