オンプレミスからプライベートなAPI Gatewayを呼ぶ ― CognitoのTokenエンドポイントをAPI Gatewayでプロキシする構成

皆さんは、社内の古いシステムと、クラウドにある新しいシステムを連携させる必要に迫られたことはありますか？例えば、長年使っている社内データベースから、AWS（Amazon Web Services）というクラウドサービスにある機能を使いたい、といったケースです。

今回ご紹介するQiitaの記事は、まさにそんな「社内システムからクラウドのAPIを安全に呼び出す」ための具体的な方法を解説したものです。特に、AWSの認証サービスである「Cognito（コグニト）」の機能を使って、API Gateway（APIの入り口を管理するサービス）で認証を代行させるという、ちょっと高度なテクニックが紹介されています。

記事を書いたのは、BIPROGY / ユニアデックス社の社内AWSコミュニティ「BIPROGY AWS SPARK」の皆さん。普段からAWSを使いこなしているエンジニアの方々が、その知見を共有してくれる企画なんですね。

なぜ、このような構成が必要なのでしょうか？

社内システムから直接、AWSのサービスを呼び出そうとすると、セキュリティ上の問題が出てくることがあります。例えば、AWSのサービスを使うためには「認証」という、本人確認のような手続きが必要なのですが、これを社内システム側で直接行うのは、管理が大変だったり、セキュリティリスクを高めたりする可能性があります。かといって、認証情報を社内システムに持たせるのも避けたい。

そこで登場するのが、今回の主役である「API Gateway」と「Cognito」の組み合わせです。API Gatewayは、外部からのAPIリクエストを受け付ける窓口のようなもの。ここにCognitoという「認証の専門家」に「この人はちゃんと本人ですか？」と確認してもらう機能を連携させます。そうすると、社内システムはAPI Gatewayにリクエストを送るだけでよくなり、面倒な認証処理を直接行う必要がなくなります。API Gatewayが、Cognitoに確認を取り、OKが出たら、本来のAWSサービスへリクエストを渡してくれる、という流れです。

まるで、会社の受付係さんが、社外からのお客さん（社内システム）の身元を確認し、OKなら担当部署（AWSサービス）につないでくれるようなイメージでしょうか。

この構成のメリットは、何と言ってもセキュリティの向上です。認証の仕組みをAWS側でしっかり管理できるので、社内システム側での情報漏洩リスクを減らせます。また、社内システム側は「API Gatewayにリクエストを送る」というシンプルな処理に集中できるため、開発や運用の手間も省けるという利点もあります。

この記事は、社内システムとクラウドサービスを連携させたいと考えているエンジニアの方々はもちろん、ITインフラのセキュリティや効率化に関心のある方にも、ぜひ読んでいただきたい内容と言えるでしょう。現場のエンジニアならではの、実践的なノウハウが詰まっています。