【AWS】Apacheで最低限やっておくべきSSL/TLSの設定

AWSでEC2とRDSでwordpressをセットアップしてみたので記事にする！の第3回です。この記事ではApacheで最低限やっておくべきSSL/TLSの設定を紹介していきます。

この記事はこんな人にオススメ

必要でセキュアなインバウンドルールを知りたい！
EC2インスタンスにApacheでWEBサーバを立てたい！
Apacheで最低限設定すべきことを知りたい！
EC2インスタンスにSSLを使えるようにしたい！
自己署名証明書（オレオレ証明書）でSSLを使いたい！

このサイト（ブログ）はConoHa WINGで運用しています。国内最速、超安定、稼働率99.99%以上、ということだけあってConoHa WINGにまったく不満もなくむしろ動作もキビキビ速いし、コンソールもまずまず使いやすく快適で満足しかないです。ConoHa WINGの詳細はこちらです。

当サイトのサーバ：ConoHa WING

ConohHa WING：当サイトで使用しているサーバです

本シリーズの記事はAWSのEC2とRDSを使ってwordpressをセットアップし、バックアップにはS3を活用します。自由度や柔軟性は圧倒的にAWSが高い反面、セキュリティの対策や日々のメンテナンスも必要になってきます。つまりネットーワークやセキュリティ、AWSの勉強にはもってこい！ってことです。

それとは逆に、コンテンツ制作やクリエイティブ面に注力したい場合は、ネットワークやセキュリティ、サーバ構築、メンテナンスなどがほぼ必要のないConoHa WINGがオススメです。

国内最速しかも安い：ConoHa WING

ConohHa WING：国内最速、超安定のレンタルサーバ

前回までの記事を少しご紹介します。

第1回ではコンソール操作でEC2とRDSを準備する方法を紹介しました。
まだAWSアカウントを作成されていない方や、インスタンスをまだ立ち上げていない方は、まず下の記事からご覧ください。

関連

【AWS】コンソール操作でEC2とRDSを準備する

第2回ではEC2にSSHで安全にアクセスする方法を紹介しました。
下の記事からご覧ください。

関連

【AWS】EC2にSSHで安全にアクセスする

そして第3回のこの記事では、
Apacheで最低限やっておくべきSSL/TLSの設定を紹介していきます。

この記事でわかること

やっておくべきインバウンドルール
やっておくべき最低限のApacheの設定
mod_sslの設定
SSLの申請と設定
自己署名証明書（オレオレ証明書）の設定

ネットワーク、セキュリティや各種チューニング、AWSの各サービスの詳細は奥が深すぎるので今回は触れませんが、「AWSではじめるインフラ構築入門安全で堅牢な本番環境のつくり方」はオススメの書籍です。

全体像

STEP
【AWS】コンソール操作でEC2とRDSを準備する
関連
【AWS】コンソール操作でEC2とRDSを準備する
STEP
【AWS】EC2にSSHで安全にアクセスする
関連
【AWS】EC2にSSHで安全にアクセスする
STEP
【AWS】Apacheで最低限やっておくべきSSL/TLSの設定
関連
【AWS】Apacheで最低限やっておくべきSSL/TLSの設定
STEP
【AWS】EC2とRDSでwordpressをセットアップする
関連
【AWS】EC2とRDSでwordpressをセットアップする
STEP
【AWS】S3にwordpressをバックアップする
関連
【AWS】S3にwordpressをバックアップする

EC2インスタンスのサーバ構築

インバウンドルールの追加

ApacheのWEBサーバを構築するにあたり、HTTPとHTTPSのアクセスを許可します。構築するサイトはまだ自分自身しかアクセスする必要はないので、可能な限りアクセス元のIPアドレスは制限します（自宅のIPアドレスなど）。アクセス元を制限する方法は「インバウンドルール」で設定します。

アクセス元を制限しないと全世界からアクセスできる状態となり、第三者により不正アクセスされる可能性が高まり大変危険です。テストサイトなどは必ずアクセス元を必要最低限に制限します。

