728x90

CloudEndure

온프레미스에서 AWS 환경으로 마이그레이션 I - WordPress 설치

아키텍처 구성도

 

사전 작업

- 가상 머신에 WordPress 설치 (CentOS7, Apache2, MariaDB, PHP)

 

마이그레이션 작업

  1. CloudEndure 계정 등록
  2. CloudEndure 콘솔에 로그인
  3. 프로젝트 설정
  4. 자격 증명 생성 및 사용 (정책 생성, IAM 사용자 및 자격 증명 생성, AWS 자격 증명 적용)
  5. 복제 설정 구성
  6. CloudEndure 에이전트 설치
  7. WordPress 콘텐츠 생성
  8. 대상 머신 Blueprint 구성
  9. 대상 머신 테스트

 

WordPress 설치

 

VMware Tools 설치

더보기

# VMware Tools 설치

mkdir /mnt/cdrom
mount /dev/cdrom /mnt/cdrom
cp /mnt/cdrom/VMwareTools-version.tar.gz /tmp/
ls /mnt/cdrom
cd /tmp
tar -zxvf VMwareTools-version.tar.gz
cd vmware-tools-distrib
./vmware-install.pl

# pl 실행 에러 시
yum install –y perl

# ifconfig 명령어 설치
yum install -y net-tools

Install VM ware Tools

 

Apache 설치

더보기

# 아파치 설치

yum -y update
yum -y install httpd
systemctl start httpd
systemctl enable httpd
firewall-cmd --add-service=http --permanent
firewall- cmd --add-service=https --permanent
firewall-cmd --reload
systemctl status httpd.service
웹 브라우저 열기
http://IP 주소 접속

테스트 페이지 확인

 

MariaDB 설치

더보기

yum install -y mariadb-server mariadb
systemctl start mariadb
systemctl enable mariadb
systemctl status mariadb
mysql_secure_installation
엔터
mariadb root 계정의 비밀번호를 생성할 것인가
y
새로 추가할 root 계정의 비밀번호 등록
It12345!
인증된 계정만 접속할 수 있도록 anonymous 계정을 삭제할 것인가
y
mariadb root 계정이 외부에서 접속하지 못하도록 할 것인가
y
테스트용 DB를 삭제할 것인가
y
설정을 바로 적용할 것인가
y

MariaDB 설치 및 구성 완료

 

PHP 설치

더보기

# PHP 설치

yum install -y wget
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -Uvh epel-release-latest-7.noarch.rpm
wget http://rpms.remirepo.net/enterprise/remi-release-7.rpm
rpm -Uvh remi-release-7.rpm
yum install -y yum-utils
yum-config-manager --enable remi-php72
yum -y install php php-mysql php-gd
vi /var/www/html/index.php
<?php phpinfo(); ?>
systemctl restart httpd

# 웹 브라우저 열기
http://IP 주소/index.php 접속

# 소스 코드가 그대로 출력될 경우
vi /etc/httpd/conf/httpd.conf
AddType application/x-httpd-php .html .php7 .php
AddType application/x-httpd-php-source .phps
systemctl restart httpd

PHP 테스트 페이지 확인
테스트 페이지 대신 소스 코드가 출력될 경우

 

WordPress 설치 및 구성

더보기

mysql -uroot -pIt12345!
CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL ON wordpress.* TO 'user'@'localhost' IDENTIFIED BY 'It12345!';
exit
yum install -y wget
wget "http://wordpress.org/latest.tar.gz"
tar -xvzf latest.tar.gz -C /var/www/html
ll /var/www/html/
chown -R apache: /var/www/html/wordpress
ll /var/www/html/
vi /etc/httpd/conf/httpd.conf
systemctl restart httpd.service


# 웹 브라우저 열기
http://ip주소/wp-admin/setup-config.php

 

 

한국어 선택

 

설치 시작

 

앞서 생성한 정보 입력

 

wp-config.php 파일 생성

더보기

cd /var/www/html/wordpress/
vi wp-config.php
systemctl restart httpd

