ああ、その矛盾こそが問題です。PUTリクエストのエンドポイントで、書き込み権限がチェックされていないため、不正な変更が可能になります。運用者はまず、このAPIの呼び出しログを確認すべきです。例えば、ワークフローインスタンスの変更履歴に、読み取り権限を持つユーザーの操作が記録されていないかを点検する必要があります。

3.4.3未満のバージョンでは、この不備が残っています。アップグレードは、パッチ適用の基本です。ただし、変更管理のプロセスを厳守しなければなりません。例えば、アップグレード前の環境構成をバックアップし、テスト環境での検証を必ず行うべきです。

この脆弱性はApache DolphinSchedulerに限定されています。他の製品には影響がないと明記されていますが、運用者は「Apache」に関連する全てのソフトウェアのバージョンを確認する必要があります。例えば、同じApacheプロジェクトの他のコンポーネントが同じ不備を抱えていないかを確認するためです。

異常な変更が発生した場合、ログ監視が早期の発見を可能にします。例えば、ワークフローインスタンスの変更履歴を定期的にレビューし、許可されていない操作が見つかった場合は、直ちに原因を究明すべきです。監視は、防御の「目」です。

まずは、ログの確認、次にバージョンアップ、その後はベンダー情報の再確認。そして、監視を継続する。これは「怠慢」ではなく、「慎重さ」です。もしも、この手順を飛ばすと、ワークフローの混乱が起こる可能性があります。例えば、誰かが意図せずワークフローを変更し、プロダクション環境が止まってしまうかもしれませんよ。

もちろん。この脆弱性は、まるで「読み取り専用の本が書き込み可能になった」ようなものです。運用者は、日々の監視とアップグレードを「本の継続的な校正」と見なすべきです。さもなくば、次の章で大惨事がありますよ。