← AWSサービスの内部原理 コース
65. セキュリティ4つの問いの地図 — 誰か・何をしてよいか・改ざんは・盗み見は
1本のAPIリクエストが AWS に届いてから許可されるまでを縦に追いながら、「誰か」「何をしてよいか」「改ざんは」「盗み見は」という4つの問いに、それぞれどの仕組みが答えているのかを1枚の地図にまとめていきます。
① 4つの問いの地図
署名付きリクエスト送信クライアントから
本人だと分かった
問い1 認証誰か? = SigV4署名
アクセスキーの所持証明この操作は許可
問い2 認可何をしてよいか? = ポリシー評価エンジン
途中で書き換えられていない
問い3 完全性改ざんは? = SHA-256ハッシュ+HMAC署名
実は問い1と同じ署名処理の中で同時に確認される4問すべて通過
問い4 機密性盗み見は? = TLS / KMS
経路はTLS、保存時は封筒暗号+HSM処理を実行
- 「AWS がリクエストを受け取ると、許可か拒否かを決めるまでにいくつかの段階を踏む」— 最初が Authentication(認証)、次が Processing the request context、そして allow / deny の判定、という順序が公式に定義されている(reference_policies_evaluation-logic)。
- 問い1(認証)と問い3(完全性)は別々の処理ではなく、SigV4 署名という1つの仕組みが同時に両方を満たしている。
セキュリティの「認証・認可・完全性・機密性」という4分類は、そのまま AWS の SigV4・ポリシー評価・ハッシュ+HMAC・TLS/KMS という実装に対応する。マネージドサービスの一見バラバラな機能は、この古典的な地図の上に並べ直せる。
② 認証 — 秘密を送らず証明
シークレットキー絶対にネットワークへ送らない
署名鍵を導出日付→リージョン→サービス→aws4_request
各段の出力が次段の鍵になる署名鍵でHMAC-SHA256
正規リクエスト作成メソッド・パス・ヘッダ・本文ハッシュを決まった形に整形
アクセスキーID+署名だけをAuthorizationヘッダで送る
署名を計算署名 = HMAC-SHA256(署名鍵, 文字列)
署名は一致するか?
AWSが同じ計算を再現届いた内容から署名を再計算して照合
一致 → 本人と認める
不一致 → 拒否
- アルゴリズム識別子は AWS4-HMAC-SHA256。つまり HMAC-SHA256 が署名の中核(reference_sigv-signing-elements の Authentication information)。
- 公式の言い回し: 「You don't use your secret access key to sign API requests. Instead, you use the SigV4 signing process.」秘密鍵そのものは署名に直接使わず、そこから導出した署名鍵を使う(reference_aws-signing)。
- 4段の導出は公式の擬似コードそのまま: DateKey = HMAC-SHA256("AWS4"+シークレット, 日付) → DateRegionKey → DateRegionServiceKey → SigningKey = HMAC-SHA256(…, "aws4_request")(create-signed-request の Derive a signing key)。
- 署名鍵は「日付 / リージョン / サービス / aws4_request」でスコープされる。だから署名は特定リージョン・特定サービス・特定日付でしか通用しない(reference_sigv-signing-elements の Credential scope)。
- AWS 側は「同じ処理を再現して署名を検証し、一致すればアクセスを許可、しなければ拒否する」("AWS then replicates this process and verifies the signature")(reference_aws-signing)。
認証とは「秘密を見せること」ではなく「秘密を持っている証拠を計算して見せること」。SigV4 は秘密鍵を送らずにそれを実現し、AWS は同じ計算を再現して照合するだけで本人確認ができる。
③ 長期キーと短期3点セット
認証に使う資格情報
どちらも
長期アクセスキーアクセスキーID+シークレットの2点
IAMユーザーに紐づく。期限なし(手動で無効化)短期3点セット2点+セッショントークン
STSが動的発行。数分〜数時間で失効、再取得可。ロール・フェデレーションの実体SigV4で署名短期の場合は署名計算にセキュリティトークンも必要
- 一時認証情報は「long-term access key credentials とほぼ同じように動作する」が、(1)短命で「数分から数時間」で失効し失効後は一切のアクセスを拒否、(2)ユーザーに保存されず必要時に動的発行される、という違いがある(id_credentials_temp)。
- 一時認証情報は「roles と identity federation の基礎(basis)」。つまりロールを引き受ける=STS から3点セットを受け取ること(id_credentials_temp)。
- 3点目のセキュリティトークン(セッショントークン)について、署名側の公式記述: 「If you are using temporary security credentials, the signature calculations also require a security token.」(reference_aws-signing の Why requests are signed)。
- EC2 では「起動時にインスタンスへ一時認証情報が供給され、長期の資格情報をインスタンスに保存する必要がない」というのが短期キーの動機(id_credentials_temp の Roles for Amazon EC2)。Lambda の実行ロール credentials が環境変数で渡ってくるのも同じ仕組み(Lambda編で既出)。
「誰か」の答えは、期限なしの長期キー(IAMユーザー)か、STSが動的に配る短期3点セット(ロール・フェデレーション)かの2択。後者はセッショントークンが3点目で、失効するからこそ機械に埋め込んでも安全という発想。
④ 認可 — デフォルト拒否の評価エンジン
リクエスト到着
許可の根拠を探しにいく
暗黙の拒否が出発点デフォルト = implicit deny。何も書かなければ拒否
ない
明示的Denyは?1つでもあれば即・拒否
最優先。Allowを上書きyes
SCP/RCPでAllow?組織の上限。no → 拒否
Organizations未使用なら素通りyes
ID/リソースでAllow?アイデンティティ / リソースベースのポリシー。no → 拒否
yes
境界の内側?アクセス許可境界(permissions boundary)。no → 拒否
yes
セッションポリシーは?許されていなければ拒否
許可
- 公式の3原則: 「By default, all requests are implicitly denied」(ただしアカウントのルートユーザーだけは例外でフルアクセス)、「Requests must be explicitly allowed by a policy(...)」「An explicit deny overrides an explicit allow.」(reference_policies_evaluation-logic_policy-eval-denyallow)。
- 評価は最初に全ポリシー横断で Deny を探す。「If the enforcement code finds even one explicit deny that applies, (...) returns a final decision of Deny.」明示的 Deny は1つでもあれば即拒否で、他を見ない(同上)。
- この図は簡略版。公式の評価順は Deny評価 → RCP → SCP → リソースベース → アイデンティティベース → 境界 → セッションポリシーで、リソースベースポリシーがセッション主体などに直接許可した場合は、境界・セッションポリシーの暗黙拒否を飛び越えて最終 Allow になる例外がある(同上の Resource-based policies)。
認可は「許可リスト」ではなく「デフォルト拒否+明示Deny最優先」という順序つきの評価。まず拒否から始まり、明示的なDenyは何より強く、それ以外は各段の許可をすべて通過して初めて許可になる。
⑤ 与える和と上限の積
アイデンティティベース権限を「与える」
リソースベース権限を「与える」
すべての上限の内側なら = intersection(積)
SCP / RCP組織の上限
アクセス許可境界ユーザー単位の上限
セッションポリシーセッションの上限
実効権限与える和のうち、上限の積の内側だけが残る
- 和(union): 同一アカウントで「アイデンティティベースとリソースベースの許可の union をとる。どちらか一方、または両方が Allow なら AWS は許可する」(reference_policies_evaluation-logic)。
- 積(intersection): アクセス許可境界は「2つの category の intersection」。SCP/RCP は「ユーザーのポリシー・SCP・RCP の intersection で、3種すべてが Allow でなければならない」(公式の前提はリソースベースポリシー未設定のリソースへのアクセス時)(同上)。
- どの category でも「An explicit deny (...) overrides the allow.」明示Denyは和にも積にも優先(同上)。
権限は「与えるポリシーの和」から「上限を切るポリシーの積」を通した残りが実効権限。許可を足しても、どこかの上限(境界・SCP・セッション)で削られればアクセスできない。
⑥ 完全性・機密性とCS基礎部品
問い3 完全性正規リクエストのSHA-256ハッシュ+HMAC署名で改ざん検知
タイムスタンプでリプレイ防止(原則、タイムスタンプから5分以内)問い4 機密性経路=TLS / 保存=封筒暗号+HSM(KMS)
API Gateway編のTLS終端とS3編のSSEの再登場ハッシュ=指紋一方向。中身が1bit変われば別物(SHA-256)
HMAC=鍵付き指紋鍵を知る者だけが正しい指紋を作れる
対称鍵=速い錠前同じ鍵で施錠・解錠。大量データ向き
鍵階層=金庫鍵を暗号化する鍵。最上位はHSMの中(KMS)
- 完全性: 「some of the request elements are used to calculate a hash (digest) (...) it uses the same information to calculate a hash and matches it (...) If the values don't match, AWS denies the request.」ハッシュ照合で改ざんを検知(reference_aws-signing の Why requests are signed)。
- リプレイ防止: 「In most cases, a request must reach AWS within five minutes of the time stamp」= 原則、タイムスタンプから5分以内に届かない再送は拒否(同上)。日付は「third parties が傍受して後で再送するのを防ぐ」目的でもある(reference_sigv-signing-elements の Date)。
- 封筒暗号: KMS の root key(最上位鍵)が data key を守り、data key が実データを守る階層。「you must protect the highest level encryption key (root key) (...) That's where AWS KMS comes in.」(kms overview)。
- HSM: KMS キーは「FIPS 140-3 Security Level 3 validated hardware security modules (HSM) に保護され、平文では KMS の外に出ない」("They never leave AWS KMS unencrypted.")(同上)。
- KMS は認可の入口が特別: ④⑤の一般ルール(アイデンティティかリソースどちらかの Allow で可)の例外として、KMS キーポリシーは「must explicitly allow access for principals」— キーポリシー側の明示的な Allow が必須で、キーポリシーが主(同種の例外は IAM ロールの信頼ポリシーにもある)(reference_policies_evaluation-logic_policy-eval-denyallow の Resource-based policies)。
完全性は署名時のハッシュ照合とタイムスタンプ、機密性はTLS(経路)とKMSの封筒暗号+HSM(保存)が守る。ハッシュ=指紋、HMAC=鍵付き指紋、対称鍵=速い錠前、鍵階層=金庫、という対応で見れば、AWSのセキュリティは既習のCS基礎部品の組み合わせに還元できる。