はじめに

こんにちは、クラウド事業部のおほりです。

AWS のリソースに対するほとんどの操作は、各サービスの RESTful API (以下API) に対してリクエストを送信することで実行されます。もちろん世界中の誰もが自由にリソースを操作できてしまっては困りますので、何らかの認証(=そのユーザーが当本人であることの確認)を行った上で操作を認可しています。

今回はその認証の仕組みとして採用されている AWS Signature Version 4 (以下Sigv4) について簡単にご紹介します。

はじめに
AWSのセキュリティ認証情報
Sigv4 署名
おわりに

AWSのセキュリティ認証情報

原状、世界で最も普及している認証方法は

ID
パスワード

の組み合わせで本人確認をするパスワード認証でしょう。この ID とパスワードのことを認証情報(credentials)と呼びます。そして AWS における認証情報といえば以下の3つです。

Access Key ID
- 例: AKIAIOSFODNN7EXAMPLE
Secret Access Key
- 例: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Session Token
- 例: AQoDYXdzEJr...(ずっと続く)

Access Key ID と Secret Access Key は ID とパスワードのようなものです。 Session Token は一時的な認証情報を利用する際に登場します。

AWSには長期間有効(long-term)な認証情報と、その強化版である一時的(short-term, temporary)な認証情報があります。

長期間有効な認証情報: Access Key ID + Secret Access Key

一時的な認証情報: Access Key ID + Secret Access Key + Session Token

Access Key ID と Secret Access Key は自ら更新しない限り使い続けることができます。
一方でSession Token は数分~数時間の間(セッション)だけ有効な寿命の短い認証情報で、時間的に最小な権限とすることでより安全なアクセスを実現します。

(ゼロトラスト7大原則で言うところの "Evaluate on a Per-Session Basis" です。)

Session Token は AWS Security Token Service (STS) の API にリクエストを送信することで入手できるのですが、その解説は今回割愛します。

Sigv4 署名

上の認証情報はそのままAWSのAPIに送信する...わけではなく、リクエストに署名をするために使われ、その署名の手順(=仕様)は AWS Signeture Version 4 (AWSSigv4) と呼ばれます。もちろん過去には Version 3 や 2 もありました。ここでの登場人物は以下の3名です：

Signing Key: Secret Access Key と、日時・リージョン・サービスの情報を組み合わせたもの
String to Sign: HTTPリクエストとその他情報(access key ID 含)を組み合わせたもの
Sigv4 署名: String to Sign を Signing Key でハッシュしたもの

ユーザーは手元で Sigv4 署名を計算し、AWSへのリクエストメッセージに付与します。 AWS側では送られてきたリクエストを見て同じ方法で署名を計算をし、両方の署名が一致すればリクエストが改ざんされていない、本人のものであることが確認できますので、そのリクエストを受け入れます。(そのあとは IAM による認可の確認が走ります)

普段私たちはこの AWSSigv4 を意識することはありませんが、AWS コンソールや AWS CLI、各種 SDK(boto3等) にはこの機能が組み込まれていますし、最近では curl コマンドでも標準採用された身近な仕組みです。 AWS で開発を進めていると署名関連のトラブルが発生することもありますので、以下のドキュメントをじっくり読んでより詳細な仕組みを知っておいても損はありません。

docs.aws.amazon.com