Upgrade to Pro — share decks privately, control downloads, hide ads and more …

漏洩しても大丈夫なクレデンシャル運用ができないか考えてみた.pdf

umihico
March 14, 2022

 漏洩しても大丈夫なクレデンシャル運用ができないか考えてみた.pdf

umihico

March 14, 2022
Tweet

Transcript

  1. MFA AssumeRole AWS Vault awslabs/ git-secrets IPアドレス制限 Githubへpush ◦ ◦

    × ◦ ◦ ~/.aws/credentials ~/.aws/cli/cache リークされる × × ◦ × ◦ 環境変数を リークされる ◦ ◦ × × ◦ リーク先のリモートから ではなく端末上で叩か れる × × × × × やらかし防衛策を並べてみたらIP制限したくなった
  2. 1. 未許可の IP からでも許可申請を受け付けるには a. 踏み台っぽい IAM user を作る b.

    IP 制限だけ書き換えれる最低限の権限を持たせる c. 踏み台ユーザーは MFA 必須、かつキャッシュしないように漏洩対策をす る 2. 複数 IP でも利用できるようにするには a. 申請日時を管理して、一定期間ずつ IP を貯める必要がある b. 同時更新されても整合性を守りたい 利用技術 - DynamoDB - TTL (Time To Live) - Iam - Permission Boundary 可変IP、複数IPでも使える基盤を考えてみる
  3. これはつまり IAM のポリシーである JSON を書き換えること ( iam:CreatePolicy, iam:PutRolePolicy, iam:PutUserPolicy 等)

    JSON を書き換える権限であるため、「 IP リストだけ書き換える権限」という ものは作成が不可 →うっかり許可すると Action, Resource も含めた JSON 全体を編集でき、 踏み台ユーザーがメインユーザーの権限エスカレーションを実行できて しまう 安全性を高めるどころか、とんでもない脆弱性を持たせるところだった 編集権限は Permission Boundary の JSON とし、エスカレーションリスク無 く権限を「絞る」ことができて無事に解決 IAMの権限を書き換える権限(メタ権限?)の注意