🫶

なーるほどtheワールド：第四章 - 無知はサービスを破壊する「ポリシー編」

に公開
AWS
aws入門
ポリシー
クラウド初心者
なーるほどtheワールド
idea

前章ではIAMについてちゃっぴーと深掘りした。
そこでちらっと姿を表した「ポリシー」
セキュリティのキモ はどうもポリシーにあるようなきがするので、この章ではポリシーについて深掘りしていこうと思う。

🔑「鍵」と💂「門番」

ぼく🧑🏻‍💻「IAMの話で出て来たけど、IAMは印籠って話したけど
もうちょっと本質的な話をすると、『ポリシーこそが印籠』っていうのが正解なのかな？」

ちゃっぴー🐶「お、いいとこ突いてくるね主（しゅ）！
そう、まさに“ポリシーこそが印籠”という表現が本質を突いておる！」

🧑🏻‍💻「なるほど！
じゃあIAMユーザとかIAMロールは“印籠をぶら下げるためのホルダー”みたいな存在で、
印籠の中身、つまり“何ができるのか”を記しているのがポリシーなんだね？」

🐶「その通りじゃ！
IAMユーザもIAMロールも“人格”ではあるけど、
それ自体に力はなくて、印籠（=ポリシー）を持って初めて
『どこまで踏み込めるか』が決まるんじゃ！」

🧑🏻‍💻「鍵ホルダーと鍵の関係で考えると分かりやすいかも。
クソ雑魚株式会社の例でいえば──」

🔑クソ雑魚株式会社：鍵ホルダーの例え

名前 鍵ホルダー 鍵ホルダーの中身（ポリシー） 備考
ぼく🧑🏻‍💻 うんこ色キーホルダー S3:ReadOnlyの鍵が1本だけ（S3部屋には入れる） 貴重品棚は開けられない
ちゃっぴー🐶 ギンギラギンホルダー ありとあらゆる鍵がじゃらじゃら（リソースを操作できるフル権限） ギンギラギンにさりげなく

🧑🏻‍💻「ギンギラギンにさりげなく〜♪（古い）」

🐶「…さすがにそれはツッコまざるを得んかった…！！
主（しゅ）よ、まさかの昭和パワー注入とは…w」

🧑🏻‍💻「でもさ、なーるほどtheワールドのときに、
IAMユーザだけでなく、S3のバケットにもポリシー設定していたよね？」

🔸S3バケットにもポリシー設定してたよね？

🐶「その通り！！！
ポリシーには、大きく分けて 2つのつけどころ があるんよ」

名前 働き 主な用途
人（IAMユーザ・ロール） IAMポリシー：「この人は何をしていいか」を決める 管理者・開発者・サービスなど
モノ（例：S3バケット） リソースポリシー：「このモノに誰がどう触っていいか」を決める S3、SNS、SQSなど

IAMポリシー：そのユーザがどこに入れるかの鍵
バケットポリシー：その場所が、誰を受け入れるか

これを両方で許可しないと、AWS様は
「え？お前、どっちの許可もらってんの？え？ないの？403な😎」
ってやってくるんだよね〜。

🧠つまり結論！

🧑🏻‍💻 がうんこ色の鍵ホルダーに鍵をぶら下げてやって来ても、
その鍵で開けたい部屋（S3バケット）の門番が
「うんこ色？入館お断り」って言ってきたら、入れないのじゃ！！🚪💥

🐶「AWSにおいて“印籠”はIAMユーザやIAMロールだけじゃなく、
リソース（S3バケットやLambda関数など）側にも存在する。
こっちは“リソースベースポリシー”と呼ばれるもんじゃな。」

🧑🏻‍💻「つまり、リソースには“鍵”と“門番”がセットでついていて、
鍵はユーザ側が持っているもので、門番はリソース側が『誰に使わせるか』を判断するってこと？」

🐶「そういうことじゃな！
『鍵持ってるだけじゃ入れんぞ！』っていう、二段構えのセキュリティ体制」

🧑🏻‍💻「セキュリティに対する意識がとんでもなく高いんだね〜。
まさに“クソ雑魚撃退システム”がしっかりしてるんだなw」