EC2のダッシュボードからセキュリティーグループのインバウンドルールで、SSH（TCP22番）に加え、HTTP（80番）とHTTPS（443番）を特定のIPアドレスから許可します。

タイプ	プロトコル	ポート	ソース	IPアドレス
SSH	TCP	22	カスタム	x.x.x.x/32
HTTP	TCP	80	カスタム	x.x.x.x/32
HTTPS	TCP	443	カスタム	x.x.x.x/32

Apacheか？Nginxか？

WEBサーバはApacheかNginxか？ってぐらい両者のシェアが高くどちらを選択するか悩みどころです。下記の状況を見るとどちらも経験しておいた方がよいかな、と改めて思いました。

2022年10月7日現在のシェアはNginxが34.2%、Apacheが31.3%とほぼ互角です。

参考

Historical trends in the usage statistics of web servers, October 2022

w3techs.com

現在のシェアで見ると互角ですが、直近の10年でみるとApacheのシェアが50%以上低下しNginxのシェアが凄まじい勢いで増加しています。

	2011	2015	2020	2022
Apache	69.7%	58.8%	42.1%	31.3%
Nginx	5.9%	22.9%	31.3%	34.2%

引用：https://w3techs.com/technologies/history_overview/web_server/ms/y

参考

Historical yearly trends in the usage statistics of web servers, October 2022

w3techs.com

性能の比較やそれぞれのメリット、デメリットについては下のサイトがとても参考になります。

参考

ApacheとNginxについて比較 – Qiita

qiita.com

参考

NginxとApacheの比較〜ウェブサーバー直接対決〜

Kinsta

私の結論は、ApacheもNginxも両方できるに越したことはない、です。どちらかを選ぶ必要に迫られたら初心者はApacheです。Apacheで出来ることを理解した上で、Nginxを比較しながら理解する、というのが良いと思います。

Apacheのインストールと設定

yum updateで最新にアップデートし、yumでhttpd（Apache2.4系）をインストールします。

Apacheのインストールとバージョン確認


sudo yum update -y
sudo yum install httpd -y

httpd -vでバージョンを確認しておきます。


httpd -v
Server version: Apache/2.4.54 ()
Server built:   Jun 30 2022 11:02:23

最新のApacheのバージョンは下記のApache公式サイトで確認できます。

参考

Download – The Apache HTTP Server Project

httpd.apache.org

Apacheの起動、自動起動

Apacheを起動し、再起動時に自動で起動するように設定します。


sudo systemctl start httpd
sudo systemctl enable httpd.service

Apacheの状態確認はsystemctl statusです。


sudo systemctl status httpd
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
  Drop-In: /usr/lib/systemd/system/httpd.service.d
           └─php-fpm.conf
   Active: active (running) since 火 2022-09-27 17:16:17 JST; 1 weeks 3 days ago
     Docs: man:httpd.service(8)

Apacheの再起動、停止、自動起動停止

Apacheの設定ファイルを変更した際などは、Apacheの再起動が必要になります。systemctl restartでApacheの再起動ができます。


sudo systemctl restart httpd

接続の確認

この段階でHTTPで「インバウンドルール」で許可したIPアドレスからアクセスすることができます。試してみましょう。ブラウザのURL入力箇所にIPアドレスを入力しアクセスします。test pageが表示されるはずです。

test pageは、ドキュメントルートにindex.html（やindex.php）などのコンテンツが存在しない場合に表示されるテストページです。

本番運用する際は、test pageが表示されることは好ましくないので、test pageを表示しない設定にしておきます。

Apacheの最低限必要な4つの設定

これまでのようにApacheは簡単にインストールすることができ、またインストール後すぐに動作することができます。動かすまでに面倒な設定は不要でありがたいですが、一方でデフォルトの状態はセキュリティがあまい状態にあります。最低限必要な設定を紹介していきます。

その1：test pageを表示しない設定

接続を確認したらtest pageを無効にします。/etc/httpd/conf.d/welcome.confがtest pageの設定ファイルです。

