250226_SecurityJAWS

20250226のSecurityJAWS登壇の資料になります！！

Transcript

1. SSOもOrganizationもない 利用者IAMの制限をする話 2025/05/26 白"雪姫" a.k.a Yuki Sunaoka
2. 自己紹介 ➢ Name ◦ 白”雪姫”（Shirayuki) a.k.a YUKI SUNAOKA ➢ Company ◦ （色々お騒がせしてる）株式会社ゆめみ ➢ Jobs ◦ SRE and Security Engineer ➢ Certificate ◦ CLF/SAA/SAPro/ANS/SCS ➢ Join Community others ◦ JAWS-UG クラウド女子会運営 ◦ AWS Community Builders 2025 ▪ Category：Security ◦ AWS Global Community Gathering運営 ➢ X/Qiita ID ◦ yuri_snowwhite ➢ Like AWS Service ◦ AWS Inspector
3. • 自己紹介 • IAM Identity Center(旧SSO)とは？ • Organizationとは？ • SSOもOrganizationも何故無かった の？ • IAMで制限する要件 • 本来のあるべき姿 – 依頼元に詳細を聞いてみた • IAMのみで設定した実際の姿 – ポリシー適用順序を理解する – 適用ポリシーを分ける！ – 不要な物を拒否する • 実際やってみたら・・・・ お品書き
4. • IAM Identity Center(旧SSO)とは？ OktaやEntraID、Googleなどといった「既存のアカウント 管理システムを利用し、AWSを操作する管理サービス。 このサービスを使うことでユーザはアカウント毎の ID管 理、管理者は複数のシステムを一元的なアカウントに統 合できる。 また、AWS Single sign On (SSO) という名称でした。 本登壇では便宜上SSOと呼称します。
5. • AWS Organizationsとは？ AWSの複数アカウントを一元的に管理する機能、 OUと呼ばれるグループがあり、 SCPを用いて「アカウントでで きること」を制限できる機能を有する。 他にも利用料の請求先も一箇所にまとめることができる。 ※個人的には毎回「オーガニゼーション」なのか「オルガナイ ゼーション」なのか悩みます。
6. • SSOもOrganizationsも何故無かったの？ ある理由から、 今回の環境は、AWS Organizations のメンバーアカウント。 SSO(ア カウントインスタンス含む )やSCPといった機能は利用不可な状態に なっています。
7. 困ったことにこんな依頼を受けました。 IAMで制限する要件 • VPC上で起動してるEC2はIAMアクセスキーとシークレットアクセ ス経由(SSMもしくはHelper)で許可端末ならどこからでも接続 し たいなー。 • マネジメントコンソールは操作性高いから IP制限して、ログイン 出来ても、操作できないよう にしたいなー • AWS CLIはどこからでも実行したい なー。
8. ちょっとまって・・？
9. 一般的には 
 - SCPでアカウント事にできることを制御 
 - SSOでログインしたユーザごとに制御 
 を行って、許可できることに対して規制をする 
 
 なのですが・・・・？ 
 本来のあるべき姿 AWSアカウント SCP SSOに紐付く IAMポリシー 許可
10. 依頼元に詳細を聞いてみた • 許可端末ならどこからでも接続 ◦ 端末とユーザが紐付いていて MDMが導入されているため許可端末での接続は許可したい • IP制限して、ログイン出来ても、操作できないようにする ◦ 勝手に削除をしたり停止をした入りする人が居て、本番と検証環境が同梱しているため、すぐに対 処出来る時間帯かつ、会社の IPからだけ許可したい • AWS CLIはどこからでも実行したい ◦ AWS CLI(アクセスキーとシークレットアクセス )を用いた場合は何でも実施して良いことにしたい。 (但し導入可能なのは MDM導入された端末や会社貸与端末に限る )
11. IAMのみで設定した実際の姿 細かくポリシー分けて，必要な 物を許可するだけじゃダメだ なぁ。 • 利用しているサービスの削除を 拒否するポリシー • 利用しているサービスで操作可能を許可するポリシー • 特定IP以外から特定操作があった場合許可をするポリシー
12. ポリシー適用順序を理解する 明示的拒否ポリシー 条件付きの拒否ポリシー 条件付き許可ポリシー 許可ポリシー 公式ドキュメントをわかりやすく書くと下記の様になる https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html より 強 弱
13. 適用ポリシーを分ける！ 色々適用をしたり，拒否と許可を一緒のポリシーに書いたらうまく動 かず，最終的には以下の様にポリシーを分割しました。 • 利用しているサービスの削除を 拒否するポリシー • 特定操作を実施を指定した IPアドレス以外からの場合は，拒否 するための「条件付き拒否ポリシー 」 • 実際やることが判明している 許可ポリシー
14. 不要な物を拒否する 「必要の無い操作」を拒否するポリシーを，作成しまし た。 サンプルは右のような感じ AWS CLIを許可している関係上，不要な物も拒否して おかないと，管理者のアクセスキーなどが漏れたと時 に，何でも操作できてしまうと言う観点から追加した物 です。
15. まとめ 一般的に許可する物だけを記載 と言う手段では無く「明示的な拒否」を導入することで， 確実に操作制限を入れることができます。 許可A 拒否A 条件付き 拒否B この部分だけ許可 される
16. 実際やってみたら・・・・ • 純粋に許可だけの方がポリシーは 書きやすい（必要な許可を入れるだ けで済む） • 覚えておくことで，何らかで使えない ときに制限する手段となり得る • 拒否ポリシーは書き方がややこしい ◦ 拒否の許可なんて言葉になる くらい • 余談 ◦ 実は書いた制御以外で後から リージョン制限もと言われたの で分割してて良かったなと思っ てます。
17. 同じ様にこんな感じに作って対応しました 部分的に抜粋 "Resource": "*", "Condition": { "StringNotEquals": { "aws:RequestedRegion": [ "us-east-1", "ap-northeast-1", "ap-northeast-3" ] }, "Resource": "*", "Condition": { "IpAddressIfExists": { "aws:SourceIp": "*" }, "NotIpAddress": { "aws:SourceIp": [ "XXX.XXX.XXX.XXX/XX", "XXX.XXX.XXX.XXX/XX" ]
18. ご静聴ありがとうございました