HTTPSの終端:API GatewayとALBの比較とセキュリティ上の考察
HTTPとHTTPS
インターネットの世界では、情報のやり取りはHTTP(Hypertext Transfer Protocol)というプロトコルを基礎として行われます。
しかし、HTTPは基本的にテキストベースのプロトコルであり、そのままでは通信内容が第三者に盗み見られる危険性があります。ここで重要な役割を果たすのがHTTPS(HTTP over SSL/TLS)です。
HTTPSの終端とは
HTTPSの終端(Termination)は、HTTPSトラフィックが復号され、通常のHTTPトラフィックに変換されるプロセスです一般的には、負荷分散装置(Load Balancer)、リバースプロキシ、またはサーバー自体で行われます。
HTTPS終端の主な利点は、暗号化されたトラフィックの処理を特定のポイントで集中させることができ、後続のシステム(サーバー、アプリケーションなど)は通常のHTTPトラフィックを扱うだけで済むことです。
SSL証明書の種類
SSL(Secure Sockets Layer)証明書は、インターネット上でのデータの安全な伝送を保証するために使用されます。
これらの証明書は、特にWebサイトとその訪問者間の通信を暗号化し、セキュリティを確保するために重要です。SSL証明書にはいくつかの主要な種類があり、それぞれ異なるレベルのセキュリティと検証を提供します。
1. ドメイン検証(DV)SSL証明書
検証レベル: 低
使用目的: 基本的なウェブサイトやブログに適しています。
プロセス: 証明書発行機関(CA)は、申請者がドメイン名の管理者であることのみを確認します(通常は電子メールによる確認)。
特徴: DV証明書は迅速かつ簡単に取得でき、コストも低いですが、組織の詳細な検証は行いません。
2. 組織検証(OV)SSL証明書
検証レベル: 中
使用目的: ビジネスウェブサイトや公共機関のウェブサイトに適しています。
プロセス: CAは申請者の組織が合法的な存在であることを確認します。これには、組織の名前、所在地、その他の企業情報の確認が含まれます。
特徴: OV証明書は、ビジネスの正当性を示すために使用され、信頼性が高いです。
3. 拡張検証(EV)SSL証明書
検証レベル: 高
使用目的: 高度なセキュリティが求められるビジネスウェブサイト、特に金融機関やオンラインストアに適しています。
プロセス: CAは、厳格な検証プロセスを通じて申請者の組織を確認します。これには、組織の合法性、運営状況、身元の確認などが含まれます。
特徴: EV証明書は、ブラウザのアドレスバーに緑色の表示をもたらし、訪問者に対して最高レベルの信頼性を示します。
AWS環境におけるHTTPSの終端とは
AWS環境でHTTPSの終端を行う場合、通常はAWSのサービス(例えばElastic Load BalancerやAmazon CloudFront)を使います。これらのサービスでHTTPSを使用するためには、SSL/TLS証明書が必要です。ここでACMが重要な役割を果たします。
ACMの役割
ACMで生成またはインポートしたSSL/TLS証明書は、これらのAWSサービスに簡単に統合できます。例えば、Elastic Load BalancerにACMで生成した証明書を適用することで、そのLoad BalancerはHTTPSの終端ポイントとして機能し、安全な通信を提供することができます。
ユーザーとの通信をHTTPSで暗号化するとともに、ドメインの使用権を確認してアクセス先のサーバーが本物でるという証明をします。
ACMで管理するSSL/TLS証明書はACMから発行できるほか、ユーザー独自の証明書もインポートして利用できます。
※ACMで発行できる証明書はドメイン証明書のみです
ACMで発行した証明書は有効期限が切れる前に自動で更新されますが、インポートした証明書はユーザーが更新しなければなりません。
AWS Configを利用して証明書の有効期限切れを防止する
AWS ConfigはACMで管理している証明書の有効期限に関するルールを作成できます。ユーザーが指定した日数以内に有効期限が切れる場合、Event Bridgeのイベントルールを作成し、Amazon SNSから通知することができます。
API GatewayとALB:HTTPSの終端を扱うAWSのサービス
HTTPSの終端を行うAWSのサービスであるAPI GatewayとApplication Load Balancer(ALB)について詳しく見ていきましょう。以下は、サーバ証明書をApplication Load Balancer (ALB) および API Gateway に配置する場合のメリットとデメリットの比較表です。
比較項目 | ALB | API Gateway |
---|---|---|
スケーラビリティ | Auto Scalingグループと組み合わせて、トラフィックの増加に応じて自動的にインスタンスをスケールアウトできる | 高トラフィックの場合にも自動的にスケールアウトできる |
ヘルスチェックと負荷分散 | ヘルスチェック機能を提供し、正常なインスタンスにのみトラフィックをルーティングできる。また、トラフィックの負荷分散も行う | ヘルスチェックと負荷分散をサポートしている |
ユーザー認証と認可 | ALBは、クライアント証明書を使用してクライアントの認証を行うことができる。また、ALBに接続されたアプリケーション自体でユーザー認証と認可を実装できる | AWS Cognitoやカスタム認証基盤と統合することでユーザー認証と認可を行うことができる。 |
設定の複雑さ | 柔軟な設定が可能だが、その分設定の複雑さも増す。特に、複数のターゲットグループやルーティングルールを設定する場合は注意が必要 | よりシンプルに設定できるが、一部の高度な設定は制限されている |
コスト | リクエスト数やデータ転送量に基づく | リクエスト数やデータ転送量に基づく |
サーバ証明書をどちらに設置すべきか悩んでいる場合、以下が参考になるかもしれません。
1. ALBに設置するのが適している場合:
- もしアプリケーションがバックエンドサーバ(EC2インスタンスなど)を必要とし、スケーラビリティや負荷分散が重要な要素である場合、ALBにサーバ証明書を設置することを検討します。
- ALBはAuto Scalingグループと組み合わせて使用することで、トラフィックの増加に応じて自動的にインスタンスをスケールアウトします。
- ALBはヘルスチェック機能と負荷分散を提供しており、正常なインスタンスにのみトラフィックをルーティングし、負荷を分散することができます。
2. API Gatewayに設置するのが適している場合:
- アプリケーションがサーバレスアーキテクチャを採用しており、APIの公開やユーザー認証・認可が重要な要素である場合、API Gatewayにサーバ証明書を設置することを検討します。
- API Gatewayはスケーラブルなサービスであり、高トラフィックの場合にも自動的にスケールアウトします。
- API GatewayはAWS Cognitoやカスタム認証基盤と統合する事が可能です※。
-
設定手順の概要
設定手順は以下の通り。
(1)ユーザーがRoute 53を使用してドメイン名を登録または移管します。
(2)ユーザーがACMで新しい証明書をリクエストし、その際にRoute 53で管理しているドメイン名を指定します。
(3)ACMがRoute 53を通じてドメインの所有権を確認します。
(4)Route 53が所有権を確認した後、ACMが証明書の承認をユーザーに通知します。
(5)ユーザーが承認された証明書をALBにデプロイします。
(1)ユーザーがRoute 53を使用してドメイン名を登録または移管します。
(2)ユーザーがACMで新しい証明書をリクエストし、その際にRoute 53で管理しているドメイン名を指定します。
(3)ACMがRoute 53を通じてドメインの所有権を確認します。
(4)Route 53が所有権を確認した後、ACMが証明書の承認をユーザーに通知します。
(5)ユーザーが承認された証明書をAPI Gatewayにデプロイします。
これにより、API GatewayでHTTPSの終端を行うことが可能となります。
セキュリティ要件やアプリケーションの特性によっても選択肢が異なる場合があるため、詳細な要件や制約を考慮しながら最適な選択を行うようにしましょう。
参考
Amazon Cognito ユーザープールをオーソライザーとして使用して REST API へのアクセスを制御する
※AWS Cognitoではサービス単位での認可しかできないので「認証」ではありません
Discussion