기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AL2 자습서 다음 자습서에서는 AL2를 실행하는 Amazon EC2 인스턴스를 사용하여 일반적인 작업을 수행하는 방법을 보여줍니다. 동영상 자습서는 [AWS 교육 동영상 및 실습](https://www.aws.training/) 섹션을 참조하세요. AL2023 지침은 *Amazon Linux 2023 사용 설명서의 *[자습](https://docs.aws.amazon.com/linux/al2023/ug/tutorials-al2023.html)서를 참조하세요. **Topics** + [자습서: AL2에 LAMP 서버 설치](ec2-lamp-amazon-linux-2.md) + [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md) + [자습서: AL2에서 WordPress 블로그 호스팅](hosting-wordpress.md) # 자습서: AL2에 LAMP 서버 설치 다음 절차는 AL2 인스턴스(LAMP 웹 서버 또는 LAMP 스택이라고도 함)에 PHP 및 [MariaDB](https://mariadb.org/about/)(MySQL의 커뮤니티 개발 포크) 지원이 포함된 Apache 웹 서버를 설치하는 데 도움이 됩니다. 이 서버를 사용해서 고정 웹사이트를 호스팅하거나 데이터베이스에서 정보를 읽고 쓰는 동적 PHP 애플리케이션을 배포할 수 있습니다. **중요** Ubuntu 또는 Red Hat Enterprise, Linux와 같은 다른 배포에서 LAMP 웹 서버를 설정하려는 경우 이 자습서를 이용할 수 없습니다. AL2023의 경우 [AL2023에 LAMP 서버 설치를 참조하세요](https://docs.aws.amazon.com//linux/al2023/ug/ec2-lamp-amazon-linux-2023.html). Ubuntu의 경우 Ubuntu 커뮤니티 설명서 [ApacheMySQLPHP](https://help.ubuntu.com/community/ApacheMySQLPHP)를 참조하세요. 다른 배포는 관련 설명서를 참조하세요. **옵션: 자동화를 사용하여 이 자습서 완료** 다음 작업 대신 AWS Systems Manager 자동화를 사용하여이 자습서를 완료하려면 [AWS Docs-InstallALAMPServer-AL2](https://console.aws.amazon.com/systems-manager/automation/execute/AWSDocs-InstallALAMPServer-AL2) 자동화 문서를 실행합니다. **Topics** + [1단계: LAMP 서버 준비](#prepare-lamp-server) + [2단계: LAMP 서버 테스트](#test-lamp-server) + [3단계: 데이터베이스 서버 보안 설정](#secure-mariadb-lamp-server) + [4단계: (선택 사항) phpMyAdmin 설치](#install-phpmyadmin-lamp-server) + [문제 해결](#lamp-troubleshooting) + [관련 주제](#lamp-more-info) ## 1단계: LAMP 서버 준비 **사전 조건** + 이 자습서에서는 인터넷에서 연결할 수 있는 퍼블릭 DNS 이름으로 AL2를 사용하여 새 인스턴스를 이미 시작했다고 가정합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)을 참조하세요. SSH(포트 22), HTTP(포트 80), HTTPS(포트 443) 연결을 허용할 수 있도록 보안 그룹을 구성해야 합니다. 이러한 사전 조건에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [보안 그룹 규칙을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html) 참조하세요. + 다음 절차에서는 현재 AL2에서 사용할 수 있는 최신 PHP 버전을 설치합니다`php8.2`. 이 자습서에서 명시한 애플리케이션이 아닌 PHP 애플리케이션을 사용하려는 경우 `php8.2`와의 호환성을 확인해야 합니다. **LAMP 서버를 준비하려면** 1. [인스턴스에 연결합니다](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html). 1. 모든 소프트웨어 패키지가 최신 상태로 업데이트되어 있는지 확인하기 위해, 인스턴스에서 퀵 소프트웨어 업데이트를 실행합니다. 이 업데이트 과정은 몇 분 정도 시간이 소요될 수 있지만, 최신 보안 업데이트와 버그 수정을 위해 수행할 필요가 있습니다. `-y` 옵션을 사용하면 확인 여부를 묻지 않고 업데이트를 설치합니다. 설치 전에 업데이트 정보를 확인하려면 이 옵션을 생략합니다. ``` [ec2-user ~]$ sudo yum update -y ``` 1. `mariadb10.5` Amazon Linux Extras 리포지토리를 설치하여 최신 버전의 MariaDB 패키지를 가져옵니다. ``` [ec2-user ~]$ sudo amazon-linux-extras install mariadb10.5 ``` `sudo: amazon-linux-extras: command not found` 오류가 발생하면 인스턴스가 Amazon Linux 2 AMI로 실행되지 않은 것입니다(Amazon Linux AMI를 사용하고 있는 것일 수 있음). 다음 명령을 사용하여 Amazon Linux 버전을 볼 수 있습니다. ``` cat /etc/system-release ``` 1. `php8.2` Amazon Linux Extras 리포지토리를 설치하여 AL2용 PHP 패키지의 최신 버전을 가져옵니다. ``` [ec2-user ~]$ sudo amazon-linux-extras install php8.2 ``` 1. 이제 인스턴스가 최신 상태이므로 Apache 웹 서버, MariaDB 및 PHP 소프트웨어 패키지를 설치할 수 있습니다. yum install 명령을 사용하여 여러 소프트웨어 패키지와 모든 관련 종속 프로그램을 동시에 설치합니다. ``` [ec2-user ~]$ sudo yum install -y httpd ``` 다음 명령을 사용하여 이러한 패키지의 현재 버전을 볼 수 있습니다. ``` yum info package_name ``` 1. Apache 웹 서버를 시작합니다. ``` [ec2-user ~]$ sudo systemctl start httpd ``` 1. **systemctl** 명령을 사용하여 Apache 웹 서버가 매번 시스템이 부팅할 때마다 시작되도록 합니다. ``` [ec2-user ~]$ sudo systemctl enable httpd ``` 다음 명령을 실행하여 **httpd**가 실행되고 있는지 확인할 수 있습니다. ``` [ec2-user ~]$ sudo systemctl is-enabled httpd ``` 1. 인스턴스에 대해 인바운드 HTTP(포트 80) 연결을 허용하는 보안 규칙이 없는 경우 추가합니다. 기본적으로 초기화 중에 인스턴스에 대해 **launch-wizard-*N*** 보안 그룹이 설정됩니다. 이 그룹에는 SSH 연결을 허용하는 규칙이 한 개 들어 있습니다. 1. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)에서 Amazon EC2 콘솔을 엽니다. 1. **인스턴스**를 선택하고 해당 인스턴스를 선택합니다. 1. **보안** 탭에서 인바운드 규칙을 확인합니다. 다음과 같은 규칙이 표시되어야 합니다. ``` Port range Protocol Source 22 tcp 0.0.0.0/0 ``` **주의** `0.0.0.0/0`을 사용하면 모든 IP 주소에서 SSH를 사용하여 인스턴스에 액세스할 수 있습니다. 테스트 환경에서 잠시 사용하는 것은 괜찮지만 프로덕션 환경에서는 안전하지 않습니다. 프로덕션에서는 특정 IP 주소나 주소 범위만 인스턴스에 액세스하도록 허용하세요. 1. 보안 그룹에 대한 링크를 선택합니다. [보안 그룹에 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule)의 절차에 따라 다음 값을 사용하여 새 인바운드 보안 규칙을 추가합니다. + **유형**: HTTP + **프로토콜**: TCP + **포트 범위**: 80 + **소스**: 사용자 지정 1. 웹 서버를 테스트합니다. 웹 브라우저에서 인스턴스의 공용 DNS 주소(또는 공용 IP 주소)를 입력합니다. `/var/www/html`에 콘텐츠가 없으면 Apache 테스트 페이지가 표시됩니다. Amazon EC2 콘솔을 사용하여 인스턴스의 퍼블릭 DNS를 확인할 수 있습니다. **퍼블릭 DNS** 열을 확인합니다. 이 열이 숨겨진 경우 **열 표시/숨기기** 아이콘(기어 모양 아이콘)을 선택하고 **퍼블릭 DNS**를 선택합니다. 인스턴스의 보안 그룹에 포트 80에서 HTTP 트래픽을 허용하는 규칙이 포함되어 있는지 확인합니다. 자세한 내용은 [보안 그룹 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) 섹션을 참조하세요. **중요** Amazon Linux을 사용하지 않는 경우, 이러한 연결을 허용하도록 인스턴스의 방화벽을 구성할 필요가 있습니다. 방화벽 구성 방법에 대한 자세한 내용은 사용자의 특정 배포에 대한 문서를 참조하세요. ![\[서버를 테스트하면 Apache 테스트 페이지가 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/images/apache_test_page_al2_2.4.png) Apache **httpd**는 Apache document root라는 디렉터리에 보관된 파일을 처리합니다. Amazon Linux Apache 문서 루트는 `/var/www/html`이며, 기본적으로 루트에서 소유합니다. `ec2-user` 계정에서 이 디렉터리의 파일을 조작할 수 있게 하려면 디렉터리의 소유권과 권한을 변경해야 합니다. 이 작업을 수행하는 방법에는 여러 가지가 있습니다. 본 자습서에서는 `ec2-user`를 `apache` 그룹에 추가하여 `apache` 그룹에 `/var/www` 디렉터리의 소유권을 부여하고 쓰기 권한을 할당합니다. **파일 권한 설정** 1. 사용자(이 경우는 `ec2-user`)를 `apache` 그룹에 추가합니다. ``` [ec2-user ~]$ sudo usermod -a -G apache ec2-user ``` 1. 로그아웃하고 다시 로그인한 다음, 새 그룹을 선택하고 멤버십을 확인합니다. 1. 로그아웃합니다(**exit** 명령을 사용하거나 터미널 창 닫기). ``` [ec2-user ~]$ exit ``` 1. `apache` 그룹의 멤버십을 확인하려면 인스턴스에 다시 연결한 후 다음 명령을 실행합니다. ``` [ec2-user ~]$ groups ec2-user adm wheel apache systemd-journal ``` 1. `/var/www` 및 그 콘텐츠의 그룹 소유권을 `apache` 그룹으로 변경합니다. ``` [ec2-user ~]$ sudo chown -R ec2-user:apache /var/www ``` 1. 그룹 쓰기 권한을 추가하여 나중에 하위 디렉터리에 대한 그룹 ID를 설정하려면 `/var/www`와 그 하위 디렉터리의 디렉터리 권한을 변경합니다. ``` [ec2-user ~]$ sudo chmod 2775 /var/www && find /var/www -type d -exec sudo chmod 2775 {} \; ``` 1. 그룹 쓰기 권한을 추가하려면 `/var/www` 및 그 하위 디렉터리의 파일 권한을 반복하여 변경합니다. ``` [ec2-user ~]$ find /var/www -type f -exec sudo chmod 0664 {} \; ``` 이제 `ec2-user`와 `apache` 그룹의 향후 멤버는 Apache document root에서 파일 추가, 삭제, 편집을 할 수 있고, 이를 통해 사용자는 정적 웹 사이트 또는 PHP 애플리케이션과 같은 콘텐츠를 추가할 수 있습니다. **웹 서버를 보호하려면(선택 사항)** HTTP 프로토콜을 실행하는 웹 서버는 송신하거나 수신하는 데이터에 대해 아무런 전송 보안 기능도 제공하지 않습니다. 웹 브라우저를 사용하여 HTTP 서버에 연결할 때 방문하는 URL, 수신하는 웹 페이지의 내용, 제출하는 HTML 양식의 내용(암호 포함)이 모두 네트워크 경로를 따라 어디서든 엿보려는 사람들에게 보입니다. 웹 서버를 안전하게 보호하기 위한 최선의 방법은 SSL/TLS 암호화로 데이터를 보호하는 HTTPS(HTTP Secure) 지원 기능을 설치하는 것입니다. 서버에서 HTTPS를 활성화하는 방법에 대한 자세한 내용은 [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md) 섹션을 참조하세요. ## 2단계: LAMP 서버 테스트 서버가 설치되어 실행 중이고 파일 권한이 올바르게 설정되었다면 사용자의 `ec2-user` 계정을 통해 인터넷에서 사용 가능한 `/var/www/html` 디렉터리에서 PHP 파일을 생성할 수 있어야 합니다. **LAMP 서버를 테스트하려면** 1. Apache 문서 루트에서 PHP 파일을 생성합니다. ``` [ec2-user ~]$ echo "" > /var/www/html/phpinfo.php ``` 이 명령을 실행하는 동안 "Permission denied" 오류가 발생하면, 로그아웃하고 다시 로그인한 다음, [파일 권한 설정](#setting-file-permissions-2)에서 구성한 적절한 그룹 권한을 선택합니다. 1. 웹 브라우저에서는 방금 생성한 파일의 URL을 입력합니다. 이 URL은 인스턴스의 퍼블릭 DNS 주소에 슬래시(/)와 파일 이름이 추가된 형태입니다. 다음 예를 참조하세요. ``` http://my.public.dns.amazonaws.com/phpinfo.php ``` PHP 정보 페이지가 표시되어야 합니다: ![\[LAMP 서버를 테스트하면 PHP 정보 페이지가 표시됩니다.\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/images/phpinfo7.2.10.png) 이 페이지가 보이지 않을 경우 이전 단계에서 `/var/www/html/phpinfo.php` 파일이 제대로 생성되었는지 확인하세요. 또한 다음 명령을 사용하여 필수 패키지가 모두 설치되었는지도 확인할 수 있습니다. ``` [ec2-user ~]$ sudo yum list installed httpd mariadb-server php-mysqlnd ``` 출력에서 필요한 패키지가 하나라도 나열되지 않으면, **sudo yum install *package*** 명령을 사용하여 패키지를 설치합니다. `php7.2` 및 `lamp-mariadb10.2-php7.2` extra가 **amazon-linux-extras** 명령의 출력에서 활성화되는지도 확인합니다. 1. `phpinfo.php` 파일을 삭제합니다. 이 파일은 유용한 정보를 포함하고 있지만 보안상 이유로 인터넷에 공개되어서는 안 됩니다. ``` [ec2-user ~]$ rm /var/www/html/phpinfo.php ``` 이제 LAMP 웹 서버가 완전히 동작하는 상태가 됩니다. `/var/www/html`의 Apache document root에 콘텐츠를 추가하면 인스턴스에 대한 퍼블릭 DNS 주소에서 그 콘텐츠를 볼 수 있습니다. ## 3단계: 데이터베이스 서버 보안 설정 MariaDB 서버의 기본 설치는 테스트 및 개발 기능에 유용한 여러 기능을 포함하고 있지만, 이 기능들은 프로덕션 서버에서는 비활성화되거나 제거되어야 합니다. **mysql\$1secure\$1installation** 명령을 통해 루트 암호를 설정하고 설치 패키지에서 보안성이 낮은 기능을 제거하는 과정을 수행할 수 있습니다. MariaDB 서버를 사용할 계획이 없더라도 이 절차를 수행하는 것이 좋습니다. **MariaDB 서버의 보안을 유지하려면** 1. MariaDB 서버를 시작합니다. ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. **mysql\$1secure\$1installation**를 실행합니다. ``` [ec2-user ~]$ sudo mysql_secure_installation ``` 1. 암호를 입력하라는 메시지가 표시되면 루트 계정의 암호를 입력합니다. 1. 현재 루트 암호를 입력합니다. 기본적으로 root 계정에는 암호가 없습니다. Enter를 누릅니다. 1. 암호를 설정하려면 **Y**를 누른 후 안전한 암호를 두 번 입력합니다. 보안 암호 생성에 대한 자세한 내용은 [https://identitysafe.norton.com/password-generator/](https://identitysafe.norton.com/password-generator/) 섹션을 참조하세요. 이 암호를 안전한 장소에 보관하시기 바랍니다. MariaDB에 대한 루트 암호를 설정하는 것은 데이터베이스를 보호하는 가장 기초적인 방법일 뿐입니다. 데이터베이스 기반 애플리케이션을 빌드하거나 설치할 때, 일반적으로 그 애플리케이션의 데이터베이스 서비스 사용자를 만들고 데이터베이스 관리 이외의 어떤 목적으로도 루트 계정을 사용하지 못하게 합니다. 1. **Y**를 눌러서 익명 사용자 계정을 제거합니다. 1. **Y**를 입력하여 원격 루트 로그인을 비활성화합니다. 1. **Y**를 눌러서 테스트 데이터베이스를 제거합니다. 1. **Y**를 눌러서 권한 테이블을 다시 로드하고 변경사항을 저장합니다. 1. (선택 사항) 지금 바로 사용할 계획이 아니라면 MariaDB 서버를 중지합니다. 필요할 때 다시 시작할 수 있습니다. ``` [ec2-user ~]$ sudo systemctl stop mariadb ``` 1. (선택 사항) 부팅 시 MariaDB 서버가 시작되도록 하려면 다음 명령을 입력합니다. ``` [ec2-user ~]$ sudo systemctl enable mariadb ``` ## 4단계: (선택 사항) phpMyAdmin 설치 [phpMyAdmin](https://www.phpmyadmin.net/)은 EC2 인스턴스의 MySQL 데이터베이스를 보고 편집하는 데 사용할 수 있는 웹 기반 데이터베이스 관리 도구입니다. Amazon Linux 인스턴스에서 `phpMyAdmin`을 설치 및 구성하려면 다음 단계를 따르세요. **중요** Apache에서 SSL/TLS를 활성화하지 않은 경우 `phpMyAdmin`을 사용하여 LAMP 서버에 액세스하지 않는 것이 좋습니다. 이 상태에서 액세스하면 데이터베이스 관리자 암호와 기타 데이터가 인터넷을 통해 안전하지 못한 상태로 전송됩니다. 개발자의 보안 권장 사항을 보려면 [phpMyAdmin 설치 보안](https://docs.phpmyadmin.net/en/latest/setup.html#securing-your-phpmyadmin-installation)을 참조하세요. EC2 인스턴스에서의 웹 서버 보안에 대한 일반적인 정보는 [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md) 섹션을 참조하세요. **phpMyAdmin을 설치하려면** 1. 필요한 종속 항목을 설치합니다. ``` [ec2-user ~]$ sudo yum install php-mbstring php-xml -y ``` 1. Apache를 다시 시작합니다. ``` [ec2-user ~]$ sudo systemctl restart httpd ``` 1. `php-fpm`을 다시 시작합니다. ``` [ec2-user ~]$ sudo systemctl restart php-fpm ``` 1. Apache 문서 루트(`/var/www/html`)로 이동합니다. ``` [ec2-user ~]$ cd /var/www/html ``` 1. [https://www.phpmyadmin.net/downloads](https://www.phpmyadmin.net/downloads)에서 phpMyAdmin 최신 릴리스의 소스 패키지를 선택합니다. 인스턴스로 파일을 직접 다운로드하려면 다음 예제와 같이 링크를 복사한 후 **wget** 명령에 붙여 넣습니다. ``` [ec2-user html]$ wget https://www.phpmyadmin.net/downloads/phpMyAdmin-latest-all-languages.tar.gz ``` 1. `phpMyAdmin` 폴더를 생성하고 다음 명령을 사용하여 해당 폴더로 패키지의 압축을 풉니다. ``` [ec2-user html]$ mkdir phpMyAdmin && tar -xvzf phpMyAdmin-latest-all-languages.tar.gz -C phpMyAdmin --strip-components 1 ``` 1. *phpMyAdmin-latest-all-languages.tar.gz* tarball을 삭제합니다. ``` [ec2-user html]$ rm phpMyAdmin-latest-all-languages.tar.gz ``` 1. (선택 사항) MySQL 서버가 실행 중이지 않으면 지금 시작합니다. ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. 웹 브라우저에서 phpMyAdmin 설치의 URL을 입력합니다. 아래의 예와 같이 이 URL은 인스턴스의 퍼블릭 DNS 주소(또는 퍼블릭 IP 주소)에 슬래시(/)와 설치 디렉터리의 이름이 추가된 형태입니다. 다음 예를 참조하세요. ``` http://my.public.dns.amazonaws.com/phpMyAdmin ``` 사용자는 phpMyAdmin 로그인 페이지를 볼 수 있어야 합니다: ![\[phpMyAdmin 설치의 URL을 입력하면 phpMyAdmin 로그인 화면이 나타납니다.\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/images/phpmyadmin_login.png) 1. 앞서 만든 `root` 사용자 이름 및 MySQL 루트 암호로 phpMyAdmin 설치에 로그인합니다. 작동하려면 먼저 설치를 구성해야 합니다. 먼저 다음과 같이 구성 파일을 수동으로 작성하는 것이 좋습니다. 1. 최소 구성 파일로 시작하려면 자주 사용하는 텍스트 편집기를 사용하여 새 파일을 생성한 후에 `config.sample.inc.php` 내용을 파일에 복사합니다. 1. 이 파일을 `config.inc.php`가 포함된 phpMyAdmin 디렉토리에 `index.php`로 저장하세요. 1. 추가 설정에 대해서는 phpMyAdmin 설치 지침에서 [설정 스크립트 사용](https://docs.phpmyadmin.net/en/latest/setup.html#using-the-setup-script) 섹션의 파일 생성 후 지침을 참조하세요. phpMyAdmin에 대한 자세한 내용은 [phpMyAdmin 사용 설명서](http://docs.phpmyadmin.net/en/latest/user.html)를 참조하세요. ## 문제 해결 이 섹션에서는 새 LAMP 서버를 설정하는 동안 발생할 수 있는 일반적인 문제 해결을 위한 제안을 제공합니다. ### 웹 브라우저를 사용하여 서버에 연결할 수 없음 다음을 확인하여 Apache 웹 서버가 실행 중이고 엑세스 가능한지 확인합니다. + **웹 서버가 실행되고 있습니까?** 다음 명령을 실행하여 **httpd**가 실행되고 있는지 확인할 수 있습니다. ``` [ec2-user ~]$ sudo systemctl is-enabled httpd ``` **httpd** 프로세스가 실행되지 않는 경우 [LAMP 서버를 준비하려면](#install_apache-2)에 설명된 단계를 반복합니다. + **방화벽이 올바르게 구성되었습니까?** 인스턴스의 보안 그룹에 포트 80에서 HTTP 트래픽을 허용하는 규칙이 포함되어 있는지 확인합니다. 자세한 내용은 [보안 그룹 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) 섹션을 참조하세요. ### HTTPS를 사용하여 서버에 연결할 수 없음 다음 확인을 수행하여 Apache 웹 서버가 HTTPS를 지원하도록 구성되어 있는지 확인합니다. + **웹 서버가 올바르게 구성되었습니까?** Apache를 설치한 후 서버는 HTTP 트래픽에 대해 구성됩니다. HTTPS를 지원하려면 서버에서 TLS를 활성화하고 SSL 인증서를 설치합니다. 자세한 정보는 [자습서: AL2에서 SSL/TLS 구성](SSL-on-amazon-linux-2.md) 섹션을 참조하세요. + **방화벽이 올바르게 구성되었습니까?** 인스턴스의 보안 그룹에 포트 443에서 HTTP 트래픽을 허용하는 규칙이 포함되어 있는지 확인합니다. 자세한 내용은 [보안 그룹에 규칙 추가를 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule). ## 관련 주제 파일을 인스턴스에 전송하거나 웹 서버에 WordPress 블로그를 설치하는 것에 대한 자세한 다용은 다음 문서를 참고하세요. + [를 사용하여 Linux 인스턴스로 파일을 전송합니다WinSCP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html#Transfer_WinSCP). + [SCP 클라이언트를 사용하여 Linux 인스턴스로 파일을 전송합니다](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html#linux-file-transfer-scp). + [자습서: AL2에서 WordPress 블로그 호스팅](hosting-wordpress.md) 이 자습서에서 사용되는 명령과 소프트웨어에 대한 자세한 내용은 다음 웹 페이지를 확인하세요. + Apache 웹 서버: [http://httpd.apache.org/](http://httpd.apache.org/) + MariaDB 데이터베이스 서버: [https://mariadb.org/](https://mariadb.org/) + PHP 프로그래밍 언어: [http://php.net/](http://php.net/) + `chmod` 명령: [https://en.wikipedia.org/wiki/Chmod](https://en.wikipedia.org/wiki/Chmod) + `chown` 명령: [https://en.wikipedia.org/wiki/Chown](https://en.wikipedia.org/wiki/Chown) 웹 서버에 대한 도메인 이름을 등록하거나 기존 도메인 이름을 현재 호스트로 이전하는 것에 대한 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [Amazon Route 53에서 도메인 및 하위 도메인 생성 및 마이그레이션](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/creating-migrating.html)을 참조하세요. # 자습서: AL2에서 SSL/TLS 구성 Secure Sockets Layer/Transport Layer Security(SSL/TLS)는 웹 서버와 웹 클라이언트 간 암호화된 채널을 만들어 전송 중인 데이터가 도청되지 않도록 보호합니다. 이 자습서에서는 AL2 및 Apache 웹 서버가 있는 EC2 인스턴스에서 SSL/TLS에 대한 지원을 수동으로 추가하는 방법을 설명합니다. 이 자습서에서는 로드 밸런서를 사용하고 있지 않다고 가정합니다. Elastic Load Balancing를 사용하는 경우 [AWS Certificate Manager](https://aws.amazon.com/certificate-manager/)의 인증서를 대신 사용하여 로드 밸런서에 SSL 오프로드를 구성하도록 선택할 수 있습니다. 일반적으로 웹 암호화를 단순히 SSL이라고 부릅니다. 웹 브라우저에서 여전히 SSL을 지원하지만, 후속 프로토콜인 TLS가 공격에 덜 취약합니다. AL2는 기본적으로 모든 버전의 SSL에 대한 서버 측 지원을 비활성화합니다. [보안 표준 본문](https://www.ssl.com/article/deprecating-early-tls/)에서는 TLS 1.0이 안전하지 않다고 간주합니다. TLS 1.0 및 TLS 1.1은 2021년 3월에 공식적으로 [사용 중단](https://datatracker.ietf.org/doc/rfc8996/)되었습니다. 이 자습서에서는 TLS 1.2 활성화만을 기반으로 하여 지침을 제공합니다. TLS 1.3은 2018년에 완료되었으며, 기본 TLS 라이브러리(이 자습서의 OpenSSL)가 지원 및 사용 설정되는 한 AL2에서 사용할 수 있습니다. [클라이언트는 2023년 6월 28일까지 TLS 1.2 이상을 지원해야 합니다](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/). 업데이트된 암호화 표준에 대한 자세한 내용은 [RFC 7568](https://tools.ietf.org/html/rfc7568) 및 [RFC 8446](https://tools.ietf.org/html/rfc8446)을 참조하세요. 이 자습서는 현대 웹 암호화를 단순히 TLS로 언급합니다. **중요** 이 절차는 AL2와 함께 사용하기 위한 것입니다. 또한 사용자가 새 Amazon EC2 인스턴스로 시작한다고 가정합니다. 다른 배포를 실행하는 EC2 인스턴스 또는 이전 버전의 AL2를 실행하는 인스턴스를 설정하려는 경우이 자습서의 일부 절차가 작동하지 않을 수 있습니다. Ubuntu의 경우 커뮤니티 설명서 [Ubuntu에서 SSL 열기](https://help.ubuntu.com/community/OpenSSL)를 참조하십시오. Red Hat Enterprise Linux의 경우 [Apache HTTP 웹 서버 설정](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/deploying_different_types_of_servers/setting-apache-http-server_deploying-different-types-of-servers)을 참조하세요. 다른 배포는 관련 설명서를 참조하세요. **참고** 또는 AWS Nitro Enclaves를 사용하여 Amazon EC2 인스턴스에서 실행되는 웹 애플리케이션 및 서버에 퍼블릭 및 프라이빗 SSL/TLS 인증서를 사용할 수 있는 엔클레이브 애플리케이션인 AWS Nitro 엔클레이브에 AWS Certificate Manager (ACM)을 사용할 수 있습니다. Nitro Enclaves는 격리된 컴퓨팅 환경을 생성하여 SSL/TLS 인증서 및 프라이빗 키와 같은 매우 민감한 데이터를 보호하고 안전하게 처리할 수 있도록 지원하는 Amazon EC2 기능입니다. Nitro Enclaves용 ACM은 Amazon EC2 Linux 인스턴스에서 실행되는 **nginx**와 함께 작동하여 프라이빗 키를 생성하고, 인증서와 프라이빗 키를 배포하며, 인증서 갱신을 관리합니다. Nitro Enclaves용 ACM을 사용하려면 엔클레이브 지원 Linux 인스턴스를 사용해야 합니다. 자세한 내용은 [AWS Nitro Enclaves란 무엇입니까?를 참조하세요](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave.html). [AWS Certificate Manager Nitro Enclaves 사용 설명서](https://docs.aws.amazon.com/enclaves/latest/user/nitro-enclave-refapp.html)*AWS 의 Nitro Enclaves*용 및 . **Topics** + [사전 조건](#ssl_prereq) + [1단계: 서버에서 TLS 활성화](#ssl_enable) + [2단계: CA가 서명한 인증서 가져오기](#ssl_certificate) + [3단계: 보안 구성 테스트 및 하드닝](#ssl_test) + [문제 해결](#troubleshooting) ## 사전 조건 이 자습서를 시작하기 전에 다음 단계를 완료합니다. + Amazon EBS 지원 AL2 인스턴스를 시작합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 시작](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-launch-instance-wizard.html)을 참조하세요. + 인스턴스가 다음 TCP 포트에서 연결을 허용하도록 보안 그룹을 구성합니다. + SSH(포트 22) + HTTP(포트 80) + HTTPS(포트 443) 자세한 내용은 *Amazon EC2 사용 설명서*의 [보안 그룹 규칙](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-rules.html)을 참조하세요. + Apache 웹 서버를 설치합니다. step-by-step[자습서: AL2에 LAMP 웹 서버 설치를 참조하세요](ec2-lamp-amazon-linux-2.md). httpd 패키지와 그 종속 프로그램만 필요합니다. PHP 및 MariaDB와 관련된 지침은 무시해도 됩니다. + 웹 사이트를 식별하고 인증하려면 TLS 퍼블릭 키 인프라(PKI)는 도메인 이름 시스템(DNS)을 사용합니다. EC2 인스턴스를 사용하여 퍼블릭 웹 사이트를 호스팅하려는 경우, 웹 서버의 도메인 이름을 등록하거나 Amazon EC2 호스트로 기존 도메인 이름을 전송해야 합니다. 수많은 타사 도메인 등록 및 DNS 호스팅 서비스를 이에 사용할 수 있습니다. 또는 [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html)을 사용할 수도 있습니다. ## 1단계: 서버에서 TLS 활성화 **옵션: 자동화를 사용하여 이 자습서 완료** 다음 작업 대신 AWS Systems Manager 자동화를 사용하여이 자습서를 완료하려면 [자동화 문서를](https://console.aws.amazon.com/systems-manager/documents/AWSDocs-Configure-SSL-TLS-AL2/) 실행합니다. 이 절차에서는 자체 서명된 디지털 인증서를 사용하여 AL2에서 TLS를 설정하는 프로세스를 안내합니다. **참고** 자체 서명된 인증서는 테스트에는 허용되지만 프로덕션에는 허용되지 않습니다. 자체 서명된 인증서를 인터넷에 노출하면 사이트 방문자에게 인사말로 보안 경고가 표시됩니다. **서버에서 TLS를 활성화하려면** 1. [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)한 다음 Apache가 실행되는지 확인합니다. ``` [ec2-user ~]$ sudo systemctl is-enabled httpd ``` 반환된 값이 "enabled"가 아닌 경우 Apache를 시작한 다음 시스템 부팅 시마다 시작하도록 설정합니다. ``` [ec2-user ~]$ sudo systemctl start httpd && sudo systemctl enable httpd ``` 1. 모든 소프트웨어 패키지가 최신 상태로 업데이트되어 있는지 확인하기 위해, 인스턴스에서 퀵 소프트웨어 업데이트를 실행합니다. 이 업데이트 과정은 몇 분 정도 시간이 소요될 수 있지만, 최신 보안 업데이트와 버그 수정을 위해 수행할 필요가 있습니다. **참고** `-y` 옵션을 사용하면 확인 여부를 묻지 않고 업데이트를 설치합니다. 설치 전에 업데이트 정보를 확인하려면 이 옵션을 생략합니다. ``` [ec2-user ~]$ sudo yum update -y ``` 1. 이제 인스턴스가 최신 상태이므로 다음과 같은 Apache module `mod_ssl`을 설치하여 TLS 지원을 추가합니다. ``` [ec2-user ~]$ sudo yum install -y mod_ssl ``` 이제 인스턴스에는 보안 서버 구성과 테스트를 위한 인증서 생성에 사용할 다음 파일이 포함됩니다. + `/etc/httpd/conf.d/ssl.conf` mod\$1ssl의 구성 파일입니다. 여기에는 Apache에 암호화 키 및 인증서의 위치, 허용하는 TLS 프로토콜 버전, 허용하는 암호화 암호를 알려주는 *명령*이 포함되어 있습니다. + `/etc/pki/tls/certs/make-dummy-cert` 서버 호스트에 대한 프라이빗 키와 자체 서명된 X.509 인증서 생성용 스크립트입니다. 이 인증서는 Apache가 TLS를 사용하도록 올바르게 설치되었는지 테스트하는 데 유용합니다. 제공하는 자격 증명이 없기 때문에 프로덕션에서 사용되어서는 안됩니다. 프로덕션 환경에서 사용되는 경우 웹 브라우저에서 경고를 트리거합니다. 1. 스크립트를 실행하여 자체 서명된 테스트용 더미 인증서와 키를 생성합니다. ``` [ec2-user ~]$ cd /etc/pki/tls/certs sudo ./make-dummy-cert localhost.crt ``` 그러면 새 파일인 `localhost.crt` 파일이 `/etc/pki/tls/certs/` 디렉터리에 생성됩니다. 지정된 파일의 이름은 `/etc/httpd/conf.d/ssl.conf`의 **SSLCertificateFile** 명령에 할당된 기본값과 일치합니다. 이 파일에는 자체 서명된 인증서와 인증서의 프라이빗 키가 모두 포함됩니다. Apache에서는 인증서와 키를 PEM 형식으로 요구합니다. 이 형식은 아래의 축약된 예제와 같이 "BEGIN" 및 "END" 라인으로 프레임 처리된 Base64 인코딩 ASCII 문자로 구성됩니다. ``` -----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q 3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT ... 56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs 27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo 4QQvAqOa8UheYeoXLdWcHaLP -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE----- ``` 파일 이름과 확장명은 편의상 사용되며 기능에 영향을 미치지 않습니다. 예를 들어 `ssl.conf` 파일에서 관련 명령에 동일한 이름을 사용하는 한, 인증서 이름을 `cert.crt`, `cert.pem` 또는 다른 파일 이름으로 지정할 수 있습니다. **참고** 기본 TLS 파일을 고유의 사용자 지정 파일로 대체하는 경우 파일이 PEM 형식인지 확인하세요. 1. 자체 서명된 더미 인증서에도 키가 포함되어 있으므로 자주 사용하는 텍스트 편집기(예: **vim** 또는 **nano**)를 루트 사용자로 사용하여 `/etc/httpd/conf.d/ssl.conf` 파일을 열고 다음 줄에 주석을 답니다. 다음 단계를 완료하기 전에 이 행을 주석으로 처리하지 않는 경우 Apache 서비스가 시작되지 않습니다. ``` SSLCertificateKeyFile /etc/pki/tls/private/localhost.key ``` 1. Apache를 다시 시작합니다. ``` [ec2-user ~]$ sudo systemctl restart httpd ``` **참고** 앞에서 설명한 대로 EC2 인스턴스에서 TCP 포트 443에 액세스할 수 있는지 확인하세요. 1. Apache 웹 서버가 현재 포트 443에 대해 HTTPS(보안 HTTP)를 지원해야 합니다. 접두사가 **https://**인 브라우저 URL 표시줄에 IP 주소 또는 EC2 인스턴스의 정규화된 도메인 이름을 입력하여 이를 테스트합니다. 신뢰할 수 없는 자체 서명된 호스트 인증서를 사용하여 사이트에 연결하기 때문에 브라우저에 보안 경고가 연속으로 표시될 수 있습니다. 경고를 무시하고 계속 진행합니다. Apache 기본 테스트 페이지가 열리면 서버에 TLS가 구성되었다는 것입니다. 브라우저와 서버 사이를 통과하는 모든 데이터가 이제 암호화됩니다. **참고** 사이트 방문자에게 경고 화면이 표시되는 것을 방지하려면 암호화뿐만 아니라 해당 사이트의 소유자라는 것을 공개적으로 인증하는 신뢰할 수 있는 CA 서명 인증서를 가져와야 합니다. ## 2단계: CA가 서명한 인증서 가져오기 CA가 서명한 인증서를 가져오려면 다음 절차를 사용할 수 있습니다. + 프라이빗 키에서 인증서 서명 요청(CSR)을 생성합니다. + 인증 기관(CA)에 CSR 제출 + 단일 호스트 인증서 가져오기 + Apache를 수성하여 인증서 사용 자체 서명된 TLS X.509 호스트 인증서는 CA가 서명한 인증서와 암호적으로 동일합니다. 그 차이는 수학적인 것이 아니라 사회적입니다. CA는 신청자에게 인증서를 발급하기 전에 도메인의 소유권을 최소한으로 검사합니다. 각 웹 브라우저에는 이를 하도록 브라우저 공급업체에서 신뢰한 CA 목록이 포함되어 있습니다. X.509 인증서는 프라이빗 서버 키에 해당하는 퍼블릭 키와 퍼블릭 키에 암호화 방식으로 연결된 CA의 서명으로 주로 구성되어 있습니다. 브라우저가 HTTPS를 통해 웹 서버에 연결되면 서버는 브라우저에서 신뢰할 수 있는 CA 목록을 확인하도록 인증서를 제공합니다. 서명자가 목록에 있거나 신뢰할 수 있는 다른 서명자로 구성되는 *신뢰 체인*을 통해 서명자에 액세스할 수 있는 경우, 브라우저는 서버와 암호화된 빠른 데이터 채널을 협상하고 페이지를 로드합니다. 요청 확인 절차로 인해 인증서에는 일반적으로 비용이 발생하므로 여러 인증 기관을 알아봐야 합니다. 일부 CA는 기본 수준 인증서를 무료로 제공합니다. 이러한 CA 중 가장 주목할 만한 것은 [Let's Encrypt](https://letsencrypt.org/) 프로젝트인데, 이것은 인증서 생성 및 갱신 프로세스의 자동화도 지원합니다. Let's Encrycrypt 인증서 사용에 대한 자세한 내용은 [Certbot 받기](https://eff-certbot.readthedocs.io/en/stable/install.html)를 참조하세요. 상업용 서비스를 제공할 계획이라면 [AWS Certificate Manager](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)가 좋은 옵션입니다. 호스트 인증서의 기본을 이루는 것은 키입니다. 2019년 현재 [정부](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf) 및 [산업](https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.5.pdf) 그룹에서는 2030년까지 문서를 보호하기 위해 마련된 RSA 키에 대해 최소 2048비트의 키(모듈러스) 크기를 사용할 것을 권장합니다. AL2에서 OpenSSL에 의해 생성된 기본 모듈러스 크기는 2048비트이며 CA 서명 인증서에 사용하기에 적합합니다. 다음 절차는 사용자 지정된 키(예: 더 큰 모듈러스 또는 다른 암호화 알고리즘 사용)를 원하는 사용자를 위해 제공되는 선택적 단계입니다. **중요** 이 CA 서명 호스트 인증서 획득 지침은 등록과 호스팅이 완료된 DNS 도메인을 소유하지 않을 경우 제대로 적용하기 어렵습니다. **CA가 서명한 인증서를 가져오려면** 1. [인스턴스에 연결](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-to-linux-instance.html)한 다음 /etc/pki/tls/private/으로 이동합니다. 여기는 TLS에 대한 서버의 프라이빗 키를 저장하는 디렉터리입니다. 기존 호스트 키를 사용하여 CSR을 생성하려면 3단계로 건너뜁니다. 1. (선택 사항) 새 프라이빗 키를 생성합니다. 다음은 몇 가지 키 구성 샘플입니다. 어떤 결과 키도 웹 서버에서 사용할 수 있지만 보안 구현의 정도와 유형은 각각 다릅니다. + **예 1:** 기본 RSA 호스트 키를 만듭니다. 결과 파일인 **custom.key**는 2048비트 RSA 프라이빗 키입니다. ``` [ec2-user ~]$ sudo openssl genrsa -out custom.key ``` + **예 2:** 더 큰 모듈러스로 더 강력한 RSA 키를 만듭니다. 결과 파일인 **custom.key**는 4096비트 RSA 프라이빗 키입니다. ``` [ec2-user ~]$ sudo openssl genrsa -out custom.key 4096 ``` + **예 3:** 암호로 보호되는 4096비트 암호화 RSA 키를 생성합니다. 그러면 AES-128 암호화로 암호화된 4096비트 RSA 프라이빗 키인 **custom.key** 파일이 생성됩니다. **중요** 키 암호화를 통해 보안을 강화할 수 있지만, 암호화된 키에는 암호가 필요하기 때문에 이를 사용하는 서비스는 자동으로 시작할 수 없습니다. 이 키를 사용할 때마다 SSH 연결을 통해 암호(위의 예에서는 "abcde12345")를 제공해야 합니다. ``` [ec2-user ~]$ sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096 ``` + **예 4:** 비 RSA 암호를 사용하여 키를 생성합니다. RSA 암호화는 두 개의 라지 소수의 결과를 기반으로 하는 공개 키의 크기 때문에 상대적으로 느릴 수 있습니다. 그러나 RSA 암호화 이외의 암호화를 사용하는 TLS의 키를 생성할 수 있습니다. 타원 곡선 수학을 기반으로 하는 키는 동등한 보안 수준을 제공할 때보다 작고 산술적으로 빠릅니다. ``` [ec2-user ~]$ sudo openssl ecparam -name prime256v1 -out custom.key -genkey ``` 그 결과는 OpenSSL에서 지원하는 "명명된 곡선"인 prime256v1을 사용하는 256비트 타원 곡선 프라이빗 키입니다. [NIST](http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf)에 따르면 이 키의 암호화 강도는 2048비트 RSA 키보다 약간 더 높습니다. **참고** 모든 CA에서 타원 곡선 기반 키에 대해 RSA 키와 동등한 수준의 지원을 제공하지는 않습니다. 새 프라이빗 키의 소유권 및 권한은 매우 제한적(소유자=루트, 그룹=루트, 소유자 전용 읽기/쓰기)이어야 합니다. 명령은 다음 예에서와 같습니다. ``` [ec2-user ~]$ sudo chown root:root custom.key [ec2-user ~]$ sudo chmod 600 custom.key [ec2-user ~]$ ls -al custom.key ``` 이 명령의 결과는 다음과 같아야 합니다. ``` -rw------- root root custom.key ``` 만족스러운 키를 생성 및 구성한 후 CSR을 생성할 수 있습니다. 1. 원하는 키를 사용하여 CSR을 생성합니다. 다음 예에는 **custom.key**가 사용됩니다. ``` [ec2-user ~]$ sudo openssl req -new -key custom.key -out csr.pem ``` OpenSSL은 대화 상자를 열고 아래 표의 정보를 입력하라는 메시지를 표시합니다. 도메인에서 확인된 기본 호스트 인증서의 경우 **Common Name**을 제외한 모든 필드는 선택 사항입니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/linux/al2/ug/SSL-on-amazon-linux-2.html) 마지막으로 OpenSSL은 챌린지 암호(선택 사항)를 입력하라는 메시지를 표시합니다. 이 암호는 해당 CSR 및 사용자와 해당 CA 간의 트랜잭션에만 적용되므로, 암호 및 기타 선택적 필드(선택적 회사 이름)에 대한 해당 CA의 권장 사항을 따릅니다. CSR 챌린지 암호는 서버 작업에 영향을 미치지 않습니다. 결과 파일인 **csr.pem**에는 퍼블릭 키, 퍼블릭 키의 디지털 서명 및 입력한 메타데이터가 포함되어 있습니다. 1. CA에 CSR을 제출합니다. 이는 보통 텍스트 편집기에서 CSR 파일을 열고 웹 양식에 내용을 복사하는 것으로 구성됩니다. 이때 인증서에 추가할 하나 이상의 주체 대체 이름(SAN)을 입력하라는 메시지가 나타날 수 있습니다. **www.example.com**이 일반 이름일 경우, **example.com**은 좋은 SAN이며, 그 반대의 경우도 마찬가지입니다. 사이트 방문자는 이 이름 중 하나를 입력하면 오류 없이 연결됩니다. CA 웹 양식에서 이를 허용하는 경우, SAN 목록에 일반 이름을 포함시킵니다. 일부 CA는 이를 자동으로 포함시킵니다. 요청이 승인되면 CA에서 서명한 새 호스트 인증서를 받게 됩니다. CA의 신뢰 체인을 완료하는 데 필요한 추가 인증서가 포함된 *중간 인증서* 파일을 다운로드하라는 안내를 받을 수도 있습니다. **참고** CA는 다양한 목적을 위해 마련된 여러 형식의 파일을 보낼 수 있습니다. 본 자습서에서는 PEM 형식의 인증서 파일만 사용해야 하는데, 이는 보통 `.pem` 또는 `.crt` 파일 확장명으로 표시되지만 항상 그런 것은 아닙니다. 어떤 파일을 사용할지 확실하지 않은 경우 텍스트 편집기로 파일을 열고 다음 라인으로 시작되는 블록 하나 이상이 포함되는 파일을 찾습니다. ``` - - - - -BEGIN CERTIFICATE - - - - - ``` 또한 파일은 다음 라인으로 끝나야 합니다. ``` - - - -END CERTIFICATE - - - - - ``` 또한 명령줄의 파일을 다음과 같이 테스트할 수 있습니다. ``` [ec2-user certs]$ openssl x509 -in certificate.crt -text ``` 이 줄이 파일에 나타나는지 확인하세요. `.p7b`, `.p7c`, 또는 유사한 파일 확장명으로 끝나는 파일을 사용하지 않습니다. 1. `/etc/pki/tls/certs` 디렉터리에 CA가 서명한 새 인증서와 모든 중간 인증서를 배치합니다. **참고** 여러 가지 방법으로 새 인증서를 EC2 인스턴스에 업로드할 수 있지만, 가장 간편하고 유익한 방법은 텍스트 편집기(예: vi, nano, 메모장)를 로컬 컴퓨터와 인스턴스에 모두 열고 두 편집기 간에 파일 콘텐츠를 복사하여 붙이는 것입니다. EC2 인스턴스에서 이러한 작업을 수행할 때 루트 [sudo] 권한이 필요합니다. 이렇게 하면 권한 또는 경로 문제가 있는 경우 즉시 확인할 수 있습니다. 하지만 콘텐츠를 복사하는 동안 라인을 추가하거나 어떤 식으로든 콘텐츠를 변경하지 않도록 주의하세요. `/etc/pki/tls/certs` 디렉터리 내부에서 파일 소유권, 그룹 및 권한 설정이 매우 제한적인 AL2 기본값(owner=root, group=root, 소유자 전용 읽기/쓰기)과 일치하는지 확인합니다. 다음 예제는 사용하는 명령을 보여 줍니다. ``` [ec2-user certs]$ sudo chown root:root custom.crt [ec2-user certs]$ sudo chmod 600 custom.crt [ec2-user certs]$ ls -al custom.crt ``` 이 명령의 결과는 다음과 같아야 합니다. ``` -rw------- root root custom.crt ``` 중간 인증서 파일에 대한 권한은 덜 엄격합니다(소유자=루트, 그룹=루트, 소유자 쓰기 가능, 그룹 읽기 가능, 모든 사용자 읽기 가능). 다음 예제는 사용하는 명령을 보여 줍니다. ``` [ec2-user certs]$ sudo chown root:root intermediate.crt [ec2-user certs]$ sudo chmod 644 intermediate.crt [ec2-user certs]$ ls -al intermediate.crt ``` 이 명령의 결과는 다음과 같아야 합니다. ``` -rw-r--r-- root root intermediate.crt ``` 1. `/etc/pki/tls/private/` 디렉터리에서 CSR을 생성할 때 사용한 프라이빗 키를 배치합니다. **참고** 여러 가지 방법으로 사용자 지정 키를 EC2 인스턴스에 업로드할 수 있지만, 가장 간편하고 유익한 방법은 텍스트 편집기(예: vi, nano, 메모장)를 로컬 컴퓨터와 인스턴스에 모두 열고 두 편집기 간에 파일 콘텐츠를 복사하여 붙이는 것입니다. EC2 인스턴스에서 이러한 작업을 수행할 때 루트 [sudo] 권한이 필요합니다. 이렇게 하면 권한 또는 경로 문제가 있는 경우 즉시 확인할 수 있습니다. 하지만 콘텐츠를 복사하는 동안 라인을 추가하거나 어떤 식으로든 콘텐츠를 변경하지 않도록 주의하세요. `/etc/pki/tls/private` 디렉터리 내부에서 다음 명령을 사용하여 파일 소유권, 그룹 및 권한 설정이 매우 제한적인 AL2 기본값(소유자=루트, 그룹=루트, 소유자 전용 읽기/쓰기)과 일치하는지 확인합니다. ``` [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ ls -al custom.key ``` 이 명령의 결과는 다음과 같아야 합니다. ``` -rw------- root root custom.key ``` 1. 새 인증서 및 키 파일을 반영하기 위해 `/etc/httpd/conf.d/ssl.conf`를 편집합니다. 1. Apache의 `SSLCertificateFile` 명령에 CA가 서명한 호스트 인증서의 경로와 파일 이름을 입력합니다. ``` SSLCertificateFile /etc/pki/tls/certs/custom.crt ``` 1. 중간 인증서 파일을 받은 경우(이 예에서는 `intermediate.crt`), Apache의 `SSLCACertificateFile` 명령을 사용하여 경로 및 파일 이름을 입력합니다. ``` SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt ``` **참고** 일부 CA는 호스트 인증서와 중간 인증서를 단일 파일로 결합하기 때문에 `SSLCACertificateFile` 명령이 불필요합니다. CA가 제공한 지침을 참조하세요. 1. Apache의 `SSLCertificateKeyFile` 명령에 프라이빗 키(이 예에서는 `custom.key`)의 경로와 파일 이름을 입력합니다. ``` SSLCertificateKeyFile /etc/pki/tls/private/custom.key ``` 1. `/etc/httpd/conf.d/ssl.conf`를 저장하고 Apache를 다시 시작합니다. ``` [ec2-user ~]$ sudo systemctl restart httpd ``` 1. `https://` 접두사가 포함된 브라우저 URL 막대에 도메인 이름을 입력하여 서버를 테스트합니다. 브라우저에서는 테스트 페이지가 오류 생성 없이 HTTPS를 통해 로드되어야 합니다. ## 3단계: 보안 구성 테스트 및 하드닝 TLS이 작동되고 일반에 공개된 후 이의 실제 보안 수준을 테스트해야 합니다. 보안 설정을 무료로 완벽하게 분석해 주는 [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html)와 같은 온라인 서비스를 사용하면 이를 손쉽게 수행할 수 있습니다. 그 결과에 따라 수용할 프로토콜, 원하는 암호 및 제외할 암호를 관리하여 기본 보안 구성을 하드닝할 수 있습니다. 자세한 내용은 [how Qualys formulates its scores](https://github.com/ssllabs/research/wiki/SSL-Server-Rating-Guide) 섹션을 참조하세요. **중요** 실제 테스트는 서버 보안에 매우 중요합니다. 구성상의 작은 오류가 심각한 보안 침해 및 데이터 손실로 이어질 수 있습니다. 권장되는 보안 사례는 연구 및 새롭게 생겨나는 위협에 대처하기 위해 끊임없이 변화하므로 보안 감사를 주기적으로 실시하는 것이 서버 관리에 필수적입니다. [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html) 사이트에 **www.example.com** 형식으로 서버의 정규화된 도메인 이름을 입력합니다. 약 2분 후 사이트 등급(A - F) 및 확인된 상세 분석 결과를 받게 됩니다. 다음 표에는 AL2의 기본 Apache 구성과 동일한 설정과 기본 Certbot 인증서가 있는 도메인에 대한 보고서가 요약되어 있습니다. | | | | --- |--- | | 종합 등급 | B | | 인증서 | 100% | | 프로토콜 지원 | 95% | | 키 교환 | 70% | | 암호화 수준 | 90% | 개요에서 구성이 대체로 문제가 없어 보여도 세부 정보 보고서에서는 몇몇 잠재적 문제를 여기에 심각도 순서로 나열하여 표시합니다. ✗ **RC4 암호는 이전 버전의 특정 브라우저에서 사용하도록 지원됩니다.** 암호는 암호화 알고리즘의 수학적 핵심입니다. TLS 데이터 스트림을 암호화하는 데 사용하는 빠른 암호인 RC4에는 몇 가지 [심각한 취약점](http://www.imperva.com/docs/hii_attacking_ssl_when_using_rc4.pdf)이 있는 것으로 알려져 있습니다. 타당한 레거시 브라우저 지원 사유가 없다면 비활성화해야 합니다. ✗ **이전 TLS 버전이 지원됩니다.** 구성에서는 TLS 1.0(이미 사용 중지 상태)과 TLS 1.1(사용 중지 절차 진행 중)을 지원합니다. 2018년부터는 TLS 1.2만 권장됩니다. ✗ **전방향 보안은 부분적으로 지원됩니다.** [전방향 보안](https://en.wikipedia.org/wiki/Forward_secrecy)은 프라이빗 키에서 파생된 임시(사용 후 삭제) 세션 키를 사용하여 암호화하는 알고리즘의 기능입니다. 이는 실제 공격자가 웹 서버의 장기 프라이빗 키를 보유하고 있더라도 HTTPS 데이터의 암호를 해독할 수 없다는 것을 뜻합니다. **TLS 구성을 수정하고 향후에 대비하려면** 1. 텍스트 편집기에서 `/etc/httpd/conf.d/ssl.conf` 구성 파일을 열고 다음 줄의 시작 부분에 "\$1"을 입력하여 해당 줄을 주석으로 처리합니다. ``` #SSLProtocol all -SSLv3 ``` 1. 다음 명령을 추가합니다. ``` #SSLProtocol all -SSLv3 SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 ``` 이러한 명령은 SSL 버전 2 및 3과 TLS 버전 1.0 및 1.1을 명시적으로 비활성화합니다. 이제 이 서버는 TLS 1.2 이외의 프로토콜을 사용하는 클라이언트와의 암호화된 연결을 허용하지 않습니다. 명령의 상세 내용은 서버의 구성 내용을 사람에게 더욱 명확히 전달합니다. **참고** 이러한 방식으로 TLS 버전 1.0 및 1.1을 비활성화하면 적은 비율의 오래된 웹 브라우저가 사이트에 액세스하지 못하도록 차단합니다. **허용된 암호의 목록을 수정하려면** 1. 구성 파일인 `/etc/httpd/conf.d/ssl.conf`에서 **SSLCipherSuite** 명령이 포함된 섹션을 찾고 기존의 줄을 줄의 시작에 “\$1”을 입력하여 주석으로 처리합니다. ``` #SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5 ``` 1. 명시적 암호 그룹과 전방향 보안을 우선순위에 두고 부정확한 암호를 방지하는 암호 오더를 지정합니다. 여기에 사용된 `SSLCipherSuite` 명령은 서버에서 실행되는 특정 소프트웨어에 맞게 TLS 구성을 조정하는 [Mozilla SSL Configuration Generator](https://mozilla.github.io/server-side-tls/ssl-config-generator/)의 출력에 기반합니다. 먼저 다음 명령의 출력을 사용하여 Apache와 OpenSSL의 버전을 확인합니다. ``` [ec2-user ~]$ yum list installed | grep httpd [ec2-user ~]$ yum list installed | grep openssl ``` 예를 들어, 반환된 정보가 Apache 2.4.34 및 OpenSSL 1.0.2인 경우 이를 생성기에 입력합니다. "현대" 호환성 모델을 선택하면 적극적으로 보안을 적용하지만 대부분의 브라우저에서 여전히 작동하는 `SSLCipherSuite` 명령을 생성합니다. 소프트웨어가 최신 구성을 지원하지 않으면 소프트웨어를 업데이트하거나 대신 "중간" 구성을 선택할 수 있습니다. ``` SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 ``` 선택된 암호에는 이름에 *Elliptic Curve Diffie-Hellman Ephemeral*의 약자인 *ECDHE*가 포함되어 있습니다. *ephemeral*은 전방향 보안을 나타냅니다. 부차적 결과로서 해당 암호는 RC4를 지원하지 않습니다. 내용이 표시되지 않는 기본값 또는 terse 명령 대신 명시적 암호 목록을 사용하는 것이 좋습니다. 생성된 명령을 `/etc/httpd/conf.d/ssl.conf`에 복사합니다. **참고** 여기에서는 가독성을 위해 여러 줄로 표시했지만, 이 명령은 `/etc/httpd/conf.d/ssl.conf`에 복사할 때 암호 이름 사이에 공백 없이 콜론만을 추가하여 한 줄에 입력해야 합니다. 1. 마지막으로 줄 시작 부분에 있는 "\$1"을 제거하여 다음 줄의 주석 처리를 해제합니다. ``` #SSLHonorCipherOrder on ``` 이 명령은 (이 예에서는) 전방향 보안을 지원하는 암호를 포함하여 서버에서 순위가 높은 암호를 선호하도록 합니다. 이 명령이 설정되면 서버는 먼저 강력한 보안 연결 설정을 시도해 본 후 보안이 더 약한 허용된 암호로 대체합니다. 이 두 절차를 모두 완료한 다음에는 변경 사항을 `/etc/httpd/conf.d/ssl.conf`에 저장하고 Apache를 재시작합니다. [Qualys SSL Labs](https://www.ssllabs.com/ssltest/analyze.html)에서 도메인을 다시 테스트하면 RC4 취약성과 다른 경고 문제가 해결되고 요약은 다음과 같을 것입니다. | | | | --- |--- | | 종합 등급 | A | | 인증서 | 100% | | 프로토콜 지원 | 100% | | 키 교환 | 90% | | 암호화 수준 | 90% | OpenSSL을 업데이트할 때마다 새 암호가 사용되고 이전 암호에 대한 지원은 제거됩니다. EC2 AL2 인스턴스를 up-to-date 유지하고, [OpenSSL](https://www.openssl.org/)의 보안 공지를 주시하고, 기술 보도에서 새로운 보안 악용에 대한 보고를 주의 깊게 확인하세요. ## 문제 해결 + **암호를 입력하지 않으면 Apache 웹 서버가 시작되지 않음** 암호화되고 암호로 보호되는 프라이빗 서버 키를 설치한 경우 이는 예상된 동작입니다. 키에서 암호화 및 암호 요구 사항을 제거할 수 있습니다. 기본 디렉터리에 `custom.key`라는 암호화된 프라이빗 RSA 키가 있고 이 키의 암호가 **abcde12345**라고 가정하면, EC2 인스턴스에서 다음 명령을 실행하여 이 키의 암호화되지 않은 버전을 생성합니다. ``` [ec2-user ~]$ cd /etc/pki/tls/private/ [ec2-user private]$ sudo cp custom.key custom.key.bak [ec2-user private]$ sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt [ec2-user private]$ sudo mv custom.key.nocrypt custom.key [ec2-user private]$ sudo chown root:root custom.key [ec2-user private]$ sudo chmod 600 custom.key [ec2-user private]$ sudo systemctl restart httpd ``` 이제 Apache가 암호를 묻지 않고 시작할 것입니다. + **sudo yum install -y mod\$1ssl을 실행할 때 오류가 발생합니다.** SSL에 필요한 패키지를 설치하려 할 때 다음과 같은 오류가 표시될 수 있습니다. ``` Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64 ``` 이는 일반적으로 EC2 인스턴스가 AL2를 실행하고 있지 않음을 의미합니다. 이 자습서에서는 공식 AL2 AMI에서 새로 생성된 인스턴스만 지원합니다. # 자습서: AL2에서 WordPress 블로그 호스팅 다음 절차는 AL2 인스턴스에 WordPress 블로그를 설치, 구성 및 보호하는 데 도움이 됩니다. 본 자습서는 기존 호스팅 서비스에서는 일반적이지 않은 WordPress 블로그를 호스팅하는 웹 서버를 사용자가 완전히 제어할 수 있다는 점에서 Amazon EC2 사용에 있어 좋은 입문 기회를 제공합니다. 사용자는 서버에 대한 소프트웨어 패키지를 업데이트하고 보안 패치를 유지관리할 책임이 있습니다. 웹 서버 구성과 직접 상호 작용할 필요가 없는 보다 자동화된 WordPress 설치를 위해 CloudFormation 서비스는 빠르게 시작할 수 있는 WordPress 템플릿을 제공합니다. 자세한 내용은 *AWS CloudFormation 사용 설명서*에서 [시작하기](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.Walkthrough.html)를 참조하세요. 데이터베이스가 분리된 고가용성 솔루션이 필요하다면 *AWS Elastic Beanstalk 개발자 안내서*에서 [고가용성 WordPress 웹 사이트 배포](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/php-hawordpress-tutorial.html)를 참조하세요. **중요** 이 절차는 AL2와 함께 사용하기 위한 것입니다. 기타 배포에 대한 자세한 내용은 해당 설명서를 참조하세요. 본 자습서에 있는 단계의 상당수가 Ubuntu 인스턴스에서 작동하지 않습니다. Ubuntu 인스턴스에 WordPress를 설치하는 방법은 Ubuntu 설명서에서 [WordPress](https://help.ubuntu.com/community/WordPress) 섹션을 참조하세요. [CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorials-wordpress-launch-instance.html)를 사용하여 Amazon Linux, macOS 또는 Unix 시스템에서 태스크를 수행할 수도 있습니다. **Topics** + [사전 조건](#hosting-wordpress-prereqs) + [WordPress 설치](#install-wordpress) + [다음 단계](#wordpress-next-steps) + [도움말\$1 내 퍼블릭 DNS 이름이 변경되어 블로그를 사용할 수 없습니다.](#wordpress-troubleshooting) ## 사전 조건 이 자습서에서는의 모든 단계에 따라 PHP 및 데이터베이스(MySQL 또는 MariaDB)가 지원되는 기능 웹 서버를 사용하여 AL2 인스턴스를 시작했다고 가정합니다[자습서: AL2에 LAMP 서버 설치](ec2-lamp-amazon-linux-2.md). 또한 본 자습서는 보안 그룹이 `HTTP` 및 `HTTPS` 트래픽을 허용하도록 구성하는 단계와 파일 권한이 웹 서버에 맞게 적절하게 설정되어 있는지 확인하는 여러 단계를 포함하고 있습니다. 보안 그룹 규칙 추가에 대한 자세한 내용은 [보안 그룹에 규칙 추가](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#adding-security-group-rule) 섹션을 참조하세요. 탄력적 IP 주소(EIP)는 WordPress 블로그를 호스팅하는 데 사용 중인 인스턴스와 연결하는 것이 가장 바람직합니다. 인스턴스의 퍼블릭 DNS 주소가 설치 위치를 바꾸거나 위반하는 것을 방지할 수 있기 때문입니다. 자신이 소유하고 있는 도메인 이름을 블로그에 사용하고 싶다면 도메인 이름의 DNS 레코드가 EIP 주소를 가리키도록 업데이트할 수 있습니다(이와 관련하여 도움이 필요하다면 도메인 이름 등록 기관에게 문의하세요). 실행 중인 인스턴스와 연결되어 있는 EIP 주소는 한 개까지 무료로 사용할 수 있습니다. 자세한 내용은 *Amazon EC2 사용 설명서*에서 [탄력적 IP 주소](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)를 참조하세요. 블로그에 사용할 도메인 이름이 아직 없는 경우 Route 53에 도메인 이름을 등록하고 인스턴스의 EIP 주소를 도메인 이름에 연결할 수 있습니다. 자세한 내용은 *Amazon Route 53 개발자 안내서*의 [Amazon Route 53을 사용하여 도메인 이름 등록](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/registrar.html)을 참조하세요. ## WordPress 설치 **옵션: 자동화를 사용하여 이 자습서 완료** 다음 작업 대신 AWS Systems Manager 자동화를 사용하여이 자습서를 완료하려면 [자동화 문서를](https://console.aws.amazon.com/systems-manager/documents/AWSDocs-HostingAWordPressBlog/) 실행합니다. 인스턴스에 연결한 후 WordPress 설치 패키지를 다운로드합니다. **WordPress 설치 패키지의 다운로드 및 압축해제 방법** 1. **wget** 명령을 사용하여 최신 WordPress 설치 패키지를 다운로드 합니다. 다음 명령을 사용할 경우 언제나 최신 릴리스를 다운로드합니다. ``` [ec2-user ~]$ wget https://wordpress.org/latest.tar.gz ``` 1. 설치 패키지의 압축 및 아카이빙을 해제합니다. 설치 폴더는 `wordpress`라는 폴더로 압축 해제됩니다. ``` [ec2-user ~]$ tar -xzf latest.tar.gz ``` **WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면** WordPress 설치 시 블로그 게시물, 사용자 의견 등의 정보를 데이터베이스에 저장해야 합니다. 다음 절차를 통해 블로그의 데이터베이스와 이 데이터베이스에 대해 정보 읽기 및 저장 권한이 있는 사용자를 생성할 수 있습니다. 1. 데이터베이스 서버를 시작합니다. + ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. 데이터베이스 서버에 `root` 사용자로 로그인합니다. 메시지가 표시되면 데이터베이스 `root` 암호를 입력합니다. 이 암호는 사용자의 `root` 시스템 암호와 다를 수 있으며, 데이터베이스 서버를 보안 설정하지 않은 경우 암호가 비어 있을 수도 있습니다. 데이터베이스 서버를 보안 설정하지 않았다면 반드시 설정하시기 바랍니다. 자세한 내용은 [MariaDB 서버의 보안을 유지하려면](ec2-lamp-amazon-linux-2.md#securing-maria-db) (AL2)를 참조하세요. ``` [ec2-user ~]$ mysql -u root -p ``` 1. MySQL 데이터베이스에 대한 사용자 및 암호를 생성합니다. WordPress 설치는 MySQL 데이터베이스를 통신하기 위해 상기 값을 사용합니다. 사용자에 대해 보안이 강력한 암호를 생성하시기 바랍니다. 작은따옴표(')는 각 명령을 구별하는 구분자로 기능하기 때문에, 암호에는 사용하지 마세요. 기존 암호를 재사용하지 마세요. 새로 설정한 암호는 안전한 장소에 보관하세요. 고유한 사용자 이름과 암호로 해당 부분을 대체하여 다음 명령을 입력합니다. ``` CREATE USER 'wordpress-user'@'localhost' IDENTIFIED BY 'your_strong_password'; ``` 1. 데이터베이스를 생성합니다. 데이터베이스에 이를 설명할 수 있는 유의미한 이름을 붙입니다(예: `wordpress-db`.). **참고** 아래 명령에서 데이터베이스 이름을 앞 뒤로 묶는 기호(`)를 백틱(backtick)이라고 합니다. 백틱(```) 키는 일반적으로 표준 키보드에서 `Tab` 키 위에 있습니다. 백틱이 항상 필요하지는 않지만, 이를 통해 데이터베이스 이름에 하이픈(-) 등 허용되지 않는 문자를 사용할 수 있습니다. ``` CREATE DATABASE `wordpress-db`; ``` 1. 데이터베이스에 대한 전체 권한을 이전에 생성한 WordPress 사용자에게 부여합니다. ``` GRANT ALL PRIVILEGES ON `wordpress-db`.* TO "wordpress-user"@"localhost"; ``` 1. 데이터베이스 권한을 새로고침(flush)해서 모든 변경사항이 적용되도록 합니다. ``` FLUSH PRIVILEGES; ``` 1. `mysql` 클라이언트를 종료합니다. ``` exit ``` **wp-config.php 파일 생성 및 편집 방법** WordPress 설치 폴더는 `wp-config-sample.php`라는 샘플 구성 파일을 포함하고 있습니다. 본 절차에서는 이 파일을 복사하고 특정 구성에 맞도록 편집합니다. 1. `wp-config-sample.php` 파일을 `wp-config.php`라는 파일에 복사합니다. 이를 통해 새 구성 파일을 생성하고 원본 샘플 파일을 이전 상태 그대로 백업으로 보존할 수 있습니다. ``` [ec2-user ~]$ cp wordpress/wp-config-sample.php wordpress/wp-config.php ``` 1. `wp-config.php` 파일을 원하는 텍스트 편집기(**nano**, **vim** 등)로 편집하고 설치에 대한 값을 입력합니다. 원하는 텍스트 편집기가 없는 경우 초보자에게는 `nano`가 적합합니다. ``` [ec2-user ~]$ nano wordpress/wp-config.php ``` 1. `DB_NAME`을(를) 정의하는 줄을 찾고 `database_name_here`을(를) [Step 4](#create_database)의 [WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면](#create_user_and_database)에서 생성한 데이터베이스 이름으로 변경합니다. ``` define('DB_NAME', 'wordpress-db'); ``` 1. `DB_USER`을(를) 정의하는 줄을 찾고 `username_here`을(를) [Step 3](#create_database_user)의 [WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면](#create_user_and_database)에서 생성한 데이터베이스 사용자로 변경합니다. ``` define('DB_USER', 'wordpress-user'); ``` 1. `DB_PASSWORD`을(를) 정의하는 줄을 찾고 `password_here`을(를) [Step 3](#create_database_user)의 [WordPress 설치에 대한 데이터베이스 사용자 및 데이터베이스를 생성하려면](#create_user_and_database)에서 생성한 보안성이 강력한 암호로 변경합니다. ``` define('DB_PASSWORD', 'your_strong_password'); ``` 1. `Authentication Unique Keys and Salts`라는 섹션을 검색합니다. 이 `KEY` 및 `SALT` 값은 WordPress 사용자가 로컬 컴퓨터에 저장하는 브라우저 쿠키에 암호 계층을 제공합니다. 기본적으로 긴 무작위 값을 추가해서 사이트의 보안성을 강화할 수 있습니다. [https://api.wordpress.org/secret-key/1.1/salt/](https://api.wordpress.org/secret-key/1.1/salt/)을 방문해서 키 값의 세트를 무작위로 생성하고 이를 `wp-config.php` 파일로 복사해서 붙여 넣을 수 있습니다. PuTTY 터미널로 텍스트를 붙여넣기 하기 위해, PuTTY 터미널 내부에서 텍스트를 붙여넣기하려는 위치에 커서를 놓고 마우스를 오른쪽 클릭합니다. 보안 키에 대한 자세한 내용을 보려면 [http://codex.wordpress.org/Editing\$1wp-config.php\$1Security\$1Keys](https://wordpress.org/support/article/editing-wp-config-php/#security-keys)로 이동하세요. **참고** 아래 값은 예시 목적만을 위한 것입니다. 설치 시 이 값을 사용하지는 마세요. ``` define('AUTH_KEY', ' #U$$+[RXN8:b^-L 0(WU_+ c+WFkI~c]o]-bHw+)/Aj[wTwSiZ)Y |;(^[Iw]Pi+LG#A4R?7N`YB3'); define('NONCE_KEY', 'P(g62HeZxEes|LnI^i=H,[XwK9I&[2s|:?0N}VJM%?;v2v]v+;+^9eXUahg@::Cj'); define('AUTH_SALT', 'C$DpB4Hj[JK:?{ql`sRVa:{:7yShy(9A@5wg+`JJVb1fk%_-Bx*M4(qc[Qg%JT!h'); define('SECURE_AUTH_SALT', 'd!uRu#}+q#{f$Z?Z9uFPG.${+S{n~1M&%@~gL>U>NV.|Y%Ug4#I^*LVd9QeZ^&XmK|e(76miC+&W&+^0P/'); define('NONCE_SALT', '-97r*V/cgxLmp?Zy4zUU4r99QQ_rGs2LTd%P;|_e1tS)8_B/,.6[=UK` ``` # # Possible values for the Options directive are "None", "All", # or any combination of: # Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews # # Note that "MultiViews" must be named *explicitly* --- "Options All" # doesn't give it to you. # # The Options directive is both complicated and important. Please see # http://httpd.apache.org/docs/2.4/mod/core.html#options # for more information. # Options Indexes FollowSymLinks # # AllowOverride controls what directives may be placed in .htaccess files. # It can be "All", "None", or any combination of the keywords: # Options FileInfo AuthConfig Limit # AllowOverride None # # Controls who can get stuff from this server. # Require all granted ``` 1. 위 영역에서 `AllowOverride None` 라인을 `AllowOverride All`로 변경합니다. **참고** 이 파일에는 `AllowOverride` 라인이 많기 때문에 `` 영역의 라인을 변경할 때는 주의해야 합니다. ``` AllowOverride All ``` 1. 파일을 저장하고 텍스트 편집기를 종료합니다. **AL2에 PHP 그래픽 그리기 라이브러리를 설치하려면** PHP용 GD 라이브러리를 사용하면 이미지를 수정할 수 있습니다. 블로그의 헤더 이미지를 잘라야 하는 경우 이 라이브러리를 설치합니다. 설치하는 phpMyAdmin 버전에는 이 라이브러리의 특정 최소 버전(예: 버전 7.2)이 필요할 수 있습니다. 다음 명령을 사용하여 AL2에 PHP 그래픽 그리기 라이브러리를 설치합니다. 예를 들어, LAMP 스택 설치의 일부로 amazon-linux-extras에서 php7.2를 설치한 경우 이 명령은 PHP 그래픽 그리기 라이브러리의 버전 7.2를 설치합니다. ``` [ec2-user ~]$ sudo yum install php-gd ``` 설치된 버전을 확인하려면 다음 명령을 사용합니다. ``` [ec2-user ~]$ sudo yum list installed php-gd ``` 다음은 예제 출력입니다. ``` php-gd.x86_64 7.2.30-1.amzn2 @amzn2extra-php7.2 ``` **Apache 웹 서버에 대한 파일 권한 수정 방법** WordPress의 제공 기능 중 일부(예: 관리 화면을 통한 미디어 업로드 등)는 Apache 문서 루트에 대한 쓰기 권한을 필요로 합니다. 아직 적용하지 않은 경우 다음 그룹 멤버십 및 권한을 적용합니다(에 자세히 설명됨[자습서: AL2에 LAMP 서버 설치](ec2-lamp-amazon-linux-2.md)). 1. `/var/www`의 파일 소유권 및 그 콘텐츠를 `apache` 사용자에게 허용합니다. ``` [ec2-user ~]$ sudo chown -R apache /var/www ``` 1. `/var/www` 및 그 콘텐츠의 그룹 소유권을 `apache` 그룹에 허용합니다. ``` [ec2-user ~]$ sudo chgrp -R apache /var/www ``` 1. `/var/www` 및 그 하위 디렉터리의 디렉터리 권한을 변경해서 그룹 쓰기 권한을 추가하고 미래 하위 디렉터리에서 그룹 ID를 설정합니다. ``` [ec2-user ~]$ sudo chmod 2775 /var/www [ec2-user ~]$ find /var/www -type d -exec sudo chmod 2775 {} \; ``` 1. `/var/www` 및 그 하위 디렉터리의 파일 권한을 재귀적으로 변경합니다. ``` [ec2-user ~]$ find /var/www -type f -exec sudo chmod 0644 {} \; ``` **참고** WordPress를 FTP 서버로도 사용하려는 경우 여기서 더 많은 권한 그룹 설정이 필요합니다. 이 작업을 수행하려면 권장된 [WordPress 단계 및 보안 설정](https://wordpress.org/support/article/changing-file-permissions/)을 검토하세요. 1. Apache 웹 서버를 재시작해서 새 그룹 및 권한을 가져옵니다. + ``` [ec2-user ~]$ sudo systemctl restart httpd ``` **AL2를 사용하여 WordPress 설치 스크립트 실행** 이제 WordPress를 설치할 준비가 되었습니다. 사용하는 명령은 운영 체제에 따라 다릅니다. 이 절차의 명령은 AL2와 함께 사용됩니다. 1. **systemctl** 명령을 사용하여 시스템이 부팅될 때마다 `httpd` 및 데이터베이스 서비스가 시작되도록 합니다. ``` [ec2-user ~]$ sudo systemctl enable httpd && sudo systemctl enable mariadb ``` 1. 데이터베이스 서버가 실행되는지 확인합니다. ``` [ec2-user ~]$ sudo systemctl status mariadb ``` 데이터베이스 서비스가 실행 중이지 않은 경우, 이를 시작합니다. ``` [ec2-user ~]$ sudo systemctl start mariadb ``` 1. Apache 웹 서버(`httpd`)가 실행 중인지 확인합니다. ``` [ec2-user ~]$ sudo systemctl status httpd ``` `httpd` 서비스가 실행 중이지 않은 경우, 이를 시작합니다. ``` [ec2-user ~]$ sudo systemctl start httpd ``` 1. 웹 브라우저에서 WordPress 블로그의 URL을 입력합니다(인스턴스에 대한 퍼블릭 DNS 주소 또는 `blog` 폴더 다음의 주소). 이제 WordPress 설치 스크립트가 나타납니다. WordPress 설치에 필요한 정보를 제공합니다. **WordPress 설치(Install WordPress)**를 선택해서 설치를 완료합니다. 자세한 내용은 WordPress 웹 사이트의 [5단계: 설치 스크립트 실행](https://wordpress.org/support/article/how-to-install-wordpress/#step-5-run-the-install-script)을 참조하세요. ## 다음 단계 WordPress 블로그를 테스트한 후 구성을 업데이트하세요. **사용자 지정 도메인 이름 사용** EC2 인스턴스의 EIP 주소와 연결되어 있는 도메인 이름이 있는 경우에는 EC2 퍼블릭 DNS 주소 대신에 해당 이름을 사용하여 블로그를 구성할 수 있습니다. 자세한 내용은 WordPress 웹 사이트의 [사이트 URL 변경](https://wordpress.org/support/article/changing-the-site-url/)을 참조하세요. **블로그 구성** 다른 [테마](https://wordpress.org/themes/)와 [플러그인](https://wordpress.org/plugins/)을 사용하여 더욱 풍부한 맞춤형 경험을 독자에게 제공하도록 블로그를 구성할 수도 있습니다. 하지만 설치 프로세스가 역효과를 낳아 전체 블로그를 잃는 경우가 발생할 수도 있습니다. 따라서 테마나 플러그인을 설치하기 전에 인스턴스의 백업 Amazon Machine Image(AMI)를 생성하여 설치 중 오류가 발생하더라도 블로그를 복구할 수 있도록 대비하는 것이 좋습니다. 자세한 내용은 [자체 AMI 생성을 참조하세요](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html#creating-an-ami). **용량 증가** 운영하는 WordPress 블로그가 유명해지고 그에 따라 보다 많은 컴퓨팅 파워 또는 스토리지가 필요하게 될 경우 다음 단계를 고려하세요. + 인스턴스에서 스토리지 공간을 확장합니다. 자세한 내용은 *Amazon EBS 사용 설명서*의 [Amazon EBS Elastic Volumes](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-modify-volume.html)를 참조하세요. + MySQL 데이터베이스를 [Amazon RDS](https://aws.amazon.com/rds)로 이동하여 이 서비스의 간편한 조정 기능을 이용합니다. **인터넷 트래픽의 네트워크 성능 향상** 블로그가 전 세계에 위치한 사용자로부터 트래픽을 유도할 것으로 예상되는 경우 [AWS Global Accelerator](https://aws.amazon.com/global-accelerator) 사용을 고려해 보세요. Global Accelerator는 사용자의 클라이언트 디바이스와 AWS에서 실행되는 WordPress 애플리케이션 간의 인터넷 트래픽 성능을 개선하여 지연 시간을 줄일 수 있도록 돕습니다. Global Accelerator는 [AWS 글로벌 네트워크를](https://aws.amazon.com/about-aws/global-infrastructure/global_network/) 사용하여 클라이언트와 가장 가까운 AWS 리전의 정상 애플리케이션 엔드포인트로 트래픽을 전달합니다. **WordPress에 대해 자세히 알아보기** WordPress에 대한 자세한 내용은 [http://codex.wordpress.org/](http://codex.wordpress.org/)에서 WordPress Codex 도움 문서를 참조하세요. 설치 문제 해결에 대한 자세한 내용은 [일반적인 설치 문제를](https://wordpress.org/support/article/how-to-install-wordpress/#common-installation-problems) 참조하세요. WordPress 블로그의 보안을 강화하는 방법에 대한 자세한 내용은 [ WordPress 강화를](https://wordpress.org/support/article/hardening-wordpress/) 참조하세요. WordPress 블로그up-to-date 유지하는 방법에 대한 자세한 내용은 [ WordPress 업데이트를](https://wordpress.org/support/article/updating-wordpress/) 참조하세요. ## 도움말\$1 내 퍼블릭 DNS 이름이 변경되어 블로그를 사용할 수 없습니다. WordPress 설치 위치는 EC2 인스턴스의 퍼블릭 DNS 주소를 사용해 자동으로 구성됩니다. 이때 인스턴스를 중단했다가 다시 시작하면 퍼블릭 DNS 주소가 바뀌어(탄력적 IP 주소와 연결되어 있지 않은 경우) 블로그를 더 이상 사용할 수 없게 됩니다. 리소스를 참조해야 할 주소가 더 이상 존재하지 않거나 다른 EC2 인스턴스에 할당되었기 때문입니다. 문제에 대한 자세한 설명과 몇 가지 가능한 해결 방법은 [사이트 URL 변경에](https://wordpress.org/support/article/changing-the-site-url/) 요약되어 있습니다. WordPress 설치에이 문제가 발생한 경우 WordPress용 **wp-cli** 명령줄 인터페이스를 사용하는 아래 절차를 사용하여 블로그를 복구할 수 있습니다. ****wp-cli**를 사용하여 WordPress 사이트 URL을 바꾸는 방법** 1. SSH를 통해 EC2 인스턴스에 연결합니다. 1. 인스턴스의 이전 사이트 URL과 새로운 사이트 URL을 기록합니다. 이전 사이트 URL은 WordPress 설치 시 EC2 인스턴스의 퍼블릭 DNS 이름일 가능성이 높습니다. 그리고 새로운 사이트 URL은 EC2 인스턴스의 현재 퍼블릭 DNS 이름입니다. 이전 사이트 URL을 잘 모르더라도 아래와 같이 **curl** 명령을 사용하여 찾을 수 있습니다. ``` [ec2-user ~]$ curl localhost | grep wp-content ``` 명령을 실행하여 출력되는 화면에서 이전 퍼블릭 DNS 이름의 참조를 확인해야 합니다. 출력 화면은 다음과 같습니다(빨간색의 이전 사이트 URL). ``` ``` 1. 다음 명령으로 **wp-cli**를 다운로드합니다. ``` [ec2-user ~]$ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar ``` 1. 아래와 같은 명령으로 이전 사이트 URL을 찾아 WordPress 설치 위치로 바꿉니다. EC2 인스턴스의 이전 사이트 URL과 새로운 사이트 URL, 그리고 WordPress 설치 경로(일반적으로 `/var/www/html` 또는 `/var/www/html/blog`)를 치환합니다. ``` [ec2-user ~]$ php wp-cli.phar search-replace 'old_site_url' 'new_site_url' --path=/path/to/wordpress/installation --skip-columns=guid ``` 1. 웹 브라우저에서 WordPress 블로그의 새로운 사이트 URL을 입력하여 사이트에 올바로 접속되는지 다시 확인합니다. 그렇지 않은 경우 [사이트 URL 변경](https://wordpress.org/support/article/changing-the-site-url/) 및 [일반적인 설치 문제](https://wordpress.org/support/article/how-to-install-wordpress/#common-installation-problems)에서 자세한 내용을 참조하세요.