142-AWS SAP AWS 「理論・実践・一問道場」

type

status

date

slug

summary

理論

AWSでのAPIセキュリティとプライベートアクセスに関する知識

AWSでAPIをセキュアかつ効率的に運用するには、適切な設計と設定が必要です。このセクションでは、特にAPI Gatewayを使用したプライベートAPIの構築に関連する重要な知識を解説します。

1. API Gatewayのエンドポイントタイプ

API Gatewayは以下の3種類のエンドポイントタイプを提供します：

エッジ最適化 (Edge-Optimized):

グローバルに分散されたCloudFrontエッジロケーションを利用。
世界中のユーザー向けに最適化。

リージョナル (Regional):

特定のAWSリージョン内でエンドポイントを提供。
高速なレスポンスが必要な地域での使用に適している。

プライベート (Private):

VPC内からのみアクセス可能。
重要：完全にパブリックアクセスを排除し、セキュアなネットワーク環境での運用が可能。

2. VPCエンドポイントを使用したプライベートAPI

プライベートAPIをVPC内で利用するには、VPCエンドポイント (Interface VPC Endpoint) を設定します。

設定手順

API Gatewayエンドポイントタイプの変更:

API Gatewayのエンドポイントタイプを「プライベート」に設定。

VPCエンドポイントの作成:

AWSマネジメントコンソールまたはCLIを使用してVPCエンドポイントを作成。

API Gatewayのエンドポイントサービスを選択。

リソースポリシーの追加:

特定のVPCまたはサブネットからのアクセスを許可するポリシーを設定。

メリット

APIへのアクセスをVPC内部に限定。

パブリックインターネットを介さないため、セキュリティが向上。

ネイティブな認証機能 (IAM, Cognito) と組み合わせ可能。

3. API認証と認可

すべてのAPIリクエストを認証されたユーザーに限定するため、以下のAWS認証メカニズムを活用します：

AWS IAM:

ロールやポリシーを使用してアクセス制御。

APIキーや署名付きリクエストでセキュアに管理。

Amazon Cognito:

ユーザープールで認証を管理。

アクセストークンをAPI Gatewayに渡して認証を実施。

リソースポリシー:

特定のVPCやIPアドレス範囲にアクセスを制限。

JSON形式で柔軟なポリシーを設定可能。

4. トラブルシューティングとベストプラクティス

ネットワーク接続の確認:

VPCエンドポイントとサブネットのルーティング設定を適切に構成。

モニタリングとログ記録:

CloudWatch Logsを有効化して、APIリクエストの詳細を確認。
AWS X-Rayを使用して、APIのパフォーマンスやエラーの分析を行う。

セキュリティの強化:

必要最低限のアクセス許可を付与（最小権限の原則）。
SSL/TLSを必ず有効化。

まとめ

AWS API GatewayのプライベートエンドポイントとVPCエンドポイントを組み合わせることで、APIを完全にセキュアかつ内部専用に設計することが可能です。これにより、外部からの不要なアクセスを排除しつつ、認証されたユーザーによる利用を確実に管理できます。このアプローチは、セキュリティと効率性を両立させたい場合に非常に有効です。

実践

略

一問道場

質問 #142

トピック 1

ある会社が、Regionalエンドポイントを使用したAmazon API GatewayでAPIを開発しました。これらのAPIは、API Gatewayの認証メカニズムを使用するAWS Lambda関数を呼び出します。デザインレビューの結果、いくつかのAPIがパブリックアクセスを必要としないことが判明しました。ソリューションアーキテクトは、これらのAPIをVPC内からのみアクセス可能にするソリューションを設計する必要があります。すべてのAPIは、認証されたユーザーによって呼び出される必要があります。

最小限の労力でこの要件を満たすソリューションはどれですか？

A. 内部のApplication Load Balancer (ALB) を作成します。ターゲットグループを作成し、呼び出すLambda関数を選択します。ALBのDNS名を使用してVPCからAPIを呼び出します。

B. API GatewayのAPIに関連付けられたDNSエントリを削除します。Amazon Route 53でホストゾーンを作成し、ホストゾーン内にCNAMEレコードを作成します。API GatewayのAPIをCNAMEレコードで更新し、VPC内からこのCNAMEレコードを使用してAPIを呼び出します。

C. API GatewayでAPIエンドポイントをRegionalからプライベートに更新します。VPC内にインターフェイスVPCエンドポイントを作成します。リソースポリシーを作成し、それをAPIにアタッチします。このVPCエンドポイントを使用して、VPC内からAPIを呼び出します。

D. Lambda関数をVPC内にデプロイします。EC2インスタンスをプロビジョニングし、Apacheサーバーをインストールします。このApacheサーバーからLambda関数を呼び出します。EC2インスタンスの内部CNAMEレコードを使用して、VPC内からAPIを呼び出します。

解説

正解: C

理由:

このシナリオでは、API GatewayのAPIをVPC内からのみアクセス可能にし、認証されたユーザーによる呼び出しを確保する必要があります。以下は選択肢の評価です。

選択肢 A: ALBを使用した方法

手順: 内部のApplication Load Balancer (ALB)を作成し、ターゲットグループとしてLambda関数を指定。ALBのDNS名を使用してAPIを呼び出す。

問題点: ALBをLambda関数のフロントエンドとして動作させるには、設定が複雑で追加のコストが発生する可能性があります。また、API Gatewayの機能を活用せず、APIの認証を簡単に処理することが難しくなります。

労力: 高い。LambdaとALBの統合設定が必要。

選択肢 B: Route 53を使用した方法

手順: API GatewayのDNSエントリを削除し、Route 53でCNAMEレコードを作成してAPIを呼び出す。

問題点: APIをVPC内部専用にすることはできません。この方法では、DNSレコードをVPC内でのみ利用可能にする機能がなく、APIのパブリックアクセス制限が不十分です。

労力: 中程度。

選択肢 C: プライベートエンドポイントを使用した方法 (正解)

手順: API GatewayのエンドポイントをRegionalからプライベートに更新し、VPCエンドポイントを作成してAPIにアクセス。認証やリソースポリシーで制限を追加。

利点:

API Gatewayのネイティブな機能（認証やスケーラビリティ）を活用可能。
プライベートエンドポイントを使用することで、APIへのアクセスをVPC内部に制限可能。
効率的かつ設定が比較的簡単。

労力: 最小限。API Gatewayの設定変更とVPCエンドポイントの作成のみ。

選択肢 D: EC2インスタンスを使用した方法

手順: Lambda関数をVPC内にデプロイし、EC2インスタンスから呼び出してAPIを構築。

問題点: EC2インスタンスの管理やApacheの設定が必要で、インフラストラクチャが複雑化する。また、API Gatewayの機能を十分に活用できない。

労力: 非常に高い。

結論

選択肢 C は、要件を満たすための最も簡潔かつ効果的なソリューションです。プライベートエンドポイントとリソースポリシーを使用することで、VPC内部からのみアクセス可能なAPIを簡単に設定できます。また、API Gatewayの認証機能もそのまま利用可能です。