従来のシステムでは、「社内ネットワークに接続しているから安全」「VPNを通過しているから信頼できる」という考え方が一般的でした。
しかし、クラウドサービス、リモートワーク、モバイル端末、外部APIなどが広く利用される現在では、ネットワークの内側と外側だけで安全性を判断することが難しくなっています。
そこで注目されているのが Zero Trust（ゼロトラスト） というセキュリティモデルです。
本記事では、ゼロトラストの基本的な考え方と、Webサービスへ取り入れる際の実践ポイントを紹介します。
Zero Trustとは？
Zero Trustは、簡単に言えば、
「最初から信頼せず、アクセスごとに確認する」
という考え方です。
よく知られている原則として、
Never Trust
Always Verify
があります。
つまり、ユーザーや端末がどこからアクセスしているかだけで信頼するのではなく、
- 誰がアクセスしているのか
- どの端末を利用しているのか
- どのリソースへアクセスするのか
- どの権限を持っているのか
を継続的に確認します。
従来型セキュリティとの違い
従来型のネットワークでは、境界防御を中心に考えることが多くありました。
Internet
↓
Firewall
↓
Internal Network
↓
Applications
Firewallの内側に入れば、比較的信頼された状態として扱われる設計です。
一方、Zero Trustでは、
User
↓
Identity Check
↓
Device Check
↓
Authorization
↓
Application
というように、各アクセスごとに確認します。
ネットワークの場所ではなく、IdentityとContextを中心に判断する点が大きな違いです。
1. Identityを中心に考える
Zero Trustでは、ユーザーIDが非常に重要になります。
単純なユーザー名とパスワードだけではなく、
- Multi-Factor Authentication
- Session Management
- Identity Provider
- Risk-Based Authentication
などを組み合わせます。
例えば、重要な管理画面へアクセスする場合は、通常ログインに加えてMFAを要求する設計が考えられます。
Password
+
One-Time Code
↓
Access
1つの認証要素だけに依存しないことが重要です。
2. 最小権限を適用する
Zero Trustでは、ユーザーへ必要以上の権限を与えません。
これは Least Privilege（最小権限） と呼ばれます。
例えば、
Viewer
→ Read
Editor
→ Read / Write
Admin
→ Read / Write / User Management
のように役割ごとに権限を分けます。
全ユーザーへAdmin権限を与えるような設計は避けます。
WebアプリケーションではRBAC（Role-Based Access Control）を利用すると管理しやすくなります。
RBACの簡単な実装例
Node.jsでは、次のようなMiddlewareを作れます。
function requireRole(role) {
return (req, res, next) => {
if (!req.user) {
return res.status(401).json({
error: "Authentication required"
});
}
if (req.user.role !== role) {
return res.status(403).json({
error: "Access denied"
});
}
next();
};
}
管理画面で利用する場合：
app.get(
"/admin",
requireRole("admin"),
(req, res) => {
res.json({
message: "Admin area"
});
}
);
重要なのは、フロントエンド側でボタンを非表示にするだけではなく、サーバー側でも権限チェックを行うことです。
3. Sessionを継続的に確認する
一度ログインしたからといって、永続的に信頼するべきではありません。
Sessionには適切な有効期限を設定します。
例えば、
Access Token
→ 15分
Refresh Token
→ より長い有効期限
のように役割を分ける方法があります。
重要な操作では再認証を要求する設計も有効です。
例えば、
通常閲覧
→ Session確認
メール変更
→ Password再入力
権限変更
→ MFA再認証
のように、操作の重要度によって認証レベルを変えられます。
4. デバイス情報も判断材料にする
Zero Trustでは、IdentityだけでなくDeviceも重要です。
例えば、
- OS
- Browser
- Device Status
- Security Update
- Login History
などを確認します。
通常と大きく異なる環境からアクセスされた場合は、追加確認を行うことができます。
ただし、デバイス情報だけでユーザーを完全に識別することはできません。
複数の情報を組み合わせて判断することが重要です。
5. APIごとに認可を行う
モダンなWebサービスでは、フロントエンドとバックエンドがAPIで通信するケースが一般的です。
Zero Trustの考え方では、
「ログイン済みだからすべてのAPIへアクセスできる」
という設計は避けます。
例えば、
GET /api/profile
と
DELETE /api/users/123
では必要な権限が異なります。
そのため、API単位で、
Authentication
+
Authorization
を確認します。
6. JWTを利用する場合の注意点
JWTはAPI認証でよく利用されます。
例えばPayloadには、
{
"sub": "user123",
"role": "editor",
"exp": 1760000000
}
のような情報を含められます。
サーバーでは、
- Signature
- Expiration
- Issuer
- Audience
- Role
などを検証します。
単にJWTをデコードできたからといって、安全とは限りません。
署名検証を必ず行う必要があります。
7. ネットワークだけを信用しない
Zero Trustでは、JLPH
192.168.x.x
のような内部IPだから安全、という判断だけ