welcome.confの中身をすべてコメントアウトします。welcome.confを削除したりリネームするだけではApacheのアップグレード時にwelcome.confが復活しますので、中身の全てをコメントアウトする方法がオススメです。


sudo vi /etc/httpd/conf.d/welcome.conf
# welcome.confの内容をコメントアウトします。

設定後はApacheの再起動が必要です。sudo systemctl restart httpd

その2：ディレクトリ一覧を表示しない設定

次にindex.htmlやindex.phpが存在しない場合、ディレクトリ一覧が表示されてしまいます。悪意のある第三者に悪用される危険もありますので、ディレクトリ一覧表示をOFFにします。

ディレクトリ一覧を表示しないために、/etc/httpd/conf/httpd.confでIndexesを削除します。


sudo vi /etc/httpd/conf/httpd.conf
# Directory "/var/www/html" の144行明付近の
# Options Indexes FollowSymLinks を
# Options FollowSymLinks　にします。

設定後はApacheの再起動が必要です。sudo systemctl restart httpd

その3：バージョン情報を非表示にする

存在しないページにアクセスした際に表示されるエラーページにApacheのバージョンやOSが表示されます。悪意のある第三者にソフトウェアのバージョンやOSが知られることで、例えばそのバージョンに存在するバグをつかれて悪用される危険があります。バージョン情報を表示しないように設定します。

バージョン情報とは、Apacheのレスポンスヘッダー内のServerヘッダーで返される文字列です。

Apacheのバージョン情報が表示されているレスポンス


nc IPアドレス 80
HEAD / HTTP/1.0
#上記のHEAD以降を入力しEnter
（省略）
Server: Apache/2.4.54 () OpenSSL/1.0.2k-fips PHP/7.4.30
（省略）

Apacheのバージョン情報が非表示にしたレスポンス


nc IPアドレス 80
HEAD / HTTP/1.0
#上記のHEAD以降を入力しEnter
（省略）
Server: Apache
（省略）

バージョン情報を非表示にするには、/etc/httpd/conf/httpd.confにServerTokens ProductOnlyを追加します。


sudo vi /etc/httpd/conf/httpd.conf
#httpd.conf内にServerTokens ProductOnlyを追加します。
#（httpd.confの一番最後に記載するとわかりやすいですね）

設定後はApacheの再起動が必要です。sudo systemctl restart httpd

ServerTokens には以下のオプションがあります。

オプション	表示例
`ServerTokens Full`	Apache/2.4.54 (unix) OpenSSL/1.0.2k-fips PHP/8.1.11
`ServerTokens ProductOnly`	Apache
`ServerTokens Major`	Apache/2
`ServerTokens Minor`	Apache/2.4
`ServerTokens Minimal`	Apache/2.4.54
`ServerTokens OS`	Apache/2.4.54 (unix)

表：ServerTokensのオプション

その4：iconsディレクトリを無効化する

ブラウザで「IPアドレス/icons/」にアクセスすると、もともと用意されている画像ファイルが一覧表示されてしまいます。また「IPアドレス/icons/README」にアクセスするとiconsに関する説明ファイルが表示されます。これを無効化します。/etc/httpd/conf.d/autoindex.confが設定ファイルです。


sudo vi /etc/httpd/conf.d/autoindex.conf
Alias /icons/ "/usr/share/httpd/icons/"

<Directory "/usr/share/httpd/icons">
    Options Indexes MultiViews FollowSymlinks
    AllowOverride None
    Require all granted
</Directory>
#上記をコメントアウトします。

設定後はApacheの再起動が必要です。sudo systemctl restart httpd

Apacheのインストールと最低限の設定は終わりです。この後にSSLの設定を行います。

mod_sslのインストール

本番用にサーバ証明書を使ったSSLを有効化する方法と、Apache2.4系で自己署名証明書（オレオレ証明書）を使ったSSLを有効化する方法を紹介していきます。

まずはmod_sslをインストールします。mod_sslはApacheでSSL/TLSを有効にするためのモジュールで、OpenSSLへのインタフェースを提供します。

