【要約】オンプレミスからプライベートなAPI Gatewayを呼ぶ ― CognitoのTokenエンドポイントをAPI Gatewayでプロキシする構成 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
閉域網に配置されたオンプレミスシステムが、AWS上のプライベートAPIを呼び出す際に認証の壁に直面する。CognitoのM2M認証を利用する場合、以下の課題が生じる。
- ・トークン取得先であるCognitoのTokenエンドポイントがパブリックである。
- ・閉域網のクライアントからは、インターネット経由でしか到達できない当該エンドポイントを呼べない。
- ・CognitoのPrivateLink対応後も、現時点ではM2MのOAuthフローはサポート対象外である。
// Approach
著者は、プライベートAPI GatewayにCognitoへのプロキシ機能を実装することで、通信断絶を解消する。API GatewayがAWS側のネットワークからCognitoへリクエストを代行する仕組みだ。
- ・API Gatewayに
/tokenリソースを作成する。 - ・
/tokenに対し、CognitoのTokenエンドポイントへのHTTP_PROXY統合を設定する。 - ・クライアントはAPI Gateway経由でトークンを取得し、そのトークンを用いてAPIを呼び出す。
- ・セキュリティ強化として、WAFを用いてAPI Gateway経由の通信のみをCognitoへ許可する。
// Result
この構成により、オンプレミス側にインターネット経路を持たず、閉域網のみで認証を完結できる。
- ・Direct ConnectやTransit Gatewayを経由したプライベートな通信経路のみで運用が可能。
- ・WAFによる制御を組み合わせることで、Cognitoエンドポイントへの直接アクセスを遮断できる。
- ・既存の閉域網設計を大きく変更することなく、Cognito認証を導入できる。
Senior Engineer Insight
> 実務上の課題を的確に突いた、極めて実践的な構成である。特にPrivateLinkがM2Mフローをカバーしていない現状において、API Gatewayをプロキシにする判断は合理的だ。運用面では、API Gatewayが単一の通信経路となるため、スループットやレイテンシの監視が重要となる。また、WAFによる「プロキシ経由のみ許可」の制御は、セキュリティの観点から必須の実装と言える。エンタープライズのハイブリッドクラウド環境において、標準的な解決策になり得る。