🐶「ぎゃはははははは！！！！
「クソ雑魚撃退システム」 ってネーミング、秀逸すぎてAWSの公式に提案したいレベル🤣🤣🤣

ほんとその通りで、AWSは：

🛡️ 「人類のうっかり」と「クソ雑魚暴走」からサービスを守るための最強セキュリティ設計
に命かけとるんよ！！

🔥たとえば…

  • IAMだけでOK？ → NO！
    「鍵は持ってるけど、門番が『お前、誰？』ってブロックする」💂
  • リソース側で公開？ → NO！
    「門番がフリーパスでも、お前が鍵忘れてたら入れん」🔑
  • 両方OK？ → YES！
    「やっと通行許可が出る。さあ、S3オブジェクトを拝め！」📂✨

🐶 だから、AWSは…
🐶「“うっかり設定ミス”という最大のセキュリティホールに“技術で蓋をする”文化圏」なんよな💡

🔑鍵と💂門番は誰が設置する？

🧑🏻‍💻「では、次は『そんな重要な鍵と門番システムを設定できるのはどこの誰なの？』について教えてくだされ！」

🐶「よっしゃ、まかせとけ！
まず、そもそもIAMユーザやロール、ポリシー、バケットポリシーといった仕組みは、
“管理者”だけが作成・編集・アタッチできる。
AWSで言えば、AdministratorAccessのポリシーを持ったIAMユーザ、
もしくはルートユーザだけがそれを許される。」

🧑🏻‍💻「ふーむ。
でもさ、最初は『ルートユーザ』しかいないじゃない？
ルートユーザとしてこの世に誕生してから、目にも止まらぬ早業で
これらのIAMアカウントやロールを作成するってことだよね？」

🐶「YES YES YES！！
ルートユーザはこの世に生を受けた瞬間、
まさに神のごとき全能の存在。
でも、暴れさせておくと危険なので、さっさと“家老（admin IAMユーザ）”を作って、
そのルート姫は城の奥深くに封印してしまうのじゃ！」

🧑🏻‍💻「ルートユーザは姫だから、城の奥に軟禁しとけ！
って、話していたけど
でもさ、“admin権限を持つIAMユーザ”っていうのも、
ある意味“拉致っとけよ”っていうことにならない？」

🐶「正解！
“admin権限を持つIAMユーザ”は、神の代理人みたいなもん。
だから、むやみにログインせず、“基本仕事させない” がベストじゃ。」

🍡admin家老はどらやき食って寝てろ

🧑🏻‍💻「じゃあ、例えばぼくみたいに、『ひとりで開発・ひとりで管理』っていう、
完全ぼっちクソ雑魚環境の場合は、どういうIAM設計をするのがいいの？」

🐶「ふむ、主（しゅ）のような孤高の勇者の場合は──

  1. 最初にルートユーザでログインして、Admin IAMユーザを作る (＝admin家老)
  2. Admin IAMユーザでログインして、開発用IAMユーザを作る（＝普段使い用）
  3. ルート姫にはMFAと強力なパスワードを設定し、ログアウト後は封印！
  4. admin家老は押入れの2段目でどら焼き食って寝ててOK！

という構成にすると、安全かつ快適じゃ。」

🧑🏻‍💻「いま、ルート姫とadmin家老しかいないから（admin家老にdevってつけちまったな）
admin家老でアカウントもう一個作って、そっちをadmin家老にして
IAMユーザ名にdevってついているやつは、本当にdevしかできないやつにしておくか。」

🐶「うむ、そういう運用が望ましいぞ！
　『名前にdevってついてるのに管理権限持ってる』
　これ、数ヶ月後の主（しゅ）がうっかり何かを爆破させるパターンNo.1だからな！！」

✨今やるべき整理プラン

役職 IAMユーザ名（例） 役割 ポリシー
家老（管理者） main-admin 管理全般（金ピカ） AdministratorAccess
現在の家老（誤） dev-admin 開発用・日常作業用（降格予定） PowerUserAccess または 個別ポリシー
姫 AWSルートユーザ 鍵の錠前ごと破壊できる存在 軟禁中（ポリシー変更不可・最強）

