最小特権の原則（アクセス制御） — セキュリティ基本
最小特権の原則 (Principle of Least Privilege) とは、
「プログラムやユーザーに必要最小限の権限だけを与える」ことで、セキュリティリスクを減らす考え方です。
Javaでも、クラス設計やアクセス修飾子の使い方でこの原則を守ることができます。
基本の考え方
- 必要な権限だけ: 「誰でも触れる」より「必要な人だけ触れる」ように制御する。
- アクセス修飾子を正しく使う:
private→ クラス内部だけdefault（修飾子なし）→ 同一パッケージ内protected→ 同一パッケージ＋サブクラスpublic→ どこからでも
👉 原則: まず private にして、必要になったら範囲を広げる。
コード例で理解する
例題1: フィールドを private にする
public class User {
private String password; // 外部から直接触れさせない
public User(String password) {
this.password = password;
}
// 外部には安全な方法だけ提供
public boolean checkPassword(String input) {
return this.password.equals(input);
}
}
- ポイント: パスワードを直接公開しない。
- 最小特権: 外部は「照合」だけできるが「中身を読む」ことはできない。
例題2: クラスの公開範囲を制御
// パッケージ内部だけで使う補助クラス
class PasswordValidator {
static boolean isValid(String pw) {
return pw != null && pw.length() >= 8;
}
}
- ポイント:
publicを付けないと「パッケージ内だけ」で利用可能。 - 最小特権: 外部に不要なクラスは公開しない。
例題3: メソッドの公開範囲を制御
public class Account {
private int balance;
public Account(int balance) {
this.balance = balance;
}
// 外部に公開するのは安全な操作だけ
public void deposit(int amount) {
if (amount > 0) balance += amount;
}
public int getBalance() {
return balance;
}
// 内部処理専用（外部から呼べない）
private void auditLog(String msg) {
System.out.println("LOG: " + msg);
}
}
- ポイント:
auditLogは内部専用。外部から呼べない。 - 最小特権: 外部に不要な機能は隠す。
実務での応用
- API設計: 公開するのは「必要なメソッド」だけ。内部処理は隠す。
- ライブラリ開発: 外部に見せるクラスは最小限。内部ユーティリティは
package-private。 - セキュリティ: 機密情報（パスワード、トークン）は
privateに保持し、外部に直接返さない。 - テスト容易性: テストのために安易に
publicにしない。必要ならパッケージ分けやテスト用APIを設計。
テンプレート集
フィールドは基本 private
private 型 フィールド;
外部公開は getter/setter で制御
public 型 getフィールド() { return フィールド; }
public void setフィールド(型 値) { /* 検証してから代入 */ }
内部専用メソッド
private void helper() { /* 内部処理 */ }
パッケージ内部専用クラス
class InternalHelper { /* 外部には見せない */ }
まとめ
- 最小特権の原則: 「必要最小限のアクセス権だけを与える」ことで安全性を高める。
- Javaでの実践: アクセス修飾子（private, default, protected, public）を正しく使う。
- 実務効果: セキュリティ強化、バグ防止、APIの明確化。
👉 練習課題として「銀行口座クラス」を作り、残高フィールドを private にして、deposit と withdraw メソッドだけを public にすると、最小特権の考え方が体感できます。