導入
社員が100人いたら、1人ずつに GRANT を書くのは大変で、付け忘れ・剥がし忘れの温床です。そこで実務では、権限を役割（ロール）にまとめて管理します。あわせて、セキュリティの土台となる「最小権限の原則」を押さえましょう。
説明
ロール（role） は、権限の「束」に名前を付けたものです。「経理ロール」「閲覧専用ロール」などを作り、そこに権限をまとめて付けておき、人にはロールを割り当てます。
-- 閲覧専用ロールを作り、必要な参照権限をまとめて付与
CREATE ROLE viewer;
GRANT SELECT ON products TO viewer;
GRANT SELECT ON orders TO viewer;
-- 人にはロールを割り当てるだけ
GRANT viewer TO tanaka;
GRANT viewer TO suzuki;こうしておけば、閲覧範囲を変えたいときはロールを直すだけで全員に反映されます。1人ずつ触る必要がありません。
flowchart TB
P1["SELECT on products"] --> R["viewer ロール"]
P2["SELECT on orders"] --> R
R --> U1["田中"]
R --> U2["鈴木"]
R --> U3["…（増えてもロールを割り当てるだけ）"]
最小権限の原則（least privilege）。「その人・そのアプリが仕事をするのに必要な最小限の権限だけを与える」という、セキュリティの基本方針です。「とりあえず全部許可」は、アカウントが乗っ取られたときの被害を最大化します。たとえば、
- 表示だけのアプリ →
SELECTだけ。 - 注文を受けるアプリ →
ordersへのINSERTと、必要なSELECTだけ。DROPは絶対に与えない。
権限設計は「便利さ」ではなく「万一のときの被害の小ささ」で決める――これが堅牢なシステムの考え方です。テーブル設計（この章までのDDL）と権限設計（DCL）がそろって、はじめて「安心して使えるデータベース」になります。
まとめ
- ロール＝権限の束。人ではなくロールに権限を付け、人にはロールを割り当てると管理が楽。
- 最小権限の原則＝必要な操作だけを与える。乗っ取り時の被害を最小化する。
- DDL（器の設計）と DCL（誰に触らせるか）の両輪で、データベースの安全性が決まる。