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

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

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for umihico umihico
March 14, 2022

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

Avatar for umihico

umihico

March 14, 2022
Tweet

Other Decks in Programming

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の権限を書き換える権限(メタ権限?)の注意