mod_sslのインストール

まずはmod_sslをインストールします。


sudo yum update -y
sudo yum install mod_ssl -y

mod_sslの設定ファイル

mod_sslの設定でよく使うディレクトリやファイルは下記となります。ファイルが多くまたディレクトリも微妙に異なり格納場所がわからなくならないようにまとめてみます。

パス	説明
`/etc/httpd/conf.d/ssl.conf`	mod_sslの設定ファイル
`/etc/pki/tls/certs/make-dummy-cert`	自己署名証明書（オレオレ証明書）を作成するスクリプト
`/etc/pki/tls/private/`	秘密鍵を格納するディレクトリ
`/etc/pki/tls/certs/`	公開鍵や証明書を格納するディレクトリ

表：mod_sslでよく使うディレクトリやファイル

秘密鍵、公開鍵、CSRの見分け方

秘密鍵、公開鍵、CSRの意味が理解しにくいのに加えて、ファイル自体の見分けもつかないのでこれまたややこしく、難しく感じる原因でもあると思います。さっくり見分け方をまとめます。

ファイルの「始まり」と「終わり」で秘密鍵、公開鍵、CSRかを判別できます。

種類	始まり	終わり
秘密鍵	`—–BEGIN RSA PRIVATE KEY—–`	`—–END RSA PRIVATE KEY—–`
公開鍵	`—–BEGIN CERTIFICATE—–`	`—–END CERTIFICATE—–`
CSR	`—–BEGIN CERTIFICATE REQUEST—–`	`—–END CERTIFICATE REQUEST—-`

サーバ証明書を使ったSSL有効化方法

本番サイト用のSSLを設定していきます。流れは下の通りステップ1からステップ5となります。なお、テストサイト用の自己署名証明書（オレオレ証明書）の作成方法はこちらです。

AWSの公式ドキュメントの「チュートリアル: Amazon Linux 2 に SSL/TLS を設定する」も参考になります。

STEP
秘密鍵を作成する
STEP
CSR（署名リクエスト：Certificate Signing Request）を作成する
STEP
SSLサーバ証明書を発行する認証局（CA）へCSRを送信する
STEP
認証局がドメイン認証する
STEP
認証局（CA）が署名をしたサーバ証明書を入手する
STEP
Apacheの設定を行いサーバ証明書を使えるようにする

【STEP1】秘密鍵を作成する

ここでは秘密鍵をprivate.keyというファイル名で作成します。現在の主流である2048ビットのRSA公開鍵暗号方式の秘密鍵を作成します。秘密鍵だけにパーミッションは600にします。


cd /etc/pki/tls/private/
sudo openssl genrsa -out private.key
sudo chmod 600 private.key

RSAの鍵長は2048ビットで作成しました（デフォルトで2048ビット）が現在の主流の鍵長です。

【STEP2】CSR（署名リクエスト：Certificate Signing Request）を作成する

ここではCSRをcsr.pemというファイル名で作成します。


cd /etc/pki/tls/private/
sudo openssl req -new -key private.key -out csr.pem

下のような入力項目が表示されます。認証局により必須の項目が異なりますので確認をおすすめします。項目の入力を指定しない場合は「.」（ピリオド）を入力します。


Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

項目	説明	例
Country Name	2文字国のコード(ISO-3166)	JP
State or Province Name	都道府県名	Tokyo
Locality Name	市区町村名	Shibuya-Ku
Organization Name	会社名の英文名称
Organizational Unit Name	申請部署
Common Name	SSL接続する際に使われるドメイン名
Email Address	証明書に反映されないので入力しない（「`.`」（ピリオド））
A challenge password	入力しない（そのままリターン）
An optional company name	入力しない（そのままリターン）

これでcsr.pemが出来ました。次はこのcsr.pemを認証局に送ります。

【STEP3】SSLサーバ証明書を発行する認証局（CA）へCSRを送信する

