Seu Dev Notes

AWS のアクセス制御と監査の判断基準(IAM / SCP / KMS / CloudTrail)

一言まとめ

認可は「明示的 Deny > 明示的 Allow > 暗黙の Deny」。組織全体の禁止は SCP、委譲先の上限は Permissions Boundary、経路や IP は Condition。KMS は封筒暗号化と鍵ポリシー、CloudTrail は管理 / データイベントの区別とログ整合性検証が要点。

作成 · 更新 · #aws#iam#kms#cloudtrail#soa-c03
目次 9 sections
  1. 01 認可評価のルール
  2. 02 制御手段の使い分け
  3. 監査に使うツール
  4. 03 KMS(保管時の暗号化)
  5. 封筒暗号化と GenerateDataKey
  6. 暗号化 AMI で Auto Scaling の起動が失敗する
  7. 04 ACM(転送中の暗号化)
  8. 05 Secrets Manager と Parameter Store の SecureString
  9. 06 CloudTrail(API 操作の監査)
  10. 管理イベントとデータイベント
  11. ログファイルの整合性検証
  12. AWS Config との分担
  13. 07 RAM(Resource Access Manager)によるリソース共有
  14. VPC サブネット共有の権限境界
  15. 08 関連
  16. 09 更新履歴

調査時点: 2026-07。料金は当時の値。

IAM は AWS の利用者やロールの権限を管理する仕組み、KMS は暗号鍵の管理サービス、CloudTrail は AWS 上の操作履歴を記録するサービス。SCP は AWS Organizations でアカウント群に上限を課すポリシー。

認可評価のルール#

許可される操作 = (IAM 等による明示的な許可) − (SCP 等による明示的な拒否)。これから 2 つの原則が出る。

  • 明示的 Deny が最優先。メンバーアカウントに AdministratorAccess が付いていても、SCP で rds:DeleteDBInstance が Deny なら、そのアカウントの全ユーザー(ルートユーザー含む)が実行できない
  • 許可が書かれていない操作は暗黙の Deny。SCP のデフォルトは FullAWSAccess で、これを外してホワイトリスト型にすると明示的に許可した操作以外がすべて止まる

SCP は管理アカウント(マスターアカウント)のユーザー・ロールには適用されない。適用対象はメンバーアカウントのみ。

制御手段の使い分け#

実現したいこと使う機能性質
ルートユーザーや管理者を含む組織全体の禁止事項SCP(サービスコントロールポリシー)API 実行そのものを拒否する予防的統制
開発者に IAM 操作を委譲しつつ、作成する子ロールの最大権限を制限(特権昇格防止)Permissions Boundary(アクセス権限の境界)委譲先が作るロールの上限
特定 IP・時間帯・経路からのアクセスのみ許可各ポリシーの Condition(aws:SourceIp など)文脈による絞り込み
作られた後のリソース構成の違反を検知・是正AWS Config + SSM Automation発見的・事後。EventBridge と自動修復
1 バケットを複数部門で共有し、ポリシーを分割したいS3 Access Pointsグループごとに専用のアクセスポイントとポリシー。バケットポリシーのサイズ上限(20KB)と複雑化を回避

S3 の暗号化を強制する条件キーは対象で変わる。オブジェクト単位のアップロード時ヘッダー検証は s3:PutObject への制限、バケットのデフォルト暗号化設定の変更は s3:PutBucketEncryption への制限。

監査に使うツール#

  • IAM Access Analyzer: 意図しない外部共有の特定
  • Policy Simulator: 権限のテスト
  • Trusted Advisor: ベストプラクティス準拠のチェック
  • 「WAF / Shield / Network Firewall が適用されているか」を定期的・自動的に確認する構成も監査の一部

KMS(保管時の暗号化)#

  • キーポリシー: IAM ポリシーではなく鍵ごとのポリシーで、鍵の管理者と利用者(暗号化・復号)を分離する(職務分掌)
  • 自動キーローテーション: カスタマーマネージドキーは年次で自動ローテーションできる。BYOK で外部からインポートしたキーマテリアルは自動ローテーション非対応
  • クロスリージョンのスナップショットコピーでは、コピー先リージョンの KMS キーで再暗号化される

封筒暗号化と GenerateDataKey#

EBS に書き込むたびに KMS を呼ぶと I/O が遅くなるので、AWS はデータキーを使う。

  1. EC2 / Auto Scaling が KMS に「使い捨てのデータキー」を要求する(kms:GenerateDataKey)
  2. KMS は平文のデータキーと、CMK で暗号化したデータキーを返す
  3. ハイパーバイザーが平文キーをメモリに載せてローカルで高速に暗号化・復号する
  4. 暗号化済みデータキーは EBS のメタデータに保存され、再起動時に kms:Decrypt で平文に戻す

既存の暗号化 EBS を読むだけなら kms:Decrypt で足りるが、スケールアウトで新しいボリュームを作るときは新しいデータキーの発行が要る。GenerateDataKey* とワイルドカードにするのは GenerateDataKeyWithoutPlaintext も許可するため。

