こちらは エキサイトホールディングス Advent Calendar 2021 22日目の記事です。
はじめに
オンプレとクラウドのハイブリッド環境でシステムを運用していると、外部アプリケーションからAWSリソースを操作することが多々あります。脳死で「IAMユーザを作って、クレデンシャル情報を生成して・・・」となりがちだったので、どのような認証手段があるのかを整理しました。
署名バージョン4
IAMユーザのアクセスキー（クレデンシャル情報）を使った認証です。AWS SDKを使えばアプリケーション側も手っ取り早く実装できるので、使っている方も多いはずです。
Signing AWS API requests - AWS Identity and Access Management
が、有効期限の長いクレデンシャル情報を使うことになるので、キー漏洩による不正利用などが問題になりがちです。そのため、クレデンシャル情報のローテーションなどを考える必要があったりします。
セキュリティは軽視できませんし、なるべくならクレデンシャル情報の保存は避けたいところです。
SAML・OpenID Connector
使い回せるような半永続的なクレデンシャル情報ではなく、一時的に都度作成されるものであればリスクを低減できそうです。そこでSAMLやOpenID Connector（OIDC）の出番です。GitHub ActionsがOIDCをサポートしたのは記憶に新しいですね。おかげでIAMユーザを作成せずとも、GitHub ActionsのワークフローからAWSリソースを操作できるようになったわけです。
Configuring OpenID Connect in Amazon Web Services - GitHub Docs
大体はこれで解決できそうですが、IdPがSAMLやOIDCに対応していなかったり、そもそもIdPが存在しない場合には新たに構築が必要になります。当然のことながら、SAMLやOIDCの認証プロセスの実装や運用も必要なので、一から作っていくのは骨が折れそうです。
MutualTLS
その他にも、MutualTLS（mTLS）が使えると思います。相互TLS認証とかクライアント認証などとも呼ばれていますね。AWSではAPI GatewayやAWS IoT CoreなどでmTLSを設定できます。古くからある認証手段ですので、アプリケーション側も容易に実装できます。
Configuring mutual TLS authentication for an HTTP API - Amazon API Gateway
Client authentication - AWS IoT Core
ただし、証明書のライフサイクル管理が必須、という課題は残ります。また、API GWでは証明書が失効したかどうかについては検証しない*1ため、別途Lambdaオーソライザーなどを挟む必要があります。
おわりに
どれもメリット・デメリットがあります。
| 手法 | メリット | デメリット |
|---|---|---|
| 署名バージョン4 | 手軽に実装できる | クレデンシャル情報が漏洩したときのリスクが大きい |
| SAML / OIDC | 一時的なクレデンシャル情報を用いるのでセキュリティ的に安心 | SAMLアサーションやアクセストークンのライフサイクル管理、IdPの管理などが必須 |
| MutualTLS | レガシーなシステムでも実装が比較的容易 | 証明書のライフサイクル管理が手間になる |
今回に限った話ではないですが、アプリケーションとの相性やビジネス的な優先度などから使い分けていけると良いかなと思います。
エキサイトではエンジニアを募集しています。募集情報は以下から。