STEP2で作成したcsr.pemをサーバ証明書を発行する認証局へ送付します。送付の方法も認証局により様々あると思いますが、フォームにcsr.pemの内容をコピペするか、フォームでcsr.pemアップロードすることが多いと思います。

【STEP4】認証局がドメイン認証する

次に、認証局がドメイン認証を行います。

ドメイン認証は「ドメイン所有権確認」とも呼ばれており、ドメインを持っていることを証明するための手続きです。
https://ssl.sakura.ad.jp/column/domain-authentication-pitfalls/

例えば、「sub.example.jp」というサブドメインのSSL証明書を取得したい場合、「example.jp」のドメインを本当に所有しているのかを確認します。この確認の方法は様々あります。

電話認証
DNS認証
ファイル認証
ページ認証
メール認証

上記以外にもあると思いますが、ざっくり認証の方法を下記に記載します。

電話認証

認証に利用するデータベースでその申請組織の電話番号（代表電話番号）を確認し、実際に電話がかかってきて認証する方法です。

DNS認証

指定された文字列（認証文字列）をDNSのTXTレコードに追加し認証する方法です。ドメインを管理するシステム管理者は対応しやすい方法です。

ファイル認証

指定されたファイル名のファイルをWEBサーバにアップロードして認証する方法です。サイトの管理者は対応しやすい方法です。

ページ認証

指定されたMETAタグをHTMLに追加して認証する方法です。これもサイトの管理者は対応しやすい方法です。

メール認証

該当ドメインの特定のメールアドレスに認証のメールが届き認証する方法です。テクニカルなことは発生しないので簡単で楽です。

【STEP5】認証局（CA）が署名をしたサーバ証明書を入手する

STEP4の認証が無事に終わると、CAによって署名されたサーバ証明書が届きます。

【STEP6】Apacheの設定を行いサーバ証明書を使えるようにする

サーバ証明書の設置

STEP5で届いたサーバ証明書を/etc/pki/tls/certs/に設置します。ファイル名は何でも良いですが、ここではdomain.crtとします。

STEP5で届いたサーバ証明書をEC2インスタンスに安全に設置する方法はいくつかあります。今回は一番簡単で確実でもあるviでコピペする方法にします。

ここでは/etc/pki/tls/certs/domain.crtに秘密鍵をviでコピペします。


cd /etc/pki/tls/certs/
sudo vi domain.crt
# viでdomain.crtを開き、STEP5で届いたサーバ証明書の内容をコピーします

sudo chmod 600 domain.crt

ここでは/etc/pki/tls/certs/domain.ca-bundleに中間証明書をviでコピペします。


cd /etc/pki/tls/certs/
sudo vi domain.ca-bundle
# viでdomain.ca-bundleを開き、STEP5で届いた中間証明書の内容をコピーします

sudo chmod 600 domain.ca-bundle

ssl.confの設定

ssl.confに、ステップ1で作成した秘密鍵と、上記で設置したサーバ証明書や中間証明書を指定します。


sudo vi /etc/httpd/conf.d/ssl.conf
SSLCertificateFile /etc/pki/tls/certs/domain.crt
#上記は102行目付近（サーバ証明書の指定）

SSLCertificateKeyFile /etc/pki/tls/private/private.key
#上記は110行目付近（秘密鍵の指定）

SSLCACertificateFile /etc/pki/tls/certs/domain.ca-bundle
上記は130行目付近（必要により中間証明書の指定）

Apacheを再起動して確認する


sudo systemctl restart httpd

再起動後、ブラウザでhttps://IPアドレスにアクセスできることを確認します。

徹底解剖 TLS 1.3

マスタリングTCP/IP 情報セキュリティ編 (第2版)

自己署名証明書（オレオレ証明書）を使ったSSL有効化方法

自己署名証明書（オレオレ証明書）のSSLを設定します。本番用のSSLを設定している場合は不要です。

自己署名証明書（オレオレ証明書）はテストサイト用でSSLの検証をするためにも便利です。あくまで自己署名のダミー証明書なので本番サイトでは使用しません。下記のコマンドでテスト用の自己署名証明書（オレオレ証明書）を作成します。

