IAM 與權限管理：最小權限原則，出事不會全滅

用 Root 帳號做所有事，等於完全不鎖門：Key 一旦洩漏，攻擊者拿到的是完整控制權，包括刪除你的資料和產生天文數字帳單。更麻煩的是，AI 生成的程式範例通常直接用 Root Key，不會主動提醒你建立限制權限的帳號。這篇帶你搞懂 IAM 的基本概念，學會用最小權限原則保護自己的專案。

IAM 是什麼

IAM（Identity and Access Management）是管理誰能對什麼資源做什麼事的系統。每個雲端平台都有自己的 IAM：AWS IAM、GCP IAM、Supabase 的 RLS 都是 IAM 的概念。

最小權限原則

最小權限原則（Principle of Least Privilege）：每個身份只給它執行任務所需的最小權限，不多給一分。這麼做有三個好處：洩漏損害最小化，就算 API Key 洩漏，攻擊者能做的事也被限制住了；bug 影響範圍最小化，程式 bug 導致的誤操作不會波及無關的資源；審計更容易，每個身份的操作都有明確範圍，異常行為容易發現。

AWS IAM 快速入門

如果你用 AWS 的服務（S3、Lambda、RDS），一定要理解 IAM 的基本操作。建立限制權限的 IAM User，不要用 Root：

1. 登入 AWS Console，進入 IAM → Users → Create User。
2. 選「Attach policies directly」，搜尋並附加你需要的 Policy，例如 AmazonS3ReadOnlyAccess。
3. 建立後進入 User → Security Credentials → Create Access Key，選「Application running outside AWS」。
4. 下載 Access Key ID 和 Secret Access Key，存到 .env。不要用 Root 帳號的 Key。

Supabase RLS：資料庫層級的權限

RLS（Row Level Security）讓你在資料庫層級控制誰能看到哪些資料列，是 Supabase App 的必設安全機制。

-- 開啟 RLS（預設關閉，開啟後所有操作都被擋）
ALTER TABLE posts ENABLE ROW LEVEL SECURITY;

-- 政策：只能看自己的文章
CREATE POLICY "Users can view own posts"
ON posts FOR SELECT
USING (auth.uid() = user_id);

-- 政策：只能新增自己的文章
CREATE POLICY "Users can insert own posts"
ON posts FOR INSERT
WITH CHECK (auth.uid() = user_id);

Service Account vs 個人帳號

很多人把個人帳號的 Key 用在程式裡，這是常見的安全問題。程式應該用 Service Account 或獨立的 API Key，不應該用個人帳號。

Vibe Coder 的 IAM 檢查清單

• 程式使用的 API Key 是 Service Account 或限制權限的 Key，不是個人帳號或 Root
• 每個 Key 只有它執行任務所需的最小權限
• Supabase 的所有資料表都開啟了 RLS
• 不同環境（dev、prod）使用不同的 Key，不共用
• 定期檢查有沒有閒置但未撤銷的 Key