はじめに
プログラミングスクールで作成したSNSアプリをAWSにデプロイしていましたが、http通信のままでセキュアではなかったため、https対応をしたものです。
下記記事を参考にさせて頂きました。ありがとうございます。
当初、Route 53 → ALB → EC2とする予定でしたが、アクセス数が限られることやコストの観点から、Route 53 → CloudFront → EC2に変更しました。
参考記事
AWS EC2上のアプリのhttpリクエストをhttpsにした【初学者】
内容
- ドメインの取得（お名前.comにて取得）
- SSL証明書の取得
- ロードバランサーの作成（は行わず、CloudFrontにて対応）
- CloudFrontの設定
- まとめ
SSL証明書の取得
AWSコンソール画面で「Certificate Manager」を選択
※ AWS Certificate Manager（以下、ACM）とは、AWSで提供されているSSL証明書の発行サービス
新しいACM管理証明書「証明書をリクエスト」を選択
証明書をリクエスト「パブリック証明書をリクエスト」
取得したドメイン名を記載します
検証方法：DNS検証
キーアルゴリズム：ECDSA P 256
- セキュリティとパフォーマンスを考慮
- 従来のRSA 2048よりも暗号化処理が高速な『ECDSA 256bit』を選択
-『ECDSA 384bit』を選択しなかったのは下記理由
・ 計算量が多くなり接続に時間がかかる
・ 少し古めのOSだと対応していないものが多い
・ セキュリティ的には256で十分（384は国家機密情報レベル）
下の画像のページ下にある「タグ」項目は設定しない（下画像には写っていない）
ページ右下のリクエストを押下する（下画像には写っていない）
DNS自体はお名前.comで取得しましたが、管理をAWS側にするようにしました。
DNSレコードの設定がされていないため、証明書のステータスが「保留中の検証」となっている。
Route53のホストゾーン作成
「レコードを作成」から、タイプNSの「値/トラフィックのルーティング設定」の４つのNS(ネームサーバー)レコードを記録しておきます
お名前.comにログイン
ネームサーバーの変更で、「2.ネームサーバーの選択」→「その他のネームサーバーを使う」
→ 先ほどの４つのNSレコードを記載
AWSに戻り、ACM「証明書のステータス」画面で、「Route 53でレコードを作成」押下
数分〜１時間程度で、レコード作成完了
ロードバランサーの作成
と思いましたが、コスト最適化を意識してアーキテクチャを選定することとし、CloudFront+EC2の構成とします。
CloudFrontの設定
ACM証明書の再取得
CloudFrontにセットできるACM証明書は、「米国東部（バージニア北部：us-east-1）リージョン」で作成したものだけというAWSの厳格なルールがあるため、再度取得します。
リージョン変更して再取得
米国東部（バージニア北部：us-east-1）リージョンに変更して、上記「SSL証明書を取得」と同様にして取得する。
CloudFrontに移動
ディトリビューションを作成
Origin typeの設定
Custom originとし、EC2 > インスタンス よりパブリックDNSをコピーし入力します。
- オリジン設定
「Customize origin settings」 にチェックを入れます。
[理由] : 「Protocol」を「HTTP only」とするため（CloudFront→EC2は80番ポートで通信） - キャッシュ設定
動的コンテンツのため、CloudFrontが画面を記憶しないように「キャッシュポリシー」を「CachingDisabled」に指定します。
Enable security
セキュリティオプション選択画面となりますが、
「セキュリティ保護を有効にしないでください
アプリケーションに AWS WAF セキュリティ保護が必要ない場合は、このオプションを選択してください。」
を選択。
※CloudFront自体に標準のDDoS防御（AWS Shield Standard）が無料で組み込まれていて、WAFを追加しなくても、一般的なbotや大量アクセスへの最低限の対策はできているため。
ディストリビューションの作成
あとはそのまま進み、「create distribution」を押下
ディトリビューションの一覧画面のステータスが [デプロイ]→[有効] になれば完了です。
まとめ
コスト最適化の意識
アクセス数が限られる個人開発のアプリで、月額約3,000円のALB（ロードバランサー）を使うのは過剰と判断し、無料枠が非常に大きい CloudFront ＋ EC2 の構成を採用して固定費をほぼ0円に抑えるよう対応した。
最新のセキュリティトレンドの理解
証明書には、従来のRSA 2048bitよりも処理が高速でモダンな ECDSA 256bit（P-256） を選択し、パフォーマンス向上を図った。
アプリの動作担保（バグの防止）
ログイン機能や動的コンテンツのバグを防ぐため、CloudFrontのキャッシュポリシーを CachingDisabled（キャッシュ無効） に、オリジンリクエストポリシーをAllViewerExceptHostHeader に設定し、クッキーやセッション情報を正確にEC2へ引き渡すように設計した。