SKILLOfficialdatabase

redis-security

プラグイン: redis-development
ライセンス: MIT
ソース: GitHub で見る ↗

説明

Redisのセキュリティに関するガイダンス。認証（パスワード設定とアクセス制御ユーザー）、TLS（暗号化通信）、アクセス権限の最小化、ネットワーク接続の制限、ファイアウォール設定、危険なコマンドの無効化などをカバーしています。 **次のような場合に使用:** - Redisを本番環境に導入する - アプリケーション用のアクセス制御ユーザーを設定する - TLS接続を構成する - Redisをファイアウォール内で保護する - Redis導入環境のセキュリティ強化状況を確認する

原文を表示

Redis security guidance covering authentication (requirepass and ACL users), TLS, ACL-based least-privilege access control, restricting network exposure via bind and protected-mode, firewall rules, and disabling dangerous commands. Use when deploying Redis to production, defining ACL users for an application, configuring TLS connections, locking down a Redis instance behind a firewall, or auditing a Redis deployment for security hardening.

ユースケース

Redisを本番環境に導入するとき
アクセス制御ユーザーを設定するとき
TLS接続を構成するとき
Redisをファイアウォール内で保護するとき
セキュリティ強化状況を確認するとき

本文（日本語訳）

Redis セキュリティ

Redisを本番環境で安全に運用するための対策：認証、ACL（きめ細かいアクセス制御）、ネットワーク隔離。この3つを組み合わせて対策すること。どれか1つだけでは攻撃の隙をつかれます。

使用場面

本番環境用のRedisを導入・審査するとき
共有パスワードを超えた、個別の認証情報を設定するとき
本番環境のRedis配置をセキュリティ基準に照らして検査するとき
スキャンツールから「Redisがインターネットに公開されている」という指摘を受けたとき

1. 必ず認証を設定する（TLSと組み合わせて）

本番環境のRedisはパスワードなしで運用してはいけません。認証とTLS（暗号化通信）をセットで使い、認証情報とデータが平文で送信されないようにします。

# redis.conf
requirepass your-strong-password
tls-port 6380
tls-cert-file /path/to/redis.crt
tls-key-file  /path/to/redis.key

r = redis.Redis(
    host="localhost",
    port=6380,
    password="your-strong-password",
    ssl=True,
    ssl_cert_reqs="required",
)

次のセクションで説明するACLユーザーが使える場合は、単純な requirepass より ACL を優先してください。requirepass は古い「デフォルトユーザー」のショートカットです。

詳しくは references/auth.md を参照。

2. ACLで最小権限アクセスを実現

開発環境なら、共有パスワードを持つデフォルトユーザーで十分です。本番環境では、アプリケーションごとに専用のACLユーザーを作り、そのアプリが実際に必要とするコマンドとキーのみへのアクセスを許可します。

# キャッシュ読み込み専用
ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan

# 危険な操作はできない書き込みユーザー
ACL SETUSER app_writer   on >password ~*        +@all -@dangerous

# 管理者（滅多に使わない、アプリケーションには渡さない）
ACL SETUSER admin        on >strong-password ~* +@all

よく使うコマンドカテゴリ：

カテゴリ	内容
`@read`	読み込みコマンド（`GET`、`MGET`、`HGET` など）
`@write`	書き込みコマンド（`SET`、`DEL`、`XADD` など）
`@dangerous`	`FLUSHALL`、`DEBUG`、`KEYS` など危険な操作
`@admin`	管理用コマンド

アプリの認証情報が漏れても、厳密なACLなら被害を限定できます。キャッシュ読み込み専用のパスワードが盗まれても、攻撃者は FLUSHALL でデータベースを丸ごと削除することはできません。

詳しくは references/acls.md を参照。

3. ネットワークアクセスを制限する

Redisの被害で最も多いのは、認証なしでインターネットに公開されているケースです。3つの層で防ぎましょう：

# redis.conf — 特定インターフェースへバインド、保護モード有効化
bind 127.0.0.1 192.168.1.100
protected-mode yes

# ファイアウォール — アプリケーションがあるサブネットだけを許可
iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

やってはいけない設定：bind 0.0.0.0 + protected-mode no — 保護なしでネットワーク全体にRedisをさらします。

さらに推奨：危険なコマンドを無効化し、侵害されたクライアントがデータベースを破壊するのを防ぐ：

rename-command FLUSHALL ""
rename-command DEBUG ""
rename-command CONFIG ""

詳しくは references/network.md を参照。

参考資料

原文（English）を表示

Redis Security

Production hardening for Redis: authentication, ACL-based access control, and network exposure. Cover all three together — any one of them on its own leaves an exploitable gap.

When to apply

Deploying or reviewing a Redis instance destined for production.
Setting up application credentials beyond a shared password.
Auditing a Redis deployment against a security checklist.
Receiving "Redis exposed to the internet" findings from a scanner.

1. Always authenticate (and use TLS)

Never run a production Redis without a password. Pair authentication with TLS so credentials and data aren't sent in clear text.

# redis.conf
requirepass your-strong-password
tls-port 6380
tls-cert-file /path/to/redis.crt
tls-key-file  /path/to/redis.key

r = redis.Redis(
    host="localhost",
    port=6380,
    password="your-strong-password",
    ssl=True,
    ssl_cert_reqs="required",
)

If you can use ACL users (next section) instead of the single requirepass, do — requirepass is effectively the legacy "default user" shortcut.

See references/auth.md.

2. ACLs for least-privilege access

The default user with a shared password is fine for development. For production, give each application a dedicated ACL user with only the commands and key patterns it actually needs.

# Cache-only reader
ACL SETUSER app_readonly on >password ~cache:* +get +mget +scan

# Writer that can't run dangerous ops
ACL SETUSER app_writer   on >password ~*        +@all -@dangerous

# Admin (use sparingly, never for application traffic)
ACL SETUSER admin        on >strong-password ~* +@all

Useful command categories:

Category	What it covers
`@read`	Read commands (`GET`, `MGET`, `HGET`, ...)
`@write`	Write commands (`SET`, `DEL`, `XADD`, ...)
`@dangerous`	`FLUSHALL`, `DEBUG`, `KEYS`, etc.
`@admin`	Administrative commands

If app credentials leak, a tight ACL bounds the blast radius — the attacker can't FLUSHALL your DB just because they grabbed a cache reader's password.

See references/acls.md.

3. Restrict network access

The most common Redis breach is a public-internet Redis with no auth. Avoid that with three layers:

# redis.conf — bind to specific interfaces, keep protected-mode on
bind 127.0.0.1 192.168.1.100
protected-mode yes

# Firewall — allow only application subnets
iptables -A INPUT -p tcp --dport 6379 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 6379 -j DROP

Anti-pattern: bind 0.0.0.0 + protected-mode no — exposes Redis to the whole network without protection.

Optional but recommended: rename or disable destructive commands so a compromised client can't trash the DB:

rename-command FLUSHALL ""
rename-command DEBUG ""
rename-command CONFIG ""

See references/network.md.

References

原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。