wp-config.php 파일 생성

 

WordPress에서 사용할 사이트 제목과 WordPress 관리 계정 생성

 

생성 완료

 

로그인

 

WordPress 관리자 페이지 확인

 

①http://IP주소를 입력하여 WordPress 페이지 확인

728x90
728x90

Monitoring

루트 계정에 대한 계정 활동 모니터링 및 알림 설정

  1. CloudWatch Events 규칙은 AWS Root 사용자 계정 API의 모든 이벤트 감지
  2. AWS Lambda 함수 트리거
  3. Lambda 함수는 Root API 이벤트 처리
  4. SNS 주제에 메시지 게시
    - 제목: Root API 호출이 감지된 AWS 계정 ID 또는 AWS 계정 별칭과 API 활동 유형 포함
  5. SNS 주제는 이벤트에 대한 알림을 구독자에게 이메일 전송

사전 작업

  1. 모든 AWS 리전에 대해 다중 리전 AWS CloudTrail 추적 생성 및 활성화
  2. RootActivityLambda.zip 파일을 S3 버킷에 업로드

 

CloudTrail 추적 활성화

  • 모든 리전에 적용되는 추적은 모든 리전에서 S3 버킷으로 로그 파일을 전송함
  • 추적을 생성하면 사용자가 지정한 이벤트에 대한 로깅을 자동으로 시작함
  • 계정에 대한 추적 생성 시 이점
  • 1) 로그 이벤트를 Amazon CloudWatch Logs로 보내 지정된 이벤트를 자동으로 모니터링함
  • 2) Amazon Athena로 사용자 활동을 분석하고 로그를 쿼리하는 옵션

 

CloudTrail 콘솔 > 추적 생성

 

 

로그 파일 SSE-KMS 암호화 > SSE-S3 대신 SSE-KMS로 로그 파일을 암호화 할 경우 활성화

추가 설정
 > 로그 파일 검증 : 로그 다이제스트를 S3 버킷으로 전송
 > SNS 알림 전송 : 로그가 버킷으로 전송될 때마다 알림
                - 여러 이벤트를 로그 파일에 저장
                - CloudTrail의 모든 이벤트가 아닌 모든 로그 파일에 대한 SNS 알림 전송

 

 

CloudWatch Logs > 로그 파일을 전송하도록 구성
태그 > CloudTrail 추적과 CloudTrail 로그 파일이 포함된 Amazon S3 버킷을 모두 식별

 

관리 이벤트 : 기본
데이터 이벤트 : 추가 요금 부과
Insight 이벤트 : 추가 요금 부과

 

생성 완료

 

 

RootActivityLambda.zip 다운로드

 

S3 버킷에 파일 업로드

 

CloudFormation을 이용한 배포

  1. RootAPIMonitor.json 템플릿을 이용한 스택 생성
  2. us-east-1 리전에서 스택 생성
    - Root API 로그인은 글로벌 이벤트이며 us-east-1에서 기록됨
  3. 매개 변수 정보 입력
  4. 선택 기능 수신 확인 선택
  5. CloudFormation 스택 완료 시 SNSSubscriptions에 제공된 이메일로 전송 된 SNS 구독 이메일 확인

 

객체 URL 복사

 

복사한 객체 URL 입력

 

파라미터 입력
SNSSubscriptions : SNS 주제를 구독할 이메일 주소
SNSTopicName : 생성할 SNS 주제의 고유한 이름
Lambda Timeout : Lambda 함수 제한 시간 값
LambdaS3Bucket : Lambda 함수 zip 파일이 저장된 S3 버킷의 이름
LambdaS3Key : Lambda 함수 zip 파일의 이름

파라미터 입력

 

스택 생성 완료

 

파라미터 값에 입력한 이메일 주소로 구독 확인 메일이 수신됨 

 

이후 루트 계정에서 로그인을 하면 메일로 알림을 받음

 

728x90
728x90

AWS IAM

