Slide 1

Slide 1 text

SSOもOrganizationもない 利用者IAMの制限をする話 2025/05/26 白"雪姫" a.k.a Yuki Sunaoka

Slide 2

Slide 2 text

自己紹介 ➢ 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

Slide 3

Slide 3 text

• 自己紹介 • IAM Identity Center(旧SSO)とは? • Organizationとは? • SSOもOrganizationも何故無かった の? • IAMで制限する要件 • 本来のあるべき姿 – 依頼元に詳細を聞いてみた • IAMのみで設定した実際の姿 – ポリシー適用順序を理解する – 適用ポリシーを分ける! – 不要な物を拒否する • 実際やってみたら・・・・ お品書き

Slide 4

Slide 4 text

• IAM Identity Center(旧SSO)とは? OktaやEntraID、Googleなどといった「既存のアカウント 管理システムを利用し、AWSを操作する管理サービス。 このサービスを使うことでユーザはアカウント毎の ID管 理、管理者は複数のシステムを一元的なアカウントに統 合できる。 また、AWS Single sign On (SSO) という名称でした。 本登壇では便宜上SSOと呼称します。

Slide 5

Slide 5 text

• AWS Organizationsとは? AWSの複数アカウントを一元的に管理する機能、 OUと呼ばれるグループがあり、 SCPを用いて「アカウントでで きること」を制限できる機能を有する。 他にも利用料の請求先も一箇所にまとめることができる。 ※個人的には毎回「オーガニゼーション」なのか「オルガナイ ゼーション」なのか悩みます。

Slide 6

Slide 6 text

• SSOもOrganizationsも何故無かったの? ある理由から、 今回の環境は、AWS Organizations のメンバーアカウント。 SSO(ア カウントインスタンス含む )やSCPといった機能は利用不可な状態に なっています。

Slide 7

Slide 7 text

困ったことにこんな依頼を受けました。 IAMで制限する要件 ● VPC上で起動してるEC2はIAMアクセスキーとシークレットアクセ ス経由(SSMもしくはHelper)で許可端末ならどこからでも接続 し たいなー。 ● マネジメントコンソールは操作性高いから IP制限して、ログイン 出来ても、操作できないよう にしたいなー ● AWS CLIはどこからでも実行したい なー。

Slide 8

Slide 8 text

ちょっとまって・・?

Slide 9

Slide 9 text

一般的には 
 - SCPでアカウント事にできることを制御 
 - SSOでログインしたユーザごとに制御 
 を行って、許可できることに対して規制をする 
 
 なのですが・・・・? 
 本来のあるべき姿 AWSアカウント SCP SSOに紐付く IAMポリシー 許可

Slide 10

Slide 10 text

依頼元に詳細を聞いてみた ● 許可端末ならどこからでも接続 ○ 端末とユーザが紐付いていて MDMが導入されているため許可端末での接続は許可したい ● IP制限して、ログイン出来ても、操作できないようにする ○ 勝手に削除をしたり停止をした入りする人が居て、本番と検証環境が同梱しているため、すぐに対 処出来る時間帯かつ、会社の IPからだけ許可したい ● AWS CLIはどこからでも実行したい ○ AWS CLI(アクセスキーとシークレットアクセス )を用いた場合は何でも実施して良いことにしたい。 (但し導入可能なのは MDM導入された端末や会社貸与端末に限る )

Slide 11

Slide 11 text

IAMのみで設定した実際の姿 細かくポリシー分けて,必要な 物を許可するだけじゃダメだ なぁ。 ● 利用しているサービスの削除を 拒否するポリシー ● 利用しているサービスで操作可能を許可するポリシー ● 特定IP以外から特定操作があった場合許可をするポリシー

Slide 12

Slide 12 text

ポリシー適用順序を理解する 明示的拒否ポリシー 条件付きの拒否ポリシー 条件付き許可ポリシー 許可ポリシー 公式ドキュメントをわかりやすく書くと下記の様になる https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html より 強 弱

Slide 13

Slide 13 text

適用ポリシーを分ける! 色々適用をしたり,拒否と許可を一緒のポリシーに書いたらうまく動 かず,最終的には以下の様にポリシーを分割しました。 • 利用しているサービスの削除を 拒否するポリシー • 特定操作を実施を指定した IPアドレス以外からの場合は,拒否 するための「条件付き拒否ポリシー 」 • 実際やることが判明している 許可ポリシー

Slide 14

Slide 14 text

不要な物を拒否する 「必要の無い操作」を拒否するポリシーを,作成しまし た。 サンプルは右のような感じ AWS CLIを許可している関係上,不要な物も拒否して おかないと,管理者のアクセスキーなどが漏れたと時 に,何でも操作できてしまうと言う観点から追加した物 です。

Slide 15

Slide 15 text

まとめ 一般的に許可する物だけを記載 と言う手段では無く「明示的な拒否」を導入することで, 確実に操作制限を入れることができます。 許可A 拒否A 条件付き 拒否B この部分だけ許可 される

Slide 16

Slide 16 text

実際やってみたら・・・・ ● 純粋に許可だけの方がポリシーは 書きやすい(必要な許可を入れるだ けで済む) ● 覚えておくことで,何らかで使えない ときに制限する手段となり得る ● 拒否ポリシーは書き方がややこしい ○ 拒否の許可なんて言葉になる くらい ● 余談 ○ 実は書いた制御以外で後から リージョン制限もと言われたの で分割してて良かったなと思っ てます。

Slide 17

Slide 17 text

同じ様にこんな感じに作って対応しました 部分的に抜粋 "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" ]

Slide 18

Slide 18 text

ご静聴ありがとうございました