暗号化 AMI で Auto Scaling の起動が失敗する#

失敗のフェーズ直す場所必要なアクション
EC2 が起動する前(スケールアウト時)に落ちるKMS キーポリシー(対象は AWSServiceRoleForAutoScaling)kms:Decrypt、kms:GenerateDataKey*、kms:CreateGrant
起動後に OS 内のアプリが動かないIAM インスタンスプロファイルアプリが使う各リソースへの権限

ACM(転送中の暗号化)#

  • ACM のパブリック証明書は秘密鍵をエクスポートできない。EC2 の OS に直接インストールすることはできず、ALB / CloudFront などの統合サービスに関連付ける
  • リージョンサービス(ALB)に使う証明書はそのリージョンの ACM で作る。CloudFront に使う証明書は必ず us-east-1 の ACM で作る(エッジへの配布システムがそこにある)
  • ALB で TLS を終端し、ALB と EC2 間を HTTP にすると、EC2 の CPU 負荷を下げつつ証明書の自動更新を一元化できる

Secrets Manager と Parameter Store の SecureString#

比較Parameter Store(ssm-secure)Secrets Manager(secretsmanager)
本質暗号化された文字列の静的な置き場ライフサイクル管理付きの機密情報
自動ローテーション不可可(Lambda 連携で定期更新)
ランダム生成不可可(CloudFormation から生成可能)
料金標準パラメータは無料当時シークレット 1 つ月 0.40 USD + リクエスト従量
用途頻繁に変わらない API キーDB マスターパスワード、外部サービス認証情報

ローテーション Lambda を閉域 VPC に置く場合の通信要件は 2 つ: Lambda → RDS はセキュリティグループで DB ポート(5432 など)を相互許可、Lambda → Secrets Manager は VPC インターフェイスエンドポイント(PrivateLink)。

CloudTrail(API 操作の監査)#

管理イベントとデータイベント#

比較管理イベントデータイベント
対象コントロールプレーン操作(バケット作成、EC2 起動、IAM ユーザー作成、SG 変更)データプレーン操作(S3 の GetObject / PutObject、Lambda Invoke)
デフォルト有効。1 つ目の証跡への配信は無料無効。明示的な有効化と追加コストが要る
用途誰がインフラ設定を変えたか誰が特定のオブジェクトにアクセスしたか
  • デフォルトの CloudTrail(管理イベントのみ)では、S3 オブジェクト操作をトリガーにした EventBridge 連携は動かない。データイベントの有効化が要る
  • データイベントは量が多いので、高度なイベントセレクター(Advanced Event Selectors)で対象バケットやプレフィックスを絞る
  • Organizations 配下の全アカウント・全リージョンを 1 つの S3 バケットに集約するのが「組織の証跡」。アカウント × リージョンごとに手動で証跡を作らない

ログファイルの整合性検証#

証跡で「ログファイルの検証」を有効にすると、1 時間ごとに署名付きダイジェストファイルが生成される。aws cloudtrail verify-logs を実行すれば、特権管理者を含め後から改ざん・削除されていないことを暗号学的に証明できる。サーバーや自作スクリプトは不要。

要件機能
ログが改ざんされていないことの証明CloudTrail ログファイルの検証
ログファイルの物理的な削除を禁止S3 オブジェクトロック(コンプライアンスモード)

VPC フローログはネットワーク層のパケット記録であり、API 操作の整合性検証には使えない。

AWS Config との分担#

CloudTrail は「誰がいつ何を呼んだか」の記録、Config は「リソースが今どういう構成か」の評価と変更履歴のタイムライン。SG の変更履歴を追うなら Config、API 呼び出し元を特定するなら CloudTrail。

RAM(Resource Access Manager)によるリソース共有#

  • 共有してもリソースの所有権は移動しない。共有先(Participant)は利用のみで、作成・削除・設定変更の権限はオーナーに残る
  • 頻出の共有対象: VPC サブネット、Transit Gateway、License Manager のライセンス、Route 53 Resolver ルール
  • Organizations 内への共有は受信側の承認(Accept)が不要で即時反映。組織外への共有は招待を承認するまで使えない

VPC サブネット共有の権限境界#

主体できること
OwnerVPC 全体(ルートテーブル、NAT、IGW)、CIDR、NACL
Participant共有サブネット内で自分のリソース(EC2 / RDS / NLB)を起動・管理し、自アカウントのセキュリティグループを作ってアタッチ
Participant にできないこと他アカウントが同じサブネットに置いたリソースの参照・変更、ルートテーブルや NACL の編集、他アカウントの SG の適用

Participant から「ネットワーク設定を変えたい」と言われたら、まず自分の SG で解決できるか確認し、ルートテーブル / NACL / CIDR が要るなら Owner 側に依頼する。

関連#

更新履歴#

  • 2026-07-18: 初版(ローカル調査ノート)
  • 2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加

同じトピック — AWS