보안 모범 사례 II - 사용자 계정

  1. MFA 활성화
  2. IAM 사용자 및 그룹 관리 (개별 IAM 사용자 생성, 그룹을 사용한 권한 할당)
  3. IAM 비밀번호 정책 적용
  4. 액세스 키 회전

 

MFA 활성화

 

AWS 공식 홈페이지에서 안내하는 가상 MFA 디바이스 설정과 호환되는 애플리케이션 목록 확인

 

애플리케이션 설치

 

IAM 콘솔 > 사용자 > 생성한 사용자 > 보안 자격 증명 > 할당된 MFA 디바이스 > 관리

 

가상 MFA 디바이스

 

어플리케이션 실행 > 바코드 스캔

 

QR 코드 표시 > QR 코드 스캔 > MFA 코드 두 번 입력 > MFA 할당

 

MFA가 할당된 것을 확인할 수 있음

 

IAM 사용자 및 그룹 관리

user라는 사용자 계정을 추가하고 AdministratorAccess 정책이 적용되도록 Administrator 그룹에 추가한다.

 

 

액세스 키 회전

사용자 계정만 해당되는 항목

 

 

최초 액세스 키가 활성 상태이므로 두 번째 액세스 키를 생성한다.

 

 

새 액세스 키를 사용하도록 모든 애플리케이션과 도구를 업데이트한다.

최초 액세스 키를 아직도 사용하고 있는지 확인하고 사용 내역이 없다면 삭제대신 비활성화를 시킨다.

 

 

 

새 액세스 키를 정상적으로 사용하고 있는지 확인하고 최초 액세스 키를 삭제한다.

728x90
728x90

AWS IAM

IAM의 보안 모범 사례 I - 루트 계정

  1. 루트 액세스 키 삭제
  2. MFA 활성화
  3. IAM 사용자 및 그룹 관리 (개별 IAM 사용자 생성, 그룹을 사용한 권한 할당)
  4. IAM 비밀번호 정책 적용

루트 액세스 키 삭제

루트 계정에 해당하는 보안 항목

 

루트 계정으로 로그인 > IAM 콘솔 접속
AWS 계정 생성 후 첫 로그인 시에는 취약한 보안 상태를 확인할 수 있음

 

추후 모범 사례에 따른 보안 설정을 마친다면 안전한 상태가 됨

 

액세스 키 존재 여부 확인

 

액세스 키가 존재한다면 해당 키를 삭제한다.

 

MFA 활성화

루트 계정과 사용자 계정 모두 적용되는 항목

 

MFA 호환 앱 확인

AWS 공식 홈페이지에서 안내하는 가상 MFA 디바이스 설정과 호환되는 애플리케이션 목록 확인

 

여러 개의 애플리케이션 중 한 가지를 선택하여 설치

 

루트 계정에서 MFA 활성화

 

가상 MFA 디바이스 선택

 

다운로드한 어플리케이션 실행 > 바코드 스캔

 

QR 코드 표시 > QR 코드 스캔 > MFA 코드 두 번 입력 > MFA 할당
MFA 활성화 완료

 

IAM 사용자 및 그룹 관리

 

결제 정보에 대해 IAM 사용자 접근 권한을 부여하는 설정 (루트 계정에서만 설정 가능)

 

내 계정

 

편집

 

IAM 액세스 활성화 체크 > IAM 사용자가 결제 대시 보드에 액세스할 수 있음

 

사용자와 그룹을 직무 또는 역할따라 생성하고 그룹 단위로 정책을 할당하여 관리한다.

AWS에서는 루트 계정 사용을 최소화하고 IAM 사용자와 그룹을 이용하여 관리자 IAM 사용자 및 그룹을 생성하여 사용하는 것을 권장한다. (단, AdministratorAccess 정책은 관리자 사용자 및 그룹에게만 부여할 것을 주의한다)

 

관리자 사용자 추가
관리자 그룹 생성
AdministratorAccess 정책을 연결하여 관리자 권한 부여
.csv 파일은 추후 액세스 키 재발급 등으로 주기적인 교체를 해주는 것을 권장한다.

 

