はじめに
サポートダッシュボードには制限済みアカウントがありますが、まだ Redis の広いデフォルトアカウントで接続しています。設定を切り替え、監視を維持しながら旧経路を廃止します。
この独立環境には前のレッスンの dashboard アカウントがあります。そこで学んだ Redis コマンドと ACL の知識だけを使います。各操作は新しい接続を開くため、次のリクエストは現在の設定を使います。
新しい環境のアプリ動作を確認する
このステップでは、新しい環境の通常動作を確認します。Dashboard を開くと、入力は Ticket 104: password reset、結果は空、ユーザーは default です。Process ticket をクリックし、Processed: Ticket 104: password reset を確認します。
Client で非公開のアプリ設定を読みます。cat はファイルを表示します。端末は設定ディレクトリ /workspace から始まります。
cat app.json
JSON は波括弧内の名前付きフィールドでデータを保存します。username は Redis ユーザー、password は認証用の秘密です。文字列は二重引用符で囲み、フィールドはコンマで区切ります。現在のユーザーは default、パスワードは空です。
アプリはリクエストごとにファイルを読み直し、新しい Redis 接続を開きます。再起動やクライアント開発は不要です。別の monitor アカウントは monitor:heartbeat を読みます。デフォルトアカウントを変更しても動作を維持してください。設定には秘密が含まれるため、ファイルは非公開です。
ダッシュボードの接続を切り替える
このステップでは、アプリで制限アカウントを使います。Client で 2 フィールドの設定を置き換えます。cat > app.json は後続のテキストをファイルにリダイレクトし、旧内容を上書きします。引用された EOF はヒアドキュメントを開始します。最後の単独行 EOF も含めてすべて貼り付けます。引用符は JSON 内のシェル展開を防ぎます。
cat > app.json <<'EOF'
{"username":"dashboard","password":"Dash-Lab-42"}
EOF
変更するのは設定だけです。この新しいスナップショットでは、アカウントに support:* への GET/SET が既にあります。Dashboard を再読み込みし、ユーザーが dashboard であることを確認して Process ticket を再度クリックします。古い結果だけでは不十分です。この新しい操作が設定したアカウントの読み書きを証明します。
WRONGPASS の場合は JSON の認証情報を修正して再試行します。NOPERM の場合は Cache Server の cache-admin ACL GETUSER dashboard でキーパターンとコマンドを確認します。最初のラボの完全なリセットコマンドで誤設定を修復できます。JSON の構文エラーは上のブロックの再入力で修正できます。
maint を近道に使わないでください。アプリには専用の制限アカウントが必要です。
広いデフォルト入口を廃止する
このステップでは、正規アカウントを無効化せず、自動のデフォルト経路を無効化します。Cache Server に切り替えます。cache-admin の保守アカウントは有効のままなので、管理操作は続けられます。
ACL SETUSER default off は新しいデフォルトユーザー認証を防ぎます。有効な変更を設定済み ACL ファイルに保存します。
cache-admin ACL SETUSER default off
cache-admin ACL SAVE
両方とも OK を返します。Client に切り替え、認証情報なしの新規接続を試します。
redis-cli -h cache-server GET support:ticket
意図した拒否である NOAUTH Authentication required. を期待します。認証済みアカウントの権限不足を示す NOPERM とは異なります。ここでは毎回新しい接続を使います。ユーザーを無効化しても、既に認証済みのセッションの終了は保証されません。その取り消しは本演習の対象外です。
Dashboard を再読み込みし、Process ticket をクリックします。名前付きアカウントは動作するはずです。誤ったアカウントを無効化した場合は、保守端末で正しい完全なリセットルールを適用して保存します。アプリ設定エラーを隠すために広いデフォルトアカウントを再有効化してはいけません。
安全性と可用性を一緒に試す
このステップでは、許可された作業、禁止データ、不要なコマンドを比較します。Client を使い、各 --askpass の要求で Dash-Lab-42 を入力します。
redis-cli -h cache-server --user dashboard --askpass GET support:result
処理済みサポート結果は引き続き読めます。次は意図的に無関係な財務データを要求します。
redis-cli -h cache-server --user dashboard --askpass GET finance:payroll
NOPERM を期待します。CONFIG GET はサーバー設定を読みますが、この管理読み取りもアプリには不要です。引用した星印は全設定名を要求し、変更せず Redis に渡す必要があります。
redis-cli -h cache-server --user dashboard --askpass CONFIG GET '*'
コマンド権限による NOPERM を期待します。次に既存の監視アカウントを使い、パスワード要求に Monitor-Lab-42 を入力します。
redis-cli -h cache-server --user monitor --askpass GET monitor:heartbeat
healthy を期待します。全アカウントの無効化や Redis の停止はこの正常系テストを壊すため、修復にはなりません。Cache Server で有効な ACL と保存ファイルを表示します。
cache-admin ACL LIST
cat /data/users.acl
default off を含め、保存済みの項目は有効な項目と一致する必要があります。異なる場合は cache-admin ACL SAVE を再実行します。最後に Dashboard の Process ticket をもう一度クリックします。実際の可用性と適切な拒否の両方が結果を示します。正常なページだけでは最小権限を証明できません。
まとめ
実際のアプリを制限 Redis アカウントへ切り替え、新規デフォルトアクセスを無効化し、ACL を保存しました。禁止リクエストと正規の業務・監視操作を確認しました。テストは新しい接続を使い、既存セッションの取り消しを示すものではありません。
