原文はこちら。
The original article was written by Ana-Maria Mihalceanu (Senior Developer Advocate, Oracle).
https://inside.java/2024/12/11/quality-heads-up/
OpenJDK Quality Groupは、リリースの全体的な品質向上の手段としてOpenJDKビルドを使ってのFOSSプロジェクトのテストを推進しています。
Quality Outreach
https://wiki.openjdk.java.net/display/quality/Quality+Outreach
このHeads upは、関係するプロジェクトに送られる定期的なコミュニケーションの一部です。このプログラムの詳細と参加方法については、上記wikiをご覧ください。
The quality-discuss Archives
https://mail.openjdk.org/pipermail/quality-discuss/
The Security Manager is a Legacy Feature with High Costs and Low Adoption
最小権限の原則を徹底するために導入されたSecurity Manager（セキュリティ・マネージャー）は、ファイルやネットワーク接続などの機密リソースへの不正なコードのアクセスを防止するように設計されました。 理論上は効果的ですが、実際にはいくつかの理由により、期待通りの効果は得られていません。
| complexity （複雑） | 多くの開発者は、Security Managerのパーミッション・モデルを煩雑だと感じています。 |
| limited adoption （限定的な採用） | 長い歴史があるにもかかわらず、Security Managerは Java アプリケーションではほとんど使用されていません。 |
| maintenance overhead （メンテナンスのオーバーヘッド） | Security Managerの最小特権モデルは、Javaライブラリに大きな複雑性を課しています。1,000以上のメソッドで権限の確認が必要であり、1,200以上のメソッドで権限の昇格が必要です。これらの確認を維持することは、貴重なOpenJDK contributorの時間を消費します。 |
| modern threat landscape （最近の脅威の状況） | 悪意のあるデータやシリアライゼーション攻撃などの最近のセキュリティ上の課題に対処する能力が、Security Managerは不十分です。 |
しかしながら、長年にわたって、Security Managerの複雑性、採用件数の少なさ、メンテナンスコストはSecurity Managerのメリットを上回るものでした。Security ManagerはJava 17で廃止され、コミュニティからのフィードバックもほとんどないため、Security Managerの時代が終わったことは明らかです。
Phasing Out the Security Manager
Java 17では、JEP 411により、Security Managerが廃止され、削除されることが決定しました。
JEP 411: Deprecate the Security Manager for Removal
https://openjdk.org/jeps/411
今後、JDK 24では、その機能は事実上無効化されます。主な変更点は以下の通りです。
| Security Managerの無効化 | コマンドライン・オプションを使って起動時にSecurity Managerを有効化できなくなります。そして実行時にカスタムのSecurity Managerをインストールすることもできなくなります。 |
| Security Manager APIを機能しないようにする | Security Manager APIは互換性目的で残りますが、操作上の効果は無くなります。 |
| 保守性の向上 | Security Managerをサポートする専用の数千行のコードが削除されます。OpenJDK contributorが最新のセキュリティ機能の実装に専念できるようになります。 |
旧バージョンのJavaや、Security Managerに依存するレガシー・アプリケーションを使用している開発者や企業では、JDK 24までは引き続きアクセスできます。それ以後は、代替のサンドボックスやAPIインターセプトの仕組みへの移行が推奨されます。
一部のアプリケーションでは、System.exit への呼び出しをブロックするなど、Security Managerを使用してJavaプラットフォームAPIへの呼び出しをインターセプトしていました。 ほとんどの場合、これはセキュリティ上の懸念事項ではありませんが、インターセプトはアプリケーションの動作のデバッグや管理に役立ちます。 以下で、Security Managerによるインターセプトメカニズムよりも信頼性の高い代替アプローチをいくつか紹介します。
| 動的なコードの書き換え | バイトコード操作エージェントなどのツールを使用して、Security Manager に頼らずに動作をインターセプトし、変更できます。 |
| 静的解析 | 導入前のツールを使用して、開発サイクル中に望ましくない API 呼び出しを特定し、防止できます。 |
Taking Action
JDK 17でのSecurity Managerの廃止は、ほとんどのJava開発者には、ほぼあるいはまったく影響を与えませんでした。JDK 17～23で発行されていた警告は、Javaエコシステムではほとんど議論の対象にならず、その関連性の低さを浮き彫りにしました。さらに、Jakarta EE、Ant、Tomcatなどの主要なフレームワークやツールはすでにSecurity Managerのサポートを削除しており、この傾向を強めています。
6.2.2. Jakarta EE Security Manager Related Requirements
https://jakarta.ee/specifications/platform/11/jakarta-platform-spec-11.0-m4#jakarta-ee-security-manager-related-requirements
August 20, 2023 – Apache Ant 1.10.14 Released
https://ant.apache.org/antnews.html#Apache%20Ant%201.10.14
Security manager (Apache Tomcat 11 (11.0.2) – Security Considerations)
https://tomcat.apache.org/tomcat-11.0-doc/security-howto.html#Security_manager
Security Managerに依存しているアプリケーションについては、JDKはその使用を特定し対処するためのオプションを提供しています。
jdeprscan | JAR ファイルをスキャンし、廃止API 要素の使用をチェックできるため、こうしたメソッドを使用しているコードを見つけるのに役立ちます |
| ローカルおよびスクリプトで、Javaアプリケーションの起動方法をチェック | コマンドラインオプションでSecurity Managerを許可または有効にしたり、インストールおよび構成が必要なポリシーファイルを使用したりしている可能性があります。 |
| コンソール上のメッセージの警告 | 実行時のSecurity Managerを利用していることを強調しています。 |
Jdeprscan – Deprecated API Elements Scanner
https://dev.java/learn/jvm/tools/core/jdeprscan/
これらのツールは、将来のJDKリリースでSecurity Managerが完全に削除される前に、コードの保守担当者が移行するために必要なインサイトを与えます。これらの手順を踏むことで、より効果的なセキュリティ・プラクティスを採用しながら、Security Managerからのスムーズな移行を確実に行うことができます。
More Details
このエントリでは概要をまとめています。詳細については、JEP 486を確認してください。
JEP 486: Permanently Disable the Security Manager
https://openjdk.org/jeps/486
Logico Inside 