IAM 비밀번호 정책 적용

 

 

 

728x90
728x90

Amazon VPC

VPC Flow Logs 구성

  1. CloudWatch 로그 그룹 생성
  2. IAM 역할 생성
  3. Flow Logs 생성
    - VPC, 서브넷, 게이트웨이 등 네트워크 인터페이스

 

VPC Flow Logs란?

VPC의 네트워크 인터페이스에서 전송되고 수신되는 IP 트래픽에 대한 정보를 수집하는 기능

 

로그 정보

  1. 보안 그룹 및 NACL 규칙에 의해 허용 및 차단된 트래픽 정보
  2. 소스&목적지 IP 주소, 포트, 프로토콜 번호 패킷 바이트 모니터링 간격 시간
  3. ACCEPT 또는 REJECT 액션 정보

 

Flow Logs를 생성할 수 있는 다른 AWS 서비스

  • Elastic Load Balancing
  • Amazon RDS
  • Amazon ElastiCache
  • Amazon Redshift
  • Amazon WorkSpaces
  • NAT 게이트웨이
  • 전송 게이트웨이

 

CloudWatch 로그 그룹 생성

 

ClouWatch 콘솔 접속 > CloudWatch Logs > 로그 그룹 > 로그 그룹 생성

 

로그 그룹 이름 입력 후 생성

 

CloudWatch Logs에 Flow Log를 게시하기 위한 IAM 역할 생성

 

IAM 콘솔 접속 > 역할 > 역할 생성 > AWS 서비스: EC2

 

역할 이름 및 설명 입력 후 생성 완료

 

생성한 역할에 인라인 정책 추가

 

더보기

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogGroups",
        "logs:DescribeLogStreams"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

 

위와 같은 최소 권한 필요

 

정책 생성 완료

 

Flow Logs의 역할을 허용하는 신뢰 관계 편집

 

더보기

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "vpc-flow-logs.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Flow Logs 생성

 

플로우 로그를 수집할 VPC 선택 후 플로우 로그 생성

 

플로우 로그 구성

 

플로우 로그 생성 완료

 

Flow logs 확인

플로우 로그 작성 후 약 15분 후에 새로운 로그 그룹이 생성되고 로그를 확인할 수 있음

 

 

728x90
728x90

Amazon Route 53

가비아에서 구입한 도메인 AWS에서 사용하기

  1. Route 53에서 호스팅 영역 생성
  2. 가비아에서 도메인 정보 변경
  3. 네임 서버 변경 적용

 

Route 53에서 호스팅 영역 생성

 

Route 53 콘솔 > 호스팅 영역 생성

 

가비아에서 구매한 도메인 이름 입력 후 호스팅 영역 생성

 

생성된 레코드에서 네임 서버 모두 복사

 

가비아 홈페이지로 접속하여 해당 도메인의 도메인 정보 변경

 

복사한 네임 서버로 변경하여 적용

728x90
728x90

AWS Certificate Manager

인증서 등록

  1. 인증서 요청
  2. DNS 또는 이메일 검증
  3. 발급 완료

 

인증서 요청

인증서 요청

 

도메인 이름 추가

 

DNS 또는 이메일 검증

DNS 또는 이메일 검증 선택

 

도메인 이름 및 검증 방법 검토 후 요청

 

DNS 검증을 위해 Route 53에서 레코드 생성 선택

 

Route 53에서 레코드가 생성된 것을 확인할 수 있음

 

생성된 레코드는 추후 인증서 갱신에 이용되므로 삭제 금지

 

발급 완료

레코드가 생성되고 몇 분 후 발급 완료 상태가 된 것을 확인할 수 있음

728x90
728x90

Amazon RDS

DB 인스턴스의 서브넷 변경

Overview