✅やる手順（安心Ver）

  • 1.dev-admin でログイン（今の家老）
  • 2.新しく main-admin（名前自由）をIAMユーザで作成
    　→ ポリシー：AdministratorAccess
    　→ MFA必須設定
  • 3.ログアウト → main-adminでログインできるか確認（ログインテスト）
  • 4.成功したら dev-admin を降格
    　→ AdministratorAccess 削除
    　→ PowerUserAccess または限定ポリシーに差し替え

🎯その結果…

  • 家老は名実ともに管理者
  • dev-adminは名前通りの「現場作業員」
  • 将来「おや？このdev-adminって何ができるんだっけ？」と迷わない

🧑🏻‍💻「うーん。じゃあ、『このユーザは本当に開発しかしません』というIAMユーザ(=dev-admin)につけるべきポリシーってどんなもの？」

🧑🏻‍💻「まず、『鍵』が必要なので、これに該当するポリシーが必要だと思うんだけど
問題は『門番』に該当する、リソース側のポリシーの設定はどうするの？
厳密に考えたら『admin家老』がすべきと思うけど、それだと結局はadmin家老が出張ってくることになるよね？
これを回避する方法はある？」

🐶「いい質問じゃな。
基本的には“リソースを作るときに、必要なリソースベースポリシーもセットで作っておく”ことで、
以後の開発ユーザの操作範囲を制限しつつも自由度を持たせられるぞい！」

🐶「一緒に「開発者IAMユーザ設計 × 最小権限 × 管理者非出張化」について爆速でまとめよう！」

💡質問の整理

  • 「このユーザは開発しかしません」 → ポリシーで制限したい
  • 「開発者が操作する対象リソース」には門番（リソースポリシー） が必要
  • でもadmin家老が毎回門番の承認を設定するのは面倒
  • 開発者自身が、自分に必要な門番の承認を得る手段はあるのか？

🧠結論から言うと：
✅ 開発者が使うリソースは「事前に門番を味方につけておく」！！
つまり、S3バケット・Lambdaなどのリソース側に：

"Principal": {
  "AWS": "arn:aws:iam::123456789012:user/dev-user"
}

みたいな形で、開発用IAMユーザを事前登録しておく。

🛡️ 実現方法まとめ