なお、本番サイト用のサーバ証明書の作成方法はこちらです。

AWSの公式ドキュメントの「チュートリアル: Amazon Linux 2 に SSL/TLS を設定する」も参考になります。

自己署名証明書の作成


cd /etc/pki/tls/certs/
sudo ./make-dummy-cert localhost.crt

/etc/pki/tls/certs/にlocalhost.crtが作成されます。


ls -l /etc/pki/tls/certs/
（略）
-rw------- 1 root root 3.2K  9月 27 17:14 localhost.crt
（略）

自己署名証明書の確認

catで中身を確認すると秘密鍵と公開鍵（オレオレ証明書）であることがわかります。


sudo cat /etc/pki/tls/certs/localhost.crt
-----BEGIN PRIVATE KEY-----
（略）
-----END PRIVATE KEY-----

-----BEGIN CERTIFICATE-----
（略）
-----END CERTIFICATE-----

ssl.confの設定

/etc/httpd/conf.d/ssl.confのSSLCertificateKeyFileをコメントアウトします。


sudo vi /etc/httpd/conf.d/ssl.conf
#SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
107行目の上記行をコメントアウトします

指定されている/etc/pki/tls/private/localhost.keyは存在しないのでコメントアウトします。また秘密鍵は/etc/pki/tls/certs/localhost.crtに公開鍵とセットで記載されているのでSSLCertificateKeyFileの指定は不要となるためです。

Apacheを再起動して確認する


sudo systemctl restart httpd

再起動後、ブラウザでhttps://IPアドレスにアクセスできることを確認します。

MFA（多要素認証）を有効にする

AWSで必ずやっておきたい多要素認証の設定方法を紹介します。

AWSではセキュリティ強化のために必ずMFA（多要素認証）を設定しましょう。AWSアカウントのルートユーザーとIAMユーザーでMFAを設定することができます。設定も簡単です。

ざっくりMFAとは？

MFAとは、一般的なログイン認証情報であるユーザー名とパスワードに加えて、もう1つ（1つ以上）の認証要素を加え、ユーザに対してこの2つ以上の認証要素を要求し認証する方法です。

今回は追加の認証要素としてワンタイムパスワード（OTP）を追加します。ワンタイムパスワードは6桁の数字となり、受信方法はSMSやメールといったケースも多いですが、私は1Password8で保存してワンタイムパスワードを管理しています。

2FAとの違いは？

ちなみに、2FAという単語もよく見かけますが2FAとは「2要素認証」です。2FAは2つの要素で認証する方法ですが、MFAは2つ以上の要素を設定し認証する方式です。

それではAWSのMFAを有効にしましょう。

AWSでワンタイムパスワードを追加する手順

以下のAWS公式ドキュメントを参考にMFAを有効にします。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_mfa_checking-status.html

STEP
IAM コンソールにアクセス

AWS Management Console にサインインし、IAM コンソールにアクセスします。

IAMコンソール：https://console.aws.amazon.com/iam/
STEP
セキュリティ認証情報をクリック

右上のナビゲーションバーでユーザー名を選択し、セキュリティ認証情報をクリックします。
STEP
MFAが有効か無効かを確認

MFAが有効でない場合は下の画像のようにアラートが出ています。
STEP
MFAを割り当てる

では実際にMFAを割り当て設定します。
STEP
MFAデバイスを選択

今回は1Password8でワンタイムパスワードを管理するので「Authenticator app」を選択します。デバイス名にはわかりやすい名前をつけます。（なんでも構いません）
STEP
デバイスの設定

QRコードを表示して、1Password8でスキャンします。

1Password8では、ワンタイムパスワードの項目を追加して下の画像のようにスキャンします。

参考
https://support.1password.com/one-time-passwords/
support.1password.com
STEP
MFAコードを2つ入力しMFAを追加する

1Password8の追加したワンタイムパスワードの項目に表示された6桁のコードを入力し、最大30秒後に新しいコードが生成されるのでそれを入力します。

これでMFAを追加することができました。