Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
AIの権限設定に悩んでいる話
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Shuma
March 19, 2026
Programming
58
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
AIの権限設定に悩んでいる話
2026/3/19(木) 第四回 唐揚げ会 発表LT
Shuma
March 19, 2026
More Decks by Shuma
See All by Shuma
DB移行、油断した瞬間に 肝が冷えた話
shubox
0
21
インフラ深掘りLT
shubox
0
55
飲食店長から_SREになった話
shubox
0
49
Ansible で Vector を導入し Slack 通知とログレベル色分けまでした話
shubox
0
59
阿部寛のホームページをSRE観点で改善出来るか考えてみた。
shubox
0
150
一日の終わりに、晩酌しながら眺めたいシステムログの世界
shubox
0
130
プロダクトがクローズした話
shubox
0
190
今も熱いもの!魂を揺さぶる戦士の儀式:マオリ族のハカ
shubox
0
320
信頼性工学とは? ~カツオを題材に~
shubox
0
140
Other Decks in Programming
See All in Programming
言語を使う側から、作る側へ。 自作 Lisp で得た新たな気づき。
andpad
0
140
改善しないと、タスクが回らない。 “てんこ盛りポジション” を引き継いだ情シスの、入社3ヶ月の業務改善録
krm963
0
230
AI Engineeringは、AIプロダクトだけのものか? 〜AIがソフトウェアを作る時代の新しい当たり前〜 / No AI in your product. AI Engineering in your development.
rkaga
4
280
Lean は証明の正しさを確認するためだけのツールって思ってませんか?
inoueasei
1
120
PHP初心者セッション2026 〜生成AIでは見えない裏側を知る:今だからLAMPを通して仕組みを学ぶ〜
kashioka
0
730
Claude Team Plan導入・ガイド
tk3fftk
0
240
<title><a id="</title>君はこのHTMLをパースできるか"></a></title> #雑LT_study
pizzacat83
0
110
なぜ関数型プログラミングで「型」と「証明」が語られるのか #fp_matsuri
kajitack
3
1.1k
5分で問診!Composer セキュリティ健康診断
codmoninc
0
700
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
480
その節約、円になってますか?
isamumumu
0
490
地域 SRE コミュニティ最前線 - ホンマでっかSRE勉強会
tk3fftk
0
290
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
The Spectacular Lies of Maps
axbom
PRO
1
880
How to Get Subject Matter Experts Bought In and Actively Contributing to SEO & PR Initiatives.
livdayseo
0
160
The Illustrated Guide to Node.js - THAT Conference 2024
reverentgeek
1
420
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Optimizing for Happiness
mojombo
378
71k
エンジニアに許された特別な時間の終わり
watany
108
250k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
350
The Curse of the Amulet
leimatthew05
2
13k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
380
A Modern Web Designer's Workflow
chriscoyier
698
190k
Transcript
1 2 3 4 5 6 >_ AIは愛を知らないが、 エンジニアは AIを知っている
〜AIの権限設定に悩んでいる話〜 NotebookLM
自己紹介 名前: Shuma 職種: SRE / インフラエンジニア 興味: @ShuShuShuBOOOx 最近うれしかったこと
IaC, 障害対応, 監視, パフォーマンス改善 大きな負荷対策の監視をしていて 同じ会社の人とかなりのトラフィックをさば いたこと。
1 2 3 4 5 6 7 8 9 10
11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 「AIツール、業務で使ってますか?」 [ ChatGPT ] [ GitHub Copilot ] [ Claude Code ] [ Cursor ] 「権限設定してますか?」
$ Claude Code + Terraform で本番RDSが全消えした 月$5-10ドルの節約 → 2.5年分のデータが消えた (※24時間後に復旧)
> terraform destroy を承認したのは人間だった > 復旧対応でBusiness Supportにアップグレードしコスト10%増 → ソフトウェアとインフラ、両方が無防備だった (DataTalks.Club / Alexey Grigorev氏の事例)
None
settings.json 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 自分の実話①: deny ルールを設定した { "permissions": { "deny": [ "Bash(aws *)", "Bash(terraform *)", "Bash(kubectl *)" ] } } ✅ → 破壊的操作を全部止めた。方向性は正しい
>_ 自分の実話②:でも問題が出た 自分の実話②:でも、大きな問題が出た 1 aws * をdenyすると自分の作業まで邪魔してしまう 2 人間とClaudeが同じ .aws/credentials
を使っている 3 shared credentialsを使っているため、 Claudeの権限を絞ると人間の権限も絞れてしまう → じゃあどうする?
>_ 社内で出たさまざまな案 社内で出たさまざまな案(どれも帯に短し) 案A: credentialsをreadonly専用に 人間が不便 ✕ 案B: AI専用IAMユーザー作成 管理コスト増・攻撃面拡大
✕ 案C: 環境変数で分離 シェル履歴に平文で残るリスク ✕ 案D: SSO (IAM Identity Center) で分ける 初期設定・運用コストが高すぎる ✕ 案E: CLAUDE.md に禁止事項を書く 強制力なし ✕ → 完璧な単一解はなかった
> _ 現状の落としどころ:多層防御(第 1層) 1 { 2 "permissions": { 3
"deny": [ 4 "Bash(aws * delete*)", 5 "Bash(terraform destroy *)", 6 "Bash(terraform destroy)", 7 "Bash(terraform apply *)", 8 "Bash(terraform apply)", 9 "Bash(terraform state rm *)", 1 0 "Bash(terraform state rm)", 1 1 "Bash(aws iam *)", 1 2 "Bash(aws rds delete*)" 1 3 ] 1 4 } 1 5 } 第1層 Claude Code側の設定 deny ルール / Hooksでブロック → AIに「やらせない」 describe や plan は通す。 ⚠ ※aws s3 rmなどはすり抜ける可能性ありと注記
> _ 現状の落としどころ:多層防御(第 2層) 第1層(Claude Code側の設定) deny / Hooks →
AIに「やらせない」 第2層(インフラ側の物理的保護) 万が一指示しても「インフラ側で弾く」設定 IAM 最小権限 RDS 削除保護 Terraform prevent_destroy リモート State管理 AIに「やらせない」設定とインフラ側で「弾く」設定。この両輪が必要。
1 2 3 4 5 6 > まとめ:AIセキュリティの現在地 Q1: AIに本番環境を触らせるべきか?
Q2: denyルールはどこまで設定すべきか? Q3: インフラ側の保護は十分か? 結局、完璧な「正解」はない。 技術とリスクのバランスを見極め、 多層防御で対応していく必要がある。
1 2 3 4 5 6 7 8 9 10
11 12 13 › >_ Resources Claude Code official docs → docs.anthropic.com/en/docs/claude-code/settings Alexey Grigorev's Substack → alexeyondata.substack.com/p/how-i-dropped-our-production-database AWS IAM least privilege → docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html