はじめに
カミナシの認証認可チームのmanaty（@manaty226）です。今年もラスベガスにて12月1日から12月5日まで開催されているre:Inventに参加しています。この記事では、3日目に参加した以下のワークショップセッションについて記載します。
- [NEW LAUNCH] Authenticate securely beyond AWS identity with JSON Web Tokens [REPEAT] (SEC352-R1)
AWSにおける長寿命クレデンシャルのこれまで
セッションの冒頭では、AWSにおける長寿命なクレデンシャル（アクセスキーなど）を、これまでにどのように改善してきたか話されました。2006年当初はルートユーザーしか存在せず、ルートユーザーのアクセスキーはアカウントの全権限を持つ長寿命なクレデンシャルでした。今考えると恐ろしい状態ですね。2011年にIAMユーザーの概念が登場したことで、ユーザーの権限を絞ることができるようになりましたが、依然として長寿命なアクセスキーしか利用できない状況が続きます。2012年にはIAMロールが登場し、短寿命なトークンを作れるようになったことで長寿命なアクセスキーの利用比率が低下していき、その後はIAMロールを最も推奨する権限の与え方としながらサービス固有のクレデンシャルなども作られてきました。
このように、AWS内部の呼び出しについては長寿命なアクセスキーを廃止していくための取り組みが長年されてきた一方で、AWSから外部サービスへの呼び出しには長寿命なクレデンシャルしか利用できなかったのが、今回のサービスの背景にある課題のようです。
ここでいう外部サービスに接続するための長寿命なクレデンシャルとは、例えばOAuthクライアントシークレットであったり、APIキーのようなものです。また、Active Directoryや独自の認証方式を作り込んでAWSと統合を図る顧客もいたようですが、複雑化してしまうことが問題でした。
IAM Outbound Identity Federationの仕組み
上述した外部サービスへの呼び出しに係るセキュリティ課題に対応するために作られたのが、最近発表されたIAM Outbound Identity Federationです。
下図に大まかな概念を示します。ここでは、Outbound Identity Federationを管理するAWS IAMと、Outbound Identity Federationのトークン生成をするIssuer、トークン発行要求するユーザー、および外部連携するサービスがいます。トークンの発行要求元はユーザーでなくてもよく、実際のユースケースではEC2やその他のコンピューティングリソースであることが多いと思います。
まず、この機能を利用するためには以下のようなコマンドでOutbound Identity Federationを有効化する必要があります。
aws iam enable-outbound-web-identity-federation
有効化されると、アカウントに1つOutbound Identity FederationのIssuerが作成されます。Issuerの識別子は https://<アカウントごとの識別子>.tokens.sts.global.api.aws という形式です。アカウントの識別子はアカウントIDでなく、UUIDv4に見えました。これはセッション中もなぜアカウントIDでないのか質問がありましたが、アカウントIDを公開URLに含めることで外部から攻撃されやすくなる可能性を避けるためのようです。アカウントごとにIssuerが異なるのは、例えば多数のトークンを発行するアカウントが他のアカウントの性能に影響しないようにするノイジーネイバー問題への対処や、あるアカウントが侵害された場合に他のアカウントへ影響を及ぼすことなくIssuer自体をシャットダウンするための考慮だと思います。
Issuerが作成されたらトークンを生成する準備は完了です。以下のようなコマンドで、アクセストークンを生成できます。下のコマンドは、本セッションのデモで見せていただいたものに基づいています。このセッションではAzureへのアクセスをデモしていたので、オーディエンスの指定がapi:AzureADTokenExchangeとなっています。
aws sts get-web-identity-token --audience api:AzureADTokenExchange --signing-algorithm RS256 --region us-east-1
このコマンドによって生成されたアクセストークンがこちらです。
issやjti、iatのような標準クレームの他に、https://sts.amazonaws.com/というカスタムクレームが存在します。ここには、トークンの要求元のアカウントIDなどのメタデータが含まれます。このカスタムクレームにふくむ情報はトークン発行要求コマンドのオプションで追加することができるようですので、外部サービスに連携したい情報を追加することもできます。一方で、このカスタムクレームをオプトアウトすることはできないようです。ある聴講者は、AWSを使ってサービスを提供しているが、どのアカウントを使っているか顧客に知られたくないのでオプトアウトできるようにしてほしいという要望を話しており、発表者もロードマップとして対応していくことを検討しているようでした。
このように取得したアクセストークンは、Entra IDに対してRFC 8693 Token Exchangeのプロトコルに従ってAWSのトークンからEntra IDのトークンへと変換することができます。これにより、短寿命なクレデンシャルであるアクセストークンを使ってAWSから外部サービスへと連携することができました。アクセストークンの有効期限はSCPなどを使って制限することで組織的に管理しやすくなっています。
おわりに
このセッションではAWSから外部サービスへ連携する際に利用できるIAM Outbound Ideneity Federationについて学びました。まだ出たばかりの機能のため、開発者もユースケースや機能に対する要望を積極的に収集したがっているようです。OAuth mTLSやDPoPなどの送信者制約付きトークンは発行できないのか質問したところ、そうした要求は他からも聞いているのでもっとユースケースを集めて検討したいとのことでした。
カミナシでは、もうすぐレギュレーション落ちする短寿命なデッキでも果敢に使うソフトウェアエンジニアも募集しています。ご興味がある方はカジュアル面談からお願いします。