퍼블릭 서브넷에 있는 RDS DB 인스턴스를 동일한 VPC내의 프라이빗 서브넷으로 이동하는 방법

  1. DB 인스턴스에서 다중 AZ 배포 및 퍼블릭 액세스 가능 여부 비활성화
  2. DB 인스턴스의 IP 주소 검색
  3. 퍼블릭 서브넷 제거 및 DB 인스턴스에 프라이빗 서브넷 추가
  4. DB 인스턴스에서 다중 AZ 활성화
  5. 장애 조치를 통한 DB 인스턴스 재부팅 및 다중 AZ 배포 비활성화
  6. 퍼블릭 서브넷 제거

해당 방법의 이점

  • 새 DB 인스턴스 생성 필요 X
  • 스냅샷 복원 프로세스 사용 필요 X
  • 새 인스턴스 생성 및 트래픽 전환과 관련된 다운타임 최소화, 장애 조치 시에만 다운타임 발생

 

DB 인스턴스에서 다중 AZ 배포 및 퍼블릭 액세스 가능 여부 비활성화

 

RDS 콘솔 접속 > 생성한 DB 인스턴스 선택

 

DB 인스턴스의 연결 & 보안 탭에서 퍼블릭 액세스 가능성 확인(아니요)

 

구성 탭에서 다중 AZ 옵션 확인(아니요)

 

퍼블릭 액세스 가능성과 다중 AZ의 파라미터 값이 아니요라면 수정할 필요 없음

 

다중 AZ의 옵션 해제

 

퍼블릭 액세스 불가, 변경 사항은 즉시 적용하여 DB 인스턴스를 수정함

 

DB 인스턴스 수정이 완료되어 사용 가능 상태인지 확인

 

DB 인스터스의 IP 주소 검색

 

현재 DB 인스턴스는 SSH 연결이 불가하므로 EC2 인스턴스를 Bastion Host로 이용하여 접속할 수 있음 (DB 인스턴스 IP 주소 확인 명령어: dig [DB 인스턴스의 엔드포인트])

 

DB 인스턴스의 IP를 통해 DB 인스턴스가 생성된 가용 영역과 서브넷을 확인할 수 있음

 

퍼블릭 서브넷 제거 및 DB 인스턴스에 프라이빗 서브넷 추가

사전 작업

- DB 인스턴스에 할당할 프라이빗 서브넷 추가

- 프라이빗 라우팅 테이블 생성 후 서브넷 연결

- 해당 작업에서는 172.31.0.0/20, 172.31.16.0/20 서브넷에 연결

 

RDS 콘솔 > DB 인스턴스 > 연결 & 보안 탭 > 서브넷 그룹에서 DB 인스턴스의 서브넷 그룹 확인

 

서브넷 그룹 편집

 

생성한 퍼블릭과 프라이빗 서브넷이 있는 가용 영역을 선택하고 프라이빗 서브넷 선택 후 저장

DB 인스턴스에서 다중 AZ 활성화

 

장애 조치 테스트를 위한 다중 AZ 활성화 설정

 

 

다중 AZ 옵션을 수정하였으므로 DB 인스턴스 수정 상태

장애 조치로 DB 인스턴스 재부팅 및 다중 AZ 배포 비활성화

 

장애 조치를 위한 재부팅

 

장애 조치로 재부팅

 

장애 조치가 진행되면 프라이빗 IP를 사용하는 보조 서브넷이 기본 서브넷으로 변경되고 기존의 퍼블릭 서브넷이 보조 서브넷으로 변경됨

 

서브넷 변경 전 가용 영역과 퍼블릭 서브넷 확인

 

재부팅 후 변경된 가용 영역과 프라이빗 서브넷 확인

 

퍼블릭 서브넷 제거

 

퍼블릭 서브넷 제거를 위해 다중 AZ 배포 비활성화

 

퍼블릭 서브넷 제거 후 필요에 따라 다중 AZ 배포를 활성화 하도록 함

 

서브넷 그룹에서 퍼블릭 서브넷을 제거하고 프라이빗 서브넷 추가

 

728x90

+ Recent posts