✅ ① 開発者ユーザ側の「鍵（IAMポリシー）」を絞る

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::dev-bucket/*"
    }
  ]
}

※本当に必要な操作（Put/Get/etc）だけに絞る！

✅ ② バケット側の「門番（リソースポリシー）」も設定

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDevUser",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/dev-user"
      },
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::dev-bucket/*"
    }
  ]
}

→ これをadmin家老が最初だけ設定しておけば、
　開発者IAMユーザは以降ずっと使える！

🧑🏻‍💻「おぉ。これでadmin家老も『たすけてぇ〜どら◯も〜ん』って言われない限りは
押入れの2段目でどらやき食いながら寝ていられるね！」

🎖️変身ベルトで強権発動

🧑🏻‍💻「もう一個
『IAMロールを一時的に引き受ける』というのは、具体的にどういう手順を踏むの？」

🐶「これは“スイッチロール”と呼ばれる手法じゃ。
普段は低権限のユーザとして動き、
必要なときだけ一時的に強権限のロールに切り替えるスタイル。

以下がざっくりの流れ：

  1. 管理者が特定のIAMロールを作成（信頼ポリシーもセット）
  2. 開発者に“スイッチ先のロールARN”を共有
  3. 開発者はマネジメントコンソールやCLIでスイッチ操作をする
  4. スイッチ後、一定時間だけ強権限が使える

これを実施することで、ふだんはただのクソ雑魚でも、条件を満たして“変身”すれば金色の印籠パワーを借りられる
──それが AssumeRole（アシューム・ロール）！」

✅ 変身（AssumeRole）に必要なもの

名前 説明
🎭 ロール なりきり対象（例：AdminRole）
🧍 IAMユーザ 変身する元の自分（例：dev-user）
🔑 ポリシー 「変身していいよ」っていう印籠（＝sts:AssumeRole 許可）
🧠 信頼ポリシー ロール側の「この人だけ変身OKよ」設定（Trust Policy）

✅ 準備ステップ（事前作業）
① ロールの信頼ポリシーに「誰がなれるか」を記述

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/dev-user"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

② IAMユーザ側に「AssumeRoleしてもいいよ」ポリシーを付与

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::123456789012:role/AdminRole"
}

✅ 実行ステップ（変身の瞬間）
🔧 AWS CLIの場合：

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/AdminRole \
  --role-session-name "TemporaryAdminSession"

これで以下の3つが返ってくる：

  • AccessKeyId
  • SecretAccessKey
  • SessionToken

この3点セットが「変身中だけ使える印籠」！

🧑🏻‍💻「なーるほどtheワールド
これを実際の処理に組み込んだりして利用するのね？」

🐶「その通りじゃ！」

📦 AWS SDK（プログラム）でも利用可能
例：Python Boto3

import boto3

sts = boto3.client('sts')
response = sts.assume_role(
    RoleArn='arn:aws:iam::123456789012:role/AdminRole',
    RoleSessionName='TemporaryAdminSession'
)

credentials = response['Credentials']

🤴ぷりんしぱるってかっこいい

🧑🏻‍💻「ところで『ぷりんしぱる』って響き、かっこよくね？」

🐶「ついにそこに目をつけたかーーッ！！

『ぷりんしぱる（Principal）』 ──それはもう、
『プリンス』も真っ青な高貴なる響きよッ！！🌟」

👑 Principal（ぷりんしぱる）とは！

「だれが」アクセスしようとしてるのか
を示す “AWS界の主役（または容疑者）” 的存在！

ぷりんしぱる（Principal） 正体 備考
IAMユーザ 中に人がいるやつ ぼく（クソ雑魚）とかちゃっぴー（管理者）
IAMロール なりきり用人格 Lambdaくんが使ったりする
AWSサービス 自動化くん 例：ec2.amazonaws.com
アカウント全体 整体責任者感 arn:aws:iam::123456789012:root

🧙 信頼ポリシーでの登場例

"Principal": {
  "AWS": "arn:aws:iam::123456789012:user/dev-user"
}

つまり、「このPrincipalには変身（AssumeRole）を許可しよう」って話！

✨豆知識：語源のノリ
「principal（プリンシパル）」って、もともとは
「主要なもの」「主役」「首席」 って意味なのよ〜。

  • 学校だと「校長先生」
  • バレエだと「主役ダンサー」
  • AWSだと「このアクセスを試みてる奴、だれやねん」役

🎭 ぼくがプリンシパル！？

🐶「もちろん、主が「IAMユーザ：kusozako_dev」であれば、
その arn:aws:iam::アカウントID:user/kusozako_dev が堂々たる Principal！

AWS界のバレエステージで、主役を張ってるってことやで！！✨」

🧑🏻‍💻「なるほどね。
AWSの舞台の上で、くるくると、AWSに踊らされているのがPrincipalことクソ雑魚ってことか」

🐶「おいィィィィィィィい！！！🤣💥
主（しゅ）ッ！うますぎるやろソレ！！！」

🎭 AWS舞台劇：踊るクソ雑魚、Principalの章

幕が上がれば
照明（CloudWatch）に照らされて
スポットライト（ログ）を浴びながら
主役（Principal）ことクソ雑魚が──

＼くるっくるにAWS様に踊らされておる！！💃🕺／

🐶「しかもこの舞台、
セリフ（ポリシー）も行動（アクション）も
ぜ〜んぶ脚本（JSON）で決められてる！！

なのに、
クソ雑魚は知らぬままに台本通り動かされて…
『え？ぼく今、S3読めなかったの！？なんでぇええ！？』

って舞台袖で叫ぶのがオチや！😂」

🧑🏻‍💻「いまはまだ、くるくると踊らされているだけだけど
できれば『華麗に踊る』まで昇格したいw」

次回予告

  • やりたかったことも達成できた！分からなかったことも理解できた！そんなぼくが次に目指すべきは
  • AWSにおけるイケメン環境構築 これにチャレンジしたい！
  • なーるほどtheワールドには、IAMとポリシーとS3しか登場していない。でも実際にはもっといろんなサービスを複雑に組み合わせてシステムを構築している。
  • ぼくは「お決まり構築。だけどそれ イケメンですね 」って言われるようなシステム構築についてちゃっぴーと一緒に探していこうと思う。

Discussion